Нужность: Golang, C#, C++

Go - это легковесные горутины, утиные интерфейсы, спека на 70 страниц, стандартный code style, быстрая компиляция, мощный tooling, чему способствует КС-грамматика (форматирование кода, рефакторинг, юнит-тесты, покрытие, профилирование - всё из коробки). Дополните, если чего забыл.

Отсутствие единого пакетного манагера
Постоянные проблемы с версиями сторонних либ как следствие (в расте cargo идет вместе с компиляором)
Статическая сборка only (да, я в курсе про gccgo)
Дебильные unused variable/import, которые мешают при дебаге (в расте это варнинги, а тут критикалы, блдж)
Public variable в «классах» указывается через капитализацию - совсем идиотское решение. Wat - public, wat - private, приходится ренеймить во всем коде.

Вот за время моего пользования го эти «фичи» конкретно достали. Дополните, если чего забыл.

QuickTime, очевидно же

Отсутствие единого пакетного манагера

Есть такое.

Постоянные проблемы с версиями сторонних либ как следствие (в расте cargo идет вместе с компиляором)

Dependency pinning. Используй одно из доступных решений, например, godep.

Статическая сборка only

Это плюс.

Дебильные unused import, которые мешают при дебаге

Настрой свой редактор.

Public variable в «классах» указывается через капитализацию - совсем идиотское решение.

Отличное решение.

приходится ренеймить во всем коде.

gorename

Не переживай, программирование вообще не нужно

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

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

js там же клей, а не язык разработки двигла, не?

правильно писать: «в отличие» — это, твоё сияющее всё. Запомни это.

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

Если нет противопоказатий и предубеждений, писать на них - самая мякотка.

ага, особенно linq выражения, которые дебаггер просто перепрыгивает

и там где нужен C#, обычно нужен и C++, а это боль

Эта школоподелка ни хера не типичная. Это гуета, а дотнет не для убогой гуеты. Типичный проект на .NET это скорее что-то с WCF.

Если у тебя func (t *test) String( ) string { то надо t := &test{0, 1}. Тогда вернет 0:1

Внезапно про это тебе анонимус и писал. Интерфейсы в Го никак не контролируют параметры, которые должны принимать (в отличае от неявного this, как тут кто-то заикался). Меняешь интерфейс — получаешь другой результат. Потом бегаешь по модулям и выставляешь указатели вместо значения. Можно сразу сделать указатель, да, но тогда тебе ПРИДЕТСЯ везде передавать указатель и придется знать и помнить какой интерфейс, что требует.

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

Всегда интересно мнение столь уважаемого аналитика и ыксперта.

Я разработчик языка Go, задавайте свои вопросы.

Настрой свой редактор.

С импортами может быть, а с переменными оно как поможет? Комментим одну строчку, получаем 10 «variable x declared and not used» - прыгаем по коду, коментя все 10 переменных, только чтоб скомпилить. Потом все обратно.

Легко ли рулить потоками в расте?

Имхо, раст он не про «лёгкость» (с оговорками), а про сложность «выстреливания в ногу» и отсутствие накладных расходов при этом. Ну то есть, после С++ многое кажется очень удобным. Подозреваю, что после более простого языка впечатление будет иным.

В общем, попробовать стоит. Но если ты прямо хочешь взять и что-то делать и сравниваешь с С#, то я бы раст не советовал. Язык даже не зарелизился и, очевидно, библиотек гораздо меньше.

Так вот. Нахер такое «ООП». Это какой-то непонятный кастрат «типа ООП»

Я Gо, мягко говоря, недолюбливаю, но ты всё-таки несправедлив. Так ведь много к чему придраться можно. Скажем, в джаве/С# нет множественного наследования классов (только интерфейсов) и ничего - живут как-то. Более того, ещё и рассказывают, что это правильно.

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

Это плюс.

Почему? Отсутствие чего-то редко бывает плюсоm (и не надо дурацкиx аналогий, пожалуйста). Ладно бы, если бы это было вариантом по умолчанию. Пусть даже выдавали бы предупреждение, но запрещать вообще тупо.

Тем более, что что-то на эту тему пилят. Значит надо.

Отличное решение.

Тоже интересно почему.

Бочку делаешь?

Что это?

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

Меня удивляет упоротость аффторов по этому вопросу. Они твердо решили - в го варнингов быть не должно. Совсем. Только критикалы. Поэтому variable declared and not used - критикал, который затыкает всю компиляцию.

Отсутсвие generics, и как средствие отсутвие реюзабельности кода совсем. Напиши на go функцию поиска максимального ключа в словаре. Для словаря string->int, потом string->string, потом int->int, а потом когда полностью задолбаешься такое писать к тебе прийдет Go программист и скажет что такие функции вообще лучше не писать и просто искать максимум на месте в for цикле. Go-way. Теперь ты официально имеешь моральное право его зарубить топором

Пруф

Потерпи немного, скоро Rust 1.0 отрелизится, как минимум Go сразу станет ненужно

На ЛОР появилась новая секта свидетелей Common Lisp Rust, по сути приговор для языка - карма безнадежно испорчена.

captcha: 256

Еще reference implementation - жуткий набор ни с чем не совместимых велосипедов и костылей прямиком из 15 лет как умершего Plan9: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ . Они даже bootstrapping не осилили, за 6-то лет.

боже, какая у вас каша в голове

Нужность с точки зрения end-user: зачастую всё равно что там под капотом, с точки зрения разработчиков несколько иная ситуация.

Нам просто не требуется писать вычисления факториалов максимальных ключей тысячи раз. А если бы требовалось, go generate спешит на помощь, как Чип и Дейл.

Haters gonna hate. Nobody cares.

Еретик! Как ты смеешь! Он будет релизнут за твои грехи, а ты даже не знаешь его синтаксис!

Авторам так было удобнее: https://news.ycombinator.com/item?id=8817990

Они даже bootstrapping не осилили, за 6-то лет.

не нужно

go generate

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

Это просто песня %)

