Про ниасиливших Scala (или фигак фигак и сервисы на Go лучше)

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

jimplush.com/...​eam-from-scala-to-golang
вот вам интересная статейка

Внутря — стоны обиженных scalaz и проклятыми функциональщиками, рассказы про то как ’да я уже 7 (семь Карл) лет программирую и прочие стоны обиженых.

Интерисуют мнения, выводы да и срачь в коментах тоже.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному3
LinkedIn

Найкращі коментарі пропустити

По прошествии пяти лет, Go оказался востребованным и полезным языком, а Scala так и осталась уделом душных фриков.

«Недолго музыка играла, недолго фраер танцевал»

Dropbox намучился с go и отказался от него в пользу rust
www.wired.com/...odus-amazon-cloud-empire

А ведь раздача файликов по сети это собственно то, ради чего go изначально и создавался

Самый важный плюс Go это его читаемость и единый стиль. Когда открываешь любой проект на гитхабе написанный на голанге, его ОЧЕНЬ легко понять и вьехать что там происходит, и уже через денек можно контрибьютат. В то время как каждый проект на Scala, да и на Java, надо сидеть долго и упорно разибраться что там происходит и какой там код-стайл. Особенно в скалке, где на каждом маломальски большом проекте — свой субдиалект языка. Отсюда и продуктивность Go, программист концентрируется на задаче, а не думает как бы ему написать тот или иной кусок кода.

Если приводить аналогии, то Go можно сравнить с русским языком, который и в Африке русский, а Scala с китайским, где в каждой провинции свой, непонятный другим диалект.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Так спарк можна й на джаві або пайтоні.

Очередная драма в лагере гоубоев.

После добавления дженериков, Гугл захотел сделать то, что он умеет делать лучше всего — встроить spywareopt-out сбор телеметрии в тулчейн Go, собирать данные с компьютеров программистов и билд серверов без чьего-то согласия. Народ нихрена не понял, возмутился, устроил срач на 500 коментов на гитхабе. Предсказуемо, тред залочили, неугодных забанили.

Наступним кроком буде перегляд реклами перед початком білду?

Дякую за новину про телеметрію, відключу

Так вони ще її не додали, це просто обговорення про бажання додати.

От того, что Go будет передавать телеметрию в Google, мне пофиг. А вот от того, что альтернативно одаренные любители матана с функциональщиной и бесполезными абстракциями засирают библиотеки Go бессмысленными дженериками, мне плохо. Поэтому лучше бы удалили дженерики перед добавлением телеметрии.

мне плохо

Приходи к нам в Rust, мы тебя научим.

Чему, засирать бесполезными абстракциями?

Научим пользоваться дженериками чтоб вместо «ой как мне плохо, дженерики добавили», вы говорили «ой как мне заебись что дженерики добавили»

А темплейтами C++ нужно сначала разучиться пользоваться, или это только на руку?

Вівсьоврьоті! :D Go запускається швидше навіть, ніж блок з інструкціями потрапляє в L0 кеш проца. Він ще в пам’яті починає виконуватися.

Тому що фанатизм безмежний. Він за межами логіки та базується виключно на емоціях.

Вообще в Go как ни крутись, но рано или поздно появляется код на C. По разным причинам, то ли нет высокопроизводительного решения на Go, то ли вообще в принципе библиотека написана на C. А это за собой тянет ещё ряд особенностей. Во-первых, падает скорость компиляции проекта, и она становится равной компиляции кода на C. Во-вторых, теряется возможность собирать проект под некоторые платформы, поскольку нет компилятора C под какие-то платформы, и вообще код на C под них не тестировался. В-третьих, сокращаются возможности для кросс-компиляции, для этого нужны танцы с бубном. Соответственно, если проект развёртывается на другой машине, требуется долгий и творческий процесс установки и настройки. Можно конечно писать всё в девконтейнере, который займёт 2,5 гига только один образ. Поэтому разворачивать на типичном ноутбуке с 16 гигами такой вариант с девконтейнером — нецелесообразно, через пару часов разработки будет дикий свопинг из-за утечки памяти со стороны докера. Ну и конечно, код на C — неуправляемый, со всеми вытекающими следствиями. С другой стороны — а где картина выглядит как-то получше? Так что, если какие-то сложности при разработке на Go и возникают — они связаны с обузой из других языков/технологий.

Походу самый долгоиграюший топик xD

Скоро выходит Go 1.20 с супер-полезной фичей — profile-guided inlining. tip.golang.org/doc/go1.20 . Ещё бы дженерики выпилили — получился бы лучший релиз.

Scala уже не подаёт признаков жизни. Ее ждёт удел Algol.

Кстати, а ты ту фичу из 1.17 не юзал ещё? Я тут посмотрел, компилятор выдаёт ошибки при компиляции кода прямо из примера вот отсюда tip.golang.org/...​to_array_or_array_pointer
вот код, скопировал как есть — go.dev/play/p/96nkeJU1DhO
выходит, что там фигню написали?

Там нужно выбрать версию go dev, т.к. go 1.20 ещё не вышел, и код по умолчанию запускается под go 1.19. Вот по этой ссылке работает как надо — go.dev/...​lay/p/96nkeJU1DhO?v=gotip

Ну понятно, работает. В общем, там создаётся новый array, и копируются значения из слайса, а не возвращается исходный нижележащий массив.
go.dev/...​lay/p/UrD7R4o3i2j?v=gotip
То есть, синтаксический сахар для функции copy. Удобная фича.

Если нужен указатель на массив из слайса, то вот такой код должен работать: go.dev/...​lay/p/kL0YS5U1NXD?v=gotip

Hive switches from GoLang to Rust

The switch from GoLang to Rust
The main difference between the new Hive variant and old ones is the programming language used. The old variants were written in Go (also referred to as GoLang), while the new Hive variant is written in Rust.

By switching the underlying code to Rust, Hive benefits from the following advantages that Rust has over other programming languages:

* It offers memory, data type, and thread safety
* It has deep control over low-level resources
* It has a user-friendly syntax
* It has several mechanisms for concurrency and fearless parallelism, thus enabling blazingly fast and safe file encryption
* It has a good variety of cryptographic libraries
* It’s relatively more difficult to reverse-engineer

* It has a user-friendly syntax

Если они считают, что у Rust синтаксис проще, чем у Go, то остается один вариант — у них Rust головного мозга. К сожалению, медицина здесь бессильна :(

frp is written in Golang and is kind of a long-running system-wide service that provide network access to devices behind NAT or firewalls. It’s the only widely used project after ngrok 1 was stopped.

I’ve rewritten (and redesign?) frp in Rust, and seen a large improvement in performance and memory

The outcome is surprisingly good. Only 1/5 memory is used and the throughput is like several times larger than frp. I think Rust really has advantages in system software, particularly speaking, rewriting those written in Golang in the past :)

В Go подвезли дженерики — ждем появление STL и aspect-oriented packages на Go в стиле Александреску :( Программы на Go переписывают на Rust. Значит, пора переписывать VictoriaMetrics с Go на Rust.

пора переписывать VictoriaMetrics с Go на Rust

Sign me up

Значит, пора переписывать VictoriaMetrics с Go на Rust.

Варто очікувати статті на DOU на тематику Rust? (Це перший варіант моєї реакції)

Значит, пора переписывать VictoriaMetrics с Go на Rust.

Яку ж БД мені тепер згадувати у стаття про Go? (Це другий варіант моєї реакції)

old.reddit.com/...​ware_in_the_wild/hkg2h75

A lot of endpoint security solutions a.k.a. virus scanners often deletes Go binaries when they reach a certain level of complexity. Crowdstrike just deletes every single Go executable.

Потому что антивирусы — самые бесполезные программы. Они не находят новые трояны с вирусами, пока разработчики антивируса не добавят их сигнатуры в антивирусную базу (на это могут уйти годы для нишевых вирусов/троянов). Кроме заведомо устаревших баз, антивирусы способны затормозить самый последний Apple M1 Pro до уровня ЕС1840 и поломать работу нормальных программ вроде тех, что написаны на Go.

Ты не очень понимаешь как они работают, к тому же написать не детектящийся вирус/троян нужна оч высокая скиллуха, а когда она есть ты не хочешь устраивать дестрой по фану, а лучше потратить время на работу с высоким рейтом, вспомни эпоху вирусов в нулевых (если ты ее застал), было все вплоть до уничтожения железа, а сча тройны да майнеры одни, которые изи находит почти любой антивирус

Вот поэтому, чтобы продолжать есть хлеб с маслом, разработчики антивирусов начинают выкручиваться как умеют, и детектить по любой надуманной причине.

Чёт не помню у себя ложных срабатываний у антивируса за последние 10 лет точно

Так вендовый дефендер срабатывает на всех кейгенах, и даже на мю-торренте. Остальные не проверял, поскольку этот хлам не нужен, но уверен, что картина та же. И теперь будет при дальнейшей развитии мысли антивирусописателей, что если исполнимый файл без сертификата, без иконки, и прочей лабуды — значит это малваре, что же ещё.

Так вендовый дефендер срабатывает на всех кейгенах, и даже на мю-торренте.

Битдефендер, есет тоже самое.

это как программисты считают что в дотнет коре есть di... выброси заглушку и поставь настоящий антивирус

А нічого, що це шпигунське програмне забезпечення?

шпигунське програмне забезпечення

dot ru

а, вот оно что... так есть же контрмера — шапочка из фольги

а, вот оно что... так есть же контрмера — шапочка из фольги

 Ну в США вирішили, що забанити касперский вийде дешевше, ніж купувати всім шапочки з фольги: www.nextgov.com/...​ernment-contracts/159742

Омг, нормальных антивирусов десяток, бери любой другой

Омг, нормальных антивирусов десяток, бери любой другой

+1. Бери будь-який норм. антивірус не зв’язаний за рашкою.
П.С. Я може не зрозумів весь тред просто. )

шо там с зиллою ?
я юзаю, но шот сомнения о его качестве имеюццо )

я юзаю, но шот сомнения о его качестве имеюццо )

Я колись собі поставив Comodo, який наче в Одессі пилили. Після запуску він зупинив/відправив в карантини половину сервісів Win XP: годиник, перемикач мови, etc.
І головне не має що йому заперечити ))

Самый лучший антивирус — Ubuntu. За 15 лет ежедневного использования ни одного вируса не пропустил.

это не антивирус, а операционная система для людей, у которых нет потребности в компьютере в принципе, телефон еще хороший антивирус — попробуй, желательно, который ретро

Какие потребности в компьютере не покрываются Ubuntu?

Все что отличается от браузера и редактирования документов в каком-нибудь недоредакторе

Сложно даже вспомнить, какой редактор не имеет версии под Linux, кроме Visual Studio и Xcode

Это точно. Вот поэтому я поставил Ubuntu под WSL, всё классно, и теперь даже не вспоминаю, какой редактор не имеет версии под Linux.

А что еще, кроме браузера и редактирования исходников, нужно программисту?

Dota 2 идет отлично, CS:GO, Metro все части, большая часть игр total war.
Большинство остальных игр с танцами и бубнами. В этом плане есть прогресс благодаря Steam и Lutris (под капотом конечно Wine).

Да, нет Microsoft Office, и популярных программ для обработки фото/видео. Есть бесплалатные альтернативы, но наверное они менее мощные, но я таким не занимаюсь, мне сложно оценить. Из известных есть Davinci Resolve. Adobe нет. Есть OBS.

Вы просто из .NET, у вас предвзятое мнение, Вы завязаны на Microsoft)

Конечно для среднего пользователя Ubuntu это сложно, зато бесплатно, и как Вы отметили, браузер там есть, и основные программы или их замены (бесплатные) тоже есть.
Но конечно, стабильность и выбор программ уступает Windows, но для разработчика там все есть, кроме тех кто пишет на C#, Swift, Objective-C.

Dota 2 идет отлично, CS:GO, Metro все части, большая часть игр total war.
Большинство остальных игр с танцами и бубнами. В этом плане есть прогресс благодаря Steam и Lutris (под капотом конечно Wine).

та не верю я в такое, игры под линукс не работают, уверен что почти у каждой что-то такое: steamcommunity.com/...​ns/0/2288338908678031190 просто первая ссылка нет фпс, не играбельно

Да, нет Microsoft Office, и популярных программ для обработки фото/видео. Есть бесплалатные альтернативы, но наверное они менее мощные, но я таким не занимаюсь, мне сложно оценить. Из известных есть Davinci Resolve. Adobe нет. Есть OBS.

увы, это бесплатный недософт, работа с видео/звуком тоже в глухом тупике

Вы просто из .NET, у вас предвзятое мнение, Вы завязаны на Microsoft)

уже не 2000-ные... я видел полно .нет разрабов на макосях и линуксах

Конечно для среднего пользователя Ubuntu это сложно, зато бесплатно

для среднего пользователя и виндовс бесплатно

и как Вы отметили, браузер там есть, и основные программы или их замены (бесплатные) тоже есть.

они не дотягивают до оригиналов

Но конечно, стабильность и выбор программ уступает Windows, но для разработчика там все есть, кроме тех кто пишет на C#, Swift, Objective-C.

для шарпа там все есть, но зачем добровольно пользоваться этим убожеством я не понимаю. мне понятно фрибсд и т.п., но линукс с графической оболочкой это просто на смех курам

«не верю в такое», «недософт», «зачем добровольно пользоваться этим убожеством», «на смех курам», «система для людей, у которых нет потребности в компьютере в принципе»

Все понятно) Сойдемся на том, что на линукс меньше вирусов, а на виндовсе программ больше и фпс стабильней.

полно дистрибутивов которые никогда не продавались и не подавались трюкам типа убунты с их поиском с амазона. Та и потом они его после скандала сделали опциональным. Убунта раскрутилась за счет установки в 1 клик слоупоками, хотя дебиан, от которого она форкнулась практически имел те же самые возможности

Debian — если stable, то старое, а если testing/unstable, то вечно проблемы.
Ubuntu выехала на том, что заткнула именно эту дыру.
Сейчас поддеградировала, конечно, с 2-летними LTS, но тоже прилично.

сейчас поколение антивирей давно ушло вперед от тех, что были 10 лет назад. Сэмплы высылаются в облако, где снифается весь трафик и действия трояна в песочнице. Используются эмуляторы и вм, и сигнатуры это только одно из защитных свойств, хотя я никогда не одобрял антивири, и с винды ушел много лет назад

Сэмплы высылаются в облако, где снифается весь трафик и действия трояна в песочнице. Используются эмуляторы и вм, и сигнатуры это только одно из защитных свойств, хотя я никогда не одобрял антивири, и с винды ушел много лет назад

Це робили з самого початку тільки все називалось простими словами

Антивірь по факту є діркою для доступу до машини

Сігнатури — так і залишилось основним методом
Причому їх так само роблять люди після реверсу сорців

сигнатуры давно для слабаков, все серьйозные конторы имеют свои песочницы и подрядчиков или даже свой инхауз тим для анализа. Ну и конечно жестокое разделение сетей.

Honeypots — були завжди
Сігнатури — це більш-менш надійний спосіб. Всі оті «розумні» способи визначення базуються на логіці — а давайте відправимо всі executables користувача до «лабораторії»

Про мережі ви не зрозуміло для чого згадали

)) да-да, а кастомные вирусы стали чекать название машины что бы определить — запускаться или удаляться.

Уже месяц прошел с момента выхода Go 1.17, но еще никто не написал об этом :( golang.org/doc/go1.17 .

Самое крутое изменение — теперь аргументы передаются в функции через регистры процессора вместо стека. Это поднимает производительность программ на 5%, одновременно уменьшая их размер на 3%. См. golang.org/doc/go1.17#compiler . Дженерики пока что не подвезли (и это здорово!)

Шел 2021 год
Го-девелоперы, внезапно, открыли для себя __fastcall
Мир уже никогда не будет прежним

У них тотальный NIH (простите, каламбур сам получился).
В чём-то это, может, и хорошо (для всего независимая реализация, начиная с сисколлов и линковки), но такими темпами до SSA они дойдут лет через 10.

Забавно. Но, судя по типовому ассемблеру, оно не было включено ещё в совсем недавних версиях.

Генератор с SSA очень характерно отличается от генератора без SSA. При SSA нет фиксированной позиции каждой переменной в стеке, одна позиция может использоваться в разное время для разных переменных, переменные могут находиться в регистрах во время других сложных вычислений, переезжая между регистрами, вытесняясь в стек и возвращаясь, и так далее.
Если же посмотреть на типовой выхлоп в чём-то более-менее сложном (как docker), там фиксированные позиции, переменные достаются из стека на короткое время и результаты кладутся тут же обратно, между операторами состояние стека содержит все переменные в конкретных местах. Это или не SSA, или оно использовалось крайне ограниченно, даже без оптимизации одной функции в целом.

Здорово. Ещё могли бы взять C-компиллер, и по списку пройтись по всем оптимизациям на предмет реализации в Go-компиллере. А дженерики обещали запилить во 2-ой версии, пока что толкового драфта даже не показали.

или компилировать Го через промежуточный С код (trollface)

Лучше компилировать Go через промежуточный js-код

Жалко для ARM пока что недоступно

Теперь тормознутый говнокод будет тормозить на 5% быстрее :-)

Не знаю насчет говнокода, но нормальный код на Go тоже работает на 5% быстрее при переходе с компилятора go1.16 на go1.17.

Это конечно хорошо но что насчет слаки, тимза и скайпа? Когда их починят? Кстати на линухе вамще дерьмище, иногда падают(первые два, третим уже практически не пользуюсь), просто от клик на какой-то кнопке :-)

Ни одно из этих приложений не написано на Go, так что претензии не принимаются

но эталонный говнокод на Go

Fixed.
Лайна в этой репе с момента нашей последней дискуссии меньше не стало, скорее наоборот)

ОК, ждем ваш open-source проект с идеальным кодом

Целый месяц с мыслями собирался?))

апгрейтнулся и таки да на слабенькой конячке быстрее скомпилилось и запустилось а вот скорости сравнительно передачи переменных по ссылке и по значению надо будет проверить — наверное уже будет всетаки по ссылке быстрее раз не встеке значения...

С грамматикой у тебя ппц как плохо

Фигня какая-то в модульной системе Go. При переходе с одной минорной версии на другую — всё гладко и чётко, однако рано или поздно в библиотеке появляются breaking changes, и нужен переход на новую мажорную версию. Если просто поставить в гите тег v2 какой-нибудь, то линтер выдаст, что допускается только v0 или v1, и будет дальше продолжать грузить 1-ю версию. А для 2-ой и последующих версий нужен отдельный путь, который оканчивается на v2 (или v3 и т.п.) Причём это форсят в мануалах по модульной системе. То есть другими словами, они предлагают скопировать весь код со всеми структурами папок в дочернюю папку v2, и дальше там развивать как 2-ю версию. Вот что это за бред вообще? И зачем это надо?

Разберём на пальцах. В результате в github.com/user/project будет лежать 1-я версия, а там же в github.com/user/project/v2 будет лежать 2-я версия. При этом если закомитить в дефолтной ветке какие-то исправления в 1-ой версии, в github.com/user/project, то они по правилам модульной системы видны не будут, поскольку подгружается последний комит с меткой v1, а у нас это закомитили уже после метки v2. Можно конечно для 1-ой версии сделать отдельный бренч, но нафига? Этот бренч никто читать не будет, и go get с ним работать не станет. go get вообще не работает с бренчами кроме дефолтного. Можно конечно в readme написать, что извлекайте не через go get, а через кучу git-команд этот отдельный бренч, но опять-таки этот readme никто не прочтёт, только если мы его не продублируем во всех бренчах. Да и это очень экзотический вёркфлоу, поскольку все работают через go get. Итак, при такой модульной системе на гитхабе зачем-то лежит отдельным мёртвым грузом 1-я версия, куда невозможно вносить исправления, и которая с тем же успехом просто извлекается по старой метке.

Я думаю, что разумнее было бы просто позволить go get работать с бренчами, и тогда последняя мажорная версия извлекается по дефолтному бренчу, а предыдущие мажорные версии со всеми исправлениями можно было бы извлекать по отдельным бренчам. И что интересно, я ещё не видел ни одной библиотеки кроме yaml, где бы реализовали модульную систему на разных мажорных версиях. Только и тут есть одно но. Эту библиотеку на разных мажорных версиях реализовали до появления этой модульной системы.

Заставив себе прочитати.

Замітка форумним гоу-боям: вчіться, як треба хвалити.
А то ваші дописи та їх формулювання у цій темі — це антиреклама для Go та його екосистеми (особливо тон дописів).
Ну, хіба, насправді це і було вашою метою — тоді так, у вас вийшло.

Вышла новая версия go — 1.16 — golang.org/doc/go1.16 . Следуя древней традиции разрабртчиков scala и c++, синтаксис Go был в очередной раз расширен — golang.org/doc/go1.16#language .

Самая главная вещь, что там добавили — это стандарты на интерфейсы виртуальной файловой системы. Именно этого функционала раньше не хватало, поскольку систематизирует работу с большим количеством статических файлов, файловых систем в памяти, а также теперь можно работать с zip, iso и с прочими файловыми системами юзая стандартные интерфейсы.

Я когда читал описание, у меня было такое впечатление, будто бы авторы подсматривали код моей библиотеки github.com/schwarzlichtbezirk/wpk, поскольку не только состав интерфейсов совпадал, но и их сигнатуры мало чем отличались. Это большой плюс, что теперь этот функционал есть в стандартной либе, а код в своей я без труда уже привёл под общий стандарт.

Итак, Go получает генерики,
github.com/...​51#issuecomment-776944155

В каментах открыта стена плача для гоубоев.

Сейчас Валялкин прийдет и расскажет на сколько в Го будут крутые генерики, не то что в других языках.

открыта стена плача для гоубоев

Индусятские „копи-паста-архитекты” уже выстроились стеной. :)

„I know its not a fair comparison, but I think the spirit of simplicity of Golang was born from the incredible weight of complexity that languages like C++, Java, and Scala evolved into over years of iterative/feature ‚improvements’. In my mind Golang from go from an O(N) to O(N*N) complexity overnight once this feature is released.

To my surprise I have literally not missed generics once since switching to Golang and I used to be a huge proponent of them writing all kinds of elegant Scala code. My mind was freed from the extra layers of abstraction and I could focus on solving problems... it just required a slightly different way of thinking about the modeling. Being free from unnecessary abstraction in Golang is what allows people to move so fast with it IMO.

That being said, I will continue to use Golang because there really is not a better option out there for rapid and performant development right now.”

incredible weight of complexity that languages like C++, Java, and Scala evolved into

LOL, Java як раз була задумана простішою альтернативою Плюсам — без множинного наслідування, оверлоадінга операторів і решти ускладнень. Явно зайва в цьому списку.

и всеравно народ не осилил, слишком сложно.

Дивно що вони сподіваються що golang їм допоможе — говнокодали б одразу на JavaScript :D

и всеравно народ не осилил, слишком сложно

Так могут дальше на плюсах продолжать кодить, всё равно множественное наследование там никто не использует, не нужно совершенно.

в плюсах из сложностей не токо множественное наследование.

Для тих, хто дуже чекав))
A Proposal for Adding Generics to Go
blog.golang.org/generics-proposal

Не проблема. Всё ещё можно поныть из-за обработки ошибок

Уже давно есть драфт с механизмом check-handle для обработки ошибок, с его использованием код значительно упрощается.

то есть спустя 11 лет Го может все таки приведут к нормальному языку, и он будет не хуже чем джава 10 лет назад

Ну и чем он в таком случае будет хуже джавы?

А я один тут такой, которому и без Genericов живется ничего ?

У тому то й справа... Нас більшість...
Це, певно, якась політкоректність щодо прихильників.. ;)))
«Generic Lives Matter»:))

Валялкин еще
Но будет хохма, если таки добавят

Наверное на скалу перейдут после выхода Go 2 с генериками.

Дело не в дженериках а в задачах. Я понимаю что 99% гошников не сталкиваются с задачами где нужно много работать с коллекциями (или другими задачами, где дженерики бы пригодились), но каждый раз тошнить «дженерикиненужны» — уже начинает надоедать.

Наличие дженериков позволит писать больше переиспользуемых библиотек, хотя и есть риск что в руках неумелых новичков дженерики будут юзатся где-попало (но это уже не вина языка).

Если даже священный Роб П. согласился с дженериками — значит есть причина, и какой-никакой запрос.

В Go есть и другие сомнительные вещи которые есть давно из коробки, но о них почему то предпочитают молчать (например empty named returns).

Він був як заміна С, С++, а не PHP

с garbage collector ему заменой си не светило никогда

(например empty named returns)

А что там сомнительного?

есть риск что в руках неумелых новичков дженерики будут юзатся где-попало (но это уже не вина языка).

Как раз это вина языка. Сейчас любители переусложненного шаблонного кода и аспектно-ориентированного программирования сидят на C++. Как только в Go появятся дженерики, эти альтернативно одаренные люди начнут писать на Go всякие аналоги STL, boost и прочих нечитаемых и в большинстве своем бесполезных библиотек из мира C++. В итоге код на Go станет таким же трудноподдерживаемым, как и на C++ с шаблонами.

всякие аналоги STL, boost и прочих нечитаемых и в большинстве своем бесполезных библиотек из мира C++.

это есть такое лично я буквально на неделе случайно узнал что оказывается в std:: есть permutations это прямо очень нужный и важный алгоритм чтобы покласть его в _standard_ lib

Как раз это вина языка.

это хороший вопрос к.м.к. в этом месте возможно таки сильно «особенности национального си++» но да такая специфика на лицо и

любители переусложненного шаблонного кода и аспектно-ориентированного программирования

просто на лицо вот из совсем свежего было тут на доу «а давайте запилим 2-факторную диспетчеризацию обязательно на шаблонах» причём ответ «а зачем?» так и не получен ))

C 1972 року
C++ 1983 року

Go 2009 року
Сьогодні 7 лютого 2021 року

Go мало стільки ж часу як і С, для перетворення в Go++, та навіть більше часу, бо зараз технології розвиваються швидше.

Але є адаптація Go для Ruby: Goby (як і Erlang для Ruby в Elixir)

Боже збав! Не хочу про таке навіть й думати..))

Servo — браузерный движок от Mozilla, частично написанный на Rust — выкинули на помойку — см. www.linuxfoundation.org/...​sted-at-linux-foundation . Rust сдает и без того слабые позиции, в то время как Go уверенно движется к званию самого распространенного языка программирования.

Мозила передает проекты, которые она начала, в комьюнити, так как они уже получили достаточно инерции и не нуждаются в родительской опеке.

То же самое касается самого Rust

Мозила передает проекты, которые она начала, в комьюнити

Ну то есть, сливает другими словами.

Rust чувствует себя прекрасно. На подходе уже const generics

Mozilla вже показала що може робити хороші проекти, JavaScript-ом й зараз активно користуються (розробник Netscape Communications Corporation, Mozilla Foundation), і Rust стане популярним коли звикнуть

Mozilla вже показала що може робити хороші проекти, JavaScript-ом й зараз активно користуються

js — это хороший проект? Что, серьёзно? Его еле из говна за уши вытянули последними стандартами.

Валялкин, где обещанное виски?

Можете отправить Новой Почтой, я зафиксирую результат на видео и выложу — и будем считать тему закрытой.

Пока его нет, главный местный адепт Go в вашем лице считается нищебродом, не способным удовлетворить копеечное обещание.

Скажите еще, что не пользовались docker’ом c kubernetes (которые написаны на Go) в 2018 году :) Так что виски от вас.

Скажите еще, что не пользовались docker’ом c kubernetes (которые написаны на Go) в 2018 году :) Так что виски от вас.

Что не пользовался, я уже год назад ответил. И повторюсь: у нас были другие средства (vagrant, virtualbox, lxc).

Это уже второй раз, когда вы публично отбрехиваетесь от собственного зафиксированного обещания. Этого достаточно, чтобы заявлять: Валялкин, вы лжец.
Такой же лжец, как и в ваших «великих достижениях» в Go и у самого этого языка.

Может потому докер и работает через жопу что написан на го?

работает через жопу

Я думал такое — от криворукости разрабов, а оказывается во всем виноват язык. :-)

в гугле написали го. в гугле написали докер. если контора которая создает язык не может что-то на нем адекватно делать то мне кажется их изобретение гавно

в гугле написали докер.

буду знати... ))

в гугле написали докер

„Docker Inc. was founded by Solomon Hykes and Sebastien Pahl during the Y Combinator Summer 2010 startup incubator group and launched in 2011.” © en.wikipedia.org/wiki/Docker_(software

простите, а можно узнать Вашу позицию, что Вы считаете более достойной альтернативой для решения задачи контенеризации и так далее ?
Которая работала бы не «через дупу»

в гугле написали го.

откуда такая информация ? разве не dotCloud написал docker ?
и разве сейчас компания docker, она же бывший dotCloud принадлежит гуголю ?
Гугль написал k8s, а вернее его фундамент, но там другая истония

По прошествии пяти лет, Go оказался востребованным и полезным языком, а Scala так и осталась уделом душных фриков.

Просто процент компетентных специалистов на рынке не изменился.
Если не ошибаюсь, ниша Go — трудонагрузить слабокомпетентных, которых статистически, внезапно, большинство.

За живе і до сліз

Найбільш оплачуваними спеціалістами є Scala та Go-розробники у Києві — їхня зарплата становить $4000.

DOU, літо 2020 року

Цілком можливо що Golang дійсно стане мовою для швидкої розробки і будуть прирівнювати до PHP чи JavaScript.

Але зараз на Golang переходять спеціалісти із-за цікавих проектів з високим rps, переходять компетентні, а слабокомпетентні ймовірніше рідше змінюють технології з якими працюють.

Под компетентными специалистами вы понимаете мазохистов, получающих удовольствие от матановского Scala-кода с нагромождением имплиситов, бесполезных абстракций и монад, в которых невозможно разобраться? Тогда возражений нет. Продолжу работать над production кодом на Go вместо того, чтобы тратить время на попытки разобраться в матановском Scala-коде, абсолютно негодном для production.

Удачи, и много денег, обязательно держите в курсе. Просто есть те кому нравится отрасль в которой они работают. Наверно, это задевает чуства тех кто «просто делает деньги»? Вас оскорбляет чья-то компетентность и любовь к отрасли настолько, что вы профанируете их усилия стать лучше в понимании что, как, и зачем они пишут? Да, здравый смысл называется математикой, и так уж принято что у математиков есть свой язык для понятного всем общения, который неплохо бы знать.

Какую отрасль представляет Scala? Отрасль монадирующих матанщиков-теоретиков с отрицательным коммерческим потенциалом?

Вообще не понимаю о чём вы. IT вам не отрасль? CS ненужон? Scala это вообще про весь большой и критичный к валидности тырпрайз. Это просто инструмент в руках инженера, которому нужно в удобные абстракции для адекватного проектирования и планирования рисков, а не колченогие «паттерны» для оправдания переписывания всего на каждый чих. Ну или тонны дублированого бойлерплейта как в Go.

Навалом кода на Scala в финансах компаниях в Лондоне

Странно, что эти компании до сих пор не обанкротились

В twitter и в linkedin уже 1000 раз пожалели, что связались со scala — см. en.m.wikipedia.org/...​mming_language)#Criticism . Вполне возможно, из-за этого они никак не могут выйти в прибыль в течение последних 10 лет.

Инженеры фанг за пределами задроченных литкодзадачь и системдизайну не так чтобы боги (в среднем).

плз, можешь детальнее прокомментировать этот коммент?
dou.ua/...​/?from=fpcomments#1989882

Под компетентными специалистами вы понимаете мазохистов, получающих удовольствие от матановского Scala-кода с нагромождением имплиситов, бесполезных абстракций и монад, в которых невозможно разобраться?

из сырых окопов Скалы виднее, чем со стороны ))

А что коментировать? Высокое ФП с монадами — совершенно иная парадигма, с кучей собственных концепций, понятий, и математических законов. Чтобы в этом всем хоть чутку разобраться одного туториала прочитать будет недостаточно. Чтобы пофиксить неработающий реальный код, скопипейстить решение со стек оверфлоу не получиться.
Для народу, который с трудом осиливает базовые понятия ООП, и совершенно плавает в паттернах, оод, архитектуре и солидах — скала с фп это бетонная стена.

бетонная стена

яхту примерно так и назвали — скалА.

youtu.be/wj-V-F9dfrE?t=23

а стОит ли оно реально того, чтобы из неё высекать энтепрайз?
кмк, энтепрайз технологичнее лепить. Ну и рынок, похоже, к этому пришел.

а стОит ли оно реально того, чтобы из неё высекать энтепрайз?

Я работал несколько лет на ынтерпрайзе где на полном серьезе юзали скалу с фп. Как по мне применение скалы широко на ынтрепрайзе — это куча проблем, описанных как в статье так и в теме. Поиск людей, расхождение в стиле кода и синтаксиса, проблемы с билд системой и версиями компилятора. Есть и нишевые моменты, например для ФПшников, ФП — религия, и они никогда на императивный код не согласяццо, даже если он быстрее, проще и короче :-) Итд итп, что для большого интерпрайзу будет проблемой.
В некоторых компонентах где есть смысл использовать спрак или акку, или где нужно писать парсеры, компиляторы, дсли — использование скалы имеет смысл.

твитер продолжает активно нанимать людей на скалу

А что им остается делать? Кто-то же должен заниматься поддержкой говно-Scala-кода.

Алчно скалясь, за большие деньги они переписывают кровавый энтепрайз на Джаву, отбиваясь от хантеров.

Ну вот, сначала контора связалась со скалой, и потратила на это деньги, теперь будет тратить деньги на то, чтоб избавиться от скалы. Тратить будет достаточно, чтоб кто-то отбивался от хантеров.

твитер продолжает активно нанимать людей на скалу

вероятно, у них специфика продукта (и доходы) позволяют юзать ФП

Доходы twitter явно свидетельствуют о правильном выборе Scala :) Operating income за три квартала 2020 года — минус 84 миллиона долларов. finance.yahoo.com/...​te/TWTR/financials?p=TWTR .

Да просто твиттер, сам по себе, нафиг никому уже не уперся. Имхо конечно, но твиттер мчится к закату.

Зараз шукають гофера в Києві на проект «конкурент Twitter», в LinkedIn активно гоферам розсилають пропозиції

Илон Маск уже уволил всех scala-программистов и заставил оставшихся программистов переписать все на Go. Так что твиттер ещё протянет с десяток лет.

Тем временем, Apache Spark (полностью) и Kafka (частично) написаны на скале :D

Использовал скалу пару лет, на Go пишу этот год, Go таки гораздо проще и легче. Но для нагрузочного тестирования Scala все годится, потому что Gatling. Хотя там, конечно, глубоко вникать не надо.

Новость мирового масштаба: самая быстрая база данных для временных рядов — VictoriaMetrics — написана на Go! Ждем появления конкурентов на Scala и Rust.

InffluxDB IOx на Rust работает в 6 раз медленне, чем VictoriaMetrics на Go — medium.com/...​toriametrics-e590f847935b

А ви швидко відреагували, вітаю з найшвидшою TSDB, плануєш додавати в статтю на вікіпедії Time series database?

Пытался добавить VictoriaMetrics в эту статью раз пять. Модераторы каждый раз удаляли мои правки со всякими объяснениями вроде «вы не привели ссылку на статью с вызывающей доверие информацией о VictoriaMetrics» :( Попробуйте добавить сами — может, у вас получится :) Если что, то вот тут можно найти статьи о VM.

Припущення що редактори мають відношення до InfluxDB або іншої БД, тому й маніпулюють

Така ситуація для Вікіпедії трапляється часто в політичних темах, в ІТ мабуть рідкість але буду вважати за прецедент

Буде ефективніше якщо створиш тему на DOU, щоб допомогли додати VictoriaMetrics до статті Time series database

Может потому что никто в мире о какой-то подделке не слышал кроме тебя?

Из моего опыта, БД становится адекватной минимум после хотя бы 3 лет юзания в настоящих продакшенах (правда этим продакшенам на это время не позавидуешь)

Согласен. Вот эти пользователи VictoriaMetrics не в счет — victoriametrics.github.io/CaseStudies.html . И вот эти тоже — github.com/...​ictoriaMetrics/stargazers

А через рік-два можна буде написати нове порівняння

Желательно, чтобы бенчмарк делал не сам автор)

Так в чем проблема? Проведите свой бенчмарк и опубликуйте результаты!

будет более подходящий юзкейс — сделаю

Как то Intel делали сравнение OpenMP и OpenCL на их процессорах, взяли в интернет бенчмарк, получается OpenCL уделывает OpenMP в четыре раза запускалось на процессоре, а не на видеокарте или акселераторе. Начали разбираться почему? Выяснили что OpenCL код банально реализует более оптимальный алгоритм и что этот бенчмарк сравнивает не технологии — а программистов. Переделали OpenMP код под этот же алгоритм, получилось одинаково.

Не слышал о VictoriaMetrics, взял на заметку

Теперь ждем новости, что ее переписывают на Rust))
/* пошел за попкорном */

Коментар порушує правила спільноти і видалений модераторами.

Я тут посмотрел твой github.com/VictoriaMetrics/fastcache, и вот интересен вопрос. Если надо кэшировать контент файлов вместе с их MIME-типом, и что-нибудь ещё, как ты это делаешь? И ещё по какому принципу удаляются записи из кэша — самые старые, или самые редко используемые, или как-то ещё?

Если надо кэшировать контент файлов вместе с их MIME-типом, и что-нибудь ещё, как ты это делаешь?

Пишу функции Marshal и Unmarshal для составных типов и записываю в кэш сериализованный байт слайс.

по какому принципу удаляются записи из кэша — самые старые, или самые редко используемые, или как-то ещё?

Данные хранятся в циклическом буфере. Поэтому новые данные затирают самые старые, как только объем кэша достигает указанного лимита.

Пишу функции Marshal и Unmarshal

В принципе это логично, только в этом случае реаллоцируется лишний слайс размером как минимум с файл + данные.

Данные хранятся в циклическом буфере.

Ну понятно, просто бывают такие кейсы, что частота использования разных записей сильно отличается.

в этом случае реаллоцируется лишний слайс размером как минимум с файл + данные

Слайс можно переиспользовать при следующей сигнатуре функции:

// Marshal appends marshaled data to dst and returns the resulting byte slice.
func Marshal(dst []byte) []byte
просто бывают такие кейсы, что частота использования разных записей сильно отличается

Ага. Все случаи не покроешь оптимально. Приходится оптмизировать пакет под конкретные случаи использования — в данном случае fastcache оптимизирован под использование в VictoriaMetrics. Там важны следующие требования:

  • максимальная многопоточная производительность
  • минимальная нагрузка на GC при миллионах элементах в кэше
  • ограничение памяти, потребляемой кэшем

Вернёмся опять-таки к кэшу :)

Вот у тебя общая идея основана на bigcache, а там в апи есть Append, которая решает вышеуказанную задачу эффективным путём. Кроме того, там есть итератор, чтоб просмотреть содержимое кэша, хотябы по ключам, а у тебя его почему-то нет. Зато есть запись каша в файл, сугубо частная задача.

Насчёт dst []byte. В случае если читать серию записей подряд в одной горутине, то такой подход вполне оправдан. Но если записи читаются из кэша по одной, тогда держать такие буфера — это неэффективное расходование памяти, которое может привести к свапу страниц в файл подкачки.

Если в fastcache чего-то нет, значит, оно не понадобилось в VictoriaMetrics. Зачем добавлять функциональность, которую ты не используешь? Ведь потом ее не выпилишь (т.к. пользователи будут недовольны) и придется заниматься ее поддержкой.

Насчет dst []byte — забыл дописать еще одно требование для кэша внутри вм — размер сохраняемых в него значений ограничен 64кб. С течением времени в некоторых местах потребовалось хранить более длинные значения, поэтому была добавлена надстройка (костыль) для этого.

Но если записи читаются из кэша по одной, тогда держать такие буфера — это неэффективное расходование памяти

Для решения этой проблемы есть sync.Pool .

У вас выходит RCU алгоритм, что хорошо например для смканировпния всего сайта. Лучше заменить на LRU/SLRU.

Так люди сейчас просто CDN подключают и там все сразу, даже голову морочить не нужно. Но в целом SLRU обычно применяют для таких кешей. В целом там какая-то билеберда, софт построен вокруг паразитного влияния сборки мусора, в Rust ее вообще нет, там хитро компилятор и сборщик следит за временем жизни объектов. Но у многих алгоритмов сборки мусора другое большое преимущество — дефрагментация памяти.

Цікава таблиця
«Do you plan to adopt or migrate to other languages in the next 12 months?»
Scala — аутсайдер...
Ось так вимірюється справжній рейтинг вподобань;))

удивляет котлин — в чем существенное преемущество над последними жабами чтобы на него переходить ?

Крім переходу, ще мається на увазі й опановування нових... додаткого до основного стеку...

котлин как раз не удивляет
удивляет, что кто-то еще предпочитает java

Тим, хто дуже чекав... покращення)))

The Next Step for Generics
blog.golang.org/generics-next-step

Сейчас гоубои набигут и будут рассказывать о том, что генерики в Го это лучшее, что могло быть сделано за всю историю информационных технологий

Ті, хто так висловлюватиметься — не є православним)) гофером...;))

генерики в Го это лучшее, что могло быть сделано за всю историю информационных технологий

Человечества. За всю историю человечества.

кстати в java в свое время хейтили введение стрим апи, мол это следование моде и хайповым тенденциям.

В джава ввели Stream API? Збс, надо заценить!

Продолжение той же ветки:
— I’ve never had such feedback. All devs who discover this fall crazy in love with it and don’t stop (over)using it
— Yes, that’s what it looks like AFTER we make a big change. Before, when we’re talking about making a big change, we get an army of angry villagers with pitchforks and torches, with dire predictions of „you’re going to destroy Java.” It was very much this way with lambdas.

Просто любые более менее значительные изменение вызывают батхерт у людей т.к. меняют их реальность.

Оно работало очень сильно медленнее чем императивный код и кушало память к тому-же. Потом оптимизировали в 1.8. До версии 1.5 в Java тоже Generic Type-ов не было и весь код рябел ворнингами и так было по моим ощущениям примерно до явы 1.7. Ещё с Guava вынужден признать что функциональный подход в CRUD подобных приложениях, обработке бизнес данных, работает сильно лучше императивного. В системных, десктопных и т.п. — напротив.

Оно работало очень сильно медленнее чем императивный код и кушало память к тому-же. Потом оптимизировали в 1.8.

Спасибо что освежил память. Оно в 1.8 только и появилось, до этого все гуаву и юзали о которой ты говоришь. Перечитай релизы, и посмотри на даты между ними что бы вспомнить как это долго было все.

Contracts — Draft Design: July 31, 2019 (...this version of the design draft is similar to the one presented on August 27, 2018...)
Type Parameters — Draft Design: June 16, 2020

«А там или ишак помрет, или падишах...» :)

Почитал новый драфт, этот уже гораздо лучше чем предыдущий. Читается всё легко и никаких непоняток не возникает. Там отказались от контрактов, и решили реализовать через интерфейсы, что более интуитивно понятно и пересекается с уже реализованными концепциями. Заодно вместе с генериками, расширяются возможности использования интерфейсов, где можно перечислять к каким типам они применимы. Помимо функций с параметрами типов, также будут возможны параметрические типы данных, и генерики-интерфейсы.
В драфт с новой обработкой ошибок судя по всему ничего нового не вносили, но это вполне объяснимо — там и так всё идеально.

Гоубои мометом перекрасились, теперь генерики это наше все :)

Да к сожалению, авторы реализовать новый функционал обещают только летом следующего года. То есть в совокупности 3 года будут тянуть резину. Но в этом есть даже определённые плюсы: новый функционал не принимается наспех, а проходит тщательное обдумывание, обсуждение, и видно что концепт становится всё лучше и лучше. Становится всё меньше аргументации для критики.

go.googlesource.com/...​2draft-type-parameters.md
Вот новая версия драфта, где концепт генериков на контрактах изменён на концепт генериков на интерфейсах. То есть, в целом этот концепт хорошо интегрируется и дополняет существующий концепт эмуляции генериков с работой на интерфейсах и утиной типизации.

это и отлично, не бездумное раздувание языка бессмысленными конструкциями, как в формошлепской ноде или пыхе, а тщательное планирование дальнейших действий)

Пока @Aliaksandr Valialkin молчит, сам подброшу: www.youtube.com/watch?v=Dq0WFigax_c ....

... whereas generics in Java are defined via erasure, in Go we use monomorphisation

думаю, він у прострації, бо у го з’явився страшний матан

Самый важный плюс Go это его читаемость и единый стиль. Когда открываешь любой проект на гитхабе написанный на голанге, его ОЧЕНЬ легко понять и вьехать что там происходит, и уже через денек можно контрибьютат. В то время как каждый проект на Scala, да и на Java, надо сидеть долго и упорно разибраться что там происходит и какой там код-стайл. Особенно в скалке, где на каждом маломальски большом проекте — свой субдиалект языка. Отсюда и продуктивность Go, программист концентрируется на задаче, а не думает как бы ему написать тот или иной кусок кода.

Если приводить аналогии, то Go можно сравнить с русским языком, который и в Африке русский, а Scala с китайским, где в каждой провинции свой, непонятный другим диалект.

Вопрос в сложности самого проекта. При достаточно сложном проекте увеличение уровня абстракции (тот самый «свой субдиалект языка») _упрощает_ концентрирование на задаче. В случае, если в языке нет механизмов для повышения уровня абстракции — то либо задача будет похоронена под мелкими деталями реализации, которые не относятся к самой предметной области. Либо эти абстракции будут таки введены, но будут выглядеть коряво (так как будут ограничены «простым» синтаксисом языка) и будут стоить каких-то затрат в рантайме (так как возможности метапрограммирования — никакие).

Ну... Это скорее зависит от сложности самого проекта. Попробуй быстро разобраться в коде Ethereum, Tendermint или Ethermint. Тут скорее вопрос в том, что обычно Go выбирают для решения более простых задач, поэтому и разбираться в них проще.

Ну на Java не скажите, обычно это или Spring Boot стандартный. Просто на Go lang пишут другого типа код. На Яве считай просто надо поднастроить фреймверк из готовых компонентов.

Якщо дивитись далі то Scala-розробники мають вищу винагороду ніж Golang-розробники

What Languages Are Associated with the Highest Salaries Worldwide?:

  • Scala $150k
  • Golang $140k

Вибирай що більше подобається:

Тоже что и Assembler вернее гораздо хуже. Nothing works and nobody knows why.

Это потому что нет желающих ломать мозг в типичном матановском коде, написанном на Scala. Поэтому приходится предлагать более высокую зарплату, чтобы хоть кто-то взялся за эту работу.

На 7% больше? Это может быть в рамках погрешости опроса.

Там є цікавіші порівняння:

  • Perl $130k
  • Bash/Shell/PowerShell $120k
  • C# $110k
  • HTML/CSS $110k
  • PHP $100k

Вброс не засчитан, поскольку то статья для девочек (hr если код пишут и строят инфраструктуру):

If programmer does nothing to exploit multi-coring in her program, both golang and Node.js are single-threaded. However, if programmer does want to go multicore, she has to use goroutines (in Golang) , or cluster module (in Node).
both golang and Node.js are single-threaded

полнейшая чушь, нода юзает вспомогательные потоки для выполнения асинхронщины

nodejs.org/...​ont-block-the-event-loop

Node.js uses a small number of threads to handle many clients

Про Го то отдельная история с горутинами, смысла нет это расписывать, в оф доках все расжевано как там треды и горутины работают и тюнить это

Scala мне просто всегда не нравилась и по прежнему не нравится, очень сложный язык без каких либо существенных преимуществ перед Java, на той же платформе. А Go 10 лет назад и сегодня это разные языки, современный вполне себе не плох. Недостаток — Go в некотором смысле уж слишком прост, разработчики переусердствовали с упрощением.

А Go 10 лет назад и сегодня это разные языки

Существенная разница только лишь в том, что ввели generics версии 1.18, и модульную систему в 1.11, причём обтесали её к 1.17. В остальном кардинальных отличий нет.

Лучше бы не добавляли дженерики. Только время зря потратили, усложнив компилятор и снизив скорость компиляции. Никто в здравом уме не пользуется дженериками в Go, т к они только усложняют код, не решая никаких практических проблем. Так что 10 лет назад Go был таким же, как и сейчас.

опять эти сектанты, свидетели языка без языка

Ви про яких саме сектантів? І тяжко зрозуміти про що ви

язык без языка

В то время, как размеры скомпилированных программ на java продолжают расти семимильными шагами (java-программисты считают нормальным иметь jar-ники в сотни мегабайт), скомпилированные программы на go в версии 1.15 будут занимать до 30% меньше места — mobile.twitter.com/...​tatus/1256348714198654976 . Это еще сильнее увеличит и без того огромный разрыв (10 и более раз) между scala (java, cotlin) и go в размерах бинарников, docker-контейнеров и объеме памяти, используемой работающими программами.

есть достаточно много серьезных проектов в проде на Го делающих не только «фыр-фыр-фыр» в консоль и с потраченными тысячами часов и толстая джава там не нужна совсем со всем тем, что вы написали. Есть ниши, где от сервисов требуется скорость и простота, а не раздувание сотнями пакетов с мертвым линкующимся кодом

В итоге получая конечный native binary или докер-образ в мегабайты, не потеряв преимуществ JVM

Это как-то не православно, docker написан на Go, вам нужно замутить какое-то альтернативное решение не потеряв преимуществ JVM.

В go все работает искаропки, а в scala (java, cotlin) нужны танцы с бубном вроде тех, что вы перечислили в своем сообщении, чтобы хоть как-то работала программа.

Но вы продолжайте приходить и сравнивать golang binary, делающий в консоль фыр-фыр-фыр с JVM-based-приложением энтерпрайз-уровня, с сотнями библиотек внутри и тысячами человеко-часов разработки

Никогда не понимал, зачем тянуть стомегабайтные зависимости, если проще написать самому или скопипастить 100 строчек необходимого кода? Остальные миллионы строк кода из зависимости ведь все равно не используются.

Наверное, потому, что «стомегабайтные зависимости» — это нечто более сложное, чем условные 100 строчек кода?

Есть, конечно, деятели, которые из-за одного класса притащат в проект целый огромный фреймворк, но это проблема недостатка культуры разработки конкретного программиста, а не технологического стека.

Наверное, потому, что «стомегабайтные зависимости» — это нечто более сложное, чем условные 100 строчек кода?

Да, зависимости обычно более сложные, но обычно проще написать 100 строчек кода, чем тянуть зависимость. К сожалению, программисты предпочитают тянуть 100-мб зависимость :(

Да, зависимости обычно более сложные, но обычно проще написать 100 строчек кода, чем тянуть зависимость.

когда вы работаете в одиночку.

а когда уже 3+ — то 3 реализации одного и того же, но которые получатся разными — нужно будет саппортить тем кто не в курсе что их там 3.

К сожалению, программисты предпочитают тянуть 100-мб зависимость :(

правда между крайностями — писать свои лисапеды и тянуть либы из которых нужна сейчас и потом только одна функция.

тебе 100 строчек в других ЯП религия не позволяет копипастить? или это исключительно уникальная фича го-шников?

тебе 100 строчек в других ЯП религия не позволяет копипастить? или это исключительно уникальная фича го-шников?

Go в отличии от других ЯП в силу концептуальных особенностей предрасполагает к постоянному копипасту. Поэтому только в Go программист вместо того чтобы тянуть 100-мб зависимости, сразу же, буквально автоматически что-нибудь скопипастит, и даже не заметит этого. Бессмысленно спорить об очевидных преимуществах Go над другими архаичными языками.

ты только мокнул го в го и написал

Бессмысленно спорить об очевидных преимуществах Go над другими архаичными языками.

одним постом. хз о чем тут спорить...

ты только мокнул го в го

Как уже неоднократно говорилось, Go — язык самодостаточный, и вполне естественно, что даже мокать Go можно в Go. Во многих других языках такой фичи нет, так что как видим, преимущества Go раскрываются с каждым шагом со всё новых сторон.

Мало кто знает, что Go настолько самодостаточен, что компилятор и рантайм Go написаны на Go — см. github.com/golang/go . Это вам не scala с java, написанные на Си.

Не було нічого, і був лише Го. І зробив Го компілятор Го і рантайм Го. І побачив Го що це добре.

В go все работает искаропки, а

что там уже reduce/filter можно сделать даже из коробки без рефлексии и бойлерплейта?

Ни разу не видел кода на Go, который бы сильно выиграл в читабельности или поддерживаемости, если бы в Go была поддержка reduce/filter.

для „hello world” можно и без reduce/filter, да

Первые 3 страницы, там почти ни одного потенциального продукта который мог бы быть написан на java или scala, мб кроме баз данных. какие-то прокси и системные утилиты которые писались бы на С. Не понимаю к чему сравнение с scala или java.

Что и показывает ту нишу, где применение Go вполне оправдано. Но некоторые фанаты Go не унимаются и при каждом удобном случае пытаются пиарить Go как one language to rule them all.

Я, если что, недавно сам маленький http сервер делал на go, потому что функционал там примитивный, а скорость и потребление памяти важны. Так что, меня сложно отнести к хейтерам языка — скорее, я сторонник подхода «каждой задаче — свой инструмент»

потому что Go — это «bash» для написания микросервисов. ну может быть иногда и макро- :)

Я так понимаю потому Пайк и сотоварищи сопротивляются введению дженериков.
Зачем в bash’е дженерики? Ах понадобились — так значит вам нужен другой инструмент. либо вы не умеете проектировать системы как — микросервисные системы.

Первые 3 страницы, там почти ни одного потенциального продукта который мог бы быть написан на java или scala

Это еще раз наглядно показывает ущербность scala и java по сравнению с великим Go!

Так нечего сравнивать. Видимо твое го несравнимое.

Більшість гоферів дивляться та порівнюють з Rust, ще пару років тому вже був такий тренд Kyiv Go Meetup January 2018

действитель, это же какая читабельность какой-то сраный contains для массивов/слайсов писать на каждый тип и т.п.

Вот хорошая цитата про ООП в java и scala:

You wanted a banana but what you got was a gorilla holding the banana and the entire jungle

Давай, расскажи нам, как эту проблему решает «расово верное» ООП в golang?

Go предоставляет следующие инструменты для решения этой проблемы:
— Применение композиции вместо наследования. Она позволяет импортировать только ту функциональность, которая действительно нужна пользователю.
— Использованием интерфейсов с небольшим количеством методов.
— Предпочтением небольшой копипасты вместо импорта здоровенной зависимости.

Ctrl+C-Ctrl+V oriented development.

Не согласен, development удобнее вести методом Ctrl+Intert-Shift+Insert.

Кроме Go не нужно ничего знать. Там даже в версии 1.14 добавили принудительное переключение между горутинами — см. medium.com/...​s-preemption-b5194227371c . Это уменьшает максимальные задержки в garbage collector’е до 10мс, что в 20 раз лучше, чем в Java.

P.s. Средние задержки в гошном gc и так были в районе десятка микросекунд еще с древних времен, что в 1000 раз лучше, чем в java.

Кроме Go не нужно ничего знать

Амінь.

Я раніше розробляв на PHP, зараз на Go, підтверджую розробляти на Go швидше, а в скільки разів це вже індивідуально

Там даже в версии 1.14 добавили принудительное переключение между горутинами

Ага, при этом внеся так незаметненько огромный breaking change:

A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases. This means that programs that use packages like syscall or golang.org/x/sys/unix will see more slow system calls fail with EINTR errors. Those programs will have to handle those errors in some way, most likely looping to try the system call again.

EINTR — это ожидаемое возвращаемое значение для многих системных вызовов. Если программа раньше не обрабатывала EINTR, то это баг в программе, который нужно исправить. Go 1.15 выявляет этот баг, что позволяет улучшить общее качество программ в долгосрочной перспективе.

Это не баг, если с более старой версией рантайма отсутствие обработки этой ошибки не мешало программе нормально работать. Неаккуратное программирование — возможно, но не баг.

Зато подобные фортели очень наглядно показывают отношение авторов golang к обратной совместимости. Нормальные люди сделали бы эту возможность опциональной, сознательно включаемой каким-нибудь флагом при компиляции. И вот тогда уже было бы логично ожидать от разработчика, сознательно включившего этот флаг, правильной обработки EINTR везде, где только можно.

хабра давным-давно уже не аргумент, там куча коммерческого вброса и статьей в стиле «привет хаброжители сильнонепинайте за первую статью как я не смог пересесть с венды на линукс», читаю его уже наискосок, то что там пишут в большинстве случаев лучше выбросить и забыть

«привет хаброжители сильнонепинайте за первую статью как я не смог пересесть с венды на линукс»

А что, есть какая-то потребность пересаживаться с венды на линукс? Зачем?

имелось ввиду бессмысленность и низкое качество контента постов на хабре, ссылка на который здесь приводится здесь как весомый аргумент

тоже смотрел когда-то.
пару книг полистал, потусовался среди пересевших

оценил как сложный, а значит не мейнстримовый.

Scala это как
ru.wikipedia.org/wiki/Ифкуиль
см Пример грамматической конструкции

ну или «С++» для JVM

потом уже были истории с поломками совместимости

потом услышал где-то пару раз, что компании выбирают ее как способ отсева соискателей

Основной аргумент: количество проектов на GitHub с более 1000 звездочек:

Вывод очевиден — Scala мертва, учите Go.

Go — 1407 звезд

за 5 лет так и не обошел java и даже близко не приблизился к js

JavaScript — 5,084 repository results
Java — 2,371 repository results

кто-то тут даже коньяк на это ставил — походу темпы роста го такие же медленные, как и язык. so sad

за 5 лет так и не обошел java и даже близко не приблизился к js

Так java за 5 лет не только что не приблизилась к js, но даже наоборот только отдаляется, с сокращением объёма разработки на джаве. Если аппроксимировать эту тенденцию, Go в дальнейшем обгонит java даже без развития языка и комьюнити.

Если аппроксимировать эту тенденцию, Go в дальнейшем обгонит java даже без развития языка и комьюнити.

Чего ж ещё не обогнал?

Зато за последние 5 лет Go обогнал следующие языки программирования по количеству популярных проектов на GitHub: C++, PHP, C, ObjectiveC, Ruby, TypeScript.

Go уже обогнал Java по количеству активных популярных проектов в текущем месяце: 336 проектов на Go против 332 проекта на Java.

Зато по TIOBE C++ обошел Java в этом году.

-В джаве есть уже лямбды, оптионал, добавили вары итд. Ейвсе еще очень далеко до всех фишек скалы, но некоторые базовые вещи можна пилить.
-В джаве, как по мне уже устоявшийся костяк набора либ, фреимворков, и альтернатив фреимворков, более мение подруженных между собою. В скале какойто полный зоопарк всего и вся, плохосовместимого, и с кучей депенденси на непонятно что.
-разные версии компилятора, плохо совместимого между собой, что в купе с предедущим пунктом доставляет.
-sbt — no comments.
-в скале можна писать кучей разных стилей, используя разные подходы и наборы фичь языка. Еслиодин проект пишеться в разных стилях — черт потом ногу сломит. Для успеха требуеться оч жосские код конвеншены, суровый ревью итд, и даже оно — не помагает :-)
-не осиляторство. Народ тут не в состоянии разобраться с парочкой простых ооп паттернов, и кричит что ооп не нужно. Но на деле фп на порядок сложнее ооп. Куда проще кричать что Го крутой языг итд.

-не осиляторство. Народ тут не в состоянии разобраться с парочкой простых ооп паттернов, и кричит что ооп не нужно. Но на деле фп на порядок сложнее ооп. Куда проще кричать что Го крутой языг итд.

Вертайся в сім’ю, в той топік. Нафіг ті фабрики і візітори, одного сінглтона досить, якщо його не обзивати сінглтоном. Інкапсуляції више криши хватає для безпенішого програмування, нафіг там наслідувати єнота від собаки з мавпою.

нафіг там наслідувати єнота від собаки з мавпою.

Ну да, каждый Гошник каждый раз велосипед изобретает, и копи-пейст юзает, мывкурсе.

Вертайся в сім’ю, в той топік.

Тут речь о другом. Лет 10 назад неосиляторы распространяли миф о том какое сложное ооп, и как фп спасет отца. Но в прадакшене они ударились головой о стену из теории категорий, и ща кричат что фп оцтой, только Го.

Причём тут ФП vs ООП, Go сочетает все подходы, а не фокусируется только на каком-то одном. Поскольку при разработке языка учтён практический опыт программирования на других языках, это результат эволюционного развития. Тем более, что разработан язык не какими-то 23-летними синьорами, а людьми имеющими в этом опыт. В языке убрали всё лишнее, и собрали все сливки.

В языке убрали всё лишнее

ога, особо это забавляет когда приходиться писать копипастить очередной contains для массива слайса или другую подобную дичь, которая есть в любом нормально ЯП...

В нас в проекті є мікросервіс для збереження статистики, який отримує дані через gRPC, зберігає в slice-буфери та пачками по 10 000 зберігає в ClickHouse, написаний на Go і ось ці всі slice-буфери під кожну proto-структуру це copy-paste

Copy-paste для contains чи інших простих алгоритмів це прикро, але й рідко таке пишу, я б з радістю перейшов на Rust, але вже звик що на Go швидко проходять тести та build проекту

Відповідно є можливість розробляти малими ітераціями та швидким запуском тестів, і інколи робити copy-paste, що для мене переважає над довгим запуском тестів який в Rust чи C#

Причём тут ФП vs ООП, Go сочетает все подходы

В Go уже завезли каррирование без костылей? Дженерики туда тоже всё никак не завезут, кстати, а без них даже элементарные map / filter / reduce требуют извращений с кодогенерацией под каждый тип, на котором нужно реализовать эти операции.

Тут речь о другом. Лет 10 назад неосиляторы распространяли миф о том какое сложное ооп, и как фп спасет отца. Но в прадакшене они ударились головой о стену из теории категорий, и ща кричат что фп оцтой, только Го.

о дааа

моя улюблена історія, як Пол Грем наваяв Yahoo Stores на Lisp
а потім то треба було саппортити, коли їх вже не було, та й переписали то все нахрін на C++

бизнесу пофиг на осиляторов и неосиляторов, им нужен адекватный продукт за адекватные деньги.

Прошу помочь окончательно развеять мимолетное, так ни во что не вылившееся и уже ни к чему не обязывающее очарование, указав на 1-3 основных аргументов почему этот ЯП «уже не торт». :)

Потому, что есть Kotlin, создатели которого, насколько я знаю вдохновлялись скалой (и вроде одна из идей котлина была сделать что-то типа «Scala для простых смертных»), который не настолько сложен, как скала (может даже проще джавы), и который похоже таки взлетел, в отличие от скалы. :-)
Правда это не означает, что скала «уже не торт», просто скала узконишевый язык, насколько я понимаю.

Тут в соседнем топике камрады накинули

blog.usejournal.com/...​reads-part-2-52611217340a

Go: 732.204 total requests over 5 min, 2,439.9 r/s
Node (cluster module): 1,116,477 total requests over 5 min, 3,720.65 r/s
Node (worker threads): 1,105,513 total requests over 5 min, 3,683.90 r/s

Я считаю, топик можно закрывать.

ключевая фраза всей статьи там в самом конце:

I’d like to point out that I am not a professional benchmarker

Та ну... То треба бути «професійним» задротом, щоб комусь щось доводити... ))))

Т.е. чтоб показать, что Го не сосет у ноды нещадно, вам надо какой-то специальный эксперт по бенчмаркам? :)

Суть сравнения сводится к скорости интерпретации V8 против исполнения откомпиленного Go-кода. Что ещё там сравнивать?

После того как откомпиленный Go слился интерпретатору JavaScript, я не знаю что еще можно сравнивать :)

в инете много тестов
результат этого — нетипичный для Go vs Node.js

но что правда, у V8 очень крутой JIT, как для языка с динамической типизацией

Все просто, Node.js зміг розпізнати патерни і оптимізувати код і алгоритми, а Go як побачив так і виконав, і є відмінності в коді

Забавно, но компиляторы с функцией оптимизации придумали еще в 70-х годах. Странно что экосистема Го пока еще не получила их, но, надеюсь, скоро будет.

Go хейтер не смог даже нормальных тестов написать. Допустил ошибку в bubble sort и не выделил память под возвращаемые массивы. В итоге бенчмарк показал, что js умеет немного быстрее ресайзить массивы по сравнению с Go. Также стоит обратить внимание на экпоненциально возрастающую сложность кода в nodejs с увеличением его размеров. И это мы еще не добрались до ахилессовой пяты nodejs — callback hell’а при работе с БД и сетью.

В проде программы на Go работают в десять раз быстрее программ на nodejs, при этом их код остается простым и понятным при любом размере программы, а количество багов в нем в 100 раз меньше, чем в nodejs программах.

И это мы еще не добрались до ахилессовой пяты nodejs — callback hell’а при работе с БД и сетью.

Да, еще есть люди, которые не раздуплились как готовить async/await в ноде, но это прийдет со временем.

Боюсь, что процент людей, способных правильно использовать async/await, примерно равен проценту людей, способных правильно использовать callback’и и писать на Rust. Т.е. он стремится к нулю, в отличие от 100% людей, которые умеют правильно использовать горутины в Go.

journal.stuffwithstuff.com/...​t-color-is-your-function

Так же как и процент людей, способных программировать вообще, очень низкий. Остальные идут в работать продавцами.

посмотрел код, никак не оформлен толком и сам http server неправильно заюзан, чтоб реквесты конкуррентно обрабатывать, формошлепы с ноды не осилили нормально бенчмарк написать по концепциям Го

Бачу, є люд, яким абичим помірятися... вдавляться за 10мс )))

Так між ними багато спільного, видимість на рівні пакету, вбудовані тести та автоформатування коду, передача error та panic, відсутність OOP

Кто не читал, общая суть в том, что у чуваков внезапно возникла попаболь из-за работы GC в Go. К слову, та же попоболь у них возникла бы и в любом другом языке, где есть GC, и всё равно как ни крути, от сборки мусора не избавиться. И поэтому они кардинально решили проблему с GC путём перехода на Rust. Ну а то, что там нет встроенной многопоточности — ну и что, не возвращаться же обратно на Go.

К слову, та же попоболь у них возникла бы и в любом другом языке, где есть GC,

ребята уточнили, что аллоцировали минимально и размер heap у них почти не менялся в рантайме, а в go gc такой тупой, что каждый 2 минуты сканил весь хип и вешал апишку и это нельзя было никак поменять. В других языках Gc тригерит загрузка памяти, поэтому такой проблемы бы не было.

Я тут посмотрел один сервис, которые без особой нагрузки работает ровно 2 дня, совокупное время работы GC за всю сессию составляет около 37 миллисекунд — это всё что требуется для 1460 таких сканов.

Дай угадаю — ты посмотрел это для stateless сервиса vs statefull описанный в статье. :) статью наверняка тоже внимательно не читал.

Ребята еще уточнили, что успользовали древнюю версию Go, где GC был не так хорош, но забыли уточнить, чем им не подошла последняя версия Go с намного лучшим GC. В это же время им ничто не помешало использовать bleeding edge версию Rust в проде, которая даже еще не релизнулась.

но забыли уточнить, чем им не подошла последняя версия Go с намного лучшим GC.
We tried versions 1.8, 1.9, and 1.10 without any improvement. The initial port from Go to Rust was completed in May 2019.

И судя по release notes, после 1.8 значительных изменений в gc не было.

medium.com/...​6ecbd62a4b/responses/show
Якщо подивитись уважніше коментарі, то вони мова про go1.9 трьох річної давнини, баг з смітников виправили/

Если почитать внимательнее, то это события 2х летней давности, и к выходу 1.12 на rust уже почти переехали. Кроме того, учитывая

we were able to beat Go on every single performance metric.

возврашаться на go было бы весьма странно.

в ленте не могу коментить, поэтому оставлю здесь
imgur.com/a/03KQGOY

Вставлю свои 5 копеек по поводу годных языков программирования
Как по мне для сервера самый крутой выбор на сегодня «с запасом» — Kotlin, Python ну Node.JS для микросервисов
www.youtube.com/watch?v=ShX4KFvhiX0

2019 год подходит к концу, а Go стремительно летит вверх и догоняет Java по количеству звезд на гитхабе. Scala лежит на дне.

Валялкин, когда обещанное отдадите?

Или адепты «вяликого» Go на самом деле настолько нищие, что не могут одну бутылку купить?

Приходь на Go мітап, там таке питання задасте

Приходь
задасте

Щось тут не стикається.

Приходь на Go мітап

Побачу хоч одну цікаву доповідь в планах — подумаю.
Поки що шансів замало.

Самое удивительное, что у Dart почему-то получился большой рост, несмотря на то, что Google на него положила болт, и не встроила виртуальную машину в chrome. Ну а Go уже на 4-м месте, что вполне ожидаемый результат.

Достаточно вакансий, даже при том, что есть немало случаев, когда проекты вынуждены тащить чемодан без ручки в виде поддержки старых никому не нужных на сегодняшний день технологий.

Самое удивительное, что у Dart почему-то получился большой рост

тому що flutter

несмотря на то, что Google на него положила болт

Если бы гугл на него положила болт, то не было бы Dart 2 и Flutter’а, а виртуальная машина дарта в хроме ИМХО нафиг не нужна, ибо зачем, если дарт вполне компилиться в джаваскрипт.

а виртуальная машина дарта в хроме ИМХО нафиг не нужна, ибо зачем, если дарт вполне компилиться в джаваскрипт

Так смысл Дарта изначально был в виртуальной машине. А если его компилить в js, то лучше сразу просто писать на js. Или на ts.

А если его компилить в js, то лучше сразу просто писать на js.

Дейсвитейльно)) А то понаписывают разных языков, компилируемых в js — github.com/...​guages-that-compile-to-JS — вместо того, чтобы сразу писать на js)

Или на ts.

Так ts тоже лишний получается, ибо «лучше сразу писать на js». :-)

github.com/...​guages-that-compile-to-JS

Я в этом списке даже Go нашёл. Причём самый впечатляющий вариант — TARDISgo, компилящий golang в Haxe, а с него в js. Впрочем, с Haxe можно отомпилить ещё в C++ и php например, не только в js, а потом другими тулзами обратно в Go. И так по кругу.

Победа! Go обогнал Java в 2020 году — madnight.github.io/githut/#/stars/2020/4 . Впереди остались Python и Javascript. Про Scala уже все забыли.

Проекты на javascript лайкают любители тормозных и неудобных в использовании ангуляров с реактами, а также любители школьного поделия под названием nodejs и гигабайтных папок node_modules

js можно не сравнивать, поскольку он занимает монопольное положение на фронтэнде, из-за принятых в прошлом неоптимальных решений. Могли бы на фронтэнде принять стандарт на байткод, и писать фронтэнд на более толковых языках. Всё равно там занимаются такой фигнёй как минификация кода.

Я просканував свій жорсткий диск і бачу чітку перемогу С++. Java на другому місці, Go взагалі нема.

Акуратно підбираєш де сканувати — і маєш перемогу чого завгодно над чим завгодно.

Why Generics?
blog.golang.org/why-generics

ПС Дженерікам — бути... але це не точно..;))

My Reasons to Consider Go Coming from Java
preslav.me/...​ider-go-coming-from-java

P.S. Let’s get ready to rumble)))

Я знаю спеціалістів які перейшли з PHP на Go, з Python на Go, Java, Ruby, DevOps, але жодного хто перейшов з C#, такі взагалі є? (читав коментарі в цій темі по C#)

Так, моя поточна контора заснована сішарперами, які звалили на го. Тепер гошний код дуже сильно пахне сішарпом, кругом IWeirdInterfaceNamings, longVariableNames і тому подібне.

Исправить не пробовали нейминги в команде? Или код на го хороший даже если он с запахами?

Так налаштовано же. Там все по стандартам окрім кількох маленьких але досить баттертних відхилень :-)

Всі звикли, тому припікає переважно лише у мене. А кодобаза огого, щоб все міняти.

PHP на Go, з Python на Go, Java, Ruby, DevOps

вот это и есть примерно целевая аудитория

Пишу вам з майбутнього.
Все що завгодно краще за Зеленського.

2% идентифицируют себя как neurodiverse, это интересно как?

Grab переходит со spark’а на go — engineering.grab.com/...​ormation-product-insights . Выводы — spark никому не нужен, spark тормозит разработку, spark тормозит в продакшн, spark постоянно глючит, scala — мертва. Да здравствует Go!

After revamping the system, the elapsed time for a single event to travel from the gateway to our dashboard is about 1 minute. We also fixed the data loss issue. Finally, we significantly reduced our on-call workload by removing Spark Streaming.

Spark не нужен там , где его не используют

After completing the MVP phase development, we noticed the Spark Streaming functionality we actually used was relatively trivial.

Было бы там что-то сложней 2+2 ,а именно какой-то СЕP, boilerplate язык по типу го никто не рассматривал даже.

Лучше выяснить кому нужен язык, где надо ждать major релиза, что бы добавили функцию sort slice. Spark он собрался покорять.

Ти таким повідомленням вирішив підняти рейтинг Go? після малого падіння із-за теми Продам книги по GO

Це не тільки я вперше почув про компанію Grab?

Апну-ка я темку следующим:

Решил поискать я на гитхабе разные интересности в плане новых языков программирования (вот просто стало интересно, что новенького придумали в этом плане), и наткнулся на вот такой любопытный язык, по синтаксису и идеологии (как мне кажется) очень смахивающий на Go:

github.com/odin-lang/Odin — оффициальный репозиторий
odin.handmade.network — оффициальный сайт сего чуда, с туториалом odin.handmade.network/wiki/3329-odin_tutorial

Интересно, как оценят гоферы (и им сочувствующие), ну и анти-гоферы соответственно сие творение рук программерских)

Прочитал 2/3 тюториала, было стойкое впечатление, что это форк с Go, но потом выяснилось, что никакой не форк, поскольку нет многих ключевых вещей из Go. Прежде всего нет концепта параллельного программирования с горотинами, а вместе с этим отсутствует и смысл использования этого языка. Нет интерфейсов и утиной типизации. Нет вообще какого-либо концепта ООП. Нет GC, судя по всему память управляется только вручную. Тема замыканий и передачи контекста — проигнорирована. В целом синтаксис удобный, но проект явно сырой, чтобы на нём что-то реально делать.

Так а что страшного то в тех строчках которые приводят в той статье? Обычное же ФП без особой жути — монады и монад трансформеры, higher kinds. На самом деле в ФП гораздо больше злой дичи, чем там написано.

Всё дело в том, что есть набор людей типа:"Я знаю спринг и ООП с паттернами головного мозга, а всё остальное ересь«(те самые которые опшенел используют только для того чтобы проверить его на isEmpty, и на коллекциях вместо мапов используют циклы, траи кетчи во все поля) и начинают пилить декоракторы абстрактных фабрик бинов, а когда встречают ОФП или не дай бог ФП у них случается жуткий когнитивный диссонанс и резкое нежелание сесть и потратить некоторое количество вечеров на самообразование.

Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.

На самом деле, скала предоставляет множество плюшек для безопасности, структурирования и упрощения и повышение читаемости кода, но только если её не использовать как джаву с синтаксом скалы и не спамить всеми модными фичами(в особенности имплиситами).

Соблюдение базовых концепций (типа прочь вары и мьютабл коллекции, мапы/флатмапы/фолды вместо циклов, айзер/трай-монада для обработки ошибок вместо тысячи траев ифов и кетчей, возвращаемое значение функции вместо throw execpetion, скальные библиотеки вместо джавных(спринг, EE, и всё остальное), применение неявных(implicit parameters) только по назначению(реализация тайп-классов, пробрасывание «контекста» в функцию), жёсткая разбивка функции-преобразования над данными и собственно сами данные) делает код гораздо чище, проще, прозрачнее и короче чем джавный и традиционный ооп-шный способ писать код.

Просто скала, как и любая достаточно продвинутая технология(покопайтесь в голове чего есть в кишка спринга интересного и подводнокаменного, я думаю что его там тоже немало) требует понимания основных принципов её функционирования. Здесь есть ещё наложение того, что принципы немного отличаются от тех, которыми пользуются в Java и других ООПшных языках.

Вот и получается что люди пологают, что их привычные ООПшные принципы без никакой рихтовки годятся для применения к Скале и кричат: Ниасилил!

Вы тут перечислили кучу детских болезней, возникающих у начинающих разработчиков, особенно если они травят свой мозг программированием на scala. Ваша задача — достигнуть результата, за который платят деньги, а не заниматься реализацией всех имеющихся возможностей вне зависимости от их необходимости. Конечному потребителю нет никакого абсолютно дела до красоты в вашем понимании вашего кода. Так что бросьте заниматься ерундой, займитесь лучше программированием. На Go.

Бросьте тыкать в кнопочки и займитесь действительно нормальным нужным и полезным делом — приготовлением пиццы, например.

Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.

Ну вы знач умный. Я писал на карлючках продакшн код два года, это былого недостаточно чтобы понимать фп концепции и уметь читать код. Особенно не код вылизанного математического катс, а тот который в продакшене, и его какойто другой умник написал. Грамотный спринг значительно легче понимать.

ООП с паттернами головного мозга, а всё остальное ересь"(те самые которые опшенел используют только для того чтобы проверить его на isEmpty, и на коллекциях вместо мапов используют циклы, траи кетчи во все поля) и начинают пилить декоракторы абстрактных фабрик бинов, а когда встречают ОФП

Та булшит, нормальный народ вполне умеет в джаве стримами меп, фильтр и прочее делать. А народ который пилит декоракторы абстрактных фабрик бинов, он и на фп напилит таглесс-файнал апликативную клайсли композицию. Ток с декоракторами абстрактных фабрик бинов любой гошник за пол часа разбереться, а с таглесс-файнал апликативной клайсли композицией даже чсв Головача не хватит.

Ниасилил дочитать этот поток бреда. Теперь понятно, почему Scala пробила дно и продолжает копать вглубь в то время, как все давно пишут на Go.

Кажіть виключно за себе. Ваша маргінальна тусовка не «всі»

Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.
и мне потребовалось всего месяц
всего месяц

ліл

Це ж який елітизм треба мати, щоб тішитись високому порогу входу? Просто на теперішній роботі я не раз ставав свідком того, як народ з нуля за день-два починав писати адекватний Го. Звісно не зразу ж всі продвинуті фішки, але загалом без проблем.

Примітивізм мови не каже про її якість

Здорово, теперь меньше времени осталось ждать до выхода Go 2. Ещё только 1.13 обещали выпустить.

Та я вже, навіть, не знаю, чи дуже чекаю я на Go 2.0...))))
Мене там все влаштовує для моїх потреб...
Так що спостерігаю, шоб не «покращили» ..))

Не можу не погодитись...
„Go, the Programming Language of the Cloud”
thenewstack.io/...​ng-language-of-the-cloud

Не признаються...
Навіщо їм такий камінгаут?! ;))

отлично сказано: „I feel like an idiot when programming in Golang ”

Все не так, як Вам хочеться бачити..;))
Цікаво, що пан/пані з Quora не скаржиться на функціонал та можливості Go... а саме на свої відчуття..)
Це певно когнітивний дисонанс: думаю, він має можливість робити те ж саме, але з меншою кількістю померлих нервових клітин..;))

И ниодного ответа от тру-скалиста.

Какой инструмент — такие и задачи.

Не напружуйтесь так...
Це тільки для справжніх поціновувачів..))

ти кажеш

Читати всім уважно

а потім

Не напружуйтесь так...

нє надо так
www.netlore.ru/...​b2hbe1tk0h4717ujsc3u.jpeg

«не напружуйтесь» — це зовсім не образа... це, скоріше, турбота..)))

Мабуть дженеріки з ексепшинами підвезли.

свежеизобретенных велосипедов подвалило

К счастью, не подвезли. Будем надеяться, что никогда не подвезут. Иначе придется пересесть на какой-нибудь Crystal

придется пересесть на какой-нибудь Crystal

oy gevalt!
crystal-lang.org/...​d_semantics/generics.html

такі може колись до вас дійде, що дженеріки — це інструмент для спрощення життя програміста, а не культ карго «аби було»

Дженерики — зло, т.к. они усложняют понимание кода. И они реально карго культ. jmoiron.net/...​n-the-go2-generics-draft

Дженерики — зло, т.к. они усложняют понимание кода.

Це правда. Але правда і те що джереніки спрощують розуміння коду, роблять його коротшим і додають ще один механізм повторного використання. Але в го чомусь вирішили обмежитися копі-пейстом.

Дженерики — зло, т.к. они усложняют понимание кода.
Це правда.

Не правда. То не вы, не ваш оппонент, не видели языков, где генерализация вшита в компилятор по умолчанию.

Всі оці невидимі мови де щось там зроблено набагато краще ніж у мовах якими справді пишуть великі і складні речі мені не дуже цікаві просто.

не видели языков, где генерализация вшита в компилятор по умолчанию

наприклад?
дійсно цікаво

Мабуть дженеріки з ексепшинами підвезли.
К счастью, не подвезли. Будем надеяться, что никогда не подвезут. Иначе придется пересесть на какой-нибудь Crystal

.
(Щоб не загубити цей діалог. xD )

Помню пару лет назад пейсатели на джаве сильно переживали по поводу того, что Go будет демпинговать великих энтерпрайз-разаработчиков. А сейчас как видим, нищающие джависты только и могут, что демпинговать Go-девелоперов.

Что там та Java, вон обошли PaaS и rabbit mq программистов даже — это определенно вершина мира.

Оригінал тут — marketing.dice.com/...​_TechSalaryReport2019.pdf. Варто зауважити що там нічого нема про Go-програмістів. Натомість мова йде про skills серед яких golang популярний запит у роботодавців на Dice. Серед інших популярних Kafka, амазодновські БД і таке інше.

Поздно оправдываться — пора смириться и переучиваться с your_language_here на Go, а не то будет поздно.

переучиваться с your_language_here на Go

Для чого переучуватися якщо можна просто знати/вміти Go на додачу до інших скілів? Чи у гошників знання чогось за межами Го це щось нечуване?

Go опередил Elixir и Node.js — stressgrid.com/...​ing_go_vs_node_vs_elixir . Scala не участвовала, т.к. очевидно, что она бы заняла последнее место.

В 2019 году программисты больше всего хотят изучать Go — zdnet3.cbsistatic.com/...​019-01-29-at-11-25-51.png .

не в чем, а в ком — в программистах

Я б написав так: «В 2019 році й надалі...» ;))

А де про саме опитування — хто, коли, де, кого?

Ага, тобто 35 тис. користувачів HackerRank заповнили форму з якої і склали ці діаграмки.

Ура! В go1.13 добавят три супер-крутые фичи! Go станет еще совершеннее, а у хейтеров большне не останется аргументов против Go!

Тобто, ти визнаєш, що поточна реалізація далека від ідеалу?

Єдність і боротьба протилежностей — ідеальна мова без недоліків та проблем недоліки та проблеми якої будуть виправлені у наступній версії.

Це зовсім не те що Java чи С++ якісь де все і так не ідеально, а нові версії та стандарти потрібні щоб зробити все ще менш ідеально.

Это збс! Добавляют дженерики и исключения. Через несколько мажорных версий дотянет до C# 2.0 по функционалу.

Ти ж розумієш що цим себе тільки підставляєш? :)

Вышел короткий нескучный драфт по Go 2.0
www.youtube.com/watch?v=U84zvGbk_CY
ждём релиза в следующем году

Классная страничка про свитчеров с разных языков программирования на Go — github.com/golang/go/wiki/FromXToGo .

Отлично, двадцать человек перешли на Гоу (ты, я так понимаю, один из них). А вот сакцес стори тех, кто переходит с Го обратно нет — ибо возвращаются втихаря, чтоб оставшиеся гоубои не заклевали предателей.

Что значит переходят с Go обратно? Те, кто туда попадает, обратно уже не возвращаются.

Возвращаются, только не оповещают об этом весь интернет.

Все мы знаем, что дельфины спасают утопающих. Однако, выясняется, это не так. Дельфины просто играют с утопающими, подталкивая их. Те, кого дельфин толкал к берегу, утверждают, что он их спас. Те же, кого дельфин толкал от берега, уже ничего не скажут.
©

Все мы знаем, что дельфины спасают утопающих. Однако, выясняется, это не так. Дельфины просто играют с утопающими, подталкивая их.

На самом деле поскольку дельфины дышат воздухом, а детёныши часто захлёбываются, у них принято толкать утопающих к поверхности. Вот и Go даёт глоток свежего воздуха в океане говнокода на всеми уже забытом scala и прочих подобных языках.

Пошкодження необоротні і надій на зцілення нема?

Go уверенно движется вверх как танк. Уже на третьем месте и скоро обгонит Java. Scala пробила дно и продолжает копать вглубь.

По-перше, на четвертому. А, по-друге, це статистика по проектах на github.

По-перше, на четвертому.

Значит, скоро будет на третьем месте.

А, по-друге, це статистика по проектах на github.

Что еще кроме github можете порекомендовать для репрезентативной статистики?

Значит, скоро будет на третьем месте.

Або на п’ятому, або залишиться на четвертому, або не скоро.

Что ... можете порекомендовать для репрезентативной статистики?

www.tiobe.com/tiobe-index

tiobe — купленный индекс. Там vb.net на первых местах.

tiobe — купленный индекс.

Ким, для чого?

Мелкомягкими)) Бейсик продвигать — очевидно же. :D

Ага, як же я забув що воно так і працює — дивишся з ранку що там на перших місцях у купленому рейтингу і починаєш переписувати усе найпопулярнішою мовою. Завжди так роблю.

tiobe — купленный индекс

нагадаю — ще рік тому він був не такий вже і куплений :)
dou.ua/...​rums/topic/16012/#1145324

В этом году гугл выделил меньше денег на раскрутку Go, вот и не получилось купить первое место в tiobe индексе

Так а для чого ж там купляти місця? Може я щось роблю не так в своєму житті і мені теж треба там місце прикупити?

Ну гітхаб то специфічна метрика — там багато хоббістських проектів і дуже мало enterprise коду, який якраз і складає левову часту IRL розробки.

Але загалом прикольно!

Go перегнав Java — абалдєть.

Що сталось в 2018, що PHP так виріс? Тобто не інші просіли, а PHP саме виріс з 4% до 7% — майже в 2 рази. Але схоже, що народ швидко просік, що PHP таки гімно і за пару місців забили на нього :).

Вони там самі посилають на індекс TIOBE, який не обмежений гітхабом і як і очікувалося місця там дещо інші — tiobe.com/tiobe-index.

Гітхаб цікавий якраз тим, що там багато хоббістських проектів. Тобто прикольно, що народ, «для себе» обирає Го, а не Яву. Тобто враховуючи, що більшість працює на Яві і постійно на ній практикуються, вони всерівно приходять додому і беруть або Го або пітон або, прости Господи, js.

Я, наприклад, знаю (однаково поверхнево) і можу використовувати кілька мов програмування: C++, Го, Яву, Пітон, C#, JS/TS. Але якщо мені теба щось швидко склепати або почати з нуля, то я не думаю, що візьмусь за Яву або C#. Якийсь МЛ буде на пітоні в jupyter ноутбуці, говносайт для розмітки даних був на пітоні на фласку (там фронтенд навіть без JS — чистий html, а бекенд навіть без баз даних читає/пише тупо csv файли), якісь змагання я досі пишу на C++, більш довгостроковий сайт був на бекенді на Го, фронтом на React’і з TypeScript’ом...

А от Яву/C# прийшлось використовувати тільки коли по роботі треба було написати FIX клієнт: для цих двох мов є афігенні бібліотеки для роботи з FIX’ом (quickfix/j, quickfix/net, quickfix/go не пропонувати — жахливо, в порівнянні з попередніми двома).

(quickfix/j, quickfix/net, quickfix/go не пропонувати — жахливо, в порівнянні з попередніми двома).

Мав на увазі, що QuickFIX/J і QuickFIX/n ок. А от QuickFIX/Go — люте гівно.

На третьому. На гітхабі. За четвертий квартал 2020-го.

Це типу як я самий швидкий на 5 км. На моїй вулиці. За останній місяць.

любителей goвнокодить все больше и больше

Любители говнокодить преходят со Scala на другие эзотерические языки программирования типа Rust и C++.

Вы привели в пример рейтинг «звёздности». Что он отражает? Хайповость технологии?
Если посмотреть на количество доставленного кода
madnight.github.io/githut/#/pushes/2018/3 то не всё так радужно для Go

Вы привели в пример рейтинг «звёздности». Что он отражает? Хайповость технологии?

О хайпе на фоне успеха можно говорить только для созданной в последние месяцы, максимум пару лет какой-то теме. Go развивается уже десятый год, и при этом с каждым годом, как мы видим, его популярность бьёт все мыслимые и немыслимые рекорды. Поэтому здесь можно говорить не о хайпе, а об невероятном прорывном языке, о феномене не имеющем в мире никаких аналогов, имя которому только одно — Go.

Мало эпитетов, добавлю: квинтэссенция человеческой мысли, венец цифровой индустрии в котором собраны наилучшие практики со времён Ньютона, качественно новый уровень и веха грядущего миллениума, сниспосланная пресвятейшим (кто там его сделал), луч света в тёмном царстве IT ... и другие штампы.

Ничего не имею против go, но слишком «сладко».

Мало эпитетов, добавлю: квинтэссенция человеческой мысли, венец цифровой индустрии в котором собраны наилучшие практики со времён Ньютона, качественно новый уровень и веха грядущего миллениума, сниспосланная пресвятейшим (кто там его сделал), луч света в тёмном царстве IT ... и другие штампы.

Вот-вот-вот, сразу видно, вы уже постигли дзен. Прислушайтесь все к мнению гуру.

У go малое количество git push’ей, т.к. хороший код на нем получается с первого раза, в отличие от остальных языков программирования, опередивших Go в этом рейтинге.

т.к. хороший код на нем получается с первого раза

На будь-якій мові гарний код виходить з першого разу. Ви тільки його нікому не показуйте.

хороший код на нем получается с первого раза

Це доволі таки іронічно враховуючи що сам го добре ні з першого, ні з наступних разів так і не получився.

Це доволі таки іронічно враховуючи що сам го добре ні з першого, ні з наступних разів так і не получився.

Понимаете, есть вещи плохие, есть хорошие. А есть идеальные в своём совершенстве, и думаю излишне будет напоминать, что речь идёт тут о Go.

хотів уточнити: ми все ще говоримо про інструмент із назвою Go, який використовується для написання програм?

хотів уточнити: ми все ще говоримо про інструмент із назвою Go, який використовується для написання програм?

Конечно. Не об игре же Go, хотя она тоже может примазаться на фоне популярности к великой славе golang.

Мені якось goto більш досконалим здається ніж go.

Мені якось goto більш досконалим здається ніж go.

Go в два раза короче, чем goto, а краткость — сестра таланта.

краткость — сестра нашего брата ©

Всьо, переписую термінову все на го!

У go малое количество git push’ей, т.к.

никто не может довести код до состояния, когда его не стыдно пушнуть

что бы еще больше помогло го так это менее всратое комунити :) Язык то норм я на нем переодически пишу но блин

что бы еще больше помогло го так это менее всратое комунити :) Язык то норм я на нем переодически пишу но блин

Я конечно понимаю, что в силу природной скромности, вы не можете открыто и честно написать, что гордитесь комьюнити Go, поскольку и сами в него входите. Но не нужно перегибать палку в этом, мы ведь и так всё понимаем. Лучше честно и объективно написать всю правду, какой бы она ни была, что комьюнити Go самое продвинутое, самое достойное, куда входят лучшие представители хайтека.

А говорили, что никогда в жизни не перейдете со Scala на Go, что Go — никудышный язык программирования. Этот топик даже открыли, чтобы поглумиться над ниасилившими Scala. А теперь сами на Go пишете :) Epic fail!

я не говорил что не пересяду, я глумился над проблемами неосиляторов- это таки разные вещи :)
На го я пишу прототипы на выброс если чесно, продакшен код я не пишу ни на одном языке сейчас ( не знаю хвастаюсь или жалуюсь- что то посредине пожалуй).

Оба комунити имеют свои проблемы
— в скала — всратые элитисты которые пытаються прирутрить монадки куда не попадя ( не всегда к месту бгг).
— в го — всратые пионеры верящие что го лучший язык со времен каменного топора
примерно так

— в го — всратые пионеры верящие что го лучший язык со времен каменного топора

На самом деле Go появился задолго до изобретения каменного топора, и с тех пор неуклонно двигает человечество к вершинам научно-технического прогресса. Если внимательно присмотреться на наскальные рисунки первобытных людей, станет ясно, что это код прототипа Go.

а скіфські кам’яні баби — це, насправді, намагання наших предків увіковічнити Go Gopher-а!

одно плохо — скифских мужиков с огромными пиструнами не сохранилось, иначе всем было бы понятно как оно от го удлинняеться

а шо каже тьобе?

www.tiobe.com/tiobe-index
Jan 2019 Jan 2018 Change Programming Language Ratings Change
1 1 Java 16.904% +2.69%
2 2 C 13.337% +2.30%
3 4 change Python 8.294% +3.62%
4 3 change C++ 8.158% +2.55%
...
16 19 change Go 1.115% -0.45%

кстати Го обогнали почти во всех кейсов джава www.techempower.com/benchmarks
единственное исключение это plaintext — что как по мне даже не должно быть там ибо в жизни оно никому не надо.

Сильно просела на TIOBE. Нишевый язык в нише с высокой конкуренцией.

У нашей галеры позиций больше тоже нет. Back to springhebirnate.

Ну це просто у Вашій галері Scala «всьо». А в Spark-спільності й області сучасних рішень для Big Data планів міняти пріоритетну мову зі Scala на щось інше ніби нема. :-)

В больших конторах, которые были драйверами скалы, тоже от нее отказываются.
Linkedin который очень активно продвигал скалу несколько лет назад свернул все и весь новый код пишет на джаве.

Дата сайентисты с удовольствием используют pyspark

PySpark это примерно как Javascript после Java, замечу я вам.

Хм.

Современный джаваскрипт это глоток свежего воздуха после java8, это имелось в виду?

Я допустил двусмысленность, сорри. В оригинале имелось ввиду, что при всём удобстве для не-дата инженеров, PySpark после Scala Spark API выглядит ограниченным для самих дата инженеров

У Data Science все зрозуміло: research, вибір моделей, навчання, валідація не залишають часу, щоб ще вчити складну мову програмування.

Збираюся через місяць на Spark+AI Summit Europe 2018 у Лондон. Переглянув на днях відео деяких доповідей із Spark+AI Summit 2018, який був у Сан-Франциско — шматків коду на слайдах майже нема, але там, де вдалося знайти, є Scala. Наприклад, доповідач з Google.

Я думаю, що там, де треба швидко набирати багато Big Data програмістів і вже писати код, будуть старатися використовувати Java. Як і в компаніях, які просто не можуть дозволити собі найняти досвідчених розробників з фінансових причин. В інших випадках писати Big Data проект на Scala ніби має більше переваг, ніж на Java. Що не заперечує, що в деяких інших областях Java є кращим вибором.

але там, де вдалося знайти, є Scala. Наприклад, доповідач з Google.

И где там скала ? О том как ранить спарк на кубернейтсе (довольно полезная в своей области тема).

В інших випадках писати Big Data проект на Scala ніби має більше переваг, ніж на Java.

Рельное преимущество , это в среднем, челы которыйе знают скалу, или которые сами по себе желают выучить скалу — имеют уровень и мировозрение больше чем среднестатестический джава-индусы. Все остальное размываеться с каждой новой версией джавы.

Якщо подивитеся на відкриту web-сторінку, яка є у тому відео, то побачите ALS.scala і MovieLensALS.scala. ;-)

Так, за рахунок вищого порогу входу рівень середньостатистичного скаліста вищий, ніж середньостатистичного джавіста, і нові версії Java все більше переймають від Scala.

Позиции конешно есть, но както оно уже не так бодрячком, как было пару лет назад. С одной стороны питон в спину дышит, с другой — собственно джава. Да и сам спарки, не то чтобы безусловный лидер — конкуренции у него с головой хватает.

Spark’ом пользуются только две группы людей:

1) у кого мало данных и им пофиг, с помощью чего их обрабатывать
2) у кого мало мозгов, но много денег, чтобы тратить over $9000 на тормозное и жрущее память решение задачи на spark вместо того, чтобы решить эту задачу за $10 с помощью go + clickhouse

решить эту задачу за $10 с помощью go + clickhouse

Тепер я розумію Богдана в якого від вас підгорає! :)

Кто такой Богдан и почему у меня от него подгорает?

Вот выдержка из интересной статьи, сравнивающей производительность clickhouse vs spark:

Yandex ClickHouse is an absolute winner in this benchmark: it shows both better performance (>10x) and better compression than Apache Spark
Кто такой Богдан

автор джава-дайджестів

почему у меня от него подгорает?

не у вас від нього, а у нього—від вас.

clickhouse

Контраргумент від Фелікса:
felixit.blog/...​2/clickhouse-ne-segodnia

Феликс попытался использовать кликхаес не по назначению, после чего сделал верный вывод:

Что в итоге? ClickHouse для big data, где big начинается с миллиардов строк и сотен гигабайтов. С этой планки вас начинают интересовать уже другие запросы (и они в ClickHouse отлично работают)

Ахахаха.

Только упоротые гошники на полном серьезе могут сравнивать базу данных со спарком. Еще и большую статью написать.

Так статья не от гошников, а от Percona — спецов по базам данных

Не дивно, що SQL-запити до стовпцево-орієнтованого сховища ColumnStore напряму виконуються швидше, ніж SQL-запити до Parquet чи ORC через прокладку у вигляді Spark. Що і демонструється у статті. LOL.

Можна ще було для даних, які зберігаються у ClickHouse, порівняти час виконання SQL-запитів напряму і через clickhouse spark connector у Spark. Думаю, що напряму буде все ще швидше. :-D

По-перше, ClickHouse може працювати тільки зі структурованими даними, а в реальних задачах дані можуть бути різні; Spark RDD дозволяє працювати і з неструктурованими даними.

По-друге, дані у ClickHouse спочатку треба покласти; для Spark ж вже є багато конекторів.

По-третє, у випадку потокових даних, наскільки я розумію, у ClickHouse нема можливості задавати, що коли скидається на диск, а що ще зберігається в пам’яті, а якщо робити це вручну на Go, підозрюю, що реалізація більш-менш складної логіки буде дорогою і довгою; Spark Streaming розв’язує проблему.

По-четверте, незрозуміло, як вирішувати за допомогою Go + ClickHouse задачі, які вирішують Spark ML, GraphX.

До речі, навіть Yandex вирішує деякі зі своїх задач за допомогою Spark. А чомусь не зв’язки Go + Yandex ClickHouse. ;-)

Новый рейтинг языков TIOBE Index for September 2018

Как и предполагалось, Java/C/Python впереди планеты всей и укрепляют позиции. Go предсказуемо лоснул тунца.

Не зрозуміло ніфіга, чому така шалена популярність стала в Сі? Та куди дівся Objective-C? На ньому проектів менше стали клепати?

Та куди дівся Objective-C?

Он (судя по TIOBE) за год поднялся с 18-го места на 10-е.

ObjectiveC -> Swift

А Swift наоборот — опустился 13-го места на 15-е.
Почему? — хз.

Не зрозуміло ніфіга, чому така шалена популярність стала в Сі?

Embedded & Automotive

Да — именно так. Сейчас ломанулись пихать Андроид, Тайзен и К° во все дыры, поэтому требуется писать много системного кода, который пишется исключительно на С.

VB.NET смотрю внезапно на строчку выше сишарпа. :)

TIOBE показує рейтинг пошуків. Що вони шукають, без найменшої уяви. Так можна накрутити рейтинг зробивши щось, про що ніхто ще не здогадується.
Нічого дивного що VB.NET пішов вверх. Як на ньому нормально писати в теперішніх реаліях я не здогадуюсь, скоріше пошуки зводяться до використання LINQ.

Теперь программы на php могут быть загружены в Go — github.com/z7zmey/php-parser

Если вы имеете ввиду создание транспиллера PHP -> Golang, то мне кажется это невыполнимая задача.
Для начала нужно определиться:
— что делать с нестрогой динамической типизацией PHP?
— что делать с наследованием методов? (в Go нет класического ООП и метод родительской структуры не будет вызывать переопеределенный метод из дочерней)

Ну и главный вопрос зачем?
Если стоит выбор на чем писть Go или PHP, Go выбирают там где нужна многопоточность или большая производительность чем PHP. Транспиллер не решит эти проблемы.

Есть тип interface{}, и через reflect можно добраться до его методов. Зачем?

Например, для увеличения скорости. Ну и для облегчения портирования старых проектов.

Да про interface{} я не подумал.
Касательно рефлексии — это не лучшее решение если важна скорость.
И прежде чем думать о реализации, стоит задаться парой вопросов:
— есть ли реальная необхдимость портировать код?
— можно ли решить это более легким способом?

К примеру можно использовать github.com/deuill/go-php.

PS: Я был не прав когда сказал что это невыполнимая задача, это мега сложная задача.

Прошла инфа что один из создателей golang начал разработку нового языка на базе scheme, обещает что перформанс на таких же задачах будет как минимум 3x по сравнению с go — за счет более продвинутой системы потоков и ускоренного сборщика мусора.

один из создателей golang начал разработку нового языка на базе scheme

если это таки правда, то будет интересно глянуть его, когда зарелизят. :)

перформанс на таких же задачах будет как минимум 3x по сравнению с go — за счет более продвинутой системы потоков и ускоренного сборщика мусора

Интересные планы. Это значит, что перфоманс вместе с планировщиком потоков и сборщиком мусора будет такой же, как у C++, поскольку перфоманс самого Go примерно так и отличается.

Это про github.com/google/wuffs ? Там нет потоков и сборщика мусора

Почему Go одержал сокрушительную победу над Scala? Потому что он против бесполезных абстракций и монадирующих программистов. тут подробности

Аутсайдер виграв у іншого аутсайдера? Яка «цікава» новина...

madnight.github.io/...​ut/#/pull_requests/2018/1
уже 4ое место на гитхабе, сразу после жавы — хорош аутсайдер

смотря какими пиписьками меряться. Если по PR — то 4ое, хотя pushи вроде как более честно. Хотя по пушам, там вообще shell рванул вверх, вот уж не ожидали :)

То есть dry, solid (даже не в контексте ООП) это приводит к понижению поддерживаемости, а их ликвидация к повышению?
Интересно это выпускник шага или гоит...

А никто не поделится ссылка разницы Scala vs Go. Лично никогда Scala не видел и даже не сидел рядом с программистом, который на ней писал.

Ну это как добираться в Одессу на современной октавии (Go).
Или на боинге (Scala). Только на боинге также надо самому пилотировать (по книжечке выучить боинг за 21 день), самому платить за керосин, итд итп. Пока выучишь как пилотировать боинг не разбившсь на посадке, и насобираешь денег на керосин — на октавии можно весь мир проехать несколько раз. Зато на боинге можно летать...

А может Go это самопилотруемый одноместный самолет :))

самопилотруемый одноместный самолет

Ага, охренеть какой самопилутруемый qph.ec.quoracdn.net/...​c72b058b85774ee804a521165

Да нормальный самолет — я же сказал, что маленький и быстрый. Ну вот нафига вам ташить Min/Max значение всех констант если можно сделать скажем так

const (
MaxUint = ^uint(0)
MinUint = 0
MaxInt = int(MaxUint >> 1)
MinInt = -MaxInt — 1
)

Или обьявить их: golang.org/ref/spec#Numeric_types

Все равно это никак не доказывает, что Go лучше Scala или наоборот. Я так посмотрел на Scala и мне показалось, что если вам хочется скажем дженериков или больше всякого синтаксического сахара, то есть тот же Rust. Вот что я могу сделать в Scala, что не могу в Go или скажем могу сделать значительно быстрее. Опять же, Scala это все-таки интепретируемый язык (хоть он и собирается в байт код), но все равно требует JVM для своего выполнения.

Scala это все-таки интепретируемый язык

А джава тогда что ? А найдите для начала 10 отличий между пхп и джава. Иначе чего вы вообще сюда пришли ?

вам хочется скажем дженериков или больше всякого синтаксического сахара, то есть тот же Rust.

А есть с++, зачем дебелы вообще какието новые языки пр идумуют, тот же Го, если есть с++ ??? И с дженериками и с поинтерами. Я вот тоже не понимаю. Дебилы.

Ну вот нафига вам ташить Min/Max значение всех констант если можно сделать скажем так

Да вообще непонятно зачем константы кудато тащить если компилятор под платформ все порешает, недальновидные дебыли, да и токо...

А джава тогда что ? А найдите для начала 10 отличий между пхп и джава. Иначе чего вы вообще сюда пришли ?

А VB.NET что ? А С# ? Все компилирует — там в байт-код, там MSIL и дальше уже процессится средой выполнения и компируется в машинный код. Я вас удивлю, но все в конечно счет переходит в машинный код :)) Как это все доказывает, что Go хуже или лучше Java ???

Мы уходит в дискуссию кто дурак. Предлагаю написать какие-то две программы на Go и Scala и сравнить.

Как это все доказывает, что Go хуже или лучше Java ???

Дак это вы утверждаете что жвм интерпретируеться.

Предлагаю написать какие-то две программы на Go и Scala и сравнить.

Во первых, Валиалкин уже все написал, читайте тему.

Во вторых, что вы сравнивать собрались ? Количество строк кода ? Количество открытых коннекшенов ?

Go разгромил Java, Kotlin (и, соответственно, Scala) на AWS Lambda — blog.travelex.io/...​o-and-lambda-d30d95290f28 . Сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках на AWS Lambda. Go, только вперед!!!!

Сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках на AWS Lambda

Звідки такі данні? У статті нічого про вартість розробки і підтримки наче нема.

Да, про стоимость разработки и поддержки там ни слова. Зато в статье приведены графики, сравнивающие стоимость работы идентичных сервисов, написанных на Go и на Kotlin. И там Go экономнее Kotlin’а в 10 раз. Что выгоднее — платить $10k в месяц за сервис на Kotlin’е или $1k в месяц за аналогичный сервис на Go?

$10К теж ніде не бачу за наведеним лінком.

Значит, и зарплаты в $10к никогда не видать :(

Так, на зменшення зп я навряд чи погоджуся.

На aws lambda в целом компилируемые в бинарку языки себя лучше покажут, изза холодного старта

В статье написано, что Go уделал Kotlin как при холодном старте, так и при прогретом сервисе.

Учитывая, что Го плавно скатывается в небытие, прошу посоветовать, за каким очередным хайповым языком будущее?

нічого у rust нема страждального
складненький — так...
але глупості писати не дає, слідкує і навіть поради роздає, як пофіксити
так що може люди і виростуть, буде хороша альтернатива c/c++

так що може люди і виростуть, буде хороша альтернатива c/c++

Не в этой жизни. Rust не соблюдает слишком много общепринятых двоичных стандартов, даже больше чем С++ ...

наприклад?
бо поки офіційну книжечку читаю — там такого нема

Если не изменяет память: «UNIX System V ABI» и компанию. В мире системного программирования где царит С, и куда уже какое десятиление ползет C++ это маст. Таже Ада его соблюдает и поэтому вполне альтернатива С во всех смыслах.

попробував нагуглити «rust unix system v abi», знайшов проблеми 2011 року — так, тоді могли бути проблеми, бо rust стабілізувався довго і нудно

тому все, що раніше 2016 року — зараз можна забути, поки не вийшла версія 1
а свіжі дані є? цікаво було б почитати і пощщупати

а свіжі дані є? цікаво було б почитати і пощщупати

По моей информации нет и не планируется. Раздел документации ffi, или как он там назывался, по факту это взаимно-исключающая альтернатива «UNIX System V ABI»

Кроме того, если мне не изменяет память, там была еще одна такая глобальная грабля, но тут меня подводит память

як написати однотредний сервер, або де мій select (2)
esr.ibiblio.org/?p=7294

Да всё в порядке, всё идёт своим чередом, выпущена версия 1.9.2, код разрабатывается легко, над ненужными 3-этажными конструкциями как в C++ париться не нужно, никаких особых подводных камней там нет. Так что слухи о скатывании в небытие несколько преувеличены.

Уже и 1.10 на подходе. А с чем связаны очередные похороны Go ?

А вы не смотрите на рейтинги — язык нужно любить не за рейтинг, а за то, насколько вам на нем удобно программировать или нет. Вот на stackoverflow Go третий по Most Loved, Dreaded, and Wanted Languages и что ?

если на это смотреть, то я вообще не понимаю как Го привлек хоть какоето внимания, хотя я знаю — Гугл, сделал бы это кто другой никто бы и не юзал

Я просто хочу показать, что рейтинги — это всего лишь рейтинги и не более того. Go отличный язык с довольно понятной конкурентной моделью работы. Я хочу еще посмотреть на Rust — может мое мнение изменится, потому что там уже есть generic, атрибуты и все остальное, но пока для своих задача Gо довольно не плохо. Ну и вы правы — Google конечно сильный аргумент :))

после PHP он отлично заходит, от сюда и популярность в спецефических кругах
язык норм просто вовсе не серебряная пуля

Непонтяно чем пыхтеров жабаскрипт неустраивает.

так на go только выебщики идут, обычне пхпшники на жабаскрипт поперелезли уже и не жужат

Уже писали 100 раз, что пыхеры — это не целевая аудитория для Go, они проходят мимо. Там концепт кардинально другой: строгая статическая типизация, многопоточность, ну и в целом код компилируемый, который крутится постоянно. Go в основном юзают те, кто раньше писал на C++ и Пайтоне.

Все самые активные го неадекваты что я знаю-
Пехапешники
Про концепции и реали sv я в курсе, но тут на доу своя атмосфера

Я не PHP-шник. Пишу на .NET, немного на Swift. Перешел на Go после того, как посмотрел в сторону Ruby и потому Elixir. Ничего не понравилось и правильно говорит @schwarzlichtbezirk — там для PHP-никого совсем другая концепция.

А як же явасценаристи які з незрозумілих мені причин хочуть вчити Go?

то не js девелоперы, а хипстеры

Откуда вы узнали, что я раньше был пхп-разработчиком? Следите за мной?

бгг нет, с х** бы
с тобой угадал чисто по уровню рассуждений о gc( очень похожих на одного другого чувака на которого я натыкался)
При том что против го я ничего не имею, но твои усилия откровенно не помагают построить не токсичное русскоязычное go lang комунити

:D чёт с го никак не разберусь с одной стороны вечно гошники трындят про простоту языка и доступность каждому, с другой про некую элитарность и открещиваются от разработчиков свитчеров с непопулярных технологий? Этот язык вообще для программирования используется или фетиша?

Вот как раз наоборот, пыхеры юзают самую популярную для бэкэнда технологию. И популярность php получила исключительно благодаря простоте, низкому порогу вхождения, не строгой практике программирования. Разработчики Go учли весь накопленный опыт в практике программирования, и успешно совместили казалось бы совершенно несовместимые вещи, которые раньше не могли быть реализованы все в одном флаконе: простоту, эффективность и качество. В разработку на Go может войти кто угодно, и в этом плюс, и с php объединяет простота разработки. В то же время Go вобрал лучшие практики серверного программирования, и в этом есть расхождение в концепте с php.

кто раньше не осилил C++ и Пайтон

пофиксил

писали писали такие и думают дай деградирую лет на 40 до 70тых

Go разработан как раз корифеями программирования, которые создали в своё время unix и C. И является естественным развитием лучших практик программирования, даже более того, Go во многом опережает своё время. Здесь очевидно сопоставление с эволюцией в животном мире: сначала животный мир развивался в сторону увеличения массы и размеров особей, появились динозавры, тиранозавры и прочие. Это продолжалось до тех пор, пока изменения внешних факторов окружающей среды не доказало неэффективность такой стратегии. После чего появились млекопитающие, которые на первый взгляд никак не сопоставимы по силе и размерам с динозаврами, но тем не менее стоят на более высокой ступени эволюции.

Что вы там с Валиалкиным курите ?

Мы не курим, а несём тут свет прозрения. Роберт Пайк после того как разработал C 40 лет назад, словно как Моисей водил человечество по пустыне, пока наконец не привёл в землю обетованную, в программирование на Go.

Роберт Пайк ... разработал C 40 лет назад

Неправда.

как Моисей водил человечество по пустыне

Крім UNIX він був співучасником чи автором таких проектів як:
— ОС Plan 9
— OC Inferno
— Мова програмування Limbo
— Мова програмування Sawzal — теж зроблена для гугла
— Графічний термінал Blit
— Текстовий редактор sam
— Текстовий редактор acme
— Співавтор UTF-8
— Співавтор двох книг з Керніганом

привёл в землю обетованную, в программирование на Go

Тільки мало хто це відчув та помітив?

Крім UNIX він був співучасником чи автором таких проектів як:
— ОС Plan 9
— OC Inferno
— Мова програмування Limbo
— Мова програмування Sawzal — теж зроблена для гугла
— Графічний термінал Blit
— Текстовий редактор sam
— Текстовий редактор acme
— Співавтор UTF-8
— Співавтор двох книг з Керніганом

Это только подчёркивает долгий и тернистый путь к Go, как к венцу его творения.

Тільки мало хто це відчув та помітив?

Картины великих мастеров тоже сначала были недооценёнными.

на жабаскрипт поперелезли уже и не жужат

Я так понял пару лет назад жужали, но сейчас это не модно уже :-)

Очевидно же, что будущее за недавно вышедшим go 1.10. В нем полно новых фич, которые никого не оставят равнодушным.

Лямбды — это полуфабрикат замыканий, которые в Go есть изначально по дизайну. В тех языках, где не могут сделать полноценные замыкания, делают лямбды с большим пафосом.

То есть ламбды не появились. Дженерики хоть запилили?

Дженерики не нужны. Для особо упоротых есть github.com/ncw/gotemplate . Только почему-то дальше парочки стандартных структур (list, ring, set, heap) и алгоритмов (sort) дело не пошло. Причем необходимость list и ring высосана из пальца:
— вместо list проще и эффективнее использовать стандартный слайс
— ring используется чуть меньше, чем в одном проекте на миллион, где проще написать один раз реализацию этого ring под конкретный тип в 10 строчек.

Set тоже легко заменяется стандартной map[key]struct{}, хотя синтаксический сахарок тут уже поприятнее.

Остается лишь дженерики для heap и sort, которые необходимы лишь в небольшом проценте оптимизированных по скорости программ, где стандартные heap и sort на интерфейсах не подходят из-за накладных расходов на вызов интерфейсных функций.

Приведите примеры из настоящих программ, где еще могут понадобиться эти дженерики?

Как по мне вот так пишут упоротые люди.

	people := []struct {
		Name string
		Age  int
	}{
		{"Gopher", 7},
		{"Alice", 55},
		{"Vera", 24},
		{"Bob", 75},
	}

	sort.Slice(people, func(i, j int) bool { return people[i].Age < people[j].Age })
}

Нормальные делают тоже самое вот так

people.Sort(p => p.Age)
Если бы у Go были генерики он бы тоже так мог.

Если очень надо, можно определить метод для слайса:

func (self *[]People) Sort() {
	sort.Slice(self, func(i, j int) bool { return self[i].Age < self[j].Age })
}
и дальше вызывать вообще без параметров: people.Sort(). С чего вдруг на каждый чих должен быть встроенный метод.
Лямбды — это полуфабрикат замыканий

Вообще-то ламбда это возможность определить «анонимную функцию» с «ссыланием на неё» не по имени а по «переменной ссылке указателю» что там поддерживается текущим языком само по себе «замыкание» это уже способность захватывать такой анонимной функцией текущий контекст так что «лямбды» никак не могут быть «полуфабрикатом замыканий» потому как вполне способны существовать и функционировать без него а замыкание просто способность как передавать переменные во внутреннюю функцию не в качестве параметров так и что более важно возможность продолжения их времени жизни временем исполнения уже внутренней функции которая обратно таки может прекрасно работать сама по себе и без этого.

Но вообще интересно нарисуй псевдокод как ты видишь замыкание без лямбды?

Кака разница, как это называется? Кому-то нравится название «лямбда», кому-то «замыкание», кому-то «анонимная функция», альтернативно одаренные называют это «лАмбда». Главное, что в Go это есть.

Кака разница, как это называется?

Видимо така разница что как это таки две разные сущности и принципа и функции не?

Главное, что в Go это есть.

Ну х.з. если честно я полагаю сабжевая речь об том что

Лямбды — это полуфабрикат замыканий

Суть замыкания в работе с контекстом вызова, который сохраняется при выходе за пределы определения локальных переменных, с которыми работает функция. Лямбда контекст не сохраняет. Например, в общем случае вариант типа этого не прокатит

std::function<int()> l;
{
	int a = 10;
	l = [&]() { return a; };
}
int b = l();

а если?

auto a  = std::make_shared<int>(10);

l = [=](){ return *a;}

В Go решение об управлении объектами GC принимает компилятор на стадии компиляции, а со стороны разработчика всё выглядит совершенно прозрачно. И таким образом, исключаются лишние возможности отстрелить себе ногу.

Это какие-то новые наркотики? На стенках видел только фен в телеге.

В нем полно новых фич
There are no significant changes to the language specification

вот и стагнация наметилась, Go больше не может ничего нового предложить хипстерам

А как же вот это?

the compilers have been updated to allow the index expression x[1.0 << s] where s is an untyped constant
The grammar for method expressions has been updated to relax the syntax to allow any type expression as a receiver

Также go 1.10 может:
— быстрее управляться с миллионом таймеров и/или одновременных подключений — github.com/golang/go/issues/15133
— быстрее конвертировать строки в числа — github.com/golang/go/issues/20557

быстрее конвертировать строки в числа

Серйозна заявка на перемогу... Сплю та бачу системи, які швидко конвертують строки в числа...

от якби вони конвертували їх в валюту

Валюту в строках зберігати? о_О
Оце взагалі перемога перемог!

топ 10 лучших языков программирования. :) Go как и Swift перспективные языки medium.com/...​earn-in-2018-2d6cbc5ffc2a

а де там Go?
там навіть його назва не згадується...

C на 2м месте, Го на 19м в январьском Tiobe

C успешно эмбедидся в коде на Go, так что низкоуровневое API можно успешно писать на C в рамках Go-проекта.

Вот именно этим и объясняется востребованность C. Врядли кто-нибудь на сегодняшний день начнёт писать с нуля полностью на чистом C какую-нибудь крупную систему. На сегодняшний день C, как и Asm, правильнее поставить в отдельную категорию.

Если на проэкте ликвидировать всех Agile-одаренных то мало какой язык сможет радикально дать фору С. 50% в лучшем случае.

Чистый С это уж слишком на любителя. Но «C с классами» (и шаблонами) ... :)

В Го все, включая С, эмбэдится очень хреново и именно это его убьет.

У Go нету будущего. Go это просто удачный студентческий эксперимент. Скорее всего в будущем разделит судьбу lua.

а що не так із долею Lua?
поцікався — вона доволі популярна серед розробників ігор, на ній пишеться доволі багато внутрішньої логіки

Узкая специализация и нишевость.

ну, це, м’яко кажучи, неправда

Узкая специализация и нишевость

Тем не менее, более широкая, чем у других скриптовых языков, используемых в геймдеве, или заточенных под конкретный игровой движок. Благодаря лёгкой встраиваемости, используется везде, где нужно выносить какую-то логику в скрипты.

Недавно наткнулся ziglang.org, вполне годная альтернатива lua когда зарелизят 1.0
Кстати, основной разраб какой-то геймдев.

відкрив приклади — савсем не пахож на lua

скорше схожий на rust, але rust вже версії 1.27 і набирає обертів

Скорее продвинутый C, всё-таки основная фишка rust это вывод типов и статическая гарантия отсутствия race condition через механизмы владения. Тут этого нет, при этом создаётся впечатление, что код 1:1 можно перевести на C, только выделены наиболее часто встречающиеся шаблоны.

Альтернатива не значит схожесть синтаксисом. Я не писал игр используя луа, не знаю как он встраивается, но подозреваю что он компилируется в байткод или просто скрипты хранятся в ресурсах. CFFI в Zig примерно такое же простое, как в Go, но для Go приходится писать враперы для C++ а-ля [code]#ifdef __cplusplus[/code]. Во-вторых, Zig транслируется в С. Ну и не похож он на Rust от слова вообще, не понимаю где ты там схожесть заметил. Скорее C++ или D.

у будь-якому випадку, це не альтернатива lua

може я погано виразився, але місце lua у цій системі — це власне «високорівневе» написання скріптів — логіки, ботів, плагінів — ніхто на lua числодробілки не пише

вона з самого початку заточена на те, що її будуть встроювати у хост систему і писати байндінги для всіх API, які хочеться туди винести

один з прикладів неігрового використання lua — OpenResty
ну і, думаю, є багато інших, оскільки, по словах людей (я свого досвіду не маю), вона реально легко ембеддиться, вплоть до того, що на ній реалізовують конфіг парсери

С тоже высокоуровневый язык =) Плюсы lua я вижу в том, чтобы дать игрокам возможность писать свои плюшки, в тоже время не открывая исходники игры. Не берусь утверждать, но то ли в Доте, то ли в Сталкере, то ли еще в какой-то мега-популярной игре именно так и сделано. Но я в компьютерные игры не играю, точно не скажу.

Насчет числодробилок, на lua+C написан torch7. Выбор, имхо, странный, тот же питон вписался бы лучше, но проект взлетел и это факт.

Но вернемся к Zig, вот что пишет сам автор про мотивацию (предупреждаю я не геймдев и не обладаю знаниями в предметной области):
```
The motivation for this design philosophy is to enable users to write any manner of custom allocator strategy they find necessary, instead of forcing them or even encouraging them into a particular strategy that may not suitable for their needs. For example, Rust seems to encourage a single global allocator strategy, which is not suitable for many usecases such as OS development and high-performance game development. Zig is taking cues from Jai’s stance on allocators, since that language is being developed by a high-performance game designer for the usecase of high-performance games.
```
github.com/...​-Already-CPP,-D,-and-Rust

В Rust есть unsafe, и создатели языка прямым текстом пишут, что unsafe это просто помощи системе вывода типов там, где она это сделать не может. И если возникают ошибки при работе с памятью (SEGFAULT, race condition), то они сконцентрированы в блоках unsafe.

Да, если есть много аллокаторов памяти, то часть преимуществ Rust будет сложно использовать.

А насчет embedding — lua выбирают потому что интерпретатор компилируется в бинарник размером ~300kb. При том lua тьюринг полный. Тут еще можно вспомнить про terralang.org

Go снова отличился!
Google’s DeepMind team has already advanced its AlphaGo AI to dominate Go without human input

Кто еще сомневался что за Go будущее?

Щоб Гугл не забив на нього, як він це робить зі своїми сервісами.

Куда ж забивать, если Go на четвертом месте по популярности на github после Javascript, Python и Java? Скоро догонит и перегонит Java. Что касается недоразумения в виде Javascript, то его можно игнорировать, т.к. его в основном используют люди, далекие от программирования.

На четвертому місці по кількості проектів на github. Варто створити кілька сот тисяч hello world на Basic щоб вивести його в лідери на github.

Go снова в десятке, а Scala — аутсайдер — octoverse.github.com

Go в десятке, а Scala — на 30 месте — www.tiobe.com/tiobe-index :

The Go programming language continues to rise. This month it is at an all time high and enters the top 10. This is an important landmark for the Go programming language, but it also makes you wonder what’s next. Is Go really able to join the big stars in the programming language world and leave languages such as JavaScript and Python behind? We will see. The hipster programming languages Kotlin, Elixir and Hack didn’t progress much this month. Kotlin lost 5 positions, Hack lost 6 positions and Elixir is still not in the top 50 losing also 5 positions.
Go в десятке,

пал ниже delphi в этом году, хипстеры видать набивились этим куском дерьма

Просто в этом году кто-то много заплатил в фонд тиобе, чтобы те опустили го в рейтинге, не имеющем никакого отношения к реальности

скорее ктото забашлял им меньше в этом году

На самом деле — tiobe что=то странное почти всегда показывает. Реальность совсем другая (на следующей неделе опубликую опрос по языкам c неожиданностями )

Как сделать бэкенд многопользовательской игры на Go — blog.u2i.com/...​owser-game-in-go-for-fun

Прикольно. Я смотрю, там чуваки собрались, и всерьёз решили потратить время на написание этой игры.

Как использовать Go вместо MapReduce и Spark для обработки BigData — thinkfaster.co/...​ang-instead-of-mapreduce .


Memory Leaks

The toughest issue I faced was a nasty memory leak. After an hour or so of running, my Go program would eventually consume all of the 200-300 GB’s of RAM on my AWS machine. I didn’t even think it was possible for a program to use that much RAM.

....

I never got to the bottom of the issue. I ran out of time, and I had to „solve” it by changing the slice size to 5000 from 50,000 for that event type. This increased the recycling frequency and solved the issue.

Сборщик мусора ГО в действии. Дальше не читал.

I was also shocked to find that the Python implementation of Spark doesn’t support counters. I’m not sure how people run multi-day jobs without being able to see running values, error rates, etc.

После этого можно не читать.

Если язык нужно осиливать, у него как бы уже проблемы

Да не, если писал на C++ то Java к примеру понять легко, а вот к примеру LISP нада будет осиливать

С хорошим ментором я думаю можно за один управится.

Ну, если например взять толкового джависта, который кроме джавы ничего особо не видел,
и дать ему кложу.
Думаю месяц на освоение синтаксиса, функциональных паттернов, и набивки руки на код, чтобы он банально работал и не падал на каждый чих.
Ну а дальше, мультипоточность, продвинутые фишки, аля всякие трансдюсеры, существующие либы, фреимворки, практики и паттерны.
Думаю, год займет, чтобы получить гребца способного писать качественный продакшен код.
Это еще при условии что он толковый и не ленивый.

Хелло ворлд, да, займет часа 3, скачать кложу там, нагуглить туториал, отредактировать и запустить.

а если писал на ЛИСП то кложур тоже легко, а вот джава полная смена концепции

Про монадирующих программистов или как придумать проблему на ровном месте — m.habrahabr.ru/post/327030 . На go бы написали понятный код за пару минут не задумываясь и не привлекая матан с монадами.

Признак образованного ума — способность принять мысль, не соглашаясь с ней.

А еще лучше налячкать за 1 минуту на похапе и не задумываться о статических типах, компиляторе и какой int выбрать для переменной.

На go бы написали понятный код за пару минут не задумываясь и не привлекая матан с монадами.

За пару минут накопипейстить в 100 раз больше строк кода, и потом повторить для каждого типа коллекций, и повторить для следующей задачи.
Кстати, монад трансформеры в реале никто не использует в 95% случаев.

Многие процессы можно упрощать до уровня понятного для «домохозяйки». Это как с паттернами, можно говорить много слов и описывать суть паттерна, а можно сказать название. В профессиональных кругах так удобнее и лаконичнее.
Как по мне вокруг функционального подхода в программировании слишком много мифов связанных с обязательностью глубокого понимания матана.
Взять теже монады. Это обертка над значением которая умеет принимать фунцию и вызывать ее для значения после чего снова возвращает обертку над значением. Что тут математического?
С другой стороны можно писать код на процедурном языке, там вообще все просто, линейно и понятно, но большое приложение написать и поддерживать сложно.

PS. А в статье автору захотелось поиграться в каноничного функционального программиста.
Я недавно в коде видел проверку существования файла перед чтением в функциональном стиле
... Option(new File(...)).filter(_.isFile).getOrElse(//throw exception)
Оно вроде как правильно с точки зрения ФП, но как по мне — это перебор и я так не пишу. В любом подходе есть крайности и нужно сохранять здравый рассудок.

С другой стороны можно писать код на процедурном языке, там вообще все просто, линейно и понятно, но большое приложение написать и поддерживать сложно.
взаимоисключающие параграфы. Следуя вышей логике, чем сложнее язык программирования и чем больше в нем матана, тем на нем проще написать и поддерживать большое приложение.

Да, я считаю что инструменты для написание сложных распределенных систем требуют определенный объема знаний от разработчика. Так как имеют множество абстракций и средств структурирования и переиспользования кода который нужно знать и понимать.
К примеру на трехколесном велосипеде совсем просто научится кататься, а на двух колесном сложнее, но когда научился — можешь ездить существенно быстрее.

Это как с паттернами, можно говорить много слов и описывать суть паттерна, а можно сказать название. В профессиональных кругах так удобнее и лаконичнее.
Как по мне вокруг функционального подхода в программировании слишком много мифов связанных с обязательностью глубокого понимания матана.

+100500 насчет как с паттернами. Тут ток следующие но: 1. Концептов в фп гораздо больше чем паттернов. 2. Паттерны ООП нечеткие — описывают примерное взаимоотношения между обджектами их можно по разному комбинировать, и по разному реализовывать. Концепты в фп выведенны из математики; монада это не просто
обертка над значением которая умеет принимать фунцию и вызывать ее для значения после чего снова возвращает обертку над значением.
там есть четкие законы которые должны строго соблюдаться, иначе оно все боком вылезет. В результате все это таки нужно изучать и прикладывать мозг. Многие изучать и прикладывать мозг не любят, им проще ГоГо ивпродакшен.
... Option(new File(...)).filter(_.isFile).getOrElse(//throw exception)
Оно вроде как правильно с точки зрения ФП

Вообще ниразу не правильно :-)
В результате все это таки нужно изучать и прикладывать мозг. Многие изучать и прикладывать мозг не любят, им проще ГоГо ивпродакшен.
Эта проблема великолепно решается следующим образом: пишется просто код на Go, а потом прикладывается мозг для решения ребусов, кроссвордов и занимательных задач по математике.

Ну просто тот кто знает фп, он написал одну строчку кода и ушел спать, нету там для него никакого ребуса с кросфордом. А гофер будет день копи пастить, два копипапстить, три копипастить, бац не там символ скопипастил ничегонеработает111

Ребус начинаеться когда фп-дрочер возвращается к написаному им коду через пару недель или его читает кто-то кроме самого автора

Тут я кстати скорее соглашусь с гофагами. ФП от овнокода впринципе не защищает, а наовнокодить можно так, что черт ногу сломает, руку, глаз выколит и сам себя за хвост съест. Преимущество простых императивных языков вроде жабы (и подозреваю го), в том что если уж кто наовнокодил, то к коду впринципе можно подойти, можно его както дебажить, рефакторить, итд, у фп с этим траблы.

У ФП траблы в первую очередь с исполнителями. Вернее с тем, что у них в головах. Умы пытливые, потому часто делают одно и тоже N разными способами :)

Встречал в описании README.txt примерно следующее. Мы потратили немного времени, чтобы написать пару десятков строчек на скала. Смотрите и разбирайтесь. Если умные, то поймёте а если глупы — то вам ничто не поможет.

Ну и ещё часто видел полное отсутствие тестов на clojure проектах. Работает в REPL — работает всегда :)

Работал в скала команде где тесты были более чем норма — мне понравилось

а какая связь между отношением к тестам и скалой? Даже на родном курсе по скале от Одерски куча тестов во всех заданиях.

В своих постах в этом топике я не сравнивал языки программирования. Писал о головах.

Тесты, кагбы не особо спасают.

Мы потратили немного времени, чтобы написать пару десятков строчек на скала. Смотрите и разбирайтесь. Если умные, то поймёте а если глупы — то вам ничто не поможет.
Угу, бич фпшников, когда спрашуеш у них что это такое и зачем — слать в универ теорию категорий учить :-)

И второе, если даже не первое — напрочь игнорить «мелочи» производительности. Выбрать O(N^2) вместо O(N) или добавить десяток аллокаций/оберток на элемент коллекции, увы, многими считается нормой. Или там родить запутанный иммутабельный код, где так и просится мутабельность (локальная).

там есть четкие законы которые должны строго соблюдаться, иначе оно все боком вылезет. В результате все это таки нужно изучать и прикладывать мозг.

Усложнять просто. Даже, если учесть правила монад, то их вполне можно понять без глубоких знаний матана.
Я в основном работаю со Spark и для меня scalaz больше академический инструмент чем практический и яркое тому доказательство, что в самых успешных продуктах написанных на scala не используется scalaz. Я имею в виду продукты из бигдата мира — Spark, Kafka, Ignite. Подозреваю что в Akka и Play картина похожая.

Вообще ниразу не правильно :-)
приведите более правильный код на чистой скале
Даже, если учесть правила монад, то их вполне можно понять без глубоких знаний матана.
Понять можно, но мозг приложить чтобы понять нужно.
А кроме монад там дофига всего, функторы, апликативные функторы, натуральные трансформациии, комонады, трамполины, семигруппы, клайсли, итд итп, терминов больше чем названий ооп паттернов, лол.
Я в основном работаю со Spark и для меня scalaz больше академический инструмент чем практический и яркое тому доказательство, что в самых успешных продуктах написанных на scala не используется scalaz
Я согласен что скалаз почти никто не использует. Однако фп без скалаз и фп со скалаз две немного разные вещи. Адапты скалаз называют такое фп без скалаз — «джавой».
приведите более правильный код на чистой скале

Тут можно много вариантов придумывать, но изнутри бросать исключение — не фп вообще ни разу.
Это обертка
Не всегда. Тот же Reader или IO из хаскеля не обвертка.

Я не знаком с хаскель. Но почитав о Reader понял, что это обертка которая содержит функции.

Еще один топ Node.js дев перешел на сторону Go twitter.com/…​status/837130223770533889

Напишите уже бота, который будет агрегировать любые статьи, блоги, твиты с любым упоминанием го и постить сразу сюда в тему.

Говорят, что умных AI ботов лучше писать на scala. Если он будет на go, то может случайно запостить статьи о переходе с go на scala.

все умные боты уже давно перешли на Go, сидят и спокойно копипастят ссылки, так что примеров нет.

Сначала переходят капитаны, а за ними побегут и все остальные, как крысы с тонущего корабля.

Все, приехали — автор node.js перешел на Go — www.mappingthejourney.com/...​n-dahl-creator-of-nodejs

Yeah, I think it’s... for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go.

I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.

If you’re building a massively distributed DNS server, I would not choose Node.

RIP node.js. Мы будем помнить о тебе (в страшных снах) :)

Он практически сразу перешел на сторону Go, осознав свою ошибку и какого Франкейнштейна он сотворил :)

Чувак пилит новый рантайм, лишенный недостатков ноды
github.com/denoland/deno

А большая часть его репо — это с++, тс и питон
Так что, можно сказать, никуда он не перешел

бгг, показово — порівну rust та c++ :)
сподіваємось, чим далі доля rust буде збільшуватись...

Доля rust увеличится за счет доли C++, т.к. C++ стал настолько сложным и запутанным, что проще есть кактус с меньшими иголками в виде rust’овых memory ownership/safety и «zero-cost abstractions», которые на самом деле совсем не бесплатные в процессе написания кода. Надеюсь, автор deno скоро осознает свою ошибку и вернется обратно на go.

rust також не проста мова, я б навіть сказав, що на рівні з c++, просто складні фішки розкидані по-іншому, а ще у нього крива навчання набагато крутіша за c++.
Просто rust багато просить спочатку і багато дає взамін потім — це не тільки параноя при роботі з пам’яттю, але й макроси, модулі, виведення типів, зрозумілі повідомлення про помилки, і дуже зручний cargo.

Нет, rust займет свою нишу вместо c++ — им будут пользоваться те же извращенцы и мазохисты, которые сейчас сидят на c++.
Scala же продолжит медленно умирать.

им будут пользоваться те же извращенцы и мазохисты, которые сейчас сидят на c++.

будуть переписувать гігатонни легаці кода?

Будут создавать гигатонны нового говнокода, в котором хрен разберешься

Спробуйте підвищити свій професійний рівень...

Хотел бы повысить, да некуда — рограммирование на Go подняло профессиональный уровень до небес.

цікаво, чи буде тема схожа на
dou.ua/forums/topic/25288
«Чому ми не бачимо збільшення кількості Rust розробників якщо їм платять більше ніж іншим?»

Не будет, т.к. ответ очевиден — среди программистов мало извращенцев с мазохистскими наклонностями, которым бы понравилось решать ребусы с borrow checking и zero cost abstractions в rust. Тут подойдут только приплюснутые, которым нравится разбираться в стострочных ошибках компилятора при неверном использовании stl или boost шаблонов

Я би не казав так,
Все ж Rust дає можливість писати високо абстрактний код, використовуючи ітератори і замикання, з одного боку, і з іншого компілювати це в швидкий код, і це без GC.
Я чим далі читаю документацію по ньому, тим більше він подобається.
А до С++ в мене неприязнь давно, так як те що і як пишуть приплюснуті в ембеддеді, потім приходиться або переписувати на С, або закривати проект.

А якщо люди хоть трохи розібралися із сементикою move, що появилася із С++11, то задовільняти borrow checker, думаю це не буде для них проблемою

Хоча в Rust я тільки починаю заглиблюватися, але вже нема початкової антипатії та відторгнення, коли починаєш розумиіти як це разом працює. Плюс до того є певна екосистема для тестування, документування та відслідковування версій.

Нет, rust займет свою нишу вместо c++ — им будут пользоваться те же извращенцы и мазохисты, которые сейчас сидят на c++.

ну чего еще ожидать от Goвношлепов

Кто такие goвношлепы и какое отношение они имеют к с++ с rust?

в том то и дело, что никакого, но амбиций выше крыши

Там дипломатично, без лишнего троллинга намекают, что пора java-обезьянам переходить на Go. Нашим сектантам надо брать с них пример.

Martin Odersky наконец-то понял, что implicit conversions — зло: github.com/lampepfl/dotty/pull/2060 . Затем он поймет то же самое о наследовании, перегрузке операторов и других бесполезных фичах scala. В итоге scala превратится в Go :)

— сами же смеетесь с примитивности Go, так держать

Только забыли добавить еще ссылку dotty.epfl.ch
Где перечисляются нововедение, одно из главных:
— Union, intersection and literal singleton types

Go не примитивный. Я несколько месяцев на нем пописал, и регулярно обнаруживал что то что я написал можно было сделать проще и красивее.

Второе предложение противоречит первому

Нет. Просто в нем есть такое чего в сях и близко нету. Чтобы научиться эффективно этим пользоваться, нужно время больше чем несколько месяцев. Хотя писать можно буквально сразу. От этого он выглядит как примитивный.

ну я же надеюсь что не нужно доказывать что на си писать сложнее? соответственно го примитивнее си

то что в нем больше возможностей из коробки не делает его сложным, напротив, это упрощать жизнь должно, соответственно делать сложные вещи проще, наращивая параметр примитивность

В итоге scala превратится в Go :)
Не превратится, чтобы достичь уровня Go, скале надо ещё развиваться и развиваться.
В итоге scala превратится в Go :)
а я грешным делом было подумал, что Мартин Одерски после всего этого перестанет разрабатывать скалу и перейдет на Go)))

Да он бы перешёл, но ведь надо сначала как-то сообщество убедить в этом, а для скалистов это долгий эволюционный путь.

Да он бы перешёл, но ведь надо сначала как-то сообщество убедить в этом
походу это проблема не только скалистов)) вон еще есть любители всяких Nim’ов dou.ua/lenta/articles/nim (да и сам Nim судя по гитхабу активно пилится), Rust’ов dou.ua/forums/topic/12748 и прочих хаскелей)

Nim и прочие — не поддерживают ни Google, ни Microsoft, ни Apple, ни даже Adobe.

именно поэтому удивительно, почему те, кто пилят код на Nim и прочих, до сих пор не перешли на Go)

У них очень важная языковая миссия: доказать своим примером правильность выбора Go. Глядя на них, для всех выбор становится очевидным.

Дык судя по этому топику, пачки же скалистов и так сами бугут и переходят, или автор топика врет ?

Всё так, только некоторые заблудшие овцы всё ещё пишут на скале, в то время как сам автор языка уже выискивает подходы, каким способом побыстрее перейти на Go.

Гошники слидят за скалой больше, чем собственно сами скалисты. Это уже на уровне паранои с с шизофренией )

Просто оставлю это здесь
www.indeed.com/...nds/q-scala-q-Golang.html
redmonk.com/...0/language-rankings-6-16
stackoverflow.com/...echnology-top-paying-tech

Учитывайте что со скалой вы можете заниматься очень широким спектром задач, начиная от разработки фронтенда(scalajs) заканчивая bigdata data processing & mining.
Что кроме написания бекендов(серверов) и консольных утилит делают на го?

Выводы делайте сами.

Scalajs звучит так же смешно как и гвт

Не, gwt говно совсем другого порядка
со scala js можно жить

С гвт в свое время был вполне рабочий юз-кейс — для джс тогда небыло вменяемых редакторов, средства отладки были фиговыми, небыло реквайеров, систем сборки и зависимостей и прочего прочего.
Сейчас когда все и много больше под жс есть, надобность в полуфабрикатах непонятна.

Да и в 2005 он уже был говно говном если нужно делать сложный UI
вообще как только в голову приходит идея писать код на java который потом няшно напрудит лапши из убогих компонентов на страницу- надо смело, с размаха бится головой о стол и больше такое не думать

код на java который потом няшно напрудит лапши из убогих компонентов на страницу
 Хз в 200(~8) это было 90% всех фреимворков.

не делает этот подход лучше ни на копейку (JSF этот еще , zalupa сотоны)

лично знаю людей которым нравиться и они это выбрали базовой технологией в 2012 кажется
и EE7

JSF i Java EE 7 добровільно вибирати в 2012? це де такі психи живуть?

Java EE 7

Про ЕЕ 7 хз, но пописал на ЕЕ 6 какраз в 2012. Для своих целей норм технология, вполне конкурент была пресловутому «спринг+хебирнейт».
Но
JSF
... вспоминаеться www.youtube.com/watch?v=0B61_5sRoBI

EE7 тода вообще в бете еще был, катинг эдж ынтерпрайзоепства жи
ну и primefaces которые делали жизнь с JSF терпимой.
но это все равно содомия. Ибо багов в итоге странных больше, чинят их хуже и привкус говна не покидает мироощущение.

Можно привести примеры кто это использует в проде? Есть ли полноценные фреймворки для написания SPA?

> www.indeed.com/...nds/q-scala-q-Golang.html

За 2016 год скала выросла в два раза, гошечка — в четыре

> redmonk.com/...0/language-rankings-6-16

Купленный рейтинг. Вот этот правильный — www.tiobe.com/tiobe-index . Скала на 29 месте, гошечка — на 14.

> stackoverflow.com/...echnology-top-paying-tech

Тут соглашусь — из-за хайпа вокруг скалы до 2010 года многие вляпались в нее, потом не смогли асилить, а теперь надеются найти супер-программиста на скале за бешеные бабки, который бы вытянул их проект из глубокой задницы. Наивные. Лучше бы перешли на go, сэкономили деньги и остались на рынке.

Что именно куплено в рейтинге redomnk где по осям количество проектов на гитхабе и количество тем на SO?
Опиши по каким параметрам считается индекс Tiobe, и почему в топ 20 в нем scratch, 2 бейсика, assembly, sql и matlab???
Из всех рейтингов этот имхо самый неадекватный.

Что именно куплено в рейтинге redomnk где по осям количество проектов на гитхабе и количество тем на SO?
По количеству проектов на гитхабе go давно обогнал scala — 57К go-репозиториев против 26К scala-репозиториев.

Большое количество вопросов на stackoverflow в первую очередь говорит о том, что scala мало кто может асилить. Вот и задают вопросы.

Учитывайте что со скалой вы можете заниматься очень широким спектром задач, начиная от разработки фронтенда(scalajs) заканчивая bigdata data processing & mining.
Что кроме написания бекендов(серверов) и консольных утилит делают на го?

Вы так говорите про bigdata, как будто кроме Scala его больше нигде нет. Например, через наши сервисы на Go сейчас проходит до 170 миллиардов событий в сутки. Все события сохраняются в базу для дальнейшего анализа. Это можно считать bigdata?

А вообще на Go много чего разрабатывается — см. github.com/...-go/blob/master/README.md .

Серьезно?
>> round(170E9/24/60/60)
ans = 1967593
2 мильёна в секунду? Что за база такое потянет?

2 мильёна в секунду? Что за база такое потянет?
Мы из постгреса выжимали 500к insert’ов в секунду на один 12-ядерный комп. При этом этот же комп занимался агрегацией, ротированием, а также обслуживанием select’ов по этим данным. Но постгрес был слабоват по двум направлениям:

— по скорости сканирования сырых данных удавалось выжать только 3 миллиона строк в секунду на один поток.

— по объему занимаемой памяти в persistent storage — каждая строка сырых данных занимала 200 байт.

Поэтому пришлось перейти на clickhouse. Теперь каждая строчка сырых данных из более 40 значений занимает 10 байт, а скорость сканирования доходит до миллиарда строчек в секунду на один поток и растет линейно с количеством потоков, обслуживающих запрос.

Теперь каждая строчка сырых данных из более 40 значений занимает 10 байт
это как — по 2 бита на значение?

Вангую, що там 16 біт малося на увазі :)

Да.
Некоторые значения с большой энтропией плохо жмутся и занимают до двух байт (например, ip-адрес). А некоторые жмутся до тысячных долей бита, т.к. редко меняются (например, дата со временем).

От мені цікаво, як ви тисячні частки біта зберігати зібралися...

8 тысяч значений даты со временем по 0.001 бита сохраняются в один байт. Что тут непонятного?

Так один байт зберігається, а не 8К значень. Ні? І приведіть приклад зберігання :)

Так один байт зберігається, а не 8К значень. Ні? І приведіть приклад зберігання :)

Например, в следующей строке закодировано почти 450К значений даты со временем. Каждое значение занимает 0.001 бита:

’Тут хранится 448К значений времени "2017-05-15 12:21:42"’

Лол. Наверное если тебя попросят сделать суппер быструю программу на Го, ты им напишешь — 2+2=4
и прокомментируешь на презентации — я могу посчитать результат ста триллионов операций и у меня это займет меньше нано секунды времени на Go.
Жмет и считает как никто ранее.

Шото я не догоняю — це жарт такий? Як вичитати всі ці таймстампи з приведеного рядка?

Ребят, я извиняюсь, но вам было бы неплохо почитать хотябы какието основы теории информации. Читать эту ветку даже не смешно ...

Не знаю, но лекции по теории информации, в отличие от некоторых, не прогуливал — ru.m.wikipedia.org/wiki/Теория_информации

Та мені здається, що ви таки прогуляли їх. Перше, зберегти значення в тисячних біта в сучасних комп’ютерах неможливо. Друге. Ваш приклад наводить тільки те, що ви виконуєте процедуру конвертації даних в інший формат із можливістю зворотнього процесу. Так само я можу стверджувати, що можу зберігати всю інформацію гугла в одному біті. Його буде достатньо для посилання на весь той масив.
Третє. Ви забуваєте про те, що окрім ваших стиснутих даних треба ще й зберігати декомпрессор ;)

Перше, зберегти значення в тисячних біта в сучасних комп’ютерах неможливо.

В битах тоже уже лет десять как не хранят и тем не менее это никому не мешает выражать информацию в битах. Или тысячных бита если так удобней.

Так само я можу стверджувати, що можу зберігати всю інформацію гугла в одному біті.

Утверждать вы так конечно можете, но ваше утверждение никто не поймет пока ваше представление о теории информации будет ограничено одним параграфом учебника по информатике.

В битах тоже уже лет десять как не хранят
А в чому? О_о
Или тысячных бита если так удобней.
Це дурня та маячня. Я ще не бачив жодної платформи, яка б оперувала тисячними біта.
Каждое значение занимает 0.001 бита
Если ты не переопределил понятие бита- то я не понимаю о чем ты говоришь. Если ты имел ввиду компрессию данных- то там говорят о % сжатия.

Что такое бит?

По вашей ссылке все написано:

If the two possible values of one bit of storage are not equally likely, that bit of storage will contain less than one bit of information. Indeed, if the value is completely predictable, then the reading of that value will provide no information at all (zero entropic bits, because no resolution of uncertainty and therefore no information).

Жаль, что вы не можете решить задачу для третьего класса: 448К значений даты со временем занимают 56 байт на диске. Какой объем данных занимает одно значение даты со временем?

Какой объем данных занимает одно значение даты со временем?
Ви в якому закладі навчалися? Скажу своїм, щоб з нього ніколи нікого не брали.
Я вас можу розчарувати, ваша школоло-математика не діє. Зробіть стискання однієї дати та дайте нарешті собі відповідь. А ще не забувайте про те, що програма-стискач має не нульову довжину, та теж займає місце на диску.

Обычно под бигдетой подразумевают хранение, обработку и анализ. А писать ивенты и в хбейс можно.

У нас есть сервисы на go, принимающие и собирающие статистику в реальном времени по 500к событий в секунду на один комп. При этом они грузят 1-2 ядра CPU из имеющихся 40 ядер. Т.е. в теории они могут обрабатывать до 20 миллионов событий в секунду на одном компе. К сожалению, мы не можем отказаться от шардинга на несколько компов, т.к. эти сервисы требуют много оперативной памяти.

Это опять нельзя считать бигдата?

А если эти сервисы обновляют в режиме реального времени десять миллиардов различных счетчиков? Все еще не бигдата? Тогда с какого числа начинается bigdata?

биг дата начинаеться с того момента когда данные не лезут на совсем офигевший дб сервер
ну там 128 ядер, 256 гиг рама и тп
так что если вы их вынужденно батч процесите — то да, биг дата

У нас есть таблица в базе с более 10 триллионов записей (триллионов, а не миллиардов). Запросы в таблицу делаются из PHP. Если даже PHP может работать с бигдата, зачем тут Scala?

Десь я це недавно читав... а, от же ж:
habrahabr.ru/post/322620
Воно ?


Дальше мы пошли к разработчикам, которые умеют разрабатывать для баз данных, знают SQL и все вот эти вещи. Они стали смотреть на ClickHouse. Они поняли, что в ClickHouse почти ничего нет:

Там нет транзакций, нет констрейнтов.
Там есть primary key, но это не primary key на самом деле, можно сказать это порядок физической сортировки.
Там нет Consistency, то есть Consistency никак не гарантируется.
Нет удалений и апдейта.
Нет NULLs, система к которой вообще нельзя Null записать.
Нет миллисекунд, то есть время с точностью до секунды, хотите миллисекунды — храните их по-своему, как Int64 или отдельным полем.
Нет автоматических приведения типов, то есть даже Int8 к Int16 надо приводить явно.
Нет нормального SQL, это понятно из всего предыдущего списка.
Нет произвольного партиционирования, партиционировать можно только по месяцам, то есть нельзя по дням или по неделям отпартиционировать или по произвольным ключам, нельзя и всё.
Нет средств управления кластером, то есть они, наверное, есть у самого Яндекса, но он их не смог настолько запаковать, чтобы это можно было увидеть в Open Source или не захотел.

Але вам, я так розумію, якраз підходить ?

Да, clickhouse отлично подходит нам по следующим причинам:

— clickhouse выполняет типичные select запросы в сотни раз быстрее по сравнению с типичными sql-базами. Т.е. там, где потребовался бы кластер из 100 серверов, мы обходимся одним сервером.

— clickhouse круто пакует данные на persistent storage. Например, сейчас наши данные пакуются в 15 раз по сравнению с размером сырых данных. Т.е. при использовании типичных sql-баз пришлось бы устанавливать в 15-30 раз больше persistent storage’а. Число 30 вылезло от того, что типичные sql-базы хранят в файлах дополнительную информацию кроме самих данных — размер каждого значения, размер одной строки, смещения, индексы и т.д. Очевидно, clickhouse тоже хранит все это, но в сжатом виде :)

— clickhouse прекрасно работает на обычных HDD с низкими iops’ами. Т.е. можно сэкономить на SSD в 5-6 раз.

— clickhouse легко масштабируется на произвольное количество физических компов. При этом скорость вставки/чтения данных растет линейно. Ноды можно добавлять/удалять в течение секунды без остановки кластера. На одних и тех же компах может быть произвольное количество кластеров, т.к. кластеры поддерживаются на уровне таблиц.

— clickhouse поддерживает композитный индекс по нескольким колонкам, с помощью которого можно оптимизировать типичные select-запросы, в отличие от google BigQuery.

— clickhouse умеет делать бэкапы десятков терабайт данных за пару секунд. И эти бэкапы не занимают место на дисках :)

— Выход из строя одной из нод не приводит к выходу из строя всего кластера, как это часто бывает у «коробочных» решений. Самое страшное, что может случиться — утеря данных, хранившихся на этой ноде (это в случае, если у вас не было бэкапов и/или репликации).

— Простой формат хранения данных на файловой системе — базы лежат в отдельных папках, внутри них — папки с таблицами, внутри которых — папки с «кусками» таблиц. Т.е. при желании можно вручную манипулировать этими папками (в пределах разумного :) )

Чем это существенно отличаеться от пресловутой кассандры ?

Не знаю, но подозреваю, что в первую очередь повышенной эффективностью использования имеющихся ресурсов CPU, RAM и storage space.

Эм, так оно же на си++ написано, где тут заслуга го, я чет не понял.

Это печально. Надеюсь, они скоро перепишут все на Go, чтобы ускорить развитие и уменьшить количество багов в коде. Или это придется сделать кому-то другому )

У нас есть таблица в базе с более 10 триллионов записей (триллионов, а не миллиардов). Запросы в таблицу делаются из PHP.
А база мап редьюс всех трилионов записей сама делает ? Или пхп делает редьюс ? Или у вас просто записи, один ключ, и положить в ключь, взять из ключа ? Так это не биг дата, в современном смысле.
А база мап редьюс всех трилионов записей сама делает ?
да
Или пхп делает редьюс ?
нет. Пхп делает select-запросы с подсчетом различной статистики по одному набору колонок (aka metrics), фильтрацией по другому набору колонок (aka custom filters), группировкой по третьему набору колонок (aka dimensions).
Или у вас просто записи, один ключ, и положить в ключь, взять из ключа ?
нет

не агрись как школьник, я тебе просто сказал что ПРИНЯТО называть big data и про скалу и пхп вообще ничего не говорил ибо это все не при чем

По моему тебе надо немного успокоиться и начать читать что тебе отвечают.

Например, через наши сервисы на Go сейчас проходит до 170 миллиардов событий в сутки.
coubsecure-s.akamaihd.net/.../med_1406984469_image.jpg

Вы считаете, что 170 миллиардов событий в сутки не тянет на bigdata?

— ну это не показатель, что такое событие, что вы с ним делаете, куда сохраняете, как обрабатываете ?

— Кстати, ваши цифри не очень впечатляют, вам нужно старатся лучше.
для примера martinfowler.com/articles/lmax.html :
The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.
будет полезно почитать про LMAX Disruptor

— да и цифры www.techempower.com/benchmarks не очень красят гошечку

Можем все таки убрать усколобост , и понять что, так малелькая латенси, просто так не дается, и старадают другие параметры, такие как пропускная способность. Для вас есть чудесная статья
habrahabr.ru/...mpany/mailru/blog/318504 где все прекрасно описывается.

P.S Долго не хотел отвечать, даже на ваше предыдущие сообщение, но не выдержал к сожалению =(

— Кстати, ваши цифри не очень впечатляют, вам нужно старатся лучше.
для примера martinfowler.com/articles/lmax.html :
The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.
будет полезно почитать про LMAX Disruptor

Ну так на бенчмарках и наша система обрабатывает несколько миллионов событий на одном потоке. К сожалению, бенчмарки обычно далеки от продакшна. Также у нас не было задачи выжать максимум производительности любой ценой — текущая производительность получилась сама собой без особых усилий. Она нас полностью устроила, поэтому дальнейшими оптимизациями не стали заниматься.

— да и цифры www.techempower.com/benchmarks не очень красят гошечку

www.techempower.com/...-r13&hw=ph&test=plaintext — гошечка в топе.

Можем все таки убрать усколобост , и понять что, так малелькая латенси, просто так не дается, и старадают другие параметры, такие как пропускная способность. Для вас есть чудесная статья
habrahabr.ru/...mpany/mailru/blog/318504 где все прекрасно описывается.

см. dou.ua/...rums/topic/16012/#1042597

Ну так на бенчмарках и наша система обрабатывает несколько миллионов событий на одном потоке. К сожалению, бенчмарки обычно далеки от продакшна. Также у нас не было задачи выжать максимум производительности любой ценой — текущая производительность получилась сама собой без особых усилий. Она нас полностью устроила, поэтому дальнейшими оптимизациями не стали заниматься.
А где вы увидели бенчмарк. Если там реальное приложение в продакшене.
www.techempower.com/...-r13&hw=ph&test=plaintext — гошечка в топе.
Go в топе, но где-то уступает, где-то выигрывает, но в топе и scala (вами не любимая) и java, но вы как-то забываете об этом упомянуть
см. dou.ua/...rums/topic/16012/#1042597
1) STW паузы в Go не превышают 100 микросекунд out of the box на любых размерах хипа, в то время как STW паузы в Java сильно зависят от настроек GC и размера хипа, и в общем случае держатся в районе 100 миллисекунд, т.е. в 1000 раз больше, чем в Go.
Ну hotspot gc’s и не тягаются с лоу-таненси системами, для этого есть имлементации Azul и Red Hat
Только вот я вам про одно, что чудес не бывает, и go gc это cms в hotspot без поколений, и выигрывая в одном параметре, проигрываем в другом. Но все упорно доказываете, что gc в go, это лучшее что есть на данный момент. Хотя для многих задач маленькие задержки , это не так важно, как пропускная способность. Но нет, вы пытаетесь везде сунуть go. На этом языке, написано чудесные инструменты: kubernetes, графана, докер и т.д. Язык занимает свою нишу, и кажется с нею справляется. Но каждый инструмент, решает определенные задачи. Но, кажется, вы пытаетесь всовывать его везде где только можно, и доказывать что другие инструменты не имеют взгляд на жизнь. Что довольно глупо
для примера martinfowler.com/articles/lmax.html :
The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.
будет полезно почитать про LMAX Disruptor

Спасибо. Почерпнул оттуда парочку полезных идей:

In fact they ended up by doing all the business logic for their platform: all trades, from all customers, in all markets — on a single thread

Классное масштабируемое решение. Что будут делать, когда один поток перестанет справляться с нагрузкой? Мы в данном случае просто добавляем компы.

Like the rest of the system, the disruptors are bounced overnight. This bounce is mainly done to wipe memory so that there is less chance of an expensive garbage collection event during trading.

Еще одна классаная идея — периодически перезагружать сервис из-за супер-навороченного gc, который «much more advanced than the simple GC in go». Или из-за нагромождения лишних абстракций с паттернами проектирования, которые так любит парить этот дядька? Мы перезагружаем наши сервисы на go только при деплое новых версий. Некоторые сервисы работают без перезагрузки месяцами.

В нужных местах на jvm языках используют память которая не под управлением gc. К примеру в Spark, Hbase, Drill и других проектах.

The system is built on the JVM platform ... that can handle 6 million orders per second on a single thread.

Для проца 3GHz это 500 тактов на запрос, если понимать буквально.

«170 миллиардов событий в сутки» это почти точно 2 million events per second.

Невнятные ответы джуна и стажера? Или хвалебные отзывы после перла и нодежс?
«Года три назад я увлёкся Erlang’ом (и ФП в целом), но понял, что зарабатывать на нём — да ещё столько же, сколько на C++, — я не смогу (сразу, а не через пять лет). По этой же причине отпала Scala (жаль, мне она показалась весьма интересной), этот язык подразумевает серьёзный бэкграунд на Java. Rust просто не понравился сразу. Go, кстати, тоже не понравился: после C++ мне многого в нём не хватает, в первую очередь гибкости.»
Ок, в мейлру не пишут на джаве, поэтому скалу протащить не получилось. Однако пишут на си, перле и js и протащили как-то го.

На сколько я знаю, в мэйл ру довольно много пишут на джаве. По крайней мере я слушал их курс по биг дате и лектор говорил, что в поисковом движке по возможности все переписывают с С/С++ на джаву.

На сколько я знаю, в мэйл ру довольно много пишут на джаве.
На жаве пишут, а скалу ниасилили. Пришлось пересесть на гошечку :)

Скала хороша не для всех задач. То есть сложность/специфика продукта должна оправдывать сожность языка и при этом «заказчик» должен иметь возможность собрать нужное количество разработчиков.
Я считаю, что если продукт написан на скале, то он с большой долей веротяности будет не тривиальным и интересным в плане разработки. В этом и есть профит скалы для меня.
Можно много философствовать о динамике развития GO, но пока на нем не появятся действительно сложные продукты, тяжело говорить, что GO крут для девелопера.

пока Go это то куда php обезьян гонят прикладами и пинками в красные ср#ки, что бы они попали хоть в какие то рамки и начали писать что то вменяемое
другой ниши пока нет ( но это не значит что язык плохой)

php-обезьяны судя по наблюдениям, как-то не тянут разработку на Go. Складывается иногда впечатление, что надо сначала на скалу перевести в качестве промежуточного звена.

ага с котятами и scalaz доо
уж там то они покажут

Сенсация!!! Вышел релиз новой версии Go 1.8 blog.golang.org/go1.8 что ознаменовало новую веху в истории программирования, девелоперская мысль поднялась на следующую ступень, и вышла на более высокий уровень развития!

Так там особо ниче не поменяли то

так оно и другим особо не надо, или вы Кнута не читали?

Не знаю, не знаю. Мужики в Гуглі кажуть що вроді їм нада.
а шо только в Гугле сидят программисты?
Кнута Гамсуна?
тот который Дональд
А до чого тут Кнут?
есть у него знаменитая фраза на этот счет:
Преждевременная оптимизация — корень всех зол

Скажем так, Го можно было бы улучшить не только оптимизировав, даже более того — для Го это улучшения выеденного яйца не стоит. не, может в гугле есть какойто проект для которого данная оптимизация нужна, но для комьюнити реальной пользы ноль.

Во первых, я думаю они оптимизировали GC только для некоторых сценариев, во вторых, если даже в JS научились решать STW проблемы (а тут вообще в этом плане все печально), то что-то мне подсказывает что и в Go, это не настолько большая беда. А вот слабый дизайн языка — это есть, и это то чтобы можно было улучшить, и то чтобы было более значимым вкладом в язык, а такого рода оптимизация, при общей бедности это является примером бесполезной оптимизации (но я таки уверен что была проблема с этим делом у какогото внутреннего проекта Гугла).

Го задумувався як альтернатива С, а не Пітону.

Ніша Go якраз близька до Python та Java.
Відносно безпечне прикладне програмування.

может быть вы и правы, посмотрим как оно будет

А итогом Rust и Swift — эт современный С, а го — таки пиитон без блекджека и куртизанок.

Але мені він здалеку нагадує С++ своєю монстроподібністю.

И близко не рядом с С++. Rust, Kotlin, Swift — вот похожи весьма, как по мне, только последние 2 таки еще и с классами. Они больше похожи на С с генериками и блекджеком.

І досі не можу зрозуміти чому Го порівнюють з Пітоном. За простоту?

Питон нифига не простой. Го — простой, как рельса (т.е. как С), но безопасный (в отличии от С). Использовал питон именно из вашей аналогии в ответе на оригинальный коммент..

Це Ви не розумієте, що GC зовсім без пауз це задача рівня студента, але будь-які міри по зменшенню пауз збільшують відносну ціну всього збору сміття. Повний STW дешевле за все, і він продовжує займати свою нишу там, де сумарна робота важливіше за рівномірність. Тому, наприклад, звичайні GC в Яві не робляться так, щоб STW не було зовсім — це потрібно 0.1% користувачів, і ті краще сядуть на Azul.

Кльовий світ у нас, ледачий, всякі гуглсамерсофкод проводять і на них жодного ГЦ такого і досі не написали!

Написали, тисячі їх. Але: поверх malloc (і явних списків) і без поколінь. Тому і не цікаві — затрати памʼяті в 2-3 рази більше, ніж у нестудентських.

От що саме в Go — можна подивитись. Якщо воно з поколіннями і на власному алокаторі — то це вже цікаво переглянути докладніше.

Боюсь що Azul не всім по карману буде.

Так. Але вже є (або скоро буде) Epsilon GC.

Інакше би всі нормальних розрабів наймали, як Гугл

Гм... боюсь, що політика Гугла більш дивна, ніж просто «нормальних».

Вам самому не смішно від того що не існує жодної хоч більш-менш промислової мови з автоматичною зборкою мусору і без STW, при тому що це робиться елементарно?

В Lua нема STW (якщо вщент не затюнити). А ціну за це я вже казав.

А всякі дурні ліплять костилі по типу смарт поінтерів чи бороу чекерів.

Так, Ви ще раз показали свою необізнаність в темі.

Всі ваші студентські подєлки насправді не далеко від Epsilon і втекли.

А в Києві дядько.

Невже ж це ціна? Пам’ять сьогодні не така вже й дорога, значно дешевше Азула то точно.

Ви такі навколо бірж не працювали. Деякі ставлять 2TB RAM в сервер, тільки що денний масив marketdata зберігати і обробляти. І ні, ніякі SSD або навіть Optane не пропонуйте — швидкості не вистачить. І розділяти на кластер серверів не можна — бо технології тупі, як сокира троглодита.
Я розумію, що все це вкрай маргінальне для більшості. Але тій більшості підходять і звичайні затримки від STW Яви (наприклад, чувак з Однокласників казав — все менше 0.2с(!) їх влаштовує).
Шлях Go вкрай дивний — вони зменшують затримки за рахунок всіх інших характеристик GC, при тому, що не мають таких обмежень, як Lua.

В оф. докі пишуть що просто дроблять паузи на менші, що й G1 намагається робити.

G1 працює в умовах значно більш складних, ніж Lua. Там суттєво зменшувати паузи значить нелінійно збільшувати накладні витрати.

Про Луа щось так сходу не знайшов.

Просто в офіційній документації. В них на 1 запит до системи памʼяті додатково k/100 (в середньому) кроків розчистки існуючого. k можна міняти, в залежності від нагальних потреб. Але, вже казав, у іншому схема дуже примитивна. Боюсь, що в Go десь те ж саме.

Від необізнаного чую!

Я дійсно знаю не все :) але я про це знаю і маю на увазі :)

обмежувався 0.18 сек

Це безглуздо багато, в інших задачах треба вже суб_мікро_секундні затримки.

аші слова мені нагадали про те що 640К вистачить усім

Це як же треба читати, щоб мої слова нагадали таке? 8-O

Про те й мова. Ви самі привели Луа в якості промислового прикладу, а потім кажете що він не потягне «складні» умови.

Так, він по-прежньому промисловий, і я не відмовлятимусь від цього. Складність буває різна.

за рахунок чого там немає пауз (як ви стверджуєте). На скільки я зрозумів то паузи там є але просто їх більше і вони дрібніші.

Затрати на GC _рівномірні_. Це і зветься «нема виділених пауз». А інакше взагалі нема сенсу розглядати, бо на рівні процесора кожне чекання cache miss це пауза.

Бо відмінність STW від промаху кеша, сискола чи іншого «тормоза» хоча би у тому що це відноситься до одного потоку, і не ставить всю систему на паузу.

Єдина нитка чи ні — це подальший розвиток питання про механізм GC, я не хотів одразу в це пірнати. В .NET, наприклад, зупиняються всі нитки заради створення пулу первісних посилань для GC. Але взагалі і це необовʼязкове: достатньо вести облік того, чи було посилання отримане після останного рескану конкретної нитки. Але форсування такого рескану може бути занадто дорогим або складним. Якщо допускається чекати і блокувати роботу, поки всі нитки відреагують, то задача спрощується в рази. Якщо ні — можна, наприклад, вести пул первісних посилань і виключати щось з нього тоді, коли жодна нитка 2 рази підряд не тримає посилання. Такий собі «консервативний» дизайн.

Я так розумію такої точки зору і термінології дотримуєтеся не лише ви?

Судячи по згадуванням в профільній літературі — так. «Stop the world» має два аспекти, які дещо конфліктують — «великий збір всього» у однонитковому сенсі, і одночасна зупинка різних ниток. Друге звичайно містить в собі перше (інакше зовсім дивна химера створюється). Але, в практичному сенсі оцінки затримки взаємодії, різниці нема: якщо нитка, що оброблює запит клієнта або активність локального користувача, заблокована, йому нема справи, зупинені інші нитки, чи ні.

набагато більше ніж відсоток користувачів бажали би менші паузи в колекторі.

Сферично в вакуумі — тобто відірвано від інших потреб — мабуть, так. Але, якщо порівняти дві реалізації — в першій паузи до, наприклад, 200мс, в другій — до 20мкс, але друга їсть в 3 рази більше памʼяті — виявляється, що таки 99% виберуть першу, і це покриє діапазон від звичайних десктопних застосунків до великого серверного навантаження. Тому основна оптимізація іде саме під них.

Я мав на увазі паралельний колектор, до якого прагне людство, який працює паралельно потокам основної програми, при цьому не зупиняючи їх.

Виділяти на нього окрему нитку? Були такі спроби. Наскільки я знаю, вже закінчились. Бо вельми недружні до кеша.

Мені здається що це лише ваше бачення потреб ринку.

І чомусь воно співпадає з баченням авторів оригінальних JVM і дотнета.

Шкода на ДОУ голосувалки немає, можна було би статистику зібрати чи потрібен такий колектор чи ні.

Так роблять голосувалки через Google Docs, регулярно.

Да. Закінчилися бо це не так просто зробити як ви намагаєтеся показати.

Я намагаюсь? На окремій нитці? Мабуть, вам треба перерву на сон.

Те що реалізації немає не обов’язково свідчить про те що вона непотрібна.

Взагалі — так. Але супроводження десятків і сотень мільйонів установок товстими комерційними фірмами зводить імовірність такого практично до нуля.

шо ви людей Гамсуном і Трампом плутаєте?

Кроме 100-микросекундных пауз STW, в Go 1.8:
— увеличили производительность скомпилированных программ. Теперь они работают да 30% быстрее по сравнению с go 1.7
— увеличили скорость компиляции
— уменьшили в два раза накладные расходы на вызов С-функций
— оптимизировали кучу мест в стандартной библиотеке
— перевели бэкенд компилятора для всех поддерживаемых архитектур на SSA
— написали с нуля новый парсер go-кода, который работает быстрее предыдущего и показывает более качественные сообщения об ощибках
— добавили поддержку компиляции под новые архитектуры
— добавили поддержку кучи ассемблерных инструкций для работы с векторными данными на разных архитектурах
— добавили профилировщик мьютексов
— добавили поддержку динамической подгрузки внешних модулей (ака плагинов)
— улучшили поддержку http/2.0 и tls
— добавили sort.Slice, с помощью которого можно сортировать данные в одну строчку

Очевидно, что ничего не поменяли за полгода с момента выхода go 1.7 — просто переименовали go 1.7 в go 1.8 :)

— добавили sort.Slice, с помощью которого можно сортировать данные в одну строчку
github.com/...inikh/go-simple/issues/27
Пффффффф. Next level killer feature.
А вы говорили generics нужны.. Ещё пару версий и будет совсем как скала из коробки.

Иными словами добавили динамический подгрузчик модулей, http 2 и sort.slice — все равно печально

Да, унылые улучшения. Не то что implicit function types в scala. Интересно, сколько человек асилит прочесть до конца этот блогпост от автора Scala и какой процент из них поймет, о чем там речь?

Домохозяйки с волнением ждут filter в одну строчку кода в новой версии Golang.

Да, унылые улучшения. Не то что implicit function types в scala.
Та норм улучшение, позволяет еще больше сократить количество кода, оставаясь в рамках статической системы типов.
Интересно, сколько человек асилит прочесть до конца этот блогпост от автора Scala и какой процент из них поймет, о чем там речь?
Для тех кто не знает скалу и что такое имплиситы, очевидно что будет непонятно. Для тех кто знает — там нету ничего особо сложного.

Если кому-то не понятны имплиситы, он может обойтись без них. Но человек применяющий скалу на практике довольно быстро разберется, что к чему.
А для Go уже появилась толковая IDE с возможностью дебага?

Люди бывают разные, наверняка есть и такие которых описали вы. Но зачем писать код медленнее если можно писать быстрее используя нормальный инструментарий. В строго типизированных языках ИДЕ всегда даст прирост производительности кодера по сравнению с блокнотом.

фича иде, не столько в помогании написании кода, сколько в помогании читания кода. Быстро понять что в данном куске кода откуда берется — многого стоит.

Как по мне С ничем не лучше структурирован, чем джава. Но суть не в этом я себе не могу представить минусы дебагера и IDE, а вот плюсы есть даже для Python. Сознательно отказываться от IDE глупость, возможно это допустимо на определенных этапах обучения. Элементарно статический анализатор поможет выявить ошибки на раннем этапе, а не при компиляции или в рантайме и не стоит забывать про средства рефакторинга

Хз, мне чет казалось что настояшим любителям vi скала гораздо предпочтительней чем С/Go/Python/etc.
Ибо то что в го нужно усердно пичтать 20 строк кода, в скале делается в одну строку.

Значит, под vim на go пишут графоманы :) А если серьезно, то код пишется один раз, а затем читается сотни раз во время расширения функционала, отладки ошибок или рефакторинга. В go для этих операций достаточно vim+ctags+grep. А вот для scala уже требуется мощная IDE.

Также при программировании на go без ide существенно выше продуктивность благодаря тому, что программы на go компилируются за секунду, в то время как аналогичные программы на scala — минимум за минуту. Без ide легче допустить различные описки, приводящие к ошибкам компиляции. Но на go они моментально выявляются во время быстрой компиляции.

Также при программировании на go без ide существенно выше продуктивность благодаря тому, что программы на go компилируются за секунду, в то время как аналогичные программы на scala — минимум за минуту. Без ide легче допустить различные описки, приводящие к ошибкам компиляции. Но на go они моментально выявляются во время быстрой компиляции.

На скале для этого есть консоль которая позваляет быстро проверить код без компиляции и выполнения.

что такое «Нормальный редактор» ?

макросы понятно, что такое

регістрів, кілбаферів
понятия не имею.

В идие много похожего есть:
-буфер копи пейста, нумерованные букмарки в коде, скоупы для открытых файлов, скретчи просто для кучи. В скале скретчи совмещены с воркспейсом — оно сразу кусок кода компилирует и эвалюирует как в скала консоли.
Макросов нету, да. Ну и клавиши отличаются.

буфер копи пейста

Один? В том и дело, что в emacs их неограниченно. Даже в vim их дофига (по количеству латинских букв). Реально я никогда более 2 одновременно не использовал, но 2 вместо 1 — это колоссальная прибавка к удобству.

типа скалу нельзя без иде писать.

Можно, я иногда пользуюсь шелом, если нужно написать 10 строк кода для проверки.

У нас народ полноценно разрабатывает в vi/emacs/atom
Но лично я не особо понимаю этих людей.

Після років у vim, завчених моторних навичках для кількох швидких операцій, дуже тяжко без цього у інших IDE. З горем пополам є плагіни Vim для Atom та Idea.
А про Vim є стаття, яка оце от пояснила, чого ті придурки юзають Vim

www.viemu.com/a-why-vi-vim.html

і ще одна докладніша

Your problem with Vim is that you don’t grok vi.

stackoverflow.com/...-with-vim/1220118#1220118

Че там небось структуры выпилили с интерфейсами и дали возможность все делать на примитивах, для одаренных?

ассемблер наше все! быстрее ничего не будет

Да, поэтому в «следующая ступень программисткой мысли» по всей видимости сведется к выпиливанию всех типов данных кроме byte[] - размер мануалов на стандартной либе будет урезан процентов на 50%, а у Гошников есть все, что им надо что бы эффективно работать и не острелить себе ногу.

от вы ржете а я слышал про людей что так на java пишут

Разработчики go с вами полностью согласны — golang.org/doc/asm

Нет. Сделали возможность писать как в плюсах последних: а ну, угадай язык программирования по исходнику.

Исходник очень лаконичен, не смог обнаружить ни начала ни конца программы,полагаю это го.

Отлично. Можете пряник взять с полки, нашли письмо за 2011 год.
codahale.com/the-rest-of-the-story

є тільки один Дональд, а це якась лєвізна

получается, что они не осилили, ни то. ни другое)) двойной фэйл)

В 2011 году go еще не вышел в релиз, поэтому они вернулись со scala на java. Сейчас небось уже на go сидят.

на java вроде
вообще откат на java стал сильно чаще как 8ка вышла

А вот я не понимаю, еси уже откатываться, то почему не котлин? К жабоэкосистеме не причастен, посему моя не понимать. У жабы 8 таки функции первого класса высшего порядка ужасны.

Котлин рискованней, и бенефиты не столь очевидны (перед 8-кой).

отлин рискованней, и бенефиты не столь очевидны (перед 8-кой).

А в чем риски-то? Бенефиты, как раз, очевидны. Нормальные функции высшего порядка и type inference, чтобы не писать монстров, как в жаба 8. Код, в общем случае, получается более короткий и элегантный, чем на жабе, чем-то приближается к скале по красоте.

А в чем риски-то?
Риски после скалы, нород думает как бы чего не вышло, и зачем оно надо.
Вообще рекламы-маркетинга пока не особо хватает.

Их микрософт купил и им стало ничего не надо :)
Вот обрывочные сведения: www.quora.com/...ology-stack-behind-Yammer

Так то некрафилить уже просто некрасиво, фу.

making.duolingo.com/...duolingos-engine-in-scala

Просто чтобы не складывалось впечатление, что со скалы лишь уходят. Само собой, рефакторинг архитектуры сыграл свою роль, и с ним не так сильно важно, куда именно двигать.

Там на протяжении всего поста чувствуется, что его писали люди, недавно заболевшие скализмом головного мозга. Надеюсь, болезнь не безнадежна и скоро они осознают, во что вляпались. Ждем еще один пост о переходе на go от ниасиливших scala.

ну скорей всего это у вас какая болезнь головно мозга, раз вам так покоя она не дает, может быть вы латентный скалист ? или у вас просто не получилось выучить скалу ? и теперь обиду держите ?

P.S Скалисты используют скалу как инструмент, а не как объект срача на форумах. Того же и вам желаю с го

Зачем тратить драгоценное время на изучение scala — мертвой ветви эволюции языков программирования?

— scala — очень сложный язык программирования, который многие не могут асилить

— при программировании на scala 90% времени тратится на ментальную маструбацию вида «как бы тут посложнее запутать код, чтобы меня считали гуру scala» или «какой из сотни возможных вариантов лучше использовать для данного участка кода?» и только максимум 10% времени тратится на собственно написание кода

— в большинстве случаев код на scala получается сложным для понимания и дальнейшего сопровождения

— программы на scala компилируются вечность

— прогоаммы на scala обычно получаются тормозными и жрущими память

— при деплое программ на scala нужно заливать на сервер сотни левых зависимостей. И не дай бог ошибиться с версией хоть одной зависимости (привет, jar hell и jvm hell)

— в большинстве случаев невозможно перевести программу на scala с большим количеством внешних зависимостей на новую версию jvm/scala. Для этого нужно дождаться, пока авторы всех зависимостей соизволили портировать их на новуб версию scala/jvm. А это на практике малореально.

— scala — очень сложный язык программирования, который многие не могут асилить

Т.е. то, что часть из вайти в айти — хомо эректус, неспособные думать, а способные только копипастить — это пробелма языка? Мне ваш дискурс очень напоминает дискурс иосеров: (обжс против обжс с синтаксисом свифта против свифта, как надо). Во время одного из моих срачей те же самые аргументы, как и вы, приводили фанаты свифта, которые свифта-то толком и не знают и не используют возможности языка.

— при программировании на scala 90% времени тратится на ментальную маструбацию вида «как бы тут посложнее запутать код, чтобы меня считали гуру scala» или «какой из сотни возможных вариантов лучше использовать для данного участка кода?» и только максимум 10% времени тратится на собственно написание кода

Я, конечно, понимаю, что в Го других вариантов, кроме ХХП нет, т.к. парадигма языка такая, но в абсолютном большинстве других языков таки сначала думают, а потом делают, а не копипастят код повсюду.

Заметьте, вы свободу выбора в решении задачи выставляете, как минус. Т.е. тот же С++ или лисп тогда, в вашем понимании — это вообще ад, т.к. возможнотей-то там поболе будет, чем в скале.

— в большинстве случаев код на scala получается сложным для понимания и дальнейшего сопровождения

Только для вайти в айти. Дял всех остальных один раз выучить мат. операции над функциями не составляет особого труда. Арифметику же как-то осилили?

Заметьте, вы свободу выбора в решении задачи выставляете, как минус. Т.е. тот же С++ или лисп тогда, в вашем понимании — это вообще ад, т.к. возможнотей-то там поболе будет, чем в скале.
Да

пару уточняющих комментов

— scala — очень сложный язык программирования, который многие не могут асилить

Это действительно так. Корень зла в том что можно вполне продуктивно писать полностью не осиливая, а используя небольшой сабсет фичь. Проблемы начинаются когда приходиться иметь дело с кодом который использует продвинутые фичи. Так все статьи про перешедших на го какраз из за этого.
при программировании на scala 90% времени тратится на ментальную маструбацию вида «как бы тут посложнее запутать код, чтобы меня считали гуру scala» или «какой из сотни возможных вариантов лучше использовать для данного участка кода?» и только максимум 10% времени тратится на собственно написание кода

Не «по сложнее» а наоборот «по элегантнее», изучая более продвинутые фичи и альтернативные подходы к написанию кода, старый свой код начинает видится как некрасивое овно. Потому местами нород тратит время на переписывание. Про 90% времени, конечно бред.
в большинстве случаев код на scala получается сложным для понимания и дальнейшего сопровождения
См пункт 1.
программы на scala компилируются вечность

Вопрос кривости рук настройки сбт и репозиториев. У нас одно время тоже «компилировалось вечность», пока какойто умник не сделал локальный прокси на репозиторий либ. Все вдруг полетело. Тоесть время не самой компиляции было длинным а скачиванием либ. Сейчас компиляция и запаковка модуля сноля занимает чтото типа минуты. И секунд 20 иннкрементал. Дольше чем джава и го, но никак не «вечность».
прогоаммы на scala обычно получаются тормозными и жрущими память

Вообще да, возможность написать одной строчкой кода то что в го занимает экран имеет свою цену. Цена заключается в куче неявных выделений кучи анонимных классов. Однако имея мозг на плечах, вполне можно ситуацию поправить в тех местах где это нужно. В крайнем случае можно всегда кусок кода на джаве написать.
при деплое программ на scala нужно заливать на сервер сотни левых зависимостей. И не дай бог ошибиться с версией хоть одной зависимости (привет, jar hell и jvm hell)

Проблема с зависимостями таки есть, однако про чтото кудато заливать на сервер — первый раз слышу. Все зависимости указываються в билд файле, и потом билд система все пакует в один архив, никуда ничего специально заливать не нужно.
— в большинстве случаев невозможно перевести программу на scala с большим количеством внешних зависимостей на новую версию jvm/scala. Для этого нужно дождаться, пока авторы всех зависимостей соизволили портировать их на новуб версию scala/jvm. А это на практике малореально.

Перевести на новую версию jvm — вооще бред какойто, без каких либо проблем все переводиться , и всегда переводилось, жвм изначально делалась совместимой, чего не скажеш о других системах.
Переводить на новую версию скалы — да есть проблема, с либами. Но не так малореально, народ таки по чуть чуть переводит основные либы на новые версии скалы.
Перевести на новую версию jvm — вооще бред какойто, без каких либо проблем все переводиться , и всегда переводилось, жвм изначально делалась совместимой, чего не скажеш о других системах.
Если все так радужно с обратной совместимостью разных версий jvm, почему многие проекты до сих сидят на java 6 и java 7, в то время как java 8 вышла несколько лет назад? Да и каждая версия scala, насколько я знаю, намертво привязана к конкретной версии java. Где-то недавно читал, что новая версия scala наконец-то перешла (или собирается переходить) на java 8.

В go с этим проще — вот неделю назад вышел go 1.8 — и все желающие уже перешли на него, т.к. для этого достаточно перекомпилировать проект новой версией go. Менять ничего не нужно ни в своем коде, ни в сторонних библиотеках.

почему многие проекты до сих сидят на java 6 и java 7, в то время как java 8 вышла несколько лет назад?

Код скомпилировный для джавы 6 будет успешно работать и на 8-й джвм. Не переходят потому что не хотят переходить, бояться лямбд, новых фичь, и стабильности новой платформы вообще.
Да и каждая версия scala, насколько я знаю, намертво привязана к конкретной версии java
Ноуп.
Где-то недавно читал, что новая версия scala наконец-то перешла (или собирается переходить) на java 8.
Имелось ввиду юзать новые фишки жвм которые ускоряют производительность.
Оно все обратно не совместимо — код скомпилированый 8-ой джавой не будет работать на 6-й джвм. Со скалой тож самое, если она таргетит 7-ую джвм, то на 6-ой джвм код работать не будет, но он прекрасно будет работать на 8-ой джвм.

С самой скалой однако есть проблемы, код скомпилированый под 2.10 не будет нормально работать с кодом скомпилированным под 2.11

Не переходят потому что не хотят переходить, бояться лямбд, новых фичь, и стабильности новой платформы вообще.
Ну вот видите, а в Go — бояться вообще нечего, преимущества очевидны.
В go с этим проще — вот неделю назад вышел go 1.8 — и все желающие уже перешли на него, т.к. для этого достаточно перекомпилировать проект новой версией go.
Це каже лише про косметичні зміни в релізі.

Угу. Правильный язык программирования при выходе новой версии компилятора требует чтобы все все переписали заново. :)

Если для вас следующие изменения в go 1.8 являются косметическими, то ОК:

— уменьшение задержек GC с десятков миллисекунд до сотен микросекунд;
— увеличение производительности скомпилированных программ до 30%;
— уменьшение времени компиляции программ до 20%;

Так, це, як на мене, фапання на хайп. Це таке собі ментальнодрочерство. Все дуже просто, ви не отримуєте щось, що зможе істотно поліпшити ані ваш код, ані його підтримку. Вам пропонують пограти в гру «хто швидше відріже собі палець». Наче й переможець є, але якось без кінцівки не дуже зручно тепер.

Ці всі відсотки «перемоги» — виключно маркетинговий хід. Він дуже ефективно працює на напівсліпих фанатів, тому що вони будуть носитися з цими безглуздими цифрами як дурні зі ступою. Через деякий час в фанів настане прозріння, але ринкова доля вже буде захоплена. Історія з хромом повторюється, тільки тепер в його ролі go.

Если вы не понимаете бенефитов такого подхода, это не значит, что их нет.

Вообще говоря, что С в свое время, что Го сейчас отодвигают индустрию на эпохи (с тз computer science) назад. И это печально.

Вообще говоря, что С в свое время, что Го сейчас отодвигают индустрию на эпохи (с тз computer science) назад.
Почему? Наоборот, благодаря С и Go на свет появилось много полезных программ, которыми все ежедневно пользуются.
Что, по вашему мнению двигает индустрию computer science вперед?
Что, по вашему мнению двигает индустрию computer science вперед?

Індустрія і computer science це дещо ортогональні речі. Індустрія сама по собі, наука десь далеко попереду (але частіше збоку від неї).

Вообще говоря, что С в свое время, что Го сейчас отодвигают индустрию на эпохи (с тз computer science) назад. И это печально.
Go — это движение в принципиально другом направлении, там реализованы подходы, поощряющие новые более перспективные практики программирования, новый взгляд на решение задач. Прежде всего, это параллелизм «из коробки», чего нет больше ни в одном промышленном языке. Современные процессоры не могут наращивать производительность до бесконечности повышая тактовую частоту и оптимизируя ядро, движение может происходить в сторону увеличения количества ядер. А значит жизнь требует новых подходов в программировании, более удобных для разработки многопоточного софта, в то время как во всех остальных промышленных языках приучили к «однопоточному» мышлению при написании софта. Go как раз решает эту проблему и открывает новые горизонты.

«параллелизм из коробки» (из либы) сделан много где. Сейчас не 2000 год, все-таки. Корутины — чуть ли не единственное, что мне в Го нравится, к слову. Хотя будь они сделаны отдельной либой, нравились бы больше.

«подходы, поощряющие новые более перспективные практики программирования» — это какие? Вездесущие «if nil == nil then return nil» ? о_О

А что не нравится — абсолютное отрицание всех идей, что появились после 70-х и перекладывают ответственность с программиста на компилятор, улучшают читабельность и поддержку (nil? generics? immutables? copy-paste-as-first-citizen? error handling? FP concepts?).

Проводя аналогию с цитатой Форда про автомобилей и коней, Го — более быстрая лошадь, и этим он тормозит развитие автомобилей, оттягивая ресурсы.

Прежде всего, это параллелизм «из коробки», чего нет больше ни в одном промышленном языке.
Erlang, не не слышали ?

Ну вот это как раз 2-ой язык. Правда тут есть нюанс, что существует более 30 лет, и за это время заметного роста использования в проектах — не было. Возможно, из-за отсутствия поддержки и продвижения софтверным гигантом, а также не алголоподобным синтаксисом, получившим наибольшее распространение.

Проблема не в продвижении, проблема в моде.

Думаю синтаксис не исправил бы проблему

гоубои уже выяснили почему в соседнем топике в рейтинге языков го набрал целых 0.79% и занял почетное хрен знает какое место?

В этом топике четко прослеживается тенденция последних лет — доля go стремительно растет за счет доли scala.

Попробовал Atom, Visual Studio XCode c плагином для Go и Gogland от JetBrain.
Gogland от JetBrain лучше всего на сегодняшний день. Eclipsе не рассматривал, потому что плагин для Eclipse разрабатывал то же JetBrain.

Кстати, вот наткнулся на такой видос — www.youtube.com/watch?v=ic8ul45oBCc — и стало интересно следующее: разраб сего чуда (jgo)... смог ли он осилить и скалу, и го? или не смог осилить ни того, ни другого (ибо хз, развивается ли данный проект или нет...)? :-)

Кто что знает-думает по этому поводу?)

Выглядит как попытка скрестить ужа с ежом :) Вот их репозиторий на github — github.com/thomasmodeneis/jgo .

ну исходя из того, что проект не разрабатывают уже года два, то можно сделать вывод, что разрабы ниасилили ни скалу, ни го, а посему забили на проект)))

В полку ниасиливших Scala прибыло — movio.co/...blog/migrate-Scala-to-Go .

Недостатки Scala из статьи:
— медленная компиляция
— медленный деплой
— бессильность grep’а перед синтаксисом Scala
— сложность языка
— неадекватное коммьюнити, больное функциональным программированием головного мозга

Преимущества Go из статьи:
— простой в изучении (2 недели на изучение Go против полугода на понимание основ Scala)
— короткая и ясная спецификация языка
— легко читаемый код
— быстрая компиляция (пару секунд для кода на go вместо двадцати минут для кода на scala)
— программы на Go быстрее работают
— программы на Go требуют меньше памяти (our average Go docker container is 16.5MB, vs 220MB for Scala, we’ve had a major success when rewriting a crucial µs from Scala to Go and going from 4G to 300M for the worst-case scenario usage)

Классные цитаты из статьи:

What I would have done differently four years ago is use Java and not used Scala as part of this rewrite. [...] it would take an engineer two months before they’re fully productive and writing Scala code
It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala. In contrast, we picked up ‘Go’ in two weeks
No map, no flatMap, no fold, no generics, no inheritance... Do we miss them? Perhaps we did, for about two weeks.
As it turned out, more flexibility led to devs writing code that others actually struggled to understand.
It’s not just the fact that channels and goroutines are cheaper in terms of resources, compared to threadpool-based Futures and Promises, resources being memory and CPU. They are also easier to reason about when coding.
Perhaps the fact that makes it simpler in ‘Go’ is that there’s usually one limited set of tools to work with, which you use repeatedly and get a chance to master. With Scala, there are way too many options that evolve too frequently (and get superseded) to become proficient with.
Скала в режиме «улучшенная джава» учится за одну неделю максимум. Никто не заставляет учить теорию категорий и писать все с использованием scalaz.

Неделя это для каких-то совсем основ, дальше идут куча неочевидных и редкоиспользуемых (для джавистов) фичь. Проблема возникает когда какойто умник прочитал про фичу, и начал ею пользоваться, другой чел, который фичу или такое ее применение не знает — код сходу не поймет ъ.
Скала в режиме «улучшенная джава» учится за одну неделю максимум.
имхо, в режиме «улучшенная джава» лучше учить не скалу, а котлин) вот его-то (по крайней мере базовые вещи) думаю точно за неделю можно выучить) ну или груви)
Если отсутствует нeнависть к динамической типизации, то я бы советовал поиграться с Clojure/ClojureScript
плюсую) плюс добавлю, «если отсутствует ненависть к скобочкам» :)

ну я имел ввиду «лисповый характер» скобочек, а так да. =)

Извините, но чесно говоря, вы уже подзадолбали. Евангелизм это явно не ваше.
Если до того времени как я увидел, ваши посты, у меня было желание посмотреть в сторону го, то сейчас этот язык вызывает только одно отвращение, благодаря вашим стараниям и хайпа в интернете.

— Вам не казалось что мерят популярность языка, первая версия которого вышла в 2003 году, по количеству написаних библиотек, довольно тупо. Так как большинство уже давно написано, и развивается. В отличии от го, где экосистема еще только растет + да и не стоит умалчивать про проблемы с пакетными менеджерами.
— Замеры в интернете, который показывают пинг-понг между горутинами и особенно хайп вокруг gc, просто уже задолбал. Вам не кажется что те цифры что вы называете, в продакшене будут немного поумеренней, из-за наличия все таки полезной работы. А чудо-gc, вызывает только одну улыбку, да бы любой человек понимающий немного о gc, знаем что ничего не дается бесплатно, если есть перевес в сторону коротких задержек, значит будет ограничение в пропускной способностью
— Ссылки которые вы скинули с quora, вы их вообще открывали ? Linkedin успешно держить нагрузку на scala, при этом один из инструментов kafka вообще уникальный среди всех существующий брокеров, и он написан на scala.

Вам не приходило в голову, что для каждой задачи свой инструмент. Да ограничений и привязка, только к одному языку, в эпоху микросервисов, это довольно узколобо.

Извините если слишком агресивно, но было бы здорово если бы пересмотрели свои взгляды на продвижение go на dou.
Варианты:
— создать топик «Новости Go»
— еженедельный или месячный дайджест про Go

Картиночки для вброса:
pbs.twimg.com/...C3M9ThVWAAAo3VV.jpg:large
pbs.twimg.com/...C3M9ThVXAAAV7jE.jpg:large

блин, я как раз себе для scala-gopher [ github.com/rssh/scala-gopher ] иконочку думаю нарисовать. Есть ли такое со счастливым сусликом ?

см. мой ответ на идентичный комментарий — dou.ua/...orums/topic/6028/#1056361

Спасибо за идею насчет дайджеста по Go. Нужно попробовать.

Особенно понравилось

— бессильность grep’а перед синтаксисом Scala
Использовать grep для регулярного поиска по коду в 2017, серьезно?

К слову, в тех случаях, когда приходилось грепать, проблем не было. Возможно, потому что грепал я по ключевым словам (проект большой, всего не знаешь), а не по синтаксису.

Дальше сплошные «гиперболы»:

— простой в изучении
Если в бекграунде только QBasic с пхп, то да, Го проще. Если есть хотя бы опыт с Джавой — нет. Какие пол-года?
— легко читаемый код
Уж это точно не плюс Го. Императивная портянка с тонной «if nil return nil».
программы на Go быстрее работают
Просто ложь.
— программы на Go требуют меньше памяти
Ситуативно. И уж явно бредово меряться образом докер контейнера.

Общее впечатление от статьи — 4 человека с бекграундом в бейсике и пхп купились на хайп и начали писать на Скале. Что же могло пойти не так?

Бла-бла-бла без аргументации. А чем подкреплены ваши слова? Может это у вас ложь, простите.

Это про скорость Го против Скалы?
1) Оригинальный коммент именно что без аргументации, просто вброс.
2) На разных бенчмарках они показывают разные результаты. Ну и не стоит забывать, что бенчмарки крайне сложно сделать так, чтобы все остались довольны — например, в сравнении горутин с акка акторами замена последних на футуры сразу выводит скалу в лидеры. Почему-то этот PR не приняли. Я бы сказал, что «в среднем по палате» скорость абстрактного чего-то у Скалы и Го примерно одна.

И уж явно бредово меряться образом докер контейнера.
Размер докер контейнера отражает реальный размер программы вместе со всем необходимым окружением. Как видно из статьи, в среднем программы на go занимают в 15 раз меньше места, чем программы на scala:
our average Go docker container is 16.5MB, vs 220MB for Scala

Также кроме докер контейнера они измеряли потребление памяти при работе программы:

we’ve had a major success when rewriting a crucial µs from Scala to Go and going from 4G to 300M for the worst-case scenario usage

Т.е. после перехода со scala на go потребление памяти снизилось более чем в 10 раз.

Общее впечатление от статьи — 4 человека с бекграундом в бейсике и пхп купились на хайп и начали писать на Скале. Что же могло пойти не так?
Теперь они купились на другой хайп и начали писать на Go :)

Новая статья о том, почему вы должны учить Go — Why should you learn Go?

Там учить особо и не нужно, просто начинать писать

И как всегда неправильное позиционирование

чем горутины лучше Akka? и почему их сравнивают с обычными потоками, а не той же Akka при сравнение со scala или java?

Горутины — это обычные потоки с точки зрения программиста, пишущего на Go. Поэтому они предоставляют основное преимущество программирования потоков перед событийным асинхронным программированием (Akka) — простой и понятный линейный синхронный код, который легко поддерживать, дебажить и расширять.

В дополнение к этому горутины предоставляют два дополнительных преимущества, благодаря которым программа на Go может спокойно работать с миллионом одновременно запущенных горутин:
1) Меньшие накладные расходы на переключение между горутинами, т.к. в большинстве случаев переключение происходит непосредственно в программе на Go без перехода в режим ядра операционной системы, в отличие от потоков.
2) Динамически растущий стек для каждой горутины, начальный размер которого составляет 2Кб. Это в 1000 раз меньше стандартного стека для потоков, размер которого фиксируется при старте потока.

чем использование горутин отличается от использования генераторов/await в шарпе/ноде/питоне?

При программировании на Go не нужно помнить, где именно использовать генератор или поставить await / async / yield — за вас это делает компилятор, который ошибается намного реже среднестатистического программиста.

Ну в том же шарпе компилятор выдает варнинг если вызывается асинхронная функция без await, надо только глазки открывать и читать.

Достаточно сделать бенчмарк, посмотреть на грустные результаты го и сразу станет понятно, чем отличается.

LiteIDE прекрасный редактор и отладчик для Go.

Деякі неофіти нам тут розказували що для го ні ІДЕ, ні дебагер не потрібні — просто пишеш на го, а воно вже без помилок і працює.

Без IDE писать можно не только на Go, и всё будет работать... Но с IDE дебажить несомненно лучше :)

А у мене таке враження що поки Пайк не скаже що ІДЕ і дебагер це добре чи погано гошніки так і будуть ніяковіти при обговорені цих тем.

Видимо Google просто не хочет вкладываться в разработку этих инструментов, тем более что VS они всё равно не догонят. Ну могли бы и плагины для VS намутить.

Видимо, Google платит Microsoft и JetBrains за разработку IDE с дебаггерами. Бюджет же на раскрутку большой — могут себе позволить оплачивать разработку инструментов для Go на стороне.

Как я понимаю плагин для vscode делали не Microsoft, а любители на github. Jetbrains будет продавать свою ide за реальные $ , у языка все же есть своя аудитория.

Как я понимаю плагин для vscode делали не Microsoft, а любители на github.
Только почему-то любители ведут разработку в аккаунте Microsoft — github.com/Microsoft/vscode-go , а большинство коммитов сделано «любителями», работающими в Microsoft — github.com/.../vscode-go/commits/master .
а большинство коммитов сделано «любителями», работающими в Microsoft
Если быть точным, одним любителем, что подтверждает тот факт, что упоротые гоубои, увы, разбрелись по топовым конторам и занимаются херней.

Про успех гошечки в экосистеме MS можете начинать говорить, когда там запилят Go.NET

Про успех гошечки в экосистеме MS можете начинать говорить, когда там запилят Go.NET

вангую, что если найдуться такие разрабы, то они быстро забросят проект, ибо ниасилят ни го, ни си-шарп))))

Про успех гошечки в экосистеме MS можете начинать говорить, когда там запилят Go.NET
Успехом в MS смогут считать, если C# не выпилят, как в своё время, 10 лет назад, канул в аналы истории J#.

Не переписыванием, а созданием параллельной (опенсорсной, кроссплатформенной) реализации (форк). Только вот многие по-прежнему нос воротят. Все им не так )

Там не просто форк. В .net добавляют новые апи которые должны заменить традиционные базовые вещи — работа с буферами, строками, пирсинг примитивов и сериализация — все с нулевыми аллокациями и без копирования. прирост производительности во много раз в Бенчах. Мс достаточно серьёзно занялся вопросом производительности возможностей у языка намного больше чем у того же го. Посмотрим как быстрый гербедж коллектор на го сможет тягаться с дотнетом без аллокаций.

«Пирсинг примитивов» — я не понял, что это, но звучит мощно и внушительно.

например когда надо из байтового массива получить строку в заданной кодировке и из нее получить число.

Все им не так )

Потому что сколько бы они его ни переписывали, остаётся мелкософтом и под винду. Писать и отлаживать на винде, запускать типа везде, но шаг влево/вправо — балдой по лбу.

C# уж больно популярен и в опенсорс он уже перешел.

Ну подсветка и автодополнение — это конечно удобно, но ещё лучше было бы увидеть дебаггер, где можно устанавливать breakpoints, делать пошаговое выполнение, смотреть содержимое переменных. Пока что этого нет, и всё интересующее приходится писать в консоль в рантайме.

Интересно. кто-то юзал/смотрел ранний билд новой IDE-шки для Go от jetbrains — www.jetbrains.com/go ? как оно?

Сам не пользовался — как ниже заметил sanchez, мне достаточно vim + ctags — но другие говорят, что неплохой редактор. Вообще, в прошлом году еще один крупный игрок на рынке IDE обратил внимание на go — microsoft. В результате появился плагин для microsoft visual studio — github.com/Microsoft/vscode-go . Судя по отзывам, очень неплох.
Вся эта возня с IDE для Go среди крупнейших игроков рынка еще раз подтверждает, что язык пошел в массы, в отличие от Scala.

З тими ресурсами, що виділяються на його розкрутку, що хочеш піде в маси...

1) Почему мне ничего не перепало из бюджета на раскрутку go?
2) Где эти люди, которые рекламируют go за деньги?
3) Где эти серверы, выделенные для продвижения go?

Вот-вот, где эти серверы, выделенные для продвижения go?

но другие говорят, что неплохой редактор
я в одном подкасте (Radio-T) в одном из последних их выпусков (вроде в последнем выпуске упоминули) слышал, что Gogland еще сырой. В общем надеюсь, что когда выйдет релиз этой идешки — сделают и Community версию.
В результате появился плагин для microsoft visual studio — github.com/Microsoft/vscode-go
ну это плагин не для IDE, а для редактора.
Вся эта возня с IDE для Go среди крупнейших игроков рынка еще раз подтверждает, что язык пошел в массы, в отличие от Scala
ну для VS Code я видел плагины и для скалы ( marketplace.visualstudio.com/...t=VSCode&sortBy=Relevance ). Думаю плагин для Scala и для Atom’а есть. Поэтому у меня подозрение, что по плагинам и средам разработки Scala и Go идут «ноздря в ноздрю». :)

Вообще Визуал Студию юзать удобнее, чем VSCode. Не понимаю, зачем вообще VSCode нужен, я поставил студию себе на виндовый планшет на базе процессора Atom, и всё отлично работает. Компилирует крупные проекты чуть медленнее, чем на Core i7, но разница во времени не столь критична.

ну для VS Code я видел плагины и для скалы ( marketplace.visualstudio.com/...t=VSCode&sortBy=Relevance ). Думаю плагин для Scala и для Atom’а есть. Поэтому у меня подозрение, что по плагинам и средам разработки Scala и Go идут «ноздря в ноздрю». :)
Прикол в том, что плагин для Go разрабатывается от имени Microsoft — см. ссылку сверху, а плагин для scala — от имени какого-то чувака.

Ну подсветка синтаксиса в визуал студии — и так работает, дальше выполнение команд build, rebuild и clean — настраиваются на выполнение go build, go install, go fmt, и можно удобно работать с проектами, как с обычным кодом C/C++. Разве только точек останова и трассировки нет.

Они мне выслали тестовый билд. Очень понравилось. Jetbrains как всегда на высоте, и после их продуктов ни к чему не надо заново привыкать.

А как получили билд? Заполняли early build форму? Как долго ждали?

Да, там надо на сайте их заполнить форму. Ответили вроде через неделю или две, уже не помню, и прислали ссылку на скачивание.

upd.

Заполнял их форму сразу после резила, ничего не приходило.
Заполнил снова и сразу пришла ссылка на почту.

<mode=av>
Фальшивый блеск и реальная нищета Goʼшного GC.
habrahabr.ru/...mpany/mailru/blog/318504
</mode>

Уже было — dou.ua/...rums/topic/16012/#1042597 . Там же и разоблачение этой заказной статьи (заказчики — адепты Scala, Java и JVM, озлобленные тем, что gc в go на три порядка быстрее их супер-навороченных gc)

Поскольку мой комментарий был удален (абсолютно заслуженно, так как содержал табуизированную лексику) предлагаю такой вариант развития событий erlach.co/pr/62u :-)

Почему не первым? Обидно (
Не совсем понятны критерии отбора кандидатов.

Я посмотрел эту штуку github.com/valyala/fasthttp
Годнота.
Задрочил все на преалоцированых буферах, избегаешь копирований, все правильно сделал
Держи звезду
net/http был аномально плохой, в три раза хуже Erlang.

Google выпустил транслятор из Python в Go — opensource.googleblog.com/...py-go-running-python.html . Ждем транслятор из Scala в Go :)

кто и зачем апнул топик ?)
вместо того, что б допилить один проджект, ушел учить GO поприколу ;) долго держался пытаясь вообще в него не лезть, но некогда приобретенный опыт намекает: что бы не замарачиваться поискам «Мама, я думаю это та самая единственная платформа под которую я хочу кодить до самой старости» и прочими холиварами, проще завести гарем и просто выучить что-то ещё для галочки.

стоны обиженных scalaz и проклятыми функциональщиками, рассказы про то как ’да я уже 7 (семь Карл) лет программирую и прочие стоны обиженых
ой вэй, жестко таки ГОшников erlang-исты, везде где не увидят гоняют, вот они злые такие ;)

да вот пока подсознание пытается научиться филосовски, с пониманием и толерантростью относиться к golang.org/...ef/spec#Type_declarations и golang.org/doc/faq#inheritance , лично я всё-же решил вернуться к основной JVM-рутине, но для «галочки», Go докурю ;)

После Go будет сложно вернуться на JVM, т.к. в Go есть:
— Настоящие first class functions, а не Runnable пародия из Java 8.
— Настоящие интерфейсы, а не пародия из Java, где их нужно явно перечислять для каждого класса, где они реализуются.
— Настоящие горутины, а не Thread-пародия из Java, из-за которой приходится создавать кучу асинхронного говнокода с кучей багов, который сложно дебажить, поддерживать и расширять.
— Настоящие channel’ы с возможностью ожидания сразу на нескольких channel’ах, а не BlockingQueue-пародия из Java.

Также в Go нет бесполезных штук из Java:
— Наследования, которое давно признано худшей идеей ООП.
— JVM&jar hell’а, т.к. программа на Go собирается в один самодостаточный исполняемый файл.
— Тонн бесполезных абстракций с паттернами проектирования.

Коментар порушує правила спільноти і видалений модераторами.

После Go будет сложно вернуться на JVM
это вряд ли ;) Go приходят и уходят, а как enterprise, так и обычный потребитель, всё более и более будет нуждаться в адекватных IT-решениях, однако, лишний раз в этом:
PS Действительно секта какая-то, не поверишь пока сам не столкнешься.
лишний раз убедился ;)

не, с Go разберусь полюбому, ибо язык от бога, но это так, по фану

Это Ритчи можно было богом считать (и он в эту херню не полез), а тут — сборище диверсантов, оживляющих замшелые идеи 70-х.

Еще замшелые идеи 70-х от тех же диверсантов:
— Си, на котором до сих пор пишутся большинство ядер операционных систем и embedded софта.
— unix, благодаря которому сейчас есть linux, android, macOS.
— BSD license, благодаря которой теперь Microsoft входит в топ open source контрибьюторов.

Си, на котором до сих пор пишутся большинство ядер операционных систем и embedded софта.

То-то основной автор Ритчи не захотел участвовать в этом go-безобразии.

BSD license, благодаря которой теперь Microsoft входит в топ open source контрибьюторов.

BSD license никак не их разработка — это требование правительства США, которое не допускало закрытия того, что писалось на госденьги. (Вот нам бы так. Но это по любому не проблема конкретных людей.)

А при чём тут Microsoft?

unix, благодаря которому сейчас есть linux, android, macOS.

Единственное, что хоть как-то можно связать с нынешними авторами. И не имеет к Go никакого отношения.

Что ж, пытайтесь дальше натянуть сову на глобус :)

Еще идеи от диверсантов, разрабатывающих Go:
— unicode и utf8 от Rob Pike
— memcache и livejournal от Brad Fitzpatrick
— Java HotSpot и v8 для js от Robert Griesemer
— re2 от Russ Cox
— современные расширения tls и прочая прикладная криптография от Adam Langley.

Это вам не ангуляры с реактами и ноджсами пилить, которые устаревают, не успев выйти в релиз.

Кстати, tls от go быстрее, чем tls в nginx — blog.gopheracademy.com/...16/tls-termination-bench . Поэтому для веб-приложений на go нет необходимости в tls termination и в nginx/apache/haproxy.

Кстати, насчёт tls. Я на днях решил запилить сервер под https, и вобщем-то с этим никаких проблем не возникло, достаточно заменить ListenAndServe на ListenAndServeTLS, и написать пару параметров. В то время, как для той же задачи на C++ потребовалось бы для начала скомпилировать и подключить либу openssl, причём она так просто с 1-го раза раньше не компилилась, для этого нужны танцы с бубном, потом ещё написать кучу кода. Ну а здесь всё сразу заработало. Проблема только в том, что стандартная библиотека Go поддерживает довольно ограниченное число алгоритмов для генерации/чтения SSL-сертификатов, и так просто любой произвольный сертификат поэтому подставить не выйдет.

Насчет настройки tls в Go есть хорошая статья от CloudFlare — blog.gopheracademy.com/...osing-go-on-the-internet .
В Go поддержка tls на самом высоком уровне — см., например, результаты тестирования одного из наших серверов — overall rating — А . Попробуйте сравнить с каким-нибудь nginx или apache сервером — результаты будут неожиданными.

проще завести гарем и просто выучить что-то ещё для галочки.
С этой точки зрения го какраз бесполезен, ибо он несет ничего нового вообще совсем.
Таже тупая ручная императивщина с сборщиком мусора, вид сзади.
Например ФП принципиально иная парадигма, дающая совершенно иной ракурс на привычные вещи, потому для расширения кругозора ей таки имеет смысл заморочиться.

ФП — для любителей матана, витающих в облаках. Для программистов-практиков оно абсолютно бесполезно.

Немного не соглашусь, фп, правда в своеобразном виде, вполне процветает в последнем ангуляре : )

btw, смотрите какая прелесть: github.com/glycerine/zygomys
лисп компилируемый в го

ФП — для любителей матана, витающих в облаках.
Воно точно не для тих, в кого ООП головного мозку. :D

Гошники презирают ООП точно также, вы шо, там же паттерны, умные слова.

интересно, кто-то из местных использует golang для ML?

Просто предположил, раз go такой быстрый и простой. Библиотеки так-то к нему есть. Комьюнити его обожающее тоже. Вот и любопытно стало. Я кроме веба ещё обработкой текста занимаюсь, хочется в будущем через ML развиваться в этой теме, вот и присматриваю на чем это делать, Python/Scala/плюсы etc. Чисто как бэк голанг мне точно не интересен, мне хватает .net’а с головой.

Я кроме веба ещё обработкой текста занимаюсь
мне хватает .net’а с головой
Аналогично.
Только я сделал небольшое исследование на предмет на чем же писать следующий text processing service. В начале очень уж хотелось запилить порт ntlk на .Net Core- но в итоге понял что проще уж на java веселье устраивать- там есть парочка отличных либ для этого.

А вот на Go я смотрю с не особым доверием. Текущее состояние языка и его развитие и хайп уж очень мне напоминает php в 2000-х

Обидно немного, что на .нетах как-то не развилась активно тема с ML, мне вообще шарп больше всего нравится из всего что пробовал

Кстати, ваш профиль (я смотрел его когда вы отписывались в теме с обработчиком текста на правилах) меня склоняет в сторону указанного в нем стека) Судя по посту 2013 года, когда оценивали технологии, и к чему пришли сейчас, стек прошел испытание временем

Обидно немного, что на .нетах как-то не развилась активно тема с ML,
Да, есть такое.
Мой стек долгое время оставался довольно прост:.Net и разные базы данных.
Еще до того как познакомился с NLP- собирал aлгоритмы со всяких white pages — реализовывал в своём проекте.Вот тут libgen.io нашел довольно много полезного.
Проект прошел довольно эпичный путь. Начинал разработку как обычный новостной агреггатор. (В то время были популярны типа редтрам и других) Даже привлек внимания Microsoft (они тогда набирали в бинг)В итоге запустил свой агрегатор новостей. Случайно упоминул о нем у себя в наработе в Люксе- так потом даже небольшая удитория появилась у аггрегатора.
А позже этот проект уже дорабатывал под финансовые новости/сводки. под заказ для одного крупного инвест банка( я когда -то об этом тут писал) системой даже какое-то время пользовались для тех анализа. но потом заказчик неожиданно купил готовое решение намного более крутое чем было у меня.
Выводы которые я сделал.
+ .Net отличная платформа.
+ C# язык позволяющий вести rapid development
— для NLP не хватает нормальных библиотек- все приходится писать либо самому либо пилить костыли по вызову java программ.
— нет доверия к платформе .Net у заказчиков из финансовой отрасли которые занимаются NLP, ML, AI. Там прочно сидят java, python, Julia, R и другое по мелочи.
— очень на хватало биндингов к всяким биг дата тулам- да и сами тулы в основном на java

Тут долго можно расписывать.
Мне очень нравится идея .Net Core. думаю это даст толчок развитию всего не достающего на .Net платформе. Но после того как я пару недель назад сам пощупал этот .Net core- понял — что он сырой еще от слова- совсем.

Я кстати последние несколько месяцев только на core и пишу бэк. В целом, мне очень нравится, но с инфраструктурой пока тяжеловато — с тем же ef.core приходится иногда очень извращаться. Но на старую платформу уже как-то не хочется.

А чем вообще в последнее время занимаетесь? Поле работ, так сказать

А чем вообще в последнее время занимаетесь
В мае этого года завершил агрегатор online casins and game jackpots comparison and prediction. Опять же использовал всё теже свои наработки по парсеру. Как известно онлайн казино очень редко пишут свои игры- они лишь организовывают площадки для игроков под своими брендами.
Вот тут самое интересное и начинается. Имея аккаунты в нескольких казино и собирая истории игры- можно попытаться предскагзать примерное время следующего джекпота.Это как то более или менее работает. Но тут пришлось конечно повозится с обходом их защиты от ботов.
Получился набор сервисов для мониторинга около сотни онлайн казино. Было интересно — так как выудил что многие грешат созданием рескинов к одной и той же платформе.

За время этого проекта понял что мне не хватает знаний- потому пошел на курсеру. заодно пару сертификатов получил.

Между делом готовился к слудующему проекту- изучал проекты Palantir (точнее крохи которые доступны). Но после того как один из их сотрудников написал в линкедин- типа что ищешь? — я как то даже расстерялся. Как эти рабята узнали что я собираю инфу о них и как меня нашли не знаю. Ну я сейчас нг близко да и по основной работе дел куча

Довольно интересно : ) А какие курсы проходили?

И спасибо за наводку на палантир, будет о чем почитать

мне очень не хватает фундаментальных знаний так как учился в крымском универе где никто и не слышал про computer science. Набив шишек «велосипедостроением» начал шерстить алгоритмы, теорию вероятности, ну всякие структуры данных.
Из того что прошел:

1 Data Structures and Performance
2 Advanced Data Structures in Java
3 Algorithms: Design and Analysis, Part 1
4 Algorithms, Part I by Kevin Wayne, Robert Sedgewick
ну и знаменитый вводный курс Andrew Ng

понял, спасибо)

я вот планирую с этим побаловаться:
fr.coursera.org/...tions/data-science-python

Не Севастопольский НТУ случайно?) У меня детство в Ялте прошло, так половина моих знакомых поступила в Ялтинский менеджмента, а технари в этот севастопольский

да, вот уж мир тесный.
ЯУМ- он самый. Ялтинский Институт Менеджмента как бы сам себя говорит. Я там учился на „компьютерных науках”
В севастопольский заборостроительный по семейным причинам не вышло поступить.

я вот планирую с этим побаловаться
Да должно подойти для начало- хотя мне больше курс Andrew Ng нравится

Вот мой todo список:

  • Data structures: Measuring and Optimizing Performance
  • Object Oriented Programming in Java
  • Java Programming: Principles of Software Design
  • Java Programming: Solving Problems with Software
  • An Introduction to Interactive Programming in Python
  • Principles of Computing
  • Algorithmic Thinking
  • Developing Data Products
  • The Data Scientist’s Toolbox
  • Machine Learning Foundations: A Case Study Approach
  • Data Science Specialization
  • Heterogeneous Parallel Programming
  • R Programming
  • Getting and Cleaning Data
  • Exploratory Data Analysis
  • Reproducible Research
  • Statistical Inference
  • Introduction to Big Data
  • Introduction to Big Data Analytics
  • Java Programming: Object-Oriented Design of Data Structures Specialization
  • Capstone: Analyzing (Social) Network Data
  • Introduction to Recommender Systems
  • Java Programming: Arrays, Lists, and Structured Data(Link)
  • Data structures: Measuring and Optimizing Performance
  • Python Data Structures
  • Machine Learning: Regression
  • Practical Machine Learning

О, приятно встретить кого-то с родных мест. Я сначала каждое лето туда ездил, к отцу, а потом на несколько лет совсем переехал, привет 15-ой школе им. Руданского. А в старших школах ездил чтоб на стройке поздаработать)

Кстати, спасибо за список. У меня два диплома, по одному инжинер-оптик, по другому физик, но как-то лучше всего получалось с прогой (кодил модули под автокады на лиспах, в лабаратории баловался с R, дип.проекты включали разработку ПО, обработку изображений). Увы, изначальную нехватку знаний компенсирую уже второй год постоянным самообучением)

Я успел годик отработать в Промте, занимаются машинным переводом (люблю иностранные языки). Парсерами баловался. Сейчас отошел больше в стандартный стек. Но мне nlp понравилось, так что потихоньку буду прокачивать скилл, пока на пет-проектах.

тут непочатый край ))) нлп — это счас или питон или джава. на джаве простора больше потому что нлп развивается в сторону фрейморков обработки неструктурированой информации типа УИМА и ГЭЙТ а они принимают джава или С++. на питоне остались только ntlk который хорош и развит, но следующий уровень абстаркций пока на нем не доступен. Если джавой не занимались то лучше продолжать питон, джава счас обросла фрейморками которые сами по себе требуют год на изучение. Питон -он очень хорош для парсингов, нлп и машин ленинга.

За УИМА -спасибо. Раньше об этом не слышал.
Пока что присматривался к open nlp и stanford nlp.

Если джавой не занимались то лучше продолжать питон
После шарпа- мне на много проще было начать использовать джава. Питон я смотрел только потому что поддался общему хайпу- что это просто и модно. После того как посмотрел исходники ntlk и обнаружил что он использует stanford nlp — решил окончательно что останусь на Java

это делалось на заказ.
Сервисы это лишь малая часть системы. Насколько я понял там целая инфраструктура развернута с виртуальными пользователями. Короче- этим надо целенаправлено заниматься. Мне больше программирование нравится- и то что за сделанное дело получаешь то на что договорился.

Спасибо, я видел что библиотеки есть, и погуглил на эту тему изрядно. Вопрос скорее в другом: если я хочу развиваться в ML-направлении, есть ли смысл развиваться через go (на самом деле, ответ я для себя уже нашел). Вообще, у меня есть идея через некоторое время попробовать всё-таки golang для простых текстовых парсеров на правилах, и посмотреть как быстро он прошуршит большие массивы текстов

Серьезно, мы здесь сравниваем скалу с го для ML и создания парсеров? Мир кактиться в какоето унылое г.

аээээм, не знаю где вы увидели здесь сравнение скалы и го для создания парсеров, да и для ml

ну я в контексте темы вообще. Даж рассматривать го както несерезно, штоле.

Так я от контекста темы оторвался. Я вот вообще себе нащупываю инструменты и путь на будущее, и задаю вопросы.

Т.е. в моем случае, я имею норм экспириенс с .нетом (ну и всякие там ангуляры), имею инженерный бэк ковыряния с железом и оптикой в лабах и обработкой стат.результатов в R. Имею опыт с обработкой текста/машинным переводом, ну и легкие познания в питоне/плюсах.

Чего хочу: годика через три-четыре хорошо прокачаться либо в nlp, либо в обработку изображений.
Ближайшее года полтора планирую учить общие концепции ML + подтянуть свой мат.аппарат, после чего решить на чем качать специализацию. Как инструментарий: скорее всего python/java(scala).

Да, я не знаю о го ровным счетом них**. Вот мне и интересно, имеет ли смысл его использовать в интересных для меня направлениях, пусть это и парсеры для начала.

я бы вместо ocalm’а уже тогда f# мучал бы, наверное

Мне вот странно почему Erlang не набирает оборотов, точнее его VM, крутейшая же задумка, да и Elixir выглядит уже не так эзотерически, но до психологию прийдется ломать

Він набирає оберти рівно настільки, наскільки може.
Проблема у тому, що Erlang є спеціалізованою мовою, на відміну від універсальних, які обговорюються у цій гілці — Scala, Go, Java.
З самого початку Erlang створювався як мова програмування телефонних комутаторів, яка має мати певні специфічні властивості (в т.ч. процеси-актори та обмін повідомленнями), має певні послаблення (продиктовані динамічною природою мови) і може не мати тих властивостей, які притаманні універсальним мовам (повноцінні рядки, підтримка деяких структур даних і т.п). Пізніше виявилось, що в якості узагальнення комутаторів, Erlang придатний і для програмування серверів, але все ж таки з тими самими обмеженнями, які, до речі, від версії до версії поступово усуваються (в останніх версіях з’явились Map-и — асоціативні масиви).
Якщо ж спробувати використати Erlang для чогось іншого — результати так собі (наприклад, Wings3D).
Щодо Elixir — він з’явився відносно недавно і оберти набирає поступово. Він закриває більшість недостач Erlang-у — структури даних, метапрограмування, але тим не менше, від нього тхне Ruby і оцими незрозумілими штучками, коли навіть прості конструкції викликають питання «а чо так, а не інакше?» (зараз не згадаю, але було щось там з функціями)
На мою думку, на швидкість набору обертів негативно впливає і те, що у Erlang/Elixir
— мала ком’юніті
— мало фреймворків
— OTP, як до сих пір заточена на «хардкорні сервери»
— нема «модного ООП» (хоча це скорше плюс).

А щодо задумок та ідей з Erlang VM — так їх тирять всі, кому не лінь: Akka на JVM, горутини на Go, greenlets у Python і т.д.
Щось таке.

Хорошая новость — Go обошел по популярности Scala в 5 раз:

* 699 проектов на Go с более 500 звездами — github.com/...?q=language:go stars:>500
* 134 проекта на Scala с более 500 звездами — github.com/...language:scala stars:>500

Также обратите внимание на место Go в колонке Languages слева — он уже обогнал C, C++ и Swift и дышит в затылок PHP:

4,567 JavaScript
2,057 Java
1,533 Python
1,279 Objective-C
1,096 Ruby
743 PHP
699 Go
653 C
629 C++
544 Swift

го же использует гитхаб как package store для единственно package managera в языке чего не делают другие языки. Придумай другой критерий популярности.

Покажите сайт, где количество и качество проектов на scala больше, чем на github.

Скоро программисты scala сами для себя неожиданно обнаружат, что стали писать код на Go.

Спустя месяц количество проектов с более 500 звездами на github выглядит вот так:
Go: +22 проекта — github.com/...?q=language:go stars:>500
Scala: +1 проект — github.com/...language:scala stars:>500

Итоговый счет — 22:1 в пользу Go.

Ну вот, 22 программиста уже перешли со scala на golang, а один по дороге заблудился.

Он просто подался в Свидетели Иеговы, что, впрочем, одно и то же.

Результаты специальной олимпиады проекты Go vs Scala с более 500 звезд спустя два месяца:

757(+58) Go
141(+7) Scala

Счет 58:7 в пользу Go. Опережение более чем в 8 раз. Go одерживает сокрушительную победу над Scala как на короткой, так и на длинной дистации.

Все еще сомневаетесь, что CTO, опубликовавший пост о переходе его команды со Scala на Go, поступил верно на 100%?

Блин, это же каким надо быть лузером, чтобы всё ещё до сих пор писать на скале!

Очередной апдейт:

Go — 817 (+60)
Scala — 148 (+7)

Популярность Go растет с каждым днем и уже в 60/7=8.5 раз больше, чем у Scala.

Потрясающе!!! С таким мега-галактическим размахом роста, скоро сообщество Go-программистов будет рассматривать сообщество скалы в микроскоп!

Прошел еще один год. Пора подводить результаты:

Go: 1177 (+420)
Scala: 191 (+50)

Счет 420:50 в пользу Go. Опережение в 8.4 раза. Scala окончательно и бесповоротно осталась на задворках истории.

Scala окончательно и бесповоротно осталась на задворках истории

Всё дело идёт к тому, что программистов scala надо будет вносить в красную книгу. Надеюсь они останутся хотябы в зоопарках.

Как и предсказывалось, в этом году Go уделал скалу по всем позициям согласно исследованию от github:
— go используется в наиболее популярных репозиториях, scala — нет
— 188k vs 70k pull requests
— +93% vs +54% yearly growth rate по pull request’ам

Последний пункт говорит о том, что в следующем году отставание скалы от гоу станет еще существеннее

hsto.org/...741b782bde4b9054ae371.png

а через год все будут писать, только, на swift и typescipt )

После написания кода на Go, решил позаимствовать очень полезную фичу «defer» для разработки на C++. Зачем писать кучу классов только ради того, чтоб выполнился деструктор, когда можно просто задать лямбду, которая выполнится при выходе из блока:

// Go-style defer pattern
class defer {
	std::function<void()> ondestroy;
public:
	defer(std::function<void()> arg) {
		ondestroy = arg;
	}
	~defer() {
		ondestroy();
	}
};
Теперь например после открытия какого-то хэндла, можно просто написать такой код:
HANDLE hFile = CreateFileW(........);
if (INVALID_HANDLE_VALUE == hFile) {
	throw std::runtime_error("Can not open file");
}
defer _file([=]() {
	CloseHandle(hFile);
});
так что вот, фичи из Go перекочёвывают в C++.
когда можно просто задать лямбду

www.boost.org/..._exit/doc/html/index.html

Поздравляю с изобретением велосипеда с 10-летним (минимум) опозданием.

так что вот, фичи из Go перекочёвывают в C++.

Оно было задолго до Go. Учите первооткрывателей, а не эпигонов.

есть такая штука — RAII — очень популярна в c++, советую ознакомиться

RAII в чистом виде чудовищно громоздок, когда действия по зачистке уникальны и приходится на каждое рисовать особый класс с кастомным деструктором. Обрамление в виде boost::scope как раз решает эту проблему ровно столь же удобным способом, как Goʼшный defer.

Go’шный defer выглядит красивее :)

А в go 1.8 он будет еще и быстрее — см. github.com/...66f645536e8031a132cfdf3dd .

Ждем в C++ ужасных в использовании подделок под go’шные горутины с channel’ами и select’ами :)

А в go 1.8 он будет еще и быстрее

Неуловимый Джо.

Ждем в C++ ужасных в использовании подделок под go’шные горутины с channel’ами и select’ами :)

Будут и не ужасные.

Будут и не ужасные.

Сомневаюсь. Достаточно сравнить удобство использования следующих фич в Go и C++:

— Работа с потоками. В гоу все сводится к ’go threadFunc(args)’. В С++ нужно инициализировать и передать кучу левых параметров в функцию запуска потока, сохранить где-то возвращенный дескриптор потока, который еще нужно не забыть закрыть после завершения потока, чтобы избежать resource leak.

— Лямбда-функции. Внутри функции на гоу просто обращаешься к необходимым объектам из родительских scope’ов. В С++ приходится явно перечислять эти объекты с помощью ужасного синтаксиса.

В С++ нужно инициализировать и передать кучу левых параметров в функцию запуска потока, сохранить где-то возвращенный дескриптор потока, который еще нужно не забыть закрыть после завершения потока, чтобы избежать resource leak.

Это не дело языка, но есть библиотеки, которые такое умеют.

В С++ приходится явно перечислять эти объекты с помощью ужасного синтаксиса.

>> [&] captures all automatic variables odr-used in the body of the lambda by reference
>> [=] captures all automatic variables odr-used in the body of the lambda by value

Читайте документацию, ламеры, она рулез.

Это не дело языка, но есть библиотеки, которые такое умеют.
Именно поэтому в гоу для решения большинства задач достаточно стандартной библиотеки, а в С++ для этого обычно нужно подключать кучу сторонних библиотек, большинство из которых такое же неудобное в использовании, как и стандартная библиотека.
>> [&] captures all automatic variables odr-used in the body of the lambda by reference
>> [=] captures all automatic variables odr-used in the body of the lambda by value
Читайте документацию, ламеры, она рулез.

Думаю, не нужно объяснять, к чему может привести использование внешней переменной по ссылке внутри лямбда-функции, которая может быть вызвана после выхода из родительской функции. Для кого эти грабли в С++?

В go компилятор сам определяет, какие переменные должны быть скопированы, а какие — переданы по ссылке внутрь лямбда функции.

Также go сам решает, какие переменные выделить на стэке, а какие — в куче. Поэтому в go следующий код не приведет к undefined behaviour, в отличие от С++:

func f() *int {
    var i = 123
    return &i
}

При желании можно повлиять на решения компилятора, чтобы добиться оптимальной производительности за счет ухудшения ясности кода. Но в большинстве случаев до этого не доходит, т.к.:
1) в типичном коде очнь мало performance bottlenecks, нуждающихся в оптимизации
2) большинство прикладных программ вообще не нуждается в низкоуровневой оптимизации

В итоге код на go получается проще и понятнее аналогичного кода на С++ при сравнимой производительности скомпилированных программ.

Именно поэтому в гоу для решения большинства задач достаточно стандартной библиотеки, а в С++ для этого обычно нужно подключать кучу сторонних библиотек, большинство из которых такое же неудобное в использовании, как и стандартная библиотека.

Спасибо, посмеялся.

Думаю, не нужно объяснять, к чему может привести использование внешней переменной по ссылке внутри лямбда-функции, которая может быть вызвана после выхода из родительской функции. Для кого эти грабли в С++?

Правильно, поэтому есть передача по значению. А сравнивать с языком, который принципиально мультипарадигменный и многоуровневый — показывает только некомпетентность сравнивающего. Вернитесь лучше к наездам на Scala, там они хоть как-то похожи ;)

В итоге код на go получается проще и понятнее аналогичного кода на С++.

Когда на всё, что вылезает за пределы предусмотренной ему ниши, «потребности в колбасе нет» — так и получится. В этой нише.

Во первых не скале, а джаве (хотя сомнений что скала будет хуже нет), во вторых вчистую продул с\с++

больше выглядить как говна хлебнувшие с го

LOL. Чувак же написал «No need for concurrency or high speed here». Как язык Python поприятнее конечно. Честно говоря все же до конца непонятно зачем они изначально переходили на Go в этом кейсе

до конца непонятно зачем они изначально переходили на Go в этом кейсе
Потомучто Aliaksandr Valialkin написал что скоро другой работы не будет?
«No need for concurrency or high speed here». Как язык Python поприятнее конечно.
так все знают то читабельность и поддерживаемость кода в сто раз важнее скорости выполнения, за редким исключением. а го тут уступает почти всем мейнстрим языкам
больше выглядить как говна хлебнувшие с го
теперь-то они разобрались в сортах говна

Пока разработчики scala заняты бесполезными на практике монадами и паттерн матчингом, разработчики go уменьшили stop the world задержки в GC в 1000 раз — с одной секунды до одной миллисекунды — см. как Go помогает писать скоростные чаты для twitch’а

бесполезными на практике монадами и паттерн матчингом
эм... ну насколько я знаю паттерн матчинг — это самая что ни на есть полезная (и очень мощная) на практике вещь) ровно как и монады — без них во многих функциональных языках (таких как хаскель и некоторых других) не было бы возможным программировать интерактивное взаимодействие с пользователем)

правда не знаю, как там с паттерн матчингом и монадами в скале — может там их реализация настолько крива (ведь скала ж смесь бульдога с носорогом гибрид ООП и фунциональщины, поэтому возможно в ней какие-то функциональные фишки может быть реализованы не так хорошо, как хотелось бы), что лучше действильно использовать Go (тем более для чатов, где функциональщину использовать по-моему просто геморно)...

эм... ну насколько я знаю паттерн матчинг — это самая что ни на есть полезная (и очень мощная) на практике вещь) ровно как и монады — без них во многих функциональных языках (таких как хаскель и некоторых других) не было бы возможным программировать интерактивное взаимодействие с пользователем)
Есть альтернативное мнение, что функиональные языки программирования не подходят для решения большинства real world задач. А монады — всего лишь не очень удачные костыли, позволяющие кое-как использовать функциональщину в практических задачах. Это мнение где-то уже проскакивало в комментах к данному посту.
Это мнение где-то уже проскакивало в комментах к данному посту.

dou.ua/...orums/topic/16012/#844902

“И костыли в виде option/either только усложняют и без того сложный код на скале.”

© Aliaksandr Valialkin, 7 січня 11:48

Попытайтесь, хотя бы для справедливого сравнения, понять идеи за концепциями ФП. Сейчас вы похожи на школьника, который кричит, что производные с интегралами — никому не нужные на практике штуки, а он может писать игры/сайты/андроид уже сейчас.

Со своей стороны, я, как и говорил ранее в этом топике, честно потратил пару недель на изучение Го.

Со своей стороны, я, как и говорил ранее в этом топике, честно потратил пару недель на изучение Го.
Неистово плюсую!
Сейчас вы похожи на школьника, который кричит, что производные с интегралами — никому не нужные на практике штуки, а он может писать игры/сайты/андроид уже сейчас.
Так школьник прав — для большинства прикладных задач производные с интегралами не нужны. Как и функциональные языки программирования
то функиональные языки программирования не подходят для решения большинства real world задач.
не стоит все ФП-языки под одну гребенку, ибо функциональщина функциональщине рознь.
Многие ФП-языки (разные Agda, Idris, Coq и т.п.) дейстивтельно предназначены для чего-то узкоспециализированного,
но есть, к примеру, Lisp, который подходит практически для всего (и имеет полноценное ООП, правда отличное от разных джав и си-шарпов), OCaml (который тоже как бы мультипарадигмальный и на котором тоже по идее все, что хочешь можно написать), тот же хаскель.

другое дело, что функциональные языки всегда находились в тени у императивных языков и многие библиотеки в этих языках либо сырые либо их попросту нет (и надо самому пилить, если приспичило). Ну и + большинство программеров привыкли к императивному стилю программирования и просто не понимают функциональный подход, и поэтому могут думать, что функциональные языки какие-то неполноценные.

К подобным мнениям можно прислушиваться пока нет успешных продуктов, а они есть. Я сталкивался с Kafka и Spark(и то и другое написано в функциональном стиле). Я не знаком с GO про этот ЯП нечего сказать не могу, но утверждение выше явно не обосновано.

Я сталкивался с Kafka и Spark(и то и другое написано в функциональном стиле)
Очень сомнительное утверждение про функциональный стиль.

Откуда сомнения? Возможно вы можете открыть исходники на гитхабе и доказать свое утверждение? Предлагаю конкретно спарк.

Пока гошники думают что ни на чем кроме го программировать нельзя, все остальные приспокойнинико на всем остальном программируют, и зарабатывают деньги.

Наивные. Скоро все, кто не знает Go, станут безработными или будут зазывать гоу-программистов фразой «свободная касса».

а я думал вы вытесните пхпшников с дна рынка

Тут вообще неочем даже говорить, какое нафиг вытеснение. Как миними большинство людей знающих скалу знают и джаву. И вы уж поверте даже, если завтра появится язык на котором можно делать все левой ногой с закрытыми глазами и при этом будет получаться идеальный код, то благодоря тоннам кода уже написанного на джаве, джаву по инерции будет держать на плаву минимум лет 5. А вот го в неком промежуточном состоянии из программ которые на слуху слышал только, что докер написан на go.
PS. Вот читаю ваши посты и от них все больше попахивает религией или наркоманией. Как можно во что-то слепо верить и делать категорические выводы не имя для этого весомых оснований

Как видно в большинстве случаев, проекты живут, пока над ними работают. Как только разработка нового функционала прекращается, они вскоре вытесняются с рынка. Говорят, что на коболе написаны несметные горы кода, ну и где это всё сейчас?

Я не застал времена популярности cabol, но логично предположить, что cabol начал терять популярность с увеличением популярности delphi, java, c#. И было — это очень давно. Сотрудник еще 2-3 года назад работал cabol программистом в Укр железной дороге. К томе же подозреваю, что уровень ЗП у спецов cabol в европе/сша довольно высокий.
Вот в вики прочел такие строки
In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software
видимо у такого рода специалистов своя тусовка. Так, что инерция популярности были и продолжалась довольно долго.

тем более для чатов, где функциональщину использовать по-моему просто геморно

Пример чата на самой что ни на есть тру-функциональной скале в 100 строк коду github.com/...ree/master/src/main/scala

Этот чат может обслуживать одновременно 500К пользователей на одном компе с максимальным временем отклика в одну миллисекунду, как вышеупомянутый чат twitch’а, написанный на Go?

чето цыфры мельчают, еще недавно шел разговор о миллионах соединеней, теперь уже всего 500к

Уже были примеры где дот нет по перформенсу разрывает го

Сервер под дот нет наверняка юзает сокеты на портах завершения, а в Go юзаются на эвентах, поскольку кросплатформенный. А на IOCP производительность изначально выше.

.net использует libuv для кросплатформенности и там тоже ивенты.

Our lab runs show that ASP.NET Core is faster than some of our industry peers. We see throughput that is 8x better than Node.js and almost 3x better than Go, on the same hardware.

Что-то они врут. Смотрим последние результаты бенчмарка. У nodejs — 300К запросов в секунду. Значит, у asp.net core — 2.8М запросов в секунду. А у go (fasthttp) — 6.3M, т.е. в 2.5 раза больше, чем у asp.net core.

Токо на первом месте джава.
Апдейт: дот нета я чето там не нахожу

Он так считает бенчмарки:
node.js * asp.net core множитель < Go

Только они почему-то не размещают результаты go в своем репозитории. Боятся опозориться? Пришлось создать тикет. Пока нулевая реакция...

те цифры которые вы приводили в этом (или другом топике), вообще были ни о чем. вы тестировали в основном работу ОС, а это как бы ни о чем.

я как бы не по скале, но мне кажется (посмотрев код), что там используется не функциональгый стиль, а ООП (ну там object есть, что наверное намекает на ооп)... хотя... там есть мапы и паттерн матчинг, так что может быть там действительно ФП-подход.
ну а то что 100 строк — так это из-за того, что поподключали доп. библиотек. :)

1. ООП в скале есть и это хорошо. Просто убрать ООП из скалы было бы глупо, можо такие вещи оставить теоретикам. И в целом функциональный стиль не отрицает ООП, ФП нужно противоставлять императивному стилю, а это в первую очередь минимизация сайд эффектов. То есть функция при вызове с одиними и теми же параметрами, должна выдавать один и тот же результат(состояние).
2. Не совсем так, на джаве кода при использовании тех же библиотек будет существенно больше.

И в целом функциональный стиль не отрицает ООП, ФП нужно противоставлять императивному стилю, а это в первую очередь минимизация сайд эффектов.
ну вообще-то ООП — это и есть подвид императивного подхода) ибо есть два осн. подхода: императивный (процедурное пргограммирование и ООП) и декларативный (функциональное программирование и логическое).

А в целом их действительно не надо отрицать, а лучше комбинировать (применять какой-либо из них в зависимости от задачи).

Не совсем так, на джаве кода при использовании тех же библиотек будет существенно больше.
ну джава насколько знаю язык сам по себе многословный)
есть два осн. подхода: императивный (процедурное пргограммирование и ООП) и декларативный (функциональное программирование и логическое).

ФП, как выше было замечено, имеет только одну цель: упрощение «reasoning about code» (например, минимизация неявных побочных эффектов). Однострочник с map-filter-reduce не является ни необходимым, ни достаточным условием ФП.
Если вдаваться в малопрактичные теоретические дискуссии, то все эти понятия (фп, ооп, императивщина, ...) очень размыты и часто пересекаются, да и часто у участников свои определения.

Скала в первую очередь — ООП язык, и соответствующие стороны развиты куда лучше, чем в той же Джаве. А «функциональный подход» — чрезвычайно удобная именно на практике вещь, которая в итоге снижает ресурсы на понимание и поддержку кода. С оговоркой, что «що занадто, то не здраво» — пришедшие фанатики с «чистых» языков типа Хаскеля используют привычные паттерны, несмотря на их ужасный вид в адаптации (одни трамплины чего стоят). Ну так и ООП-фанатики могут написать сотню классов ради хеллоуворда, чего уж там.

я как бы не по скале, но мне кажется (посмотрев код), что там используется не функциональгый стиль, а ООП

Мда, утверждение из разряда «я не знаю ни ооп, ни фп, ни скалы, но мне кажется».

Но вообще да, фп на скале строиться поверх (а не вопреки) классов и объектов (и еще рада фич, вроде паттерн матчинга и имплиситов). Большущий плюс такого подходу в том, что таки реально разобраться как оно работает и что там происходит. Хаскель всегда выглядел как непонятная черная магия. В скале все понятно стало.

Мда, утверждение из разряда «я не знаю ни ооп, ни фп, ни скалы, но мне кажется».
ну как бы да — я чесно признался. что я не по скале и что не знаю, что и как там реализовывано, и могу только предположить)
Хаскель всегда выглядел как непонятная черная магия.
а вот хаскель я смотрел немного — самые базовые вещи вроде как понятны были (видимо на то они и базовые). А вот более сложный код как по мне тоже выглядит как черная магия (видимо сильно много матана), поэтому я хаскель забросил (не дорос еще)...

з.ы.

«я не знаю ни ооп, ни фп, ни скалы, но мне кажется»
и поэтому, если выбирать между го и скалой, я бы выбрал го)

ха-ха, точно, это ж надо еще так внимательно читать ))

Кстати, а что тогда с jobs.dou.ua/...ertamedia/vacancies/23932 ? В вашей компании, да ненужная функциональщина со Скалой?

А это для того, чтоб гоферам там было лучше кого писать.

А причем фишки языка scala, к внутреностями jvm (GC), за которые отвечают совсем другие люди.
Вот примеры GC’s для jvm c Low-Pause-Time:
— openjdk.java.net/jeps/189
— JVM от Azul c их С4
+ G1 который в jdk9 станет дефолтным

Новость устарела — в go1.8 STW паузы GC не превышают 100 микросекунд на любом размере хипа — news.ycombinator.com/item?id=12821586 . Go уходит в отрыв от тормозных garbage collector’ов в Java, Scala и .Net .

Да с такими тенденциями скоро работа GC в Go начнёт ускорять работу программы и повышать общую производительность системы!!!

Статья ни о чем — в ней утверждаются очевидные вещи:
1) GC в Go проще, чем в Java.
2) GC в Go жрет на пару процентов больше процессорного времени по сравнению с GC в Java.
3) GC в Go по умолчанию требует столько же дополнительной памяти, сколько занято хипом.

Но это никак не может повлиять на факты:
1) STW паузы в Go не превышают 100 микросекунд out of the box на любых размерах хипа, в то время как STW паузы в Java сильно зависят от настроек GC и размера хипа, и в общем случае держатся в районе 100 миллисекунд, т.е. в 1000 раз больше, чем в Go.
2) Объем потребляемой памяти в приложениях на Go обычно в 10 раз меньше объема потребляемой памяти в приложениях на Java и Scala. И супер-навороченные GC не спасают.

А что это за конструкция?
if ident, isIdent := <em>x.(*ast.Ident)</em>; isIdent { (выделил нужное)

Разыменование ссылки на метод класса (в терминах более традиционных языков)? Что-то другое?

Ага, я к вечеру нашёл. Но всё равно спасибо за подтверждение.

Я ниасилю Скалу ибо туп: начал смотреть про pattern matching и акуел ... Зачем все так сложно?

это такой толстый троллинг?

Для вас сделали го, не переживайте

Вот отличная цитата, характеризующая одновременно scala и go:

I have found that all ugly things are made by those who strive to make something beautiful, and that all beautiful things are made by those who strive to make something useful.

Источник — groups.google.com/...c/golang-nuts/lsMy0kRy8zg .

Я иногда думаю: перенесли бы лучше библиотеку Go для C++. Ну так, чтобы на C++ фигнёй меньше маяться.

это точно, все-таки до с++ golangy еще очень далеко.

Во многом согласен, вся кошмарность Go и сосредоточена там, где вместо грамотной пользы пытались на карачках догнать единорога.

Вы все еще сомневаетесь, стоит ли переходить на Go? Тогда мы идем к вам.

Написал на Go одну утилиту, которая делает высоконагруженный расчёт. Раньше этот расчёт был написан на Lua, на Go время расчёта снизилось более чем в 20 раз, и примерно коррелирует с производительностью на С++. Расчёт можно разбивать в несколько тредов, в данном случае на несколько гоуротин, с минимальной синхронизацией данных (через мьютекс). Ну так вот, время расчёта с 1 гоуротиной оказалось минимальным (16 сек), с 2 гоуротинами 18 сек, с 8 около 20 сек. Число процессоров при этом установлено 8, что соответствует камню Core i7. При этом в случае 1 гоуротины загрузка 1 из ядер соответственно значительно возрастала (около 80%), в случае 2 гоуротин — на 2 ядрах, но загрузка при этом падала, на 8 гоуротин — общая загрузка чуть превышала обычную. То есть, распаралеливание не даёт эффекта. Тогда я рабочие гоуротины залочил в LockOSThread/UnlockOSThread, это дало незначительный прирост производительности, но в целом картина осталась прежней. Возможно, если повысить приоритет OS-тредов, тогда загрузка на ядрах возрасла бы, и расчёт происходил быстрее, но я такой возможности в стандартной библиотеке go не нашёл. Вобщем, вопрос: как повысить производительность за счёт очевидного распараллеливания?

Вобщем, вопрос: как повысить производительность за счёт очевидного распараллеливания?
Код под мьютексом не может исполняться одновременно на нескольких ядрах процессора. Судя по описанию, это ваш случай. Решение — избавиться от мьютекса. Или минимизировать время исполнения кода под мьютексом по отношению к коду не под мьютексом.

Код под мьютексом делает только инкремент шарового счётчика, больше ничего. Всё остальное происходит с локальными данными в каждой гоуротине. Причём «удельный вес» расчётов значительно больше инкремента под мьютексом.

Разобрался в сути проблемы. Там всё дело в том, что в некоторых ситуациях счётчик инкрементируется несколько раз подряд, с идущими друг за другом лок/анлок. Если это всё это поместить в одну залоченую секцию, производительность увеличивается. А писали же в мануалах, что залоченый код должен быть минимальным.

А писали же в мануалах, что залоченый код должен быть минимальным.

Так оно и есть — см. en.wikipedia.org/wiki/Amdahl’s_law :


For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour. Hence, the theoretical speedup is limited to at most 20 times (1/(1 − p) = 20).

Лічільник краще через атоміки інкрементувать.

А еще лучше инкрементить батчами — не по единичке, а по сотне, тысяче или вообще один раз во время завершения исполнения потока.

Для этого в Go надо что-нибудь наподобие InterlockedIncrement, или возможность выполнить ассемблерную инструкцию.

Супер, время расчётов сократилось на 8 ядрах в 3 раза! Причём на одном тоже вышел неплохой прирост производительности.

Код под мьютексом делает только инкремент шарового счётчика, больше ничего
Го не может в атомарные операции инкремента? пичальбида

если Го что-то не может — то значит оно и не надо!

Может, я просто не нашёл сразу. Производительность при этом значительно выросла, в том числе из-за сокращения вызовов lock/unlock. Кстати, это не удивительно, но и прямой вызов unlock гораздо производительнее, чем отложенный через defer.

«Недолго музыка играла, недолго фраер танцевал»

Dropbox намучился с go и отказался от него в пользу rust
www.wired.com/...odus-amazon-cloud-empire

А ведь раздача файликов по сети это собственно то, ради чего go изначально и создавался

Жду негодавание гошников о ниасиливших го

Go даже ниасиливать можно в 10 раз быстрее ты чо

И в 10 раз быстрее перейти на другой язык

Это желтая пресса. На самом деле они написали на расте какую-то маленькую хрень. Все остальное осталось на го. Вот пруфлинк. А вот соответствующая цитата:

Actually, full disclosure, we really just rewrote a couple of components in Rust. Most of Magic Pocket (the distributed storage system) is still written in golang.

Также дропбокс не собирается переходить с гоу на раст в обозримом будущем. пруфлинк. Цитаты:

Yup, Dropbox Infra is mostly a Go shop. It’s our primary development language and we don’t plan to switch off any time soon.
Most of the storage system is written in Go and the only two components currently implemented in Rust

Цитата оттуда же про Rust vs Go

Performance is 3-5x better at tail latencies. Cost savings is.. dramatic. I can’t be more specific there.
Сразу вспомнил слова про простой язык, который имеет все что нужно для того что бы работать на старом ноуте. А если что-то не умеет и ложит сервера в продакшине выжираяю всю ОЗУ не поддерживая хвостовой рекурсии, то можно написать и на другом языке.
На самом деле они написали на расте какую-то маленькую хрень
:facepalm:
Performance is 3-5x better at tail latencies
...не поддерживая хвостовой рекурсии...
tail latencies не имеет ничего общего с хвостовой рекурсией. Это лишь означает, что очень маленький процент (под tail обычно имеют ввиду не больше 5%) ответов от гоу сервера выполняется в 3-5 раз дольше, чем в раст-сервере. Скорее всего, такие задержки связаны со stop the world фазой в garbage collector’е. Это может быть следствием двух вещей:

1) Они не оптимизировали свой сервер по потреблению памяти. GC не бесплатный — чем больше объектов находится в хипе, тем больше процессорного времени будет расходоваться GC на сканирование этих объектов. В расте, насколько я понял, GС отсутствует — там ручное управление памятью.
2) Они использовали старую версию гоу (до 1.5), в которой длительность фазы stop the world (STW) в GC линейно зависела от объема хипа. Например, при 10-гиговом хипе она могла достигать нескольких секунд. Начиная с гоу 1.5 фаза STW на 10-гиговом хипе снизилась до 20мс, а в гоу 1.6 — не превышает 20мс при хипе в 256Гб.

очень маленький процент (под tail обычно имеют ввиду не больше 5%)
Кстати, 5% — это совсем не мало на масштабе дропбокса
В расте, насколько я понял, GС отсутствует — там ручное управление памятью.

В раст нет ручнго управления памятью. Там продвинутая система, которая отслеживает жизненный цикл объекта на этапе компиляции и синхронно освобождает его тогда, когда это безопасно

Вроде в расте можно и так, и так (т.е. и вручную, и с помощью упомянутой продвинутой системы).

Значить розробляючи на Go все одно треба практикувати Rust, щоб потім писати статтї і піарити продукт, або ж знати коли дійсно потрібний Rust.

Они до этого писали ещё на пайтоне, тут складывается впечатление, что им как плохим танцорам постоянно что-то мешает.

So, in the middle of this two-and-half-year project, they switched to Rust on the Diskotech machines. And that’s what Dropbox is now pushing into its data centers.

блжаж як так без ЦЕПЕПЕ ?

блжаж як так без ЦЕПЕПЕ ?

намучаются со ржавчиной и перейдут на плюсы

напишеш як перейдуть: «я ж тобі казав»

це навряд, якщо rust зайде і все получиться

rust не простий, але надто багато плюх в подарунок приносить

3 года спустя львиная доля всего бэкенда все еще на Го :) ask me how I know

Latest news: scala+akka в 10 раз медленнее, чем Go с горутинами в skynet бенчмарке. При этом код на гоу простой и понятный, а на скале — черт ногу сломит.
Результаты тестов доступны тут — github.com/...net/blob/master/README.md . Кроме гоу со скалой там есть и другие представители. Некоторые даже быстрее гоу, если судить по бенчмаркам. Только код у них слишком сложный по сравнению с гоу.

При этом там же go в 3 раза медленнее чем async-ы в .NET Core, и в 5 раз медленнее чем Task Parallel Library в .NET Framework. Отакэ.

Вообще, непонятно что они собираются протестить. Код на скале и .net не выдерживает никакой критики. При этом код на го вроде норм, сразу видно что го знают, а другие языки впервые увидели.

а джава еще быстрее оказалась. Вот епты, что ж так, джавы с дотнетами обидели гошечку так...

Это потому что кода на жаве с дотнетом не соответствует требованиям бенчмарка:

Creates an actor (goroutine, whatever), which spawns 10 new actors, each of them spawns 10 more actors, etc. until one million actors are created on the final level. Then, each of them returns back its ordinal number (from 0 to 999999), which are summed on the previous level and sent back upstream, until reaching the root actor.

Жава с дотнетом решили избавиться от такой “мелочи” как actor, и просто использовать хорошо замаскированный рекурсивный вызов фукнции.

Подробности тут и тут.

А зачем нужен какой-то «актор», если код все равно делает то же самое?

И если из-за акторов гоукод тормозит, я не знаю, может можно не юзать акторы в гоу и тогда он не будет сливать джаве?

Один хрен Go так же рекурсию использовал.
Если подитожить Го за счет несоотвествия требования тестам обошел Скалу и слился Java\.NET что использую также рекурсию.

Кстати, проверил у себя

Go: 916ms

.NET:
Sync sec: 0.052
Async sec: 0.414
TPL sec: 0.170

Авторы бенчмарка могли бы запилить что-то нормальное, типа того же сервера, который держит миллион подключений, где синхронная версия бы слила, но вместо этого они сделали то, что делают все гоубои — давайте запустим асинхронно то, что не надо запускать асинхронно, и внезапно для себя обнаружим, что гоу всем подряд сливает.

В итоге миф о офигенной эффективности гоурутинов успешно развеян — банальный синхронный код, как и прежде, решает.

Код на скале и .net не выдерживает никакой критики. При этом код на го вроде норм, сразу видно что го знают, а другие языки впервые увидели.

Может, потому что на гоу проще писать многопоточный код, чем на остальных языках?

Полная ерунда, сравнение, гхм, яблок с кирпичами. Скала версия через Future уделывает Гошный код в где-то три раза. github.com/atemerev/skynet/issues/4. Строго говоря, фьючуры тоже не являются аналогом горутинам, но они ближе к теме, чем акторы.

Акка мало того, что криво использована, так еще и абсолютно не нужна для этой задачи.

Интересная у вас методика пиара Го. Выбирать «правильные» бенчмарки, не разбираться в теме, а затем постить «разоблачения». Вам за это платят, что ли? Если да, то выберите другую стратегию, из-за такого поведения идет скорее минус репутации Го.

Так в свое время доказывали тормознутость ноды, вешали тяжелую синхроную операцию, и говорили что сервер не отвечает, и пример на джаве где эта операция в отдельном треде — результат предсказуем, тест вообще не валиден

нода далеко не самая тормознутая. вообще, все зависит от конкретных нужд и потребностей.
если вы говорите что, что-то тормознутое, то на самом деле это не более чем ваше субъективное мнение, даже если вы сделаете бенчмарк.

ибо, когда говорят о производительности, всегда важен контекст задачи и ее требования, и для какой-то задачи нода может быть быстрее и удобнее го и джавы.

так что это все разговор ни о чем

Набрасываю )

www.ageofascent.com/...llion-requests-12-6-gbps

Scala, go... тут новый ASP .Net Core, который кроcсплатформенный, который компилируется в native, на одной ноде на линуксе обрабатывает в 6 раз больше реквестов чем nodejs, на винде разрыв еще больше — в 7 раз. И это все на няшном, ламповом C#. Таки есть порох..., в верном направлении развернулись в МС, лишь бы не было поздно.

Откуда информа, что он компилиться в натив? Core clr на выходе дает dll даже под маком и требует dnx обязательно. Тесты где-то есть сеть выложены?

он вроде всегда JIT-ом компилился в найтив, что-то поменялось в core?

Если и компилировалось, то как-то через костыли. Они там что-то писали, что сам .net framework устроен так, что очень сложно все слинковать и скомпилить в native. В .net core они изначально заложили такую возможность.

Единственное что напрягает, что .net core это форк .net framework-а. Блин, если в очередной раз все меняете, сделайте уже правильно с нуля, зачем резать .net framework и приделывать костыли? Смахивает на какое-то очередное переходное, временное решение.

Единственное что напрягает, что .net core это форк .net framework-а. Блин, если в очередной раз все меняете, сделайте уже правильно с нуля, зачем резать .net framework и приделывать костыли? Смахивает на какое-то очередное переходное, временное решение.
Опыт ноды показывает, что если запилить нормальную платформу без библиотеки классов, то народ быстро напишет библиотеку классов и заопенсорсит

Что тогда что сейчас компилируется в IL, разница только в том, что в Core это нативный приложе хост, что создает managed domain и грузит в него сборки. Есть куски фреймворка которые не совсем легко сделать кросплатформенными в силу тесной привязки к винде, например credential cache, хранилище сертификатов. О каких костылях речь? Эти сборки пока не будут работать в Core, что-то добавляют по мере развития платформы. Скорее всего их оптимизация заключается в возможности отключать ненужны компоненты, глобально это как был managed процесс С Jit компиляцией так и остался.

Не совсем так. Компилируется все в native, то есть никакого jit-а, а вот рантайм да, пакуется. Все-таки сборщик мусора и managed процессы должны же где-то крутиться. С .net framework-ом толком не получалось такого сделать так как сложно было выделить зависимости и каждый проект тащил за собою чуть ли не половину .net фреймворка. В .NET Core они действительно оптимизировали зависимости, поэтому пакуется только то, что нужно проекту.

Core сбоока выполняется и под маком и под виндой и под линухой. Это уже априори говорит, что там нету native кода на выходе.

А что по вашему происходит с IL кодом на JITе? Чем по-вашему JIT занимается?

Jit выдает платформо зависимый машинный код, это самое большое заблуждение что Core clr можно собрать в сборку, которая будет иметь готовый машинный код. Для компиляции Рослину нельзя указать ни ось и ни процессор собственно и байт код он не генерить, а только MSIL. У мс был какой-то совершенно другой нативный компилятор в разработке для Win RT only. А так это попрежнему часть рантайма и одна из основных причин почему на каждую Ось нужно писать отдельный native host где будет развернут рантайм. Тут поменялось ровным счетом вообще ничего кроме того, что поддержка .NET реализована на уровне executable файла и не требует поддержку на уровне Оси, как есть в винде.

Jit выдает платформо зависимый машинный код

Так в чем проблема нагенерить этот код заблаговременно? Где вообще можно об этом нормально все почитать в контексте .net core? Как-то везде все расплывчато.

Рослину нельзя указать ни ось и ни процессор собственно и байт код он не генерить, а только MSIL.

А рослин тут причем? Как и старый компайлер генерит MSIL для JITа, и больше ничего от него не требуется.

Так в чем проблема нагенерить этот код заблаговременно?
Зачем его вообще генерить заблаговременно?

1. Чтобы не тратить время в рантайме
2. Более оптимизированный машинный код (из-за неограниченного времени на анализ кода, у JITа нет такой роскоши, он должен по-быстрому что-то выдать)

Хотя новый JIT, говорят, быстрый

Так новый «JIT быстрый» или

Не совсем так. Компилируется все в native, то есть никакого jit-а,
я уже запутался совсем в том что тут пишется.

По умолчанию все по старинке — установленный рантайм в системе и приложение в виде менеджед сборок. Ставишь флаг -native во время билда — получаешь одну экзешку с откомпилированным все в нейтив и встроенным рантаймом. Что-то на подобии го. По крайней мере я так это понимаю, не могу найти четкого описания кроме пейперов 2014 года.

Ничего заблаговременно не генериться, генерация машинного кода во время компиляции сделает сборки некросплатформенными это из определения самого термина исходит.

Информации дофига.
github.com/...re/blob/master/roadmap.md
Вот их новый JIT
github.com/...n/botr/ryujit-overview.md

А зачем кросплатформенность для native сборок? По-моему очевидно что компилиться под конкретную платформу.

Откуда такая уверенность ?
.NET native
.NET Native is not so much an “edition” of the .NET platform as it is a set of native build tools for .NET Core. .NET Native is an Ahead-of-Time (AOT) toolchain that compiles IL byte code to native machine code, so that when the code is executed, there is only “native” code running. This means that the resulting binary is what the OS executes; there is no JIT-ing, no runtime compilation. This leads to better performance, as well as some security benefits.

В конце ссылки написано, что это для WinRT инструментарий.

.NET Native is primarily used by .NET Universal Windows Platform (UWP) applications.

Да, вы правы! Накрутил лишнего. Только

WinRT
Для windows 8, а
UWP
это уже windows 10

В целом наброс годный.
В куче с возможностью писать многопоточный код с неблокирующим IO и возможностями оптимизации дотнета, плюшками рантайма в виде тех же generics, использованием стека потока , всем сахаром C# плюс заявленым в 7 версии языка выглядит куда более как node.js киллер чем проблемный Go. :)

Ну у go есть существенное преимущество — мощная библиотека. А тут огрызок от .net framework в виде .net core, и зная Майкрософт, наращивать функционал будут не очень быстро, скорое переделывать будут по несколько раз, как с мобильной виндой.

наращивать функционал будут не очень быстро, скорое переделывать будут по несколько раз, как с мобильной виндой.
Посмотрите на ноду, позорно маленькая стандартная библиотека классов, состоящая из 10 компонентов и тысячи их 3d party модулей выложенных на гитхабе.

Если MS запили хорошую базовую платформу, то весь недостающий функционал сообщество напишет с нуля или портирует очень быстро.

Посмотрите на ноду, позорно маленькая стандартная библиотека классов, состоящая из 10 компонентов и тысячи их 3d party модулей выложенных на гитхабе.
только стоит отметить что половина из них оставляет желать лучшего
только стоит отметить что половина из них оставляет желать лучшего
Большая часть из них это, что то вроде leftpad, на 12 строк кода.

даже они оставляют желать лучшего

Еще одно большое заблуждение. Core Clr может референсить любую сборку собранную под предыдущие версии дотнет ,если она не референсит явно функционал библиотек зависящих от виндовой части фреймворка. Например старый newtonsoft json собранный под. Net 4.6 будет работать под мак и линукс в Core clr. Остальные библиотеки, например зависящие от system. Io при чтении фалововой системы, могу быть легко портированный сменной типов проекта референсов.

В чем заблуждение? .NET Core на данный момент огрызок, и МС сознательно не тянули туда многих вещей из .NET 4.6, так как не могли обеспечить поддержку. То что при определенных условиях можно подключать определенные сборки и молиться что ничего не крякнет в рантайме — никак не влияет на этот факт.

Если Core огрызок, а не самодостаточный фреймворк каких жизненно необходимых компонентов не было реализовано в нем?

Не буду утверждать на 100%, руки к нему еще не дошли, лишь наблюдения из интернета и от самого майкрософта.

Вот с версией под мобильные оси год назад натрахался прилично — вроде и то есть, и се есть, но функциональность по сравнению с полноценным фреймворком, была сильно урезана, что нереально бесило. Подозреваю что тут так же.

Вот с версией под мобильные оси год назад натрахался прилично — вроде и то есть, и се есть, но функциональность по сравнению с полноценным фреймворком, была сильно урезана, что нереально бесило. Подозреваю что тут так же.
На мобилкяах там очень высокоуровневая платформа, поэтому что-то серьезное допилить нельзя, плюс она никому нах не нужна была, так как userbase нулевой, поэтому никто и не пилил ничего.

Core выглядит более обнадеживающе.

Не обязательно

не могли обеспечить поддержку
Есть куда более логические причины.
Discontinued Technology in .NET Core

Ха-хаха. Fasthttp под гоу на моем трехлетнем ноуте обрабатывает 1.3М запросов в секунду от 1К параллельных клиентов, работающих на этом же ноуте. А тут они решили гордиться 1.15М qps на топовом сервере.

Сравнение твоего http listener’a на гоу с ASP.NET вызывает ассоциации, как в известной пословице про х** и палец.

requestHandler := func(ctx *fasthttp.RequestCtx) {
    switch string(ctx.Path()) {
    case "/foo":
        fooHandler(ctx)
    case "/bar":
        barHandler(ctx)
    default:
        ctx.Error("Unsupported path", fasthttp.StatusNotFound)
    }
}
Разработчики ASP.NET и других платформ сильно недооценивают возможности Go с таким MVC..

Хотелось бы увидеть примеры кода на asp.net и других уважаемых платформах, чтобы понять, чем вам не угодил процитированный пример на fasthttp.

Да оно больше ни на что не годится кроме как файлики раздавать. В принципе можно что-то больше делать, но это будет боль и страдания. Может оно и обрабатывает 1.3М запросов в секунду (все-таки канкаренси в го годное), но это на холостом ходу. А подает это так, будто бекэнд твиттера на его трехлетнем ноутбуке может работать.

Сомневаюсь, что они тестировали что-то сложнее, чем hello world application. В таких тестах обычно измеряют производительность сервера, а не производительность обработчика запроса. Поэтому логично использовать что-нибудь вроде return «Hello, world» внутри обработчика запроса.

Кстати, где посмотреть код сервера, производительность которого они измеряли? Вот тут код fasthttp, который выдает 1.3М ответов в секунду на моем ноуте — github.com/...l/src/hello/hello.go#L214 . Можете проверить на своем компе с помощью wrk:

./wrk -t 4 -c 512 -d 10 -s pipeline.lua http://localhost:8080 -- /plaintext 16

Содержимое pipeline.lua:

init = function(args)
   request_uri = args[1]
   depth = tonumber(args[2]) or 1

   local r = {}
   for i=1,depth do
      r[i] = wrk.format(nil, request_uri)
   end
   req = table.concat(r)
end

request = function()
   return req
end

Ты не понимаешь самого предмета тестирования, ASP.NET это не веб сервер, это фреймворк. Если тебе кажеться, что твой http listener обслуживает байтовые массивы фиксированного быстрее чем Кестрел, ИИС или Апач на домашнем ПК — это отлично, можешь попробовать продать эту идею где-то еще кроме ДОУ, но я не вижу что бы даже Go коммьюнити была сильно keen on в твоем веб сервере, даже несмотря на то что ты заявляешь, что он 10 раз быстрее стандартного Go listener’a.
Так же я не понимаю, что ты хочет доказать коммьюнити этими цифрами. То что Go появившись в том же году, что и Node.js со всеми проблемами языка и колбек хеллом преуспела куда больше в рядах веб разработчиков чем перспективный и удобный Go для меня тоже показательно. Веб-разработчики не буду заниматься низкоуровневым программированием и считать байты в циклах, если уж совсем не будет вариантов, те кому нужна производительность так же как и ты смогут оптимизировать под свои конкретные нужды листенер и оптимизировать низкоуроневые операции с памятью, на других платформах с куда более приклекательными языкам.

Покажите пример hello world application на asp.net, чтобы я понял, чем он отличается от fasthttp, который вы почему-то называете не сервером, а каким-то listener’ом. Кстати, чем сервер отличается от лиснера в вашем понимании?

Листенер это и есть веб-сервер. Просто звучит менее гордо в глазах велосипедостроителей.
ASP.NET от fasthttp отличается тем же чем веб-фреймворк отличается от веб-сервера.

ASP.NET от fasthttp отличается тем же чем веб-фреймворк отличается от веб-сервера

В моем понимании веб-сервер — это отдельно работающее приложение, которое умеет принимать и обрабатывать http-запросы, возвращая http-ответы. Веб-сервер может быть написан с использованием какого-нибудь веб-фреймфорка или библиотеки функций, облегчающей написание веб-сервера.

Веб-фреймворк отличается от библиотеки функций тем, что обязывает программиста пользоваться только предлагаемым функционалом ака «каркасом». Хочешь расширить функционал, не предусмотренный создателями фреймворка — пиши кучу хаков и костылей. Которые обычно ломаются в следующем релизе фреймворка.
Библиотека функций не обязывает использовать только функции, предоставленные ею. Программист волен компоновать произвольные функции из других библиотек плюс собственные функции для достижения поставленной цели.

Fasthttp является библиотекой функций. Чем является ASP.NET?

Мне не понятна твоя терминология. Так же я вижу что ты не разделяешь понятие Веб-хоста и Веб-приложения, что уже давно делается на всех платформах.
Я не вижу грани между

Веб-фреймворк
и
Библиотека функций
у том что ты пишешь.
В Асп.нет я могу заменить любой компонент, взять его third party реализацию, могу заменить веб-приложение хост, все что мне надо соблюдать интерфейсы между слоями.
У тебя интерфейсы вообще никак не упомянуты, wtf?
Тебе нужно самом разобраться в своей терминологии раз ты уже сам ее придумал. До этого факт остаеться фактом. Твой
fasthttp
тянет максимум на Веб-хост, называй его хоть библиотекой, хоть операционной системой, сранивать его с АСП.нет пока увы нельзя.

и кстати, если уж речь про это зашла, то asp.net это контейнер для двух противоположных моделей MVC и WebForms, и обе используются параллельно
так что сам asp.net это скорее хост-контейнер, в котором может жить что угодно
но мода на MVC сбивает многих с толку

Посмотрел сорцы твоего гитхаба интересно как ты предлагаешь компоновать функции из других библлиотек с твоим сервером если у тебя внутренние абстракции сплошь и рядом точат наружу.. server, requestContext, request, response -интерфейсы которые надо соблюдать.

В ASP.NET это выглядит чуть более продумано и есть единственной зависимостью, которую нужно соблюдать между слоями и библоитеками и даже другими фреймворками для полной совместимости.
owin.org
Выглядит намного более долговечно чем куча библиотек, которые нужно компоновать адаптерами, если захочеться сделать что-то кроме как раздавать байтовые массивы фиксированного размера, не находишь?

Посмотрел на этот owin.org и пришел в недоумение. Все, что там описано — SendFile, WebSockets, Opaque streams — присутствует в fasthttp искаропки. Не понимаю, причем тут байтовые массивы фиксированного размера — fasthttp поддерживает произвольные http-ответы. Читайтее внимательно документацию.

Лучше расскажите, как с помощью asp.net сделать следующие вещи:
— принимать запросы с произвольного количества TCP портов.
— принимать запросы с Unix sockets.
— принимать запросы из произвольного файла.
— добавить поддержку шифрования соединений, отличную от ssl (tls).
— ограничить входящие подключения на основе произвольных правил (ака anti-DoS).
— обрабатывать запросы из произвольного байтового потока.
— собирать произвольную статистику по входящим запросам и/или подключениям.
— реализовать одновременно все вышеперечисленное в одном веб-сервере.
Fasthttp позволяет делать это элементарно.

ололо. Конечно поддерживает, у тебя веб Http сервер, а это расширения Http протокола
:facepalm:
Только вот если какой-то чел на гитхбае написал либу для WebSockets или может быть напишет поверх твоего http это не совсем из коробки и не совсем поддерживает, если ты конечно не собераешся саппортить и их косяки. Ну это уже мелочь с таким крутым листенером.

В целом не думал что такой матерый серверо строитель не различает понятия протоколов Application\Trasport Layer. И прочитав тех документ не поймет о чем в нем речь. Owin — спецификация с абстракциями для Application Layer протоколов.

Зы: Я правда предполагаю, что существующие ASP.NET сервера врядли поддерживают такую первой необходимости штуковину как Unix Sockets при разработке Http приложений. :) Можешь гордиться своим мощным веб-сервером! Ведь не за горами то время когда на .NET Core без обилия библиотек понабегут фрики с гитхаба и начнут запиливать кучу сомнительных фич для своих эксклюзивных веб-серверов и бибилотек.

Вообще-то unix sockets вовсю используются веб-серверами для проксирования запросов на локальный сервер, чтобы избежать накладных расходов и ограничений, связанных с TCP. Под винндой они тоже есть и активно используются, только называются named pipes.

Pipes все же не unix sockets и отсуствие их поддержки так же очевидно для меня(крослпатформенный ASP.NET пока еще в стадии RC)
я был не прав в своих предположениях в предыдущем посте. в kestrel добавлены unix sockets.
github.com/...trelHttpServer/issues/156
Все это к ASP.NET имеет мало отношения, потому что это транспортный уровень веб сервера. К чему ты вывалил список транспортных особенностей твоего сервака, риплаем на документ о Application level абстракциях внутри приложения мне по прежнему непонятно. Обьяснишься?

То что Go появившись в том же году, что и Node.js со всеми проблемами языка и колбек хеллом преуспела куда больше в рядах веб разработчиков чем перспективный и удобный Go для меня тоже показательно.
Node.js набрал популярность среди неквалифицированных разработчиков по тем же причинам,что и PHP — на нем легко наговнокодить, не соображая в программировании. Среднее качество кода проектов на nodejs это наглядно демонстрирует.

Тоесть JS проще чем Gо все-таки выходит?

Go проще, чем JS, но на JS проще наговнокодить, не соображая в программировании. Вот основные моменты:

— JS прячет ошибки наподобие обращения к неинициализированному полю объекта или выход за границы массива. Быдлокодеры обожают, когда их говнокод не валится по таким «пустякам», как выход за границы массива, и даже не выдает никаких ворнингов.
— JS «магически» преобразует один тип в другой сплошь и рядом. Говнокодеры балдеют от «магии». До тех пор, пока не придется искать коварный баг, связанный с автоматическим преобразованием типов.
— В JS можно «магическим» образом добавлять и override’ить произвольные поля в чужих объектах и классах (ака prototype’ах), в т.ч. во встроенных в язык типа

''.constructor.prototype.foobar = function() { alert("Я молодец! Я добавил во все строчки метод foobar!") }
window.open = function() { alert("Хрен вам, а не новое окно!") }

К во всему этому nodejs добавляет еще немного «магии» в виде callback’ов на каждый чих. Которые с течением времени превращаются в callback hell.

— JS прячет ошибки наподобие обращения к неинициализированному полю объекта или выход за границы массива.
TDD? не, не слышал
— JS «магически» преобразует один тип в другой сплошь и рядом
последний раз такая бага была полтора года назад, за последние года 4 (какие баги были до этого уже не помню) очень активного девелопмента на джс
— В JS можно «магическим» образом добавлять и override’ить произвольные поля в чужих объектах и классах (ака prototype’ах), в т.ч. во встроенных в язык типа
эммм.... за всю практику видел токо одного человека кто так сделал, но на код ревью забраковали
К во всему этому nodejs добавляет еще немного «магии» в виде callback’ов на каждый чих.
это единственное резонное замечание тут

Все вышеизложенное справедливо в контексте «почему nodejs популярнее, чем go среди низкоквалифицированных разработчиков». Судя по слову Senior в вашем профиле, вас эти проблемы не должны касаться.

Как много js кода ты проревьювил в свой жизни? Откуда тебе знать о предпочтения js говнокодеров?:)
Есть простые факты.
Есть платформа, Node.js, которая появилась в 2009 году так же как и Go если не ошибаюсь.
За это время преуспела в продакшине для веб девелопмента намного больше, чем go. На Node, что делают сайты визитки в CMS сотнями — нет, при чем тут дилетантские проекты на PHP?
и если человек не получает удовольствия от обработки коллекции в циклах 3х уровней вложенности решая высокоуровневую бизнесс задачу на своем веб проекте он скорее всего хороший девелопер, чем наоборот.
Этим размышления про маргинальные технологии для избранных бред еще тот.

в циклах 3х уровней вложенности

Вы предлагаете заменить простые и понятные циклы на «магические» калбэки трех уровней вложенности внутри всяких непонятных map’ов, filter’ов и reduce’ов? Спасибо, не надо.

непонятных map’ов, filter’ов и reduce’ов
Я просто залишу це тут.
assets.toptal.io/...g-image-1409691715906.png
Якщо що, навіть у сьомої джави робота з колекціями незрівненно краща за гошне убожество.

Вроде в джаве уже все нормально после того как наконец запилили лямбды

Нода взлетіла, бо вже була товпа народу, що знала джаваскрипт.

var result = client.PostAsync("/ingest/data", content).Result;

КГ/АМ, выкладывайте побольше таких винов Go

:facepalm: Автор теста http Хендлер написать простой на dotnet не может не подключив громоздкий мвц Фреймворк и блочит все потоки на io — авторитно протестировал производительность технологий, нечего добавить.

Вопрос чувакам которые в гугле работают, слейте инсайд, го для чего то серьезного юзается?

Да походу не особо, вот вопрос из официального FAQ go (golang.org/doc/faq)


Is Google using Go internally?

Yes. There are now several Go programs deployed in production inside Google. A public example is the server behind golang.org. It’s just the godoc document server running in a production configuration on Google App Engine.

Other examples include the Vitess system for large-scale SQL installations and Google’s download server, dl.google.com, which delivers Chrome binaries and other large installables such as apt-get packages.

Короче раздавалка файлов для хрома и андроида (переписали одним человеком с С++ , так что можете прикинуть размеры проекта), надстройка над mysql для ютюба ну и тулзовины/утилитки для внутреннего употребления.

Короче го в гугле за 5 лет (или сколько там ему) не взлетел

Короче раздавалка файлов для хрома и андроида (переписали одним человеком с С++ , так что можете прикинуть размеры проекта),
Вот презентация от разработчика (Brad Fitzpatrick) по этой раздавалке — talks.golang.org/2013/oscon-dl.slide#1 .

опять девопс задача, вообщем контекст применения Го раскрыт, в реальных проектах только для скриптов развертывания, сборки, и управления инфраструктурой, но никакой бизнес-логики на нем

Как-то рано флейму затухать. Набросим неплохой пост о том, почему некоторые программисты делают такой странный выбор и предпочитают скале Го. golang-basic.blogspot.nl/...-which-one-to-choose.html . Совпадает с моим субъективным ощущением и тем что я наблюдаю вокруг. Добавлю от себя что скала несомненно интересный язык и ознакомление с ней или Хаскелем однозначно полезно для расширения кругозора. P.S. не ПХПышник.

Given the language specs, it should be no surprise that Scala has more features than Go.

Does that mean Go is any less expressive than Scala?
No, you just might need to write a few extra lines to code to do what you want (but I don’t think that is a bad thing).

waat?

«Очевидно что у Мерседеса 500 лошадиных сил, у Ланоса 100. Означает ли это что Ланос менее мощный чем Мерседес? Нет! Вам всего лишь нужно смастерить Ланосу двигатель на 500 лошадиных сил (и я не вижу в этом ничего плохого).»

Как вообще можно сравнивать эти два совершенно разных языка для совершенно разных задач?


Как вообще можно сравнивать эти два совершенно разных языка для совершенно разных задач?
Ну не знаю как у вас там, а какбы топик начался из вот такого вот сравнения. И в моей среде возникают такие вопросы когда нужен хороший concurrency — куда идти — java, scala или go. Scala проигрывает.

Пост из разряд, вот какие цифры, вот пример где скала в разы понятнее и проще, но Го круче чем скала, ведь я ее выучил первой.

Ну хорошо что ты вычитал что тебе нужно было.

Старая статья.
Я вообще тренд поддерживаю. Майндлес копи пейст обезьянки ничего путного в скале точно не напишут, пусть идут в го, и копи-пейстят там сколько влезет (без дженериков это вообще валидный прием разработки получаеться).

Ну в этом определенный плюс в go, без шуток.

На скале есть куча способов сделать одно и то же разными способами, поэтому всегда преследует мысль что код не идеален, что можно было написать лучше, что матерные скалисты посмотрят и засмеют, и в итоге многие куски переписываешь несколько раз. Да ты реально получаешь от этого кайф, любуешься какой красивый получился дизайн и читаемый код, но проект от этого не движется быстрее. С опытом, конечно, это все проходит, выработаются практики, свой стиль, и некоторые вещи с первого раза уже пишешь как надо.

Другое дело go. Пишешь, видишь что получается говно, но душа спокойна, по-другому вообще никак нельзя, в go это стандартная практика. Поэтому сидишь, фигачешь говно, и получаешь результат. Как потом это все развивать и поддерживать — это уже другой вопрос.

поэтому всегда преследует мысль что код не идеален, что можно было написать лучше, что матерные скалисты посмотрят и засмеют, и в итоге многие куски переписываешь несколько раз.
Это если есть время то они переписываються, если нет времени то нет. Вообще проблема больше не в самопериписывании, а в том, что в команде народ может использовать разные стили/подходы совершенно, дговориться использовать один подход — невероятно тяжело. Поддерживать чужой код написанный в другом стиле — тоже не просто, от того все проблемы и растут.
Но это же не значит что от скалы нужно отказаться прям всем командам на всех проэктах в пользу копи-пейст го.
На скале есть куча способов сделать одно и то же разными способами
ну из за этого сразу возникает проблема, что чужой код нифига не читаемый. Или чел захочет
что можно было написать лучше
любуешься какой красивый получился дизайн
и начнет функциональщину пилить, тогда как бы все...

По собственному опыту, один и тот же проект на скалле и на го, после месяца перерыва, код на скалле вспоминается и читается лучше, чем код на го

Наверняка имееться ввиду свой код.
Хотя флетмапов вложеных фолдлефтов с _._1._2._1 можна побыстрому напилить так что потом уже через пару недель сам же будеш материшся, непонимая что происходит.

Ну код на го тоже мой. У меня главная цель это читаемость и понятливость кода, и скала позволяет писать читаемый код, а го нет — как не прыгай, все-равно глаза кровоточят, в основном из-за мусора в коде.

Тут я соглашусь, при прикладывании усилий на скале можна написать читаемо. Сколько усилий к го не прикладывай — дженерики там не появяться, всеравно копи пейстить нужно.

По собственному опыту, один и тот же проект на скалле и на го, после месяца перерыва,
А что был опыт когда один и тот же проект писался и на скале, и на гоу, (как раз под эту тему), а потом на месяц забивался ? :)

так pet проект же, там и на год может заморозиться )

Та я ж про читаемость чужого кода говорил...

Я к тому, что скала в принципе позволяет писать более читаемый и понятный код, но, все зависит от команды.

и начнет функциональщину пилить, тогда как бы все...
Как выяснилось, под функциональщиной еще и разные вещи подразумеваются.
Для одних это флетмапы вложеных фолдлефтов, и поменьше мьютбл стейта — и уже какгбы функциональщина. Сама скала себя так продает.
Для других, это теория категорий, и прочий хаскель, принесенный через скалаз. Вторые смотрят на первых, как первые на джаву и го.

по-настоящему смешно будет, в разрезе этого топика, если Пайк с Фицпатриком таки ВНЕЗАПНО! дженерики запилят

Они никуда не денутся, без дженериков go так и останется языком для консольных утилиток

ти перебільшуєш, Павлуша, як завжди ©

let alone docker (хм, “консольная утилитка”?)

но ведь высоконагруженные сервисы вроде dl.google.com смотрят на вашу фразу, как на г-но (тестимониал от Брэда Ф. легко находится)

и потом
да, с одной стороны гугель даже близко не подошел ко впадению во вселенский субботник по перелицовыванию кодбазы на гоу, это тру
там вообще все технологические выборы — в компетенции команд (в разумных пределах, само собой), а люди в массе все же консервативны
и вообще, пока что самый витринный го-проект — это докер

но я видел кое-какие internal testimonials (среди которых и переписывание высокнагруженных сервисов, вроде сжимающей прокси)

и они очень, очень впечатляющи, надо отметить

ну вот опять, по кругу...

что такое докер уже снизу обсудили, и что это за такие высоконагруженные сервисы тоже обсудили, имейте совесть

вы таки выказываете явные признаки функциональной неграмотности,
прямо сейчас

вы точно этого хотели?

Что нефиг поднимать вопросы, которые уже обсудили. Читайте ветку, и отвечайте где вы не согласны. А то сейчас пойдет все по кругу:

я: докер консольная тулзовина
вы: какая тулзвовина?!?! Да там исходников на целых 10 мбайт!!!
я: 10 мбайт это фигня по сегодняшним меркам, да и логики особо никакой, вот докер на баше в 100 строчек кода
вы: бебебе, бебебе. Зато я на go могу держать миллион открытых соединений на одной ноде!
...

вы: какая тулзвовина?!?! Да там исходников на целых 10 мбайт!!!
вы: бебебе, бебебе. Зато я на go могу держать миллион открытых соединений на одной ноде!

простите, но вы путаете меня с демонами из своей головы

ЗЫ таки поднаброшу
вот еще «консольная тулза»
vitess.io/overview
я за нее сам не знал, честно говоря

на ней работает ютуб
весь

она опенсорс, вот хаб
github.com/youtube/vitess

enjoy

Тут вообще 5 мбайт исходников, причем по заявлению самих же разработчиков, производительность получилась на уровне джавы, мда.

Вопрос не в том можно ли писать что-то кроме консольных утилит в принципе, вопрос в целеобразности.

шито?

в целесообразности чего?

быстрого и надежного главного даунлоад-сервиса для гугла?
витесса для ютуба?

а?

быстрого
как оказалось не особо
надежного
и тут конечно же заслуга го как языка, ага
главного даунлоад-сервиса для гугла?
ух как пафосно звучит, а судя по описанию оказывается это просто надстройка над MySql базой матаданных ютюба, такой себе прокси оптимизирующий работу несколько инстансов MySql
в целесообразности чего?

В целесообразности писать это именно на го. Хотя если инфраструктура действительно состоит из «нескольких серверных процессов, консольных и веб утилит», то может смысл и был, тем более это гугл, они го и создавали чтобы на плюсах все не писать.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

так оно и выглядит как продвинутая консольная утилита — врапер над майскл, крутой проект ничего не скажешь...

Уже не смешно — Фицпатрик обещает следующие штуки в следующих версиях гоу:
— Generics
— Sum types
— List comprehensions
— Immutability
— ~memory @ownership
— Data races statically impossible

См. слайды 17-30 из его презентации docs.google.com/...lide=id.g118cf9b85c_0_263 .

Так оно же все не нужно! Разве нет? Да и го попробуй потом выучи, столько новых слов, конструкций, функционала, будет не проще джавы.

Если это все введется, и не будет крупных фейлов, то это будет совсем другой, отличный от текущего, Го. И это было бы круто. Еще бы тайпклассы появились (а с дженериками должны), было бы идеально, остальные нужные штуки подтянутся.

Забавно, что кое-кто активно спорит, что перечисленные вещи «не нужны».

Edit:
Пролистал презентацию, чувак просто троллит. Никаких дженериков и прочего не будет, не повезло гоферам.

Посмотрел все слайды. Забыли добавить, Go 2.0:

  • .....вышесказанное
  • Data races statically impossible
  • Years of mistakes revisited
  • Tons of feature request resolved
-> в конце Sorry! I lied ..... So when is Go 2.0 ? — No plans maybe never.

Приходите к нам в Go-секту праздновать выход новой версии Go 1.6 — dou.ua/calendar/9812 . Вход бесплатный. Обещают пиво с пиццой на халяву.
Ждем скала-адептов и любителей nodejs для обращения в нашу веру. Обсудим преимущества гоу за рюмкой чаю.

Щоб пожвавити дискусію накину і я.

Перше і головна проблема го це дійсно якісь занадто агресивні адепти. Вони як чеченські терористи — їх кілька сот людей може усього по світу, а галасу від них як наче їх мінімум кілька сот тисяч. І через них враження про інших представників народу складається упереджене.

Я вже колись пропонував Івану Данилюку написати quick sort на го: добре усім відомий алгоритм з нюансами який на будь-якій мові займає усього кілька рядків, можна продемонструвати всю красоту го-рутін, як передаються функції як параметри (компаратор) та інше. І я навіть знаю що одним з перших питань до реалізації буде «а як мені те саме зробити для абстрактного типу?». І навіть можете сказати що у архаїчному С qsort вміє працювати з довільними типами. На що Іван скаже «ха-ха-ха, вам не вистачає дженеріків? Неправильно ви критикуєте го, ось моя стаття як правильно критикувати го...».

І навіть якщо ви не дасте перетворити своє питання на жарт хтось з гошників почне вас питати «а нащо вам дженеріки» та «а як часто вам треба писати контейнери та сортування в реальному житті». На що я можу відповісти що дуже часто, майже щодня. В коді з яким я працюю і взаглі будь-хто працює у великому проекті контейнери та алгоритми використовуються повсякчасно і те саме сортування лежить в основі багатьох колекції та пошуках і виборках що є в нашому коді.

Також дуже помітно небажання приймати реалії такі як ризикованість переходу на го просто через відсутність програмістів на ньому та непопулярність і маловідомість мови. Ніякі статистичні дані з порівняння популярності та поширеності мов гошніками не приймають бо вони «неправильні», а запропонувати власний спосіб оцінювання крім «ось в цьому репозіторії на гітхабі все на го» чи зібрати власну репрезентативну статистику якось ніхто не спромігся.

Протиставлення го та С++ просто сміхотворне. Так, дійсно, С++ з історичних причин зараз використовується багато де це не має сенсу зараз і де є кращі альтернативи як Java/C# чи пітон. Щодо виживання і можливого поширення мови то я думаю з невпинними вливаннями гугла і при умові що вони не закинуть го через пару років як це сталося з черговими їхніми «усіх переможем» базом, вейвом та іншими вбитими технологіями то років через 5-10 можливо буде помітно як го тіснить пітон.

Думаю що самі творці мови прекрасно розуміють що вони створили просунутий шел-скріпт з підтримкою многопоточності куди ніхто руками не зможе залізти і ручна синхронізація не потрібна. Проста виразна мова для написання утіліт — це ж прекрасно! Але гошнікам чомусь таке визначення не подобається і їм обов’язково треба усім доводити що «скоро не буде С++, не буде дженеріків, не буде ексепшенів, не буде віндовса, не буде радіо і телебачення, не буде ГМО і РПЦ, буде один го».

Це щоб кожен знайшов на що побугуртити.

Прое́кция (лат. projectio — бросание вперед) — психологический процесс, относимый к механизмам психологической защиты, в результате которого внутреннее ошибочно воспринимается как приходящее извне[1]. Человек приписывает кому-то или чему-то собственные мысли, чувства, мотивы, черты характера и пр., полагая, что он воспринял что-то приходящее извне, а не изнутри самого себя

Недоречна цитата — така що по тексту, змісту, стилю, і речам яким дається оцінка не співпадає з текстом до якого цю цитату приведено. Наприклад:
А: я стверджую що X, Y та Z
Б: забагато непов’язаних тверджень
А: це щоб кожен щось для себе знайшов
Б: це у вас проекція <— недоречне твердження

вы за свое чванство и невынужденный комсомольский апломб будете НАКАЗАНЫ, товарищ

Я вже колись пропонував Івану Данилюку написати quick sort на го: добре усім відомий алгоритм з нюансами який на будь-якій мові займає усього кілька рядків

Зачем изобретать колесо, если оно уже изобретено в стандартной либе — github.com/...8f5b029d/src/sort/sort.go . Там и quicksort в пару строчек, и heapsort, и insertionsort. И все это работает для любых типов данных без дженериков.

Ето какой-то позор! ©

Де ж там го-рутіни, де компаратор? Чи це треба усі мої типи даних від Interface успадковувати і імплементувати operator < для них? Поясніть плз.

А для чого вони в го взагалі? Я думав це якась гітлєр-фіча якою будуть вбивати всі інші мови. Ну і попросив демонстрацію цієї фічі на добре усім відомому і короткому в реалізації алгоритмі.

Горутины — это аналог потоков в других языках. Только с горутинами работать легче. Например, можно наплодить миллион горутин, не беспокоясь, что они сожрут всю память с процессором. В quicksort они не нужны. А вот в каком-нибудь высоконагруженном сервере нужны.

Тут не питання доцільності, прохання було продемонструвати го-рутіни та може якісь інші особливості мови на добре усім відомому алгоритмі реалізація якого вкладається у кілька рядків.
Мені здається я це вже рази 2 чи 3 повторював. І поки що почув як і очикував що «дженеріки не потрібні» та «як часто вам доводиться писати ...?» в купі з абсолютно чарівним «що складного скопіпастити код?».

Ну а если масив в терабайт — распаралелить ?

Для массива, который не помещается в памяти, нужно использовать mergesort, а не quicksort. Иначе задолбетесь ожидать на random IO операциях. И SSD тут не спасет.

У _quick_sort нет прыжков random i/o, процесс разделения отрезка идёт двумя встречно сжимающимися без прыжков указателями. Если чуть-чуть помочь ОС в понимании нужности страниц (возможно при mmap через madvise()) - получается не хуже, а часто и лучше, чем mergesort и прочие «внешние» сортировки. И даже если не помогать — алгоритмы VM работают достаточно неплохо.
(Вместе с упоминанием единственного mergesort среди всего огромного пространства внешних сортировок наглядно показывает ваш «уровень» знания вопроса.)

Параллелить процессы разделения в quicksort можно и нужно (по количеству доступных ядер), и вот тут стандартный шедулер горутин будет только мешать — надо делать пул из фиксированного числа исполнителей задач.

Параллелить процессы разделения в quicksort можно и нужно (по количеству доступных ядер), и вот тут стандартный шедулер горутин будет только мешать — надо делать пул из фиксированного числа исполнителей задач.

Стандартный шедулер горутин мешать не будет, т.к. у него очень низкие накладные расходы. Только что проверил — он может запускать и уничтожать 6 миллионов горутин в секунду на моем ноуте. Причем эта скорость остается постоянной при любом количестве параллельно выполняющихся горутин от четырех штук до четырех миллионов штук. Вот соответствующий код для проверки:

func BenchmarkGoroutineOverhead1(b *testing.B) {
        benchmarkGoroutineOverhead(b, 1)
}

func BenchmarkGoroutineOverhead10(b *testing.B) {
        benchmarkGoroutineOverhead(b, 10)
}

func BenchmarkGoroutineOverhead100(b *testing.B) {
        benchmarkGoroutineOverhead(b, 100)
}

func BenchmarkGoroutineOverhead1000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 1000)
}

func BenchmarkGoroutineOverhead10000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 10000)
}

func BenchmarkGoroutineOverhead100000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 100000)
}

func BenchmarkGoroutineOverhead1000000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 1000000)
}

func benchmarkGoroutineOverhead(b *testing.B, parallelism int) {
        b.SetParallelism(1)
        b.RunParallel(func(pb *testing.PB) {
                ch := make(chan struct{})
                for pb.Next() {
                        go func() {
                                ch <- struct{}{}
                        }()
                        <-ch
                }
        })
}

Вот результаты тестов:

$ go test -bench=. 1_test.go 
testing: warning: no tests to run
PASS
BenchmarkGoroutineOverhead1-4      	10000000	       184 ns/op
BenchmarkGoroutineOverhead10-4     	10000000	       183 ns/op
BenchmarkGoroutineOverhead100-4    	10000000	       183 ns/op
BenchmarkGoroutineOverhead1000-4   	10000000	       184 ns/op
BenchmarkGoroutineOverhead10000-4  	10000000	       183 ns/op
BenchmarkGoroutineOverhead100000-4 	10000000	       183 ns/op
BenchmarkGoroutineOverhead1000000-4	10000000	       183 ns/op
Стандартный шедулер горутин мешать не будет, т.к. у него очень низкие накладные расходы.

То есть даже минимально вдуматься в смысл моего сообщения Вы не попытались. Спасибо за подтверждение моих выводов.

Я не гоубой, но вижу, что в вашем коде в benchmarkGoroutineOverhead параметр parallelism игнорируется и всегда вызывается SetParallelism(1)

Можно в двух словах объяснить в чем СУТЬ этого бенчмарка?
И почему при увеличении кол-ва параллельных потоков производительность не увеличивается? По логике должна увеличиваться, пока вы не уткнетесь в кол-во ядер

Правильно заметили — вместо единицы должно быть parallelism. Иначе все время измеряется скорость создания горутин из четырех параллельно работающих горутин. Но если заменить единицу на parallelism, то результаты не изменятся.

И почему при увеличении кол-ва параллельных потоков производительность не увеличивается? По логике должна увеличиваться, пока вы не уткнетесь в кол-во ядер
Все верно. Просто при parallelism=1 бенчмарк запускается на количестве потоков, равному количеству ядер. На моем ноуте это четыре. Поэтому при увеличении количества параллельных потоков скорость не растет. Но и не падает.

Что мне подсказывает, что бенчмарк не правильный. Если потоков больше чем ядер — должны быть накладные расходы на переключение, ни один го это не обойдет.

там по сути BenchmarkGoroutineOverhead1 запускается кучу раз и все, а benchmarkGoroutineOverhead тупо игнорирует второй аргумент, короче бенчмарк ни о чем, как и его объяснение о его логике...

Поэтому при увеличении количества параллельных потоков скорость не растет. Но и не падает.
в этом тесте нет никакого увеличения количества параллельных потоков.

Можно сказать иначе — никогда ещё доказательство O(1) == O(1) не было таким запутанным. :)

Причем тут реализация? Вопрос в использовании. Вот небольшой примерчик:

struct Person {
    Age int
    Name string
}

people := []Person { ... }

peopleByAge = ...

А теперь поведай нам непутевым, как на выразительном go, на котором код «в 10 раз короче» ©, отсортировать людей по возрасту? И это ведь самый что ни есть элементарный пример.

та он отмораживаеться когда надо это в 10 раз короче показать )
уже не один раз тут было

Не зря же морозиться, многие даже не догадываются насколько все плохо:

struct Person {
    Age int
    Name string
}

type ByAge []Person

func (a ByAge) Len() int {
    return len(a)
}

func (a ByAge) Swap(i, j int) {
    a[i], a[j] = a[j], a[i]
}

func (a ByAge) Less(i, j int) bool {
    return b[i].Age < b[j].Age    
}

people := []Person { ... }

sort.Sort(ByAge(people))

Это сортировка только для одного типа по одному свойству. Хотите еще по чему-то отсортировать? Фигачьте еще одну кастомную коллекцию и имплементьте интерфейс.

И вот с этим они собираются убивать скалу, джаву, C#...

Ну какбы не однострочник конечно, но и страшного ничего такого в этом нету. Покажите лучше как вы в скале, Джаве или шарпе создадите подпроцесс типа горутины и получите из него данные а ля go chan.

Ну какбы не однострочник конечно, но и страшного ничего такого в этом нету.

Ну в go комьюнити вообще в отсутствии дженериков с дебагером ничего страшного не видят, а некоторые даже выдают это за преимущество.

Покажите лучше как вы в скале, Джаве или шарпе создадите подпроцесс типа горутины и получите из него данные а ля go chan.

Типа это единственное правильное решения. У скалы есть akka, у C# - async/await:

var result = await DoSomeHeavyComputationAsync()
Ну в go комьюнити вообще в отсутствии дженериков с дебагером ничего страшного не видят, а некоторые даже выдают это за преимущество.
 а что страшного в отсутствии дебагера для матерых программистов и не желающих смешиваться с ниасилившими? Настроить все-таки какой-то из дебаггеров? Или может скала прямо так легко дебажится с несколькими абстракциями и лямбдами в одной строке? Ну то есть было бы конечно неплохо с дебаггеризацией попроще, но опыт фронтэнда показывает что и без дебаггера жизнь вполне себе есть.

Отсутствие дженериков — да, для меня лично плюс. Плюс по сравнению с недо-дженериками джавы или супердженериками скалы. Особенно после переезда на микросервисы (отдельный вопрос в чем это хорошо, а в чем плохо) в моем лично опыте большинство работы с дженериками ушло на уровень объявления типа коллекции. Добавят в Го дженерики хорошо — ок. Не добавят — не смертельно.

Типа это единственное правильное решения.

О том и речь. Дженерики это не единственное правильное решение.

хотел что-то писать, потом заметил:

Mykola Gurov Жирный тролль

Нечего на других пенять если крыть нечем.

Ну а что отвечать человеку, для которого фигачить кастомные типы и копипастить функции по каждому пчиху это

для меня лично плюс

Это нужно хорошо упороться, чтобы вот это:

func FindRatesTo(rates *[]ExchangeRate, rateTo string) *[]ExchangeRate {
    result := Rates {}
    
    for _, r := range *rates {
        if (r.To == rateTo) {
            result = append(result, r)
        }
    }

    return &result
}

usdRates := FindRatesTo(&rates, "USD")

считать плюсом по сравнению с этим:

val usdRates = rates.filter(_.to == "USD")

Вот переписал небольшой проектик на go, чтобы прочувствовать все на личном опыте, и там реально, половина кода это мусор, которого не было бы будь у go дженерики

Уберите лишние звездочки с амперсандами из вашего кода, а не то глаза режут.

Ну слайсы и так по ссылке передаются, можно и без звездочек, но вот с какими-то кастомными типами все-равно придется указатели использовать.

Ну а что отвечать человеку, для которого фигачить кастомные типы и копипастить функции по каждому пчиху это
ну прежде чем отвечать неплохо бы понять собственно на что. Я говорю что дженерики плохо или что Го лучше без дженериков. Я говорю что Го лучше без таких дженериков как в Джаве или Скале.

В джаве дженерики самые базовые и дубовые которые могут быть...
Какая альтернатива вам видиться как нечто супериор в гоу ?

опыт фронтэнда показывает что и без дебаггера жизнь вполне себе есть.

То-то в Chrome встраивали самые продвинутые developer tools, а один мой бывший босс — фронтэндщик говорил, что это единственный нормальный браузер, именно из-за этих тулзов. Среди которых отладчик с возможностью хотя бы посмотреть внутрь объекта занимает совсем не последнее место.

а что страшного в отсутствии дебагера для матерых программистов

Отладчик это не только тулза для «остановиться по breakpoint и посмотреть переменные», хотя и это крайне важно для освоения новых средств (при первичном обучении программированию — для новичков, при переходе на новые языки, среды, фреймворки — для опытных), но и средство анализа истории события, включая посмертные состояния. «Страшного», конечно, в большинстве случаев нет, а вот потеря времени на непроизводительные движения вместо съёма конкретного состояния — может быть существенна.

В последние лет 20 наблюдается жуткий хайп среди «опытных» на тему «отладчик вреден, потому что учит не думать и создаёт плохие привычки», но такое впечатление, что искренне его поддерживают или снобы, или продавцы всяких анализаторов (штука, конечно, полезная, но не с обманной рекламой).

Отсутствие дженериков — да, для меня лично плюс.

Тогда покажите замену для ранее приведённых примеров, где их отсутствие приводило к порождению лишнего кода.

... Среди которых отладчик с возможностью хотя бы посмотреть внутрь объекта занимает совсем не последнее место.
очень близко к последнему, ИМХО. В принципе если кусок нормально тестируем то console достаточно удобна.
средство анализа истории события, включая посмертные состояния.
это про мемори дампы? Для меня эти задачи как-то с дебагерром не очень связаны. Может что-то пропустил?
Тогда покажите замену для ранее приведённых примеров, где их отсутствие приводило к порождению лишнего кода.
это не есть самоцель.
Для меня эти задачи как-то с дебагерром не очень связаны. Может что-то пропустил?

Э?


$ gdb ./foo /var/tmp/foo.core
gdb> bt
gdb> f 0
gdb> p arg1
gdb> p *arg1

ну и так далее.

это не есть самоцель.

Не понимаю связи этого предложения с поднятым вопросом.

troll-mode-on:

import gopher._

 def fibonacci(c: Output[Long], quit: Input[Int]): Future[Unit] = go {
     var (x,y) = (0L,1L)
     for(s  <-  select.forever) {
      s match {
        case z: c.write if (z == x) => 
                      x = y 
                      y = z+y
        case q: quit.read =>
                 implicitly[FlowTermination[Unit]].doExit(())
      }
   }
 }

def run(n:Int, acceptor: Long => Unit ): Future[Unit] =
 {
    val c = makeChannel[Long](1);
    val quit = makeChannel[Int](1);
    val r = go {
        var i = 1
        while(i <= n) {
            val x: Long = (c ?)
            //Console.println(s"received: ${i}, ${x}")
            acceptor(x)
            i += 1
         }
        quit <~ 0
    }
    fibonnacy(c,quit)
}

Из github.com/rssh/scala-gopher

Фигачьте еще одну кастомную коллекцию и имплементьте интерфейс.

Да, так сложно объявить «кастомную коллекцию» в одну строчку и скопипейстить три элементарных метода. Зато, в отличие от других языков программирования, стандартная сортировка в гоу работает с произвольными коллекциями, реализующими три вышеуказанных метода, а не только с array’ем.

Да, так сложно объявить «кастомную коллекцию» в одну строчку и скопипейстить три элементарных метода.

Сортировка это только один из 1000 случаев. Еще парочка примеров велосипедостроения:

func Contains(array *[]ExchangeRate, from string, to string) bool {
    for _, pair := range *array {
        if (pair.From == from && pair.To == to) {
            return true
        }
    }

    return false
}

rates := []ExchangeRate {
    ExchangeRate { "UAH", "USD", 0.04 },
    ExchangeRate { "EUR", "USD", 1.07 },
}

if (Contains(&rates, "GBR", "USD") == false) {
    blah blah
}
func FindRatesTo(rates *[]ExchangeRate, rateTo string) *[]ExchangeRate {
    result := Rates {}
    
    for _, r := range *rates {
        if (r.To == rateTo) {
            result = append(result, r)
        }
    }

    return &result
}

rates := []ExchangeRate {
    ExchangeRate { "UAH", "USD", 0.04 },
    ExchangeRate { "EUR", "USD", 1.07 },
}

usdRates := FindRatesTo(&rates, "USD")

И это только самые элементарные примеры. Как-то многовато выходит для языка, у которого «код получается в 10 раз короче» ©, не находите?

Зато, в отличие от других языков программирования, стандартная сортировка в гоу работает с произвольными коллекциями, реализующими три вышеуказанных метода, а не только с array’ем.

Озвучьте список таких языков пожалуйста

Если не считать, что в вашем коде лишние звездочки, не вижу других проблем. Подскажите, что с ним не так?

Не так то, что в нормальных языках все так:

val rates = 
    ExchangeRate("UAH", "USD", 0.04) ::
    ExchangeRate("EUR", "USD", 1.07) :: Nil

if (rates.exists(r => r.from == "GBR" && r.to == "USD")) {
    blahblah
}

val usdRates = rates.filter(_.to == "USD")

Вообще удивительно, модификаторы доступа в java, C# для вас это ужас-ужас, а вот всякие велосипеды на каждом шагу в go в виде отдельных типов, функций и интерфейсов — «не вижу проблем». Это все-равно чтобы целый день считать калории, есть здоровую пищу, заниматься в спортзале, потом прийти вечером домой и перед сном сожрать большую пиццу, запивая ее пивом.

Модификаторы доступа и прочая verbose хрень в жаве не несет смысловой нагрузки. Поэтому не нужна. В скале же бросаются в другую крайность, жертвуя простотой в угоду краткости кода.

В вашем примере код на гоу проще и понятнее кода на скале.
Для понимания скала кода нужно знать, как работают exists и filter, какие у них есть подводные камни, что такое ’=>’, ’_’, а также сокращенный синтаксис лямбда-функций.
Для понимания гоу кода достаточно базовых знаний программирования — переменных, функций, циклов и условий.

В гоу, в отличие от скалы, соблюден идеальный баланс между простотой и краткостью кода. Поэтому большие проекты на гоу занимают в 10 раз меньше строчек кода, чем на скале.

епт, а для понимая кода на го нужно иметь начальные знания паскаля или хотя бы знать что такое ’:=’

Для понимания скала кода нужно знать, как работают exists и filter, какие у них есть подводные камни, что такое ’=>’, ’_’, а также сокращенный синтаксис лямбда-функций.
ок ты сделаешь тоже самое, нахерачив 20 строк кода и применив 3 вложенных цикла. это можно сделать в любом языке, не надо даже базовую теорий множеств и английский язык учить. обычно на код ревью за такой бестолковый низкоуровневый код руки отбивают, потому что нужно знать
какие у них есть подводные камни
прежде чем дублировать реализацию алгоритма
.
Такую безальтернативность инструментария, называть
идеальный баланс между простотой и краткостью кода.
самообманом заниматься

ОК, признаюсь — в гоу мне иногда не хватает list comprehensions из Python. Только не говорите про это Робу Пайку.

так чего ж говорить, если в оф доке к языку пишут что мозгуют как Дженерики подкостылять бы.
Видать Роб Пайк таки не до конца доволен такому балансу простоты, когда в каждой бибиотеке надо пустой интерфейс обьявлять с бесодержательным названием и сознательно прибивать плюшки статической типизации.

В гоу, в отличие от скалы, соблюден идеальный баланс между простотой и краткостью кода. Поэтому большие проекты на гоу занимают в 10 раз меньше строчек кода, чем на скале.
У пациента явно проблемы с логикой )

Проблемы не с логикой, а с тем, что я дал недостаточно развернутый ответ, чтобы вы могли уловить смысл :)

Объем кода в маленьких проектах зачастую напрямую зависит от краткости синтаксиса — чем больше логики можно запихнуть в одну строчку с минимальным количеством символов, тем меньше результирующий объем кода. Ваши примеры это прекрасно демонстрируют. Прежде чем делать какие-то выводы, следует помнить, что обычно сложность кода растет с сокращением синтаксиса. Поэтому важно найти золотую середину между краткостью синтаксиса и сложностью кода.

Чем больше проект, тем меньшую роль играет краткость синтаксиса в минимизации объема кода. На первое место выходит архитектура проекта. Чем проще архитектура, тем меньше кода. Архитектура проекта сильно зависит от идеологии выбранного языка программирования:

— Java поощряет лишние абстракции.
— Scala — в дополнение к лишним абстракциям от своего предка-Java добавляет лишнюю мультипарадигменность и матан.
— Go поощряет простоту архитектуры.

Поэтому большие программы на гоу получаются в 10 раз короче и в 10 раз проще программ на скале.

Вы смешиваете синтаксис и семантику в языке. Синтаксис, действительно, почти ни на что не влияет. А вот семантика является именно тем, что отличает языки программирования.

К слову, я так и не понял, за счет чего Го «поощряет простоту архитектуры» ? Интерфейсы == тайпклассы для бедных, горутины == еще-один-способ-для-параллелизации (который зачем-то всунули в ядро языка). Богатая стдлиба, которая извлекла уроки из ошибок той же джавы — это, безусловно, плюс. Но стдлиба вообще никак не относится к языку. И сам вопрос «чья стдлиба круче» открытый.

Ожидаю ответа в духе «Го дает простоту архитектуры за счет: фича1, фича2, ...». Код-ревью лежит вне ЯП, и не является фичей. Фичи должны быть конкретными, а не «блаблабла проще читать, блаблабла поощряет хорошую архитектуру, ...». Желательно с примерами, когда задача А на Го решается в 10 строчек, а на Скале в 100. Примеры обратного я, если хотите, могу предоставить.

Ну я явно вашего дзена не постигаю, видимо трава не та.
Нету дженериков — нужно плодить 100500 класов, а код все же короче получаеться.

Любой большой проект это взаимодействие модулей, желательно со слабой связностью. Каждый модуль это набор абстракций, взаимодействующих между собой. Каждая такая абстракция состоит из функций. Абстракции и функции уже напрямую зависят от выразительности и функциональности языка. Скала, например, позволяет писать компактные типы и функции, go же наоборот, для каждой «скальной» функции провоцирует создавать дополнительные типы и функции-сателиты. То есть на этом уровне go сливаеться в сухую. Теперь вопрос, как синтаксис и идеи go, могут сократить количество абстракций и модулей в проекте?

А вообще, это прекрасно я считаю:

стандартная сортировка в гоу работает с произвольными коллекциями, реализующими три вышеуказанных метода, а не только с array’ем.

всего пару часов назад чуть ниже:

Какие контейнеры кроме array и hashmap вы используете каждый день?

(facepalm)

стандартная сортировка в гоу работает с произвольными коллекциями,

Ага, і цей спосіб яким вона «работаєт» називається «хіба так складно зробити ще один копі-паст?». Дуже, дуже передові технології!

Так складно користуватися мовою в якій копі-паст не є необхідністю?

В коді з яким я працюю і взаглі будь-хто працює у великому проекті контейнери та алгоритми використовуються повсякчасно

Какие контейнеры кроме array и hashmap вы используете каждый день? Эти два контейнера встроены в Go и позволяют работать с произвольными типами. Остальные контейнеры используются настолько редко, что не составляет никакого труда написать их кастомную реализацию под требуемый тип данных.

Какие контейнеры кроме array и hashmap вы используете каждый день

map (той що на tree побудовано), set, list, multiset. А ще є алгоритми типу find_if, transform, copy та інші.

Остальные контейнеры используются настолько редко, что не составляет никакого труда написать их кастомную реализацию под требуемый тип данных.

Під всі кілька сотень моїх типів даних у кількох десятках проектів? Ні, дякую, приходьте зі своїм го коли у вас буде рішення яке не вимагає копіпасти у обсязі половини моїх сорців.

map (той що на tree побудовано), set, list, multiset. А ще є алгоритми типу find_if, transform, copy та інші.

set и multiset заменяется на hashmap.
list — на array или blocking queue aka channel в зависимости от контекста.
map — на hashmap или sorted array в зависимости от контекста.

find_if — на обычный цикл или sort.Search в зависимости от того, отсортированы ли данные в контейнере.
transform — обычный цикл с вызовом нужной функции.
copy поддерживается Go для массивов любых типов.

Welcome to Basic? Ще раз ні, їжте це самі.

Никак не могу понять стремления усложнять простой код среди неопытных программистов. Наверное, хотят показаться умными перед гоу-программистами. Но не понимают, что через некоторое время им придется кричать WTF по десять раз в час, разбираясь в собственном закрученном функциональном говнокоде.

По-перше, копі-паст це ней той спосіб яким недосвічені програмісти можуть підтримувати код у стані простоти. А, по-друге, у нас вже є прості і виразні мови без колекцій/дженеріків/ексепшенів та повторного використання коду взагалі, але з циклами. Го серед них виглядає дуже пристойно тому що вміє у многопоточніть і тому що гугл поки що вливає в неї.

Я ж не проти го, і якщо виникне необхідність буду на ній писати так само як при необхідності пишу на Power Shell, shell, python та навіть cmd. Мені не подобаються оці казочки що на го можна писати і переписувати складні і старі системи.

Последние новости — Intel использует golang — habrahabr.ru/...ompany/intel/blog/275709 .

гоу поддерживает винду.
Попахивает зрадой. Роковая ошибка разработчиков... Теперь толпы разъяренных бородатых линуксоидов будут с недоверием смотреть в сторону пучеглазого зверька-гофера.
Гокапец близится.

Це не зрада, а перемога. Под виндой не работает бОльшая часть популярных сторонних библиотек. Так что виндокодеры обречены на адские муки :)

Бородатые линуксоиды одобряют.

ну офигеть теперь, даже богомерзкая нода нормально работает под всеми платформами, а гоферы не асилили?

Мабуть просто ще ніхто прийом «хіба так складно зробити копі-паст?» не застосував.

Справедливости для, копипаст иногда предпочтительнее архитектурного выделывания в духе «вооот эти две штуки почти одинаковы, а потому давайте сделаем общий интерфейс». Потому что это «почти одинаковы» может как сузиться, так и расшириться, а попытки натянуть «общий интерфейс» на изменившуюся предметную область наверняка останутся.

Но это частный случай YAGNI, и к Го не имеет отношения. У последнего нет оправданий для своего бескомпромиссного навязывания копипаста. Например, почему нельзя было сделать interface тайпклассом?

Справедливости ради, вышеуказанная проблема с интерфейсами разрешается через концепт утиной типизации, реализованный в Go.

Решается (еще бы и она не решалась, хех). Только интерфейсы — не «утиная типизация», а недотайпклассы (тк первые доказательно более слабые, чем вторые). И, как многие Го-паттерны, выглядят убого на фоне конкурентов.

Для справки, в последнем зарплатном опросе, скальных анкет не много, но получают они дофига. Го вообще в списке нет, а если бы и были, то получали бы на уровне ПХП, питона. Так что в интересах разработчиков, чтобы скала развивалась и шагала по планете. Менеджерам конечно лучше продвигать что-то простое типа go. Поэтому немного удивляет когда некоторые разработчики болеют за go и искренне верят что он убьет скалу, джаву, .net и захватит мир. Или все вы спите и видите себя стартаперами набирающих студентов за гроши? Может единицы из вас и станут стартаперами, но вот большинство из вас будут в роли этих студентов работать за гроши.

у нас в городе к стати единственная скальная контора которая пыытаеться как раз набирать студентов с горящими глазами....
А массовый приход Go ( и не дай бог в интерпрайз) думаю породит такое что индо-пехепешники еще будут вспоминаться с ностальгией )))

Нужно признать что наплодить нечитаемый и неподдерживаемый г-но код на скале гораздо легче чем на го.
Потому стратегия набора всех подряд странна, и приведет к такимже результатам как у автора блога.

Ну го вообще не спасает от этого.

Вот играюсь сейчас с go, наговнокодить там раз плюнуть. Да, он прост в изучении, но чтобы писать нормально спроектированные, поддерживаемые программы, нужен опыт, и над дизайном нужно так же само хорошо думать как в другом любом языке. Вот стандартная библиотека go спроектирована и написана нормально, любо глянуть, видно что умные, опытные люди писали. Но вот открыть репозиторий типичного гофера, «изучившего го на выходных и собирающегося запустить стартап с гоферами студентами» — там ад и Израиль. Да он написал то что хотел, и оно вроде как работает, но кроме него там никто ничего не разберет. Ну и кому нужны студенты изучившие го на выходных, если они не смогут въехать в проект написанный такими хипстерами?

ну они стараються и хорошо отбирают — умных и не жадных
соотведственно многим умным и жадным они совсем как работодатель не подходят

Так что в интересах разработчиков, чтобы скала развивалась и шагала по планете.

На самом деле в интересах разработчиков, чтобы язык был нишевой, востребованый, но непопулярный среди гоферов, пыхеров, хипстеров, и прочих индусов.

Опасения излишни, поскольку потребности в разработке софта растут и никуда не исчезнут, пока есть цивилизация. Несмотря на развитие php с увязанными фреймвёрками, другие языки и технологии тоже успешно развиваются, и php их не демпингует. Тут есть как раз другой момент. За счёт инкамеров с низким порогом входа рынок будет только расширяться и развиваться.

Прикольная логика, в которой вся илитарнасть как на ладони.
Во-первых после того не означает вследствие того. Программисты которые реально перешли на скалу обычно и ранее зарабатывали выше среднего.
Во-вторых призыв к сговору работников, программистов в данном случае, о требовании повышения оплаты не по результатам труда, а по использованию инструмента... Это да.
В-третьих — явное непонимвние что деньги берутся не из тумбочки, а колбаса не из холодильника.
В-четвёртых — интерес, мотивация разработчика ПО почему-то свелся к зарабатывания бабла лукавым способом.

Во-первых после того не означает вследствие того. Программисты которые реально перешли на скалу обычно и ранее зарабатывали выше среднего.

И что? Обычные рыночные отношения. Количество задач для скалы превышает количество специалистов, поэтому стоимость отдельно взятого специалиста растет.

Во-вторых призыв к сговору работников, программистов в данном случае, о требовании повышения оплаты не по результатам труда, а по использованию инструмента... Это да.

Если инструмент позволяет решать специфические задачи которые несут компании больше денег, то почему бы и нет? Или вы на go будете решать те же задачи, что и на скале только из-за того, что специалистов на go больше и они дешевле? Влетите же потом на куда большие деньги.

В-третьих — явное непонимвние что деньги берутся не из тумбочки, а колбаса не из холодильника.

То есть вы хотите сказать что зарплата программиста зависит от успешности компании? Что же тогда гиганты как майкрософт и гугл платят даже чуть ниже рынка, хотя учитывая сколько они генерируют чистой прибыли, могли бы платить в 2 раза больше?

Язык программирования — не инструмент. Как и русский, японский и английский.
Но массово программерские илиты тупят.

Язык программирования — не инструмент.

Что по вашему тогда инструмент ? И что тогда по вашему язык программирования ?
Что по вашему тогда инструмент ?
то что работает, чем можно пользоваться без изменения мышления, а выполняя автоматические инструкции.
например еще НЕ инструменты — паттерны проектирования.
И что тогда по вашему язык программирования?
способ коммуникации, когда-то, вначале между человеком и компьютером, сейчас между людьми которых называют программистами.
Но как и с обычным языком — люди его используют не задумываясь о его свойствах.
Прикол случается тогда, когда они не задумываясь берутся рассуждать как филологи или лингвисты.

Scala — не инструмент, а язык более удобный для выражения мыслей, чем другие, для программистов определенной категории.
Haskell — не инструмент, а язык более удобный для выражения мыслей, чем другие, для программистов определенной категории.
Go, PHP, ... — о каждом можно сказать такое.

Инструментом можно назвать транслятор языка. Правда он используется программистами автоматически, и обычно без возможности его выбора.

но нелеп вывод что себестоимость программы зависит от выбранного ЯП.
как и заявления — «нужно выбирать язык под задачу», «для одних задач лучше один язык, для других — другой» (хотя некоторое рациональное зерно есть, как в мнении что итальянский для оперы, а немецкий для армии).

Тобиш если вы хорошо знаете пэхэпэ, то вы готовы взяться писать и высоконагруженные сервисы, и драйвера и ОС на нем, потомучто вам в нем удобнее мысли выражать, а те кто выбирают язык по задаче — жалкие неудачники? Я вас правильно понял ?

я вам уже задавал этот вопрос
если на основании моих уж 6000 постов на доу вы пришли к четкому убеждению что я полный кретин — то чем я вам могу помочь? ничем. кретинизм такого 6к уровня неизлечим. ;)

зачем же вы задаете такие идиотские вопросы?
не иначе чтобы всем показать что вот он — конченный недоумок?
;)

ну а дочитавших отсылаю подумать над моей фразой:

Инструментом можно назвать транслятор языка. Правда он используется программистами автоматически, и обычно без возможности его выбора.

Пару лет назад немножко потрогал Го, и первые впечатления были: «Ребята, вы серьезно? Си с GC и асинхронностью? Назад в 70-е — это, по-вашему, и есть инновации? Да и родословная от OS Plan9, чье название кагбе сознательно намекает на пожизненное лузерство? Да ну вас фтопку».

А вот сейчас смотрю еще раз и думаю, а может, как раз в простоте и есть вся сермяга? В конце концов, многие мощнейшие проекты до сих пор прекрасно себя чувствуют на чистом Си, и ничего лучше на новомодных языках до сих пор не напилили.

Ниша у Go определенно есть, но мне кажеться она сильно отлчаеться от Scala ниши

Конечно, т.к. у Scala нет ниши после прихода Go.

бггг ты добиваешся что бы тебя просто посылали сразу при появлении я так понимаю?

Все больше утверждаюсь что главный недостаток go это вовсе не отсутствие дженериков, и даже не отсутствие дебагера. Главный недостаток go это упоротое комьюнити. И дело не в том что плохие специалисты, нет, что Valialkin, что Данилюк, вроде не дурные люди, но вот это фанатическое помешательство на гугле и go, абсолютная вера в правильность идей Пайка и полное нежелание видеть другую сторону — это все сводит на нет.

у меня закралось это сомнение после того как в radio-t кажеться был совершенно нахрен поехавший малолетний гоферохам ( и кажеться бывший пехапешник) но после этого треда я в этом окончательно убедился :-)

Да, там не просто какой-то гофоман, там был один из ведущих golang show. Меня вообще удивляет само существование подкаста про go. Что там вообще можно обсуждать? Это же простецкий, примитивный язык для небольших задач. За выпуск, максимум два можно все фичи языка и практики обсудить. Разве что они там библиотеки обсуждают и новые проекты.

величие Пайка же обсуждать и объем его бицухи.

после прихода Go
Та приход что надо !
www.tiobe.com/...paperinfo/tpci/index.html
Если хочешь найди «Go» используй «ctrl + F» он восседает на троне между «EXEC. Forth» и «Hack, Icon»..... Чесно говоря нифига про такие языки и не слышал, как и про некоторые более передовые по сравнению с Гоу..... Приход просто ошеломительный....

Если про гоу слышали, а про языки, находящиеся выше по рейтингу, не слышали, то очевидно, что такой рейтинг не имеет никакого отношения к реальности.

PS. Гоу будет на первом месте по популярности в следующем году.

Если вдумаешся в смысл этой зомбофразы, поймешь что уже надо писать ’в этом’

Ну про Го я тоже не слышал, первый раз про него прочитал в этом топике

Пора вылезать из танка — на дворе год Go.

Если в самом начале года компьютер выиграл в Go у чемпиона Европы в пяти матчах из пяти (раньше считалось, что компьютеры не могут играть наравне с людьми в эту игру из-за слишком большой комбинаторной сложности), то это 100% год Go.

www.wired.com/...player-at-the-game-of-go

О_о

А какая связь между Го-языком и Го-игрой? Программа-победитель написана (как будто это имеет значение, но все же) на диалекте Lua.

Ну пусть даже есть сакральная, сокрытая от непосвященных вроде меня связь. Если Го-игру выиграл комп, то каким образом это «успех Го» ? Наоборот ведь.

Я понимаю, что опасно вникать в безумие, можно заразиться. Но, ради всего логического, к чему было это сообщение?

Взаимосвязь очевидная: как известно, Go так же как и Lua в отличии от scala имеет хорошо проработанный концепт коротинов, функции могут возвращать несколько значений. Однозначно, это успех Go.

Ну вот видите, Go покорил новую целевую аудиторию, в отличие от scala. Какие ещё могут быть сомнения в наступившей эре Go?

мне кажется он всех троллит... ну не может такого быть по-настоящему...

Та уныло. Если вначале еще был какойто энтертеймент, то сейчас тупо скучно смотреть на «дискусси» такого уровня.

PS. Гоу будет на первом месте по популярности в следующем году.
Ну это уже банальное трололо. Или же через некоторое время в обиход пойдет словосочетание новой болезни — «ГОвизм головного мозга», на подобии «православия головного мозга» и т.д.

Чуваки, разработавшие scalaz, точно болеют «скализмом головного мозга». А вот чуваков с «говизмом головного мозга» я пока не замечал.

Чуваки, разработавшие scalaz,
Покрайне мере, они не вопят в каждой ветке о том, что scalaz выйдет на первое место в следующем году.

Это потому, что даже они прекрасно понимают, что на первое место выйдет Go.

я спрашивал их мнение, в ответ услышал смех, и предсказание что через годик, два, будет кучка статей о том как го невзлетело.

Эти статьи могут быть исключительно в целях чёрного пиара Go, очевидно же.

Го виділяється серед інших настільки ж «популярних» мов лише тим що нею опікується гугл і постійні вливання не дають їй бути непоміченою.

Что-то Dart не взлетает. Тоже детище гугла.

Потому что Дарт должен был заменить js, при этом будучи в разы сложнее конкурента и не имея полную поддержку всех браузеров.

У Го другая ниша

Простота это хорошо, если не возводить ее в абсолют.

В конце концов, многие мощнейшие проекты до сих пор прекрасно себя чувствуют на чистом Си, и ничего лучше на новомодных языках до сих пор не напилили.

А разве был выбор? Там где нужен был перфоманс, или низкий уровень, приходилось использовать С, ну или С++ на худой конец. Потратили новонавернене количество человеко-ресурсов чтобы эти проекты запилить и потом поддерживать, но что делать, выбора не было. Сейчас есть go, rust, часть из этих задач они вполне могут взять на себя. По удобству не java/C# конечно, но уже гораздо лучше чем С/С++.

Предлагаю обсудить вот эту цитату:

I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” — Martin Odersky, creator of Scala.

Холливар насчет Go тут исколючительно упервется в точку зрения о том что го подходит везде и для всего, конечно го по ряду причин лучше чем С, и дает классные позвожмности и хороший перформанс из-за своей низкоуровневости, НО его никто кроме вас ни рассматривает в нишах которых не используется С, а вы его пытаетесь сравнивать с более высокоуровневыми языками, с которыми он конкурировать не должен по определению.

Я думал, что Scala и Go находятся на одном уровне — там, где Java и C#. Или вы думаете, что CTO, написавший блогпост о переводе его команды со Scala на Go, сошел с ума и решил сделать даунгрейд? Исходя из вашей логики, следующий пост от этого CTO будет о переходе с Go на asm :)

1. вполне вероятно что скала не подходила под все нужды компании и где-то была избыточна, вне зависимости от того на что он перешел.
2. Go подходит под их технические требования и справляется лучше чем скала, за что они готовы мериться с какими-то недостатками.
3. Они перевели на Go только часть сервисов там где Go хорош, там где лучше справляется скала оставили скалу.
4. Наверное в большинстве, если не во всех, книгах по микросервисам написано, что один из главных бенифитов это то что каждый сервис можно писать на наиболее подходящем языке.
5. И если будет место где максимально эффективно решить задачу можно будет разве что с асм, и выхлоп оправдает затраты на разработку и саппорт решения, то почему бы и нет?

Ну блин, о каком уровне ты говоришь? Джава, С# и особенно скала созданы для решения проблем на гораздо высшем уровне, и к этим задачам go очень далеко. Другое дело что эти языки использовались так же и для более простых задач, так как альтернатив особо не было, и вот эти задачи теперь можно покрыть на go.

Ну блин, о каком уровне ты говоришь? Джава, С# и особенно скала созданы для решения проблем на гораздо высшем уровне, и к этим задачам go очень далеко. Другое дело что эти языки использовались так же и для более простых задач

Было бы неплохо увидеть примеры задач «на гораздо высшем уровне» и «более простые задачи» в вашем понимании. Желательно, чтобы примеры были не сферическими конями в вакууме, а с линками на настоящие проекты.

Да любые задачи с бизнес логикой, с обработкой данных. То что в нормальных языках делается одной строчкой, в go без котстылей не обойтись. А все из-за того, что какой-то самовлюбленный фрик решил выкинуть нафиг дженерики, которые уже лет 10 как являются стандартом. Ну какие адекватные аналоги в go к этим конструкциям которые в типичном scala/C# проектах на каждом шагу?

var count = students != null ? students.Length : 0;
var rate = rates.First(r => r.From == "USD");
var rate = tickets.SortBy(t => t.Price);

Короче, хорошая задумка с go, хреновая реализация из-за маразматика Пайка.

Тому що це світоч для гошників, який просто не може бути неправий, і якщо він щось робить не так, значить так має бути

І да, го таки дитя Пайка. Не спорю що багато людей приймали участь в його створені, но головний ідеолог все-таки Пайк.

А что тут обсуждать, контекста-то цитаты нет. Может, Одерски просто вежливо ушел от ответа (когда отвечающий заинтересован, его ответ обычно более развернут и с примерами).

Ну и Го ориентирован на программистов «нижнего квартиля классификации», и для этой задачи он успешен. Вопрос в том, действительно ли это нужно программированию как индустрии. Я искренне надеюсь, что нет.

Для конкретного проекта выбор зависит, в первую очередь, от команды.

Ну и Го ориентирован на программистов «нижнего квартиля классификации»

Go ориентирован на программистов из Google. Если они принадлежат к 25% худших программистов, то где работают остальные 75% «лучших проораммистов»?

Квалификация бывает в разных областях, и здесь я имел в виду сугубо «квалификацию software engineering». Те человек может отлично знать нюансы работы ядра линукса или тонкости тюнинга SVM, но это слабо коррелирует с его способностью писать человекочитаемый и поддерживаемый код (очевидно, в разных ситуациях приоритеты навыков разные).

Уточню цитату, Го ориентирован на «молодых выпусников, с небольшим опытом работы». Те это очередная попытка сделать язык, в котором у вышеописанного программиста шанс написать хороший код будет выше среднего. Замысел отличный (та же Джава с чем-то похожим стартовала), и в своей нише Го хорош. Вот только эта ниша крайне узкая и специфичная, и за ее пределами Го как язык оставляет желать лучшего.

Го ориентирован на «молодых выпусников, с небольшим опытом работы».
...
ниша крайне узкая и специфичная
Прицел на эту нишу может выстрелить и в других. Скажем наблюдаетсяя некоторое оживление вокруг Го в инфраструктурных и около-девопских кругах, где у контингента часто разнородный уровень именно программирования-программирования и Го находится в неплохой sweet spot.

Вот для «инфраструктуры» Го крут, не буду спорить. Я, например, следующий «скрипт», когда в нем возникнет надобность, сделаю на Го, эксперимента для (до этого в основном Пайтон с Башем использовал). Для разных задач — разные инструменты, писать скрипты в 20-100 строчек на Скале глупо.

писать скрипты в 20-100 строчек на Скале глупо.

Кстати почему ? на 100 строчек скалы можно уложыть логики в несколько сотен строк слабочитаемого баша. Особенно если юзать аминит опс lihaoyi.github.io/Ammonite

Если скрипт будет запускаться один раз, то можно. А вот ждать прогрева Скалы несколько секунд (каждый раз) надоедает.

Можно, конечно, сделать какой-то висящий в памяти процесс, которому будет кормиться текст скриптов (например, через scala.reflect-овский ToolBox, он работает шустрее всего, что я пробовал), но это извращение. Придется думать про ограничения по памяти, сборку мусора, не будет ли глюков в выбранном велосипеде, и так далее.

В итоге, проще взять Пайтон для чего посложнее и Баш для несколькострочников.

Тут вопрос не в логике, а в настройке окружения. Запутанная структура попок (хотя может это из-за intellij), непонятно что куда складывается, что куда грузиться, на выходе куча джарников, зависимость от jvm. Это кстати главный недостаток по сравнению с тем же go где все просто и прозрачно. Для больших проектов это фигня, но для маленьких — лишний оверхед который хотелось бы избежать.

Установить джаву, а потом по инструкции выполнить

$ mkdir ~/.ammonite; curl -L -o ~/.ammonite/predef.scala git.io/v0FGW

$ curl -L -o amm git.io/v0FGO chmod +x amm; ./amm

Это бесспорно огромный и тяжелый кусок работый невыполнимый для большинства гоферов и пыхеров.

Всего то навсего ).

С другой стороны можно просто создать одни файлик с расширением .go или .py и тупо напедалить туда код. Не надо уподобаться гошникам и возводить все в абсолют. Каждой задаче свои инструменты.

С другой стороны можно просто создать одни файлик с расширением .go или .py и тупо напедалить туда код.

Ну, если питон еще во многих системах по умолчанию присуцтвует, то го, как минимум еще установить нужно, так что не все прям так гладко :-)
Каждой задаче свои инструменты.
Тут я не спорю, однако считаю что разширять кругозор и спектр возможностей — неплохо.
Для начала — вообще непонятно что делает компилируемый статический го в списке скриптовых инструментов. Всегда было
взять Пайтон для чего посложнее и Баш для несколькострочников.
Ну, если питон еще во многих системах по умолчанию присуцтвует, то го, как минимум еще установить нужно, так что не все прям так гладко :-)

Я даже больше скажу, в go еще дополнительно нужно окружение настроить, один раз для всех проектов. Настраивается быстро, за 5 минут, но все-равно, пол дня потратил чтобы разобраться что к чему и в чем логика этого всего. После — все становиться понятно и прозрачно.

Для начала — вообще непонятно что делает компилируемый статический го в списке скриптовых инструментов.

Статическая или динамическая типизация, скриптовый или нескриптовый язык, это все дело второе. Главное чтобы инструмент позволял решать определенные задачи c наименьшими телодвижениями. А go, несмотря на свою топорность и примитивность как языка, имеет довольно мощную библиотеку которая из коробки позволяет делать много чего без шариния в Интернете.

Ну, если питон еще во многих системах по умолчанию присуцтвует, то го, как минимум еще установить нужно

Для запуска программ на Go не нужен ни компилятор, ни стандартное окружение Go, ни внешние зависимости. Т.к. скомпилированная программа на гоу представляет из себя один самодостаточный бинарник, которому пофиг на внешние зависимости.

Т.к. скомпилированная программа на гоу представляет из себя один самодостаточный бинарник, которому пофиг на внешние зависимости.
тобиш один бинарник с «пофиг на внешние зависимости» можна и на винде и на юниксах вот так вот запускать? круто, че.

Бинарник под целевую платформу. Причем гоу компилятор на любой платформе может скомпилить бинарник под любую платформу.

Кстати, настроек компиляции что-то не увидел. Есть ли поддержка SSE для x64, или AVX. Скорее всего регистры SSE не юзаются никак. Делаются ли компилятором типичные оптимизации, или самому внимательно смотреть что пишешь в циклах.

Кстати, настроек компиляции что-то не увидел.

Потому что там только две настройки — переменные окружения GOOS (целевая операционная система — linux, windows, darwin, etc.) и GOARCH (целевая архитектура — 386, amd64, arm, etc.) — см. dave.cheney.net/...s-compilation-with-go-1-5 и golang.org/...nstall/source#environment .

Есть ли поддержка SSE для x64, или AVX.

Есть — см. например, github.com/...301badf1b762888e2c69e6c57 , github.com/...5235e838839c7847da7723378 , github.com/...b11f21ea462856aeb1f6ec0c0 , github.com/...8f07c82508f0fa88e6dd69ea7 .

Делаются ли компилятором типичные оптимизации, или самому внимательно смотреть что пишешь в циклах.

Делаются. См. неполный список тут — github.com/...iki/CompilerOptimizations . В версии 1.7 будет новый компилятор на основе SSA ( en.wikipedia.org/...ic_single_assignment_form ), на котором будет много новых оптимизаций — см. github.com/golang/go/tree/dev.ssa .

Жависты смотрят на пыхеров свысока — вместо принятого у пыхеров curl | sh они делают curl | java, и вместо скриптиков по трубе идёт 30MB сжатого энтерпрайзного байткода.

doublefacepalm.jpg

Остановите эту планету плиз, я сойду.

Ну, во первых, не джавы а скалы.
Во вторых 30 мб сейчас не критично.
В третих — если скрипты большие и мудреные, избавляться от шела имеет очень большой смысл.

dou.ua/lenta/articles/language-rating-jan-2016/
Статистика вот показывает, что у нас Go юзают люди с опытом, а язык при этом молодой. Видимо, глядя на другие языки, возможность избавиться от лишних абстракций выглядит привлекательно, и писать простой рабочий код.

Это кстати странно, так как после общения с местными гоферами складывается впечатление, что ничего кроме go они в глаза не видели, максимум питон/жаваскрипт/пхп.

возможность избавиться от лишних абстракций выглядит привлекательно, и писать простой рабочий код

Кстати есть такое ощущения, но такой же простой понятный код можно писать практически на любом языке, было бы только желание. У го преимущество что стандартная библиотека молода, которая писалась на основании существующего опыта под современные задачи. Поэтому она мощна, и в то же время не имеет ничего лишнего. У .net/java много оверхеда, который накапливался 10+ лет и который излишен или ненужен в большинстве современных задачах. Но и там активно все переписывается и упрощается, что позволяет писать легкий (по крайней мере снаружи), минималистический код.

Тоже обратил внимание на эту диаграмму. Думаю, что речь идет не об основном языке использования (иначе что там делают Паскаль с Бейсиком?). Но, в любом случае, это показатель, что Го метит в нишу «любимый рабочий язык менеджеров» (в хорошем смысле этого слова), ведь последние ориентируются на «что попроще», ввиду потенциальной ограниченности «кадров». Один из моих знакомых ругался на разные виды стрелок => -> (не считая кастомных) в Скале. Думаю, Го ему бы понравился больше.

Резюмируя, с тз программистов Го весьма уныл, а с точки зрения ПМов _может_оказаться_ предпочтительным. Осталось дождаться крупных проектов на Го. Лично я не верю, что одним взмахом руки Пайк уберет всю ту сложность, с которой борятся «лишние абстракции и накрученный ООП». Они часто overused, но и без них никуда.

Есть такие вещи как check style и т.п. которые всегда могут сделать форматирование и стилистику однообразной, ограничить язык просто, есть куча статик код анализаторов и т.п. которые можно встроить в билд, а вот расширить — нет.

Осталось дождаться крупных проектов на Го.

Уже дождались — Docker, Kubernetes, Cloudflare, etcd, CoreOS и т.д.

Докер, который на баше уместили в 100 строчек кода?
github.com/...bocker/blob/master/bocker

А если серьезно, тебе уже говорили что 16 мбайт исходников это фигня по современным меркам.

(кстати, почему в каждом проекте своя директория для зависимостей?)
(корреляция между количеством строчек кода и «размером» проекта, очевидно, сильная)

find . ! -path ’*/Godeps/*’ ! -path ’*/vendor/*’ ! -path ’*/third_party/*’ -name ’*.go’ | xargs wc -l

docker: 146877
kubernetes: 568527 (386469 с exclude ’*generated*’)
etcd: 82274

Я бы не назвал эти проекты уж очень крупными. У Kubernetes подозрительно большой отрыв, может, я забыл заэксклюдить чего? Ну и не стоит забывать, что Го не самый выразительный язык, что также сказывается на количестве строчек кода.

именно основном. С другой стороны — возможно это просто отражение того, что в малых группах больше аномалий

Гугл набирает академщиков, которые бы алгоритмы знали и олимпиадные задачки решали. То что у них хорошо и быстро мозги работают, совсем не означает что они хорошие, прикладные программисты, решающие реальные проблемы. Это одна из причин, почему у гугла не так уж и много успешных продуктов доведенных до ума. Большая часть либо подыхает на разных стадиях, либо страшные и неюзабельные. Приходят такие модные хипстеры, наговнокодят на го что-то, что как бы работает, но что с ним дальше делать и как этот говнокод разгребать не знают, поэтому сбегают на другой проект и так по кругу. Такой себе антипод эпла — тот из говна конфетку может сделать и продать, гугл же из конфетки делает говно, но все-равно часто умудряеться продавать из-за отличного пиара.

смиявсь

много, глубоко за гугл знаете, я смотрю — позвольте поинтересоваться откуда?

На гоу можно писать код под браузеры — github.com/gopherjs/gopherjs . Так что скоро он заменит не только node.js, но и 100500 over-complicated js-фреймворков под браузеры.

p.s. Насколько я понимаю, на скале такого нет.


p.s. Насколько я понимаю, на скале такого нет.
www.scala-js.org ?

просто гоферов в гуле банят
ЗЫ хуже чем писать js на каком-то другом языке наверное еще ничего не придумали.

ЗЫ хуже чем писать js на каком-то другом языке наверное еще ничего не придумали.

Утверждение спорное, но таки почемуто все эти языки невзлетают.

тайпскрипт взлетел, jsx взлетел для реакта

Беру свои слова обратно :)
Зато на хабре нет статей про скалу, криптовалюту и Катю, а про гоу, криптовалюту и Катю есть:

— habrahabr.ru/...ompany/dcoin/blog/272695
— habrahabr.ru/post/273333
— habrahabr.ru/post/274885

Это там, где народ просит убрать го нафиг и писать только про Катю? )

Это там, где пхп-программист успешно перешел на гоу.

www.scala-js.org

Вообще говоря, в джс сейчас разве что брейнфак не перегоняют, и то не факт.
github.com/...guages-that-compile-to-JS

Если повторить ходя бы успех ГВТ, то тогда сможете говорить об успехе этого проекта, а пока вызывает только улыбку

чем как GWT лучше сразу в топку без мучений

ну гвт использовали в продакшене. кофискрипт тоже.
А вот используют ли го, или туже скалу для компиляции в джс — вопрос.

Некоторые в теорию могут, но лично не видел и не слышал

у людей и кобол в продакшене есть но не стоит же повторять за всеми

Ну на фоне го -не самая худшая альтернатива:)

т.е. вы хотите сказать, что гоу — это фортран и кобол будущего?

нет, го _такой_ популярности не наберет никогда
надоест гуглю с ним возиться — и фсе, на свалку истории
фортан и кобол живи и сейчас, из-за _огромного_ количества легаси кода, тянущегося из 60-70-80-х
и то только потому что другие языки в те времена плохо подходили для решения финансовых и расчетных задач, а эти были заточены под ряд специфических областей и решали задачи на то время отлично
го на мой взгляд не имеет никаких конкурентных преимуществ кроме агрессивного маркетинга от гугля, в остальном — ниже среднего

ГВТ одна из самых успешных подделок подобного рода. Но годжс вряд ли дойдет до такой популярности, вряд ли даже дарт переплюнет

На гоу можно писать код под браузеры — github.com/gopherjs/gopherjs . Так что скоро он заменит не только node.js, но и 100500 over-complicated js-фреймворков под браузеры.
не заменит)
ибо:
1. это просто компилятор кода Go в джаваскрипт. А подобных языков и компиляторов уже есть воз и маленькая тележка, начиная с CoffeeScript и TypeScript, и заканчивая разными Dart’ами и
диалектами лиспа, написанными на джаваскрипте (типа такого lispyscript.com ).
2. Я знаю минимум 5 языков, для которых написаны диалекты, транслирующие код в джаваскрипт: Clojure (Clojurescript), Haskell (Fay, Haste, GHCJS), F# (Funscript), Scala.js (см. ниже), Standard ML (SMLtoJs — www.smlserver.org/smltojs ).
3. адепты ноды, реакта, ангуляра и метеора не дадут, чтобы их убили)))
p.s. Насколько я понимаю, на скале такого нет.
У скалы есть аналогичная хрень — Scala.js ( www.scala-js.org ).
Так что скалисты тоже могут запявить, что скала скоро убьет ноду и джаваскрипт))))

А я б еще добавил, что наличие такого зоопарка компилирующихся в Javascript языков, прямо говорит о говёности чистого Javascript, особенно при написании более-менее крупных приложений, в чем лично убедился на практике. Для небольших скриптов — пойдет, для остального — Welcome to hell!
Вот ClojureScript одобряю, пишешь и прям душа поет!

уже 1000 комментариев — неплохо пофлудили

В 4 раза больше чем на хабре, Ищенко должен быть довольным

Вот ради интереса пытаюсь написать маленький скальный проект на го.

Функция на скале:

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = {
    val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
    val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
    val url = s"http://query.yahooapis.com/v1/public/yql?q=$query...blahblah"

    for {
      response <- Http().singleRequest(HttpRequest(GET, url))
      json <- Unmarshal(response.entity).to[String]
      yahooResponse = json.decodeEither[YahooResponse]
    } yield yahooResponse
  }

Та же функция на го:

func GetExchangeRates(currencyPairs []CurrencyPair) (*YahooResponse, error) {
	pairsAsStrings := make([]string, len(currencyPairs))
	for i, pair := range currencyPairs {
		pairsAsStrings[i] = fmt.Sprintf("\"%s%s\"", pair.From, pair.To)
	}

	pairs := strings.Join(pairsAsStrings, ", ")
	query := url.QueryEscape(fmt.Sprintf("select * from yahoo.finance.xchange where pair in (%s)", pairs))

	u := fmt.Sprintf("http://query.yahooapis.com/v1/public/yql?q=%s...blahblah", query)
	response, err := http.Get(u)
	if (err != nil) {
		return nil, err
	}

	defer response.Body.Close()

	var res YahooResponse

	decoder := json.NewDecoder(response.Body)
	err = decoder.Decode(&res)
	if (err != nil) {
		return nil, err
	}

	return &res, nil
}

Знатоки go, что можно сделать с функцией, чтобы она выглядела менее печально и велосипедисто? Или хотя бы предложите как правильно отформатировать чтобы читалась легче. Спрашиваю абсолютно без издевок, просто не знаю всех тонкостей языка и гайдлайнов.

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = {
val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
val url = s"query.yahooapis.com/...c/yql?q=$query...blahblah"

for {
response <- Http().singleRequest(HttpRequest(GET, url))
json <- Unmarshal(response.entity).to[String]
yahooResponse = json.decodeEither[YahooResponse]
} yield yahooResponse
}

можна вообще весь реквест в фючу запихнуть, чтобы операция на мапаньи пеиров не блокировалась, и не бросала эксепшен вне фючера. Правда строчек чуть больше:

def buildCurrencyQuery(currencyPairs: Seq[CurrencyPair]):Future[String] = Future {
    val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
    val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
    s"http://query.yahooapis.com/v1/public/yql?q=$query...blahblah"
}

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = for {
     url <- buildCurrencyQuery(currencyPairs)
     response <- Http().singleRequest(HttpRequest(GET, url))
     json <- Unmarshal(response.entity).to[String]
     yahooResponse = json.decodeEither[YahooResponse]
    } yield yahooResponse

Разве что для эстетики — оверхед на создание Future будет больше, чем тот меппинг.

Тогда уж лучше так:

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = for {
	response <- {
		val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
		val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
		val url = s"http://query.yahooapis.com/v1/public/yql?q=$query...blahblah"

		Http().singleRequest(HttpRequest(GET, url))
	}
	json <- Unmarshal(response.entity).to[String]
	yahooResponse = json.decodeEither[YahooResponse]
} yield yahooResponse  
Разве что для эстетики — оверхед на создание Future будет больше, чем тот меппинг.
Да, я забыл что стандартный скаловский Future это, не ленивый scalaz Task. У нас все кому не лень уходят от использования фючэ и переходят на использование тасков. А некторые потом отправляються в свободное космическое плавание используя scalaz-streaming. Гранды говорят что этот фреимворк крут как яйца сталоне, и вообще. Мне самому пока толком покурить не удалось.
Можно еще так:

Этот вариант ничем от вашего первого не отличается. Читаемость субьективно несколько хуже. А вот юнитТестируемость лучче в варианте с двумя функциями, причем не важно под фьюче оно или нет.

Не Го-гуру но в принципе вроде ок, более значительного приближения к скале не получится.

Топорность да, поначалу немного чувствуется. Зато прямо как валенок и падаванам типа чуть ниже в этом треде Grez и его грандам негде развернуться — в этом многие видят очень большой плюс.

хотелось бы услышать клоуна который рассказывал про код на Go в 10 раз короче Scala

код на go в 10 разів коротше всього, не тільки скала. при чому, код на скала в 2 рази коротше коду на джава, але код на go рівно в 10 разів коротше коду на скала і коду на джава. от такий він, суровий go.

але з позитиву — нарешті знайдено ту єдину, правильну і аху*нну мову програмування, якій всі інші мови тихо заздрять. 5 років тому це був пітон, зараз всі вже нагамнокодились пітоном по самі нехочу, і тепер всіх врятує go

Ну ніша пітона нікуди не ділася, просто її починає окуповувати go, відбираючище ще й ніши всякого трешака тіпа nodejs.

go насправді не такий же і поганий, топорний правда місцями, але простий і прямий як пробка, при цьому доволі потужний. Такий собі американський muscle car серед машин.

та я і не казав, що пітон кудись дівся, просто пітонщики люто доводили, що пітон він єдиний і ідеальний, все решта гамно. а на ділі, всі замахалися сапортити гори динамічного гамнокоду на пітоні, і він лишився там, де і був, в своїй ніші тулзів і маленько-середніх проектів, де важливо швидко накидати робочий варіант чогось.

гоу такий самий нішевий з дуже сумнівними плюсами, і будемо відверті, убогими інструментами і багатьма дитячими проблемами. через пару років всі про нього забудуть і хіпстери перейдуть на нову мову з банановим смаком, які всіх зарішає і буде ідеальною, це як з фреймворками

Що не кажи, але плюси go очевидні — можливість писати швидкі, легкі, компільовані, програми, а вчити C, C++, haskel влом.

Ну, якщо появиться щось нове яке усуне проблеми і недоліки go — чому б і ні? Прогресс — це завжди добре ).

Го создает очучение местами чуть улучшенного, местами чуть упрощенного паскаля.
Ниша у паскаля уже была, и весьма огромная, но, почемуто — уплыла в дальние дали. Посмотрим что с Го будет.

Как язык скорее всего да, не далеко от паскаля ушел, но вот довольно обширная стандартная библиотека плюс легкость в подключении сторонних пакетов, плюс хорошая concurrency модель — делают го довольно продвинутым и практичным инструментом. Такая себе рабочая лошадка для тривиальных, не слишком больших задач. Так что успех у го и гоподобных языков будет, особенно учитывая что сейчас мода на минимализм (в контексте упрощения) и микросервисы.

Если бы они не падали в крайности и добавили бы некоторых плюшки из C#, scala — могла бы получиться золотая средина.

Все на что-то похоже, и все — уникально.

ИМХО Паскаль-Дельфи от нас ушел потому что:
Был упущен момент пришествия веб. PHP + Adobe Flash(Flex) в массовом вебе и Java в корпоративном оказались более адекватным средствами. А потом и Ruby сделал Рельсами контрольный выстрел в голову.
Паскаль-Дельфи так и не смог победить предложение для разработки GUI приложений от MS. а выход .NET окончательно лишил Паскаль-Дельфи преимуществ. Расширение же до ASP.NET добило бы его и без указанных выше успешных «веб яп»

т.е. Даже если бы Go был копией языка программирования Паскаль — у него будет другой путь. Его рантайм уже сразу реализован по другому.

Кроме того, Борланд упёрся в продвижение своей библиотеки VCL, прямо конкурирующей с MFC и несовместимой, причём слезть с неё и не использовать было затруднительно. Всё бы ничего, только они конкурировали на чужом поле.

Был упущен момент пришествия веб
Ну у уеба своя ниша. А , например, в научной тематике так и рулят плюсы, Фортраны, даже тот же Пасхаль у седобородых, ну и из новых Эр, Пытон и таже Скала... Про Гов наверно и не слышали...

тотже спарк, кроме скалы имеет биндинги только на Рэ, питон и джаву, и все.
Это говорит о многом :-)

да, не хватает интерфейса на PHP.

Я вот более-менее матерый джавист, но если бы начинал новый стартап, то писал бы на го. Потому что вместо одного джава синора за $4000, я смог бы нанять целую команду джунов и обучив их писать более-менее сносный код по SOLID и по TDD и затем вполне себе продуктивно релизить фичи.
Для меня самый большой плюс — простота, это дает несравненные экономические преимущества перед другими экосистемами.

так в этом и прелесть Го — на нем разработка дешевле

дешевле — измеряемый критерий.
а что такое — «лучше»?

это таже цена в будущем.
дешевле сразу != дешевле потом.

То есть будущее уже можно посчитать.
Не знал.

Как то наоборот встречал — не пишите код который может пригодиться в будущем. Потому что он наверняка — не пригодится.

Вам как специалисту должен быть знаком термин «технический долг» ?

По моему вы относитесь к тем кто уверено записал меня в невежды во всем.
К чему тогда ваш вопрос?
Конечно я впервые от вас услышал это словочетание.

Вообще, это прикольно, почему умники что-то мне дауну отвечают...

Ну, что я могу на эт сказать?
Выставляя, свое мнение на показ, которое противоречит мнению «основных масс» — будь готов к трололо-нападкам.

На ~90% (на взгляд) это так. Но остаются интересные 10%, когда можно и нужно пытаться предсказывать и идти вперёд. Собственно, в умении это предсказать и проявляется опыт. Я пытаюсь периодически пересматривать свои старые решения или просто высказанные пожелания на тему, состоялось такое изменение или нет, иногда очень интересные вещи находятся...

Собственно, в умении это предсказать и проявляется опыт.
не согласен .
опыт в данном случае проявляется в том, что код в котором нет никаких предположений о будущем будет легче модифицироваться, чем код неопытного.
частный случай такого подхода кода мной обсуждался на примере reset($arr) в двух темах — для того чтобы код не был хрупок, менее связан — избегайте предположений не только о будущем, а и о настоящем, если без них можно обойтись. как понял — понят не был, и всячески разнообразно заклеймен позором :D

предположения о будущем сродни преждевременной оптимизации. с тем же эффектом — усложнение кода при высокой вероятности бесполезности этого усложнения.

Но остаются интересные 10%, когда можно и нужно пытаться предсказывать и идти вперёд
для этого нужно быть визионером типа Джобса. и бросать программирование.
частный случай такого подхода кода мной обсуждался на примере reset($arr) в двух темах

Мнэээ... я практически не разбираюсь в PHP и не могу оценить дискуссию. Насколько я понял по результатам гугления и чтения, шла речь о том, что «массив» в PHP это или сущность из последовательно нумеруемых элементов, или мапа произвольных ключей, форсировать только один из этих вариантов нельзя, реально массив может содержать оба типа ключей, и использование одного вместо другого даст кашу и неожиданные побочные эффекты. Я правильно понял? Если да, то я вообще не знаю, что тут можно и как предсказывать с таким диверсионным рантаймом, и чи не лучше будет вообще перейти на другой язык. Но при всём при этом я не понял, где тут вообще «предсказание» будущего.

для этого нужно быть визионером типа Джобса. и бросать программирование.

Зачем? Я говорю о более простых случаях типа «тут надо не позже чем через полгода поменять алгоритм, не дожидаясь горьких плачей клиентов, потому что через год нагрузка будет больше в 20 раз».

я практически не разбираюсь в PHP и не могу оценить дискуссию.
а там я ее быстро постарался увести от PHP на более универсальные, и фундаментальные вещи.
Если да, то я вообще не знаю, что тут можно и как предсказывать с таким диверсионным рантаймом
никакого диверсионного рантайма нет.

а речь там о том что — видя швейцарский нож люди не врубаются что штопор — не обязательно существует только в швейцарском ноже.
и в итоге, видя штопор в отдельном исполнении предполагает что где-то там спрятано и лезвие ножа.
и когда пишут код «использовать штопор» дописывают — «ковырнуть лезвием, если пробка туго идет»

то есть там диспут вышел о мышлении.

Я говорю о более простых случаях типа «тут надо не позже чем через полгода поменять алгоритм, не дожидаясь горьких плачей клиентов, потому что через год нагрузка будет больше в 20 раз».
откуда вы знаете что нагрузка будет больше в 20 раз через полгода?
как вы получили эту информацию из будущего?

как ниже ответили — саппорт процедурного спагетти через 3-5 лет будет стоить оочень недешево:)
хотя возможно именно этого гоферы и добиваются
хотят стать в одну когорту со злыми коболерами:)

Понятно теперь почему саппорт систем на джава весьма дорог.

Ещё будет интересно посмотреть во сколько обойдётся саппорт фронтендного новья в виде ангуляров.
По той сложности которую уже ваяют...

Процедурный же стиль плох не из-за спагетти.

Ещё будет интересно посмотреть во сколько обойдётся саппорт фронтендного новья в виде ангуляров.
По той сложности которую уже ваяют...
Вот тут соглашусь на все 100500%
Процедурный же стиль плох не из-за спагетти.
Это одна из причин, но не главная. Главная в том, что этот подход устарел на 30 лет
Главная в том, что этот подход устарел на 30 лет
технологии не физические сущности чтобы стареть.
«устаревание» технологии это следствие ее свойств, и появления, развития технологий, которые предлагают что получше.

т.е. «подход устарел» — ничего не поясняет. подход может и помолодеть.

Не вижу предпосылок для «помолодения» процедурного подхода

я к тому что в аргументе «подход устарел» ровно столько же смысла сколько и в «подход помолодел».

Ну Вы же не будете спорить, что допустим использование и дальнейшая разработка паровых машин двойного расширения потеряла смысл? Вот так и с концепциями в разработке ПО

Что можно вежливо ответить на пост с классическим демагогическим ходом и аналогией в качестве аргумента?

Ну если Вы не хотите или не можете обосновать свою точку зрения, то ничего отвечать не надо.

Смотря что писать. Если вебсервер который файлы отдает — то да.
Если нечто большое и долгоживущее, я бы воздержался.
Тыщи строк процедурного кода от кучи джунов это ад похлеще «абстракных адаптеров фабрик синглтонов» написанных джава синиором.

Тыщи строк процедурного кода от кучи джунов это ад похлеще «абстракных адаптеров фабрик синглтонов» написанных джава синиором.
В том то и дело, что пока джава джун будет изучать спринг, джуниора гофера можно натаскивать писать читаемый код с интерфейсами (low coupling), тестами и более-менее сносным дизайном. Тем более, что есть код ревью.

Только система на Java выдержит миллионы запросов пользователей и не «ляжет». А то что написано «побыстрее» — не факт.

Если у стартапа есть миллион пользователей, то и пара десятков лямов инвестиций тоже. А значит проблема с количеством запросов не критичная. Кроме того, golang отлично скейлиться.

Разве в джава мире нет более легких альтернатив для простых задач? Или там принято спринг везде пихать? Просто в том же .net веб сервис для микросервиса можно в три строчки поднять и никаких особых знаний не нужно.

В Джава-мире принято на спринге делать абсолютно все — даже в простейшей консольной тулзе обязательно должен быть спринг во весь рост.

(И это, сука, бесит!...)

Какоето время назад груви с этим боролся.
Сейчас почемуто скала в таком ключе временами используется.

Почему стандартно дефакто на каждый файловый сервер подразумеваеться использование либо спринга либо жее, для меня до сих пор загадка.
Например мои первые проекты были на тупой джаве СЕ с томкате.
Зато потом, если оно было написанно с ревью, можно рефаторить под спринг итд.

Фишка в том что сейчас джун без спринга нафиг не кому не нужен.

Если нечто большое
так это как проектировать.
большое — не означает монолитное.
Тыщи строк процедурного кода от кучи
я тут в очередной раз присматриваюсь к GroupWare софту, почитал про Liferay, не следил лет 5.
300 мб джарников, позакрученные API, и т.д. и т.п.
джуны писали? или все же это результат монолитного приложения на «абстракных адаптерах фабрик синглтонов»?
так это как проектировать.
большое — не означает монолитное.

Если не монолитное, то либо модульное, либо (микро)сервисное.
Все эти подходы имеют pros & cons, и при неблагоприятных обстоятельствах превращают работу в ад.
я тут в очередной раз присматриваюсь к GroupWare софту, почитал про Liferay, не следил лет 5.
300 мб джарников, позакрученные API, и т.д. и т.п.
джуны писали? или все же это результат монолитного приложения на «абстракных адаптерах фабрик синглтонов»?
Вас, как всегда тяжело понять. Вам не нравиться джарники и позакрученные API ?
Предложите ваш вариант, так чтобы функционально, гибко и секьюрно.
функционально, гибко и секьюрно.
если нечто сложно, дорого изменить — то это уже не гибко.
Предложите ваш вариант,
в ИТ постоянно что-то предлагается. что-то оказывается просто мечтами, что-то навозом для другого предложения.
Вам не нравиться джарники и позакрученные API ?
джарники такое дело. а вот чтобы кому-то нравились позакрученные API — как-то не слышал.
новичкам может быть. а так, обычная жалоба самих джавистов на монстров разростающихся годами.
и мой посыл был в том что монстров этих творят вовсе не джуны, и не тыщами строк процедурного кода.
если нечто сложно, дорого изменить — то это уже не гибко.
Проблема растет из за меняющихся требований.
Можна для примера смотреть какойнить опенГЛ.
Умные дяди несколько лет посидели, придумали требвания, и выкатили довольно хороший (как для процедурного) апи. И посмотрите во что этот апи превратился за годы добавления всяких фичь, шейдеров и прочего.
позакрученные API — как-то не слышал.
новичкам может быть. а так, обычная жалоба самих джавистов на монстров разростающихся годами.
и мой посыл был в том что монстров этих творят вовсе не джуны, и не тыщами строк процедурного кода.
Ну давайте возьмем пример из процедурного мира, старый добрый выньАпи32. Комуто когдато нравилось с ним работать ?

То есть это жизнь такая, а не подход.
По второму пункту — то что и говорил ранее — объективную сложность нельзя уменьшить, можно лишь выбирать подходы по управлению сложностью

Это все да.
Однако, мое мнение (и не только мое) осталось при мне — при разработке больших систем (особенно монолитов) используя процедурный подход, они в целом в итоге получаются тяжелее в поддержке чем ооп подход. И какихто качественных аргументов что это не так, я от вас так и не увидел.

Однако, мое мнение (и не только мое) осталось при мне — при разработке больших систем (особенно монолитов) используя процедурный подход, они в целом в итоге получаются тяжелее в поддержке чем ооп подход.

Ответьте, пожалуйста, на следующие вопросы:
1. В каком стиле написано ядро линукс? Подсказка — github.com/torvalds/linux
2. В каком стиле написано ядро виндовс? Подсказка — technet.microsoft.com/...ysinternals/bb963901.aspx
3. В каком стиле написано ядро макоси? Подсказка — *BSD.
4. Линукс, виндовс и макось — это большие (монолитные) проекты?
5. Почему мы до сих пор не видим операционных систем, написанных на новых языках программирования (джава, сишарп, скала, джаваскрипт, С++ и свифт) с «родной» поддержкой ООП и других крутых парадигм типа функциональности и метапрограммирования?

5. Почему мы до сих пор не видим операционных систем, написанных на новых языках программирования (джава, сишарп, скала, джаваскрипт, С++ и свифт) с «родной» поддержкой ООП и других крутых парадигм типа функциональности и метапрограммирования?

потому что, винда и линукс были написанны во времена когда ничего кроме си небыло? А изобретать велосипеды долго и дорого ? Впрочем велосипеды есть но они без инфраструктуры, прикладных программ и драйверов никому не нужны, например таже en.wikipedia.org/...larity_(operating_system .

omg, если ваш клиент в состоянии вложить столько же ресурсов сколько было вложено в винду или мак ось или ядро линухи, то почему бы и нет?

В каком стиле написано ядро линукс?

В объектном. Да, на C, а не C++. Код вида


 if (file->f_op->read)
  return file->f_op->read(file, buf, count, pos);
является вызовом виртуальной функции объекта по указателю. И так там практически во всём.
В каком стиле написано ядро макоси? Подсказка — *BSD.
Подсказка неверна и попросту некомпетентна, для «ядра макоси» микроядерность и обмен сообщениями существеннее вопроса процедурность/объектность.
Почему мы до сих пор не видим операционных систем, написанных на новых языках программирования
Потому что не умеете даже элементарно гуглить. BeOS была целиком на C++ и не выжила не потому, что на нём написана, а потому, что все ниши были заняты, а 1e11$$ на выдавливание конкурентов не нашлось.

Так что сплошное «мимо» по всем пунктам.

Почему мимо? Тут некоторые утверждали, что C и Go годятся только для процедурного кода, т.к. в них «нет поддержки ООП», т.е. нет наследования и полиморфизма «как в C++ или Java». Надеюсь, теперь они прозрели.
Насчет последнего пункта — основная причина, по которой BeOS не взлетела, — C++ слишком сложный по сравнению с C. Поэтому не нашлось достаточно профессиональных разработчиков для ее развития. Погуглите, что думает Линус Торвальдс о C++ и C++ разработчиках.

Погуглите, что думает Линус Торвальдс о C++ и C++ разработчиках.

Видел. Торвальдс слишком агрессивен. Но он прав в том, что ООП на C для специфики ядра обеспечить легче, чем на C++.

C++ слишком сложный по сравнению с C. Поэтому не нашлось достаточно профессиональных разработчиков для ее развития.

Нашлось бы, если бы были деньги.

Тыщи строк процедурного кода от кучи джунов это ад

Интересно, ООП-шников на курсах процедурным стилем запугивают, что ли?
«Плохого» или какой-то синоним. Просто «кода от кучи джунов», ok, все начинают с ошибок.

Тыщи строк процедурного кода от кучи джунов это ад похлеще «абстракных адаптеров фабрик синглтонов» написанных джава синиором.

На самом деле джуны любят городить бесполезные абстракции, т.к. полагают, что это покажет их «крутость» по сравнению с остальными. Настоящие синиоры же предпочтут лаконичный код без лишних абстракций.

Синьйоры синьйорами рознь.
Имел дело с очень эрудированными ребятами в цс. Но которые в работе на таску «зафигачить данные из базы в цсв файл», где у джуна это займет день работы и пару сотен строк джава кода, а у обычного синьйора чтобы сделать энтерпрайзнинько со спрингом, ДИ, гибкой моделью, мониторингом и юнит тестами — два дня. У данного индивида заняло больше двух недель времени, и в конце он выкатил 50+ (!!!) классов абстрактных фабрик адаптеров. Причем чел реально умный был, математек, все такое.

Вот о том и мой посыл был. Что дело нередко даже не в джунах, не говоря о парадигмах

Я с этим и не спорю.
Даже в модной нынче функциональненькой парадигме, которая вроде как призвана облегчить понимаемость и обслуживаемость кода — можно такого на г-кодить что сам черт ногу сломит лопотаю это разгребать.

Даже в модной нынче функциональненькой парадигме, которая вроде как призвана облегчить понимаемость и обслуживаемость кода — можно такого на г-кодить что сам черт ногу сломит
естественно можно, особенно, если чел до этого писал тока на процедурных и ООП языках и поэтому привык писать в императивном/ооп стиле)

Кстати, многие наврное с этим не сталкивались, но в Go есть полноценные замыкания, а там своя парадигма, несколько отличная от функциональной. Код можно писать как дерево замыканий, и внешний вид будет значительно отличаться от привычного кода на распространённых языках, особенно с коротинами.

Может у него там были предусмотрены все нюансы асинхронной записи больших объёмов, которые наверняка никогда не попадутся на практике в связи с ограниченным числом пользователей и никому ненужностью системы. А так бы иначе без классов вовсе обошёлся.

нет, там были абстрактные фабрики адаптеров, которые строили гибкую возвращаемую модель, на гибком дао, с конфигураторами, билдерами билдеров и репозиториями.
Отличный пример экстримального over-engeneering о котором тут постоянно жалуются.

4 го джуна != 1 джава синьер

Умение писать код на определенном языке и умение разрабатывать рабочие системы продакшн уровня, которые нужно поддерживать годами — это совсем разные вещи. Так что если нужно набросать что-то небольшое, что потом в случае чего не жалко выбросить и переписать с нуля — тогда команда джунов-гошников может потянуть, если же что-то больше, то нужны синьоры, а синьор гошник будет стоить те же $4000.

которые нужно поддерживать годами
стартап на ранней стадии
Не вписаться в рынок опаснее чем отрефакторить/переписать быдлокод :)

Саксес стори разные бывают.
Много из разряда «фигак фигак и в прадакшен». Но есть и такие где «Мы сделали хорошо, и убили конкурентов качеством».

Чаще всего я лично вижу: «пилять, да кто за это деньги вообще платит и почему?!»

Off topic: а кто может подсказать литературу по Scala для начинающих? Кто как её учил?

Лично я начал с Хорстман К. — «Scala для нетерпеливых». Потом курс на www.coursera.org/course/progfun .

Вот хорошая серия статей, правда перед этим желательно ознакомиться с языком и ФП:
danielwestheide.com/scala/neophytes.html

Самое главное в изучении scala, это знакомство со scalaz отложить на по-дальше и по реже заглядывать в исходники библиотек ). Это сильно бьет по мотивации изучать дальше.

Самое главное в изучении scala, это знакомство со scalaz отложить на по-дальше и по реже заглядывать в исходники библиотек ). Это сильно бьет по мотивации изучать дальше.

Это как заглянуть в исходники boost’а или STL’а для C++ - см., например, реализацию vector — github.com/...include/bits/stl_vector.h :) Это говорит о сложности языка программирования. В гоу исходники библиотек читать намного проще — см. golang.org/src .

Рад за go, это реально преимущество и этого у него не отнять.

Вот только читать код мало, надо его понимать, видеть смысл, и тут уже больше от программиста зависит чем от языка. Взять к примеру первую попавшуюся функцию из одного популярного http сервера написанного неким Aliaksandr Valialkin )

func clientDoTimeout(req *Request, resp *Response, timeout time.Duration, c clientDoer) error {
	if timeout <= 0 {
		return ErrTimeout
	}

	deadline := time.Now().Add(timeout)
	for {
		err := clientDoTimeoutFreeConn(req, resp, timeout, c)
		if err != ErrNoFreeConns {
			return err
		}
		timeout = -time.Since(deadline)
		if timeout <= 0 {
			return ErrTimeout
		}
		sleepTime := (10 + time.Duration(rand.Intn(100))) * time.Millisecond
		if sleepTime > timeout {
			sleepTime = timeout
		}
		time.Sleep(sleepTime)
		timeout = -time.Since(deadline)
		if timeout <= 0 {
			return ErrTimeout
		}
	}
}

Ну и как тут читаемость go поможет мне разобраться в функции?

Какой sleep вообще на сервере, усыпить поток ОС чтоли? В Go, насколько помню, крутится количество потоков, пропорциональное числу ядер, что если попадутся столько же клиентов одновременно в этом коде?

Это go, там до потоков ОС тебя никто не пустит. У них есть свои потоки, их много, они легковесны, есть менеджер который сам распределяет их по потокам ОС, точнее по ядрам процессора. C этими гошными потоками можно делать все что захочешь — можешь слипать, можешь вешать ненужные операции, можешь вешать IO запросы, менеджер потоков все разрулит. С точки зрения программиста, ты тупо педалишь синхронный код, который потом скармливаешь гошным потокам в местах, где нужна ассинхронность. Короче go развращает программистов в работе с потоками так же, как сборщик мусора развращает в работе с памятью.

It’s ok, до тех пор когда тебе не нужна действительно хорошая оптимизация, для типичных энтерпрайзов сойдет.

К нас этот код обслуживает на одном компе до миллиона одновременно подключенных клиентов, генерирующих 100К запросов в секунду. На каждого клиента выделен отдельный поток. Подробности тут — github.com/...valyala/fasthttp/issues/4 .
Это хорошая оптимизация или энтерпрайз приложение?

Потрясающий результат, и это судя по всему на блокированных сокетах. Если предположим достаточно большой канал связи, на чём предел возникнет — на загрузке проца, или на потреблении памяти? В Go нет такой темы как в JVM, что данные жрут лишнюю память? И что там с циклами сборки мусора?

Потрясающий результат, и это судя по всему на блокированных сокетах.
С точки зрения программы на Go сокеты блокирующие. На самом деле Go работает с неблокирующими сокетами. Но все эти epollы с event loop’ами и state machine’ами спрятаны в рантайме Go — программист работает с обычными блокирующими сокетами.
Если предположим достаточно большой канал связи, на чём предел возникнет — на загрузке проца, или на потреблении памяти?
Обычно программы на Go потребляют намного меньше памяти по сравнению с аналогичными программами на Java. Например, наша прога потребляет 10Гб памяти при обслуживании миллиона одновременных подключений. Так что узким местом, скорее всего, окажется CPU, который будет не в состоянии обработать слишком большое количество сетевых пакетов.
В Go нет такой темы как в JVM, что данные жрут лишнюю память? И что там с циклами сборки мусора?

Проблема с потреблением лишней памяти в Go встречается намного реже, чем в Java. При желании ее можно легко побороть с помощью встроенного в Go профилировщика памяти.
Сборник мусора в Go до недавнего времени мог тормозить при большом хипе, но начиная с версии 1.5 теперь все ОК. В 1.6 обещают, что максимальная задержка исполнения программы из-за GC не будет превышать 20мс на хипе в сто гигабайт.

Миллион работающих соединений — это действительно впечатляет, учитывая что 15 лет назад была так называемая проблема 10K. Я некоторое время назад написал сервер на IOCP-сокетах, работающий с несколькими десятками тысяч, правда на старом железе. Узким местом тоже была загрузка процессора. Производительность значительно проседала за счёт общения с БД, основные оптимизации касались именно этого...
Если GC будет очищать 100G мусора за 20 мс — это тоже что-то невероятное. Судя по всему, GC программистом не управляется, и механизм его работы в Go не совсем понятен. Может он очищает единоразово, или может по мере исполнения кода (какова агрессивность сборщика), настраивается ли объём кучи до вызова сборщика.

ну сторедж на мой взгляд остается главным бутылочным горлышком большинства проектов в кровавом ентерпрайзе. Я производительностью довольно давно занимаюсь и могу сказать что проблемы в основном из за

— косячного доступа к данным. когда берут слишком много или слишком часто и пренебрегают кешированием или делают его не правильно
— косячной организации стореджа ( нет индексов плохая структура и тп)
— все остальные проблемы — 20% от общего числа

Я работу с БД сделал следующим образом: когда юзер авторизуется, читаются единоразово все его данные, в дальнейшем больше ничего не читается, а только периодически отправляются апдейты. Между запросом и ответом клиенту, общение с БД — тоже исключается.
Главное бутылочное горлышко — это если при горизонтальной интеграции серверов синхронизация идёт через БД, это уже относится к архитектуре в целом.

хорошо когда маленькая система )
а когда продажа одного асета через интерфейс с биржой порождает shitstorm из тыщи другой запросов — уже поздно пить боржоми

Если GC будет очищать 100G мусора за 20 мс — это тоже что-то невероятное
20мс — это максимальная задержка исполнения кода программы в связи с работой GC. Например, если среднее время обработки запроса к серверу на гоу составляет 1мс, то максимальное время запроса при 100Гб хипе будет равно 21мс. Это вовсе не означает, что гоу чистит весь хип за 20мс.
Судя по всему, GC программистом не управляется, и механизм его работы в Go не совсем понятен. Может он очищает единоразово, или может по мере исполнения кода (какова агрессивность сборщика), настраивается ли объём кучи до вызова сборщика.

В гоу есть только один параметр для настройки GC — максимальный объем мусора, выраженный как процент от объема полезных данных в хипе. По умолчанию он равен 100%. Например, при хипе в 1Гб максимальный объем мусора будет тоже 1Гб, а максимальный объем используемой памяти будет равен 2Гб. Подробности тут — blog.golang.org/go15gc .

звучит хорошо, но я так понимаю это сервер для приложений? и сравнивать его надо например с томкатом или резином, а не каким-то конкретным веб приложением?

Ещё интересно насчёт сервера: что делаете для проверки обрывов соединения, когда клиент отвалился, а FD_CLOSE не приходит? Пингуете, или так и висят? Запросы пинга посылает сервер на клиент, или клиент обязан сам периодически отправлять уведомления? И как часто?

У нас ограничено максимальное время до получения следующего запроса от клиента. Если следующий запрос не пришел в течение этого времени, то соединение закрывается.

Ну понятно. Значит, рассылки уведомлений сервером — нет в модели общения.

Ну для типичных энтерпрайзов сам go очень низкоуровневый. Вот если надо написать небольшой сервис, с незамысловатой логикой, обслуживающий много клиентов, то тут go может выручить.

ну он наверно может хорошо пойти простые сервисы с котиками писать — если выбирать Node.js или Go-lang я бы Go выбрал 100%
а для ентерпрайза инфраструктуры нет — даже говорить пока не очем

А бекенд или фронтенд?
Недавно смотрел на ноду, был в шоке когда узнал что там имеет значение очередность объявления методов контроллера. Вообще сложилось мнения, что нода относительно крутая и реально шаг вперед для людей которые пишут например на php, но явно шаг назад по сранвению с ror или java+spring mvc или чем-то подобным(может в каких-то коренр кейсах и выиграет но в целом организация и разделение кода + общая читаемость явно хуже), хотя с другой стороны реально круто использовать тот же хендл бар как дефолтовый темплит энжин...

шо фронт, шо бек.

был в шоке когда узнал что там имеет значение очередность объявления методов контроллера.
открою для вас секрет, очередность обработки роутов так или иначе есть везде. ибо в итоге всегда строится некая таблица роут — обработчик. просто в том же експресе оно очевиднее, ибо там нет такого понятия как контролер, там есть хендлеры роутов которые добавляются к серверу.

нода не особо конкурент джаве или си шарпу, но ее ниша далеко не всегда пхпешная.

она очень подходит для программ которые идеально описываются при помощи событийной модели.

понятно что таблица роутов строится ± всегда, но сложилось такое впечатление что в экспрессе она не будет ждать проверки всех вариантов и вернет первый более менее подходящий(грубо говоря это уже не таблица, а какой-то массив с переборкой по примитивному матчингу), тем временем как в том же java бейсд апликейшене пройдет матчинг по все таблице, а только потом будет какой-то возврат условного 404(хотя может есть какие-то редкие корнер кейсы).

На самом деле — таблица от масивов в данном контексте не сильно отличается. А вот колизи вы и в джава создать можете. Но, если честно ни разу не видел чтобы в експресе из-за этого проблемы были, просто надо нормальный роутинг писать, а это делают почти все

ну я ж не знаю с каким бекграундом люди начинают — может как раз хорошо зайдет, весело задорно — это вам не унылый Одерски

думаю было бы клево, если бы кто-то написал книженцию а-ля learnyousomeerlang.com , только про скалу. Типа «Изучай Scala во имя добра».

а у меня эта книжка что то валяется без движения- не идет хоть ты тресни :|

Мне понравился курс www.udemy.com/...va-developers-ru/learn/ Он стоит 199 дол, но там часто акции бывают и его можно купить за 15 дол.

У нас в scala-дайджест #0 была подборка: с чего начинать обучение. dou.ua/...a/digests/scala-digest-0

А тем временем пришол неподтвержденный инсайд:

fwiw I talked to a (functional) Scala developer at Crowdstrike about that blog post, and they said that they hated the blog post, but it prompted them to finally resolve the go/scala tension that had long been present there, and that things are actually much better for the scala devs now.
Basically they came to a consensus on “we’ll use Scala for X and Go for Y and when we use Scala we can write idiomatic functional Scala instead of trying to write it to be familiar to Go devs”
at least that’s my understanding

Такчто, гомагедон отменяется.

Ничего себе инсайд! Про него в оригинальном блогпосте было написано:

Scala will not be leaving our stack completely. In fact it will complement where Go does not shine. Scala is a big part of our machine learning / analytics stack. It’s interop with java projects we use, and its ability to provide a nice DSL that our analysts can use still make Scala a solid choice.
Перевод для плохо владеющих английским :

Скалу оставим для всякого матана, где ей и место. А 95.7% продакшн кода будет на гоу.

Про него в оригинальном блогпосте было написано:

Было написанно так, быдто действительно

95.7% продакшн кода будет на гоу.
На практике же подругому выходит.

Угу, парсер логов и другие тулзовины для внутреннего употребления

ну вот к сожалению у хаскеля такая репутация что бизнес от него шарахается как черт от ладана а scala можно протянуть как почти java LOL

ну, от scalaz тоже все шарахаются как могут.
Нету какогото понимания, какие такие особые бенефиты в обычном бизнесе это дает, и как вообще масштабируется.

все о бизнесе и о бизнесе, вы о людях подумайте :) scalaz приносит разнообразие в нашу скучную программерскую жизнь

кому разнообразие, а кому ненужный гемор на голову, потому те ребята и убужали в го.

у хаскеля такая репутация что бизнес от него шарахается как черт от ладана а scala можно протянуть как почти java
Значит пора в бизнес протянуть Frege github.com/Frege/frege =) ну чтобы он создал репутацию хаскелю как «почти java»)) может тогда бизнес хоть не будет так шарахаться от хаскеля))))

OMFG да, это прям хорошо зашли. Добавлю в список людей пугать
<quote>
[ (x,y,z) | x <- [1..10], y <- [x..10], z <- [x..10], x*x + y*y == z*z ]
</quote>
уже представил что могут написать мои далекие индийские коллеги при такой то мощще

Такое же есть, например, в python. И что не так с этим кодом?

[(a, b, c) for a in range(1, 11) for b in range(a, 11) for c in range(a, 11) if a**2 + b**2 == c**2]

Наброшу еще по теме «эксепшны (java+scala style) против возвращаемых ошибок (go style)» — вот классная пара статей от «ниасилившего С++» (по крайней мере в комментах к его статьям так пишут), также известного как автор ZMQ:
1. 250bpm.com/blog:4
2. 250bpm.com/blog:8

Вот главная мысль этой статьи:

By the way, I've started experimenting with translating ZeroMQ into C lately. The code looks great!

Перевод для тех, кто не силен в английском:

Достали эти эксепшны, конструкторы и деструкторы! Перепишу свой hello world application с C++ на C. Обожаю функции, возвращающие ошибки!

Цитирую, «The problem with that is that you have no idea of who and where is going to handle the exception»

В Джаве вполне себе есть checked исключения, которые необходимо проверить (хотя реализация сомнительна). И я бы не стал называть «возвращаемые ошибки» «go-style» — на фоне Option/Either подход Го смотрится довольно убого.

на фоне Option/Either подход Го смотрится довольно убого.

На фоне возможности в гоу возвращать из функции произвольное количество значений ограничение скалы на одно возвращаемое значение выглядит действительно убого. И костыли в виде option/either только усложняют и без того сложный код на скале.

Во-первых, Скала де-факто умеет возвращать несколько значений.

Во-вторых, Option-подход код действительно упрощает. Я посмотрел, что предлагает Го, и уверен, что это костыль. Го не помогает в самом главном — в снижении ментальной нагрузки на программиста.

Кстати, эти самые «Option и Either» есть практически везде, от Джавы с Растом до Хаскеля. Может быть, вы потрудитесь осилитить этот «невероятно сложный матан»? Для чистоты взглядов, так сказать.

Го не помогает в самом главном — в снижении ментальной нагрузки на программиста

Ага, так сложно понять, что функция возвращает ошибку, которую нужно проверить, если один из возвращаемых ей параметров имеет тип error. С option/either ведь намного проще.

Вы еще скажите, что скала проще, чем гоу.

С option/either ведь намного проще.
Черт возьми, да, проще. Если я вижу аргумент как Option<t>, то это обращение ко мне «Эй, вот у этого аргумента может не быть значения. Не забудь это обработать!». И компилятор не даст мне забыть.

Удобство здесь в том, что точно этот же подход работает для других коллекций. Что List, что Future, что Option, все они дают удобный «интерфейс» для общения с end-user. Например, здесь

for (user <- db.getUser(id)
     data <- db.getUserData(user)) {
  ui.show(user, data)
}

db.getUser возвращает Option, а завтра Future, а db.getUserData сегодня возвращает Option, а завтра List. Но код выше вообще никак не изменится, логика будет работать именно так, как и ожидается. Слабо сделать аналог на Го?

Урезанная функциональность, которая является часть бОльшего (при этом теряя важные и полезные свойства) — вот что я называю костылем. Го дает треть Option, но в неудобной (отсутствие комбинаторов) и извращенной форме.

Option/Either не используется для обработки ошибок...

Если не упоминать о екзепшенах прокидывающихся по стеку до момента обработки (ох, простите, забыл, у вас же этого нет), то есть Try[_] монада которая как-бы намекает о том что нужно проверить, а действительно ли не было ошибки при обработке.

Весь этот тред слегка намекает на то что у некоторых гошников весьма развит стокгольмский синдром.

Во-первых, Скала де-факто умеет возвращать несколько значений.

Проведите, пожалуйста, код на скале, аналогичный этому гоу-коду, чтобы увидеть, как скала де-факто умеет возвращать несколько значений:

func Foo() (int, string, error) {
    return 42, "bar", nil
}

func CallFoo() {
    n, s, err := Func()
    if err != nil { log.Fatalf("Func returned error %s", err) }
    log.Printf("Func returned %d, %q", n, s)
}
def foo() = (42, "bar", null)

def callFoo() = {
  val (n, s, err) = foo()
  if (err != null) { log.fatal(s"func returned error $err") }
  log.print(s"func returned $n, $s")
}

(и все равно страдает форматирование, какой тег здесь используется для листингов, это явно не ’code’ ?)

Код намеренно «идентичен» приведенному выше. Обратите внимание, кстати, на подстановку переменных в стрингу, как это в Скале, и как в Го. Где интуитивнее?

Для форматирования используйте тэг pre.

Возвращать ошибки в виде параметров — днище. Но в принципе все должно быть понятно...

def foo() = Try {
  (42, "bar")
}

def callFoo() {
  foo() match {
    case Success(forthyTwo, someString) => println(...)
    case Failure(ex) => println(ex.getMessage)
  }
}

А еще одни скобочки внутри Success-а не нужны ? Success((fourtyTwo, someString))

На фоне возможности в гоу возвращать из функции произвольное количество значений ограничение скалы на одно возвращаемое значение выглядит действительно убого
А в Lua функции могут возвращать произвольное количество значений, причём разное в зависимости от условий.

А какую проблему позволяет решить возвращение нескольких значений из функции? Это упрощает программу или помогает программисту? Или все это тупо увеличивает процессорное время на обработку и никакой полезной нагрузки не несет? Мне просто интересно :)

Ну что бы не городить ненужные обертки в виде структур/классов/тюплов если функции нужно возвратить 2-3 значения. Больше — неудобно и нечитаемо, тогда уже обертка.

Всеже плохо понятно чем туплы концептцально отличаються.

Ну тюпл какой-никакой контейнер, который нужно создавать. С точки зрения использования, в скале принципиально ничем не отличаются. В .net тюплы менее красивые, но в новом C# это дело исправляют, будет как в скале.

Просто я себе не могу представить практическую необходимость вернуть из функции несколько параметров. Типа если эти значения нужны дальше, то все равно их где то надо будет хранить. А если нужны только одним уровнем выше, то почему не объединить функции — зачем плодить лишние вызовы и названия.

Очень похоже, что кто то пытается привязать разработчиков к своему компилятору. Чтобы алгоритм нельзя было перенести без диких проблем.
Или выглядит как какие-то гонки. У кого-то появились туплы, значит и у нас (другом компиляторе) они тоже должны быть.

Очень похоже, что кто то пытается привязать разработчиков к своему компилятору. Чтобы алгоритм нельзя было перенести без диких проблем.

Дикие проблемы возникают как раз при написании на языках, где значение только одно.

Если я могу написать a=b+c, где a, b, c — комплексные числа, написание того же в виде

cmplx_add3(&rd, &id, rs1, is1, rs2, is2);

убивает читабельность на корню.

Если например, функция в Lua принимает несколько значений, то можно их передавать перечислением, а можно вставить вызов другой функции, которая вернёт несколько параметров. Координаты можно инициализировать например так: x,y,z = getxy(),getz(). Можно всё сразу поместить в таблицу: t = { getvalues() }.
Имеется работа со стеком: при вызове функции параметры помещаются в стек, при возврате из функции в стек помещаются возвращаемые значения. Присваиваемые переменные извлекают значения в порядке следования. Можно легко сделать свап в 1 строчку через стек: a,b = b,a.

Ну я могу тупо передать в функцию хеш-таблицу и вернуть ее же. Ни в чем себе не отказывая, ни в количестве значений, ни в обработке. Или список.

хеш-таблицу и вернуть ее же.

С ходу замедление раз в 10-20, за счёт поиска по хэшу.

Или список.

В 5 раз. Тоже не кошер.

Я бы ещё понял передавать структуру, там ну, может, 2-3 раза...

Меряли. Цифры касаются собственно инфраструктуры передачи параметров, а не целевого исполняемого кода, конечно, но достаточно объективны.

А что «:)»? Всё имеет свои затраты, и их можно померять с достаточной точностью. А результаты иногда очень неожиданны. Например, тема cache-friendly перемножения матриц — когда, вроде бы, деоптимизация ускоряет на порядки. Или чудовищно быстрый рост потерь на open addressing hash table при приближении к критическим заполненностям. Или дешевизна реализации hash table с сохранением порядка вставления ключей (используется во всех распространённых реализациях Javascript, хоть и не стандартизовано). Скорость работы AVL-деревьев, которая в среднем не хуже, чем RB, несмотря на засилье последних. На хабре был пример из ~8 реализаций посимвольной трансляции строки для Python — выиграла, казалось бы, почти самая нелепая.

Вернуть значение и его индекс, распаристь что-то на подобии 76 RUBUSD, много чего.

В хеш-таблицу можно запихнуть все. А потом по имени получить доступ. Можно даже использовать только необходимые данные, остальные могут пригодиться в другом месте. Передавать при этом достаточно ссылку на такую таблицу.
ru.wikipedia.org/wiki/Хеш-таблица

Я могу в качестве элемента поместить в таблицу строку, назвать ее скажем «input_for_parsing». Сделать в функции парсинг и в эту же таблицу добавить значения с именами «USD», «RUB» ...после парсинга.

Приехали, в вопросе как не стрелять с пушки по воробьям, ты предлагаешь расстрелять ее из гранатомета )

Вообще то я думал что менять компилятор из-за таких мелочей это по мухе уже ядерной бомбой стрелять. А если учесть, что в случае с хэш-таблицей я могу не создавать дополнительные данные, типа код ошибки, если ошибок не было. А также не создавать ( даже в стэке) экземпляры данных, если ошибка произошла. Соответственно при этом существенно увеличив производительность программы.

Вообще мне все эти «новые» языки программирования напоминают фото мото-швейных войск. Ну или языки для «фичешистов». Ничего кардинально они не решают, выглядят уродливо, но рекламы на них вагон и маленькая тележка.

Ничего кардинально они не решают
Это смотря как на этих языках писать, если писать как на старых, то действительно нерешают.
выглядят уродливо
Это ваше сугуьо субъективное мнение.

Вы можете вернуть из функции если надо, 2 таблицы. И код ошибки. Ещё нужно не забывать, что при создании таблицы или какого-то врапера, выполняется конструктор, создаётся лишний мусор. Со стеком всё проще.

Так при создании объектов в стеке тоже вызывается конструктор и деструктор и память туда сюда бесполезно выделяется/освобождается.

ПС: память в стеке и в куче физически одинаковая. И возвращать из функции ничего не надо. Я передам в функцию только одну таблицу и буду ее модифицировать по ссылке. Возвращать что либо, а тем более грузить при этом стек несколькими значениями мне кажется абсолютно глупой затеей и крайне вредной.

То есть по вашему стэк не в оперативной памяти находится? И расчет памяти для выделения и освобождения объектов там не нужен?

И расчет памяти для выделения и освобождения объектов там не нужен?

В случае стека этот расчёт производится в момент компиляции. К тому же вероятность, что данный участок оперативной памяти будет в кэшах из-за работы предыдущих функций, или окажется полезен для следующих, выше, чем у кучи.

Осталось выяснить зачем вообще функции использовать — они стек грузят, глупая затея. Гораздо лучче все внутри меина модифицировать и все.

Функции нужны для исключения дублирования кода в разных частях программы. Или у вас другое мнение?

память туда сюда бесполезно выделяется/освобождается.

Программу пишут и сопровождают люди. Функции придумали чтобы облегчить жизнь программисту. Так что тут либо функции, либо длинный код, который программисты физически не смогут поддерживать. Если вы не знали, чтобы избежать лишней работы со стеком есть inline.

Если параметры — не ссылочные типы, GC с ними не работает, удаляются как выходят из зоны видимости, и для чисел конструктора/деструктора нет.

Вот в любом старом API раньше преобладал такой же подход — в функции по указателю передавались структуры, а возвращался либо BOOL, либо HRESULT. А теперь в стандарте C++ ввели перемещающие конструкторы. Для чего это сделали? Чтобы функции могли возвращать объекты без потери производительности.

А при чем тут GC к стеку? Для того чтобы удалить объект из стека вам придется вычислить его размер, чтобы уменьшить указатель стека на эту величину. Так что вычисления вам очень как понадобятся и для каждого объекта, который попал в стек.
В ООП нет чисел. Только объекты. Есть примитивы, но как правило их использование ограничено.
Что старый API, что новый — можно возвращать из функции или нет.
Перемещающие конструкторы скорее всего еще одна дичайшая глупость.

Числа становятся объектами, если в C# сделать boxing. Обычно числа и булевы — копируются по значению, и GC с ними не работает. Ну так вот, если создать врапер, куда что-то помещается, то он что в Go, что в Lua будет в куче и управляться GC, а в стеке — ссылка.
Есть ещё один момент: машинный стек, и стек виртуальной машины — разные вещи :)

И что? Вы пытаетесь уйти от темы? Обсуждалось практическая необходимость возвращения нескольких параметров из функции. А стек он на то и стек, потому что у него определенный алгоритм работы. И без разницы машинный он или виртуальный.

Это уже было перечисленно: для удобства разработки кода, и чтоб избавиться от создания промежуточных таблиц/структур. Которые лучше использовать по прямому логическому назначению.

Какого удобства? Передавать параметр по ссылке в функцию и после выхода из нее получить значение можно было еще на заре программирования. К чему эта «новая» фигня в компиляторе, если до этого все тоже самое можно было получить без проблем?

Функции, как в примерах выше, могут возвращать любые, в том числе нессылочные типы (неуправляемые GC). Кроме того, это вполне естественно, что функция принимает входные параметры, а возвращает результаты. Когда функции во входном параметре передаётся результат — это хак, вызванный конструктивным несовершенством языка. Если есть возможность результаты получать на выходе функции, то логичнее так и делать.

По моему вы перешли уже на бред. Компилятору без разницы входной это параметр или выходной. Он делает абсолютно одинаковые вещи в стеке для всех параметров — входных, выходных, смешанных. И только «новые» компиляторы страдают фигней, обманывая программиста.

Блин чувак, ты либо троль, либо далек от темы разговора. Странно что другие это не поняли и продолжают этот разговор.

Это типа переход на личности уже пошел, когда аргументы закончились?

Компилятору без разницы входной это параметр или выходной. Он делает абсолютно одинаковые вещи в стеке для всех параметров — входных, выходных, смешанных.

Компилятору — возможно, да. Программисту — нет. Если что-то явно оформлено в тексте как часть результата, это понятнее, чем то же самое по указателю или тем более ссылке C++ (которая часто вредит тем, что не видно, что параметр будет модифицироваться).

Ваше дело, но сокрытие/непонимание программистом того, что происходит в реальности приведет к гораздо более худшим последствиям при эксплуатации. Лучше знать, что твой параметр может быть модифицирован, чем не знать и хакерская атака потом будет основана на этой уже не «простоте» а реальной уязвимости.

Лучше знать, что твой параметр может быть модифицирован, чем не знать

Верно! Именно поэтому

x, y, z = foo(a, b, c) (1)

лучше всего;

x = foo(&y, &z, a, b, c) (2)

хуже, но взятие адреса сразу наводит на сомнения; наконец,

x = foo(y, z, a, b, c) (3)

при прототипе вида

int foo(int&y, int&z, int a, int b, int c);

хуже всего, потому что приводит к неадекватному сокрытию факта изменения, и многими рекомендациями допускается только в исключительных местах типа правой стороны у operator>>

но формат C/C++ допускает выбор только между (2) и (3), а вот новые языки позволяют и (1).

А как же возможность определения const для неизменяемых параметров? Вот компилятор и не даст модифицировать необходимое.

Это если тот const есть. А читая код вызывающего ты не знаешь, есть он там или нет, модифицируется параметр или нет, и легко сделать ложное предположение в любую сторону.

Совсем без потерь там, увы, не получается, иначе бы не придумывали всякие emplace_back().

Хеш таблица не тайпсейф. Уже луче нагородить и возвращать класс-обертку, чем хеш таблицу!

? После выбора элемента вы можете проверить его тип.

Откуда вы знаете какой тип у элемента? Откуда вы вообще знаете какое имя у элемента?
Если вы чтото поменяли у вызываемой функции (аки тип элемента), но не поменяли у вызывающей? Оно свалиться потом в продакшене? Ну уж нет, жрите с лопаты это сами.

Так я решаю какие имена задаю. Внутри функции я оперирую не ссылками а выбираю элементы по имени. Делаю кастинг к необходимому типу в данной функции. Класс при этом может иметь разный функционал, в зависимости от необходимости в данной конкретной функции.

ПС: я думал идея достаточно простая и понятная.

Оно хорошо когда пишеш сам и в первый раз.
А когда нужно иметь дело со старыми как мамонт функциями на 3 тыщи строк, и к который по сотне вызовов на каждую, вдруг начинаеш любить статическую типизацию, передачу класов, и наследование.

Ну мне тоже не очень нравится переносить определение типов в момент выполнения. Такая система может работать до появления типа, не предусмотренного алгоритмом ранее. При этом программа может не подавать признаков ошибки при тестирование, пока у клиента не вылезет ошибка с новым типом и программа просто упадет. Но дело в том, что сейчас у них направление по изменению типов данных без необходимости корректировки всех исходных текстов. В этом случае без определения типа уже никак имхо. Причем тип данных должен поддерживать функционал данной конкретной функции. Тогда менять исходный текст не придется. Хотя устойчивость к ошибкам при этом ухудшится имхо.

ПС: причем компиляторы еще можно долго совершенствовать имхо. Там куча бесполезных вещей, а необходимых почти нет.

Кроме случаев, когда тебя посадили за Javascript ;(

Просто я себе не могу представить практическую необходимость вернуть из функции несколько параметров.

Даже в самых простых системных и ядерных API есть функции, возвращающие несколько параметров, потому что это соответствует выполняемым задачам. Например:

int pipe(int fildes[2]);

существует ещё с первых Unix, возвращает реально 3 значения (код успеха и массив из двух созданных дескрипторов). Но за счёт ограничения C формально возвращается только один параметр, а дескрипторы передаются по указателю.

Более того, любой формально не имеющий такого вариант типа

int open(const char *path, int flags, ...);
int socket(int domain, int type, int protocol);

на самом деле возвращает 2 значения — код ошибки и созданный объект (дескриптор как число). Но за счёт ограничения C они передаются как один параметр. На уровне системного вызова x86 это выглядит так, что возвращается в EAX значение, которое или дескриптор, или код ошибки, а в CF собственно флаг выбора между ними (CF=1 — ошибка, CF=0 — нормальное выполнение). Дальше уже в userland идёт код вида «если ошибка, переместить этот код в персональный errno текущего треда». В Windows полностью аналогично.

int accept(int s, struct sockaddr * restrict addr, socklen_t * restrict addrlen);

и тут реально возвращается два значения — дескриптор и адрес подключившейся стороны.

А вот места, где можно передавать несколько результатов, как Python, уже возвращают для того же accept() пару — сокетный объект и адрес. (В Python есть свобода, получить все результаты как кортеж (tuple) или разобрать сразу. Есть языки, где такой свободы нет.)

Из истории IT известно, что формальный возврат одного параметра из функции явился результатом преждевременной «математизации» понятия подпрограммы. Языки ранних поколений, как Fortran, имели деление на подпрограмму (subroutine), которая вообще не имеет формального возвращаемого значения, но может получать достаточное количество параметров по ссылке, и функцию (function), которая не должна иметь побочных эффектов и возвращает только одно значение. При переходе к следующему поколению (Pascal, C) чрезмерно абсолютизировали смысл одного возвращаемого значения, отметив требование «чистоты» для функций, и сделав подпрограмму как частный случай функции. (Pascal был частично переходным тут, за счёт его procedure, но уже отменил требование чистоты. C довёл этот переход до конца.) Но когда поняли, что «чистота» должна быть просто отдельным требованием и может быть разной (например, чистота от модификации выделенных глобальных данных не требует чистоты от логгирования), это требование ослабло, зато усилились возможности возврата произвольного количества результатов.

(Побочным тут является, что в C можно возвращать несколько значений в виде структуры — см. функцию div. Логически это идеальный пример одного действия с двумя возвращаемыми значениями. Но на уровне ABI это всё равно дополнительный параметр по входящему указателю.)

И вот тогда стали появляться языки, где можно вернуть произвольную сущность, которая, если кортеж, разлагается в несколько значений — и имеем типичную нынешнюю картину (от списков Perl до кортежей C++).

Даже учитель секты scala опомнился и упомянул пост про ниасиливших в своем новогоднем обращении — www.scala-lang.org/...new-year-resolutions.html :

My second resolution is to take a larger effort to promote simplicity in Scala. I believe the recent blog post by Jim Plush should be a wakeup call for our community.

Скала мертва. Да здравствует гоу!

Забыл добавить конец цитаты

This means we have a large spectrum of choice how to write a Scala application or library. It’s very important for all of us to use this power wisely, and to promote simplicity of usage wherever possible.
Скала мертва. Да здравствует гоу!
И джава мертва, и це плюс плюс, и вообще, больной, вам пора возвращаться в палату на процедуры.

С джавой все ок — там пропагандируется только один стиль написания программ под названием over-engineered-abstract-pattern-driven-development, который некоторые ошибочно называют ООП.

А вот С++ в точку — он также, как и скала, мультипарадигменный и сложный (даже сложнее скалы). Поэтому вместе со скалой обречен на пожизненные страдания под названием «too `smart` developers».

over-engineered-abstract-pattern-driven-development, который некоторые ошибочно называют ООП.

Что же такое ООП, просвятите нас, непосвященных.
А вот С++ в точку — он также, как и скала, мультипарадигменный и сложный (даже сложнее скалы). Поэтому вместе со скалой обречен на пожизненные страдания под названием «too `smart` developers».
Он уже 20 лет как обречен, все никак недообречнется.
Что же такое ООП, просвятите нас, непосвященных

ООП — это метод проектирования программ, загоняющий разработчика в рамки взаимодействующих между собой объектов. В некоторых случаях это хорошее решение — например, GUI какой-нибудь, DOM, или игры, где архитектура программы отлично разбивается на независимые объекты с четким набором методов взаимодействия между этими объектами. В других случаях чистый ООП приводит к усложнению кода, нагромождению лишних абстракций и ухудшению производительности программы. Например, любая программа в недостаточно изученной доменной области, где не совсем ясно, на какие объекты должна быть разбита программа, и какие методы взаимодействия должны быть между этими объектами. Под этот критерий попадает большинство прикладных программ, которые мы с вами пилим на аутсорсе, в энтерпрайзе и в продуктовых компаниях.

добавлю лишь пару мелких(но в много букв) уточнений. но очень холиварных, думаю немало народу покрутит пальцем у виска в мой адрес :)

классическое Алана Кея
«Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++
«Я жалею, что придумал термин «объекты» много лет назад, потому что он заставляет людей концентрироваться на мелких идеях. По-настоящему большая идея — это сообщения
...а вызов методов это не совсем посылка сообщения.

объекты с четким набором методов взаимодействия между этими объектами
это фактически процедурный стиль. просто классы являются видом модулей. т.е. декомпозиция получается
модули-пакеты, неймспейсы, классы

Вирт, создавая Оберон об этом немало фыркал, на кой вам классы, если вы их используете как модули? (утрирую и конечно как я понял его идеи)

Например, любая программа в недостаточно изученной доменной области
однозначно. создание адекватной модели для домена — это огромный кусок работы по проектированию, который обычно не делается. особенно когда — «а у нас аджайл!» итого — иерархии классов рождаются из каких-то допущений, вкусовщины, а потом программисты мучительно в них спотыкаются, перенаследуя что во что горазд, что кому показалось стоит перенаследовать. потому что модель домена — не имеет внятного, «читабельного» отображения в иерархии классов.
не только ведь код должен быть читабельным. модель — тоже должна быть понятна, а не ребусом.

когда имеет — вот тогда красота. например классы по работе с разными коллекциями, хэшами, обычно очень толковы, и приятны в использовании. потому что — предметная область изучена, и иерархия — спроектирована.
а когда аджайл...
придумано спасение — не делайте иерархию более 3ех классов. используйте композицию а не наследование. и т.п.

Под этот критерий попадает большинство прикладных программ
да.

и ИМХО, нужно воплощать в классы не сущности предметной области, а абстракции из которых состоят эти сущности. то есть писать нечто вроде «библиотек». тогда можно пересобирать из них как из кубиков описание в коде сущностей предметной области, когда в процессе реализации выясняется что нужно утку унаследовать от классов «птицы» и «рыбы», очищая ее от чешуи покрывающей перья, потому что она ж еще и — рыба
из «летающие», «плавающие», «с крыльями», «с плавниками» — это сделать легче.
а утки они такие, норовят всплыть к концу релиза. когда уже вся стройная ирерархия классов превратилась в архитектуру.

кажется у Фаулера
архитектура — это всего лишь застывший дизайн. (т.е. такой дизайн, который уже все, не отрефакторить без адской боли за приемлимые сроки. «все ребята — бетон застыл»)

Ну да ДДД несовместим с аджаилом. И вообще, ДДД почему-то не прежился.
Но вы так пишете словно громада процедур и функций — нечто легче и проще, чем наличие объектных абстракций над этой громадой.

И вообще, ДДД почему-то не прежился.
у меня не было особых сомнений что не приживется.
Но вы так пишете словно громада процедур и функций — нечто легче и проще
от объективной сложности не уйти.

остальное сугубо для размышлений, а не для поклонения (и тем более его припысывания мне) — Антон Кекс как нам спасти Java

Тем не менее, возможность простого наследования в Go была бы весьма кстати.

Многие не могут правильно использовать наследование. Это как с маленькими детьми — надо закрыть розетки, чтобы туда не лезли.
То же самое с целевым сегментом Го и наследованием

приведите пример, где необходимо наследование

Не аргумент?

github.com/...dev/BaseServiceTest.scala

github.com/...ev/UsersServiceTest.scala

Не надоело пытаться всем доказать что баги это фичи?

Не понял, зачем здесь наследование? Тут лучше подойдет композиция. Сразу код станет понятнее и легче в дальнейшей поддержке.

Сразу код станет понятнее и легче в дальнейшей поддержке.

Только хотел написать что ctrl+клик в идее решает все проблемы с осознанием того что происходит, но вспомнил что у Вас нет IDE.

Ну раз не понимаете зачем использовать наследование вместо клепания темплейт кода в виде создания класса в каждом новом тесте, то не сильно вижу смысл продолжать диалог...

Если заменить
extends BaseServiceTest
на
val testData = BaseData
То получим композицию вместо наследования, а вместе с ней понимание происходящего в коде. И никакого темплейт кода.

Вопрос можно поставить иначе: а зачем ограничивать возможности? Я вот смотрю на Lua, язык простой и незатейливый, практически всё как в Go, на нём легко пишут даже школьники. В то же время, через конструкции языка там реализуются все парадигмы программирования. Наследование — через метатаблицы, через них же виртуальные функции. Работа с исключениями — через pcall/error, которые работают один в один как try/throw. Можно перегружать операторы, опять-таки через метатаблицы. Специальных ключевых слов для этого нет, но всё легко реализуется через возможности языка, и при этом не выглядит как костыли. В Go могли бы пойти тем же путём: сделать простой синтаксис, и предоставить при этом пользоваться всеми возможностями.
К безусловным плюсам в Go относится конечно же коротины и замыкания, чего нет в других компилируемых языках без виртуальной машины, впрочем возможности Go есть благодаря стеку и реализации механизмов VM. Ещё одна очень важная вещь, можно сказать краеугольный камень — поддержка многопоточности на уровне языка.

Ну допустим у есть 5 видов транзакций пользователя которые на 90% одинаковые, и нужно их сохранять в базе данных, естественно через ORM, очевидно что общую часть легче вынести в какую-то AabstractMappedTransaction, а дальше уже расширять ее, кстати все DAO которые обычно используются содержат ряд стандартных функций типа findOne, findAll, findByID, update, save и конечно же delete, и естественно все это писать каждый раз гемор, легче сделать одно абстрактное readWrightDao, которое сможет при наследовании с помощью дженериков подходить под любую модель + содержать кучу полезных вещей для управления персистенс контекстом, такая же хрень происходить при проектирование сервис слоя с транзакциями, а дальше когда оказывается что с транзакция нужно производить какие-то манипуляции, подсчеты и т.п. и т.д., а не только хранить в БД, то произойдет еще много чего интересного, + не забывайте, что наследование, это не только возможность вынести в родительский класс переменную или метод но и полиморфизм.
В книжках для детей пишут что наследование и агрегация можно определить логической связью между сущностными с помощью вопросов has a ..., / is a ..., так что можете придумать себе кучу других примеров про машинки с двигателем легковушки грузовики и т.д.
Конечно недавно был поднят вопрос, что разработчики, к сожалению, начали очень сильно злоупотреблять наследованием, но злоупотреблять можно и агрегацией, так что это палка о двух концах.

Откуда столько упоротости? Ты дома тоже фанат исключительно одного столового прибора? 100% или спагетти ложкой ешь или суп вилкой...

У меня дома три столовых прибора — питон-ложка, гоу-вилка и си-нож. А у вас?

Мне сложно вспомнить проект где использовался бы один язык, как минимум какие-то скрипты для енварментов/билдов + фронтенд.

Да и идеологически go совсем не открыл Америку с концепцией свой простоты и т.п., каждый язык во время своей молодости был прост как go, не от хорошей жизни и скуки С++ превратили в монстра , а java обрасла энтерпрайзным зоопарком.

Си как был простым 43 года назад, так и остался. Все зависит от идеологии языка.

Ага, как писали там в стиле
namespace_class_method(namespace_class *thispointer, parameters...)
так и пишут.

Как надо было прочитать этот пост, чтобы сделать такой вывод? о_О

Скала не самый простой ЯП, этого никто не отрицает. Основной аргумент, который пытаются донести в этом топике (я, по крайней мере) — что это не помеха для проекта с адекватными людьми. И даже во многом плюс.

Кстати, ковыряю понемногу Го. Такое чувство, как будто меня заставляют плыть со связанными руками, если честно. Мое мнение пока что — если проект будет писаться людьми с 1-2 года опыта, то Го выгоднее, да и то, 1-2 года бывают разные. Не во всех остальных случаях я бы взял Скалу (это сугубо личное предпочтение, в зависимости от команды и задач хорошо бы подошли Пайтон, Джава или Хаскель).

Скала не самый простой ЯП, этого никто не отрицает. Основной аргумент, который пытаются донести в этом топике (я, по крайней мере) — что это не помеха для проекта с адекватными людьми.
Только где их найти? Если судить по комментариям к этому топику, то адекватных людей тут почти нет.

Почти все, с кем я когда-либо работал, попадают под понятие «адекватности». Сложно дать точное определение, в целом, это «наличие здравого смысла». Не нужно искать каких-то супер-гениев.

Ставить диагноз по общению на форумах не буду (лично был случай, когда «толстый тролль» в реале оказался интереснейшим собеседником), но, на мой взгляд, большинство отписавшихся здесь тоже «адекватны».

программисты будут деградировать в профессиональном плане, ввиду развития таких языков как go, тем самым опуская порог входа, и тем самым опуская зп. это то что нужно рынку.

Го — вовсе не деградация, это другой взгляд на решение проблем. Есть масса вещей, который надо знать программисту, и конкретный язык тут даже не в первой тройке.

Го — это как раз эволюция, в плане языков, но стимулирует приход в отрасль более слабых девелоперов. Языки как раз эволюционируют в простоту в своем большинстве, иначе у них почти нет шансов выжить. Ввиду упрощения языков, работа программиста становится более простой и доступной, т.к. сравните сколько надо знать Junior Java Developer vs Junior JS/Go Developer, а потом вспомните сколько должен был знать C Developer 30 лет назад.
Чем проще язык, тем меньше необходимо технически сложных решений — язык помогает этого избегать, фреймворки все больше умеют — эволюция состоит в упрощении нашей работы, тем самым опуская высокую планку входа, и тем самым опуская цену. Это нормально, это эволюция, но в результате будет то что большинство программистов станут более слабыми — иначе говоря деградируют — это нормально, мы все к этому идем, и это ни есть плохо.

Ввиду упрощения языков, работа программиста становится более простой и доступной, т.к. сравните сколько надо знать Junior Java Developer vs Junior JS/Go Developer, а потом вспомните сколько должен был знать C Developer 30 лет назад.

30 лет назад был только юникс на 10К строчек си-кода, в котором все просто. Теперь же JS джуну нужно знать html, css, js, jquery, react, extjs, nodejs, http и еще 100500 фреймворков, чтобы его взяли на работу. Действительно, работа программиста становится более простой и доступной.

сравните сколько надо знать Junior Java Developer vs Junior JS

Ну давайте сравним.
Что нужно на жабаскрипте знать ?
Хтмл нужно ? цсс? дом апи? прототипную модель наследования? аякс ? жквери? бекбон с реактом ?
Чет мне кажеться что джуниор джс должен по факту знать больше чем джуниор джава.

Чем проще язык, тем меньше необходимо технически сложных решений

Какойто когнитивный диссонанс.
Чем проще язык — тем меньше абстракций. Чем меньше абстракций тем сложнее сосдать «простой фреимворк», и гараздо больше спагетти кода.

Го — это как раз эволюция,

Го это деградация. В реальности языки ищут компромис между фичами и абстракциями и простотой. Например в свое время джава имела полноценное ООП что позволяло делать интересные фичи и фреимворки и был достаточно простым. Будущее за свифтом и его писишными клонами.

сколько должен был знать C Developer 30 лет назад

Лолушки. Исходники первоюниксов читаются от и до за несколько вечеров. Полный аппаратно-программный мануал компьютера того времени влезал в одну книгу. Сакральность знаний системного программиста той эпохи проистекала совсем не из их объема и сложности, а из закрытости и недоступности для человека с улицы.

Чем больше лоу-лвл девелоперов, тем больше чувствуется контраст с адекватными разработчиками что позитивно влияет на их зп ;)

Вы забыли взять в кавычки слово «адекватными».

Писал и на том и на том. После 4-х лет шарпика — юзал Scala as better Java, от суслика типает. Ощущения как от t-SQL (поддержки нескольких десятков клок) — набор костылей, а не язык, синтаксис методов ужасен, несколько возвращаемых значений вместо Option[T] — тоже жуть. Для больших комманд, безотносительно языка нужны детальные guidelines, coding styles и процесс с документированными дизайн и изменениями к нему. go — это очень строгий coding style для С и инструменты для его проверки. Мой опыт с Go: проект Bleave — 50клок. Мой патч пара сотен строк. Скала — наваял 5-10 клок сам. Загуглите go lang vs brandx .
Прострелить ногу на скала можно.
Стектрейсы компилятора видел например. Баги всякие в тулзах, поломанная обратная совместимость. Но лучше уже котлин или шарпик чем gо. Отсутствие перегрузки например весьма странная фича. Закомментировал код использующий импорт — закомментируй и сам импорт. Кому лень гуглить было — это +/- Алгол68. D, Nim — быстрее в микротестах. Модель многопоточности должна быть в либе — а не языке, как в Erlang OTP, AKKA.
Таки нужна книга «Scala : the good parts». Пожалуй скажу что язык провоцирует избыточно усложнять код. Код по ссылке действительно мэджик — просто этот парень уже на своем языке думает — это должна быть его забота снабдить смердов переводом. Проблема есть, но go ниразу не решение.

Пока где-то, там в параллельной реальности go убивает джаву и скалу в больших проектах, стартап обрабатывающий big data для ФБР и ЦРУ, поднимает $800 млн. инвестиций.

Да, технологии: java, scala, spark, R (machine learning, big data), python, ruby (инфраструктура)

www.cnbc.com/...p-raises-880-million.html

хорошее место, в NZ есть дев цент )
только туда нужно подписывать контракт кровью и клиренс от разведки проходить. Это такое очень закрытое нечто с мимишными клиентами сплошняком из FVEY

Угу, всех, кто имеет отношение к американской оборонке, жестко проверяют. В Suits даже эпизод был по поводу этого ).

Офисы у них много где есть, но самая жирная разработка по-ходу только в Нью-Йорке, Калифорнии и Лондоне.

ну они набирают тут программистов — это факт

хорошее место, в NZ есть дев цент )
Для провинциалов из Харькова — wtf is NZ???

Ну такой себе аргумент. Тогда давайте вспомним Uber (он в списке приватных компаний имеет самую высокую оценку) который как раз core переписывает с node.js на go

А в макдональдсе go не используют для своей системы заказов? )

Используют для аналитики в отделе маркетинга.

Да пофиг на технологии. Вот даже в твоем примере берут

Proficiency in at least one compiled language (e.g., C, C++, Java) and one scripting language (e.g., Python, R, MATLAB)
Тоесть один общий язык и один скриптовый. Типа пофиг — можно использовать “Go” и “R”, а можно “С++” и “MATLAB”... Ну или “Java/Scala” и “Python”. Накрайняк вообще один “Python” да и йух с ним... Они ж там вообще набирают по другим критериям.

Ideal candidates learn and adapt quickly and will be able to use every tool at their disposal—software, algorithms, statistical models, and beyond—to understand and effectively tackle hard problems. They appreciate the difference between explaining and fitting statistical models, the importance of good metrics, and the tradeoff between exploration and exploitation. They can perceive common structure between superficially unrelated problems, and can use this to build tools, algorithms, and products with superlinear value.

Вопрос не в том что должен знать кандидат, а в том, что используется в компании. Там для каждой позиции конкретно указано с какими языками/технологиями придется работать. В любом случае, речь не об том. Просто там снизу с пеной во рту доказывали, что для больших, сложных проектов go так же хорош как жава/.net, более того, даже лучше так как код на go «в 10 раз короче».

Вопрос Go-адептам от Scala-приверженца. Без подвоха, действительно интересно.
.
Типичные микросервисы в Scala делаются в рамках Twitter-stack (Finagle, Ostrich, Zipkin, Mesos, Iago, ZooKeeper, ...).
Все эти штуки идут из коробки, т.е. написав однострочный микросервис и разместив его в рамках TwitterServer я получаю множество крайне полезных возможностей.
Навскидку:
— перехват внешних вызовов по множеству протоколов (http, redis, memcached, thrift, ...). Вот картинка из статьи
— распределенная трасировка вызовов (c перехватом множества сторонних протоколов), картинка_0, картинка_1.
— Finagle (ядро микросервисов) придерживается идеологии «Your Server as a Function» что в купе с функциональностью Scala (карринг, частичное применение функций, функции высших порядков, ...) позволяет одним махом построить новый сервис (=функция) на основе существующих (=функции). При чем этот «узел» автоматически попадает под трассировки.
— Контейнер TwitterServer содержит по умолчанию сотни счетчиков (время вызовов, потребление памяти, ...) которые из коробки доступны через разворачиваемый на каждой ноде http-server.
.
А теперь вопрос Go-знатокам: Есть ли такое окружение у Go и где о нем можно почитать.
Потому как без окружения (трассировка, логгирование, счетчики, ...) можно однострочный микросервис и на Delphi написать, но толку от него нет.

Классная штука. Но она не входит в стандартные либы скалы — это сторонний код. В стандартной поставке гоу такой штуки тоже нет. Но есть сторонние либы. Например, github.com/go-kit/kit . По описанию очень похоже на twitter stack.

На наших проектах используются собственная реализация метрик, которые можно опрашивать в виде json по http с использованием regexp фильтров. Занимает 200 строчек кода. Включает в себя счетчики, гистограммы и показатели. Метрики можно объявлять в любом месте кода в одну строчку. Этого нам пока достаточно.

Ну хз.
Собственный велосипед то везде написать можно. Интересно, что уже есть в экосистеме. Мы же выбираем не язык, на котором лучше всего написать библиотеку для микросервисов, а язык с уже существующей экосистемой наилучшим образом подходящие для написания микросевисов.
Может я и на Java такой велосипед поверх Servlet API напишу. Суть то в том, что сейчас такое в рамках Tomcat/Jetty не идет.

Но есть сторонние либы. Например, github.com/go-kit/kit . По описанию очень похоже на twitter stack.
хз
github.com/go-kit/kit = 439 commits
twitter.github.io/finagle = 4,188 commits
-
судя по всему пилят, но не итак усердно.

Скорее всего, для реализации данной функциональности на гоу нужно в 10 раз меньше кода и коммитов, чем на скале.

Эээ ...
Из чего-то следует, что Go в 10 раз более краткий язык в сравнении со Scala? Полагаю — нет.

я бы скорее подумал на оборот по моему опыту
скала заметно компактнее

Да, вон тут замечательно видно, насколько скала код компактнее, чем гоу — dou.ua/...rom=similar_topics#871259 . Пример типичного кода на scala:

public class MatchContainer implements StatsRegistry, LineupsRegistry, AreaRegistry, UserRegistry, TournamentRegistry, TicketRegistry, TableRegistry, ChatRegistry, BetRegistry, MatchEventRegistry, MatchReactor, ChatReactor, BetReactorThin, AreaReactor, TimeReactor { ... }
public class TournamentCollection implements TournamentRegistry, TicketRegistry, ChatRegistry, BetRegistry, TableRegistry, ChatReactor, BetReactorThin, MatchReactor, TimeReactor { ... }
Пример типичного кода на scala:
:facepalm:

гоубои упоролись и не могут отличить кровавый Java Enterprise от Scala?

Пройдитесь по приведенной выше ссылке, чтобы понять, что это как раз самая настоящая матановая Scala, а не Java Enterprise.

Не нужно никуда ходить, я джава энтерпрайз нюхом чую.

А вам стоит пойти купить книжку по скале и почитать, чтоб хоть немножко разбираться в темах, в которых вы пытаетесь высказывать свое авторитетное мнение

здаеться го бои не только упоротые но еще и в глаза ебуться

Нечем крыть тщательно скрываемый факты о Scala? Слив засчитан!
И не нужно переходить на личности — это выглядит некрасиво в глазах окружающих.

Отсюда = github.com/go-kit/kit.

Go has emerged as the language of the server, but it remains underrepresented in large, consumer-focused tech companies like Facebook, Twitter, Netflix, and SoundCloud. These organizations have largely adopted JVM-based stacks for their business logic, owing in large part to libraries and ecosystems that directly support their microservice architectures.
Сами плачут, что уступают JVM-языкам:)

Я бы сказал, что Go tool-development focused language, когда JVM Domain-development focused ecosystem.

Хорошая тема, да. Мы не раз уже в подкасте Golangshow обсуждали эту тему, и пока что, судя по статьям и блог-постам, у Go нет одного-единственного фреймворка для микросервисов. Почти все пишут необходимое себе "окружение"/пакаджи под свои нужды и не сильно парятся фреймворками потому что написать под себя оказывается проще и доступнее, чем адаптировать под себя какой-то фреймворк вроде gokit.
Вобщем-то, писать микросервисы на Go можно и со стандартной библиотекой-only. Продакшн-ready http-сервер есть (net/http), RPC клиент/сервер — есть (net/rpc), метрики/счетчики есть — (expvar), единый интерфейс для sql-бд есть (database/sql), трейсеров а-ля zipkin в стдлибе нет, но есть внешние типа appdash (github.com/sourcegraph/appdash, которые легко интегрируются в любой Go-код без надобности принадлжеать какому-либо фреймворку.

Вобщем, интересная тема, автор Gokit дает доклады регулярно, где призывает Go-коммьюнити двигаться в сторону вот такого единого фреймворка а-ля Finagle, но многие люди пишут и рассказывают, что Gokit клевые и все такое, но им проще писать свое, чем адаптировать под себя Gokit. И это действительно так — я, к примеру, тоже гоняю микросервисы практически на stdlib-е, и переезд с одного транспорта на другой(скажем, с net/http+json на gRPC) у меня занимает пару часов рефакторинга. Как-то так.

Такое ощущение, что это следствие отсутствия за Go micro-services крупной компании. Т.е. за Go, как языком системного программирования, стоит Google + ..., но не используют его для micro-services.
.
Так как если я возьму разные способы лепить REST на Scala, например содержание книги “RESTful Web Services with Scala”, то я вижу:

  • A Functional-style REST Service with Finagle and Finch
  • A Pattern-matching Approach to REST Services with Unfiltered
  • An Easy REST Service Using Scalatra
  • Defining a REST Service Using Akka HTTP DSL
  • Creating REST Services with the Play 2 Framework
  • JSON, HATEOAS, and Documentation
Из того, что знаю: Finagle/Finch = Twitter, Akka HTTP + Play = Typesafe.
Т.е. за Go, как языком системного программирования, стоит Google + ..., но не используют его для micro-services.
Используют. Насколько я знаю, в Google в основном используется gRPC сейчас.

А с REST-ом как раз проще. Опять же, это делается элементарно либо из коробки, либо с помощью 100500 библиотек/раутеров/фреймворков вроде gin/echo/gorestful и тд. В Go не нужны фреймворки вроде Akka, потому что этот функционал есть в языке и stdlibe. Встроенный net/http сервер production ready и 10К не боится. (dl.google.com на нем бегает, к примеру)

этот функционал есть в языке
функциональность Akka в языке? пруф в студию плиз

Ну, если я правильно понимаю суть Akka — это фреймворк, дающий возможность в Scala/Java писать concurrent-код, используя модель акторов. Акторы достаточно похожи на модель CSP Тони Хоара. А в Go как раз реализована CSP и это даже не в stdlib-е, это в языке. Concurrent-программирование — это одна из ключевых фич Go, вобщем-то. Внешние фреймворки тут не нужны.

если Вы про вот это: blog.golang.org/pipelines
то это скорее аналог TPL из .Net частично запихнутый в синтаксис языка
Akka это более высокоуровневый framework

Это статья с примерами пайплайнов, не более. Вопрос же того, как писать concurrent-программы лежит больше в области теории, и тут есть несколько распространенных подходов — акторы, STM, CSP и так далее. Насколько я понимаю, Akka нужна в скале именно для того, чтобы можно было использовать акторы и писать concurrent-программы. В Go это встроено в язык. Вполне вероятно, что Akka еще много чего делает, охотно верю.

Насколько я понимаю, Akka нужна в скале именно для того, чтобы можно было использовать акторы
да
и писать concurrent-программы
их можно писать из без Akka, для этого есть java.util.concurrent.*
но это будет код на уровне потоков
Akka дает инструменты для actor модели, причем инструменты отказоустойчивые и распределенные и масштабируемые. Как с этим в Go — не знаю. Для корректного сравнения стоит почитать про Akka, и тогда можно проводить какие-то параллели.

Как в том анекдоте )
«Собака — животное на четырех ногах, покрыто шерстью, в шерсти водятся блохи. Так вот, блохи...»

Это вы про goрутины что ли? Им до акки, как до луны. Несмотря на то что внутри лежат схожие принципы, снаружи они совершенно разные. goрутины конечно интересная концепция, но не покидает ощущение что это костыль чтобы позволить программистам писать синхронный код заботясь об ассинхронности и параллелизме только там, где они действительно нужны — не верхних уровнях.

Ну вам и Тони Хоар — костылист знатный, конечно же. А, это опять вы, тот, который боится код в 6 строчек написать? Ясно.

Это крутая штука, но складывается ощущение что в go оно используется не по назначению.

А, это опять вы, тот, который боится код в 6 строчек написать? Ясно.

Это там, где я должен тратить время на изучение существующих библиотек по парсингу HTML, вручную анализировать HTML реддита? Нафиг! Любой .net-чик тебе подтвердит что это несколько строк кода, если правильно, с обработкой ошибок, конечно чуть больше.

Это крутая штука, но складывается ощущение что в go оно используется не по назначению.
Хаха. А какое у нее назначение, обоснуйте свое «ощущение» пожалуйста. Вы же знаете о чем говорите, а не просто флудите, не так ли?
Это там, где я должен тратить время на изучение существующих библиотек по парсингу HTML, вручную анализировать HTML реддита
Я более чем уверен, что в вашем любимом высокоуровневном языке есть библиотеки, умеющие работать с json-api реддита. Непонятно, зачем вам сдался HTML парсинг и почему вы и его испугались. Я прошу написать простую программу, чтобы на реальном примере оценить а) размер real-life кода (не стиснутого для примера, а реально — с обработкой ошибок, со всем, как в реальном проекте) б) время и силы потраченные не только на сам код, но и на такие «дополнительные» вещи, как настройка проекта, подключение сторонней библиотеки и т.п.
Вот реально интересно.
Хаха. А какое у нее назначение, обоснуйте свое «ощущение» пожалуйста. Вы же знаете о чем говорите, а не просто флудите, не так ли?

Организовать асинхронне взаимодействие между процессами, между отдельными акторами системы каждый из которых имеет свое предназначение, свою функцию и может быть запущен на других машинах в любом количестве (масштабируемость). В го же оно используется для запуска синхронного кода асинхронно и ожидания результата, по сути то что делают Future в jvm и Task в .net, только в более няшном для программиста (но не для системы) виде (хотя async/await в .net не менее няшный).

Я более чем уверен, что в вашем любимом высокоуровневном языке есть библиотеки, умеющие работать с json-api реддита.

Тю, так бы и сказали что можно json-api использовать, вечером рожу.

В го же оно используется для запуска синхронного кода асинхронно и ожидания результата,
У вас очень ложные представления о concurrency в Go.
ю, так бы и сказали что можно json-api использовать, вечером рожу.
Я бы за эту фразу («так бы и сказали») даже джуниора уволил бы ))
Окей, жду. Желательно засеките время от самого начала до готового результата.

Википедия глаголет (CSP / Comparison with the Actor Model):

In as much as it is concerned with concurrent processes that exchange messages, the Actor model is broadly similar to CSP. However, the two models make some fundamentally different choices with regard to the primitives they provide:
CSP processes are anonymous, while actors have identities.
CSP message-passing fundamentally involves a rendezvous between the processes involved in sending and receiving the message, i.e. the sender cannot transmit a message until the receiver is ready to accept it. In contrast, message-passing in actor systems is fundamentally asynchronous, i.e. message transmission and reception do not have to happen at same time, and senders may transmit messages before receivers are ready to accept them. These approaches may be considered duals of each other, in the sense that rendezvous-based systems can be used to construct buffered communications that behave as asynchronous messaging systems, while asynchronous systems can be used to construct rendezvous-style communications by using a message/acknowledgement protocol to synchronize senders and receivers.
CSP uses explicit channels for message passing, whereas actor systems transmit messages to named destination actors. These approaches may also be considered duals of each other, in the sense that processes receiving through a single channel effectively have an identity corresponding to that channel, while the name-based coupling between actors may be broken by constructing actors that behave as channels.
Похоже общее — передача сообщений, а механизмы передачи — разные.

Различия модели акторов и модели CSP я хорошо знаю. Суть и задачи у них одинаковые, только в Go это встроено в язык, а в Scala для этого нужна Akka — вот это я и хотел прояснить.

а в Scala для этого нужна Akka

В ранних версиях акторы были частью стандартной скаловской либы.
Но от них отказались, ибо зачем, если акка значительно более продвинута.

ну вообще то гугл продвигает
kubernetes.io
такие вещи как coreOS & etcd
вроде оно еще все на го написано.

Go, как языком системного программирования,

А поясните мне, когда это успели начать называть гарбедж колекшн языки — языками систамного программирования ?

Хм..., а к какому классу ПО Вы бы отнесли Docker?

видимо у меня путаница в терминологии «системное программирование».
Можна подразумевать ось, драйвера и прочее.
А можно скомпиленые тулзовины, типа грепа, файнда, и , блжад, докера.

Интерфейсная навеска над сервисами ОС?

вот если бы LXC был бы на го можно было бы говорить — а так оно и на python точно так же бы работало

А тем временем к Go подбираются с другой стороны:
neuronews.su/...niya-s/?fdx_switcher=true

Кстати тут еще хороший наброс от Соловьева («чик-чик и в продакшн» ©):
solovyov.net/...blog/2014/when-to-use-go

А вырастить программиста на го дешевле, конечно. Еще программиста на пхп дëшево растить, сборщиков помидоров тоже недорого. Неужели мы так быстро к основному аргументу «за пхп» скатились?

Вот реально, не покидает точно такое же ощущение. Менеджерам конечно хорошо, это да, программистам — не очень.

Ошибаетесь. Главный плюс в Go именно для программистов. Недаром масса статей и твитов про Go заканчивается словами «Programming is fun again». А то, что любители нечитабельного кода готовы все, что не кложа сравнивать с пхп — лишь демонстрирует предвзятость и некомпетентность.

мне он показался на оборот на удивление унылым языком обрезанным по самую шею ’что бы ничего непонятного случайно не написали’
короче не фан а паралимпийские игры какие то

Не расстраивайтесь, вы ж из кровавого интерпрайза, у вас видение очень специфическое. Никто не идеален, все норм )

Его просто неправильно позиционируют. Это осовремененный Паскаль, кое-как замаскированный под потомка Си. С таким описанием его цели и ниши становятся очевидными.

У Go несколько иная генеалогия: pbs.twimg.com/...CVpB22RVEAAZNnt.png:large
Кто-то, увидев «:=» радостно бежит называть Go «осовремененным Паскалем». Другие, увидев знакомое «низкий порог входа» вприпрыжку обзывают «пхп».
Как будто видеть различия и разбираться в теме уже не модно, чтобы дискутировать о языках :)

У Go несколько иная генеалогия:

Я в курсе, но говорю совершенно о другом — о правильном позиционировании в сознании нынешних программистов.

Кто-то, увидев «:=» радостно бежит называть Go «осовремененным Паскалем».
Я не знаю, кто этот «кто-то», и прошу мне этого не приписывать.
Как будто видеть различия и разбираться в теме уже не модно, чтобы дискутировать о языках :)
Я вижу, что лично для Вас совершенно не модно думать о том, что хотел сказать другой, прежде чем писать свои реплики.
Я в курсе, но говорю совершенно о другом — о правильном позиционировании в сознании нынешних программистов.
И каким образом «осовремененный паскаль, замаскированный под Си» является правильным позиционированием Go? У вас, вероятно, какие-то крайне специфические отношения с Паскалем.
Я вижу, что лично для Вас совершенно не модно думать о том, что хотел сказать другой, прежде чем писать свои реплики.
Не можешь атаковать мысль, атакуй оппонента.
И каким образом «осовремененный паскаль, замаскированный под Си» является правильным позиционированием Go?

Язык с максимальной ориентацией на процедурное структурное программирование, с урезанным ООП, без исключений (с частичными костылями), максимально позиционированный на «не дать выстрелить программисту в ногу» и принципиально лишаемый средства защиты против ошибок программиста.

Не можешь атаковать мысль, атакуй оппонента.

Да, очень жаль, что Вы именно так и действуете. Какие-то «специфические отношения» ищете, приписываете реакцию на знак «:=» вместо того, чтобы хотя бы встречный вопрос задать, и так далее.

Язык с максимальной ориентацией на процедурное структурное программирование
Какая же она максимальная, когда вы можете передавать каналы каналов, по которым передаются функции, возвращающие функции. Некоторые тут вообще кричат, что Go более функциональный, чем многие функциональные языки (хоть я и не согласен). Но, как по мне, в Go достаточно хороший баланс между классической С-процедурностью и функциональными плюшками. Паскаль тут совсем как-то сбоку смотрится.
с урезанным ООП
В каком же месте он урезанный? В Go ООП даже скорее расширенный (по сравнению с класс-ориентированными языками). То, что он реализуется не так — не означает «урезанный». Паскаль тут не в тему.
без исключений (с частичными костылями),
Это вы panic()/defer()/recover() называете костылями? Так это может казаться только безбожно застрявшим в фанатизме к исключениям, которые ими event/callback системы реализовывают, а потом пишут книжки по тому, как не нужно использовать исключения. В Go просто другой, менее корявый подход к обработке ошибок.
максимально позиционированный на «не дать выстрелить программисту в ногу»
Это вообще полезное свойство, почему оно вам кажется специфичным для Паскаля — непонятно.
принципиально лишаемый средства защиты против ошибок программиста.
Это вы так назвали адски крутой встроенный race-детектор в Go? Или строгий компилятор и целую пачку линтеров?

Вобщем, никакой критики ваш прицел на Паскаль не выдерживает, простите.

Какие-то «специфические отношения» ищете, приписываете реакцию на знак «:=» вместо того, чтобы хотя бы встречный вопрос задать, и так далее.
Ну это было не столько о вас (вы не первый, кто сравнивает Go с первым, в чём увидит что-то похожее). Но, признаю, ошибался.
И каким образом «осовремененный паскаль, замаскированный под Си»

Паскаль выражал мнение автора от том, как нужно писать программы.
С давал инструменты для работы с машиной, но оставлял вопрос «как надо» полностью на программиста.

Вся эта тема слегка напоминает споры «C vs Pascal», с Го в роли Паскаля.

(напоминаю, Паскаль появлися в 1970, через два года после фразы «Go To Statement Considered Harmful» того же автора, так что делайте поправку на исторический контекст)

Ну хз, поигрался пару дней немного, пока ощущения как от паскаля.

Программисты любят сложности, любят проектировать, любят вылизывать код и делать его короче, быстрее и читабельне за счет новых техник и возможностей языка. Это как искусство. Поэтому многие люди для фана пилят на скале, хаскеле, кложуре, и их реально прет от этого.

Педалить тоннами код, который «всем понятный» — это не фан, это рутина. Никаких вызовов, никакого удовольствия, тупо сидишь, педалишь и деградируешь как программист.

По моим (и не только) наблюдениям, 90% упоротых го-шников это либо новачки, либо бывшие PHPшники/js-шники/с-шники. Сходу даже не припоминается восторженных комментариев от тех, кто работал на чем-то более высокоуровневом (java, C#, scala, clojure, haskell, и т.д.) кроме нашумевших статей от маркетологов и СТОшников о том, как мы з языка Х перешли на go.

Это просто топ-комментарий должен быть, я считаю. В нем прекрасно всё и он олицетворяет причину того, почему Go появился в первую очередь. :)
Именно чтобы не дать вот таким любителям сложности, любителям «для фана» попользовать «фичи языка», доводящие использование фич до абсурда, называя это искусством.

Вокруг Go как раз формируется коммьюнити, которое очень активно борется с таким вот отношением к программированию. У гоферов принято, что код пишется прежде всего людьми для людей, и лишь потом для компьютеров. Именно это позволяет большим командам достаточно легко работать над кодом, понимать код друг друга даже спустя хороший промежуток времени. Best practices, проверенные уже десятилетиями, которые максимально не дают новичкам в проекте «делать код короче» новыми «фичами языка», и писать нечитабельный говнокод.

Но за коммент спасибо, он вправду очень символичен. Буду цитировать впредь.

PS. А вот смешивать в одну кучу, еще и с таким неуважением, С-программистов с JS и PHP — это вы напрасно. Только подтверждает неадекватный надменный элитизм шарперов и функциональщиков.

Похожая идеология была у Руби- «язык для программистов, а не компьютеров», «Руби- делает программиста счастливым», но он не взлетел особо тоже...

Вы же это вот сейчас серьезно, да?

Руби выполнил свою задачу более чем отлично, и в своей нише до сих пор рулит и бибикает. Неужели так сложно расширить кругозор и поинтересоваться миром разработки ПО, выходящего за рамки своего проекта или языка? Мрак какой-то.

Какая задача была у Руби?) Кроме веб-фреймворка ROR ничего не взлетело, хотя Руби мог занять нишу Питона..На Руби практически также можно делать автоматизацию тестирования, десктоп, мобильную разработку, data scienсe, Dev-Ops, но прорыва не произошло..Никто из серьезных игроков рынка не развивал эти направления на Руби..

Да много на Руби радостей: Puppet, Chef, RubyMotion, Ruby/DB, Cucumber, RPG Maker, Sketch up, WATIR, Metasploit, Rake и пр. Многие ньюфаги думают, что это сугубо веб-язык типа PHP, и слышали только про рельсы:)
Потому что высоко взлетели только они..
Понятно, что как бы странно сравнивать компилируемый, лицензированный Гуглом GO с интерпретируемым опенсорсным Руби..Но всё же меня пугает), когда говорят

У гоферов принято, что код пишется прежде всего людьми для людей, и лишь потом для компьютеров. Именно это позволяет большим командам достаточно легко работать над кодом, понимать код друг друга даже спустя хороший промежуток времени. Best practices, проверенные уже десятилетиями, которые максимально не дают новичкам в проекте «делать код короче» новыми «фичами языка», и писать нечитабельный говнокод.
Не верю!) Точно такая же идеология была у Руби- и он не прошёл..
Хотя может я так считаю из-за того, что я не люблю Гугл за скотское отношение к конечным пользователям.
что код пишется прежде всего людьми для людей, и лишь потом для компьютеров.

Тут какоето прям противоречие. Меньше фич == больше кода. Который сложнее читать и поддерживать.

В каком месте я сказал что предлагаю писать код для машины? Из чего ты сделал выводы, что под фичами языка я предлагаю использовать аппликативные функторы и прочий функциональный матан?

Читаем еще раз и обращаем внимание на слова «короче» и «читабельне»:

Программисты любят сложности, любят проектировать, любят вылизывать код и делать его короче, быстрее и читабельне за счет новых техник и возможностей языка. Это как искусство.

Скала кстати, со своими мощными DSL возможностям, при желании позволяет писать код так, что домохазяйка прочитает и поймет. А ты про машины говоришь...

Все просто: меньше синтаксического сахара в языке, меньше фич, меньше стандартная библиотека = больше кода. Чудес не бывает.

И да, раз уж на то пошло, вот это код для людей:


var excellentGirls = students.Where(s => s.Sex == Sex.Famale && s.Age >= 18).OrderByDescending(s => s.Grade).Select(s => s.Name);

и вот это код для людей:


var excellentGirls = students.find(s => s.Sex == Sex.Famale && s.Age >= 18).sortBy(- _.Grade).map(_.Name);

Как только представляю как подобный код “для людей” будет выглядеть на go, тут же возникает рвотный рефлекс

Код для людей — это plain SQL, а не бесполезные ORM-обертки наподобие показанной вами. Что проще — ваш код или этот:

select name from students where sex = 'female' and age >= 18 order by grade desc 

ORM-обертки не только бесполезны, но и часто нагружают базу бесполезными запросами при джойнах таблиц. Причем для того, чтобы заставить ORM сгенерировать оптимальный запрос, нужно нагородить кучу костылей с подсказками орму. В клинических случаях, когда тупость орма невозможно обойти, приходится переходить на plain SQL.

а кто сказал что этот код имеет какое-то отношение к ORM?

var excellentGirls = students.Where(s => s.Sex == Sex.Famale && s.Age >= 18).OrderByDescending(s => s.Grade).Select(s => s.Name);
students запросто может быть например List<student> или IEnumerable<student>

Может я не совсем проникся go, там что, при каждом пчихе БД принято поднимать? )


def getExcellentGirls = for {
response <- kpi.api.getStudents()
students <- response.decode[Vector[Students]]
} yield students.find(s => s.sex == ’F’ && s.age >= 18).sortBy(- _.grade).map(_.name)

PS Какой тэг для кода использовать? Как-то калично форматирует.

thanks

def getExcellentGirls = for {
	response <- kpi.api.getStudents()
	students <- response.decode[Vector[Students]]
} yield students.find(s => s.sex == 'F' && s.age >= 18).sortBy(- _.grade).map(_.name)

>

ORM-обертки не только бесполезны, но и часто нагружают базу бесполезными запросами при джойнах таблиц. Причем для того, чтобы заставить ORM сгенерировать оптимальный запрос, нужно нагородить кучу костылей с подсказками орму. В клинических случаях, когда тупость орма невозможно обойти, приходится переходить на plain SQL.
Господи какой же бред. Я не удержался.

ну я удержался, ибо пациент не наш:)
хотя идеальных ORM-ов не бывает, иногда действительно бывает нужен хардкор
возможно он просто пытался писать свои, чем и я грешил по молодости лет,
а ввиду того что не получилось круче хибернейта, решил что это отстой.
характерная черта гоферов — полное отсутствие самокритики и, как бонус фанатизм
чотко как у линуксоводов в 90-е ...
у них, надо заметить, эта проблема решилась сама собой
линух свою нишу занял — и все довольны:)

А вот смешивать в одну кучу, еще и с таким неуважением, С-программистов с JS и PHP
Вот тут не понял, кто из них плохой и оскорбляет своей компанией остальных (не считая РНР) ? ;)

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

habrahabr.ru/post/274099 — статейка-свежачок (самый самый свежак) на хабре про Go. «Кому и зачем все-таки нужен Go?»

замечательная статья!

как мне в обсуждении доказывали что «300 хабровцев с полком лайкеров за спиной» постигли суть и Скалы и статьи Jim Plush’а, однако ж поди ты, не просекли что в ней очевидно ж написано, а теперь вот им разжевывают:
Это на самом деле очень круто для менеджмента. Посудите: можно нанять 100 посредственных программистов, дать им в руки Go и эта армия обезьян будет генерить вам много «неплохого» и очень даже поддерживаемого кода!

Что еще интересней, автор статьи «Кому и зачем все-таки нужен Go?» аккуратно высмеял Гугл, комментируя Пайка:
Фишка в том, что наши программисты гуглеры, а не ученые. Это обычно молодые, только выпустившиеся пацаны, которые возможно выучили Java, возможно даже C/C++ и может быть Python. Они не в состоянии понимать пробздетый язык, но мы все равно хотим, чтобы они делали хороший софт. Таким образом, мы даем им легкопонимаемый язык, к которому они быстро привыкнут.

хотя очевидно же, что те «300 хабровцев с лайкерками», т.е. ниасиливших Джаву на Скале будут писать еще хуже, раз даже у Гугла нет интереса переплачивать «за знание Scala»

но гении менеджмента конечно надавали советов как нужно выстраивать процессы в команде скалистов, а все кто от этого отказался — невежды в менеджменте, ниасиляторы, и т.л.

конечно, конечно, посредственные обезъяны это они, те, а мы то — 300 хабровце-скалистов — ух! мы на Скале таааакое педалим, таааакое напедалим! куды тем Go, Джавам и прочих ЯП для плебса!

можно нанять 100 посредственных программистов, дать им в руки Go и эта армия обезьян будет генерить вам много «неплохого» и очень даже поддерживаемого кода!

Все бы хорошо, вот только:
a) не слышал пока об успешном опыте применения go в больших проектах
b) еще неизвестно как оно будет поддерживаться, все слишком молодо, не успели еще наговнокодить )

Пока Go видится как более быстрый питон со статической типизацией. Но, в эру микросервисов свою нишу определенно займет, тем более то с поддержкой гугла.

не слышал пока об успешном опыте применения go в больших проектах
в случае если большие проекты будут разбивать на маленькие, в силу смены перехода от монолитных приложений к композитным, из микросервисов — и не услышите.
так что да, вы правы навсегда!
еще неизвестно как оно будет поддерживаться, все слишком молодо, не успели еще наговнокодить )
угу. перечитайте в стопицотый раз статью из топика, и в стопицотый раз умнО переспросите
«Так как же вы все таки объясните что телеграмма прошла по дну океана и не промокла?»
Пока Go видится как более быстрый питон со статической типизацией.
глубокая мысль, да.
Но, в эру микросервисов свою нишу определенно займет, тем более то с поддержкой гугла.
да, скале не так повезло. и эра не та, и поддержки гугла нет.

А вот если бы, да кабы — то конечно Scala самый правильный язык, а просто — тупни вокруг. и заговор корпораций! и по методичкам-темникам — пишутся проплаченные статьи о Go. Да!

a) не слышал пока об успешном опыте применения go в больших проектах

Даже я знаю про docker и dl.google.com. Или это неуспешное применение и проекты маленькие?

Молодцы что слышали, теперь посмотрите на размер его исходников

докер это 24 мегабайта исходников, это мало??

Аж целых 24 мегабайта? Не может быть!

У нас проект, на .net, исходников около гигабайта если что.

от того что скажем на PHP нет проектов с исходниками около гигабайта, не меняется его звание основного языка разработки веб-приложений.

то есть критерий — большой проект по количеству кода — это критерий для того чтобы победил многословный ЯП с архитектурным подходом — монолитное приложение.

А теперь удалите все ресурсы с картинками, xml, видео, бинарниками. Не забудьте удалить папку с репозиторием VCS. И посмотрите на оставшиеся 10 метров кода

Я говорил именно об исходниках. Ну вы же embeded программист, откуда вам знать что делается в энтерпрайзе.

Кстати если почистить докер, то там и того меньше, 16 мбайт

Ну вы же embeded программист, откуда вам знать что делается в энтерпрайзе.
Исходники QNX 6.6 — 10,801,564,828 bytes. Из них 1 гиг — это драйвера, 5.5 гиг — это библиотеки, всё остальное — приложения, сервисы, демоны и прочее. Забавно, раньше никогда не интересовался :)
У нас проект, на .net, исходников около гигабайта если что.
в общем чем больше места занимают исходники — тем круче язык/платформа))))
это как меряние письками — ей богу)

А ветку перечитать слабо? Упоротые гошники доказывают что большие проекты на go пилить нефиг делать, и приводят в пример докер. Я же просто показал что докер это, мягко говоря, небольшой проект.

я о том, что осталось дело за малым — запилить на Go реально большой проект))

А так я не настолько упорот, чтобы считать, что язык А круче, чем язык Б потому, что на нем можно запилить проект на столько-то гигабайт, а на языке Б такого сделать нельзя. Ровно как считать один какой-то язык (будь то го, питон, джава или сишарп) панацеей от всех программерских бед)

p.s. Да и мне как бы пофиг насколько большим проектом считается докер)

Аж целых 24 мегабайта? Не может быть!
У нас проект, на .net, исходников около гигабайта если что.

Только вот 99.9% у вас составляют бины нугет пакетов и самого проекта, а не исходники.

Ну да, вам видать виднее.
С# файл на 15 строк кода весит 300 байт, путем несложных подсчетов с ваших слов выйдет, что проект содержит около 50 млн строк кода.
Это один из самых крупных проектов в мире. По прежнему будете настаивать, что это так?
www.informationisbeautiful.net/...ns/million-lines-of-code

Я думаю больше, там только тестов около полумиллиона и они далеко не однострочные.

Чего вы так удивляетесь? Довольно типичный энтерпрайз в джава/.net мире.

я знаю какие типичные энтерпрайз проекты и сколько они весят и за счет чего, поэтому мне не удивительно.

И сколько же занимает времени билд проекта и прогонка 500 тыс тестов?

Билд довольно быстро как на такие размеры, около 7-10 минут. Тесты около часа распределенно на всех девелоперских компах (около 200 штук). При этом надо учитывать что железо у всех топовое — 6-ядерные интелы, 64 гб. RAM, SSD.

Корпоративный проект на .NET размером с ERP, над которым работают 200 программистов. Если расскажите как это завелось и кто за это платит деньги это будет почти как научное обоснование жизни на Марсе.

Сильно связанный монолит.

Кому так цікаво, то запитайте в golang-nuts. Думаю мужики вам з радістю назвуть свої об’єми Go-коду в Корпорації Добра.

Верю что много, но это слабо связаные микросервисы, или просто утилитки, то есть куча небольших проектиков.

Это не аутсорс.

Удивляет ваше удивление. Типичная ситуация в .net/java энтерпрайзе.

многие бьют этих монстров на тысячу микросервисов, и потом играешь в игру найди микросервис с багой, это весело =)

по целому ряду причин то о чем идет речь врядли являеться монолитными приложением по типу докера. В энтерпрайзе такое монолитное приложение крайне нетипично делать на .NET и на этой есть целый ряд причин, организация крупного внутреннего отдела непрофильной деятельности(который выжирает рерурсов поболее чем продукт), инфраструктурный, внутренний саппорт, бизнесс SLА, практически отсуствие беспроблемных решений для нагруженных\распределенных систем таких размеров на МС, на базе которых здравомыслящий айти директор подобной корпорации врядли решиться построить такого монстра. Для .NET энтерпрайза типично когда существует сотня другая не бизнесс критических систем интегрированных через веб-сервисы, но их нетипично лепить в один солюшин. Вообщем все это мало относиться к теме сравнения.

Нет, ну понятное дело что все логически по функциональности разбито на кучу солюшинов. Но связаность через сборки довольно сильная, параллельно приходится держать несколько открытых таких солюшинов. Это не независимые микросервисы где каждая команда работает над своим сервисом со своей кодобазой.

Билд довольно быстро как на такие размеры, около 7-10 минут.
Тесты около часа
Я-то по наивности своей думал что участвовать в таком безобразии в 2015м году от р.Х. должно быть как минимум стыдно. А тут даже бахвалятся...

Просветите, а как в 2015 году энтепрайзы пилят, чтобы не было стыдно?

Да как всегда — разделяй и властвуй. Допустим не всем нравятся микросервисы, но на пяток-дюжину-то частей разбить точно можно было.

На проекты, на солюшины, все разбито, каждый работает над своими частями. Билдит только свои проекты, локально запускает тесты только из своих проектов. Главное только один раз все перебилдить когда обновляешь исходники и все, дальше билдишь и тестируешь только то, что изменяешь.

Но, кодобаза общая, связаность довольно большая, на выходе — большой монолит.

Но, кодобаза общая, связаность довольно большая
вот это сильно очень попахивает спагетти в большом масштабе. И что для них характерно — значительная accidental complexity, при вдумчивом рефакторинге код сокращается в разы. Ну я конечно не знаю как оно у вас в этом конкретном случае.
большой монолит.
 с этим обычно большие проблемы в релизах. Как часто на продакшн? Как часто с задержкой?
вот это сильно очень попахивает спагетти в большом масштабе. И что для них характерно — значительная accidental complexity, при вдумчивом рефакторинге код сокращается в разы.

В большей мере так и есть, ну тут ничего удивительного, учитывая что проекту больше 10 лет, могло бы быть и хуже. Но все-равно, не покидает ощущение что если все переписать, количество кода и сложность уменьшиться в разы.

с этим обычно большие проблемы в релизах. Как часто на продакшн? Как часто с задержкой?

Тут все отлично, continious integration, continious deployment, все как и должно быть. Распределенная билд система берет все на себя. Если повезет — справляется за час, если нет (много компов выключено, много комитов, кривые комиты которые валят кучу тестов), то может занять более 4-5 часов.

бюджета на такое переписывание обычно нет
я видел когда переписывали что бы избавиться от легаси технологии но это все таки не то

бюджета на такое переписывание обычно нет
и хорошо что нет, потому что мы все знаем чем всегда заканчиваются глобальные переписывания. Хорошо работает постоянный рефакторинг, from the grass roots, с постепенным расширением скоупа и вовлечением бизнеса, который начинает видеть реальный возврат инвестиций сейчас.
потому что мы все знаем чем всегда заканчиваются глобальные переписывания
Ну я вот знаю, что twitter переписали с Ruby на Scala. И норм, едет и бибикает.

Ну то ж не риврайт с фризом по фиксированному бюджету.

В большей мере так и есть, ну тут ничего удивительного, учитывая что проекту больше 10 лет, могло бы быть и хуже.
наспагетить можно и за год продуктивно, а 10 лет не такой уж и срок.

Это вы пытаетесь хвастаться или жалуетесь на жизнь?..

у меня чуть больше чем 4 гига c git тянется ( а билдится это вообще в бегемота)
24 метра это детский сад штаны на лямках

Вы так пишете, будто хвастаетесь этим ) У меня на прошлой работе тоже 3 гига С++ репозиторий был, но полезного кода там были доли процентов — остальное обвязки и костыли, чтобы это хоть как-то работало. В Go же количество harness-кода на порядки меньше чем в вашем богоподобном энтерпрайзе.

я не хвастаюсь — у меня просто бомбит когда люди с 24метрами сорцов думают что видели что такое проблемы со сборкой или большой проект )
к сожалению там только в одном продукте 5К таблиц в оракле и количество функционала чудовищное

Так вы и не экстраполируйте big ball of mud на весь мир software. Сами себя загнали своими технологиями в адский ад, тратите невероятное количество усилий просто чтобы заставить код билдится, и считаете, что это круто и дает право хаять другие языки, где таких проблем нет как класса? Имхо, умение использовать правильные технологии для правильных задач — это важный навык, и он требует кругозора и уважения к другим технологиям. А не вот этого вот, что вы тут развели :)

ты по моему вообще не понял о чем я говорил тк сам никогда с подобными проектами не сталкивался
Короче еще один упоротый наглухо гофер перешедший с пиления котиков на пехепе
По моему у вас ребята есть серьезные проблемы с завышенной самооценкой

Как меня умиляют эти джависты-фанатики, которые сначала себе травмируют психику 4гигабайтовыми исходниками, а потом возносят себя до небес и считают, что все кто не в их мирке — «пишут котиков на пехепе».

Ну, не буду разрушать хрупкие иллюзии.

То что сейчас нету 4-х гибовых исходников на го, вовсе не значит что с ними не будет такойже адский ад работвть, когда они появяться, если конечно го выживет и таки пойдет на большие проекты в ынтерпрайз.

у меня чуть больше чем 4 гига c git тянется ( а билдится это вообще в бегемота)

git-репозиторий linux со всеми коммитами начиная с 1991 года сейчас занимает 1.27GB (сюда входит гигантская папка staging — github.com/...ee/master/drivers/staging — куда постоянно льется большой поток кода):

$ git clone https://github.com/torvalds/linux
Cloning into 'linux'...
remote: Counting objects: 4480343, done.
remote: Compressing objects: 100% (1665/1665), done.
remote: Total 4480343 (delta 1157), reused 154 (delta 154), pack-reused 4478522
Receiving objects: 100% (4480343/4480343), 1.27 GiB | 4.09 MiB/s, done.
Resolving deltas: 100% (3735668/3735668), done.
Checking connectivity... done.
Checking out files: 100% (52221/52221), done.

И все исходники линкуса из 19М строчек сейчас занимают 500Мб:

$ find linux/ -name *.[ch] | xargs cat | wc 
18840211 60573062 543750226

Вы что, написали там восемь ядер линукса?

p.s. Скоро жава будет запускаться на гоу — github.com/zxh0/jvm.go

Ну как бы ядро линукса большой проект но бывает и хуже )
это когда сотни или тысячи людей пишут десятилетиям. Буквально.
и это у нас еще нет настоящего ужаса — ну например стореджа на майнфрейме с десятками миллионов loc. Кто это видел в цирке не смеется

Ну как бы ядро линукса большой проект но бывает и хуже )
это когда сотни или тысячи людей пишут десятилетиям.

Так ядро линукс вроде пишут тысячи программистов уже третий десяток лет. Но они сумели создать в 8 раз меньше кода, чем в вашем репозитории. Наверное, непрофессиональные программисты.

Так ядро линукс вроде пишут тысячи программистов

Тыщи программистов какраз не ядро пишут, а драйвера и модули, и если вы их всех посчитаете, там кода поболее получиться.

19M строк это со всеми mainline драйверами и модулями.

Все драйвера лежат в репозитории с ядром в папке drivers — github.com/...linux/tree/master/drivers . И этот код учитывался при подсчете.

вангую, то есть совсем не удивлюсь, если в ближайшие 5-10 лет произойдет:
— GoLang попадет в 20ку в рейтинге TIOBE. с нынешнего 50го места.
— GoLang начнет серьезно конкурировать с Node.js
— GoLang станет чаще применяться в HiLoad проектах чем Java
— На GoLang начнут переписываться проекты типа Apache Cassandra.
— Для GoLang появятся либы типа JBoss Drools, для описания бизнес-логики.
— Под давлением популярности Пайк и Ко — обогатят, исправят дизайн языка, к которому уже сейчас есть вполне рациональные замечания. С расширением типов применения — их будет еще больше.

По каждому пункту могу написать почему этого может не произойти. Жизнь она такая, полна непредсказуемых «случайностей». Но писать много.

Заменит ли GoLang Джаву? — нет. и не из-за легаси проектов. PHP — он тоже не заменит, и не вытеснит.

А вот в 10ку TIOBE — у него есть шанс попасть. Но утверждать это сложно. там есть два кандидата на выбывание — Perl и Ruby. и от их активного развития зависит — уступят они свое место GoLang или нет

Вы меня разочаровали, уже завтра собирался начать учить потенциальную убийцу scala, java и C# а вы говорите о какой-то 20ке и конкуренции с node.js.

а зачем убивать Скалу, когда она и так — мертва?
скорее Erlang с Elixirом рванут по популярности чем Скала.

а Джаву или Сишарп да, учить полезно.

Вы меня разочаровали, уже завтра собирался начать учить потенциальную убийцу java и C#
а вы меня нет :)

как и следовало ожидать — у вас как и у многих «знатоков» вера в единственный ЯП для всего. вы пока не поняли почему такого не случилось доныне, и врядли на нашем веку случится.

но да, ищите убийцу всех ЯП среди сложных ЯП типа Scala. Сложные ЯП ж побеждают более простые всегда, это всяк знает, кто интересуется историей развития языков программирования ;)

На работе пишу на .net и всем что с ним связном, в дома попиливаю на скале и jvm, есть еще всякая мелочь типа жаваскрипта, питона и т.д., в ближайшее время планирую поиграться с go и даже применить в одном проектике (если оправдает ожидание).

Помогите определиться с верой, в какой ЯП мне верить как в единственный правильный язык?

Короче вы меня с кем то путаете. Это гошники каждый день убивают то питон, то жаву, то скалу, то хаскель, и считают go единственным правильным языком где нет ничего лишнего.

Короче вы меня с кем то путаете. Это гошники каждый день убивают то питон, то жаву, то скалу, то хаскель, и считают go единственным правильным языком где нет ничего лишнего.
не знаю кого там убивают гошники, но что статьи о GoLang вызывают возбужденные обсуждения у школоты — факт.

о том и написал.

Помогите определиться с верой
не помогаю в таких вопросах.
потому что глубоко убежден — заставь дурака молиться — он и лоб расшибет. а потом тебя же обвинит что это ты ему голову разбил.
— Для GoLang появятся либы типа JBoss Drools, для описания бизнес-логики.
Это вряд ли.
В моем понимании Drools — это самая вершина корпоративного айсберга, которая стоит поверх первого уровня: Servlet API, JDBC, ... и второго уровня JSF, JPA, JAX-RS, WS-*...
-
И вот имея эти два уровня к ним третьим уровнем пишут оркестрацию.

неа, думаю BI, EDW и workflow инструменты выше в пирамиде
а drools это обычная запускалка правил. чаще всего используют для вещей типа навигации по визардам или динамического изменения форм.

Это вряд ли.
В моем понимании Drools
в целом да. Drools на ум пришел как пример. наверное неудачный.

Скажу так
если на ЯП с развитой системой классов, или настоящем функциональном (C++, Java, C#, Scala, PHP 5.2+, Ruby, Python, Haskell, ...) бизнес-логику можно писать без особых проблем, то на ЯП лишенном таких возможностей (С, GoLang, ..., SQL, ...) - либо писать много нечитабельного кода (проклятие джависту «да чтоб ты до конца дней писал на PL/SQL!») — либо нужна какая-то либа или внешний сервис

— GoLang станет чаще применяться в HiLoad проектах чем Java
— На GoLang начнут переписываться проекты типа Apache Cassandra.
А зачем? Оно все неплохо крутится на JVM, вместе с Kafka (Scala) и Spark (Scala), Hadoop (Java)/Hive(Java), ...
А зачем? Оно все неплохо крутится на JVM
затем что если работа ноды на GoLang требует меньше вычислительных ресурсов чем на JVM, то на облачных объемах — это нехилая экономия у датацентров будет.
по тем цифрам что видел о сборщике мусора в GoLang — он эффективнее по расходу ресурсов чем JVM. в силу более простого ЯП а не какой-то супер гениальности инженеров в команде Пайка.

Конечно, переписывать все подряд не будут. Дорого. Но... как сказал — не удивлюсь если будет обычным делом, постепенный перевод некоторых продуктов для облаков с JVM на Go.
Просто на сейчас, не один год, у JVM альтернатив нет. GoLang — первая серьезная альтернатива, хотя появился по «смешному» поводу, и сам «смешной». Прямо оборжаться можно с уродца PHP/FI. Какой-то тупень Расмус Лердорф ни асилил Perl, и выкатил это позорище. Сейчас скалисты и не только так ржут с GoLang как тогда перлушники :) (впрочем перлушники и доныне потешаются над PHP. А плюсовики над Java. и т.д.

Да, всякие LLVM варианты — не альтернатива JVM потому что — УЖЕ не стали ею.

по тем цифрам что видел о сборщике мусора в GoLang — он эффективнее по расходу ресурсов чем JVM. в силу более простого ЯП
На маленьких кучах (совсем уж микросервис) и JVM отлично справляется, а для больших (10Gb+) необходимо
— посмотреть таки тесты Go на таких массивах данных
— надо иметь язык на котором можно наваять 100500 строк кода, что бы потребить столько памяти (не уверен, что это — Go). Скажем, вряд ли, Docker выделяет миллионы объектов для гигабайтов кучи.
---
Я не в восторге от микросервисов на Java (Spring stack) и Scala (Finagle), и вполне допускаю, что на Go они выглядят лучше. Но в то, что большие JVM-приложения будут переписываться на более простой язык (Go) — не верю (не вижу предпосылок).
— посмотреть таки тесты Go на таких массивах данных
конечно самый точный ответ — это эксперимент.
пока The current implementation is a parallel mark-and-sweep collector. docs.google.com/...5YXZLovrHvvLhK_h0KN8woTO4
но если в Go появится вид инкрементального сборщика — то ему без разницы объемы данных.
плюсовики пояснят про всякие auto_ptr. а Rustовцы про контроль за временем жизни на синтаксическом уровне.

из тестов пока могу по быстрому:
www.techempower.com/...9&hw=i7&test=json
benchmarksgame.alioth.debian.org/u64q/go.html

надо иметь язык на котором можно наваять 100500 строк кода,
как уже сказали — меряние по количеству строк кода, не совсем критерий для оценки эффективности — конечной системы.
Скажем, вряд ли, Docker выделяет миллионы объектов для гигабайтов кучи.
Dockerу да, не нужно.

Но микросервисной ноде — тоже этого не нужно!
миллионы объектов для гигабайтов кучи — это расплата для монолитного типа приложений! и, конечно для In-memory database

то есть, любой ЯП проиграет, если на нем программировать в парадигме другого ЯП.
у каждого ЯП есть — свой, language way. Какой он у Go — думаю еще сложно сказать. но точно — не такой как у ООП языков типа C++, Java, C#.
И если на нем проектировать и программировать как на С++... — то выйдет ерунда, и нафик он такой тогда нужен.

— надо иметь язык на котором можно наваять 100500 строк кода, что бы потребить столько памяти (не уверен, что это — Go).

У нас сервер на гоу в 2к строчек кушает 10 гигабайт памяти. При обслуживании миллиона одновременных http-подключений.

Что такое

миллиона одновременных http-подключений
это 1.000.000 http persistent connections? Или 1.000.000 запросов, которые непосредственно сейчас обрабатываются сервером?
Но в то, что большие JVM-приложения будут переписываться на более простой язык (Go) — не верю (не вижу предпосылок).
переписывание приложения, особенно огромного практически никогда не оправданно. это болезни/мечты мидлов о переписывании

Имхо, прям так совсем — еще рано заявлять.
Должна еще вылизаться инфраструктура, тулы, появиться подходы, и обучающий материал. Делов всего на пару лет, но посмотрим, ведь «конкуренты» тоже не стоят на месте.

Все так и не так. Простой ЯП требует более постую инфрастктуру и тулзы. Обучение простому ЯП, который не содержит новых концепций, тоже несложное.
А сложные конкуренты — проще не станут.

И, силу энтузиазма — никто не отменял. Если фаны Go реально получают кайф от разработки на нём, а не просто в инетах рассказывают, и если комьюнити будет прирастать, то инфраструктура и тулзы будут появляться весьма быстро.

Энтузиасты на той же Скала — могут ли что написать для неё со своим полуджавским уровнем?
А вот для Go, как понимаю, теоркат не нужен

Энтузиасты на той же Скала — могут ли что написать для неё со своим полуджавским уровнем?

Они могут написать тоже что и энтузиасты го для го.
На скале писать как на хаскеле необязательно, и большенство проетов, по моему субъективному мнению такими и являются. Взять тот же спарк, который сейчас на некотором подъеме — там внутри нету никакого терката.
Хоть код всеравно сложнее чем го, конечно.
Они могут написать тоже что и энтузиасты го для го.
УЖЕ не могут. Сколько лет Скале?
не могут — потому что Скала — сложная, и в основном осваивается на уровне улучшенной Джавы.
Взять тот же спарк, который сейчас на некотором подъеме
не слышал. про Докер — слышал и видел. А что такое спарк этот?

Или — Play Framework. Круть же. И?

Хоть код все равно сложнее чем го, конечно.
отож.

После выхода 8ой джавы пользоваться Скалой как «улучшенной джавой» смысла нет.
А пользоваться всем семантическим богатством мультипарадигменной Скалы могут немногие, потому что это требует не только энтузиазма и усидчивости, а бекграунда который нельзя получить только будучи программистом практиком.

на Джаве — можно вполне толково писать без такого бекграунда. на С можно. на C# можно, — см двадцатку TIOBE короче.
и на Go можно.

на Haskell, Scala — низя.
Даже OCaml и F# можно, на практике осваивать, не закапываясь в теории типов, теоркаты, аппликативное программирование, ..., ....

поэтому энтузиасты Scala — на посты о нисиляторах только и способны. в большинстве своем они сами такие и есть.
главное — они не написали, и уже не напишут тьму софта, тулзовин на Scala.

а каждый уважающий себя PHPист обязан написать свою CMS. и ведь пишут, в одиночку, и неплохие!
а на крутой такой Scala — в чем проблема? крутые парни, на крутом языке, и? иде выхлоп в виде тьмы софта, бОльшая часть которого ессно окажется поделиями и лисапетами, но все же?

то есть, мы подходим ко второму вопросу:
насколько повышает производительность труда программиста — круть языка. имеется ввиду — освоившего, без кавычек, этот ЯП.
тупые пыхери, ниасиляторы от сохи педалят и педалят разной сложности и запаха ПО. на чем вебщина живет? на джаве, руби? а, да, на Спарке?

Крутые скалеры и хаскелисты, на более мощных языках, с реально бОльшими знаниями в самих основах программирования. И?

а далее еще более глубокие причины:
математическое мышление vs инженерное vs лингвистическое.
но это тема уже из разряда философии математики.
а что математику, что философию большинство знает плохо или никак.
какая еще Скала этому большинству?

А что такое спарк этот?
lmgtfy.com/?q=spark
на Scala — низя.
Ложь и провокация. Учить скалу и потом успешно ее использовать, не зная, что такое «аппликативный функтор» не просто реально, а во многих случаях даже правильно. Язык в своей основе состоит из нескольких ортогональных фич, из которых затем строится что угодно, такая уж у него философия. А сразу нырять в самые глубокие впадины никто не заставляет, и часто это не нужно.

Загуглите уже «scala» на гитхабе.

lmgtfy.com/?q=spark
и?
гугл много чего знает.
и? какое отношение имеет знание гугла о чем-то с распространенностью этого чего-то в жизни?
Ложь и провокация. Учить скалу и потом успешно ее использовать
да, да.
а во многих случаях даже правильно
это во скольких процентах случаев, подтвержденных не досужими домыслами, а хоть какими то цифрами?
Загуглите уже «scala» на гитхабе.
и что означают цифры на гитхабе?

вы наверное не знаете. Поясняю — цифры на гитхабе показывают кто-то что комитит на гитхаб с словом Scala. будем считать что это всегда — исходный код на Scala.
Какое отношение код который комитят на гитхаб имеет к коду который используется в проектах?

Но, ок
спросим гихаб, шо на него комитят
Scala We’ve found 30,270 repository results
PHP We’ve found 162,750 repository results
Go We’ve found 166,746 repository results
Java We’ve found 252,663 repository results

да, победа Scala очевидна!

вы наверное не знаете. Поясняю — цифры на гитхабе показывают кто-то что комитит на гитхаб с словом Scala. будем считать что это всегда — исходный код на Scala.
Ну не позорьтесь так явно, «language:smth» в помощь. Я даже помогу, раз интерфейс гитхаба вызывает такие трудности:
«We’ve found 59,759 repository results» для «language:scala».
«We’ve found 99,722 repository results» для «language:go».
«We’ve found 1,577,618 repository results» для «language:java».

Вопрос был: «где софт на скале?». Я не утверждаю, что его больше всего. Особенно, если учесть, что из Скалы прекрасно вызываются библиотеки на Джаве. Я утверждаю, что он есть, и используемый в «продакшне».

какое отношение имеет знание гугла о чем-то с распространенностью этого чего-то в жизни?
Если вы чего-то не знаете, это не повод кричать о своем невежестве. Потрудитесь прочитать, что такое Спарк, и где его область применения.
это во скольких процентах случаев
В тех случаях, когда изучающий по каким-то причинам не знаком с «теоретическими основами». Я сильно сомневаюсь, что все гоферы изучали CSP, но это не мешает успешно использовать горутины. Точно так же и с «функциональщиной», «матаном», и практически всем.
подтвержденных не досужими домыслами, а хоть какими то цифрами?
Научитесь вести конструктивный разговор, и не портите репутацию языка, за который так фанатично болеете.
Ну не позорьтесь так явно
пока я наблюдаю привычный позорище «энтузиастов X» — полную неспособность понять о чем речь :)
Я утверждаю, что он есть, и используемый в «продакшне».
особенно когда я и не говорил что его нет в продакшене.
потому что в продакшене чего только нет.
В тех случаях, когда изучающий по каким-то причинам не знаком с «теоретическими основами».
не вижу цифр. ссылок на исследования. хоть на что-то, кроме пустословных рассуждений.
Научитесь вести конструктивный разговор
с кем? с тем кто ни асиливает тезисы оппонента? кто находится на уровне — «а вот я знаю случай»?
и не портите репутацию языка, за который так фанатично болеете.
и за какой язык болею? приведите мне цитатку о том где я болею.

вот вы да, явно больны «скалой», раз столь нелепой аргументацией за нее вступаетесь.

Наблюдая за подобными адептами скалы не один год и понятно — ей массовость не грозит. болеющие есть — а вот писать на ней некому.

«We’ve found 59,759 repository results» для «language:scala».
«We’ve found 99,722 repository results» для «language:go».
да, действительно, победа за scala
«We’ve found 1,577,618 repository results» для «language:java».
да, эти цифры говорят что Scala убила Джаву окончательно.
R.I.P. Java
особенно когда я и не говорил что его нет в продакшене.
иде выхлоп в виде тьмы софта
Я не зря взял слово «продакшн» в кавычки. Софт есть, «тьма» это или нет, судить не берусь.
да, эти цифры говорят что Scala убила Джаву окончательно.
Вы читать умеете? Где я писал, что Скала убивает Джаву?

На всякий случай, поясню еще раз — очевидно, что для Го будут делать многие вещи, которые уже решены на Джаве, потому что языки не совместимы. Очевидно, что Скала может переиспользовать код с Джавы. Очевидно, что эти вещи не нужно велосипедить на Скале.

Я даже не утверждаю, что Скала 100% лучше Го, это, очевидно, не так. Если для какой-то моей задачи Го подойдет лучше, я выберу его. Поэтому мне интересны границы применимости Го. Сейчас я считаю, что для «крупных проектов» использовать Скалу выгоднее, чем Го. Чтобы убедиться наверняка, я бы хотел поучаствовать в каком-то проекте на Го (вполне вероятно, что я не прав, и аргументы гоферов более весомые), но мысль, что я могу работать вместе с неадекватами вроде вас, убивает энтузиазм.
с тем кто ни асиливает тезисы оппонента?
Вы приписываете мне то, что я не говорил. Вы ни разу не ответили по теме. Пуслослов здесь — вы. Разговор окончен.
Софт есть, «тьма» это или нет, судить не берусь.
так что вы тогда решили сказать? что опровергнуть?
Вы читать умеете?
конечно не умею. разве не понятно?
Вы приписываете мне то, что я не говорил.
ну зато с вами все проще — вы вообще не читали что я писал в этой теме, а решили блеснуть чем-то.
но я так и не понял чем.
обычное дело.
да и ладно. «очередной лайк к мнению 300ех хабровцев» не имеет значения.

о чем и был мой первый комент в этой теме :)

Вы ни разу не ответили по теме.
нельзя ничего ответить по теме тому кто вообще не в теме.
Пуслослов здесь — вы.
у вас Scala — основной язык — сколько лет?
Ну не позорьтесь так явно, «language:smth» в помощь. Я даже помогу, раз интерфейс гитхаба вызывает такие трудности:
«We’ve found 59,759 repository results» для «language:scala».
«We’ve found 99,722 repository results» для «language:go».

Кстати, интересно посмотреть, как изменяется количество репозиториев на скала и гоу со временем. Сейчас цифры такие:

Scala — We’ve found 62,335 repository results — github.com/search?q=language:scala . Плюс 2.5К репозиториев или где-то 4%.
Go — We’ve found 106,136 repository results — github.com/search?q=language:go . Плюс 6.5К репозиториев или более 6%.

Очевидно, что гоу одерживает верх над скалой не только по количеству репозиториев, но и по скорости прироста новых репозиториев.
Также у популярных репозиториев на гоу намного больше лайков (звездочек) по сравнению со скалой — 28.5К у Docker vs 8.5К у PredictionIO. Кстати, почему все знают про Docker, но никто не слышал про PredictionIO?

почему все знают про Docker, но никто не слышал про PredictionIO?
наверное потому что докер это тулза для админов, а PredictionIO — для data scientists, которых на порядки меньше

Надеюсь, теперь вам понятна целевая аудитория этих языков?

Гоу — для продакшна.
Скала — для матана.

Скорее так — скала для сложных вещей, а го для унылого мелкого говна

Если для вас унылое мелкое говно является синонимом продакшна, то ОК.

Нет — унылое мелкое говно, это всякие утилитки
И докер к ним тоже относится

Почему у Го больше лайков и реп — хайп от Гугла (да и вообще его пиарят вовсю, интересно, сколько миллионов вбухано в маркетинг). Из десятка споров ирл аргумент «ну его Гугл придумал» был использован в 100% случаев.

Сравнивать 4% и 6% роста — просто несерьезно, это на грани погрешности. Мое мнение — где-то через пару лет с Го наиграются, набьют шишки на крупных проектах, и перестанут пихать туда, где он демонстрирует слабые стороны.

К PredictionIO отношусь скептически, но докер я вообще ни разу не использовал (далек от темы «девопса», и смутно представляю, с чего вообще шумиха). У вас выборка нерепрезентативная.

Это не моя выборка. Это наиболее популярные репозитории на гитхаб по каждому из языков программирования.

Сравнивать 4% и 6% роста — просто несерьезно, это на грани погрешности. Мое мнение — где-то через пару лет с Го наиграются, набьют шишки на крупных проектах, и перестанут пихать туда, где он демонстрирует слабые стороны.

4% vs 6% в месяц превращаются в 60% vs 100% в год. Согласитесь, разница существенная.

Через пару лет 95.7% продакшн кода будет писаться на гоу.

Через пару лет про контроль эффектов через монадические трансформеры будут на собеседованиях джунов спрашивать ;)
(на регулярном базисе, конечно). Потому что ФП концептуально более надежное и поддерживаемое, чем императивщина.

Как следствие, на Го будут писать в лучшем случае софт типа докера.

Через пару лет про контроль эффектов через монадические трансформеры будут на собеседованиях джунов спрашивать
уже спрашивают

Дополню свой ответ. Именно «монадические трансформеры» будут спрашивать из желания поиздеваться проверить более глубокие знания. А вот штуковины типа referential transparency, почему сайд-эффекты — нехорошо, и как от них уходить (где-то здесь можно вывернуть на монады, а затем и на трансформеры), как сделать выбор между мутабельностью и иммутабельностью и прочее в таком духе уже вошли в общепринятые вопросы программирования в целом.

За ФП будущее, потому что вышеописанные вещи не просто идеально ложатся на ФП, а ФП было придумано для них. Некоторые вещи спорны (те же трансформеры), некоторые непрактичны (типа рекомендуемых в FPPiS трамплинов), но тенденция правильная.

Также в пользу моего прогноза говорит то, что компиляторы сейчас гораздо более умные, чем 15 лет назад. А оптимизировать код-"что делать" можно куда сильнее, чем код-"как делать".

И касательно языков. Го уйдет. Скала уйдет. Ни первый, ни второй ЯП не идеален. Вместо них появятся более удобные инструменты. Но понимание описанных в первом абзаце вещи останется все такой же базовой необходимостью.

(вот только Го уйдет куда раньше, ровно через месяц после того, как Гугл наиграется с сусликом ;) )

За ФП будущее

lol
дикая, хтоническая, упоротая чуть более чем полностью ЧУШЬ

потому что вышеописанные вещи не просто идеально ложатся на ФП, а ФП было придумано для них

патамушта патаму канчается на у

блин, вы же, упоротыши функциональные, с формальной логикой, по идее, плотно работаете постоянно

как, вот КАК из констатации факта «есть вещи такие-то и такие-то, важные в таком-то контексте» следует «этот контекст станет доминирующим (потому что есть инструменты хорошо эти концепции реализующие)»?

на деле, ваш контекст, как универсальное средство — гвно: он годится только для обработки линейных списков,

для инженерии же реального мира, где сущности имеют _состояния_, да еще и разворачивающиеся во времени — подходит примерно как гондон в качестве головного убора

а потом вы вынуждены неистово монадировать, в попытке таки резинтехническое изделие натянуть

Очень аргументированный ответ. Хорошее продолжение дискуссии.

К слову, стейт отлично описывается в терминах ФП. Как и проходящее время. И как раз работа с последним в языках без продвинутой системы типов — боль и унижение.

Есть области, где та же иммутабельность мешает — некоторые структуры данных (хотя Окасаки и последователи догоняют), низкоуровневые ресурсоограниченные вещи (иногда удобнее поменять часть обьекта, чем плодить ссылки-диффы). Очевидно, что у всего есть границы применимости, и нефиг их нарушать. Но для подавляющего большинства задач ФП просто удобнее.

как, вот КАК из констатации факта «есть вещи такие-то и такие-то, важные в таком-то контексте» следует «этот контекст станет доминирующим (потому что есть инструменты хорошо эти концепции реализующие)»?
Потому что смещаются приоритеты задач. Больше дешевого железа => меньше необходимости экономить на спичках. Умнее компиляторы => профит от хаков не такой большой => за счет отказа от последних, повышается читабельность => повышается поддерживаемость кода. На первый план переходит надежность => необходимо уменьшать «шанс ошибки» => проявляются плюсы типизации. Еще?
Потому что ФП концептуально более надежное и поддерживаемое, чем императивщина.
Анекдот про «концепция поменялась» згадався.
На практиці, високолобим чувакам опосля написаного стає скушно саппортити і розширяти, і вони йдуть. А у менеджерів потім голова болить, де знайти чуваків за вмєнямі гроші, і щоб їм не скушно було.
Paul Graham & Co наваяли Yahoo Stores на Lisp. Всі функціональщики, як з писаною торбою з ним носилися. А потім він пішов, і довелося все для саппорту переписати на C++, тому що саппорт і є наявність розробників на ринку.
Через пару лет 95.7% продакшн кода будет писаться на гоу.
чувак, ну открой все-таки нам секрет, где ж ты такую забористую берешь! Ну или отсыпь хотя-бы

апдейт:
github.com/search?q=language:scala — 69701 репозитория или +11%.
github.com/search?q=language:go — 124535 репозитория или +17%.
Итого — полная победа go над scala.

тупые пыхери, ниасиляторы от сохи педалят и педалят разной сложности и запаха ПО.
Крутые скалеры и хаскелисты, на более мощных языках, с реально бОльшими знаниями в самих основах программирования. И?
ну насчет хаскелистов — таки что-то педалят (по крайней мере знаю штук пять веб-фреймворков на хаскеле + есть пара зенакомых хаскелистов, которые едалят хаскель в продакшене). Правда то, что они педалят в основном внутри хаскельного комьюнити известно, чему во многом «способствует» «матанство» хаскеля (хотя есть книженция одного российского хаскелиста Д.Шевченко «О Haskell по человечески», которая демонстрирует, что не так страшен хаскель, как его малюют).

А так да — напедаленного на более простых и понятных языках типа похапе или питона таки в разы больше, чем на хаскеле и скале)

З.Ы. И у меня чуйка, что скала посложнее хаскеля будет, ибо туда помимо хаскельного матана впихнули джавовский матан))

ну насчет хаскелистов — таки что-то педалят
и не только хаскелисты. опять же — я разве говорил что они, или скалисты ничего не педалят в продакшн?
А так да — напедаленного на более простых и понятных языках типа похапе или питона таки в разы больше, чем на хаскеле и скале)
вот этого то упоротые «фанаты скалы» и не видят :) сколько не читал их аргументов за эти годы, еще до вот нового всплеска активности, в виде Go-хейтерства, для них это — никакой не факт, а выдумка ниасиляторов. :)
И у меня чуйка, что скала посложнее хаскеля будет, ибо туда помимо хаскельного матана впихнули джавовский матан
да, где-то так. я бы заменил посложнее на поопаснее.
мультипарадигменность дает возможность сбежать в привычную императивщину. что у недоскалистов порождает ощущение простоты вхождения в язык.
Хаскел же не позволит сбежать. ты либо асилишь нечто вроде «О Haskell по человечески», либо выматеришься и больше за него не сядешь.

В скальных кругах поэтому встречал что пришедших из классической императивщины и ООшности нужно вначале сажать за Haskell, или, если все же щадить, то за OCaml. и только после успешной сдачи на «джун хаскеля» подпускать к Scala.
как раз потому что педаля на «улучшенной Джава» — они не выходят с зоны комфорта. и никакой такой Scala не понимают. а когда встречают профессиональный код на ней — требуют:
а пусть менеджмент пропишет в коде стайл проекта ограничения! вот те, те и те фичи языка — не использовать! (потому что мы — никогда ни асилим. ни через год, ни через пять. их бессознательное — им об этом кричит)

но вот на форумах то эти ниасиляторы самые громкие адепты за Scala :)

Вообще, для меня активные собачилова Go vs «Scala» интересны тем, что ничегошеньки не зная об этих двух языках, можно довольно точно кто из них победит, читая сугубо аргументы сторон. Побеждает ведь не ЯП, а активность и производительная конструктивность комьюнити.
это не классический холивар, как например NVidia vs AMD где уровень аргументации одинаков, а выставить коэффициенты к плюсам минусам чтобы свести к вердикту — победитель-проигравший — вряд ли возможно. по крайней мере — очень сложно, не представляю как.

во-первых потому что за Go агитируют те кто на нем уже пишет, а за Scala те которые чего-то там пробовали, или, как уже писал — пишущие не на Scala а на улучшенной Java. мне легко отличать, потому что на моем веку я видел как завоевывал место под солнцем C++. И тогда тоже был совет — чтобы отучить писать на «С с классами», выдавая это за С++, нужно вначале посадить за Smalltalk.
во-вторых, и это важнее — недоскалисты напрочь не слышат что им говорят. они на своей волне :) о, примерно как грамманаци, цепляются к каким-то малозначимым деталям в мнений энтузиастов Go пропуская главное.

ну а такая слепота признак «смерти». это неадекватность в хрестоматийном виде. «деменция», «функциональная неграмотность». утрировано говоря — недоскалисты ничего не заметят даже тогда, когда гипотетически, Go в первой пятерке TIOBE будет. они будут далдонить тоже самое. о плохом дизайне, ниасиляторах, о славе Спарка, о том что

Учить скалу и потом успешно ее использовать, не зная, что такое «аппликативный функтор»
 — то есть что «С с классами» это С++, что «улучшенная Java» это Scala, ... при этом «сидя на Perl в каком-то агромном ИТ отделе», как в одной статье было меткое о лекторах заоблачных подходов в программировании.

Шевченко если че себе с трудом работу мидлом нашел )))
так что с ботанством у хаскелистов все ок

но нашел же — это главное) а на ботанство мне как-то пох)

Если я правильно догадался, о ком ты, то «с трудом» это годовые поиски, а тут точно такого не было :)
И, кстати, за счёт своего «хаскелизма» он тут такие штуки наворачивает, что я завидую бело-зелёной завистью.

а еще полезно знать что автор книжки пол года искал работу мидл хаскелистом
что еще раз подчеркивает практическую ценность оного

а еще полезно знать что автор книжки пол года искал работу мидл хаскелистом
Ага, то есть, им будет руководить синьор, с поднятым вверх пальцем, который никаких книжек по хаскелю не писал.

Ну или то что чувак написавший вроде как годную книжку не тянет на синьйора по принятым понятиям. Я бы опасался вкладывать время в язык с настолько упоротой тусовкой как хаскель

Кстати тусовка функциональной скалы — такаяже упоротая, видимо по тому, что хаскелисты не найдя работы на хаскеле, перешли на скалу, чтобы хоть какуюто работу найти.

Вот же незадача, хаскель — такой продвинутый язык, а вакансий нет.

Неосиляторов очень многа. Посмотрите на местных гошников в топике «зачем чтото осиливать, если можно херак херак на го и оно миллион соединений будет держать». Причем бизнес скорей гошников и прочих нодежс разработчиков поддержует.

не слышал
А что такое спарк этот?

То что вы в личном танке, не значит что другие ребята не пользуються — каждая 3-я вакансия по биг дате в джава инфраструктуре нынче включает тем или иным образом спарк.
После выхода 8ой джавы пользоваться Скалой как «улучшенной джавой» смысла нет.
Вам из танка виднее конечно.
Я вам просто по секрету скажу что между «улучшеной джавой», и «хаскелем на скалаз» есть «нормальная скала», для которой не нужно теорката, и которая всеравно имеет ряд преимуществ перед джавой.
поэтому энтузиасты Scala — на посты о нисиляторах только и способны. в большинстве своем они сами такие и есть.
главное — они не написали, и уже не напишут тьму софта, тулзовин на Scala.
Опять таки, вам из танка виднее.
а каждый уважающий себя PHPист обязан написать свою CMS. и ведь пишут, в одиночку, и неплохие!
а на крутой такой Scala — в чем проблема? крутые парни, на крутом языке, и?
Да, цмски на скале никто не пишет, пишут инфраструктуру для биг даты.

Короче, если чесно, мне не интересно спорить с великим мыслителем Воздушным Сергеем, который на скале не работал и не писал, технологий и рынка не знает, но в дебри философствования отправляеться. На сим закончу.

каждая 3-я вакансия
почему-то я уверен, что можно подобрать такое «по ...» что 80% вакансий будут содержать что-то на Haskell.
Опять таки, вам из танка виднее.
в танке вы, если ничего кроме биг даты не знаете :)
Я вам просто по секрету скажу что между «улучшеной джавой», и «хаскелем на скалаз» есть «нормальная скала», для которой не нужно теорката
это конечно, не для всякого проекта на C++ нужен Boost.
Вот только мнение ратующих за С++ и не понимающих как устроен Boost — неинтересно. пусть его залайкают не только на хабре, а и на реддите.

тоже и с мнением о Scale недоскалистов. А где скалисты тусуются я знаю, чтобы послушать профессиональное мнение, а не мнение плебса, рядящегося в одежды «элиты».

Да, цмски на скале никто не пишет
надо же какое откровение. «Грамманаци» накопал очередную «ошибку», и при этом в танке не он :D
На сим закончу.
да, заканчивайте ковырять изюм из булочек, для того чтобы доказать что он на полях колосится, а не пшеница.

Ваш пост очень в точку. Для 2010го года, правда.

вангую, то есть совсем не удивлюсь, если в ближайшие 5-10 лет произойдет:
— GoLang попадет в 20ку в рейтинге TIOBE. с нынешнего 50го места.
Не прошло и года, как Go занял 13 позицию в рейтинге tiobe, а также признан языком 2016 года — www.tiobe.com/tiobe-index .
Не прошло и года, как Go занял 13 позицию в рейтинге tiobe, а также признан языком 2016 года
Скоро Go даже потеснит английский! И китайский!

Насчет китайского в точку — большинство go-проектов на github написаны китайцами. Так что скоро go станет официальным государственным языком программирования в Китае.

Я тоже заметил, что каменты в исходняках go зачастую на китайском. Это также означает, что все рейтинги Go взлетят до небес.

Пока Go видится как более быстрый питон со статической типизацией.

Не-а. Это чуть осовремененный Паскаль, замаскированный под потомка Си. Такой вариант описания самый адекватный из всех вариантов через сравнение.

a) не слышал пока об успешном опыте применения go в больших проектах
В Google 3+ млн строк кода на Go, в Dropbox-е — 400 тысяч. И, в отличие от всяких дотнетов процент полезного кода относительно static private void const обвесок и деклараций совсем другой. Так что зря вы хвастаетесь своими гигабайтами мусора, которые поддерживают пару тысяч строк непосредственной логики.

От создателей «дебагер не нужен», «IDE не нужна», «дженерики не нужны» — «Код на го короче».

Ох go-шники и упоротые. Как с таким примитивным языком, с такой кастрированный системой типов, где тебя просто вынуждают велосипедить и копипастить, можно писать короче код по сравнению с той же джавой, не говоря уже о шарпе и скале? Может какие-то отдельные задачи и можно заимплементить короче, но проект в целом — даже теоретически не представляю как.

Проще? Да. Быстрее? Если проект небольшой — скорее всего да. Меньше кода — это вряд ли.

Можете привести пример конкретной задачи, или куска кода на жава/шарпе, который на го выйдет короче? Я имею ввиду семантически короче, а не за счет более укороченных имен.

Не знаю как на Го но на джс запросто, но в целом так же коротко могу и на джаве переписать,только такая имплементация в джс будет органичной а на джаве корявой, хотя это вопрос восприятия.

Ох go-шники и упоротые.
Мне кажется, такими заявлениями вы опускаете себя и свое сообщество, создавая ему специфическую репутацию.
Как с таким примитивным языком, с такой кастрированный системой типов, где тебя просто вынуждают велосипедить и копипастить, можно писать короче код по сравнению с той же джавой, не говоря уже о шарпе и скале? Может какие-то отдельные задачи и можно заимплементить короче, но проект в целом — даже теоретически не представляю как.
То что вы не представляете — это понятно. Джава и шарп сильно ограничивают людей. Давайте просто сделаем эксперимент — напишите мне проект, который, пусть даже с использованием сторонней библиотеки — забирает 10 последних постов с сабреддита /r/java и выводит их названия и даты в формате «дд-мм-гггг» на экран. Вот такой вот простой проект. Я хочу увидеть каждый байт, вовлеченный в решение такой простенькой задачи, каждый файл и, в идеале, увидеть сколько времени и усилий у вас это займет — начиная от поиска и интеграции внешней библиотеки в проект и заканчивая готовой сборкой.
Время пошло. Сравним.

Детский сад штаны на лямках.

Асинхронно загрузить страничку — 1 строчка
Найти нужные дивы по аттрибуту с использованием одной из библиотечек в nuget-е — 1 строчка (спасибо LINQ)
Вывести все в консоль — 1 строчка

Ну еще импорты — до 5 строчек, и главный класс — 3 строчки.

Итого, один исходный файл, один прожект файл. На выходе сборка самого проекта и сборка html библиотечки.

Это на шарпе, в джаве и скале похоже, возможно чуть больше кода на джаве.

Не страдай фигней, в го нет ничего чтобы помогло сократить количество кода.

Дайте, пожалуйста, ссылку на гитхаб с вышеописанным проектом. Таким, как бы вы писали в реальной жизни. Правда, интересно.

На гит всякую фигню заливать не буду, вот сама логика:

var json = await new WebClient().DownloadStringTaskAsync("http://reddit.api/queryblahblah");
var response = await JsonConvert.DeserializeObjectAsync<RedditResponse>(json);

foreach (var post in response.Posts)
{
	Console.WriteLine("{0} {1}", post.Date, post.Title);
}

Логику тут и думать не нужно ) Меня интересовал сам код. Как мне запустить эти 6 строчек? Я хочу посмотреть на финальный результат.

и библиотека тоже имеется github.com/SirCmpwn/RedditSharp

var reddit = new Reddit();
var subreddit = reddit.GetSubreddit("/r/java");
foreach (var post in subreddit.New.Take(10))
{
  Console.WriteLine("{0} {1}", post.Date, post.Title);
}

Спасибо. А как этот код запустить? Я так понимаю это сниппет, а не финальный проект?
Меня интересует окончательный вариант, готовый к употреблению — вся суть запроса примера кода была именно чтобы получить финальный результат.
PS. Subscribe() и Login(), думаю, тут лишние. Получить список сабреддитов можно и без аккаунта.

чувак ты прикалываешься?

public class Reddit
{
   public static void Main()
   {
      var reddit = new Reddit();
      var subreddit = reddit.GetSubreddit("/r/java");
      foreach (var post in subreddit.New.Take(10))
      {
            Console.WriteLine("{0} {1}", post.Date, post.Title);
      }
   }
}
+ пара using
но это тебе иде сгенерит

Я не прикалываюсь, а вы уже третий человек, кто избегает написать полный код. Напомню, разговор в комментах зашел о количестве harness-кода, дополнительного, вот этих всяких объявлений и деклараций, using, public static void и тд. Товарищи уверяли, что код на Go впринципе не может содержать меньше вот этого всего. Я попросил написать пример — но пример не «вот логика», или «вот несколько основных строчек, а там остальное неважно» — а *полностью*, по всем идиоматичным правилам. Не сокращенно «для примера», а так как это пишется в реальных проектах.
Что сложного? Почему все избегают этого?
Я еще там попросил написать сколько это времени заняло. Уже неделю никто не может дать код.

Нет, тебя уверяли что код в принципе не может быть короче, не говоря уже о том, чтобы быть в 10 раз короче как тут некоторые заявляли. Может какие-то отдельные конструкции и короче, из-за особенностей синтаксиса, но если рассматривать проект в целом то вряд ли, даже наоборот, будет длиннее (если конечно проект на hello world).

I have reimplemented a networking project from Scala to Go. Scala code is 6000 lines. Go is about 3000. Even though Go does not have the power of abbreviation, the flexible type system seems to out-run Scala when the programs start getting longer. Hence, Go produces much shorter code asymptotically.” — Petar Maymounko

Ссылку на код, или хотя бы на статью.

Сверху я продемонстрировал на реальном примере насколько го «короче».

Я чуть не попехнулся толи бубликом толи чаем, когда почитал

the flexible type system seems to out-run Scala
. Ну нельзя быть таким додоном. Уменьшение строк кода в результате переписывания только из-за языва — это классическое заблуждение. В результате переписывания идет нехилый рефакторинг, за счет него весь праздник. Объективно, в Го нет ничего to outrun скалу, особенно в работе с коллекциями, выразительного паттерн-матчинга, обработки ошибок и нулевых значений. Сказать, я сам рассматриваю Го как неплохой кандидат на написание утилит, хотя Rust возможно и поинтереснее будет. Непризнание очевидных недостатков языка из-за необразованности или какого-то комплекса не делает Го рыцарям чести, скорее говорит об узком кругозоре, синдроме утенка. В конце концов, язык — это инструмент, и за свою карьеру вы можете сменить несколько из них. Чем больше языков вы будете использовать, пробовать, тем меньше эмоциональной привязянности и необходимости защищать у вас будет к конкретному из них. Поэтому призываю самообразовываться.

не портите себе желудок вкушая пхп — попробуйте лучше Ocaml, Scheme, Elixir :)

Хорошо, держите. IDE вам не понадобится. Следуете на dotnet.github.io/getting-started и качаете .NET Core под ту ось которая у вас стоит. Я делал это на винде.

1. Запускаете консоль на винде или баш на юникс;
2. Создаете папку для исходников;
3. Генерите исходные файлы командой dotnet new;
4. Подключаете необходимые пакеты командами dnu intstall Newtonsoft.Json, dnu intstall System.Net.Http, dnu intstall System.Dynamic.Runtime
5. После подключения пакетов выполняете команду dotnet restore;

6. В файл Program.cs вставляете код:

using System;
using System.Net.Http;
using System.Threading.Tasks;
using Newtonsoft.Json.Linq;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args) {
            GetLastSubbreddits("/r/java", 10).Wait();
        }

        public static async Task GetLastSubbreddits(string subReddit, int count) {
            var response = await new HttpClient().GetAsync($"http://www.reddit.com{subReddit}.json?sort=new&limit={count}");
            var rawString = await response.Content.ReadAsStringAsync();
            foreach (var post in JObject.Parse(rawString)["data"]["children"])
            {
                var title = post["data"]["title"];
                var created = DateTimeOffset.FromUnixTimeSeconds(Int64.Parse((string)post["data"]["created"])).DateTime;
                Console.WriteLine($"Title: {title}, Created: {created}");
            }
        }
    }
}

7. Возвращаетесь к консоли/башу и запускаете код командой dotnet run
8. Можете скачать замечательный кросплатформенный текстовый редактор Visual Code и поредактировать код с интелсенсом и подсказками.

Отлично, спасибо. Теперь можно сравнивать, хоть в вашем примере хотелось бы еще увидеть как происходит подключение сторонней библиотеки и обработка ошибок. В Go это так:
1. Идем на godoc.org и вбивает в поиск reddit. Находим самый популярный пакет (geddit).
2. Пишем go get github.com/jzelinskie/geddit — через секунду, библиотека готова к использованию.
3. Пишем код, не экономя строчек и с полноценной проверкой ошибок:

package main

import (
	"fmt"
	"<a href="http://github.com/jzelinskie/geddit" target="_blank">github.com/jzelinskie/geddit</a>"
	"time"
)

func main() {
	session := geddit.NewSession("")

	opts := geddit.ListingOptions{
		Time: geddit.ThisYear,
	}

	posts, err := session.SubredditSubmissions("golang", geddit.TopSubmissions, opts)
	if err != nil {
		fmt.Println("Failed to get posts:", err)
	}

	for _, post := range posts {
		date := time.Unix(int64(post.DateCreated), 0)
		fmt.Printf("%s: %s\n", date.Format("02 Jan 2006"), post.Title)
	}
}
4. go run main.go — запускаем, или go build — получаем бинарник, или GOOS=windows go build — кросс-компилируем в PE.

Стоит заметить, что этот пример я попросил, потому что как раз писал статью, где этот код написал за 3 минуты, практически не отвлекаясь на зависимости, обертки и абстракции, а от начала до конца почти каждая строчка несла полезную нагрузку.

Что у гоферов за тупая прывычка подбирать примеры под готовую либу, и показывать это как превосходство го.
На шарпе высше весь код тоже можно кудато в либу запихнуть, и программа будет в одну строчку.

С чего вы взяли, что это привычка? Мой вопрос с кодом изначально был с просьбой использовать либу, потому что это тоже интересный аспект в разных языках, который хотелось бы сравнивать.

А давайте предстваим что пришел заказчик и говорит, не хочу редит, хочу список из 10 последних тем на доу.
У программиста на шарпе высше переделать займет 15 мин времени. А сколько займет времени у вас ? Волшебной готовой либы то нет.

+ давайте это в базе хранить + орм и транзакционный слой в дао/сервисе

У программиста на шарпе высше переделать займет 15 мин времени.
А, да? Переделайте, пожалуйста, код выше за 15 мин так, чтобы он выбирал 10 последних тем на ДОУ.

Но, давайте представим, что есть у DOU API, вот вам аналог вышеприведенной программы, которая напрямую работает с Reddit API, без библиотек. Непонятно, зачем вы к этому придрались и пытаетесь увести в сторону дискуссию, впрочем. Тут изменить код займет секунд 20 времени.

package main

import (
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"time"
)

type RedditResponse struct {
	Data struct {
		Posts []Post `json:"children"`
	} `json:"data"`
}

type Post struct {
	Data struct {
		Time  float64 `json:"created"`
		Title string  `json:"title"`
	} `json:"data"`
}

func main() {
	resp, err := http.Get("<a href="http://www.reddit.com/r/golang.json?sort=new&limit=10" target="_blank">www.reddit.com/…ng.json?sort=new&limit=10</a>")
	if err != nil {
		log.Fatal("Failed to get posts:", err)
	}
	defer resp.Body.Close()

	var posts RedditResponse
	err = json.NewDecoder(resp.Body).Decode(&posts)
	if err != nil {
		log.Fatal("Failed to decode JSON:", err)
	}

	for _, post := range posts.Data.Posts {
		date := time.Unix(int64(post.Data.Time), 0)
		fmt.Printf("%s: %s\n", date.Format("02 Jan 2006"), post.Data.Title)
	}
}

И если я ответил на ваш вопрос («Сколько времени это займет у вас?»), мой вопрос — а сколько времени у вас займет сделать программу, которая запускает 1000 параллельных соединений, читает 10 последних постов, выбирает один с максимум лайков и кладет результаты в, скажем, SQL базу данных? С тестами и проверкой ошибок, чтобы уж было ближе к реальным сценариям. И чтобы работала и под MacOS X, и под Windows, и под Linux.

И чтобы работала и под MacOS X, и под Windows, и под Linux.
а кому это, простите, может быть нужно?
кроссплатформенность — это всегда в ущерб производительности
а кому это, простите, может быть нужно?
Действительно, кому может понадобиться писать софт на макбуке, а запускать его в докере. Нонсенс же.
Я понимаю, что если долго живешь ограниченный одной технологией, то отсутствующий функционал начинаешь считать не нужным, но, в самом деле, не настолько же изолироваться от реальности, люди!
кроссплатформенность — это всегда в ущерб производительности
Обоснуйте, пожалуйста, в чем ущерб производительности в кроссплатформенности в Go?
Действительно, кому может понадобиться писать софт на макбуке, а запускать его в докере.
Да ну:)
99.99% людей не сидят на переоцененных в 4 раза железках от погрызанного яблучка
И никогда не будут
Аргумент только для любителей сыров по 900
Я понимаю, что если долго живешь ограниченный одной технологией, то отсутствующий функционал начинаешь считать не нужным, но, в самом деле, не настолько же изолироваться от реальности, люди!
Видимо Ваша реальность сильно отличается от той в которой живет 90% разрабов
Или этот комент проплачен гуглем?:)
99.99% людей не сидят на переоцененных в 4 раза железках от погрызанного яблучка
И никогда не будут
Аргумент только для любителей сыров по 900

Причем для оставшихся 0.005% есть среды и компиляторы, которые отлично работают и на джаве и на хаскеле, и еще на 100500 языках, окромя, наверное дотнета, который всеже движеться в этом направлении, а остальные 0.005% юзают дев сервера, либо виртуалки и не паряться.
99.99% людей не сидят на переоцененных в 4 раза железках от погрызанного яблучка
И никогда не будут
Даже не утруждая себя разоблачать ваши странные представления об окружающем мире, представим, что ваши 99% сидят на православной Windows, и пишут софт для платформы, на которой держится добрая половина интернета — Linux. Тут тоже не нужна кроссплатформенность?
Не говоря уже о том, как легко вы выбрасываете и игнорируете целую индустрию разработки под ARM-устройства, на которых нативная компиляция зачастую недоступна вообще.

Впрочем, я уже имел возможность общаться с фанатами продуктов Microsoft и я прекрасно представляю в каком мире вы живете. Там, действительно, нет ни кроссплатформенности, ни других технологий, ни open-source — ничего, что выходит за рамки весьма своеобразного мира MS. Все что остается — убеждать себя в бесполезности кроссплатформенности и насмешливо отзываться о продуктах других компаний.
Весьма прискорбно.

Даже не утруждая себя разоблачать ваши странные представления об окружающем мире, представим, что ваши 99%
Видимо осмысленные аргументы закончились, раз пошло хамство
ваши 99% сидят на православной Windows, и пишут софт для платформы, на которой держится добрая половина интернета — Linux. Тут тоже не нужна кроссплатформенность?
Нормальный разраб будет писать для линуха на нем же , на фиг тут кроссплатформенность?
целую индустрию разработки под ARM-устройства, на которых нативная компиляция зачастую недоступна вообще.
Вы видимо не понимаете разницы между кросс-компилятором и кроссплатформенным софтом:)
Между прочим самые удобные среды такого рода как раз чисто виндовые
99.99% людей не сидят на переоцененных в 4 раза железках от погрызанного яблучка
И никогда не будут

вот тут я уже заржал в голос

товарищ, нельзя же так палиться

и настоятельный вам совет по поводу: СПИЛИТЕ МУШКУ

а то вам постоянно будет больно, некомфортно

Очередной упоротый аноним....
Это уже начинает надоедать

ага, да-да

то есть это «аноним» упоротый

а у кого «джуны будут на интервью манады педалить» — образец адекватности и здравого смысла

то есть это «аноним» упоротый
да, именно
а у кого «джуны будут на интервью манады педалить» — образец адекватности и здравого смысла
тот человек о котором Вы упомянули — адекватен (возможно несколько категоричен, но не более), в отличии от Вас.
и не похож на блюющего зомби без имени

«монада» и «адекватен»
ага
ок

я так и думал

а какие у вас проблемы с монадами? они же просты как 5 копеек

у меня с ними нет проблем

проблемы у тех, кто во все это вообще вступает

это совершенно лишняя, искусственная, ненужная за пределами контекста чистой функциональщины, концепция

которая в оной функциональщине — костыль, нужный исключительно для того, чтобы все эти нишевые инструменты обработки линейных списков — натянуть (как гондон на голову) на инженерию реального мира, где сущности имеют состояния, да еще и разворачивающиеся во времени

в мире JS Promise стало очень удобным подходом для управления асинхроностью, Promise по факту монада (принцип один и тот же), но ту гибкость которую он предоставляет иначе не получить, используется во всех серьезных приложениях на JS.

и это совсем не лишнее, это очень эффективный инструмент

Promise — костыль против callback hell’а. Причем не очень подходящий. Вместо того, чтобы пойти по пути Go и реализовать простые и понятные легковесные потоки, mainstream разработчики nodejs придумывают недокостыли в виде promise и async с await. Через пару лет придут к православным горутинам :)

Это не костыль против колбек хела. Вообще колбек хел решали давно и без него через флоу контроль (он иногда и с промисами нужен). Промисы помогают управлять асинхроными операциями, и в этом их фишка.
async await давно присутствует в языке намного более зрелым чем го — в С#, и нормально себя показывают

Да и вообще горутины с точки зрения джс тот же колбек (nextTick) только если в джс оно безопасно ввиду асинхроной модели, то в го нет, т.к. есть шаред мемори

Оно в джс «безопасно» не в виду асинхронной модели, а ввиду того, что джс не может в многопоточность.

При этом безопасность относительная, так как в JS точно та же shared memory и JS точно так же может выполнять параллельно несколько логических процесов, которые будут прерываться для ожидания IO, но при этом никаких продвинутых методов синхронизации там не предусмотрено, ни в базовой библиотеке ноды, ни в нормальных 3d party библиотеках.

Вообщето в джс асинхронность используется как альтерантива классической однопоточности.
В джс невозможно изменять один и тот же объект из двух потоков, т.к. нет объектов которые живут в обоих потоках.
Коммуникация между потоками при помощи сообщений.
Безопасность в том что ни один объект не может быть измененым в один момент времени.

Безопасность в том что ни один объект не может быть измененым в один момент времени.
Сегодня в завтрашний день
В джс невозможно изменять один и тот же объект из двух потоков, т.к. нет объектов которые живут в обоих потоках.
Я вроде бы и не писал про потоки.

Во взрослых языках программирования есть всего несколько атомарных операций, которые сводятся к атомарным инструкциям, поддерживаемыми CPU, все остальное неатомарно, так как может быть прервано шедулером. Следовательно, если нужна длинная атомарная операция — используй критические секции и прочие кошерные вещи, которые есть в библиотеке классов любого нормального языка программирования.

В JS все упрощено до детского уровня — все атомарно в рамках текущего тика. Джиэсбои радуются, но забывают, что любая IO операция или даже просто ожидание выполненого промиса завершит обработку текущего тика и запустит следующий, в итоге то, что выглядит атомарным, на самом деле таким уже не является.

Даже банальный и безобидный кусок кода с вашими любимыми генераторами и промисами является источником потенциальных багов, вызваных race condition

var value = 0;
var nextValue = Q.spawn(function*(){
    value = yield someService.getNextValue(value);
});

Здесь бы пригодились механизмы синхронизации, реализованные поверх nodejs event loop, но вот пичалька — никто не позаботился об их нормальной реализации, ибо зачем, в javascript же все безопасно, кококо. А вместо того, чтоб пилить свою реализацию с нуля (что не так просто как кажется), проще переписать весь код на Java или C#, где все эти проблемы давно решены.

Ясень пень что говорится о статичности в рамках тика, но если у вас есть объект который вы хотите изменять в рамках двух тиков, то это вы как разработчик написали глупость. И в джава (как и с#) эта проблема абсолютно не решается.

Допустим есть два потока который пишут и читают какойто шейред объект, вы столкнетесь с той же проблемой что и в джс, и синхронизация вам никак не поможет.

Ясень пень что говорится о статичности в рамках тика, но если у вас есть объект который вы хотите изменять в рамках двух тиков, то это вы как разработчик написали глупость. И в джава (как и с#) эта проблема абсолютно не решается.
Болезнь гоубоев передается воздушно-капельным путем. Теперь
и фанаты JS, как только видят, что кейс выходит за рамки того, что можно скопипастить из туториала, заявляют что кейс идиотский и не нужен.
Допустим есть два потока который пишут и читают какойто шейред объект, вы столкнетесь с той же проблемой что и в джс, и синхронизация вам никак не поможет.
Давайте вы пойдете почитаете про критические секции?
Давайте вы пойдете почитаете про критические секции?
я прекрасно знаю что это такое, только она вам в лучшем случае даст то что в джс реализовано асинхронной моделью, в худшем случае дед-лок.

мир джаваскрипт, и ваш пример. у нас есть 3 хендлера на обработку в очереди ивент лупа, и есть ссылка на объект доступная в каждом из хенддеров, и свойство у объекта который каждый тик меняет. первый тик, приравнивает свойство этого объекта единицы. второй тик (мы о нем скорее всего даже и не знали), присваивает этому свойству ноль. а третий тик ожидает что свойство содержит единицу — но вот облом, значение там другое.

давайте разберем. мир джавы. у нас есть два потока, и есть шаред мемори, доступ к которой вы реализовали при помощи synchronized. теперь два потока не могут изменять наш объект в один и тот же момент, что дает нам защиту от похеренной памяти. это отлично, но в джс это всегда есть, ввиду отсутствия как таковой шаред мемори. теперь применим пример из джс, на случай в джаве. допустим первый поток, изменяет в шейред мемори некое значение, приравнивая его 1, второй поток пытается тоже его изменить, но уходит в ожидание, из-за синхронизации, потом первый поток делает некий запрос к БД, и добавляет к единицы (как он думает), значение из БД, но вот только там уже ноль, ибо второй поток поменял значение. в итоге, пришли к тому с чего начинали. естественно можно сделать synchronized всю операцию, но тогда это не кисло может затормозить второй поток (и вы получите перфоменс ишью).

в целом проблему которую вы привели, является больше логической, и решается часто через использование иммутабельные данные, как в джс так и в джава, ибо это более адекватное решение.

критические секции в джава решают, то что в джс не существует как класс проблем, и это о том, о чем я сразу говорил

давайте разберем. мир джавы. у нас есть два потока, и есть шаред мемори, доступ к которой вы реализовали при помощи synchronized. теперь два потока не могут изменять наш объект в один и тот же момент, что дает нам защиту от похеренной памяти. это отлично, но в джс это всегда есть, ввиду отсутствия как таковой шаред мемори. теперь применим пример из джс, на случай в джаве. допустим первый поток, изменяет в шейред мемори некое значение, приравнивая его 1, второй поток пытается тоже его изменить, но уходит в ожидание, из-за синхронизации, потом первый поток делает некий запрос к БД, и добавляет к единицы (как он думает), значение из БД, но вот только там уже ноль, ибо второй поток поменял значение. в итоге, пришли к тому с чего начинали. естественно можно сделать synchronized всю операцию, но тогда это не кисло может затормозить второй поток (и вы получите перфоменс ишью).
ок, т.е. теперь у нас и потоки в js нашлись
можно сделать synchronized всю операцию
Код я выше привел, покажите как вы сделаете это synchronized
но тогда это не кисло может затормозить второй поток (и вы получите перфоменс ишью).
Правильно, зачем тормозить поток, когда можно просто разрешить потокам херить данные?
критические секции в джава решают, то что в джс не существует как класс проблем
решают то, что не существует как класс в голове джсеров
ок, т.е. теперь у нас и потоки в js нашлись
просто это реальный аналог той же проблемы но в джаве. проблема в том что есть некое состояние которое меняется непредсказуемым образом.
покажите как вы сделаете это synchronized
пожалуйста
final List collection = new ArrayList<String>();
        
        Thread thread1 = new Thread() {
            public void run() {
                synchronized(collection) {
                    collection.add("Test");
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) { }
                    System.out.println("Hello World " + collection.size());
                }
            }
        };
        
        Thread thread2 = new Thread() {
            public void run() {
                synchronized(collection) {
                    collection.add("Test 2");
                    System.out.println("Hello World " + collection.size());
                }
            }
        };
        
        thread1.start();
        thread2.start();
Правильно, зачем тормозить поток, когда можно просто разрешить потокам херить данные?
действительно лучше тормозить поток, чем решать реальные проблемы
решают то, что не существует как класс в голове джсеров
потому что в мире джс таких проблем и нема

Я спрашивал как вы это сделаете в javascript.
в жабе ясное дело что это делается одной строчкой кода.

потому что в мире джс таких проблем и нема
ну как нема, я выше привел пример кода с проблемой. или там проблемы тоже нема?
Я спрашивал как вы это сделаете в javascript.
в жабе ясное дело что это делается одной строчкой кода.
ааа... тогда я вам скажу следующие. так -
var value = 0;
var nextValue = Q.spawn(function*(){
    value = yield someService.getNextValue(value);
});
никто не пишет. по крайне мере я такого кода не видел в реальных проектах. некоторые порываются так писать, но их обычно на кодревью банят. в джс есть много особенностей которыми можно себе ногу прострелить, но это не значит что так надо писать. и да, в этом плане язык не предотвращает от подобных глупостей, все ап ту ю.

есть случаи когда замыкание полезно, но, в большинстве случаев оно вредно, как и в вашем примере

то что вы хотели написать, обычно пишут как —

someService.getNextValue(value).then(function (value) {
// do something
});

Я так и понял, что как только появляется более менее сложная задача, то «так не пишут».

Задача простая — есть глобальная переменная. По команде нужно передать ее значение во внешний серврис, получить новое значение и сохранить вместо предыдущего. Я понял, что в js это сделать невозможно, потому что в туториале по ноде не показали как это сделать

вы удивитесь, но в джс давно не юзают глобальные переменные.

вот адекватная реализация того что вы хотели сделать

var interface = (function () {
    var value = 0;

    return {
        get value () {
            return value;
        },
        getNextValue: function () {
            return someService.getNextValue(value).then(function (newValue) {
                return value = newValue;
            });
        }
    };
}();

В итоге
1) Вместо 1 уровня вложенности стало 4 уровня вложенности
2) На смену няшным yield-ам пришли пративные колбеки
3) Появился богомерзкий return value = newValue
4) Проблема, которой болел изначальный вариант, так и не решена

Печально, что даже Senior Javascript Developer-ы, каждый день пишущие код, работающий асинхронно, слабо понимают как он работает, какие проблемы его окружают и как их решать. Но при этом тыкают свою ноду куда попало, уступая пальму неадекватности только гоубоям.

1) Вместо 1 уровня вложенности стало 4 уровня вложенности
вообщето 3, плюс в случае окружения common.js или новой модульной системы, замыкающию функцию можно убрать.
2) На смену няшным yield-ам пришли пративные колбеки
с yield-ами есть проблема, если вы их используете, то у вас все должно через генераторы быть (к примеру лично я генераторы не очень люблю), а это не всегда просто сделать
3) Появился богомерзкий return value = newValue
ну в нем ничего страшного нету, зато полный контроль и оригинальный
getNextValue
можно будет потом использовать с async / await
4) Проблема, которой болел изначальный вариант, так и не решена
судя по всему я не до конца понял какая у вас была там проблема.

я там видел проблему того что value могло не предсказуемо изменится, и те кто так пишут обычно на эти грабли и наступают.

возможно вы имели ввиду тот кейс когда, вызов getNextValue для 2-х value перетрет предыдущие? если да то не заметил, как-то не сталкиваюсь с подобными проблемами, обычно чтото меняется, из хрен знает откуда. но тогда

var value = 0;
var valueRequests = {};

module.exports = {
        get value () {
            return value;
        },
        getNextValue: function () {
            if (!valueRequests[value]) {
                valueRequests[value] = someService.getNextValue(value).then(function (newValue) {
                    return value = newValue;
                });
                return valueRequests[value];
            }
        }
    };
Печально, что даже Senior Javascript Developer-ы, каждый день пишущие код, работающий асинхронно, слабо понимают как он работает, какие проблемы его окружают и как их решать.

я прекрасно знаю какие проблемы меня окружают, и ту которую вы привели ни одна из них

использование ArrayList-а в многопоточном коде? Окай...

вы бы сперва прочитали что я хотел показать, подумали, а потом комментировали

я о том что в джаве есть специальные инструменты, которые нужно использовать, а не писать код без этих инструментов, чтоб показать что в джаве будет та же проблема.

в том случае ArrayList можно было бы заменить любым сервисом

так о чем речь тогда? Вы приводите как минус платформы (то что будут перфоманс проблемы) желание дергать в многопоточной среде не потокобезопасный сервис.

я не привожу это как минус платформы, а объясняю то, что обойти JS проблемы в Java не получится не потеряв перфоменс.

Добрый день! пишу сюда не для спора, а для что бы узнать что то новое.
Processing model
По моему представлению в node.js есть пулл рабочих потоков для IO операций и один единственный поток для выполнения event loop назовем его main tread.
Event loop код имеет доступ к условному массиву содержащему указатели на ф-и «калбеки». Калбек добавленный раньше и будет выполнен в main tread раннее тех что были добавлены после него.
И даже если main tread выполняет не атомарный код меняющий состояние шаред объекта никто не сможет повредить данные т.к банально некому, т.к по факту нет других потоков, кроме main tread, ответственных за выполнение «упорядоченных» калбеков.
Мне кажется «критическая секция» как понятие вообще отсутствует в node.js потому что там нет паралельного выполнения.

Смотрите, single core CPU, без Hyperthreading. Запускаем 2 потока, которые используют одни и те же данные, в т.ч. и модифицируют. CPU физически неспособен в любой момент времени выполнить больше 1 потока. Используя вашу логику, можно предположить, что пока поток выполняется, состояние шаред объекта никто не сможет вопредить, т.к. банально некому?

А теперь представьте что в реальности происходит на одноядерном CPU. И скажите, в чем принципиальная разница между кодом на C#

Company.Address.City = service.GetCompanyCity();
Company.Address.ZipCode = service.GetCompanyZipCode();

и кодом на JS

Company.Address.City = yield service.GetCompanyCity();
Company.Address.ZipCode = yield service.GetCompanyZipCode();

И затронут ли проблемы, существующие в многопотомном C#, код, который написан на однопоточном JS.

в итоге, пришли к тому с чего начинали. естественно можно сделать synchronized всю операцию, но тогда это не кисло может затормозить второй поток (и вы получите перфоменс ишью).
неблокирующие синхронизации, CAS-алгоритмы и тп ? Не, не слышал
неблокирующие синхронизации
с этим вы получите те же проблемы что и в джс с его асинхронной моделью, а тут человек от них пытается полностью изолироваться

нет, не получу. Для того эти инструменты и есть в джаве, чтоб и перфоманс ишью не было и синхронизация была.

Теперь и фанаты JS, как только видят, что кейс выходит за рамки того, что можно скопипастить из туториала, заявляют что кейс идиотский и не нужен.

Я правильно понимаю, что для JS следует считать, что мы имеем кооперативную многозадачность? Или тут что-то уже поменялось?

Можно сказать, что кооперативная многозадачность, с единственным исключением — процес отдает процессорное время не тогда, когда он хочет, а каждый раз, когда ему нужно выполнить любую IO операцию или даже просто получит значение уже зарезолвеного промиса, даже если ему очень не хочется отдавать управление.

Даже банальный и безобидный кусок кода с вашими любимыми генераторами и промисами является источником потенциальных багов, вызваных race condition
var value = 0;
var nextValue = Q.spawn(function*(){
value = yield someService.getNextValue(value);
});

Артем, можешь дать рабочий пример кода, который можно скормить ноде и увидеть проблему явно относящуюся к «параллелизму выполнения js кода», который использует зашаренное состояние в памяти, без всех этих невнятных вопросов с подводными камнями о том как один или два ядра процессоров будут считать биты?

пока из всего описанного вижу только, что ты подменяешь понятия побочных эффектов использования замыкания и критических секций в многопоточных языках.

Вот пример, который иллюстрирует проблему:

var Q = require("q");

var service = {
    add: function(a, b){
        return Q(a+b);
    }    
};

var counter = 0;
var increment = Q.async(function*(){
    counter = yield service.add(counter, 1);
});    

Q.all([
    increment(),
    increment(),
    increment(),
    increment()
]).then(function(){
    console.log(counter);
});

По понятным причинам результат выполнения будет не таким, как ожидается.

В сишарпе это решается обычным локом.
Вот моя попытка решить проблему, правда я не уверен, что код корректно обработает синхронные исключения и как-то лень копать глубже

var counter = 0;
var sync = Q();
var increment = function(){
    var result = sync
        .then(function(){
            return service.add(counter, 1)
                .then(function(newCounter){
                    counter = newCounter;
                });
        });
    
    sync = result.then(function(){}, function(){});
    
    return result;
};

Ааа, так у вас проблема в неправильном использовании.

Кто же знал, что вы хотите это не правильно использовать. Нельзя асинхронные операции использовать как синхронные и надеятся что все будет гуд.
Тогда сам вызов и фиксить нечего.

итог — некоторые джавабои не далеко ушли от гоубоев

У тебя неправильно используеться замыкание.
В ивент лупе весь код, который помещаеться в следующий тик(Q(...)) будет выполнен после секции событий. На момент вызова всех твоих инкрементов состояние замыкания

service.add(counter, 1);
будет 0 во всех вызовах функций — синхронная часть кода.
Убераем замыкание и решаем твою проблему. Как подтверждение, что в js все детерминировано передаем внешнее сообщение, которые выводиться в callback’e после резолва промиса. Как начали так и закончили
var Q = require("q");

var service = {
    increment : 0,
    add: function(b){
        return Q(this.increment += b);
    }
};


var increment = Q.async(function*(message){
    yield service.add(1);
    console.log(message);
});

Q.all([
    increment('i was added first'),
    increment('i was added second'),
    increment('i was added third'),
    increment('i was added fourth')
]).then(function(){
    console.log(service.increment);
});
все это никак не относиться к тому что кто-то внезапно может поменять состояние обьекта, тем более использование монитора ни к чему в js — он просто бесполезен.

У меня был няшный stateless сервис, который складывал два числа, вы его переделали в statefull, и он теперь делает что-то совсем другое, остальные кастомеры этого сервиса сломались. не надо так.

там ломаться нечему, сервис как был локальным так и остался. Состояние на том же уровне локальной переменной и осталось, только к другому обьекту прицеплено. Тем более, что это не пример реальной продакшин проблемы или задачи.

если человек знает что такое event loop, он не будет наступать на эти грабли. Вопрос только в знании языка и всего сахара, который в нем есть. Тут не надо лепить какие-то костыли для синхронизации, тем более лепить асинхронный вызов там где он не нужен. Надо просто понимать, что ты пишешь и получишь ожидаемый результат.

Разумеется там нечему ломаться, так как это тестовый пример, но я удивлен, что вы не решили проблему еще более радикально, написав

var i = 0;
i++;
i++;
i++;
i++;
console.log(i)

Я делал пример, который можно скопипастить и запустить у себя на компьютере, как вы и просили. Поэтому так случилось, что код сервиса находится рядом с кодом клиента, в том же скоупе, и его можно хакнуть, добавить внутреннее состояние, поменять интерфейс и т.п.

В реальности этот код может, например, вызывать внешний сервис по HTTP, которым могут пользоваться и другие клиенты. И никто не будет менять логику и API сервиса из-за того что кто-то не знает как разрулить racing condition в клиенте.

Можно остановиться на том, что все участники здесь уже признали:

В небезопасном однопоточном джаваскрипте есть те же проблемы, которые есть в хардкорных взрослых языках с настоящей многопоточностью, а именно:
1. Логически параллельные процессы
2. Racing conditions
3. Общая память, которую можно похерить

Эти проблемы проявляются реже ввиду того, что нода работает на одном потоке, и проблемы возникают только в тех местах, где логически атомарная операция должна прерываться (например для чтения результата из промиса или IO). Но ситуация усугубляется тем, что понимания этих проблем у армии кодеров гораздо меньше, учитывая повторяющиеся мантры о том что 1 поток, значит все безопасно, а так же тем, что никаких нормальных средств для синхронизации не запилено.

Показательно, что все, кто понял, в чем проблема в примере, пытаются поменять пример, чтоб избавиться от неатомарной операции, вместо того чтоб показать как упорядочить параллельные асинхронные процесы.

Я не спорю, что нужно избегать использования глобальных объектов, за которые идет конкуренция.
В том же дотнете, например, можно пять леть просидеть за ASP.NET, разрабатывая приложения, которые природно многопоточны, ни разу не столкнувшись с упомянутыми проблемами, связанными с многопоточностью.
Но при этом MS не сказала, что все, кто хочет модифицировать общую память — дураки и делают что-то не так, а запилила целую библиотеку для синхронизации с поддержкой в синтаксисе языка. Аналогично в джаве.

Мне правда интересно увидеть хоть один пример, когда код в event loop выполниться непредсказуемым образом из-за указаных причин

1. Логически параллельные процессы
2. Racing conditions
3. Общая память, которую можно похерить
и не будет связан с неправильным ожидаемым окончания предудщей задачи.

Так же интересно к какому из пунктов относиться пример выше?

Я сделал вывод, что там у вас не получилось закинуть замыкание правильно в коллбек, на следующем тике.

Я привел пример, на котором воспроизводится проблема, если не запилить дополнительный код для синхронизации параллельных логических процессов (что сделал я).

Я сделал вывод, что там у вас не получилось закинуть замыкание правильно в коллбек, на следующем тике.
Замыкание здесь не при чем, оно использовалось чтоб расшарить один объект между разными процессами, как глобальную переменную. Если в коде асинхронную операцию с промисом заменить синхронной, все будет прекрасно работать и с замыканием.

В твоем примере это чисто проблема неправильного использования замыкания.

Если в коде асинхронную операцию с промисом заменить синхронной, все будет прекрасно работать и с замыканием.

потому что у тебя порядок выполнения совсем другой. Синхронно такой

counter = 0
counter = 0 + 1
counter = 1 + 1
counter = 2 + 1
а асинхронно такой:
counter = 0
Q(0 + 1) 
Q(0 + 1)
Q(0 + 1)
counter = 1
counter = 1
counter = 1
посмотри внимательно, все присвоение ты вынес после yield — то есть он выполниться на следующем тике.

сделай counter нормальным замыканием в простой accessor и вызови его после резолва промиса, у тебя заработает все:

var Q = require("q");

var service = {
    add: function(a, b){
    return Q(function(){return a()+b});
}
};

var counter = 0;
var increment = Q.async(function*(){
    counter = (yield service.add(function(){return counter}, 1))();
});

Q.all([
    increment(),
    increment(),
    increment(),
    increment()
]).then(function(){
    console.log(counter);
});

ты можешь это так же решить нормальным построение цепочки ожидания(там надо было делать рекурсию).

Короче что так что так соль одна — js код выполняет не так как ты ожидаешь и те побочные эффекты тут не причем. Хотя бы потому что как бы я его не переделал у меня он работает каждый раз так, как ты того хочешь.

В моем сервисе есть метод, который принимает 2 числа, и возвращает промис, в котором лежит их сумма.

Попробуйте решить задачу, не нарушая этот контракт.

Тут решать не чего к сожалению. Это не контракт, а ошибка. Промис ваш всегда вернет Q(1) потому что Q() к получает аргументом уже готовую сумму и просто резолвит ее каждый раз на следующем тике.

В js замыкания тут нету
a = 1;
Q(a + 1)
а вот это замыкание, которое нужно тут юзать и пробрасывать его на следующий тик:
a = 1;
Q(function(){a + 1}).then(function(callback) {callback();})

тут разбираться надо чем отличаеться
Q(a + b)
от
Q(func(a+b))
и какая между ними разница.

В контракте нет никакой ошибки

Это стандартрная практика — метод принимает значения, с которыми он может работать напрямую, не предпринимая никаких дополнительных усилий для того, чтоб предварительно зарезолвить эти значения.

То, что клиентский код не умеет правильно себя синхронизировать и ломается — это проблема клиента, а не проблема сервиса, и она решается исправлением клиента, а не исправлением сервиса.

так же исправляеться и на клиенте.

var Q = require("q");

var service = {
    add: function(a, b){
        return Q(a+b);
    }
};

var counter = 0;
var increment = Q.async(function*(){
    counter = yield service.add(counter, 1);
});


((function run(calls){
    return  calls.length ? calls.shift()().then(function(){
       return run(calls);
    }) : Q(undefined);
})([
    increment,
    increment,
    increment,
    increment])).then(function(){
    console.log(counter);
});

Если не нравиться код — в ES 7 это решено async\await. На клиенте это уже работает благодаря babel со всеми плюшками отладкой и т.д.
Можно ли дебажить ноду через транспайлер не уверен, но гонять через babel точно можно.

До появления Babel в продакшине проблемы, о которых ты говоришь джуны встречают от непонимания js, но достаточно не часто. Приблизительно так же как со значимыми и ссылочными типами.

возвращает промис
А не профит ?

требования странные. никто не читает 10 последних постов из 1000 паралельных соединений. И кросплатформенность некому не нужна.

никто не читает 10 последних постов из 1000 паралельных соединений.
Да, concurrent-программы вообще никому не нужны, хахаха.
И кросплатформенность некому не нужна.
Что ж вы сразу не сказали. А я тут время трачу на общение с теми, кто живет в мире одной платформы.

Сел в лужу с заявлениями «код на го в 10 раз короче», теперь плавно пытается спрыгнуть на тему что код на го пишется быстрее.

Покажите, пожалуйста, где вы нашли заявление «код на го в 10 раз короче». Если не найдете, объясните, зачем придумываете. Зато у вас появился повод пересмотреть свое непонимание, как код на Го может быть короче, ведь, по вашим предыдущим убеждениям, в Го в основном приходится велосипедить и копипастить. Найдите велосипеды и копипасты.

Покажите, пожалуйста, где вы нашли заявление «код на го в 10 раз короче».

У напарника твоего:

Aliaksandr Valialkin 31 грудня 2015 9:30
Скорее всего, для реализации данной функциональности на гоу нужно в 10 раз меньше кода и коммитов, чем на скале.

Найдите велосипеды и копипасты.

Ну напиши функцию (используя виртуальный API доу, как у меня), которая возвращает заголовки 10 первых статей ДОУ отсортированных по времени (старые вначале), написанных в период с 02.01.2016 по 05.01.2016.

Ну вот вот, код уже не столь лаконичный и понятный.
И количество чистых строчек больше чем в примере сишарпа.
Что и требовалось доказать

В примере C#-па нет обработки ошибок и налеплено куча методов в одну строчку, что делает код менее читабельным.

девочки не сорьтесь я на джс в 7 строк напишу с хендлингом ошибок

5 минут, с такой же безобразной обработкой ошибок:

using System;
using System.Net.Http;
using System.Threading.Tasks;
using Newtonsoft.Json;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args) 
        {
            GetLastDOUPosts(10).Wait();
        }

        public static async Task PrintLastDOUPostsAsync(int count) 
        {
        	try 
        	{
        		var json = await new WebClient().DownloadStringTaskAsync("http://dou.ua/api");
				var response = await JsonConvert.DeserializeObjectAsync<DOUResponse>(json);

				foreach (var post in response.Posts.Take(count))
				{
					Console.WriteLine("{0} {1}", post.Date.ToString("dd MMM YYYY"), post.Title);
				}
        	}
        	catch (IOException ex)
        	{
        		Console.WriteLine("Failed to get posts: " + ex);
        	}            
        	catch (JsonSerializerException ex)
        	{
        		Console.WriteLine("Failed to decode JSON: " + ex);
        	}
        }
    }

    class DOUResponse
    {
    	public IEnumerable<DOUPost> Posts { get; set; }
    }

    class DOUPost
    {
    	public string Name { get; set; }
    	public DateTime Date { get; set; }
    }
}

Хоть убейте не вижу где код го короче

dou.ua/api возвращает 404, ваш код не работает. Но он показательно многословен.

Не более чем гошный, форматирование тут страдает. Вербальность чуть выше, но это ничто по сравнению с велосипедами которые приходиться писать на го.

Перечислите, пожалуйста, велосипеды, которые вы увидели.

ну как по мне тоже что и в шарпе

автори ні, сліпі гугло/го фанатики — так

Можете привести пример конкретной задачи, или куска кода на жава/шарпе, который на го выйдет короче?

github.com/.../fileserver/fileserver.go — http-сервер для статики. 33 строчки кода на гоу. Фичи сервера:

* Может слушать на любом порту.
* Может сервать файлы из любого каталога.
* Поддерживает If-Modified-Since запросы.
* Поддерживает прозрачное сжатие ответов.
* Генерирует индексные страницы для директорий.
* Скорость работы сравнима с nginx. На маленьких файлах, а также при включенном прозрачном сжатии ответов быстрее nginx.

Жду похожего кода на жаве/скале/сишарп.

Только где там 33 строчки ?
Я вижу целую кучу файлов и строчек в github.com/valyala/fasthttp

Это код сторонней библиотеки, который не принято учитывать при подсчете количества строчек в программе. Вы же не учитываете строчки кода из сторонних библиотек при оценке сложности программы на скала или жава.

Напишите аналог этой программы на жава или скала с использованием сторонних библиотек, чтобы он уложился в 32 строки.

Это не просто «стороння библиотека», а это ваш собственный сервак написанный под конкретные нужды.

Можете ли вы заэкстендить функционал, чтобы, например, по пути /plus/2/3
Вам возвращалась сумма чисел, не меняя при этом код «сторонней библиотеки» ?

Можете ли вы заэкстендить функционал, чтобы, например, по пути /plus/2/3
Вам возвращалась сумма чисел, не меняя при этом код «сторонней библиотеки» ?

Конечно — см. gist.github.com/...yala/02156e6a35a35c8724dd . 58 строчек кода.

Вот тебе аналогичный «плюс» сервак на ужасной джаве: gist.github.com/...mous/4240bdf7b5e80e07da45
Бум играть в игру «найди 10 отличий» ?

1. Не вижу файловый сервер.
2. Не вижу возможности задать порт, корневую директорию, индекс и сжатие через параметры командной строки.
3. Сервер на жаве тормозной.
4. Невооруженным глазом видно, что код на гоу проще кода на жаве.

1. Не вижу файловый сервер.

Это потому что сервер стандартный, а не подключенный самописный.
3. Сервер на жаве тормозной.
Я тут особо спорить не буду, так как не в курсе, но вы бы чтоле какието пруфлинки дали, чтоле.
4. Невооруженным глазом видно, что код на гоу проще кода на жаве.
Невооруженным глазом видно что код на джаве проще чем на гоу. Fail.
3. Сервер на жаве тормозной.
Это Вы, извините, из кода увидели? Расскажите как вот тут поподробнее, а то я 10 лет на 10 пишу сервер код и вот не вижу тормознутости.

Полистал исходники сервака. Что не говори, вполне норм, совсем не стыдно в репозитории такой иметь, даже наоборот, по крайней мере для go-шника. Велосипед на велосипеде правда, что ожидаемо от go, но все-равно чел постарался, уйму времени убил. Но, на шарпе такой сервачек вышел бы в разы короче.

Но, на шарпе такой сервачек вышел бы в разы короче.

И где этот мифический сервачок на сишарпе с аналогичной производительностью и функциональностью, да еще и с меньшим количеством кода?

Вы ещё не написали код, который я попросил привести для сравнения verbosity языков выше. Не увиливайте пожалуйста.

Делать мне нечего на праздники код тебе писать. Я же тебя не заставляю писать. Я тебе написал каков объем будет. Хочешь верь, хочешь нет, я в своей правоте уверен, мне нечего доказывать.

Это же 6 строчек, судя по комментарию выше. Очень жаль, что вы испугались такого простого задания. Очень интересно было бы сравнить на практике код. Это было бы показательно и менее голословно чем эти сотни предвзятых комментариев тут.

Пока окончательно не слился, советую менять стратегию с «го крут, потому что язык крут, позволящий быстро педалить минималистический понятный код» на «го крут, потому что под него напедалили библиотечек на все случаи жизни». Хотя зная сколько таких библиотечек напедалили под .net и java, я бы и эту стратегию тоже не сильно рекомендовал бы.

Ну все, убедили, раз уж у вас можно написать мейн метод в 33 строки который будет дергать либу и поднимать http сервер, то это имхо на порядок лучше чем эта наша скала.

тогда нода должны быть в разы круче, там сервер разворачивается на раз

Тщерт, только мануал по Го начал читать...

читайте мануал по ноде она круче Го =)

Конечно. А еще каждый js разработчик овладевает темной стороной силы

Там где-то вверху ноджс разработчики только на четвертый день смогли написать аналог простейшего кода, повсеместно использующегося в серверных приложениях. И аналог получился несколько сложнее для понимания из-за callback’ов. Вот такая темная сторона силы.

ну я не спорил с тем что читабельность у синхронного кода выше. но если много с этим работаешь то проблем не возникает.

10К вместе со статьей www.kegel.com/c10k.html — это говно мамонта начала 2000-х годов.

В 2015 году сервер на гоу держит 1000К параллельных подключений в продакшн, а не на синтетических тестах. Для такой нагрузки потребовалось бы 100 серваков с нодой вместо одного с гоу.

Всегда было интересно, как люди пишущие про 1м паралельных подключений игнорируют лимит в 65к открытых файлов... и еще интересно, что это за запросы такие?

Всегда было интересно, как люди пишущие про 1м паралельных подключений игнорируют лимит в 65к открытых файлов...

Всегда было интересно, откуда взялся лимит в 65к открытых файлов.

У нас на сервере он такой:

# ulimit -n
3040000
и еще интересно, что это за запросы такие?

Подключения != запросы. По подключениям могут передаваться запросы. У нас это разные события от клиентов по keepalive подключениям. Подробности тут — github.com/...valyala/fasthttp/issues/4 .

65к это лимит на некоторых линухах.
Ну у вас я так понял пиковая нагрузка меньше, и тогда ваш 1м больше держит операционка, чем сервак.
Какая была максимальная пиковая нагрузка? И какой был латенси?

Давайте пример программы на скала с аналогичной функциональностью, ипсользуя сторонние либы.

Мне жаль что вы искренне не понимаете сарказм и то что если вы заюзали либу то это уже не 33 строки кода. Я в подобных соревнованиях не учавствую, с такими предложениями вам бы на хабр.

У меня на хабре нет аккаунта. Дайте инвайт!

static private public interface inherits const override volatile synchronized — это еще ягодки по сравнению с любовью java-программистов загромождать код десятками бесполезных абстракций над абстракциями и ненужными паттернами проектирования по типу «я тоже знаю, что такое абстрактная фабрика синглтонов!».

static private public interface inherits const override volatile synchronized
Это МОДИФИКАТОРЫ, если они Вам противны, то Вы можете их не использовать.
class User {
    String name;
    int age;
}
это кошерный код на Java. Не хотите — не используйте.
.
И судя по всему, Вы не умеете программировать на Java, так как:
const — нет такого ключевого слова (оно зарезервировано, но не используется).
override — это необязательная аннотация, которая помогает отыскивать ошибки смешения overloading и overriding.

Мне противны абстрактные фабрики синглтонов, а не модификаторы

Противны — не используйте.
Я не понимаю саму суть претензий.
.
Про фабрики: множество API в Java-экосистеме являются фабриками. Именно так реализована возможность заменять функционал (JDBC — работа с разными базами, XML-парсинг, ...). Если Вам не надо заменять реализации, то используйте одну конкретную библиотеку напрямую.

Из разряда «Оружие убивает».

Если программисты лепят ненужные в конкретной ситуации абстракции и паттерны, причем тут язык?

Если программисты лепят ненужные в конкретной ситуации абстракции и паттерны, причем тут язык?

хз, но факт остается фактом — java-программисты больше всего любят лепить ненужные абстракции с паттернами. Подозреваю, что в этом виноват дизайн языка, стандартная библиотека и книжки, по которым программисты изучают java. Все они переполненны ненужным over-engineering’ом и complexity.

На java тоже можно писать простой лаконичный код. Но такой код почти не пишут из-за вышеуказанных первопричин.

Кстати, java-программисты продолжают писать код в стиле java на других языках программирования. И это печально.

Вы не поверите, но оружие таки убивает. Говорить «люди убивают, а не оружие» и игнорировать тот факт, что оружие — это специально придуманный инструмент для облегчения убийства людей всё равно что говорить «говнокод пишут люди, а язык, который помогает, а не мешает писать говнокод тут не причем».

Нож тоже убивает. Давайте откажемся от ножей. Вилка тоже убивает. Давайте откажемся от вилок. Бритва убивает. Давайте откажемся от бритв. Самолеты убивают (все помнят 11 сентября), давайте откажемся от самолетов. И этот список я могу продолжать очень долго....

Да, вот об этом я и говорю. Невозможность увидеть как различный дизайн языков стимулирует разные практики примерно то же самое, что и невозможность людей увидеть, чем отличается «инструмент для поедания еды» от «инструмента для убийства людей». И то, и другое приводит к достаточно печальным последствиям.

Печально то, что некоторые тут пытаются доказать что вилкой можно убивать так же эффективно, как и оружием, при этом они не считают вилку опасным инструментом. Никакой логики, слепая убежденность.

Это вы Go назвали вилкой, Scala — ружьем, а программирование — убийством? Никакой логики, слепая убежденность.

Ну вы же не станете отрицать что жава, скала, шарп это более высокоуровневые языки по-сравнению с го?

Они более усложненные и обладают большим количеством фич, но по «уровневности» они более чем в одной лиге. Просто в Go абстракции реализуются иначе, чем в вышеупомянутых языках.

Вообще, круто было бы, если бы вы ознакомились с предметом спора, прежде чем тратить время на яростные споры.

Это вы у том го, который позицинируется как более простой и няшный С, на котором смогут все писать?

Вообще, круто было бы, если бы вы ознакомились с предметом спора, прежде чем тратить время на яростные споры.

В отличии от вас, я знаю шарп, немного скалу, на выходных изучил го. Вы же, ничего кроме го (который учиться за выходные) в глаза не видели.

Вы же, ничего кроме го (который учиться за выходные) в глаза не видели.
С чего вы это взяли, кроме как, опять же, придумали сами? Узнать синтаксис языка и написать реальный большой проект, чтобы оценить использование языка в больших проектах — разные вещи, так что не утешайте себя напрасно.

Scala однозначно выше по уровню, чем Java/C#. Как минимум есть следующие языковые механизмы, практически не эмулируемые:

  • Dependent types
  • Generics of higher kind
  • Macroses
.
Хотя, может, в C# есть макросы?
Хотя, может, в C# есть макросы?
нету, и пока не предвидится
но они там не слишком-то и нужны

они и в скале для 99% задач не нужны. Но если хочеться прострелить себе ногу, выколоть глаз соседу, и подорвать кафетерий, то могут пригодиться.

Ружжо це ж інструмент для вигравання медалей на стрілецьких змаганнях в тій же мірі як ніж це інструмент для поїдання їжі. Також «невозможность» -> «неспособность».

Да, но есть множество случаев когда оружие может спасти вам жизнь. Так же как и хорошо иметь машину с мощным двигателем — вы можете ездить сколь угодно аккуратно но запас мощности позволит вам уйти от столкновения в нужный момент. Почему я должен отказываться от этих преимуществ из-за маргинальных или пьяных людей убивающих себя и других людей?

Вы начитались страшилок об паттернах, абстракциях, слоях, но так и не уловили суть критики. А суть критики не в том, что это все плохо и надо забыть как об страшном сне, а в том, что люди используют это все где ни попадя, то есть занимаются over-engineering-ом. Так что если в небольшом приложении, микросервисах без этих практик проектирования и можно обойтись, то в случае с системой по-больше, без этого будет туго.

Я понимаю, что вы пытаетесь доказать, но не согласен с тем, что вы называете это «критикой». Это предвзятое мнение, основанное на незнании технологии и убежденности в превосходстве другой, знакомой вам технологии. Почему вы, вместо того, чтобы действительно разобраться в предмете, и лишь потом судить о его применимости в больших проектах, изо всех сил стараетесь себя и остальных убедить в том, что ваше предвзятое мнение справедливо — мне непонятно.

Критику очень интересно слушать от тех, кто может сравнивать и оценивать. а не от тех, кто навязывает свое предвзятое мнение, не имея ни опыта, ни желания его получить.

По-моему это очевидно что более выскоуровневые языки позволяют решать более глобальные и объемные задачи. Именно поэтому они пишутся на жаве и шарпе, а не на с/с++/го.

Понятно, у вас фанатизм. Код писать вы боитесь, предмет спора не знаете, но твердите одну мысль «джава/шарп — единственное решение для больших(глобальных,объемных) задач, все остальное — мусор». Фанатики, сэр.

Я где-то говорил что нельзя писать большие проекты на с/с++/го? Все можно, но это будет в разы сложнее и дольше, чем на на шарпе/жаве. Если критическая производительность — тогда да, выбора нет, пилят на с++. Но вот у го пока с этим проблемы — как только начинают писать что-то сложнее раздавалки файлов, производительность проседает до уровня жавы.

Все можно, но это будет в разы сложнее и дольше, чем на на шарпе/жаве.
Обоснуйте, пожалуйста. С чего вы настолько в этом уверены, что игнорируете аргументы тех, кто на самом деле пишет на Go, и тратите сотни комментариев, чтобы навязать свое мнение и оскорбить несогласных с вами. Код вы так и не удосужились привести в пример, кстати.

Вань, не парся, это бессмысленно. Это хабрасик.

Именно поэтому они пишутся на жаве и шарпе, а не на с/с++/го.

Они пишутся на Python.

prom.ua написан на python. Много кода с очень сложной бизнес-логикой. Все чотко и по понятиям. Новые фичи добавляются очень быстро. Рефакторинг кода также проходит быстро и в основном безболезненно. По крайней мере так было полтора года назад, когда я там работал.

Если бы prom.ua решили написать на жаве или шарпе, то пришлось бы нанимать в десять раз больше программистов, чтобы успевать развиваться с аналогичной скоростью. Я участвовал в разработке проекта схожей сложности на сишарп, поэтому знаю, о чем говорю.

так высокоуровневый, прикладной(скриптовый) же язык Питон, на Руби или ПХП тоже была бы быстрее разработка такого веб сайта, чем на С #..
Но это не совсем ентерпрайз приложение..
Как их можно сравнивать? Причем тут С\С++\Го?

Смотришь гитхаб Aliaksandr Valialkin:
«Хм, может человек не так уж и плох...»

Читаешь очередной коммент на доу:
«...а нет, показалось»

Вам ещё не надоело попускать людей, не согласных с вашим предвзятым некомпетентным взглядом на Go? От вашего гитхаба, кстати, ощущения такие же, как и от ваших комментариев.

Что Scala не взлетит, я пришел к выводу в году 2009ом. отхоливарил по разным ЖЖшкам с ее адептами, неинтересно уже повторяться.

по факту, за эти годы, споры о преимуществах Scala напоминают ежегодную победу Linux на десктопах. «А вот в следующем то году, точно капец винде и яблокооси!»

Ну и с тем же эффектом когда кто-то что-то нехорошее написал о Scala — - «а-а-а, это у вас руки кривые! мозги у вас не работают! а работали б». ... перешли бы на Haskell, уверенно скажет профи(т.е. пишущий код за деньги) хаскелист.

эту статью на хабре перевели недавно. комменты там — автор дурень, как и вся его компания, и программисты в ней — тупни!

ежегодную победу Linux на десктопах
Коли лінукс переможе він буде мати тіж проблеми що і віндовс і почне скочуватися.

Не почне. Справа у тому, що у випадку лінукса завжди є вибір — якщо не хочеться «повністю віндової» системи (як роблять, наприклад, з типової Ubuntu), то можна поміняти декілька компонент або перейти на споріднений дистрибутив і продовжити майже в тих же умовах, але зручніше для себе. З Windows такого нема, або підтримується дуже погано і тільки сторонніми виробниками, сама MS дає тільки один варіант кожного принципового компонента.
Для адміна це може бути гіршим (навіть проблема вибора, якої взагалі нема з MS або вибір вже зроблений за нього), для розумного користувача — значно краще.

Linux никогда не победит на десктопах, т.к. скоро рынок десктопов схлопнется. Останутся только айпады с айфонами, на которых линукс давно победил в виде ведроида.

т.к. скоро рынок десктопов схлопнется.

Нет, не схлопнется. Ниша «рабочая станция» и ниша «десктоп продвинутее, чем можно обеспечить на мобильном устройстве» будут живы, хоть и сократятся, потому что в первой есть необходимость сама по себе, а вторая выигрывает за счёт в 2-3 раза более дешёвых решений на ту же производительность (и даже за счёт того фактора, что системный блок сложнее унести, чем лаптоп и тем более планшетник). Они могут ещё в 2-3 раза от текущего сократиться, или видоизмениться в сторону комплекта «носимый отрываемый терминал плюс стационарная часть, к которой его можно цеплять» (развитие нынешних док-станций на системы хранения данных, второй монитор и т.п.), но не уйдут в ноль.

А программировать ты на чем будешь, на айфоне?

Что Scala не взлетит, я пришел к выводу в году 2009ом.

Если под «взлетит» подразумевается «вытеснит джаву», то таки да.
Но, в отличи от 2009, она свою нишу заняла, работа есть, и, по моим субъективным очучениям, чувствует она себя получше чем все остальные распиареные фп языки.

Но, в отличи от 2009, она свою нишу заняла, работа есть,
а сколько работы было на взлетевшем Дельфи....

а нишу да, заняла. Тогда же я ее назвал — планета Java нуждалась в своем Haskell — вот он, в виде Scala и появился. И — там и останется. в нише.

Вот почему Groovy не занял ниши Ruby-Python на планете Java... не скажу, не знаю. по моим прогнозам ниша больше, чем распространенность Groovy. вобщем много писать.

А со Скалой у меня вопросов нет — и ниша та, и публика в ней, в нише та же что и в Haskell (если не хуже) — меньшинство реальные профи, большинство — адепты возомнившие себя равными этому меньшинству, но так на деле они не равны, то большинство это компенсирует этот комплекс неполноценности фырканием снобов на форумах.
Встречал даже мнение что это не они виноваты, а понаехавшие на планету Java за более высокими зарплатами хаскелисты, не смогшие попасть в то меньшинство реальных профи на планете ФП. Может быть и так.

а сколько работы было на взлетевшем Дельфи...
Имхо, проблема Дельфи в маркетинге, точнее в его отсуствии. Сан агресивно пихали джаву куда могли, майкросовт пихал дотнет еще агресивней, в то время как борланд втыкал. Впрочем тема для совершенно иного холивора...
Вот почему Groovy не занял ниши Ruby-Python на планете Java... не скажу, не знаю. по моим прогнозам ниша больше, чем распространенность Groovy. вобщем много писать.
Это для меня тоже загадка.
А со Скалой у меня вопросов нет — и ниша та, и публика в ней, в нише та же что и в Haskell
В том то и суть, что не везде. Есть некое обособленное меньшенство функциональщиков, которые делают себе скалаз. Есть большенство, которые используют «обычную» скалу в ее нише — биг дате.
Вот почему Groovy не занял ниши Ruby-Python на планете Java... не скажу, не знаю.
так Jython и JRuby же уже были вроде в этой нише)

И кто на них пишет?

Для JVM чего только нет.

Groovy же задуман для комфорта программистов на джава, и с учетом специфики экосистемы, а не для рубистов и питонистов желающих запустить свой прект на JVM

И кто на них пишет?
не знаю кто пишет, но релизы по крайней мере jRuby как смотрю выходят стабильно. Последний был 19 дней назад (судя по офф. репозиторию на гитхабе). Да и Jython вроде как живой — на репозитории гитхаба github.com/jythontools/jython последний коммит 10 дней тому назад был.
Для JVM чего только нет.
что да, то да)

Вот тоже можно сказать и про .NET — для него тоже много всякого понаписали)

Groovy же задуман для комфорта программистов на джава, и с учетом специфики экосистемы, а не для рубистов и питонистов желающих запустить свой прект на JVM
так наверное он эту функцию и выполняет — дополнительного инструмента для джавистов (может разве что за исключением тех случаев где он идет как основной язык для веба в рамках Grails)...

А линукс еще не победил? Посмотрите хотя бы на Android. Это линукс с надстройкой. Посмотрите на Windows 8 и далее — это уже копирование интерфейса Android. Windows уже не нападает а защищается.

Посмотрите хотя бы на Android.
вы тогда сразу давайте — UNIX победил, чтобы МакОСь приплюсовать.
Это линукс с надстройкой.
надо же, какое откровение.
А я, как только прозвучало это слово — Андроид, наванговал что победит потому что Java как основной ЯП для приложений потому что часть операционки — это бомба!

вы считаете что это Андроид — это победа линукса? а мне все же и сейчас думается что пофик какое там ядро. Джава — и как следствие — взрывной рост приложений — вот причина успеха.

Посмотрите на Windows 8 и далее — это уже копирование интерфейса Android.
меня учили что интерфейс, UI — это НЕ часть операционки :)

а то что интерфейсы под пальцевый ввод, и просто из-за изменений в моде дизайна — меняются, не говорит о том что это победа ядра, на который они натягиваются.

Windows уже не нападает а защищается.
это да. сложно нападать когда ты и так фактически монопилист :)
на десктопах.

Доо, конечно монополист. Windows8 — 10% десктопов, а Windows 10 — 5%. Итого 15%

угу, а остальные 85% поделены между линуксом и макосью. причем у линукса бОльшая часть, потому что он бесплатный. да!

На устройствах с тачскрином, например мобильные телефоны, доля Windows 3,6% и сокращается. Конечно виндовс монополист.

милок, прибегание к подмене тезиса показывает либо демагога, либо не очень умного человека.

там было написано:

споры о преимуществах Scala напоминают ежегодную победу Linux на десктопах.

НА ДЕСКТОПАХ, слышь, а?
какого ты приплетаешь смарты, о которых я — ничего не говорил?
упоротый линуксоид что ли?

Что считать десктопами? Системный блок с монитором?

Что считать десктопами?
а ты ввязался в разговор не зная что такое десктопы?
молодец!

Куда уж на про десктопы знать :)

Если вы сидите за допотопным гробом, то это не значит что все вокруг тоже за ним сидят. «Видишь слона? А он есть».

да я так и понял, что все сидят на смартах, планшетах, или Raspberry PI — а это только я последний из могикан.
да, я вас понял. пора мне думать о «сплаве по Днепру»

десктопы это полноценный рабочие станции, обычно подразумевается что основной контролер не тач

Это понятно. Десктопы сейчас живут только благодаря инерции индустрии игр. И то самые лучшие игры выпускают уже на игровых станциях.

Ну да, конечно, все пользователи САПРов с радостью начнут возюкать пальцами по 32 дюймовым экранам
И верстальщики тоже
И разрабы начнут писать код на виртуальной клавиатуре
Вобщем можно долго примеры приводить полной несостоятельности Вашему посылу☺

Ну удачи вам с САПРами. Ведущие компании делают макеты, делают стереосъемку, моделируют — не трогая мышку или клавиатуру руками. Ну вы же самые «умные».

Стереосъемку _чего_? Того что еще не существует?;)
И какие это прасцице «ведущие компании»? Пруф в студию плз

Смотря чего проектируют, того и съемку. Макет дома из картона, съемка, моделирование. Машину из пластилина в масштабе. Сварка на заводе Тесла проводится один раз сварщиком, а программа сама повторяет его движения распределяя качество шва.

Ну что-ж, теперь понятно что в этой области Вы, простите, профан, насмотревшийся рекламных роликов Маска
Что-то более реальное предъявить можете?
Зы. И конечно все научные расчеты уже проводятся сугубо на сенсорных экранах:)

А зачем? У меня же все нереальное и выдуманное основанное на роликах. Сидите со своими САПРами, кроме них ничего нет а кругом одни дураки, один вы Дартаньян на белом рояле.

Fat troll detected:)
А если серьезно, то нет САПРов — нет варенья
Планшет на котором Вы видимо щас сидите(и я кстати тоже), спроектирован как раз с помощью классических десктопных приложений. И так будет еще ооочень долго:)

Не важно на чем вы сидите. Важно соотношение количества устройств. У меня сейчас в комнате 2 ноута, 1 нетбук, 1 планшет, 3 смартфона. Десктопа ни одного. Винда только на 2-х ноутах и то на этих же ноутах стоит VirtualBox, с несколькими ОС (Ubunu, Rasbean, RH). Смартфоны и планшет на Android (подключившись через кабель к смартфону, через отладчик, легко убедиться что там линукс). Скажите мне, почему я должен считать Windows и десктопы лидерами чего-либо?

Ну и Raspberry PI 2 B+, но вы же его не считаете :)

Не съезжайте с темы
То о чем Вы пишете говорит только о том что у Вас нет необходимо стиль в больших диагоналях и серьезной производительности
По поводу ОС я вообще ничего не говорил, но теперь скажу с учетом каментов ниже:
Это говорит о том что реально Вам не нужно профессиональная специализированное ПО, поэтому Вы юзается линукс
И да, kicad не катит — это даже не детский сад

Ну как бы скроллинг десктопа никто не отменял. На виндовс это почти не возможно. А большие экраны терпеть не могу. Надо поворачивать голову, а это утомляет и замедляет. Ну пусть будет kicad — детский сад. А у вас что?

На виндовс это почти не возможно
Не смешите
А большие экраны терпеть не могу. Надо поворачивать голову, а это утомляет и замедляет
Большой монитор надо просто поставить на правильную дистанцию, если зрение позволяет конечно
А у вас что?
Solidworks
Практически универсален
На линухе вряд-ли появится вообще

Вот как только Solidworks станет необходимым каждому, так я и скажу что без Windows никак :)

Большой монитор можно поставить на дальнюю дистанцию. Только ваши глаза не смогут на таком расстоянии получить необходимую детализацию :)

Не стоит передергивать
Речь шла о десктопе, и исключительно о профессиональных применениях
Вам конечно солид ни разу не нужен, как и большинству юзеров, но если его не будет, как и автокада, то свои любимые новые гаджеты, машины и все прочее вы увидите очень нескоро

Большой монитор можно поставить на дальнюю дистанцию. Только ваши глаза не смогут на таком расстоянии получить необходимую детализацию :)
Найдите себе нормального окулиста и подберите очки
Мне они пока не нужны, и кстати большой монитор нужен не столько из-за детализации, сколько для того чтобы видеть сложные сопряжения в многотельных сборках
Или для вынесения срезов.... вобщем много для чего
Дальнейший спор будет непродуктивен, ибо рациональные аргументы Вы не воспринимаете, подменяя их фразами «а вот я...»

На ноутах у меня есть kicad. Как сапр подойдет? Есть бесплатная программа рисования чертежей...

А также есть Gimp, OpenOffice ... у меня в квартире победил Linux уже давно.

а он не считается конечно :) Ведь автор решил доказать победу линукса. для этого надо правильно считать, и прибавлять к десктопным ОСям Andoid.
и Победа — очевидна!

хотя я бы, для надежности, добавил и серверные установки линукс. сервера это ж тоже в некотором роде десктопы. ведь в браузере — UI, а раз он туда приходит с сервера, то он часть операционки сервера

и прибавлять к десктопным ОСям Andoid
ну вообще-то есть порт андроида для x86 наксколько мне известно www.android-x86.org . Правда хз, кто юзает андроид в качестве десктопной оси)

я встречал мнение (от Зубинского) что Андроид со временем вполне может прийти и на десктопы. надо конечно нормальную оконную систему туда будет добавить, и т.д.

вполне может быть. не завтра, но — вполне. только — я не считаю Андроид клоном Linux как и OSx — клоном BSD. Как и Windows NT — клоном OpenVMS.

А то так можно и x86 процессоры считать RISC процессорами, потому что там внутри давно суперскалярное RISC ядро

А интел не производит RISC, только x86?

не производит.
они продали свое подразделение лет с 5, или 7 тому.
как понимаю — из понимания что в случае успеха — столкнутся с антимонопольными разбирательствами, и все равно придется продать.
У меня до сих пор живой Покет на ВинМо на интелевском АРМе

контролеры да. они у всех либо на ARM либо на MIPS

CISC пережиток прошлого, когда оперативной памяти было мало и за счет сложных инструкций можно было сократить объем программ. Но это приводит к тому, что внутренняя частота процессора должна быть значительно выше, чтобы обеспечить адекватный объем обмена данных с памятью. RISC работают на той же частоте, что и память, а значит энергоэффективность гораздо выше. Именно поэтому интел проиграл ARM на мобильных устройствах с автономным питанием.

CISC пережиток прошлого
подите Интелу расскажите.
RISC работают на той же частоте, что и память, а значит энергоэффективность гораздо выше.
то-то сервера массово на ARMах.
Именно поэтому интел проиграл ARM на мобильных устройствах с автономным питанием.
если будет решена проблема с емкостью акумуляторов — да, Интел вообще разорится. аха.

Wed Nov 02 2011,

да, и всем известно, сервера HP сплошь на АРМах. :D

российская компания Рикор демонстрирует блейд-сервер

о, ну если российская компания то это да, это все. капец мировому рынку серверов!
Кстати, о процессорах, а вы в курсе что российский процессор «Байкал» обрушил процессорный рынок? армы и интелы рыдают, «Россия — вперде!»

Через 5 лет после США. Был бы он так плох, почему они его не сделали на Intel? Все вокруг дураки по вашему?

ну почему все. известно что есть одна все же страна с очень умными, супердуховными и прочим — Россия.
а вот остальные да, дурачье.

слушайте, а вы и правда совершеннолетний? а то я как-то начинаю подозревать что напрасно вам отвечаю.

Вот как можно быть настолько упоротым, чтобы давать ссылку за 2011 год? Дай новую сылку, где все давно решено.

P.S. Calxeda Inc. в 2013 раззорилась как раз после того, как не смогла доказать эффективность АРМ для HP в серверах, после чего их HP послал. Опытные образцы с треском провалились. Кроме нового геморроя они ничего не смогли дать.

Считается десктопом Raspberry PI ? Под него даже виндовс бесплатный вроде есть. Только на нем клоны линукса.

да, согласен. Raspberry PI добил наконец десктопы.
Все, победа за вами!

Ну если вы когда нибудь его купите, то там можно посмотреть карту с активными устройствами. Карта Киева вас очень удивит :)

Вижу у вас мозг так и прет из всех щелей :)

Зашел на ДОУ раз в году, как говна наелся (((

Я вроде никого дураком не обзывал, только в ответ на оскорбления.

И как, помогло? Sergiy Skyninko перевоспитан и больше не будет?

Ну я слегка пошутил. Виноват :) А будет он еще или нет — не мои проблемы.

RISC работают на той же частоте, что и память, а значит энергоэффективность гораздо выше.

У DDR3-1600, например, на переключение между строками требуется 35 нс, что соответствует частоте около 28 МГц. Вы хотите сказать, что все RISC процессоры работают на такой частоте? :)

За ВСЕ я не писал. Не знаю почему вы решили что выборка каждый раз новой строки это единственный способ работы памяти. В частности у ARM есть принцип конвейера. Это когда выполнение команды выполняется в 3 этапа. Выборка, декодирование, выполнение. 3 конвейера автоматически смещаются, когда один выполняет, второй автоматически выбирает следующую. Таким образом реальная частота умножается на 3... и более.

За ВСЕ я не писал. Не знаю почему вы решили что выборка каждый раз новой строки это единственный способ работы памяти.

Я это не решал, ваша догадка неверна. Но или в принципе понятие «та же частота, что и память» некорректно, и его надо принципиально уточнять; или же надо принципиально учитывать самый медленный случай. Выбирайте.

В частности у ARM есть принцип конвейера. Это когда выполнение команды выполняется в 3 этапа. Выборка, декодирование, выполнение. 3 конвейера автоматически смещаются, когда один выполняет, второй автоматически выбирает следующую. Таким образом реальная частота умножается на 3... и более.

Спасибо за объяснение известных азов, хотя и в откровенно сомнительном виде. Главное тут то, что они в современной обстановке с учётом всех проблем, таких, как медленная основная память, слои кэшей, отдельные длительные операции (как общеизвестно мучительно долгое деление чисел) — всю эту «схему» из 3-х этапов превращает практически в ничто. А самое существенное, что ровно такие же проблемы на границе 60-х и 70-х годов привели к результату, полностью противоположному современному — началось засилье CISC. Для примера: алгоритм Tomasulo — ядро современных подходов к out-of-order исполнению — придуман в 1969 и тут же внедрён в поздние линии IBM/360. В 1970 релизится PDP-11 — самый CISC из всех CISC тогда. Это вам о чём-то говорит?

ARM, кстати, из всех условно-RISC архитектур самый не RISCовый. MIPS, Alpha, Sparc значительно ближе к идеалу этой архитектуры. И да, писать на них местами неуютно (одно извращение в виде delay slots чего стоит).

CISC пережиток прошлого, когда оперативной памяти было мало и за счет сложных инструкций можно было сократить объем программ. Но это приводит к тому, что внутренняя частота процессора должна быть значительно выше, чтобы обеспечить адекватный объем обмена данных с памятью.

Вы не замечаете прямые несоответствия в этой логике? Если команды короче, надо меньше выбирать их из памяти. Но каким образом из этого следует необходимость повышения частоты? Частота процессора вообще-то зависит от технологии электроники (считаем, лучшее, что доступно не в лабораториях) и от параметров вроде максимальной длины линейных цепочек вентилей в логике — а эта длина не зависит собственно от CISC/RISC. Потому CISC без конвейера будет заведомо выигрывать в экономности у RISC без конвейера, который не будет иметь других преимуществ. CISC с простым конвейером типа описанного Вами (как в 8086) будет выигрывать перед аналогичным RISC. И так далее, пока не начнутся собственно проблемы затрат, вызванных сложным кодированием и множественностью действий в командах CISC.

Самый адекватный, по-моему, ответ о причинах засилья CISC в 60-80-х — это крайняя слабость компиляторов тех годов вместе с происходящей из неё необходимостью массовой ручной оптимизации на ассемблере. Это подтверждается тем, что только со внедрения «постклассических» компиляторных технологий, начиная с SSA, CSE, copy propagation и т.п., начался выход RISC из той ниши, где они были в 80-х и первой половине 90-х — спецмашины для особых применений. До этого компиляторы были не в состоянии делать под RISC код, хоть как-то сравнимый по эффективности с написанным человеком. Причём первыми эту задачу догнали специализированные коммерческие компиляторы, дорогие, кривые и глючные; и только после 2000-го она была реализована в открытых (GCC и последующие).
Компиляторы предшествовавшего периода были тупы до ужаса — например, в них последовательно выдерживался метод «всё, что не объявлено как register, держим на стеке и только временно берём оттуда в регистры». И то, стек это уже существенное продвижение по сравнению с областью данных для данной функции в оперативной памяти рядом с ней, как в Фортране-IV.

Сейчас же (возвращаясь к Android) мы имеем, при одинаково развитых технологиях работы с памятью, проблему CISC в мобильных устройствах именно в сложности команд. С прямым исполнением CISC вообще бы его не осилили; с перекодировкой в RISC эта сама перекодировка весьма дорога. Картину ухудшает неровность архитектуры x86. Если Intel это осилит, построив Atom’ы сходной производительности при том же энергопотреблении — будет интересно. Пока я таких успехов не вижу.

Команды короче (смотря какие разумеется, 32-64 бита уже не настолько и короткие команды), но дело в том, что от 80% и более (не говоря уже о жестких дисках) в программе занимает пересылка данных в регистры процессора и обратно. А вот вычисления и обработка все остальное. Так что команды короче (ну допустим), но их обработка бесконечно малая величина по сравнению с передачей данных.

Команды короче (смотря какие разумеется, 32-64 бита уже не настолько и короткие команды),

У кого именно короче? Я не понял идеи.

Я сравнивал объём одних и тех же программ в вариантах под x86-64 и AArch64. Во втором случае прирост объёма на единицы процентов, например:


-rwxrwxr-x 1 netch netch 204584 гру 27 22:59 prog
-rwxrwxr-x 1 netch netch 212880 гру 27 22:58 prog_a64

Опции и компилятор (gcc 4.8) одни и те же, меняется только таргет, в обоих случаях размер после strip.

но дело в том, что от 80% и более (не говоря уже о жестких дисках) в программе занимает пересылка данных в регистры процессора и обратно

То есть ожидание медленной памяти? Тогда тем более — по этой логике нет серьёзных преимуществ у RISC.

Преимуществ на мой взгляд несколько. Ну там расход в ваттах на команду опустим как и все прочее, многократно описанное. ARM ближе всех к вычислениям типа CUDA имхо. Наконец то исчезнет разница между GPU и CPU. Сейчас уже смарты есть с 8-ю ядрами. Как только количество ядер приблизится к GPU Intel окончательно перестанет существовать.

В том смысле что у CISC дистигнут предел тепловыделения. А RISC могут поднять частоту на 2 канала графика/цпу. Кристалл все равно холодный.

Бред, такая платформа, как Renesas R-CarH2 выделяет огромное количество тепла, четыре ядра по 1.5GHz. Быстрее АРМов я не видел.

А современный Интел процессор — это тогда что? GPU, контроллер памяти, PCIE контроллер и ещё много чего на одном кристалле. Ну или покажи мне хоть один массовый современный RISC процессор не в форме SoC.

Для того чтобы сравнить тепловыделение SoC и CPU вам надо перенести на CPU все мосты + добавить много чего еще. А потом сравнивать.

Бред в стиле 80х, сейчас «чистые» процессоры можно найти разве что в музее.

У вас да, чистый бред, соглашусь.

Ну то есть на чистый процессор в вакууме я ссылочки так и не получу? Жаль.

А я где то ссылочку такую обещал? Я вам черными буквами написал, что SoC и CPU это разные вещи. Как по длинне проводов (а значит паразитной емкости) так и по сопротивлению. И чтобы поддерживать такую систему нагрузочная способность микросхемы совершенно разная. Отсюда разное тепловыделение. Ну почему я должен объяснять элементарные вещи.

Ну почему я должен объяснять элементарные вещи.
Потому что CPU уже лет 10 как не существует.
Ну там расход в ваттах на команду опустим как и все прочее, многократно описанное.

Я бы сказал, что оно единственное.

ARM ближе всех к вычислениям типа CUDA имхо.

Простите, это каким именно образом? Как сам по себе ARM (а не встроенное ядро какого-нибудь GPU) окажется в состоянии выполнить, например, в 1024 шейдерных ядрах (или как они там будут зваться у конкретного вендора) загрузку из памяти, вычислительные операции, обмен данными с соседями и выгрузку результатов? Причём все одновременно из общего потока команд?

Наконец то исчезнет разница между GPU и CPU.

Она никогда не исчезнет. Как не пригоден процессор общего назначения для SIMD в тысячи потоков, так и не пригодно GPU для управляющих операций. GPU это такой продвинутый АЛУ с минимумом управления.

Как только количество ядер приблизится к GPU Intel окончательно перестанет существовать.

«Как только количество ядер приблизится к GPU», на том же количестве транзисторов можно будет сделать новые GPU в тысячи раз производительнее, которые куда-то обязательно применят. Делать же десятки тысяч ядер общего назначения это сейчас нереальная фантастика — им просто не найдётся работы.

Intel не «перестанет существовать», а почему — посмотрите хотя бы на Larrabee. Задачу выжать максимум одноядерной производительности при отсутствии существенных ограничений на мощность ARM проваливает с таким же громким треском, с каким x86 проваливает скорость при ограничении в 1 Вт.

Как только количество ядер приблизится к GPU Intel окончательно перестанет существовать.
С какого бодуна?
Как только количество ядер приблизится к GPU
Ну вот в 2005 у меня в GeForce FX5600 было 4 пиксельных конвейера. Интелу уже пора перестать?

А FX5600 умеет обращаться к биосу системной платы, читать данные с диска без CPU?

Может не совсем понятно объяснил. Помните MMX команды? Вот как только к обычным ядрам добавят части от GPU появится нечто совмещающее в себе CPU и GPU. Универсальное логическое ядро. Тогда программа будет решать, использовать всю мощность объединенного процессора для вычислений или оставить какую-то часть графике. Уйдет необходимость в шине PCI-E... Память от видеокарты станет доступна обычным процессам...

Может не совсем понятно объяснил. Помните MMX команды? Вот как только к обычным ядрам добавят части от GPU появится нечто совмещающее в себе CPU и GPU. Универсальное логическое ядро.
Мальчик, ты для начала разберись как оно всё работает буквально, а не на пальцах и в общем. Тогда 90% глупостей ты писать тут не будешь.
Уйдет необходимость в шине PCI-E...
С какого бодуна?
Память от видеокарты станет доступна обычным процессам...
Сделайте мне развидеть это, я больше не могу читать эту херню.

Кстати про длину команд. У ARM 2 варианта. Есть THUMB, они 16 бит. Так что команды у них явно короче.

1. Вы заметили, что я сравнивал именно x86-64 и AArch64, а не x86-32 и ARM32, или наперекрёст по разрядности? А для AArch64 все эти Thumb отменены.
2. Thumb короче, да. Но и эффективность укладки действий в команду там сильно ниже. Реально Thumb имеет смысл только на задачах класса управления, где годится, например, нормально работать с 8 регистрами вместо 16 обычного набора ARM32 (и 31 — AArch64). Как только идёт обработка данных, математика, etc. — его выключают.

Там ничего не выключают. THUMB или ARM32 различаются только одним битом. Допустимо смешивание для достижения оптимальных результатов.

THUMB или ARM32 различаются только одним битом.

Ну-тко, подробнее, пожалуйста. Почему-то документация говорит немного иное.

Это такой новый интересный вид спорта — приводить наобум ссылку с общими словами, имеющими лишь отдалённую связь с обсуждаемым вопросом? Или это «-atpcs /interwork» теперь называется «один бит»?

Все жевать надо.

Знаете, Вы сами нарвались на стандартный флеймовый ответ — «Иногда лучше жевать, чем говорить». В данном случае — чем врать вначале про «один бит», а затем приводить ссылки, которые ни слова не говорят про этот самый бит.

Да, похоже неадекватных тут пруд пруди. Тут один уже требовал определять способ работы с памятью. Теперь вы. Там черным по белому написано, зависит от реализации. Будем лезьть в Cortexы или еще куда?

Там черным по белому написано, зависит от реализации. Будем лезьть в Cortexы или еще куда?

Да, пожалуйста. Покажите на примере какой угодно версии, но так, чтобы Ваши слова «отличаются одним битом» получили хоть какой-то реальный смысл. Или же признайтесь, что ляпнули хоть что-то, лишь бы показаться компетентным. Лучше так, чем если то же самое будет доказано другими.
(И к слову, если «один бит» это бит режима в каком-то управляющем регистре, то это никак не будет ответом по сути.)

Да, похоже неадекватных тут пруд пруди.

Я думаю, у Вас в квартире найдётся хоть одно зеркало? Пользуйтесь им чаще при поиске некомпетентных.

Допустимо смешивание для достижения оптимальных результатов.
Ты хоть раз это делал, что несёшь подобную ахинею?

По поводу частоты памяти. Мне странно слышать про ваши 28 МГц. Даже DDR были 400 МГц. В 2-х канальном варианте все 800 МГц. Кэш Intel работает блоками а не строками.

По поводу частоты памяти. Мне странно слышать про ваши 28 МГц.

Я на это могу только повторить свои предыдущие слова: или в принципе понятие «та же частота, что и память» некорректно, и его надо принципиально уточнять; или же надо принципиально учитывать самый медленный случай. Выбирайте.

28 МГц было обратной величиной именно к самому дорогому случаю — это если бы строка менялась на каждый байт.

Кэш Intel работает блоками а не строками.

«Кэш Intel» работает строками (в его терминах) по 64 байта начиная с Pentium 4, а то и раньше. Но если из его строки используется малая часть, то эти 64 байта расходуются впустую. Фактически у нас только для кода можно более-менее гарантировать рациональное использование кэша, а работу с памятью элементарно «убить» неэффективным шаблоном.

Если вы хотите тут конструктивной дискуссии, сначала всё-таки определитесь, какие именно время/скорость из параметров памяти вы считаете тут согласующимися со скоростью процессора, а потом — в чём тут отличие RISC от CISC (а без этого отличия — неинтересно).

Думаю будущее нас рассудит. Объединится GPU с CPU или нет — посмотрим. А бессмысленный спор и доказательства того что будет оставим промышленности. Она все докажет за меня и за вас :)

Объединится GPU с CPU или нет — посмотрим.
Тут и смотреть нечего, такие проекты как Intel Larrabee, Intel MIC не взлетают уже лет 10.

При таких термодинамических нагрузках они сразу на тот свет улетают. Я же уже писал об этом.

Ссылочку плиз, из того, что я видел своими глазами, ничего там не улетало, а вполне себе работало, вот только цена там непотребительская.

Кэш Intel работает блоками а не строками.
Боже сколько нового и неправильного. См. что такое cacheline.

И что смотреть? Блоки по 64 байта?

Ну так это не я написал, что память 28Мгц построчное обращение. Я как раз и писал, что блоками обмен идет. Вы как с луны свалились, честное слово.

В упор не вижу блоков ни там, ни там.

Ну тут даже не знаю что вам посоветовать. Нажмите Ctrl+F. Потом введите 28 или 35. Потом F3. Это называется поиск. По моему это уже полный идиотизм с вашей стороны.

Ссылку про организацию кеша блоками у Интела, плиз. Тогда продолжим разговор.

С кешами ты слил, поздравляю.

В частности у ARM есть принцип конвейера. Это когда выполнение команды выполняется в 3 этапа. ... Таким образом реальная частота умножается на 3... и более.

o.O

Поинтересуйтесь на досуге, как расшифровывается MIPS.
Конвеер есть у все современных «быстрых» процессоров.

CISC пережиток прошлого
Как и RISC, сейчас вообще мало кто делит их, ну кроме тех, кому из университетской программы это запомнилось.
RISC работают на той же частоте, что и память, а значит энергоэффективность гораздо выше.
Пример, плиз. Я знаю как раз только обратные примеры.
Именно поэтому интел проиграл ARM на мобильных устройствах с автономным питанием.
Походу — это только у тебя в голове.

А почему сюда не добавить музыкальные центры, смарт телевизоры? Там по вашему windows?

да, точно. и их добавим!

это тоже десктопы!

Отсутствие тачскрина похоронит десктопы.

угу. мониторов с тачскрином не существует же, и невозможно их сделать.
капут значит десктопам, да, ваша правда

Скорее их похоронить работающий интерфейс мозг-компании
Лет так через 90-150

вы считаете что это Андроид — это победа линукса?

Да, потому что только в такой открытой системе могло получиться внедрение каждым конкретным производителем его драйверов и адаптаций под конкретную модель, и обмен лучшим опытом по адаптации под специфику телефонов/планшетов (специфические шедулеры, управление питанием, и т.д.)
Без открытого ядра и открытой реализации самой ОС межвендорный обмен не состоялся бы.

Джава — и как следствие — взрывной рост приложений — вот причина успеха.

Это вторая необходимая составляющая, но не достаточная.

меня учили что интерфейс, UI — это НЕ часть операционки :)

Увы, на некотором уровне это так. Простейший пример — не дело каждого конкретного приложения разбираться, как объединяются и универсализуются потоки событий от мыши и графического планшета. Где-то это вынесено на userland, как в драйверах X-сервера, но всё равно он очень плотно связан с ОС — настолько, что обычно в десктопных ОС считается неотъемлемой частью.

это да. сложно нападать когда ты и так фактически монопилист :)
на десктопах.

Тогда зачем они вводили Metro на десктопах, пока хоровой вой не заставил хотя бы дать возможность обходиться без него? Когда «монополист» ведёт себя, как будто защищается от обвальной потери рынка — надо предполагать, что в нём кто-то решил, что эта потеря таки состоится, если не принять меры.

Без открытого ядра и открытой реализации самой ОС межвендорный обмен не состоялся бы.
Линукс, как линукс, а вот GPL — это кость в горле у многих полупроводиковых вендоров. Посмотрим выстрелит ли Blackberry Priv, но он даже просто как пример, пол года разработки и линукс не нужен для андроида вообще.
а вот GPL — это кость в горле у многих полупроводиковых вендоров.

А чем оно им так серьёзно мешает? Всегда можно порождать проприетарные драйвера, а общая база, которую все понемногу лечат, эффективнее (доказано примером busybox).

А чем оно им так серьёзно мешает?
Сейчас уже более-менее подстроились, если брать видео, то драйвер из-за ядра бьют на две части, одну GPL, вторую проприетарную в виде либы, которая через GPL драйвер памит регистры и работает напрямую, но любая синхронизация между различными процессами будет стоить времени доступа через ядро. Многие производители делают квази-аппаратные мьютексы и прочие объекты синхронизации и субконтексты из-за этого, чтобы обойти вызовы ядра стороной и позволить параллельный доступ к железу со стороны многих процессов. В общем подходов много, но везде есть своя цена, связанная с производительностью. Т.е. аппаратная реализация исходит из софтовых ограничений, что не есть хорошо.
а общая база, которую все понемногу лечат, эффективнее (доказано примером busybox).
А в андроиде её практически нет этой общей базы :)

Для тех, кому не нравится/сложно scalaz, есть cats (non.github.io/cats//index.html) ;)

К стати похоже что у Go совершенно упоротое комунити
впечатление сложилось по нескольким подкастам и по общению с гоферами тут в теме ага

Упоротые наркоманы — это разработчики на node.js. А мы — нормальные адекваты. Лучше зацените доклад нашего предводителя — www.youtube.com/watch?v=PAAkCSZUG1c . Это вам не псих, орущий со сцены какой-то бред www.youtube.com/watch?v=e-p35Z3Z7DI , которому поклоняются адепты ООП, не знающие значения этой аббривеатуры.

шановний, ти мабуть зовсім втратив зв’язок з реальністю

Где именно я потерял связь с реальностью?

Упоротые наркоманы — это разработчики на node.js.

мне кажеться, что это скорее это те, которые признают за кошерный только свой язык (джава, сишарп, да и любой другой собственно), а остальные языки считают какими-то недоязыками.

К стати похоже что у Go совершенно упоротое комунити
впечатление сложилось по нескольким подкастам и по общению с гоферами тут в теме ага
Я, даже не заглядывая в профиль, догадался какое коммьюнити вы представляете. Виден опыт в попускании всех и вся. :) Не бойтесь, такое только в вашем коммьюнити, никто корону не заберёт.
У нас все дружно-чинно — к новичкам доброжелательные, агрессивных неадекватов отправляем подальше (возможно, ваше впечатление тут как-то связано), на другие языки не набрасываем за ненадобностью.

А можно было просто не использовать scalaz, ведь широко известно что это вредоносная и ухудшающая кодовую базу библиотека

она как минимум спорная и притащить ее в проект партизански — очень не хороший номер
я бы сильно срался ибо такие вещи требуют что бы все в них разбирались все кто пишет код

да там и без ScalaZ вычислений на типах хватает с головой, чтобы писать кодгольфинг. Чуваки заигрались в ковбой-кодинг, натащили всякого в проект и закономерно огребли. Я думаю что при должном прилежании афтар статьи через время напишет как они там с Го отстрелили себе голову и перешли на жабу 1.4 без генериков, ибо ну уж совсем просто.

Я думаю что при должном прилежании афтар статьи через время напишет как они там с Го отстрелили себе голову и перешли на жабу 1.4 без генериков, ибо ну уж совсем просто.

Зачем переходить на жабу, если в гоу и так нет генериков? И не только генериков, но и конструкторов, деструкторов, перегрузки методов, наследования, эксепшнов, геттеров с сеттерами, абстрактных фабрик с билдерами, дебаггера, IDE, паттерн матчинга и, как ошибочно полагают некоторые посетители этого топика, ООП.

Вот на вопрос «зачем» нужно обратиться к первоисточнику, заменить вон то все Scala на Go и чучуть поправить исходники. Проблема у афтара не с языком, а с управлением проектом, тут хоть гоу, хоть джаву, хоть кресты или дотнет — кина не будет. Ему никто не пояснил, что недостаточно собрать 200 человек программистов и выдать им молоток — а что надо еще какой-нибудь минимальный процесс настроить — ну там кодревью хотя бы.

Если код будут ревьювить такие же упоротые функциональщики, то это не избавит от проблем, описанных в статье. Ведь 99% программистов не отличит говнокод от совершенного кода, написанного в функциональном стиле. Scalaz тому яркий пример.

«Упоротых функциональщики» в определенных кейсах могут давать бенефиты. Но менеджмент должен понимать какие риски с этим связанны, и стоит ли с этим связываться.

А можно было просто не использовать scalaz, ведь широко известно что это вредоносная и ухудшающая кодовую базу библиотека

Правильнее было бы написать вот так:

А можно было просто не использовать scala, ведь широко известно что это вредоносный и ухудшающий кодовую базу язык программирования наряду со всеми функциональными и мультипарадигменными языками программирования типа C++, Clojure, lisp, Haskell, nemerle, F# и прочим матаном с моноидами, паттерн матчингом и т.п. бредом
nemerle
не ожидал, что его кто-то вспомнит) думал, что о нем не так много людей знает, а юзает еще меньше)

С Nitra без знания хотя бы основ Nemerle работать не получится
Поэтому ниша даже наверное несколько больше чем принято считать:)

Ну как, заходишь на RSDN — а там его реклама :)
поневоле запоминается :)

Попытаюсь обьяснить. В многих языках больше фич, чем было бы полезно для long term поддержки и читаемости. Не то чтобы фичи совсем не нужны, но очень ограничено. Для них пишут Codestyle, который может очертить основную массу хороших фич языка, ограничив сложные и тяжело воспринимаемые. Вот например для С++ google.github.io/styleguide/cppguide.html

Для Scala — Scalaz явно за пределом того что лучше использовать в основной массе проектов, скажу как разрабочик на Scala в течении пары лет

Для вас может вся Scala за пределами, судя по комментарию, но это нормально, вы не часть коммьюнити и думаю в этих языках глубого не копали. Такие мнения видали не раз на всех форумах, хотя потом эти люди таки прочитывали книжку по этим ЯП и говорили «а, вот оно что»

Пока что вижу только 3 плюса у Go перед JVM языками:

1) Простота — можно нанять студентов и за пару недель обучить писать вменяемый продакшен код.
2) Нет VM, лично меня аж трясет насколько тяжело в больших проектах проапдейтить JVM. Из за этого большая часть проектов еще на 1.6 и 1.7
3) Язык разивается, можно накоммитить в опенсорс много чего полезного, что очень хорошо для персонального бренда.

Но, сам язык еще имеет детские болезни и его основной конкурент это не Java, а скорее Node.js. А «go get» это худшее что можно было придумать для пакетного менеджера.

Nodes — это лютый звездец, а не конкурент Go. На nodejs пишут только извращенцы — любители callback hell’а.

У ноды будет своя ниша 100% пока джс будет в браузере, так что смиритесь

Согласен. К сожалению, среди нас полно программистов, любящих кушать кактус :)

Js проще простого, проблемы возникают ввиду того что многие проецируют свой опыт других языков, и думают что он делают некую магию, а ее там нет.

А генераторы зачем придумали? Как бы уже не времена 0.12.* версии и можно пользоваться смело.

Генераторы не решают проблему callback hell’а. Они ее усугубляют, т.к. от колбэков мы переходим к корутинам, которыми нужно явно управлять. А это сложнее для понимания, чем колбэки. Получаем еще худший coroutine hell вместо callback hell’а :)

читать код проще намного, места занимает меньше. как по мне — лучше решение, чем callback. и не на много сложнее в понимании. что в них сложного?

Достаточно переписать вот этот простой и понятный код на колбэки или корутины, чтобы понять, что в них сложного:

function GetUser(userID) {
    var u = getUserFromMemcache(userID);
    if (u == null) {
        u = getUserFromDB(userID);
    } else {
        logAccessToMongoDB(userID);
    }
    return u;
}

Не забывайте, что все функции в вышеприведенном коде лезут в сеть, т.е. являются блокирующими. Поэтому предположим, что у вас имеются аналогичные асинхронные функции с калбэками или корутинами.

function __sync(gen) {
var iterable, resume;
resume = function(err, retVal) {
if (err) iterable.throw(err);
iterable.next(retVal);
};

iterable = gen(resume);
iterable.next();
}

function GetUser(userID) {
__sync(function* (cb) {
var u = yield getUserFromMemcache(userID, cb);
if (!u) {
u = yield getUserFromDB(userID, cb);
} else {
yield logAccessToMongoDB(userID, cb);
}
return u;
});
}

Где-то так можно сделать. И если спрятать хелпер функцию в какой-то модуль или использовать любое другое подобное решение с просторов интернета — не намного больше кода и достаточно понятно что происходит.
Единственная реальная проблема — обработка ошибок, в примере выше можно все обернуть в try..catch, либо можно в __sync возвращать объект ошибки. как угодно в общем.

Да, ваш код реально проще моего — любой школьник сразу поймет, что к чему. Беру свои слова насчет callback hell’а обратно.

А так?

function getUser(userId) {
    return getUserFromMemcache(userId)
        .then(null, () => getUserFromDB(userId) )
        .then(null, () => logAccessToMongoDB(userId) );
};
А так?
function getUser(userId) {
return getUserFromMemcache(userId)
.then(null, () => getUserFromDB(userId) )
.then(null, () => logAccessToMongoDB(userId) );
};

Не пойму, куда в вашем коде подевался if после чтения юзера из мемкэша.

Да, пардон, я изначально не правильно прочитал, как-то так:

function getUser(userId) {
    return getUserFromMemcache(userId)
        .then(function(p) {
            logAccessToMongoDB(userId);
            return p;
    }, () => getUserFromDB(userId) );
};
^ подразумевает (иное не было оговорено) что getUserFromMemcache возвращает промис, который резолвится если юзера нашли и риджектится иначе.
подразумевает (иное не было оговорено) что getUserFromMemcache возвращает промис, который резолвится если юзера нашли и риджектится иначе.
Очень спорное предположение, учитывая, что в оригинале резолвится null, а не реджектится.

В таком случае можно обретнуть это в еще один промис

 getUserFromMemcache(userId).then(rejectIfNull);

т.е. получаем

function getUser(userId) {
    return getUserFromMemcache(userId)
        .then(rejectIfNull)
        .then(function(p) {
            logAccessToMongoDB(userId);
            return p;
    }, () => getUserFromDB(userId) );
};

Уже нифига не понятно, что происходит, при этом код до сих пор не работает так, как оригинал — в оригинале logAccessToMongoDB вызывается синхронно, у вас асихнронно.

Дак в этом же и смысл был — посмотреть на эквивалентный асинхронный код, поэтому весь этот код, разумеется, не будет работать также:

предположим, что у вас имеются аналогичные асинхронные функции

upd:

т.е. получаем
можно еще слегка улучшить читаемость так (смысл не меняется):
function getUser(userId) {
    var getFromCache = () => getUserFromMemcache(userId).then(rejectIfNull);
    var getFromDb = () => getUserFromDB(userId).then(rejectIfNull);
    var logAccessToMongoDb = (p) => { logAccessToMongoDB(userId); return p; };
  
    return getFromCache().then(logAccessToMongoDB, getFromDB);
};

эхх... поверьте мне как человеку пишущему на js очень много — асинхронный код всегда более сложен для восприятия, даже с async/await надо понимать как оно работает.

в целом асинхронность не страшна — но есть неоспоримый факт — синхронный код всегда очевиднее, единственное почему асинхронный апроач получил популярность, так это потому что асинхронность проще чем многопоточность. в целом, главный плюс асинхронности в том что многопоточность весьма хорошо прячется, и вы уже не наступите на старые грабли — это важно ибо большинство программистов весьма посредственны.
именно из-за низкого уровня программистов появился Go. и скорее всего, все будет идти к этому, я имею ввиду упрощению.

Java со временем потеряет свои позиция из-за сложности как и C++ в свое время, естественно она скорее всего полностью не умрет, но в данный момент — она излишне сложная.

JS — очень простой, но вот асинхронность которая лежит в его корне многим не нравится, и будут пытаться уйти от него

поверьте мне как человеку пишущему на js очень много — асинхронный код всегда более сложен для восприятия
Охотно верю, разумеется это так.
Писать однопоточные приложения тоже проще, чем многопоточные, не так ли? Я вот как-то не наблюдал кричащих о том, что эта ваша многопоточность — отстой. Поэтому, разумеется, non-blocking код будет сложнее для понимания/дебагинга чем blocking. Так же как и многопоточный код сложнее для понимая чем однопоточный.
И да, я не адепт жса или чего еще (если что), я просто предложил вариант без колбек хела (который, вроде бы, чуть понятней).
И да, я не адепт жса или чего еще (если что), я просто предложил вариант без колбек хела (который, вроде бы, чуть понятней).
я вам к тому что это не благородное занятие, вы потратите время но все равно придет другой человек и спросит — а как этот код вообще работает?
Я вот как-то не наблюдал кричащих о том, что эта ваша многопоточность — отстой.

Да дофига и больше их было и есть. Причём со всеми вариантами альтернатив, начиная с раздельных процессов на каждую задачу (относительно дёшево и давно автоматизировано на Unix, но убойно дорого на Windows), автоматов под управлением select/poll/etc. (для Unix; по сути это та же асинхронность в рамках одного треда), автоматов под более сложные структуры типа Twisted (на высшем уровне — то же вплоть до промисов)... Постоянно вспоминают удачные примеры такой реализации — от классических юниксовых средств типа innfeed и до современных комбайнов вроде nginx, а на соседней планете — монстры типа драйвера NTFS...

Или ещё было эпическое противостояние между squid и oops, причём первый был, грубо говоря, на poll, а второй — на треде на клиента. Oops отлично работал на Solaris, которая была практически единственная тогда (~2000) из юниксов нормально вылизана на многонитевость, и то, её M:N модель начинала дохнуть; но он не работал нормально нигде больше, и особенно на основных тогда Linux & FreeBSD. Squid ожил и сейчас занимает свою скромную нишу (в основном для шейпинга http, а не кэширования), oops скончался очень быстро и про него помнят только старперы вроде меня.

И само тредовое взаимодействие, как только оно выходит за пределы стандартных шаблонов организаций вроде пулов с очередями, становится неподъёмно сложным. Больше всего это бьёт не по userland, где легче разделить активности вроде отрисовки экрана, скачивания данных и т.д., а по коду ядра, где в принципе не уйти от сложных взаимодействий вокруг слоёв BIO, VM, VFS (эта троица кого хочешь до цугундера доведёт), и во FreeBSD все девелоперские ветки переполнены lock order reversal’ами чуть менее, чем полностью, а в Linux сложность подсистемы RCU превысила, кажется, сложность любой другой подсистемы. Matthiew Dillon поэтому отколол себе DragonflyBSD, что решил увести это на обмен сообщениями — но в результате стал отшельником посреди густонаселённой местности.

Поэтому, разумеется, non-blocking код будет сложнее для понимания/дебагинга чем blocking.

Ровно до тех пор, пока этот самый blocking не впадёт в первый раз в банальный deadlock между двумя подсистемами. Обычно наблюдение такой ситуации приводит к вырванным волосам и желанием снести всё это и перейти хотя бы на Erlang, где можно штатно спросить процесс «на чём ты завис, женщина лёгкого поведения?» и вывести из этого ожидания. Но так как в 99.99% случаев такой переход недостижим, начинаются шаманские пляски вокруг перевода всей синхронизации в такую форму, когда она понятна последнему из юниоров в отделе.

весь код может работать так же, вам всего лишь нужно дождаться резолва промиса, который вернет вам logAccessToMongoDB, но вы по понятным причинам решили этого не делать.

Дождаться резолва промиса logAccessToMongoDB и что? Результат все равно игнорируется, error handling’a никакого тоже нет (в оригинале). Но какбы не вопрос, можно и «дождаться»

var logAccessToMongoDb = function (p) {
    return logAccessToMongoDB(userId).then(() => p, () => p);
};
п.с. вы же понимаете, что слово «дождаться» тут некорректно — именно поэтому весь этот код будет работать по-другому (включая, самое главное, клиента getUser — который теперь вместо значения получает промис)
Дождаться резолва промиса logAccessToMongoDB и что? Результат все равно игнорируется, error handling’a никакого тоже нет (в оригинале). Но какбы не вопрос, можно и «дождаться»
В оригинале исключение из logAccessToMongoDB обрабатывалось бы выше по стеку, а в вашем случае оно просто проглатывалось...
return logAccessToMongoDB(userId).then(() => p, () => p);

... и продолжает проглатываться (facepalm)

вы же понимаете, что слово «дождаться» тут некорректно
Абсолютно корректно
именно поэтому весь этот код будет работать по-другому
Он будет работать по-другому потому, что вы не осилили написать эквивалентный асинхронный код, что в общем случае всегда возможно сделать.
В оригинале исключение из logAccessToMongoDB
погодьте, а откуда там исключения-то? Особенно в коде от человека пишущего на go =) Поэтому в моем примере оно специально и не хендлится.
Он будет работать по-другому потому, что вы не осилили написать эквивалентный асинхронный код
Я что-то упустил, но зачем такой эквивалентный код вообще?
что в общем случае всегда возможно сделать.
а можно пример?
погодьте, а откуда там исключения-то?
Откуда исключения при записи в монгу? Например, монга может упасть.
Особенно в коде от человека пишущего на go =)
А никто тут и не пишет на го
Поэтому в моем примере оно специально и не хендлится.
Оно у вас хендлится, только местами, так как промисы изначально предоставляют обработку исключения из коробки, которую вы хакнули так, что она перестала делать то, для чего она предназначена.
Я что-то упустил, но зачем такой эквивалентный код вообще?
Эквивалентный код для того, что показать как в ноде решить задачу, которая уже решена на другом языке. Если это сильно сложно, покажите лучше как на ноде поднять веб-сервер тремя стрчоками кода
а можно пример?
Вот эквивалентный код, который не проглатывает никакие исключения, работает точно так же как оригинал и вырвиглазно выглядит, как и большая часть кода, написанного под ноду.
function getUser(userID){
    return getUserFromMemcache(userID)
        .then(function(userFromCache){
            if (userFromCache == null){
                return getUserFromDB(userID);
            } else {
                return logAccessToMongoDB(userID)
                    .then(function(){
                        return userFromCache;
                    });
            }
        });
}
Откуда исключения при записи в монгу? Например, монга может упасть.
Во-первых, мы вызываем какую-то произвольную функцию, которая может перехватить исключения от драйвера монги. Во-вторых, сам драйвер монги может и не кидаться исключениями.
А никто тут и не пишет на го
Погодьте, тред начался с того что гофер дал пример блокирующего js-кода и сказал что аналогичный асинхронный код на джсе будет выглядеть совсем нечитаемым.
Эквивалентный код для того, что показать как в ноде решить задачу, которая уже решена на другом языке
Ээ, решена как/на каком другом языке?
так как промисы изначально предоставляют обработку исключения из коробки, которую вы хакнули
При ексепшене промис зареджектится. Да, если будет ошибка получения юзера из кеша — в моей варианте пойдет запрос в базу, что сделано специально, но отличается от оригинала. (при условии что оригинальный getUserFromMemcache кинется эксепшеном; но оригинальной getUserFromMemcache может и не кидаться, а скетчить его сам — в примере это неопределено)
Где я эту обработку хакнул (кроме игнорирования результата работы logAccessToMongoDB)?
Т.е. в вашем примере если упал мемкеш — промис getUser’a зареджектится. В моем примере — промис getUser’a зареджектится если упал и мемкеш и дб (при этом пофигу что произошло с logAccess)
Вот эквивалентный код, который не проглатывает никакие исключения,
Ок, спасибо. Да, если предположить что каждая из ф-ций в оригинале кидается эксепшенами — то ваш вариант будет эквивалентным.
Погодьте, тред начался с того что гофер дал пример блокирующего js-кода и сказал что аналогичный асинхронный код на джсе будет выглядеть совсем нечитаемым.
И адепты JS успешно этот тезис подтвердили

Хипстероы не следуют реквайрментам, хипстары «пыщь пыщь и в продакшен»

Я экспериментировал с разными асинхронными стилями и в конце-концов остановился на использовании классических callback. Проблема «callback hell» существует только в учебных примерах и решается библиотеками типа async, обеспечивающими последовательный вызов асинхронных функций и встроенную поддержку ветвления. По моему опыту этот паттерн покрывает примерно 95% всего кода NodeJs (оставшиеся 5% это параллельное исполнение кода, map, etc).

Для этих 95% вначале я использовал async потом сделал свою tflow: www.npmjs.com/package/tflow поддерживающую также досрочное прерывание потока. Ваш пример будет выглядеть еще проще с tflow:

var tflow = require('tflow')

function getUser(userId, done) {
  var flow = tflow([
    () => getUserFromMemcache(userId, flow),
    (u) => u ? logAccessToMongoDB(userId, flow.send(u)) : getUserFromDB(userId, flow)
  ], done)
}

async function (userID) { var u = await getUserFromMemcache(userID); if (u == null) { u = await getUserFromDB(userID); } else { await logAcessToMongoDB(userID); } return u; }


async function GetUser(userID) {
    var u = await getUserFromMemcache(userID);
    if (u == null) {
        u = await getUserFromDB(userID);
    } else {
        await logAccessToMongoDB(userID);
    }
    return u;
}

Co в помощь.
И фреймворк отличный на генераторах есть: Koa

github.com/tj/co не избавил от callback hell’а, также как и koajs.com . Они пытаются решить проблему вложенных колбэков, но колбэки все равно остаются, а вместе с ними и callback hell при дебаге, рефакторинге и последующей поддержке чего-нибудь сложнее hello world application’а, где есть общение по сети (с базами данных, мемкэшами, микросервисами и прочей external хренью).

Callback hell это уже давно решенная с помощью промисов проблема.

Не совсем. Многие промисы тоже не понимают, и им кажется это тоже какойто магией/безумием/излишеством.
Как по мне, наилучший подход для программирования — это императивный. Он самый понятный/простой/тупой, люди знают чего от этого ожидать, и для огромного колва современных задач его более чем достаточно.

лютый звездец
это для тех, кто не умеет правильно писать на nodejs.

Это как бить молотком по пальцам и винить в этом молоток — сами создают себе проблемы, а потом плачут на форумах, вместо того, чтобы посмотреть как правильно что-то делается.

Другие же, более адекватные люди, используют инструмент правильно и никаких проблем с какими-то «callback hell’ами» не имеют. Что именно использовать — это дело вкуса. Кто-то использует промисы, кто-то генераторы, кто-то async/await, а каму-то достаточно просто использовать нормальные именнованные функции, с помощью которых запросто избавляешься от «страшнейших» «вложенных» коллбеков, так и в разы упрощаешь процесс дебага.

это для тех, кто не умеет правильно писать на nodejs.
Это как бить молотком по пальцам и винить в этом молоток
Именно, только при всём при этом вам нужно был шуруп вкрутить и «правильно бить молотком, не попадая по пальцам» — так себе решение проблемы.

Если вам вкручивать шурупы, то на кой черт вы молоток взяли?

Спросите у разработчиков на nodejs.

Тут только товарищ выше предлагает молотком шурупы забивать. Остальные разработчики используют нужные инструменты для соответствующих целей.

нужные инструменты для соответствующих целей.
Это вы так JS для бекенда называете? )

а чем JS для бэкэнда плох? может крупные мего-порталы на ноде и не стоит писать, а вот чатик — вполне) ИМХО канеш)

а каму-то достаточно просто использовать нормальные именнованные функции, с помощью которых запросто избавляешься от «страшнейших» «вложенных» коллбеков, так и в разы упрощаешь процесс дебага
Тут один товарищ уже пытался привести пример кода на nodejs с «нормальными именованными функциями». Что-то результат так себе. Может, вы ему поможете?

Программисты nodejs делятся на три категории:
1. Новички. Они попробовали написать hello world application, которое не общается по сети. Результат из вдохновил и они пока считают nodejs крутой технологией. Наивные.

2. Испытавшие ад обработки ошибок и дебаггинга nodejs в продакшн. Обычно после этого они стараются забыть ноду как страшный сон.

3. Упоротые наркоманы, считающий, что ад разработки сетевых приложений на ноджз делает их мега-гуру-программистами.

Используйте асинк или промисы и не будет вам колбек хела

Помогите своим товарищам выше написать понятный код на асинке с промисами без калбэк хелла. А не то они, похоже, скоро зайдут в тупик.

Alexander Kazantsev уже написал понятный пример когда с использованием генераторов, что еще нужно? зачем в таком случае использовать промисы?
вот тот же пример только с co + обработка ошибок


function GetUser(userID) {
co(function* () {
var user = yield getUserFromMemcache(userID);
if (!user){
user = yield getUserFromDB(userID);
} else {
yield logAccessToMongoDB(userID);
}
return user;
})
.catch(err => throw e) // or log
}
function GetUser(userID) {
	return getUserFromMemcache(userID)
		.then(user =>
			!user ?
                                getUserFromDB(userID) :
				logAccessToMongoDB(userID)
		)
}

Этот код не эквивалентен изначальному примеру, так как возвращает результат logAccessToMongoDB, а должен возвращать user. Попробуйте еще раз.

А точно, у вас код не очень хорошо написан, прочитал иначе
Ксати никакие операции логирования не должны кидать эксепшены, если кидает, то у вас проблемы

function GetUser(userID) {
	return getUserFromMemcache(userID)
		.then(user => {
            if (user) {
logAccessToMongoDB(userID);
}

return user || getUserFromDB(userID);                 }
		)
}
Сори за форматирование она по идее будет ужасным, но я сча пишу с телефона

Мне интересно, хоть один Javascript Senior сможет написать эквивалентный асинхронный код на Javascript с промисами? Я ж даже не просил делать это на чистых хардкорных колбеках...

Проблемы такого варианта уже были расписаны выше, во-первых, частично игнорируются исключения, бросаемые logAccessToMongoDB, во-вторых, код не дожидается завершения операции logAccessToMongoDB

Ксати никакие операции логирования не должны кидать эксепшены, если кидает, то у вас проблемы
В каких-то случаях должны бросать, в каких-то нет. С чего вы взяли, что именно в этом случае они не должны бросать? В исходном коде не делается никаких предположений на этот счет, в асинхронном варианте тоже не должно делаться.

Во-вторых, если уж вы явно решили игнорить исключения операции логгирования, то почему вы игнорите только асинхронные исключения, а синхронные валят процедуру и возвращаются вверх по стеку?

Ок, давай я расскажу о логировании.

Логи по своей сути не должны блокировать в принципе, и не особо должны быть синхроными по отношению к основной логике, ибо не одна логика не должна зависеть от того есть ли логирование или нет.

Вот представь себе, монга почемуто недоступна которая юзаеться только для логов, должно ли падать все приложение — ответ нет, ибо это свойство отказоустойчивости системы в целом.

Теперь о том что синхронный эксепшен свалит логику. В Js синхронный эксепшен будет разве что происходит из-за того что код неправильно написан внутри функции логирования, либо не хватает параметров, а это для нас даже очень хорошо, оно упадет еще на этапе девелопмента, а значит мы отловим багу сразу.

Вобщем в данном случае только будут бенефиты от такого использования, и на колбек хел это ни разу не похоже

Логи по своей сути не должны блокировать в принципе, и не особо должны быть синхроными по отношению к основной логике, ибо не одна логика не должна зависеть от того есть ли логирование или нет.
Серьезно, это в любом приложении так работает? Даже в банковском ПО? Даже если логирование это требование GRC и по логам будет проводиться аудит или они могут использоваться как вещественные доказательства в случае инцидента?
Вот представь себе, монга почемуто недоступна которая юзаеться только для логов, должно ли падать все приложение — ответ нет, ибо это свойство отказоустойчивости системы в целом.
Ответ — it depends, на эту тему можно долго говорить. В данном случае был дан кусок кода, который падает, если произошло исключение при вызове функции логгирования. И я второй день не могу получить кусок асинхронного js кода, который делает то же самое.
Теперь о том что синхронный эксепшен свалит логику. В Js синхронный эксепшен будет разве что происходит из-за того что код неправильно написан внутри функции логирования, либо не хватает параметров, а это для нас даже очень хорошо, оно упадет еще на этапе девелопмента, а значит мы отловим багу сразу.
Ну так асинхронные исключения так же могут падать из-за того что неправильно написал код внутри какой-то функции, или из-за того, что где-то не хватает параметров, их тоже было бы неплохо отловить на этапе девелопмента, а не через 6 месяцев в проде, когда выяснится, что логов за последние 6 месяцев нет.
Вобщем в данном случае только будут бенефиты от такого использования, и на колбек хел это ни разу не похоже
В данном случае, увы, получился хел без колбеков
Серьезно, это в любом приложении так работает? Даже в банковском ПО?
скажу так, если вы делаете банковское ПО — то единственное для чего вы можете ноду заюзать, чтобы нотификейешны слать на фронтенд
Ответ — it depends,
если такой ответ, то скорее всего у вас архитектурные проблемы
Ну так асинхронные исключения так же могут падать из-за того что неправильно написал код внутри какой-то функции, или из-за того, что где-то не хватает параметров, их тоже было бы неплохо отловить на этапе девелопмента, а не через 6 месяцев в проде, когда выяснится, что логов за последние 6 месяцев нет.
простите, а отдел QA для чего?

но, если вы так настаиваете

function GetUser(userID) {
	function onGetUserFromCache (user) {
		return logAccessToMongoDB(user.id)
			.then(() => user);
	}

	return getUserFromMemcache(userID)
		.then(user =>  user ?
			onGetUserFromCache(user) :
			getUserFromDB(userID)
		);
}
Даже если логирование это требование GRC и по логам будет проводиться аудит или они могут использоваться как вещественные доказательства в случае инцидента?
Полагаю, в таком случае, это уже НЕ логи.
Это уже часть бизнес-функционала системы.
В Java мире типичный логгер (Log4j):
— не возвращает исключений в код (а вот уродливая поделка java.util.logging возвращает)
— всеми советуется использовать AsyncAppender для развязывания записи в файл с бизнес-логикой
— нет стандартной практики ни на формат сообщений, ни на моменты, когда это делается, ни на данные, которые логгируют.
Везде так и говорится, что логгирование — это замена System.out.println для программиста.
Полагаю, в таком случае, это уже НЕ логи.
Это уже часть бизнес-функционала системы.

Уже тут писалось — логи могут быть целевые, контрольные и отладочные. (Логи в рулонах для производства туалетной бумаги пока что не будем рассматривать, хотя некоторые применения очень к ним близки.) Вы сводите применение только к отладочным логам, для них, да, специфика такова, что они должны минимально влиять на остальную систему.

Я просто оставлю это здесь en.m.wikipedia.org/wiki/Fault_tolerance понимаю что проектирование систем нынче не в моде, ибо лучше всего хуяк хуяе и в продакшен

Я просто оставлю это здесь

Красивая ссылка, но не имеющая никакого отношения к обсуждаемому вопросу.
Запись факта доступа пользователя к ресурсу обычно относится к категории контрольного лога (для собственно подсистемы контроля — даже к целевому), и к нему другие критерии, а не выкидывание в любом проблемном случае.
Только в редком случае «производительность любой ценой» можно их выкидывать, но там обычно уже нет разделения доступа как такового.

Хм. Ок, пусть будет ваш кейс, а не из примера. Если почему-то не работает система логирования должна ли вся система из-за этого не работать? В большинстве случаев должна, за исключением если такие логи не являются бизнес-требованиями (лично я такого никогда не встречал даже в энтерпрайзе, но говорят что такое бывает). В целом любая система должна по максимуму оставатся работоспособной, даже если вышла из строя одна из подсистем (кстати те же микросервисы с этим помогают), обычно это то чего ожидают от систем

Если почему-то не работает система логирования должна ли вся система из-за этого не работать? В большинстве случаев должна, за исключением если такие логи не являются бизнес-требованиями (лично я такого никогда не встречал даже в энтерпрайзе, но говорят что такое бывает).

Ну, я не знаю, что такое «энтерпрайз» в Вашем случае, но в моей работе в интернет-провайдере (думаю, каждый может себе представить, что это и как оно в основе работает) были:

1. Логи, которые критичны — в Вашей терминологии, являются бизнес-требованиями. На диалапе это собственно факт входа/выхода пользователя, апдейты насиженного на линии времени. Система авторизации писала лог, а затем по нему (просто по файлу) шла программа акаунтинга. Кроме того, они предполагались к длительному хранению (грубо говоря, год). Аналогичные требования предъявляются к CDRам (call data records) установленных звонков и пересланных SMS на телефонных коммутаторах.

2. Логи, которые важно иметь настолько, что их не-запись требует срочной реакции, но несистематическая потеря не фатальна. Далее они анализируются для получения статистики и качественных характеристик. Это логи почтовых серверов, http-прокси, групповых юзерских NAT и аналогичных средств. У телефонистов — логи проб звонков (без соединения), потоков дополнительных сервисов.

3. Логи, которые пишутся, только пока никому не мешает эта запись, и используются достаточно редко (в основном при анализе странных ситуаций). Сюда относился netflow магистральных каналов и выделенных внутренних каналов, причём сами генераторы «любили» терять из них записи, так что просто вносилась поправка по статистической оценке потерь в конкретных условиях.

В принципе, группы 2 и 3 тоже можно назвать бизнес-требованиями, но такими, для которых явно описана возможность потери (с ограничениями плотности такой потери и реакцией на превышение этой плотности).

В целом любая система должна по максимуму оставатся работоспособной

Для систем массового обслуживания, вроде телефонного оператора, критерии немного другие. Обычно сохранение CDR — первичное требование, которое важнее, чем собственно приём новых звонков и даже поддержание текущих. Далее, установленные звонки имеют жёсткий безусловный приоритет перед новыми, а с учётом промежуточных фаз звонка — находящиеся на более поздней имеют приоритет перед теми, что на более ранней. Если это не соблюдается, получаются ситуации вроде такой. Но, возвращаясь, логи тут — абсолютное требование.

Ага, из вашего примера группы 2 и 3 не должны блокировать основную логику, а вот группа 1 судя по всему должна. Хотя 1 группу я бы логами не назвал, но по поводу терминологии спорить не собираюсь.

Когда команда не может понять, что написано в коде, это скорее проблемы организации работы (отсутствие комментариев и ревью), а не языка.

Скала позволяет писать очень универсально, но при этом очень витиевато. В прикладном коде это обычно не нужно, на ревью приведённый кусок должны были попросить переписать более прозрачно, упростить и специализировать.

В библиотеках такой хитрый код допустим, но ими должна заниматься команда, которая специализируется конкретно на Скале, а не просто использует её как один из возможных вариантов. То есть там все должны быть такие, как парень, написавший приведённый кусок.

Я Скалу активно ковыряю уже несколько месяцев и до сих пор не могу сказать, нравится она мне или нет. Попробовать её точно стоит — язык интересный и расширяет мировоззрение.

Отличная статья. Без набросов, кратко и по сути. Автор — практик, а не языковой религиозник. Будет через 5 лет технология, которая позволяет решать их задачи лучше, чем Go — перейдет на нее и глазом не моргнет. И это правильно.

Кто не знает ещё про Go, приходите 23 января на львовский митап по Go — www.meetup.com/...g-Group/events/227453083 Пообщаемся.

видео с митапа на ютуб планируется?

Статья была бы отличной, если бы он так прямо и заявил, что они натрахались со скалой, с ее сложностью, что те же, конкретно ихнее задачи на go у них получается решить быстрее и эффективнее и был бы в большей части прав. Но нет же, он делает упор на смехотворные аргументы, что у них бардак в разработке, никаких конвеншинов, все пишут как хотят, не делают код ревью, и винит во всем скалу, будто бы она во всем виновата. Ну смешно же.

Он не делает на этом упор, а лишь приводит пример из прошлой работы, призванный показать, что со Скалой нужны гораздо более жесткие организационные усилия. С Go они тоже нужны. но в меньше степени.
А смешно вам потому, что аргументы вы сами автору приписали, он о другом писал. :)

Чуть офтопик, но все же. А как вам такие вещи заходят? — bartoszmilewski.com/...-programmers-the-preface

Эта тема как-то мимо меня прошла, а вот поковырявшись в Хаскеле, неизбежно прихожу к ТК. Но не могу сказать пока что «хорошо пошло»...

заходят плохо )))
я как то по наводке Влада Патрышева кое чего начинал читать но похоже моя математика за столько лет после матфака превратилась в тыкву ( надо как минимум теорию множеств освежить )

Ну вот я, по той же наводке так же начинал читать — и таааак грустно че-то. Правда, у меня в бэкграунде математики считай что вообще нет.

когда ей двадцать лет не пользовались а ынтерпрайз починяли — тоже считай что нет
жалко конечно протерянных знаний но к сожалению при выборе покушать или математика в начале 200х мне покушать казалось важнее( тк в универе с этим было прям совсем грустно )

Ну вон тот же Патрышев — хороший пример: и с покушать сложилось, и с математикой, и со скалой, и с многим прочим. Хотя исходные условия у чувака были жесткие.

да он человечище с титановыми яйцами но не все же такие
плюс далось это все не малыми трудами и в не юношеском возрасте
он сам рассказывал как в 30 себе смог велосипед купить наконец то.(слава СССР) ... Так что главное не ссать и продолжать пахать

да он человечище с титановыми яйцами

Это да. Коротко и объективно.

Нищеброд какой-то. Кстати, количество вакансий по Go уже превышает количество вакансий по Scala в 3 раза и разрыв продолжает стремительно расти. Stackoverflow подтверждает.

чето вы молодой человек резкий как понос и не по делу

У вас неправильный stackoverflow. У меня по этим ссылкам результат такой:
careers.stackoverflow.com/jobs/tag/go — 153 вакансии
careers.stackoverflow.com/jobs/tag/scala — 68 вакансий

походу выборка зависит от страны из которой заходишь

careers.stackoverflow.com/jobs/tag/go — 6 вакансий
careers.stackoverflow.com/jobs/tag/scala — 33 вакансий

А что не так? Автор как бы не утверждает что Скала г-но. Говорит про области применимости и т.п. Вполне резонно. Или может быть ТС считает что Скала — это самый лучший язык ®™© ?

Проблема в том что всем было лень учить скалу, ибо она отличается от тех языков где можно нахерачить спагетти кода в императивном стиле.
Батхерт вызывает лень членов команды

и менеджмент который вместо наведения порядка притащил новый клубочек поиграться
все такие котики — ми ми ми а сцанину ни кто не убирает

Очень легко видеть проблемы в других. Если у языка такой высокий уровень вхождения (тут думаю споров не будет) и для общих задач есть более простые, удобные и современные инструменты, то зачем его такой учить? Ну кроме как для интереса или для тех узких задач где супер типизация отыграет.

Какая разница на каком языке педалить тонны бойлерплейт кода? А хотя можете не отвечать, кто-то же должен это делать...

Ну если так все запущенно, то действительно ни Го ни скала не помогут.

То, что видел.
Часто приходят в Scala по трем причинам:
— писали на «хипстерском» Ruby/... и решили пересесть на что-то «хипстерское», но «по-мощнее»;
— перешли на скала, буквально, из-за 1-2-3 библиотек (акторы в Akka, REST API в Spray, ...) - кратко, ясно, красиво;
— перешли на скала, что бы привлечь «загрустивших» Java-сениоров.
-
А потом понеслась — scalaz, shapeless, ..., но матчасть никто не подтягивает.

Согласен в целом. Добавлю вариант когда есть (один) очень продвинутый чел который действительно будет более производителен если ему дать вполную оторваться с ФП. Проблема в том, что он(и) как положено фан-бою верит что все остальные в команде быстро подтянутся, осознают, просветлятся когда увидят как это все совершенно. И когда этого не происходит, то начинается поиск «рациональной» причине, как правило в скудоумности «ниасилифших». И ривью тут, которые так советуют в этой ветке, не всегда помогают потому как чел может действительно быть продвинутым и объяснить что к чему красиво, вот потом это без него понять другим не присутствующим может нелегко быть.

но матчасть никто не подтягивает.
об одном известном языке программирования очень понравилось:
язык который требует от программиста регулярного изучения нескольких научных монографий в год — плох для продакшена.
Часто приходят в Scala по трем причинам
и эти причины — НЕ причина переводить разработку в конкретной компании на Scala :)
и эти причины — НЕ причина переводить разработку в конкретной компании на Scala :)
Ну это философский вопрос.
А что может служить причиной перехода на Scala?
А что может служить причиной перехода на Scala?
из тех что смог понять и согласен с их весомостью:
— предметная область сложна и разработка в ней осталась традиционно в каком-то из видов waterfall
— предметная область хорошо формализована спецами из computer science
— предметная область и относится к computer science
— требуется удержать-привлечь амбициозных и заскучавших программистов, в расчете на то что после отсева оказавшихся просто программистами с завышенной самооценкой — число оставшихся окажется достаточным для проекта, и их уровень будет качественно другой чем средний. по другому — применение Scala как средства отбора и удержания программистов высокой «математической» квалификации, и отсев программистов с «инженерной» квалификацией.

Просто вся статья сводится к следующему: мы купили жителям нашего города Хамеры, но они начали летать по городу, попадать в аварии, убивать себя и пешеходов. Поэтому вместо того, чтобы установить светофоры и ввести ПДД, мы выдали всем самокаты, на них трудно убиться.

Я понимаю если жители обычно ездили в ближайшую булочную и назад, тогда переход на самокат оправданный. Но аргументы выше звучат нелогично и притянутыми за уши.

Нормальная статья. Все четко написано. Вон даже гуру джава энтерпрайза начали на гоу переходить (источник цитаты нагуглите сами):
> I had spent over a decade of writing Java backend software and just like when I switch from writing C++ to Java I thought I was 10 — 100x more productive I feel the same switching from Java to Go.

Для всех задач есть свои инструменты. Какой-то микросервис написать, или небольшую тулзовину, действительно с go продуктивность будет выше. Но с ростом сложности проекта, основное преимущество go начинает таять. Как с тем же питоном — все кричат о возросшей продуктивности, но никто не рискует браться за большой проект а если беруться, то потом жалеют.

Но с ростом сложности проекта, основное преимущество go начинает таять.
Интереса ради, откуда такие выводы? Писали большой проект на Go или «так кажется»?

Не писал, но знаю людей которые пробовали. Да и вообще, можете вспомнить большие проекты написаны на go?

Да и вообще, можете вспомнить большие проекты написаны на go?
Я то как раз могу.
А вот аргумент «знаю людей, которые пробовали» никакой критики не выдерживает.
Я то как раз могу.

Жду

А вот аргумент «знаю людей, которые пробовали» никакой критики не выдерживает.

Чем этот аргумент отличается от аргумента что я сам пробовал и понял что не годится? Чужой опыт не в счет?

Чем этот аргумент отличается от аргумента что я сам пробовал и понял что не годится? Чужой опыт не в счет?

Без пруфлинков такой аргумент аналогичен наглой лжи.

Да и вообще, можете вспомнить большие проекты написаны на go?

Вот список опенсорц проектов на гоу — github.com/search?q=language:go . Какие из них большие, а какие не очень, судить вам. Очевидно, что многие из них сейчас на слуху не только среди наших братьев по гоу-секте.

Вот список хипстерско-стартаперских компаний, пишущих на гоу:
* Google
* Facebook
* Apple
* Twitter
* Uber
* Booking.com
* CloudFoundry
* Dropbox
* Mail.ru
* Yandex
* ....
* PROFIT!!!

Да он в конец любого списка ставит этот бессмысленный пункт. Слово-паразит.

Не годиццо.

* Google
В Гугле — 30.000 сотрудников. Полагаю, что в совокупности они пишут более чем на 100 языках программирования.
Аналогично с другими компаниями.

Нет. Официально принятыми языками в гугеле являются
— C++
— Java
— Python
— Go

все остальное предано анафеме, а за haskell руки отрывают.

+JavaScript. Кроме этого там существует — непустон множество пользователей R (ссылка на googlе R conventions была в R дайджесте), кроме Go разработаны языки Dart и Sawzall (также см.https://www.quora.com/Which-programming-languages-does-Google-use-internally )

Вот список опенсорц проектов на гоу — github.com/search?q=language:go . Какие из них большие, а какие не очень, судить вам. Очевидно, что многие из них сейчас на слуху не только среди наших братьев по гоу-секте.

Так и знал, что не знаешь, видать в методичке не написано. Помогу, наиболее известный проект на go это докер, но кода там не сильно много, несколько десятков тысяч строк.

Вот список хипстерско-стартаперских компаний, пишущих на гоу:

Я не спрашивал какие компании используют go, я спрашивал о целеобразности go в больших/сложных проектах. Эти компании используют десятки языков, даже, присядь, си шарп. Ну я же не кричу что гугл, фейсбук и эпл пишут на си шарпе.

Ну я же не кричу что гугл, фейсбук и эпл пишут на си шарпе.

Потому что они не пишут на сишарпе

Я не спрашивал какие компании используют go, я спрашивал о целеобразности go в больших/сложных проектах.
Если вам и вправду это интересно, то отталкивайтесь от того, что Go изначально разрабатывался для потребностей Google, которыми они как раз и называли «большие масштабы» — всего, и команд, и количества кода, и количества нод и т.д.
В Google на Go написано более 3 млн. строк кода (по неофициальным данным начала 2015-го года, сейчас уже больше). И я думаю, Go более чем отлично справляется с этой задачей, даже если ваши представления о качествах «языка для больших проектов» расходятся с оными от Google.

Вы считайте не строки кода, а строки кода per project.

3 млн. строк кода при одном проекте — отлично.
3 млн. строк кода в 100-1000 небольших проектиках — не впечатляет.

Никто не спорит что на го можно педалить код. Писать и поддерживать большой проект на го — пока кажеться из ряда фантастики.

Писать и поддерживать большой проект на го — пока кажеться из ряда фантастики.
Судя по вашим комментариям, вы превозносите скалу/c#/java, а Go считаете кастрированным и гоферов упоротыми. Но Go сами вы, разумеется, ещё не писали, ни маленький, ни большой проект.

Так как у вас могла родиться мысль, что ваше «кажется» как-то близко к реальности?

en.wikipedia.org/..._in_most_popular_websites
чет не видно го ни на фейсбуке ни на твитере

Интересно, сколько в твитере в процентном соотношении скалы, а сколько го.

Через год в твиттере всю скалу заменят на гоу. Инфа 100%.

если незаменят с вас ящик коньяку.

Твиттер — github.com/twitter/gozer
Prototype mesos framework using new low-level API built in Go.
0 releases
3 contributors

А вообще, вот классная картинка от @divan0, показывающая компании, использующие гоу в продакшн — habrastorage.org/...94793b1809d0bf18ce4dd.png .

Хотелось бы видеть такую для скалы.

Так это только верхушка айсберга.

Это как с 3D принтерами

Заголовок: «В США запустили первый спутник напечатанный на 3D принтере!»
Реальность: ну напечатали не сам спутник, и лишь заготовки держателей солнечных панелей

так и тут:

Заголовок: «Booking.com перешел на go!»
Реальность: ну в смысле не сам сайт, парсер логов на go переписали

Упоротые гоферы такие упортые.
сравни " We are using Go for a few small projects, " с

Booking.com пишет на Go

У них добрая половина внутренней инфраструктуры написана на Go — точнее это было так в ноябре 2014, когда я сидел рядом с инженером из booking.com на конференции dotGo.

А что такое эта самая «внутренняя инфраструктура»? Если речь о каких-нибудь скриптах или утилитах для, напиример, continuous deployment, парсинга логов и т.п. вспомогательных вещей, то их хоть на shell script написать можно. Выбор языка в подобных задачах, как раз, на десятом месте — были бы удобные API для решения насущных задач.

Следуя аналогии я увидел немного другое: да, брали мы хаммеры, но задолбались — здоровые, парковать сложно и жрут как не в себя. Нам не подходит.

Если бы это было основным мотивом, тогда бы не было такого шума. Но в статье же говорится о другом — Хамерами сложно управлять, сложно научить ездить на нем ребенка, многие ездят как вздумается, нарушают ПДД, не уважают друг друга, а одни гонщик так запарковал свой Хамер, что несколько часов его доставали. То есть реально притянуты за уши аргументы вместо более реальных — здоровые, парковать сложно и много жрут.

Эта статья не про то, какая Scala плохая или какой Go крутой, это про то, что найти 100 программеров на Go проект намного проще, чем столько же на Scala проект, причем это точка зрения не программиста и даже не Team Lead а CTO, у которого наряду с задачами написать проект красиво, есть так же задачи по поддержке и развитию, которые в прямую упираются в вопрос кадров. И на самом деле — найти 100 программистов на Scala не реально. Даже если Вы Twitter и готовы отстегнуть существенные бонусы — такого количества Scala программистов не найти. То есть они есть конечно, но все они повязаны контрактами и обязательствами и вот просто так повыдергивать их из текущих компаний/проектов не возможно. Порог вхождения в Scala большой. Если в проекте в полную используется scalaz + функциональное программирование — порог вхождения очень большой. То есть привлечь скажем PHP или JS программиста и посадить писать на Scala не получится. С другой стороны это можно сделать с Go ( то есть взять средней руки PHP программиста и научить его за пару недель писать сервисы на Go ). Именно об этом и была написана статья и все это полностью соответствует действительности.

Даже если Вы Twitter и готовы отстегнуть существенные бонусы

Твитер не готов, я даж ему резюме слал, был удивлен результатом :-)
Порог вхождения в Scala большой.

В базовую скалу, при знании джавы порог вхождения не такой уж и большой. Другое дело что времени между писанием джавообразной фигни, и более мение нормального скала кода должно пройти прилично, и у самого программиста должно быть желание научиться писать нормальный скала код. Судя по всему у программистов из указанной статьи такого желания нет, от того и проблема растет.
Если в проекте в полную используется scalaz + функциональное программирование — порог вхождения очень большой.

Таки большой, но вы должны знать, для чего вы его используете, и что оно вам дает.
Решение за использованием данной технологии должно лежать не только на программистах.

более того я скажу что бы притащить scalaz надо предъявить какие то серьезные причины ( чего я так понимаю в этом случае и близко не было )

Типичная причина — отсуствие код ревью, где каждый комитит как хочет.
Видимо это и случилось с автором статьи.

самая большая проблема с этой скалой, что все время улучшаешь код , вместо того, чтобы фичи добавлять. идет постоянное «совершенствование», потом гуру уходит, и все начинается по-кругу. напомнило мой опыт с перлом, через полгода, долго пытался понять, что же я написал :)

Scala — это Perl 6. Такой же выразительный и такой же далекий от продакшн нужд.

Те Akka, Spark, Play — не «продакшн» ?

Кстати, показательная ситуация со Спарком. Его авторы придерживаются достаточно строгого codestyle (github.com/...abricks/scala-style-guide ).

Есть условное разделение на «программистов библиотек» и «прикладных программистов». Для первых важно минимизировать неправильное использование своего инструмента (для вторых собсно тоже, но немного в меньшей степени). Далее, типы — подсказки компилятору, и, что важнее, программисту. Есть два экстремума — типов «нет» (ну или тип унитарный, или еще какая несущественная терминология), как в Питоне, или же «типы везде», «фанатизм типов». Оба варианта, как показала практика, не подходят для крупных проектов. Оптимум где-то посередине, что Скала позволяет получить. Здесь «оптимум» — ограничения на неверное использование методов, без «связывания рук»

И есть мнение, что для этого надо не 100 «умников-скалистов», а одного-двух адекватных архитекторов + кодстайл, остальным достаточно знать действительно базовые вещи и придерживаться кодстайла. При этом профит (читать как уменьшение трудозатрат на развитие и поддержку проекта) будет бОльшим, чем если бы проект был на Го или Джаве. За счет этих самых «подсказок».

Я бы еще подискутировал насчет иммьютабл вс мьютабл подходов, но это уже будет оффтопиком.

это можно сделать с Go

Я всеже с Го не знаком, и реквестую ссылку на статью Го вс Джава 8.
Что можно прям такого сделать на Го, чего нельзя на джаве, чтобы ЦТО вдруг взял и с перепуга весь стек поменял ?

N причин, почему гоу лучше жавы:

1. Код на гоу можно писать в виме. Для жавы нужна IDE с автокомплитом, которая обычно кушает память, тормозит и еще бывает платной. Поэтому гоу разносит в пух и прах жаву с экономической точки зрения.

2. 100 строк кода на жаве обычно эквивалентны 30 строкам кода на гоу. Средняя длина строки кода на гоу в три раза короче, чем в жаве. Средняя длина идентификатора в гоу в три раза короче, чем в жаве. Поэтому код на гоу легче читать, рефакторить и поддерживать. При этом, в отличие от скалы и С++, код на гоу грепается так же легко как и на жаве с Си.

3. В гоу нет наследования, которое так любят использовать не по назначению жава-программеры. Поэтому в коде на гоу легче разобраться, чем в коде на жаве.

4. В гоу нет бесполезных дженериков и эксепшнов.

5. Юзабельность интерфейсов в жаве нервно курит в сторонке по сравнению с интерфейсами в гоу.

6. Программа на гоу собирается в один исполняемый бинарник без каких-либо намеков на jar hell, jvm и xml configs.

7. На гоу пишут стартаперы и хипстеры. На жаве — аутсорс- и legacy- программисты.

8. На гоу можно запустить 100500 параллельных потоков и они не сожрут всю память и не загрузят проц бесполезными context switch’ами на 100%, в отличие от жавы.

9. На гоу принято обходиться без абстрактных фабрик визиторов по синглтонам и прочих inversion of control-извращений. Поэтому гоу не нуждается в мощном дебагере.

10. ...

11. PROFIT!!!

ну то есть под Go нет
— IDE
— дебагеров
— дженериков
— исключений
И судя по всему на него активно переходят бывшие PHP программисты

Вот тут подробней рассмотрено, как правильно жаловаться на Go в зависимости от бекграунда ) Помогает читать вышеприведенные статьи более вдумчиво )
medium.com/...o-349013e06d24#.6gvsfktip

И судя по всему на него активно переходят бывшие PHP программисты

Ага, даже бывшие пхп-кодеры из facebook переходят на гоу — github.com/facebookgo .

А чего тут ожидать, когда Роб Пайк считает Acme (en.wikipedia.org/...tor)#/media/File:Acme.png) идеальной IDE а подсветку синтаксиса — злом.

ну то есть под Go нет
— IDE
а как же это — github.com/visualfc/liteide ?
«LiteIDE is a simple, open source, cross-platform Go IDE.»
Ну и еще есть плагины для IntelijIDEA и Eclipse (для эклипса вроде плагин так и называется go-ide).
И судя по всему на него активно переходят бывшие PHP программисты
я думаю питонщики на него тоже вполне могут переходить) да и не только питонщики (помню видел когда-то статью на хабре (перевод кажись), как один из разрабов node.js написал что-то в духе — «нода уже не та, поэтому я ухожу в Го», «го рулит» и все такое).

Вот эта статья — medium.com/...well-node-js-4ba9e7f3e52b . Чувак являлся maintainer’ом кучи популярных nodejs библиотек — github.com/tj .

Знайомий написав аутокомліт тулзу для Go та Vim редактора:github.com/nsf/gocode

100 строк кода на жаве обычно эквивалентны 30 строкам кода на гоу.

Я к сожалению на джава 8 не работал, так бы даже поучаствовал бы в специальной олимпиаде «дайте пример 30 строк на го, для которых нужно 100 строк на джаве».
1. Код на гоу можно писать в виме. Для жавы нужна IDE с автокомплитом, которая обычно кушает память, тормозит и еще бывает платной. Поэтому гоу разносит в пух и прах жаву с экономической точки зрения.
угу, комунити идея против вима... оок.
3. В гоу нет наследования, которое так любят использовать не по назначению жава-программеры. Поэтому в коде на гоу легче разобраться, чем в коде на жаве.
ТОбиш Го даже не ОО яп, а процедурный, и в нем легче разобраться ? оок.
4. В гоу нет бесполезных дженериков и эксепшнов.

А монады в нем есть? или все делаеться аля старый добрый це, с 100500 функций для каждого типа данных, и возвращаемым кодом ошибки из функции ?
5. Юзабельность интерфейсов в жаве нервно курит в сторонке по сравнению с интерфейсами в гоу.
А подробнее ?
6. Программа на гоу собирается в один исполняемый бинарник без каких-либо намеков на jar hell, jvm и xml configs.

Тобиш сторонние либы нельзя подключить совсем ?
7. На гоу пишут стартаперы и хипстеры. На жаве — аутсорс- и legacy- программисты.

Ок, это единственный валидный аргумент в списке.
8. На гоу можно запустить 100500 параллельных потоков и они не сожрут всю память и не загрузят проц бесполезными context switch’ами на 100%, в отличие от жавы.

Пруф линки на тесты ?
9. На гоу принято обходиться без абстрактных фабрик визиторов по синглтонам и прочих inversion of control-извращений. Поэтому гоу не нуждается в мощном дебагере.
Тобиш дебагера нету ?
ТОбиш Го даже не ОО яп, а процедурный, и в нем легче разобраться ? оок.

Ну да — в процедурах легче разобраться, чем в ООП. На самом деле в гоу есть все необходимое для ООП — структуры, к которым можно привязывать методы и супер-классные интерфейсы (об интерфейсах ниже).

А монады в нем есть? или все делаеться аля старый добрый це, с 100500 функций для каждого типа данных, и возвращаемым кодом ошибки из функции ?

Трихомонад нет. И это здорово — матан не совместим со среднего уровня программистами, для которых спроектировали гоу! Еще в гоу нет конструкторов с деструкторами.

А подробнее ?

В коде гоу не нужно перечислять все интерфейсы, которые реализует данная структура (ака класс). Считается, что структура реализует интерфейс, если у нее есть методы данного интерфейса. Например, все экземпляры структур с методом Write(p []byte) (int, error) можно передавать в качестве аргумента, объявленного как io.Writer (такой интерфейс с одним методом, указанным выше). Кроме того, интерфейсы можно объявлять в любом месте кода (ака inline). golang.org/...ective_go.html#interfaces

Тобиш сторонние либы нельзя подключить совсем ?

Можно, но они по умолчанию статически линкуются в один бинарник.

Пруф линки на тесты ?

У нас в продакшне сейчас сервер на гоу держит до миллиона одновременных подключений. Каждое подключение обрабатывается отдельным потоком.

Тобиш дебагера нету ?

В стандартной поставке гоу нет, т.к. в нем нет необходимости. Есть сторонние дебаггеры для желающих писать в стиле жава на гоу (к сожалению, такие индивидуумы встречаются довольно часто).

Пока сочинял ответ, вспомнил еще пару преимуществ го перед жавой:

12. Тесты на гоу писать не просто, а очень просто. golang.org/pkg/testing . Не нужно устанавливать дополнительный софт, не нужно заморачиваться с настройками окружения и xml конфигами — тесты лежат рядом с исходниками.

13. Бенчмарки на гоу писать не просто, а очень просто. Ссылка все та же — golang.org/pkg/testing .

14. Профилировщик гоу по CPU, выделяемой памяти и по блокировкам встроен в рантайм. Поэтому оптимизировать программы на гоу — одно удовольствие. blog.golang.org/profiling-go-programs

15. Генератор документации из исходников поставляется искаропки. И никакого xml-я. blog.golang.org/...godoc-documenting-go-code .

16. Код стандартной библиотеки на гоу понятен даже школьникам из мира ПХП, в отличие от кода стандартной библиотеки для жавы. См. golang.org/src .

17. Полная спецификация гоу короче спецификации жавы раз в 100. golang.org/ref/spec .

18. В компиляторе гоу нет ворнингов — есть только ошибки. Поэтому код на гоу всегда компилируется без ворнингов.

19. В гоу встроен стандартный форматировщик кода. Поэтому код на гоу легко читается в одном стиле, не зависимо от того, кто его написал.

20. Функции в гоу могут возвращать произвольное количество значений, а не одно, как в жаве.

21. Программа на гоу запускается мгновенно, в отличие от программы на жаве, которая раздупляется в лучшем случае через пару секунд после запуска.

оно еще и компилится мгновенно, а скала тормоз

16. Код стандартной библиотеки на гоу понятен даже школьникам из мира ПХП, в отличие от кода стандартной библиотеки для жавы. См. golang.org/src .
Я в недоумении — учил Java как раз по сорцам стандартной библиотеки (Collections Framework, Java IO, ...). Вы могли бы указать на сложные куски?

Местами таки есть непростое для чтения.
Например:
java.util.concurrent.ForkJoinPool

Местами таки есть непростое для чтения.
Например:
java.util.concurrent.ForkJoinPool
Это, да.
Но, полагаю, в любом языке программирования
— предельно оптимизированный
— системный код для работы с многопоточностью
выглядит аналогично.
-
Если в Go легко создать корутину, то и в яве легко создать поток
new Thread(() -> System.out.println("Hello!")).start();

Сравните создание потока в жаве с гоу:

new Thread(() -> System.out.println("Hello!")).start();

Vs

go fmt.Printf("Hello")

Где проще?

Проведите для полноты картины аналогичный код для жавы ниже восьмой версии — ведь сейчас 95% жава проектов не используют Java 8.

Где проще?

Слово «проще» надо рассматривать не только с точки зрения написания собственно символов кода из множества unicode, но и в специфике полного цикла разработки, когда отлаживать у программиста в 10 раз дороже, чем писать код, у QA — в 10 раз дороже, чем у программиста, а диагностировать и отлаживать у пользователя в 100 раз дороже, чем у QA.

Поэтому проще — в яве. В Go неизвестно, что произошло на самом деле, породилось что-то или нет и на какой фазе оно упало.
Если горутина должна была что-то отдать в результате своей работы, то у вас нет возможности проверить, как она завершилась, без таймаута ожидания на channel’е или поллинга счётчика наблюдаемых горутин. Оба варианта непригодны для практической работы — не обеспечивают эффективный и даже просто надёжный контроль результата (таймаут может быть из-за того, что до выполнения банально не дошли из-за перегрузки...)

На самом деле, конечно, в обоих не совсем хорошо — если говорить о порождении процесса — асинхронного исполнителя, то лучше всего в Erlang:

Pid = spawn(fun() -> io:fwrite("Hello!~n") end)

тут и выдаётся внутренний pid исполняющего процесса, и исключение, если что-то не то (а исключения — ещё одно то, что авторы Go ниасилили), и на несколько слов меньше, чем в Java. Но Java при своём многословии даёт диагностируемую среду исполнения, а Go — нет, язык с такими свойствами пригоден только для поделок, надёжность которых никого не интересует.

Поэтому проще — в яве. В Go неизвестно, что произошло на самом деле, породилось что-то или нет и на какой фазе оно упало.

Не понял, что должно упасть? Если код, исполняемый в потоке, то если он выполнит недопустимую операцию типа выход за границы массива или разыменование нулевого указателя, то по умолчанию вся программа на гоу свалится со стэктрейсом. Это помогает говнокодерам оперативно исправлять свой код. В жаве же, насколько я помню, по умолчанию стэктрейс потока будет записан в лог (если он включен), а программа продолжит выполняться. И говнокодер может очень долго не догадываться о багах в своей программе, пока она будет глючить и бесить юзеров в продакшне. Отличное поведение по умолчанию!

Если горутина должна была что-то отдать в результате своей работы, то у вас нет возможности проверить, как она завершилась, без таймаута ожидания на channel’е или поллинга счётчика наблюдаемых горутин

Не совсем понимаю, о чем вы. Можете привести код соответствующий на java?

тут и выдаётся внутренний pid исполняющего процесса

Для чего использовать этот pid в гоу?

и исключение, если что-то не то (а исключения — ещё одно то, что авторы Go ниасилили)

«исключения, если что-то не то» в гоу есть — golang.org/pkg/builtin/#panic . Они используются, когда программист написал говнокод, который делает что-то не то — выход за границы массива, чтение из закрытого channel’а, передача в функцию неожиданных аргументов, разыменование нулевого указателя и т.д. А вот исключения, используемые для сигнализации о заранее предусмотренной ошибочной ситуации («нет файла», «нельзя подключиться к серверу», «ошибка чтения из сокета») в гоу отсутствуют. Т.к. такие ошибки должны обрабатываться в месте вызова функции, в которой возникла эта ошибка, а не ловиться глобальным эксепшн хэндлером, чтобы быть записанной в лог (если он включен).

Но Java при своём многословии даёт диагностируемую среду исполнения, а Go — нет

Не совсем понимаю, что такое диагностируемая среда выполнения. Можете пояснить на примерах из Java?

Чтобы долго и много не писать — спасибо, я понял. Позиция апологета Go состоит в том, что программа целиком (всеми тредами/горутинами/etc.) падает по любой ошибке программиста, и это преподносится как достижение по сравнению с Java. У меня больше вопросов нет.

Вы правильно описали мою позицию. Для апологетов жава-стиля обработки ошибок (пустые catch’и и/или утаивание багов в недрах глобального эксепшн хендлера) гоу предоставляет такую возможность — defer recover().

Вы правильно описали мою позицию.

Это грустно.

Для апологетов жава-стиля обработки ошибок

Почитал. Самое смешное, что это и есть обработка исключений, только дорогая, скрытая и ущербная, у которой обрубили все конечности.

Теперь я ещё больше в недоумении, зачем строить кривых инвалидов, когда вся отрасль уже отработала в мельчайших деталях правильные механизмы.

Эээ ...
Я вижу на Java множество мелких понятных методов и javadoc, который составляет 80% по объему.
Может пропустил, но сложного кода не вижу.

В исходниках File на гоу тоже есть документация. Понятная и лаконичная. Как и код. В жаве же качество документации также соответствует качеству кода — много воды и не по делу.

21. Программа на гоу запускается мгновенно, в отличие от программы на жаве, которая раздупляется в лучшем случае через пару секунд после запуска.
Минимальный HelloWorld на Java отрабатывает за 30мс (при хороших настройках). Медленный старт при подключении большого кол-ва фреймворков + большом объеме инициализации (прогрев кэша данными из базы, ...) - но это следствия не языка, а архитектуры проекта. Если он здоровенный и вы подключили 100500 специализированных библиотек — то дело не в языке.

Go так и останется уделом хипстеров и «стартаперов» (не путать со стартаперами (без квычек)), если его будут продвигать вот такие фанатики, которые не то что не видят недостатков, а выдают их за преимущество

Перечислите недостатки из моего списка преимуществ гоу перед жавой. А не то я не вижу ни одного

Если вам нравится писать в виме это не преимущество, а недоразвитость go для которого за столько лет еще не сделали нормальную IDE с дебагером. Еще вопрос что проще — научить новичка писать на скале в intellij или на go в виме (имеется ввиду реальные проекты, а не hello world).

Если вам нравится if err != nil { .. } через строчку вместо эксепшинов, называйте это «своим, альтернативным подходом к обработки ошибок», но никак не преимуществом. Хоть я и сам не любитель ексепшинов.

Если вам нравится копипастить коллекции для каждого типа, флаг вам в руки, но не называйте это преимуществом.

Не нравится ООП? Не называйте отсутствие оного преимуществом.

и т.д., и т.п.

Отсутствие чего либо никак не может быть преимуществом, это ограниченность. Проще? Однозначно да. Но, простым средствам, простые проекты. Java, .NET превратились в монстров не от хорошей жизни.

PS Действительно секта какая-то, не поверишь пока сам не столкнешься.

Если вам нравится писать в виме это не преимущество
в виме (имеется ввиду реальные проекты, а не hello world).
блин, я наивный думал, что Vim считается редактором для продвинутых программеров, а оказывается это редактор для хэллоувордов))))
оказывается это редактор для хэллоувордов
Так и есть.

www.youtube.com/watch?v=e-p35Z3Z7DI

Псих какой-то скачет по сцене и что-то вопит. Не хватает воплей «developers, developers, developers».
Лучше следуйте примеру нашего настоятеля в выборе инструментов разработки — usesthis.com/interviews/rob.pike .

Роб Мартин? Один из авторитенейших людей в мире разработки. Ты когда-нибудь про SOLID слышал?

SOLID — это то, как не надо писать код? Предпочитаю KISS ( en.wikipedia.org/wiki/KISS_principle ).

Я считаю вим редактором для задротов или тех кто ностальгирует по древним временам айти.

ну... каждому свое) но то, что на подавляющем большинстве удаленных серваков кроме vi (ну и может еще nano) обычно хрен что встретишь из редакторов — факт (насколько я знаю).

так что знание хотя бы основ vi/vim может пригодиться (хоть раз в жизни).

Хотя... если сервак твой собственный ты можешь накатить на него любой редактор — все, что твоей душе угодно)

Да, базово знать надо, но не обязательно же программировать через него. Хотя с ним и можно прямо по ссх фигачить. Лично я юзаю тестовый домен на сервере и нетбинсом через фтп правлю. Еще вариант выкачать себе на локалку гитом.

так я ж и не говорю. что надо обязом в нем кодить)
хотя есть надстройка над вимом — Cream, которая делает из вима ну почти обычный редактор (т.е. с одним режимом ввода и привычным простому смертному управлением).
Хотя труЪ вимеры на Cream наверное ругаццо будут))

Не нравится ООП? Не называйте отсутствие оного преимуществом.

В гоу ООП встречается на каждом шагу, начиная от стандартной библиотеки — см. golang.org/pkg и заканчивая 95.7% всех сторонних библиотек и программ на гитхабе — см. github.com/...ies&ref=advsearch&l=Go&l= .
Если вы не знаете, что такое ООП, то это не значит, что ее нет в гоу.

Если вам нравится писать в виме это не преимущество, а недоразвитость go для которого за столько лет еще не сделали нормальную IDE с дебагером

Да, мне нравится писать в виме. Не только на гоу, но и на остальных языках программирования, с которыми я сталкивался, за исключением жавы (для нее пришлось пересесть на эклипс, т.к. в виме надоело набирать 100500-символьные строчки). Не пойму, как это связано с недоразвитостью гоу.

Насчет IDE и дебаггеров под гоу — они есть (где-то тут уже проскакивали ссылки на них). Просто для разработки большинства проектов на гоу эти костыли не нужны.

Если вам нравится if err != nil { .. } через строчку вместо эксепшинов, называйте это «своим, альтернативным подходом к обработки ошибок», но никак не преимуществом.

Да, никому не нравится писать обработку ошибок, в т.ч. и мне. Ведь это скучно и уныло — лучше это время потратить на разработку новой хипстерской фичи :) Но гоу, в отличие от java, настойчиво просит программиста — «не ленись — пиши нормальную обработку ошибок, please!!!».

Если вам нравится копипастить коллекции для каждого типа, флаг вам в руки, но не называйте это преимуществом.

Да, пару раз копипастил коллекции на 10-30 строчек для разных типов. Но это было пару раз за 100500 лет разработки на гоу и меня это особо не парило :)

Насчет IDE и дебаггеров под гоу — они есть (где-то тут уже проскакивали ссылки на них). Просто для разработки большинства проектов на гоу эти костыли не нужны.
Ну да, мегаязык Go так крут что тупую ошибку по запарке в нем сделать просто невозможно, и даже если вдруг сделаешь, то найти ее в 100К строк кода _очень_ легко при помощи глаз:)
И да, мне всегда казались странными люди, которые отказываются от инструментов, повышающих производительность, и страхующих от ошибок (это я про IDE) :)
Не, ну можно конечно понять человека, который 20 лет в Vim сидел потому как ничего лучше тогда не было, и теперь он не в силах перебороть свой консерватизм:)
Ну да, мегаязык Go так крут что тупую ошибку по запарке в нем сделать просто невозможно, и даже если вдруг сделаешь, то найти ее в 100К строк кода _очень_ легко при помощи глаз:)

Хм, когда это IDE научились находить баги за программистов?

И да, мне всегда казались странными люди, которые отказываются от инструментов, повышающих производительность, и страхующих от ошибок (это я про IDE) :)

Я думал, что такими инструментами являются язык программирования и его компилятор. IDE — это костыль для посредственных языков с компиляторами.

Хм, когда это IDE научились находить баги за программистов?
во-первых IDE уменьшают вероятность ошибки, ровно тех пор как в них появилась поддержка проверки синтаксиса на лету и статический анализ
Resharper/PVS-Studio/etc ?
не, не сылшали
Я думал, что такими инструментами являются язык программирования и его компилятор. IDE — это костыль для посредственных языков с компиляторами.
вообще-то основным инструментом являются мозги,
но кмк, лучше не тратить время на то, что за тебя может сделать инструмент, а сосредоточиться на том, что он сделать не сможет.
зы. Профайлеры тоже, я так понимаю, нафиг не нужны?:)
зы. Профайлеры тоже, я так понимаю, нафиг не нужны?:)

Профайлер встроен в гоу — blog.golang.org/profiling-go-programs .

По ссылочке прошел, и увидел что для профайлинга надо еще код править:)
Не, ну на дотнете при желании можно то же самое делать, только зачем, если есть _нормальное_ средство визуализации, без написания кода и command line hell’a? особенно зачотно выглядят порванные диаграммы:)
Такой профайлер был бы оправдан лет 15-20 назад, сейчас же это вызывает только жалость и недоумение...

По ссылочке прошел, и увидел что для профайлинга надо еще код править:)

Для профилирования тестов и бенчмарков код править не нужно — там есть для этого специальные command line флаги.

Для встраивания профайлера в программу достаточно добавить одну стрчоку кода (импортировать пакет net/http/pprof) — golang.org/pkg/net/http/pprof . После этого программу можно профилировать в продакшн по сети онлайн в любое время.

там есть для этого специальные command line флаги
welcome to command line hell:)
Для встраивания профайлера в программу достаточно добавить одну стрчоку кода (импортировать пакет net/http/pprof) — golang.org/pkg/net/http/pprof . После этого программу можно профилировать по сети онлайн в любое время.
Ну это от убогой неинтерактивной визуализации на уровне gnuplot не спасает
Для сравнения поставьте VS свежую и посмотрите как профайлер реализован там, вдруг захочется работать в нормальных условиях?;)
welcome to command line hell

Что-то не гуглиццо в отличие от jar hell, callback hell, dll hell.

Ну это от убогой неинтерактивной визуализации на уровне gnuplot не спасает

Вроде основное назначение профайлера — обнаружение top1-3 узких мест в программе. Для визуализации этой информации достаточно трех строчек в консоли. Ну и еще желательно посмотреть аннотированные исходники с этими top1-3 узкими местами, чтобы лучше понять, куда дальше копать. go tool pprof с этим прекрасно справляется без лишнего информационного шума в виде графической визуализации, да еще красивой, да еще интерактивной. Нафиг-нафиг.

Для сравнения поставьте VS свежую и посмотрите как профайлер реализован там, вдруг захочется работать в нормальных условиях?;)

Помню приходилось дебажить программы на C# под VS. Графический интерфейс, конечно красивый и приятный, но не идет ни в какое сравнение по эффективности использования с консольной WinDbg. Думаю, то же самое касается и профайлеров.

Вроде основное назначение профайлера — обнаружение top1-3 узких мест в программе. Для визуализации этой информации достаточно трех строчек в консоли. Ну и еще желательно посмотреть аннотированные исходники с этими top1-3 узкими местами, чтобы лучше понять, куда дальше копать. go tool pprof с этим прекрасно справляется без лишнего информационного шума в виде графической визуализации, да еще красивой, да еще интерактивной. Нафиг-нафиг.
классический случай нежелания перестраиваться для повышения собственной продуктивности:)
этот самый «информационный шум» позволяет с гораздо большей скоростью установить узкие места, позволяет в наглядном виде сравнить n профайлерных сессий, дабы понять какой вариант лучше и т.п.
Помню приходилось дебажить программы на C# под VS. Графический интерфейс, конечно красивый и приятный, но не идет ни в какое сравнение по эффективности использования с консольной WinDbg. Думаю, то же самое касается и профайлеров.
сразу видно матерого линуксовода:)
как насчет в 2-3 клика мышой за 1-2 секунды посмотреть что там во внутренностях объекта и поменять его стейт? имхо коммандлайн если такое и позволит, то это точно будет не так быстро и удобно
зы. командная строка, это хорошая штука, но для админов
для разраба это лишние телодвижения, на которые время тратится
я уж не говорю о различиях в функциональности
ззы. этот тред уже попахивает холиваром, пора заканчивать...
хотя топикстарстер кажется этого и хотел:)
IDE — это костыль для посредственных языков с компиляторами.

т.е. раз LiteIDE github.com/visualfc/liteide и GoClipse github.com/GoClipse/goclipse позициониру.тся как IDE для Go, то получается это — «костыли для посредственного языка» ))

еще для хаскеля есть своя собственная IDE (Leksah) — значит хаскель тоже посредственный язык получается))

походу для Эрланга кроме плагинов для IDEA, Eclipse и Emacs своей IDE-шки вроде нету (видел разве что какой-то простецкий редактор для эрланга написанный на самом эрланге, но то такое :) )

P.S. вот для какого языка я вообще не видел никакой IDE так это для Standard ML (для него кажеться даже плагинов для IntelijIDEA и эклипса нет). :)

P.P.S. а вообще IDE vs Vim — это ИМХО холивары из серии «мне яблоки не нравяться — я люблю груши».

т.е. раз LiteIDE github.com/visualfc/liteide и GoClipse github.com/GoClipse/goclipse позициониру.тся как IDE для Go, то получается это — «костыли для посредственного языка» ))

Есть спрос — есть предложение. Но факт остается фактом — на Go, в отличие от Java, можно продуктивно кодить хоть в notepad.

на Go, в отличие от Java, можно продуктивно кодить хоть в notepad.
ну это да — в блокноте для джавы или сишарпа особо не покодишь)

ну и у джавы и сишарпа так исторически сложилось, что для их изучения в большинстве случаев изначально рекомендуют какую-либо IDE (в отличие, например, от пхп, для изучения которого и применения которого что хватит просто редактора с подсветкой а-ля нотпад++).

Для джавы — либо эклипс, либо Идею (хотя есть дохрена других редакторов, которые по-моему вполне позволяют писать для джавы), Для сишарпа — вижуал студия (в последнее время — еще моно-девелоп для юниксов). И юзать что-то другое для этих языков по-моему у многих джавистов и сишарперов считается дурным тоном...
Даже для питона вроде делают стандартом применение PyCharm, несмотря на то, что для питона есть несколько ИМХО вполне кошерных редакторов и IDE (я вообще для мелких скриптов на питоне люблю иногда юзать консольный Joe’s Own Editor, его же юзал, когда смотрел основы Go).

З.Ы. а принцип «для го не нужен редактор/иде» считаю просто причудой Роба Пайка (если ему не нужна подсветка и прочие ништяки — это еще не значит, что это вообще не нужно).

я сча для джавы юзаю c9.... это ужос...

ну я не джавист, поэтому насчет того, какие иде (помимо эклипса и идеи) кошерны не в курсе)
а с9 подозреваю, что для джавы таки ужос)

P.S. вот для какого языка я вообще не видел никакой IDE так это для Standard ML (для него кажеться даже плагинов для IntelijIDEA и эклипса нет)
Есть для emacs

полноценное (ну там с автокомплитом, интеллисенсом, дебаггером и прочими ништяками)? просто я не емаксер, посему не в курсе)

С REPL ;) Тоже не особо емаксер, но когда изучал SML, хоть что-то было только в emacs

а что насчет автокомплита по функциям и т.п. ? или только репл добавляет?

просто с плагином для SML, реализующим REPL, я знаю редактор Enki enki-editor.org/features.html , но там вроде кроме репла других ништяков он вроде не добавляет.

Насколько я помню — только репл, форматирование и указание ошибок компиляции

Действительно секта какая-то, не поверишь пока сам не столкнешься.
 да тут у каждого по своей секте: javascript секта, php секта и т.д.

Я так и не смог определить, какого же смайлика не хватает вашему сообщению. Тут нужен настоящий художник в стиле Эдварда Мунка...

1. Код на гоу можно писать в виме. Для жавы нужна IDE с автокомплитом, которая обычно кушает память, тормозит и еще бывает платной. Поэтому гоу разносит в пух и прах жаву с экономической точки зрения.

Вы всерьез считаете, что экономическая целесообразность использования того или иного языка программирования определяется стоимостью IDE?

Да о чём спорить, это же типичное «сегодня нету потребности в колбасе».

Если у CTO в обойме 200 скалистов, причем половина из них матерные функциональщики, есть проект на скале, как-то неразумно вдруг переписывать все на go набирая школьников изучивших go на выходных или переучивая скалистов, не находите? Да и вообще, скаллист, тем более матерный функциональщик сделавший downshift в сторону go, звучит как что-то из области фантастики.

Я не спорю что возможно это действительно имело место быть, но причины были более веские чем то, что несколько матерных скалистов не смогли понять код, написанный другим матерным скалистом.

Он явно что-то недоговаривает в статье.

Я не спорю что возможно это действительно имело место быть, но причины были более веские чем то, что несколько матерных скалистов не смогли понять код, написанный другим матерным скалистом.

Если бы вы были CTO быстро развивающейся компании из 200 человек и перед вами стоял выбор:

1) Продолжать разбираться в скала коде, написанном «матерыми скалистами» (таких уместнее называть говнокодерами, раз в их коде не могут разробраться «матерые функциональщики») и терять позиции на рынке разным хипстерам-школьникам, пишущим на гоу (т.к. они выкатывают полнофункциональную версию софта в 10 раз быстрее). В итоге разориться и жить на пособие по безработице оставшуюся жизнь, т.к. такой горе-CTO больше никому не нужен.

2) Перейти на гоу и уделать всех этих школьников-стартаперов, т.к. 200 «матерых функциональщиков» по определению умнее школьников, поэтому смогут быстрее выкатывать новые фичи с меньшим количеством багов. В итоге заработать 100500 миллиардов баксов, выйти на IPO и стать богаче Билла Гейтса.

Что бы вы выбрали? Только будьте честны перед собой.

Перейти на Java+Python и уделать иеговистов :)

Перейти на Java+Python и уделать иеговистов :)

Любите извращения? Жаву уместнее скрещивать с nodejs, scala или на худой конец с clojure. А python’у лучше подойдет спаривание с Go, т.к. в их идеологии много общего.

Любите извращения?

Нет, чтобы работало.

А python’у лучше подойдет спаривание с Go, т.к. в их идеологии много общего.

Я не думаю, чтобы идеология «Х-Х и в продакшн» была движущей в Питоне.

Вообще-то идеология Go и Python — KISS.

Продолжать разбираться в скала коде, написанном «матерыми скалистами» (таких уместнее называть говнокодерами, раз в их коде не могут разробраться «матерые функциональщики»)
Вы
1) не правы
2) обсуждаете статью даже не прочитав ее
---
1) Не правы потому, что функциональтный код и гуанокод — это совершенно разные вещи. Да, обе доставляют боль, но это как сравнивать управление сверхзвуковым истребителем и дедовской тачкой с отваливающимся колесом. И говорить — и тачка и истребитель — фигня, вот велосипед Украина — рулит.
2) в статье говорится о двух лагерях авторов на Scala. И вот те, для которых Scala == Java++ не могут читать код тех, для которых Scala == Haskell on JVM.
Да, обе доставляют боль, но это как сравнивать управление сверхзвуковым истребителем и дедовской тачкой с отваливающимся колесом.

Тут уместнее сравнение запутанной псевдонаучной ахинеи (говнокод) с крутой научной работой по матану. Оба варианта — мало чем отличающаяся китайская грамота для большинства программистов. Если во втором варианте наборщик текста ошибается хотя бы в одном символе, то научная работа превратится в говнокод, но этого никто не заметит, включая автора этой работы.

То есть в говнокоде (если таков действительно был) виновата скала и перейдя на go те же программисты при том же СТО вдруг начнут писать совершенный код?

Говнокод в первую очередь это плохой дизайн. Ты можешь ясно понимать каждую строчку программы (и бесспорно go тут имеет явное преимущество), но соединить все воедино, уловить смысл, ты не можешь. Ничто не мешает на go напедалить мутабельные функции с 10+ аргументами и 5-ма вложенными циклами. Более того, императивный, даже я бы сказал антифункциональный подход в go, только провоцирует на написания говнокода.

Более того, императивный, даже я бы сказал антифункциональный подход в go, только провоцирует на написания говнокода

К сожалению, практика доказывает обратное. Матан с функциональщиной не пройдет!

Какая практика, где?

Функциональщина тоже разная бывает, так что не надо впадать в крайности. Есть прикладная с чистыми фунциями, трейтами, паттерн матчингами, монадами, и т.д., а есть академическая с «матаном». Никто не заставляет учить матан и тащить его в проект, более того, это удел упорытых функциональщиков и разработчиков библиотек, как той же scalaz. Но, собственный опыт показывает что без этого можно спокойно жить.

Есть прикладная с чистыми фунциями, трейтами, паттерн матчингами, монадами

Объясните в двух словах, что такое монада, чтобы программистов-императивщики поняли ее смысл с назначением.

«Упаковка» значения в некоторый контекст («коробку») + удобные способы композиции. Исключительно практическое применение — контроль «побочных эффектов» (что бы последним не называлось).

Классический пример использования — есть функция, которая делит два числа. Что делать, если попался ноль? Возвращать «null» — неправильный ответ, при оговорке, что обсуждаемый ЯП создавался «с чистого листа» (надеюсь, тут споров не будет). Я знаю три более-менее работающих способа (все со своими плюсами, минусами и границами применимости), это 0) Null Object Pattern 1) исключения и 2) некоторая «обертка», в которой либо есть результат (и с ним можно работать вне «обертки», как с обычным обьектом), либо нет. Последнее, вместе с методами-для-работы-с-ним, и есть «монадой». В чем плюсы конкретно этой «монады» — гарантированная (на уровне компилятора) проверка содержимого, и, главное, улучшение семантики кода — явное указывание, что вот этот аргумент может отсутствовать.

Еще важный плюс в том, что методы работы с этой «оберткой-монадой» совпадают с методами работы с любой другой монадой. Как практическое следствие, очередное понижение «энтропии кода» и значительное повышение читабельности.

Я знаю три более-менее работающих способа (все со своими плюсами, минусами и границами применимости), это 0) Null Object Pattern 1) исключения и 2) некоторая «обертка», в которой либо есть результат (и с ним можно работать вне «обертки», как с обычным обьектом), либо нет

Есть еще один способ — возвращать два значения — результат деления и объект-ошибку, как это принято в Go.

А вообще, спасибо за лаконичное и понятное объяснение, что такое монада и как она упрощает код.

Как я раньше и говорил, имеет право на жизнь. Но вот если представить более сложную ситуацию, когда нужно из базы что-то взять, потом сделать API вызов, распарсить результат, положить назад в базу — код с этими проверками становиться слишком громоздким и плохо читаемым. С монадами все просто — в базе ничего не нашли, последующие функции просто не применяются.

Монады конечно тоже не подарок, особенно когда функции возвращают разные монады и надо их неявно или явно трансформировать, но когда представляешь этот же код с ексепшинами или ГОшным стилем, понимаешь что это не самый плохой вариант.

Более того, императивный, даже я бы сказал антифункциональный подход в go, только провоцирует на написания г@внокода.

императивный подход сам по себе врядли может провоцировать на написания г@внокода)
ну и в го насколько мне известно есть некоторые вещи, взятые из функционального программирования.

А вот написание г@внокода провоцирует не язык, я подход к его изучению и применению — вот в пхп по-моему до сих пор дохрена г@внокода пишут потому, что многие привыкли, что пхп код можно впихивать в хтмл и оно будет работать и не надо париться над такими «страшными» вещами как MVC.

А у go разве не такой же подход? Ху*к, ху*к и в продакшн а после этого хоть потоп.

я о том, что язык (пхп, да и го наверное) позволяет делать это самое «ху*як-ху*як», не заботясь о структуре и т.д. проекта. Но ведь на пхп можно писать продуманный качественный код. Вот и на Go думаю можно. А подход «х*як-х*як и в продакшн» думаю наверняка можно к любому языку применить (хоть к джаве, хоть к скале, хоть к сишарпу) — главное чтобы работало и компилятор не ругался)

Если у CTO в обойме 200 скалистов, причем половина из них матерные функциональщики, есть проект на скале, как-то неразумно вдруг переписывать все на go набирая школьников изучивших go на выходных или переучивая скалистов, не находите?
Скалистам нужно кучу бабла платить, школьникам можно не платить — профит.
Сказать «деньги закончились» чувак не может, вот и выдумал причину.

без РеалитиХацкера тема не взлетит, нету накала.

вот тоже самое интересует — куда пропал человек

Видимо, сходил с кем-то на сходку порешать у кого процессы легковеснее и его аргументы оказались слабее...

да, могли поймать в реале и просто убить.
в Америке то.

а может надоело просто и нашел новую площадку для дискуссий

я пошутил ))
наверно да, -ему тут надоело с 23-летней элитой спорить.

Я не знал что он в Америке. Тогда все просто: развлекается где-то с мыщъ.

вот мыщъ это наверно единственный чувак с rsdn которого я бы был рад видеть тут

Это да. Но он не то чтобы «с рсдн». Он подтусовывается там — он же вообще интернет-экстраверт. Еще до рсдн он присутсвовал на других площадках (wasm32 вроде), я его много где встречал. Так что на рсдн он больше случайный чувак. А вот завсегдатаи с рсдн — это ад.

ну у нас сильно не пересекающиеся интересы так что я его строго по рсдн помню
у него интересно блога нет? а то жег он немилосердно, почитал бы

У него бложиков тоже было дофига и больше, но обычно там 2-3 поста и он его забрасывает и где-то открывает новый. И так далее.

nezumi-lab.org — ну вот вроде последний, но там уже давно апдейтов нету, так что наверное или вообще забил, или еще где-то новый завел :)

n2k.me — это вот более старый

почитав его блоги становится понятно, почему программеры так озаботились поиском реальных девушек.
Дело в том, что на порносайтах не менее опасно чем в реале.
А хранение порнухи чревато криминалом (в Украине, по крайней мере)

а его любимые спарринг -партнёры где?
напомните кто там с Хацкером любил сразиться?

не путайте спарринг-партнёра и макивару.
Вовка интеллектом не вышел с Хацкером тягаться

АПД:
а топик -то взлетел.

да спасибо упоротости гошников — страсти не стихают

упоротости джавистов спасибо ) я там одного товарища попросил простенький код написать — вот чисто для сравнения, без подвоха. ответил, что код слишком простой и писать не будет. может кто другой согласится?

да спасибо упоротости гошников — страсти не стихают
упоротости джавистов спасибо )

спасибо упоротости обеих сторон)

срач Go vs. Java/Scala читать по крайней мере полезнее и приятнее, чем какой-нибудь политстрач)

говорят, порог входа в Go не сильно высокий.
нету риска, что их начнут называть Go-пниками?

если судить по комментариям тут скоро будет правило ГЗН

А ты чегото Вовку невзлюбил )

неа, Igor Petruk любил попинать Хацкера.

тоже посматриваю в сторону Скалки, чисто ради фана, ну а может и не только. На курсере есть два неплохих курса, один по основам ( www.coursera.org/course/progfun ), другой по реактивной Скале ( www.coursera.org/course/reactive ), как пройду — отпишу, асилил или ниасилил)

Що не кажи а повільний білд скали+заповільнена підсвітка коду в intellij реально напрягає.

обновите интелиджей или комп :) на маке с 16 гигами все ок ;) и ителией 15й

16 Гб памяти для подсветки синтаксиса?

Со scala не может справиться не только среднестатистический программист, но и макбук, если в нем меньше 16ГБ оперативки. Видно сразу — scala идеально подходит для разработки больших проектов.

для начала стоило бы самому поставить скалу и интелидж и посмотреть, а потом только делать провокационные заявления:)
по факту на i3 4Гб оперативы работать вполне комфортно

Спасибо, vim’у достаточно 640КБ для продуктивной правки кода на Go.

продуктивной?:)
спасибо, я помню что такое vim, за 20 лет воспоминания не изгладились:)

Можно подробнее про впечатления? У меня за последние 10 лет программирования в vim впечатления в основном положительные (за исключением программирования на java — в этом случае вим может понравиться только графоманам. Но это не проблема вим, а недостаток жавы).

говоря коротко — жесть
если более развернуто — то более идиотский подход к реализации текстового редактора надо еще поискать, впрочем ноги то из vi растут, оттуда же тянутся кошмарные сочетания клавиш для навигации по текст, копирования, вставки, и т.п.
не, я знаю что там можно все настроить, но нафига мне обрабатывать напильником древнюю как гуано мамонта софтину, вместо того чтобы просто работать
на тот момент даже первая VS и дельфа давали много очков вперед
да и собственно под линухом тогда что-то коммерческое писать не имело смысла
поэтому вим вместе с линухом отправился в мусорку

кошмарные сочетания клавиш для навигации по текст, копирования, вставки
Это какие именно? Вроде как очень даже логичные:
paste
yank
delete
jkhl — навигация — вообще классика, перекочевавшая даже в веб

они _были_ логичными для терминалов конца 70-х начала 80-х
т.к. там зачастую клавиатуры были без дополнительного блока справа (PgUp/PgDown/Home/etc), и использовавшие ctrl в служебных целях
при наличии нормальной клавы эти костыли (вот тут слово «костыли» как раз уместно) стали не нужны:)
вот тут вступают в игру два самых неприятных фактора в юниксовом мире:
— дикий легаси код, зачастую еще с 70-х, когда железо было гораздо слабее и стоило на порядки дороже
— общая идеология которая лучше всего описывается сравнением совковых автомобилей и всех остальных (под советским больше лежишь с ключами чем ездишь)

при наличии нормальной клавы эти костыли (вот тут слово «костыли» как раз уместно) стали не нужны:)

s/нормальная клава/графический терминал/
и там, да, полно других редакторов. А вот под текстовый терминал, включая удалённый на остров Разочарования через два спутника, модем на 2400 и три screen/tmux — альтернатив нет и, скорее всего, не будет.

— дикий легаси код, зачастую еще с 70-х, когда железо было гораздо слабее и стоило на порядки дороже

vim написан с нуля, в нём нет этого лигаси.

— общая идеология которая лучше всего описывается сравнением совковых автомобилей и всех остальных (под советским больше лежишь с ключами чем ездишь)

Стандартное штампованное сравнение не в тему.

А вот под текстовый терминал, включая удалённый на остров Разочарования через два спутника, модем на 2400 и три screen/tmux — альтернатив нет и, скорее всего, не будет.
это не повод во времена гигабитных каналов использовать устаревшее на десятилетия ПО и подходы
vim написан с нуля, в нём нет этого лигаси
да ну?:)
первый релиз 91 год
и да, стандартные юниксовые/линуксовые либы — это и есть дикое легаси, т.к. они навязывают определенные шаблоны
Стандартное штампованное сравнение не в тему
может оно и «штампованное» для кого-то , но я его очень хорошо ощутил в свое время на собственном опыте. Человеку который не ездил на древнем москвиче или жиге и после этого пересел на японца/немца/etc этого не понять:)
и да, стандартные юниксовые/линуксовые либы — это и есть дикое легаси, т.к. они навязывают определенные шаблоны

Какие именно шаблоны? Прошу подробнее. (После этого можно будет и к остальным выдвинутым тезисам подобраться.)

оттуда же тянутся кошмарные сочетания клавиш для навигации по текст, копирования, вставки, и т.п.
а это тянется с тех времен, когда клавы другие были и некоторые клавиши на этих клавах по другому располагались. ;) (и тогда vi-шные комбинации клавиш было самое то)

з.ы. а вообще насколько мне известно в конфиге вима можно свои хоткеи прописать)

если в нем меньше 16ГБ оперативки.
это если поставить IDEA со всеми плагинами, насколько я понимаю)
если же взять какой-нибудь простой редактор с подсветкой и отлаживать/компилить в консольке, то думаю и слабый комп вполне потянет) а вот потянет ли программер писать на скале в notepad++ - вот в чем вопрос)))

для подсветки синтексиса есть текстовые редакторы, можете погуглить что такое IDEA и зачем они и какой от них толк. А так да, можно принтэфами дебажить код ;)

В vim тоже есть подсветка синтаксиса. Зачем мне IDEA?

ну так я о чем. Можно и руками рыть яму для фундамента, можно взять полезные тулзы типа лопаты, а можно использовать экскаватор. В итоге все равно один и тот же результат, но... ;)

Мне кажется, вы не сильно понимаете как добрая половина программистов всего мира программирует в vim-е и почему :) Сравнивать vim с «рыть руками» — как-то ну совсем странно.

Если вам в джаве чтобы вообще сделать шаг влево-вправо нужен мощный IDE со специальным рефакторингом и без этого никак — так и говорите. Но не применяйте этот печальный опыт на остальные языки и остальные инструменты.

не не, я не о этом, он для кложура много плагинчиков для emacs например :) но вообще да, я бы по рукам бил бы если б кто то пытался в 2016м году писать на скале\пхп\руби\питоне\js(?) не в idea, так как помогает уменьшить человеческий фактор.

так как помогает уменьшить человеческий фактор.
Человеческий фактор чего? — опечяток? так для вима тоже есть автокомплит, да и тесты + статические анализаторы не отменял никто. Уж выбор редактора — сугубо личное дело человека.

А метод вы как переименовуете ?

Щас напишут в ответ, шо настоящие пацаны методов не переименовывают, они их сразу кошерно называют:)

А этот gofmt работает на уровне AST, или «грепает» ?

воспользовавшись соответствующим инструментом в экосистеме языка, плагином для соответствующего языка, или search & replace.

Качество method rename/find usages в иде для

пхп\руби\питоне\js
тоже будет никаким (читай не сильно отличимо от грепа). Для java — да, не вопрос — иде тут (наверное) будет удобней (для скалы, наверное, тоже)

А вы правда методы (публичные, с переименованием внутренностей
проблем много меньше) каждый день переименовываете?

каждый день переименовываете?
конечно каждый, а еще класы и пекеджи, и перетаскиваю класы по пекеджам!

Имитируете видимость работы, чтобы не уволили?

printf (точнее, библиотека лога) для дебага неизбежен не там, где нет IDEA, а там, где нет возможности остановить процесс в некоторой точке и подождать, пока программист выпьет свои 10 глотков кофе. А также там, где, несмотря на все возможности отладчика, часть истории не сохранилась в текущем состоянии и её нельзя вычислить по этому состоянию.
Упоминание printf для дебага как альтернативу IDE выдаёт, что Вы не излагали собственный опыт, а повторяли расхожие штампы, специально распространяемые маркетологами интегрированных средств.

есть такая вещь как adoption.
— из-за него не взлетают хорошие красивые жирные стартапы, которые выходят на рынок и ... всем по*уй.
— из-за него трудно вытолкнуть на рынок новую ОС, потому что это-экосистема, и трудно переманить тех, кто уже прижился в других экосистемах. Т.е. написать можно чё хошь, но экосистему разработчиков не купишь и не построишь на ровном месте.
-из-за него великий могучий падлючий гугл выбрал Джаву как ЯП для Андроид, т.е. под Андроид можно было взять любой ЯП, — новый, крутой, без детских болезней. Но- нет.

гугл андроид купил, а java там потому что в первой половине 2000х с зазором на team growth ничего лучше не было

чорд, прочитав

Про насиловавших Scala

группа програмистов насиловала Scala два года!

прям готовый хедлайн газеты ’Бангалорский Комсомолец’ ©

Я скалу поковырял — не понравилось совсем. Причем, не понравилось, скорее, окружение: разборки с SBT, теми же зависимостями и т.п. Та же джава, вид сбоку. Пока доберешься до ФП, плюнешь. Хаскель вызвал гораздо больше энтузиазма. Го не пробовал вообще.

Хаскель вызвал гораздо больше энтузиазма.

У кого? Скала хоть имеет хоть какойто шанс «уйти в продакшен», из за джава экосистемы, и спарка.

ну хаскель в продакшене тоже вполне используется насколько знаю (и возможно его популярность несколько выросла за последнее время), хотя возможно он и станет менее популярен по сравнению со скалой.

хотя возможно он и станет менее популярен по сравнению со скалой.
careers.stackoverflow.com/jobs?searchTerm=haskell
careers.stackoverflow.com/jobs?searchTerm=scala

эдак больше чем в 10 раз “мение популярен”.

Та все равно бедненько. Со скалой не сравнить.

Скала хоть имеет хоть какойто шанс «уйти в продакшен»,

Ой, чего только не используют иной раз в продакшене...

Та же джава, вид сбоку. Пока доберешься до ФП, плюнешь.
поэтому из функциональщины для JVM лучше ковырять Clojure)

З.Ы. Сам скалу не ковырял, но слышал/читал, что писать на скале в стиле джавы плохой подход — уж лучше просто джаву для этого юзать.

писать на скале в стиле джавы плохой подход

Это логично. Но тут я даже не про стиль написания, а про «инфраструктуру» — по-моему, там все еще страшнее: поверх джавовских традиционных проблем накрутили еще новые. Особенно хорошо, когда на скале тебе надо взаимодействовать с джавовскими либами. В итоге, именно кодить на скале может и ничего, но вот вся «обвязка» вокруг проекта — адище.

поэтому из функциональщины для JVM лучше ковырять Clojure)

Сам ковырял? Какие впечатления? Я время от времени собирался поковырять, но не дошел пока.

Сам ковырял? Какие впечатления?
Ковырял. Понравилось) ну и помимо собственно Clojure, интересуют (в плане посмотреть) две другие ее реализации — ClojureScript и ClojureCLR(реализация кложуры для .NET-платформы).
В итоге, именно кодить на скале может и ничего, но вот вся «обвязка» вокруг проекта — адище.
ясненько.

clojure приятный такой современный лисп. C удовольствием бы на работе на таком пописал но не складывается

А что там с maven/cabal/sbt? Там эту роль играет некий leningen или как-то так. Какие впечатления от него?

p.s. писать код — это лишь небольшая сторона медали. Иной раз муки сборки проекта умножают на ноль все прелести писания кода.

а я только коаны порешал и leiningen трогал в совсем хеллоу ворд контексте (те нифига не понятно норм или адище)

Clojure не ад.

Ад — аутисты/"мое кложе толще и длинее" программисты. Подебажить clojure адь еще тот.

аутисты они сами по себе ад — я видел как ебанашки простейший JS код превращали в кошмар

Тут свобода фреймворков и языков была. + деплоим приложение на 6000 VM. До сих пор удивляюсь почему никто хаскель не добавил :)

Нейтив с++ код само собой есть :)

еще есть шанс впердолить хаскель тогда
или баронскую вольницу по прижали уже?

Стараюсь как могу :) Вольность убрать. Clojure локализовать. Где что можно чистой джавой заменить.

Все в наших руках, но не все в нашей власти.

у нас на JUG единственные кложур ребята плакали от чего то похожего а их вождь обещал много плохого тем кто попробует повторить их опыт. Но не с трибуны, в калурах

На Жуге чел себя не как кложурист подавал. :)
Но неважно. Может он и хорошие теоретические вещи говорит. Но когда чел в джава проект для того чтобы иметь сущность близкую к scala Tuple для двух значений а больше и не надо тянет депенденси на скала джарник (при наличии класа Пара или Entry), то служать его серьощно ну очень трудно. Хотя парень толковый.

А теперь сопоставь с тем, что Intel использует аутистов для разработки ядер своих процессоров.

у меня на текущем проекте со сборкой такое что людям не расскажешь
4 с гаком гига воркспейс до сборки вот это все
при том что сам код в принципе норм но сборка это просто нечто ( хотя я и по жестче штуки видел у других продуктовых компаний)

Там эту роль играет некий leningen или как-то так. Какие впечатления от него?

помню как-то попробовал собрать Clooj из исходников с гитхаба ( github.com/arthuredelstein/clooj ) - вполне нормалььно было (в смысле лекости и удобства сборки) насколько помню.
Хотя возможно все зависит от крупности проекта.

P.S. Clooj — редактор для кложуры, написанный на самой кложуре, неплохой кстати для начинающих, жаль что автор его уже не разрабатывает.
Поэтому лучше юзать либо LightTable lighttable.com , либо NightCode sekao.net/nightcode .

Поверьте, вы не хотите работать с clojure :)

На текущем проекте: java 8, clojure, scala. Вместе.

Единственое, что возможно вы хотите — команду профи-единомышленников, готовую писать на clojure.

а зачем вы так все и сразу? Расскажите какая мотивация была так делать

про команду — да наверно так и есть, и что бы не могли Кумара подкинуть «помогать»

Нет. Не Кумары. Англичане и поляки. Мотивация — дадим стране быстрее говна. Мол 100 строк на clojure заменят 10 джава классов. Видел места где одно и тоже делалось 3 мя разными спрособами. НаУА? Да промто чел режил разик с функциями высших порядков, раз с макросами а третий вызов джава классов и —> оператора. С докой коментами и названиями функций было туго. О том что имя функции и то что она по факту делает редко совпадали не говорю. Имена переменных abc, ccd, jakas_mapa — в поорядке вещей.

А ну и главаное тесты. Тесты если есть то это типа делаю чтото и печатаю на консоль. Моки, ассерты это для слабаков.

Зато авторы занимались резюме дривен рапзработкой. Даже в clojure 1,7 контрибьютили. Имеют 100+ статей на дэоне и в питере на джуге выступали осенью.

вот а тут я ж скажу опять что проблема в людях а не кложуре
как обычно если с культурой не сложилось то чем богаче язык тем толще приколы
и тесты это боль вот у нас сейчас есть интеграционные хотя бы для основного и это колоссальная помощь

и небось эти модные чуваки имели право лихо без код ревью строчить куда попало?

Так и я о том. Люди главное и культура команды. Работал в классной скала команде и многому научился. Спасибо Саша, Балинт и Сандро. Тут же совсем другая песня.

Короче curse-list у меня есть ;)

Ну и кложа тут при чем? Такой бардак можно организовать с применением какой хочешь технологии.

Ну не о кложе же речь. Речь как раз о том, что каждая обезьяна, нашедшая гранату в восторге от оной. Начинает играться ею, колоть орехи и т.д. пока не вытянет чеку. Согласитесь, с просто ананасом так эффектно не получается.

вот sbt он какой то коряво противный, даже Cabal мне больше нравиться

Как-то так. Насчет кабала — щас вот stack в моде, и он реально неплох (ну, в сравнении с тем же кабалом, во всяком случае).

посмотреть как то что ли
кабал бесил тем что я на ровном месте получал какой то ад и он крашился со словами нишмагла
реально я на хаскеле всего ничего написал а на мину в кабале наступил с разгону и так что забил на язык после потраченных пару часов на гугление солюшенов ( то есть этот самый кабал то для меня хаскель и убил(!) )

Ну вот у меня примерно так же со скалой вышло. Проект (он небольшой) я дорожал, но желания иметь дела со скалой у меня, мягко говоря, значительно поубавилось.

А на хаскеле я на коленке поигрался, курс на степике прошел, задачки разные порешал — со стеком все путём, пока никаких граблей не встретил.

но все равно это все разговоры в пользу бедных
у меня в городе одна скала контора и ни одной хаскельной
на этом фсе
более того последнее время c# на рынке явно больше java (что вообще развлекает)

Я на это смотрю с другой стороны совсем: мне просто интересно обрести новые навыки, и Хаскель мне тут пошел больше чем Скала. Что до продакшена и кол-ва работ — это, как и все прочее, переменчиво и по большому счету даже не важно.

у меня семья дети вот это все сильно сокращает время на поиграться
по этому хочется получать фан прямо на галерах

Играться надо. Потому что однажды можешь утром проснуться «специалистом по Фортрану», — а работы «в твоем городе» нет.

ну stack он вроде не как замена cabal идет, а как дающий возможность создавать окружение с нужной тебе версией хаскеля.

т.е насколько я понимаю — cabal никуда не денется, просто часть кабаловского функционала в улучшенном виде реализовали в stack + добавили новых фитчей (как например указанная мной выше создание окружения с нужной версией хаскеля)

Именно так. Но так стало гораздо лучше :)

Ну, у Go есть свои неоспоримые плюшки, вроде одного небольшого бинарника, и в некоторых задачах это полезно.

А Scala, действительно, не запрещает (напрямую, код стайлы и ревью помогают) всякую дрянь вроде «—==>>» методов. Вот не понимаю, если автор этого кода такой умный, почему бы не придумать человекочитаемый алиас? Всегда считал, что, если для функции/класса/переменной трудно придумать хорошее имя, то что-то пошло не так.

С другой стороны, я искренне не понимаю, за счет чего Go пиарят как «удобный для больших проектов». Легкость входа для новичков — это, конечно, сильная фича, но явно не решающая. По моему мнению, функциональщина (а точнее декларативщина, просто её удобнее использовать именно с ФП) значительно снижает ментальную нагрузку для программиста (иммутабельность, минимизация сайд эффектов). Продвинутая система типов уменьшает количество «случайных» ошибок (вроде сложения id: String с name: String) и повышает абстракцию кода, что (если не увлекаться), приводит к значительному уменьшению копипаста.

Было бы интересно послушать опытных Go-водов, какие у них аргументы.

По моему мнению, функциональщина (а точнее декларативщина, просто её удобнее использовать именно с ФП) значительно снижает ментальную нагрузку для программиста

«Немнога декларативщины»,и функциональщина, это чутку разные вещи.

Вообще-то, при разумных предположениях, «функциональное програмирование» — подмножество «декларативного программирования» ( stackoverflow.com/...nd-imperative-programming ).

Это если вопрос о терминологии, сам я думаю, что слова туда-сюда гонять можно как угодно, без видимого профита.

Ну и, опять же, главное не увлекаться и выдерживать баланс Силы. «Идеальный ФП-код» так же вреден, как и «идеальный ООП-код», или «идеальный ТДД», или любая другая крайность.

опытных Go-водов
вроде правильнее называть их Go-ферами (Gophers).
я искренне не понимаю, за счет чего Go пиарят как «удобный для больших проектов»
Как минимум потому что он для этого создавался одними из самых сильных программистов мира. Понятно, что у людей разные представления о том, что важно для команд из 1К+ программистов и количества строк кода больше 100К+, но вот опыт авторов UNIX и их работы в Google сказал им о том, что важен баланс простоты и возможностей. Go исповедует подход UNIX — дает минимально необходимый набор блоков, из которых можно лепить что угодно. Порог входа — как бонус.

Так подход юникса очень даже «функциональный». Взять данные отсюда, отфильтровать ерунду, пайпнуть на один скрипт, результат пайпнуть на другой, ошибки на третий, и вывести в стдаут. Это с точностью до синтаксиса переносится на любой язык с «map, filter, bind, ...» -like операциями. И это я считаю «декларативщиной».

Go я практически не знаю, и поэтому хотел бы уточнить, что именно в нем «юникс-вей».

Пишу не для холивара, мне интересно прояснить вещи.

Нет, подход UNIX — это не про пайпы, а про концепцию минимально необходимых блоков, позволяющих строить более сложные конструкции. Найти баланс между «минимально необходимым» и «набором фич», чтобы создавать практичеки необходимое множество архитектур и программ. Такие вещи нереально формилизировать, их можно построить только отталкиваясь от опыта. Поэтому, собственно, Go и считается opinionated.
Есть ещё интересное сравнение подходов MIT vs New Jersey примерно об этом же (вот тут статья есть на тему — habrahabr.ru/post/270981/.

Я понимаю и даже согласен. Писать в таком стиле можно что на Джаве, что на Пхп (наверное). Но аналогию «элементарных блоков» несложно отобразить в «функциональщину» — небольшие функции без побочных эффектов, удобство их композиции, отсутствие глобального стейта.

Мой вопрос — что именно в Го поощряет вышеописанный стиль программирования?

Я не спорю, что на той же Скале можно писать ужасно, это вовсе не идеальный язык. Но на ней можно писать действительно понятно, красиво и изящно. Последнее, к сожалению, никак не «форсируется», и зачастую у разных людей свои мнения о том, как вот эту конкретную изящность реализовать. Есть ли такой механизм у Го? Если есть, как Вы его сравните с вещами из первого абзаца?

Писать в таком стиле можно что на Джаве, что на Пхп
В каком стиле? Мы, кажется, о разном сейчас говорим.
Последнее, к сожалению, никак не «форсируется», и зачастую у разных людей свои мнения о том, как вот эту конкретную изящность реализовать. Есть ли такой механизм у Го?
В Go практически нет мест, где что-то можно сделать несколькими способами. Подход был не «дать много фич, чтобы можно было любое желание программиста из коробки сделать», а «дать только те фичи, которые минимально необходимы и гарантируют скорость исполнения».

Думаю, лучше всего тут будет переписать какой-то реальный проектик, чтобы понять для себя разницу. Благо, основа Go учится за пару вечеров.

В каком стиле?
В стиле «атомарных композируемых блоков».
В Go практически нет мест, где что-то можно сделать несколькими способами

Честно говоря, такое впечатление у меня не сложилось. Смотрел сравнение на rosetta.alhur.es/compare/scala/go для более-менее больших листингов (и с другими языками тоже). Да что там, даже в Питоне, с его максимой «There should be one—and preferably only one—obvious way to do it» все не так гладко.

И все же, какие есть паттерны языка для достижения (поощрения, доступности, ...) «юникс-вей»?

Небольшой проект на Го я обязательно сделаю в ближайшем будущем.

ну на розетте явно какой то говно код написан (что на Го что на Скале). Посмотрите Скала примеры, полный ад в большинстве 0_о

Вместо того, чтобы отказаться от scalaz, проводить код ревью и ввести хоть какие-то стандарты и code conventions — начали кричать, что язык плохой, и ушли на go, причем не полностью. Так что если до того у них были «две версии» скалы — то теперь у них «две версии» скалы и го — так, конечно, гораздо проще.

Во всей статье отсутствует логика и здравый смысл. Не верю что менеджер компании на 200 человек в здравом уме может приводить такие доводы. Похоже он просто неровно дышит к гуглу.

Ну а scalaz да, зло.

Ну а scalaz да, зло.
 вы его просто не умеете готовить.

Не, ну понятное дело когда с ней разберешься то все потом ок. Проблема в том, что ее учить нужно, а не просто взять и использовать как любую другую библиотеку. Многие смотрят на это дело и думают — да ну эту скалу нафиг с ее overcomplexity.

Кагбы да, так просто внести как либу и начать от балды использовать в неготовой к этому команде — както опрометчиво.
А вообще сейчас есть «Functional Programming in Scala», так что проблема смещаеться в сторону народа который не хочет новому учиться.

Не верю что менеджер компании на 200 человек в здравом уме может приводить такие доводы.
риторический вопрос к вам как к техническому директору — сколько у вас в подчинении программистов?

Я не считаю его идиотом, иначе он не был бы СТО в такой большой компании. Верю что у него были веские причины отказаться от скалы в отдельных проектах и попробовать go. Просто по каким-то причинам ему захотелось войти в тренд и попиарить go по стандартной гошной методичке и в данном случае это вышло неуклюже так как не надо быть матерным скалистом чтобы понять что его аргументы высосаны из пальца, и это тогда, когда можно было привести гораздо реальнее аргументы.

Просто по каким-то причинам ему захотелось войти в тренд и попиарить go по стандартной гошной методичке
угу. чуть что, сразу методичка — госдеповская, кремлевская, жидомасонская, и ... т.д. заговор производителей! проплачено! разве можно искеренне симпатизировать X?
и в данном случае это вышло неуклюже так как не надо быть матерным скалистом чтобы понять что его аргументы высосаны из пальца
а по мне ваши и прочих скалистов аргументы против этой статьи -бурчание неофитов-адептов скалы. Когда я на хабре стал читать коменты то удивился — а статью то они читали?
«смотрю в книгу — вижу фигу» — вот основной уровень критиков.

ну и конечно обязательна демагогическая приписка, как «аргумент» — «это знают все», «как известно».

и это тогда, когда можно было привести гораздо реальнее аргументы.
он привел аргументы по которым он решил свести скалу к минимуму в компании. а то что некие скалисты ни асилили их, ну так это ж показатель их уровня, а не автора :)

и хотя автор повторяет что его решение было вызвано не столько техническими причинами, сколько социальными, как следствие технических, критики «недоумевают» — так какие его аргументы?

перечитайте статью, там все есть ;)

Вам не странно что весь хабр увидел в статье одно, а парочка ГОшников другое?

Не весь хабр, а дюжина гоу-хейтеров

Да-да, дюжина «хейтеров» развела срач на 300 комментов и лайки напротив своих комментариев наставили, ага.

Кстати хейтерят не гоу, а упоротых фанатов гоу. Прям как ватники:
— фанаты go упоротые Путин х*йло
— Почему вы не любите go все русское?

Да-да, дюжина «хейтеров» развела срач на 300 комментов
ну раз аж целых 300 хабровцев плюс в разы больше лайкнувших — то да, то точно — с тенденциями в программировании сомнений нет.
экспертное сообщество хабровцев и они же — владыки тенденций — как решило значит все так и есть.
— фанаты go упоротые Путин х*йло
— Почему вы не любите go все русское?
звучит прям как «Роб Пайк — агент кремля!!!»)))

Не Кремля, а Цюриха. Потому что переметнулся на сторону зла Вирта, хотя сама разработка C была ему злейшим вредом.

Не Кремля, а Цюриха
а вдрпуг в Цюрихе тоже агенты кремля сидят?))
хотя сама разработка C была ему злейшим вредом.
может не С, а Limbo — ru.wikipedia.org/wiki/Limbo ? ;)
ибо С разрабатывали К.Томпсон и Д.Ритчи :)

Limbo — да, как явный предшественник Go. Но он тут не вместо C.

а вдрпуг в Цюрихе тоже агенты кремля сидят?))

Они сидят, конечно, но вряд ли именно там.

Вам не странно что весь хабр увидел в статье одно, а парочка ГОшников другое?
вам ни странно что я никаким боком не имею отношения к GoLang и в статье в отличие от «всего хабра» увидел рассказ не о фичах, дизайне языков, а историю которая не редкость и до появления Scala и Go.

Мне же да, не странно, что «весь хабр» окажется не в состоянии в одно предложения ответить на вопрос:
Какая проблема возникла перед автором статьи?

Подсказка: если в этом ответе окажутся слова Scala, или Go, или фразы смысла — «автор и его команда ни асилили» — то можно точно утверждать о виде функциональной неграмотности школоты, или сугубой упоротости, узости мышления и личного опыта.

Почитайте внимательнее комментарии. Народ взбесило то, что автор пытается решить очевидные менеджерские провтыки сменой языка. Большинство проблем, на которые автор акцентирует внимания, решаются:

а) Введением культуры в разработку
б) Введением хоть каких либо конвеншинов (даже авторы спрака ввели бан на большинство фич скалы и чувствуют себя хорошо (github.com/...de/blob/master/README.md)
ц) Ведением код ревью

И это тогда, когда у скалы есть реальные проблемы, которые так просто не решить, и с которыми приходится мириться, и которые автор либо не упомянул, либо упомянул мимолетно.

Народ взбесило то, что автор пытается решить очевидные менеджерские провтыки сменой языка.
именно — толпа великих менеджеров с хабра, у которых в подчинении много больше программистов чем у этого лузера — конечно спецы в менеджменте...
Большинство проблем, на которые автор акцентирует внимания, решаются:
.... и потому предлагают более дорогое и сложное решение, с бОльшим числом бизнес-рисков, чем было выбрано конкретным менеджером в конкретной ситуации.
вы таки менеджер?
И это тогда, когда у скалы есть реальные проблемы, которые так просто не решить,
у Скалы проблема как у любого академического (или сложного) ЯП. и способы решения проблем академического ЯП известны — отказ от него, или сведение к применению только в ресерч командах.

вам ли как менеджеру больших ИТ команд и проектов напоминать эту обычную практику, с времен например — применения Cobola вместо LISPа, С вместо Алгола-68, ..., Java вместо С++, ... PHP вместо Ruby ..., и т.д. и т.п.

и которые автор либо не упомянул, либо упомянул мимолетно.
автор как и любой другой упомянул то что считал важным, значимым.

а то что хабровская школота считает что он должен был упомянуть то что ей хочется, потому что она больше ничего ни ап чем не знает и не понимает — говорит об ее уровне, а не об уровне автора.

впрочем, я это кажется уже все написал. горохом об стену, ессно.

именно — толпа великих менеджеров с хабра, у которых в подчинении много больше программистов чем у этого лузера — конечно спецы в менеджменте...
Большинство проблем, на которые автор акцентирует внимания, решаются:
.... и потому предлагают более дорогое и сложное решение, с бОльшим числом бизнес-рисков, чем было выбрано конкретным менеджером в конкретной ситуации.
вы таки менеджер?

Не такой уж этот менеджер и великий, раз на go успешно решает задачи которые решал на скале. Значт лоханулся раньше — когда тащил скалу, используя инструмент не по назначению, стреляя с пушки по воробьям. Очень уж разные языки с разными областями применения.

у Скалы проблема как у любого академического ЯП. и способы решения проблем академического ЯП известны — отказ от него, или сведение к применению только в ресерч командах.

Тем не мене, 90% скалистов вспоминают про академичность языка только когда залазят в исходники библиотек. Тот факт, что язык позволяет писать академический код не означает что его надо писать в прикладном проекте.

выше уже дали ссылку на очередную статью, и там я дал комментарий.

В завершение возьму ее завершение:
Go так или иначе уже здесь, он уже взлетел. Его уже используют, его уже котируют, он уже нужен. Можно очень долго воротить жопу и ругаться на отсутствие дженериков, но час Go уже настал.

Поэтому извините, мнение хабро-скалистов не только о менеджменте, о тенденциях в программировании, их причинах, а даже о самой скале мне малоинтересно. потому что, из моего многолетнего наблюдения они и в джаве не шарят.

места же где обитают действительные скалисты, и вообще функциональщики мне известны, и нередко посещаю.

такое везде наблюдается. всегда есть более слабые девелоперы, и чтобы оставлять их на борту предпочтительней писать более «тупой» код/архитектура. именно это есть причиной того что многие люди предпочитают императивный апроач — он самый понятный

Осталось выяснить чем го существенно лучче чем старая добрая джава 8.

а вам разве не интересно отлавливать новые доселе не известные глюки в GC? да вы ретроград батенька :)

а что там еще вкусного? А то я только по этой части наблюдал оч нефиговые приключения ( хотя их типа недавно починили

До сборки мусора еще дожить надо :). А это генерация байткода. Баги как всегда есть.

Посмотрите; а ютюб, как люди отработавшие в тайпсейф уходят со скалы.

Посмотрите; а ютюб, как люди отработавшие в тайпсейф уходят со скалы.

ссылки ?

Андрей, там 45 мин,
если не лениво, тыцни плз в те минуты, где изюм и грабли.

Чел в 45 минутах расказывает что стандартные скала коллекции «оверенджениред», и в ряде случаев дают по его мнению нелогичный и багливый результат (с некоторыми его утверждениями я даже согласен, с некоторыми нет).
Причем в конце он дает ссыль на свою библиотеку скала-коллекций, по его мнению, с блекджеком и ленивостью. Так что выбор есть.

Насколько я понял, решили (90%), что игра не стоит свеч.

непростой выбор между гемором и свечами ))

как это чем? сусликом на логотипе конечно же)))
я в во многом из-за логотипа и посмотрел немного Go) правда еще читал, что Go простой как 5 копеек, но основным мотиватором для его изучения был все-таки логотипчег))

Кстати, это не суслик, а гофер — это отдельная зверюшка, не сильно известная в Европе )

ну вообще да) но мне его больше нравится сусликом называть (правда не знаю, насколько суслики похожи на гоферов).

Ну они грызуны и те, и другие, но разные семейства — беличьи vs гоферовые )
ru.wikipedia.org/wiki/Суслики
ru.wikipedia.org/wiki/Гоферовые

>half the team didn’t want anything to do with it.
Ленивые неудачники, которым самое место подметать полы в зале с коболовскими меинфреймами.

Зря вы так про кобол
за сакральные знания и дрочилово с майнфреймами все еще очень жирно платят
правда мне лично всегда хотелось помыть руки и накатить даже после очень коротких встреч с этими зверями

Проблема в отсутствии менеджмента же, они дали мощный инструмент своим инженерам, но забыли присматривать за ними, ну и в итоге они сделали то что сделали. Но даже аннотация в конце статьи что код ревью бы решило эти проблемы не остановит срач)

if err != nil return nil, err

ну так да — чувак подменяет управление процессом разработки притаскиванием по пояс деревенного языка. Я могу сказать что это в лучшем случае спрячет проблему под ковер ( а скорее всго ситуацию только ухудшит)

следующий шаг — мы внедрили микросервисы так как они позволили делегировать ответственность (читай «весить тонны легаси на конкретных людей») и после этого у нас (менеджеров) все хорошо

бггг это еще хорошо когда микросервисы
хуже когда делают моноблочный снежочек из фекалий и пытаються это преподносить как сервисы
вот где интереснейшие вещи лезут

не в курсе- выглядит пока мертво рожденным, все ни как ненаберет traction

TL;DR:

I dug in to the Go world and saw it solved a lot of issues I had with Scala at the organizational scaling level.

Fast build times, small binaries, one file, built in formatting, great tooling, built in test framework, profilers, a nice concurrency model ... one of the other benefits of Go was widening the pool of backgrounds we can hire. We can take someone from any language background and have them ramped up on Go in weeks. With the Scala side there’s the JVM learning curve, the Java world of containers, black magic of JVM tuning etc. New developers we’ve hired are ramped up in weeks vs months.

Golang метит в нишу JVM. В ту её (большую) часть, для которой Java вполне достаточно но VM уже давно мёртвый груз.

Заодно глянул чего они там такого пишут.
www.crowdstrike.com/products/falcon-host
dou.ua/forums/topic/15866

в переводе на русский — нанять вменяемых людей на скалу не вышло

о переводик накропали
срачь там какой то слабенький как мне кажеться, оскорблений и унижений маловато — кармодрочные принцессы стесняються

В следующем году Go порвет Scala с Java как тузик грелку

Посмотрим через год, доберется ли Go до штанов Java со Scala. Думаю, к декабрю 2016 года от этих штанов останутся жалкие ошметки. Спорим на сыр по 1500?

ну может на рынке котиков они пхп и задушат
но я пока ВООБЩЕ не вижу Go в интерпрайзе и финтече
основная масса вообще озадачена переходом на 1.8, IBM теперь клауды за гольфом парит и BI.

Энтерпрайзу нужны простые как грабли инструменты типа go, а не матановый scala. Иначе тысячи индусов ниасилят миллионы строчек своего энтепрайзного говнокода.
Про go в энтерпрайзе www.techworld.com/...va-in-enterprise-3626140 .

ну что то я там не увидел никакого enterprise
стартапы медийщики и пару единрогов. Ни одного tier 1 банка или серьезного вендора

даже haskell и erlang есть в продакшене у банков а про Go пока как то не слышно

порвет Java
слишком толсто, тоньше нужно.

походу в переводе есть фраза, которая ИМХО должна была свести на нет весь срач " ’Scala круче Go’ vs ’Go круче Scala’ ":

этот пост, описывающий, почему мы перевели большую часть нашего стека на Go, и почему новые сервисы мы по-умолчанию теперь пишем именно на Go.

Вместо того, чтобы заставлять ждать читателя до конца поста, я сразу скажу, что Scala не покидает наш стек полностью. По сути, она остается дополнением к Go в тех местах, где он не блещет.

что намекает на то, что:
1. Go во многих случаях вполне может заменить скалу,
2. Go не идеален, в каких-то местах он хромает, и там лучше будет оставить Scala.
3. в данном проекте применяются и Scala, и Go. Хотя большинство кода пишеться на Go, но Scala никуда не делась и какие-то критические вещи пишуться на ней.

Підписатись на коментарі