You see, despite having written their own entire toolchain (including a compiler identifying itself as accepting C that does no such thing), the authors decided that the normal “.” character was simply too special to be repurposed in source code. Instead, it would retain its existing meaning as the customary dot operator. But this means some other character will be needed to identify symbols that should have a dot in their names. So obviously the natural choice here is some high Unicode character. Obviously. And equally obviously, when such code is compiled, the character is replaced in symbol names with an ordinary dot.

go generate

Ух ты, вот это костылище, использовать внешнюю кодогенерацию как суррогат дженериков и макросов.

Нам просто не требуется

Видимо я просто не понял, лисп go не предназначен для этого, он работает по-другому.

C# не убийца Java, а Java в которую средствами языка добавили вещи которые спокойно можно реализовать в библиотеке.
Делегаты-это просто интерфейсы, в java 8 они,кстати, называются functional interface.
LINQ-я так понял что это stream из java 8.
Свойства-не нужны, есть getX() setX().
async, await-хз, асинхронное IO и в Java есть.
Самое тупое что есть в C# — конечно, события. Очевидно, что это маркетинговый ход от мс для формошлеперов.
Адекватно сравнить производительность C# и Java очень сложно, потому что все зависит от виртуальной машины.
Между Java и C# выбирай Java, ну а если очень хочется сахарку и ФП, бери scala, в ней доступны все Java библиотеки(и часто наоборот тоже).
C# не нужен потому что он перегружен ненужным синтаксическим сахарком.

С++ является производительным, но сложным для написания программ

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

Golang

Погоди пока оно станет более популярным, сейчас лучше приложения из его ниши писать на Java. Библиотек больше на Java. Если возникнут затруднения, решение на много проще найти для жабки, чем для нового ЯП.
Хотя потыкать можно, вдруг понравится. Я думаю переучится из джависта, а тем более из плюсовика, на go будет очень нетрудно.

Авторам так было удобнее

Очевидно авторам было удобнее притащить свои родные поделки из Plan9, чем открывать для себя gnu/llvm toolchain, но не вижу, как это оправдывает низкое качество итогового продукта. Тот же gccgo нормально заработал, значит проблема в интеллектуальной лени и ретроградстве разработчиков.

bootstrapping не нужно

На столько не нужно, что они это основной фичей 1.5 хотят сделать.

LINQ-я так понял что это stream из java 8.
Свойства-не нужны, есть getX() setX().
async, await-хз, асинхронное IO и в Java есть.

Вот это экспертиза так экспертиза. Забыл еще сказать, что полноценные дженерики и вывод типов не нужны, и все удачные решения из C# все равно появляются в Java, через 7-8 лет.

Я уже написал про scala

не вижу, как это оправдывает низкое качество итогового продукта

а именно?

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

who cares?

На столько не нужно, основной фичей 1.5 хотят сделать

основной фичей будет конкурентный GC, а это будет приятным дополнением

а именно?

Как минимум, отсутствие динамической линковки, отсутствие поддержки чего-то кроме х86 и ARM, велосипеды вместо state-of-art оптимизаторов и линкеров из gcc или llvm. Все это, к слову, есть в gccgo, но авторы упорно продолжают пилить свой особенный тулчан с нескучным ассемблером.

основной фичей будет конкурентный GC

Они за 6 лет даже конкурентный GC не осилили?

динамической линковки

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

велосипеды вместо state-of-art оптимизаторов

высокая скорость компиляции - один из приоритетов

Они за 6 лет даже конкурентный GC не осилили?

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

P.S. Всегда удивляют люди яростно поливающие говном инструмент, которым даже не пользуются.

высокая скорость компиляции - один из приоритетов

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

На ЛОР появилась новая секта свидетелей Common Lisp Rust, по сути приговор для языка - карма безнадежно испорчена.

Да тут у любого языка есть обожатели и ненавистники, так что не аргумент. К тому же, мало кого (кроме нубов задающих вопрос «какой язык изучить?») волнует «карма языка» на ЛОР.

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

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

Варнинги в расте на предмет «правильного именования» смущают больше (в Gо, кажется, такого нет?). Скажем, у нас несколько языков используется, а стиль один. Подстраиваться под язык не захочется.

вопрос масштаба, компиляция иного плюсового кода может весь день занять

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

В С++ медленная компиляция вызвана (оправданными или нет) дизайнерскими решениями самого языка, конкретно тем, что инклуды и теймлейты обрабатываются при компиляции каждого юнита в отдельности. Отдельные компиляторы могут работать над скоростью компиляции - clang например - но пока не примут С++17 с модулями, выше головы им не прыгнуть.

В Go теймплейтов и макросов нет, import вроде как умнее #include, а синтаксис оптимизирован под парсинг в ущерб читаемости, так что никакого смысла затачивать компилятор по скорости компиляции в ущерб качества итогового кода нет. Все заявления о скорости компиляции, тем более сравнения с С++, выглядят как неудачная попытка отвести внимание от на самом деле важных вещей.

В Go теймплейтов и макросов нет...

Я отвечал на это:

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

http://stackoverflow.com/questions/6089086/what-is-open-recursion