Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю
Плюсы:
— свежим глотком после java стало наличие структур и пойнтеров (без арифметики). легче представить как выглядят данные с которыми работаешь и например, в каком виде что передается в метод. это избавление от одного уровня абстракции что имхо есть хорошо. тем более что возможность "привязывать" поведение к данным не пострадала. из С же пришли конвенции стандартных библиотек (strconv, fmt и тп), тоже хорошо, не дает повязнуть в специфичной джаве jdk номенклатуре
— вменяемые литералы для популярных типов ([]) и работы с ними. это скорее не к заслугам именно го, а к костности джава. вроде как стандарт везде. вот в жаве в 12й собирались ввести raw строковые типы и даже уже запилили, сам на бете игрался, а потом архитектор пишет "есть корнер кейсы которые не устраивают, и не уверен, что мы займем литерал ` а через 100500 лет (утрирую) он нам не понадобится под другое. их не так много свободных" no comments как говорится
— нативность бинарников и быстрый запуск что как бы очевидно, но приятно удивляет еще скорость компиляции. почитав архивы разработчиков языка нашел, что скорость компиляции -- один из приоритетов в разработке языка.
— прозрачный toolchain, написанный на го. можно отпрофилировать программу вплоть до системных вызов. в жестких случаях в компиляторе используется сразу asm, ну да. но никакого промежуточного black box в виде jvm-монстра с ее неявным поведением требующим в итоге "прогрева" и прочей магии, нет.
— спорно, но авторы заявляют "простоту" языка приоритетом в разработке, и так во всем: в реализации методов, в семантике, в тулинге. и в целом у них кмк получается. пример 1: сортировка это mergesort для не-примитивных типов (ускоренный insertion sort) такая реализация занимает несколько десятков строк. в java и python более эффективный (+30% скажем в среднем) tim sort на порядок больше (сотни строк). стоит ли одного другого вопрос выбора. если у меня все будет упираться в сортировку, и я это смог понять, всегда можно именно ее впилить, какую нужно, но мне нравится по умолчанию подход с "least surprise" во всем, куда бы не полез. пример 2: в java для мап есть хитрые методы computeIfAbsent() compute ifPresent() putIfAbsent() (внимание! putIfPresent() нету) это пример развитости стандартной библиотеки что с одной стороны хорошо. но экономит ли это время разработки, вопрос. авторы go хотят оптимизировать фактор времени освовения/разработки, в т.ч. за счет вычислительной сложности. это осознанный выбор
— авторы языка позиционируют его как ... язык системного программирования. не ядра наверняка, но все равно, сишники вряд ли с ними согласятся. по мне — дернуть системный вызов, обернув вокруг него какую-то логику, без JNI, jvm и т.п. удобно, да. в итоге интересный эффект: если в java профессиональный рост возможен только "вверх по стеку" (архитектура, энтерпрайз) то в го вполне можно заниматься полезными вещами, в сторону системы. кмк плюс
— из стандартных библиотек нравится сетевой стек, ну, его многие хвалят
— нравится community (разработчиков языка, про девелоперское ниже). вот возник вопрос — в го нет бинарных литералов, нашел ветку обсуждения, proposal, написал туда своей пример, ответили. уже комиты идут. а в питоне хотел поинтересоваться, почему с версии 3.3 стали рандомайзить seed встроенной hash() функции при каждом старте рантайма, и насколько это правильно, ничего не нашел. может, совпало, но вот...
— каналы. inmemory cache на них не сделать, но для большого числа ("простых" ага) случаев message passing работает хорошо.
— есть goto... хм
Не нравится:
— обработка ошибок. например у меня передается буфер и я делаю в методе несколько записей в него. мне все равно на какой по счету записи я сфейлюсь, мне нужно выкинуть ошибку а количество записанных символов не важно (ответ по http скажем шлем). так бы я поставил try/catch и все, а в го нужно If на каждую запись. и дело не в сборке стека. если в го есть семантика сигнализирования об ошибке то хотелось бы механизмы удобной их аггрегации и без сбора стека
— традиционно сюда относят отсутствие дженериков. не уверен что это именно недостаток языка как такового. если у меня не библиотека, можно подкорректировать механизмы управления сложностью под доступные языковые инструменты. в го для этого интерфейсы которые включением других как бы наследуют поведение и соответственно reciever types которые позволяют неявно (без implements) задавать имплементацию, интерфейсов или структур. встроенные типы (мапа, слайсы) параметризованы. доступен type casting но это небезопасно, и делает код малочитаемым, поэтому когда необходим богатый полиморфизм типов, лучше посмотреть в сторону других языков. это как бы официальная позиция разработчиков. пока не найдут "идеальный" вариант генериков по крайней мере. сколько его искать будут...
— долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction
— в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. при том, что в самом runtime авторы их используют но гарантий разрабам не дают. и это в языке заточенном на конкарренси. тикет открыт уже много лет. бывают такие wtf
— управление зависимостями. тема известная. авторы языка не сидят на месте. здесь пусть выскажутся те, кто пишут большие проекты в продакшн с многими зависимостями. вроде как работа ведется постоянно. без конфликтующих зависимостей проблем нет как с GOPATH так и с новыми модулями (с модулями есть баги, допиливают)
— девелоперское сообщество. когда пытаются перенести практику ООП. с интерфейсами и тайп кастингом в го можно можно накрутить, но в таких случаях непонятно, зачем берут именно го, если нужен энтерпрайз то это другие языки. на го это получается.. плохо
— востребованность. найти проект сложно. особенно с учетом предыдущего. джавы завались
В целом как как один из мейнстримовых языков, компилируемый, статически типизированный и с автоматическим управлением памятью golang неплох и вроде как без особых альтернатив. плюс удобная модель асинхронной работы. нравится
Более подходящего форума не нашел, философия, ок. просьба перенести если что
A>Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю
А ты смотрел на связку C# + .NET Core? Недавно сравнивал его с Go, и плюсов у Go нашёл только "один экзешник без необходимости таскать runtime", "авторы go торопятся подержать реально много платформ не только win/lin/mac" и, собственно, всё. Остальное только сплошные недостатки.
Так как Go своей популярностью сильно взбодрил MS, там уже ваяют упаковку в один exe для C# (пока альфа, но темп хороший), и наконец-то начали быстро добавляться новые платформы, типа всяких Linux arm32. Есть ощущение что к релизу .NET 3 или вскоре после за go аргументов вообще не останется.
Здравствуйте, andmed, Вы писали:
A>В целом как как один из мейнстримовых языков, компилируемый, статически типизированный и с автоматическим управлением памятью golang неплох и вроде как без особых альтернатив. плюс удобная модель асинхронной работы. нравится
Rust ваще без вариантов.
Писать на нём почти так же удобно как на немерле.
_>А ты смотрел на связку C# + .NET Core? Недавно сравнивал его с Go, и плюсов у Go нашёл только "один экзешник без необходимости таскать runtime", "авторы go торопятся подержать реально много платформ не только win/lin/mac" и, собственно, всё. Остальное только сплошные недостатки.
Привет. Нет. Исторически сложилось так что вся экосистема Windows меня обошла стороной
A>Привет. Нет. Исторически сложилось так что вся экосистема Windows меня обошла стороной
Ну может посмотри. Конкретно .NET Core с рождения был инициативой полного отвязывания от Windows, и года за 2 отвязался настолько что в NuGet (аналог maven в java) уже есть кросплатформенные библиотеки на все случаи жизни. В остальном в C# привычный для Java-программиста стиль, разве что синтаксического сахара очень много насыпано. Ну и async/await удобнее goroutines хотя-бы потому что try/catch работает и для асинхронного кода.
Читая твой пост я, наконец, понял философию дизайна и целевую аудиторию go.
Это язык для слабых программистов. Это самое политкорректное выражение которое я смог подобрать.
У go даже эмблема со зверюшкой, у которой явно синдром дауна.
По всей видимости, авторы получили указание от начальства такого вида: Мы тут набрали кучу случайных людей по объявлениям и квотам на негров, геев, феминисток итп. Уволить мы их не можем, ибо SJW обвинят нас в расизме, гомофобии и что там ещё популярно у SJW. Нам нужен язык, который даже эти могут использовать.
Разумеется, никто никогда в этом не сознается. Но других объяснений этому языку у меня нет.
Сравнивать буду с раст. Ибо это компилируемый в нативный код язык системного программирования с автоматическим управлением памятью, но без ГЦ. Просто раст на этапе компиляции знает, когда память нужно освобождать.
И главное авторы раста делают язык для умных людей, которые способны освоить мощные инструменты предоставляемые растом.
A>- нативность бинарников и быстрый запуск что как бы очевидно, но приятно удивляет еще скорость компиляции. почитав архивы разработчиков языка нашел, что скорость компиляции -- один из приоритетов в разработке языка.
Нужна не скорость, а параллельность, инкрементальность и спекулятивность (это когда ИДЕ компилирует код, пока ты пишешь). В этом случае даже если ты начал работать с проектом, в котором гигабайт исходников то компиляция завершиться мгновенно.
A>- прозрачный toolchain, написанный на го. можно отпрофилировать программу вплоть до системных вызов. в жестких случаях в компиляторе используется сразу asm, ну да. но никакого промежуточного black box в виде jvm-монстра с ее неявным поведением требующим в итоге "прогрева" и прочей магии, нет.
Это свойство всех нативных языков.
A>- спорно, но авторы заявляют "простоту" языка приоритетом в разработке, и так во всем: в реализации методов, в семантике, в тулинге. и в целом у них кмк получается. пример 1: сортировка это mergesort для не-примитивных типов (ускоренный insertion sort) такая реализация занимает несколько десятков строк. в java и python более эффективный (+30% скажем в среднем) tim sort на порядок больше (сотни строк). стоит ли одного другого вопрос выбора. если у меня все будет упираться в сортировку, и я это смог понять, всегда можно именно ее впилить, какую нужно,
Авторы го настолько боятся свою ЦА, что даже нормальную сортировку в стандартную библиотеку побоялись положить.
Ой, а что если разработчик полезет смотреть, как работает сортировка и испугается?
A>но мне нравится по умолчанию подход с "least surprise" во всем, куда бы не полез. пример 2: в java для мап есть хитрые методы computeIfAbsent() compute ifPresent() putIfAbsent() (внимание! putIfPresent() нету) это пример развитости стандартной библиотеки что с одной стороны хорошо. но экономит ли это время разработки, вопрос. авторы go хотят оптимизировать фактор времени освовения/разработки, в т.ч. за счет вычислительной сложности. это осознанный выбор
Опять говорит про то, что думают авторы го о разработчиках на го.
Фактор освоения релевантен, только если те, кто пытается освоить не могут освоить сложные концепции.
Вот пример кода на rust. Тут полно сложных концепций. Но один раз, освоив их, получаешь гору очень мощных инструментов.
while let Some((state_set, new_from_state)) = vars.states_to_process.pop()
{
let mut all_signals = BTreeMap::new();
for trans in state_set.iter()
.flat_map(|state| vars.signal_transitions.get(state))
.flatten()
{
all_signals.entry(trans.signal_begin).or_insert_with(|| (Vec::new(), Vec::new())).0.push(trans.state_to);
all_signals.entry(trans.signal_end) .or_insert_with(|| (Vec::new(), Vec::new())).1.push(trans.state_to);
}
let mut last_signal = 0u32;
for (signal, (begin_to_states, end_to_states)) in all_signals.iter()
{
Этот код абсолютно безопасен, не смотря на то, что тут полно указателей ссылающихся на внутренности коллекций.
Например, signal, begin_to_states и end_to_states это указатели на элементы коллекции all_signals. При этом компилятор гарантирует, что all_signals во время цикла изменена, не будет.
А значит, эти указатели не протухнут.
Эта конструкция сама по себе потянет на большую статью.
Но она безопасна, эффективна и удобна в использовании.
Тут происходит один поиск в словаре, если элемента нет, то происходит вставка нового элемента в новое место и в результате данная конструкция возвращает указатель на значение, через который это значение можно менять.
Используя этот указатель, мы получаем нулевой элемент кортежа и вставляем в него данные.
.0.push(trans.state_to)
При этом в этом коде не происходит ни одного лишнего выделения памяти и компилятор всё это очень агрессивно инлайнит и оптимизирует.
Например, в подобном коде в большинстве языков будет куча выделений памяти. Раст обходится без них.
for trans in state_set.iter()
.flat_map(|state| vars.signal_transitions.get(state))
.flatten()
И да, переменная trans является указателем на элемент массива, который лежит в словаре signal_transitions.
A>- авторы языка позиционируют его как ... язык системного программирования.
Врут. Или точнее льстят своей ЦА. Глядите теперь вы системные программисты.
Вот рас действительно подходит для системного программирования.
Тут нужно быть совсем упоротым, чтобы с этим спорить.
A>- нравится community (разработчиков языка, про девелоперское ниже). вот возник вопрос — в го нет бинарных литералов, нашел ветку обсуждения, proposal, написал туда своей пример, ответили. уже комиты идут. https://internals.rust-lang.org/
A>а в питоне хотел поинтересоваться, почему с версии 3.3 стали рандомайзить seed встроенной hash() функции при каждом старте рантайма, и насколько это правильно, ничего не нашел. может, совпало, но вот...
Это защита от DoS атак при помощи коллизий хеша. Это не про конкретно питон, а вообще.
Кстати про хеш. Дизайн хэша в раст просто замечательный. Там отделили алгоритм вычисления хеша и код превращения объекта в хешь. Таким образом в зависимости от задачи для одного и того же объекта можно посчитать быстрый платформозависимый и рандомизированный хешь для хештаблици и криптографический платформонезависимый.
A>- каналы. inmemory cache на них не сделать, но для большого числа ("простых" ага) случаев message passing работает хорошо.
Для сравнения раст позволяет такое. https://www.youtube.com/watch?v=s19G6n0UjsM&feature=youtu.be&t=1997
A>- есть goto... хм
Необходим для генерации кода из высокоуровневых языков.
A>- традиционно сюда относят отсутствие дженериков.
Опять же страх перед ЦА. Генерики это сложно. ЦА не поймёт.
В раст есть очень мощные генерики и их связь с трейтами позволяют чудеса творить. Это вообще очень большая тема.
Более того в раст есть макросы. Это мега пушка, которую даже разработчики C# боятся, а они о своей ЦА несколько более высокого мнения.
A>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. при том, что в самом runtime авторы их используют но гарантий разрабам не дают. и это в языке заточенном на конкарренси. тикет открыт уже много лет. бывают такие wtf
Ещё одно доказательство моей теории. Атомики это очень сложно.
Чтобы их использовать и не развалить всю систему нужно очень хорошо уметь думать. ЦА го на такое и близко не способна.
Для сравнения https://doc.rust-lang.org/std/sync/atomic/
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И главное авторы раста делают язык для умных людей, которые способны освоить мощные инструменты предоставляемые растом.
Предлагаю названия для таких людей: плюсоголики и растофилы.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
WH>Это язык для слабых программистов. Это самое политкорректное выражение которое я смог подобрать.
Писать просто несколько сложнее чем кажется
WH>У go даже эмблема со зверюшкой, у которой явно синдром дауна.
Спасибо за анализ. Я замечал что растаманы активные, а они еще и злобные оказывается
Дерьмо этот rust редкостное. Ещё большее дерьмо, чем Go.
Основное предназначение Go-это ЯП, который бы позволял менять программистов на проекте без ущерба для него. Он специально заточен под то, чтоб разрабам, пришедшим на проект, можно было легко и быстро въехать в существующий код, и, не разбираясь в хитровывернутых синтаксических конструкциях, которые нагородили до него всякие гуру, сосредоточиться на развитии бизнес логики. Именно за это его качестве, Go в крупных компаниях позиции завоёвывает просто бешенными темпами (именно для этого его в гугле и создали). На Go там уже пишутся и переписываются вещи, которые очень далеко не примитивные, и назвать людей, их разрабытвающих и ими занимающихся, даунами может только тот, кто сам даун.
A rust-это очередная игрушка для красноглазых, которые не осилили C++. Никому он нафиг не нужен.
Да... здорово у вас полыхнуло. Не ожидал что настолько в точку попаду.
S>Дерьмо этот rust редкостное. Ещё большее дерьмо, чем Go.
Не осилил? Бывает.
S>Основное предназначение Go-это ЯП, который бы позволял менять программистов на проекте без ущерба для него. Он специально заточен под то, чтоб разрабам, пришедшим на проект, можно было легко и быстро въехать в существующий код, и, не разбираясь в хитровывернутых синтаксических конструкциях, которые нагородили до него всякие гуру, сосредоточиться на развитии бизнес логики.
У меня на освоение раст ушел день. На освоение большого проекта на любом языке нужен не один месяц.
Но я не репрезентативен. Я очень много языков изучил. Тем не менее, для нормального программиста там неделя на освоение максимум.
Главная проблема borrow checker всё остальное весьма распространено в других языках.
S>Именно за это его качестве, Go в крупных компаниях позиции завоёвывает просто бешенными темпами (именно для этого его в гугле и создали).
Крупная корпорация -> много случайных людей...
А если корпорация ещё и американская то там есть квоты на разнообразие сотрудников.
Это не шутки. Там всё серьёзно.
Там это уже на законодательном уровне https://corpgov.law.harvard.edu/2018/10/16/the-california-board-diversity-requirement/
А просто толпы беснующихся SJW уже давно всех терроризируют.
Ну и рейдерский захват линукса тоже забывать не стоит.
S>На Go там уже пишутся и переписываются вещи, которые очень далеко не примитивные, и назвать людей, их разрабытвающих и ими занимающихся, даунами может только тот, кто сам даун.
Это не я выбрал логотип для го.
И данная ассоциация у меня возникла сразу, как я этот логотип увидел.
Тогда я подумал, что просто проблемы со вкусом. Что меня не удивило, ибо язык ужасен.
Но теперь вижу что авторы тонко и очень злобно тролят.
Кстати неспособность отделить обсуждение логотипа от обсуждения разработчиков...
S>A rust-это очередная игрушка для красноглазых, которые не осилили C++. Никому он нафиг не нужен.
С++ я осилил лучше чем 99% разработчиков на С++.
Там вообще ничего сложного нет. Нужно просто очень внимательным быть. Всегда. И это очень напрягает.
Раст сложнее и мощнее. Но не требует внимательности. Совсем.
Что после освоения его системы типов позволяет писать, совершенно не напрягаясь. Я знаю, что если сделаю что-то не так, то получу по рукам.
Иногда не заслужено. Но это редко и не сложно исправить. А с приходом non-lexical lifetimes будет ещё реже.
И это делает его лучшим языком для низкоуровнего кода.
Для сложной логики ГЦ конечно удобнее, а иногда и просто необходим. Но таких задач мало. Так что на расте можно писать почти всё.
В этом смысле он намного проще, чем го. Ибо го ни от чего не защищает. ГЦ конечно обклеивает стены матрасами но гарантий всё равно никаких, особенно в случае с многопоточностью.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexRK, Вы писали:
ARK>Всё, немерле уже не нужен?
Нужен. Просто для других задач.
Если до появления раста я видел нишу для С/С++ то теперь эти языки в моих глазах окончательно мертвы.
Нет никаких причин начинать на них новые проекты.
Раст просто объективно лучше по всем параметрам.
ARK>Мое ИМХО, кстати, что идеальный язык вполне может представлять собой нечто среднее между растом и го.
И что там тогда от го останется?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Да... здорово у вас полыхнуло. Не ожидал что настолько в точку попаду.
В какую точку? В себе льстите. Я старый сишник и лиспер. По мне так все ЯП-ы дерьмо по сравнению с чистым Cи и Lisp-ом. Но rust и go изучал, чисто для прикола. Повторю, rust ещё большее дерьмо чем Go. А ту мысль выражу иначе: менеджеры выберут Go, а не rust. Так что, если кто хочет работать в найме у менеджеров, пусть лучше пишет на Go, а не на rust.
WH>С++ я осилил лучше чем 99% разработчиков на С++. WH>Там вообще ничего сложного нет. Нужно просто очень внимательным быть. Всегда. И это очень напрягает.
В С++ можно написать сложно, так сложно, что это прочитать никто не сможет. В Go так нельзя, не получится.
WH>Раст сложнее и мощнее. Но не требует внимательности. Совсем.
Раст-быдлоязык, коих видел уже кучи. Как появился, так и исчезнет, если бизнес этот ЯП не поддержит. А не поддержит он его по уже высказанным причинам.
Здравствуйте, WolfHound, Вы писали:
ARK>>Всё, немерле уже не нужен? WH>Нужен. Просто для других задач.
И что же — из распространенных задач — можно сделать на немерле, чего нельзя на расте?
WH>Если до появления раста я видел нишу для С/С++ то теперь эти языки в моих глазах окончательно мертвы. WH>Нет никаких причин начинать на них новые проекты. WH>Раст просто объективно лучше по всем параметрам.
Помимо технических параметров есть и нетехнические.
Кроме того, раст гораздо сложнее Ц — это тоже минус.
ARK>>Мое ИМХО, кстати, что идеальный язык вполне может представлять собой нечто среднее между растом и го. WH>И что там тогда от го останется?
Здравствуйте, smeeld, Вы писали:
WH>>Да... здорово у вас полыхнуло. Не ожидал что настолько в точку попаду. S>В какую точку? В себе льстите.
То-то тут целая толпа прибежала рассказать мне как я вам всем безразличен.
А у тебя зарево такое, что его из космоса видно.
Подумать только кто-то посмел похвалить язык, который ты не понял.
S>Я старый сишник и лиспер. По мне так все ЯП-ы дерьмо по сравнению с чистым Cи и Lisp-ом.
Это очень много о тебе говорит.
Си это переносимый ассемблер, минное поле, где вообще никакой защиты нет. Лисп, динамически типизированный язык. Та же фигня только ещё и тормозная.
Но обе создают у программистов ложное чувство крутизны и контроля.
При этом если в момент своего появления Си имел смысл с инженерной точки зрения (хотя бессмысленных косяков там тоже хватает), то динамически типизированные языки всегда плохой выбор.
Ещё ни один человек не смог мне продемонстрировать задачу, при решении которой они лучше.
Я же люблю писать корректный код. И я знаю, что человек без помощи компилятора на это не способен.
Вот поэтому мне очень нравится раст. Он делает некоторые классы ошибок невозможными. И именно эти классы ошибок самые сложные в починке и диагностике.
И многие другие классы ошибок практически недостижимыми за счёт того что позволяет явно выражать свои намеренья на уровне системы типов.
При этом раст оставляет тот же уровень контроля, что и Си. Только по невнимательности накосячить нельзя. И память он без подсказок освобождает, убирая кучу мусора из кода.
А если раст ещё и с Dafny скрестить, добавить эффекты и заменить макросы на нитру будет вообще сказка.
S>В С++ можно написать сложно, так сложно, что это прочитать никто не сможет. В Go так нельзя, не получится.
А можно писать проще, чем на го. И при этом иметь намного больше статических гарантий корректности кода.
Но для этого нужно знать С++. А не смотреть на него как на С с непонятными конструкциями.
Вот только на раст можно писать ещё проще и гарантии там 100%'ные. Что очень сильно снижает когнитивную нагрузку.
S>Раст-быдлоязык, коих видел уже кучи.
И это по твоему не полыхает?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexRK, Вы писали:
ARK>И что же — из распространенных задач — можно сделать на немерле, чего нельзя на расте?
В расте нет ГЦ. Если логика сложная без него грустно.
При этом если сделать язык с поддержкой регионов памяти на уровне типов, то можно будет запускать ГЦ только в небольшой части программы не трогая остальную.
Как это интегрировать в раст чтобы не поломать кучу кода я пока не придумал.
Главная проблема: в расте очень строго определено время жизни объектов. И я уверен, куча unsafe кода на это завязана.
Но если делать язык с нуля, то точно можно скрестить borrow checker и регионы памяти.
И вот тогда я первый побегу закапывать немерле. При прочих равных, конечно же.
А так оба языка полны по Тьюрингу, а значит эквивалентны.
ARK>Помимо технических параметров есть и нетехнические. ARK>Кроме того, раст гораздо сложнее Ц — это тоже минус.
В первую неделю. А потом намного проще.
Конечно, если ты ковбой, которому наплевать на качество кода то раст всегда будет сложнее. Но я так не могу. Если я не уверен, что код корректен, я сплю плохо.
ARK>>>Мое ИМХО, кстати, что идеальный язык вполне может представлять собой нечто среднее между растом и го. WH>>И что там тогда от го останется? ARK>Простота, небольшое количество базовых фич.
Приборы. 42. Что 42? А что приборы?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А у тебя зарево такое, что его из космоса видно. WH>Подумать только кто-то посмел похвалить язык, который ты не понял.
Не понял, не понял, только спокойно, не волнуйтесь (не спеша покидает помещение, покручивая пальцем у виска)
Здравствуйте, andmed, Вы писали:
A>Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю
A>Плюсы: A>- авторы языка позиционируют его как ... язык системного программирования. не ядра наверняка, но все равно, сишники вряд ли с ними согласятся. по мне — дернуть системный вызов, обернув вокруг него какую-то логику, без JNI, jvm и т.п. удобно, да. в итоге интересный эффект: если в java профессиональный рост возможен только "вверх по стеку" (архитектура, энтерпрайз) то в го вполне можно заниматься полезными вещами, в сторону системы. кмк плюс
А так разве можно в Go просто дернуть системный вызов?
Там вроде для вызова системных вызовов нужно отдельный пул потоков городить и прочее,
потому что корпоративная многозадачность пойдет лесом, если прямо взять и вызвать системный
вызов который потенциально может текущий поток усыпить на неопределенное количество времени.
S>>Дерьмо этот rust редкостное. Ещё большее дерьмо, чем Go. WH>Не осилил? Бывает.
Зачем тратить усилия на переусложненный инструмент, если нужный результат можно получить проще. Rust по сравнению с C переусложнен, а до возможностей C++ он не дорос и никогда не дорастет (он уже сейчас сложен, если в него добавить то, что есть в C++, он станет неподъемно сложен). Rust инструмент нишевой для фанатиков — любителей головоломок и тем, кому хочется попробовать что-то новое. Ну и до кучи, в коммерческом программировании разработчики выбирают инструмент, чтобы решить задачу, а не для того, чтобы гордиться, что они там что-то "осилили". То, ради чего в Rust приходится в каждой строчке бороться с borrow checker (и включать unsafe, когда побороть его не получается, например, для двусвязного списка), в C++ решается использованием статического анализатора типа coverity. Людей, которые борются со своим инструментом разработки (с переменным успехом) и гордятся, когда "осиливают" его, я уже давно перестал понимать.
A>Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю
Посмотри в сторону Kotlin. Он есть в варианте для JVM (можно в проекте совмещать код на Java и Kotlin), Native (Linux, Windows, Mac, iOS, можно совмещать с кодом на C и Swift) и еще JS (но эта экзотика для тех, кто хочет фронтэнд и бэкэнд писать на одном языке). Во всех вариантах будет работать сборка мусора, даже на Native Mac или Linux.
M>Посмотри в сторону Kotlin. Он есть в варианте для JVM (можно в проекте совмещать код на Java и Kotlin), Native (Linux, Windows, Mac, iOS, можно совмещать с кодом на C и Swift) и еще JS (но эта экзотика для тех, кто хочет фронтэнд и бэкэнд писать на одном языке). Во всех вариантах будет работать сборка мусора, даже на Native Mac или Linux.
Привет. Котлин нравится. Делали бэкенд на нем. Хорошо заходит в e-commerce но замечания в большинстве относятся и к нему.
В целом он как бы "вверх от джавы", го — вниз
Здравствуйте, Zhendos, Вы писали:
Z>А так разве можно в Go просто дернуть системный вызов?
без проблем
Z>Там вроде для вызова системных вызовов нужно отдельный пул потоков городить и прочее, Z>потому что корпоративная многозадачность пойдет лесом, если прямо взять и вызвать системный Z>вызов который потенциально может текущий поток усыпить на неопределенное количество времени.
пул потоков — это не про го вообще. там другие абстракции. "пулирование" можно просимулировать, ограничив число горутин (горутина != потоку)
на возможность делать системный вызов не влияет
Z>Там вроде для вызова системных вызовов нужно отдельный пул потоков городить и прочее, Z>потому что корпоративная многозадачность пойдет лесом, если прямо взять и вызвать системный Z>вызов который потенциально может текущий поток усыпить на неопределенное количество времени.
а да. у них там есть corner cases. приняли пропосал https://github.com/golang/go/issues/24543 про preemptive вытеснение, должно помочь.
поэтому и написал в большинстве "простых" работает хорошо ж)
Здравствуйте, Masterspline, Вы писали:
M>Зачем тратить усилия на переусложненный инструмент, если нужный результат можно получить проще
Тоже самое наверное когда-то про позиционные системы исчисления говорили, ну а что, на пальцах ж проще считать, особенно когда все задачи уровня пересчитать с десяток баранов
Здравствуйте, Masterspline, Вы писали:
M>Зачем тратить усилия на переусложненный инструмент, если нужный результат можно получить проще.
Практика показывает что нельзя. Получается протекающий и падучий багадром, в котором постоянно уязвимости находят.
Собственно по этому раст и появился. Разработчики огнелиса очень хотели сделать некоторые оптимизации, но им было очень страшно. Ибо человек просто физически не способен держать в памяти все связи в сложном коде. А компилятор может. Он туп, но имеет абсолютную внимательность.
M>Rust по сравнению с C переусложнен,
А с моей точки зрения в расте не хватает многих фич.
Правда не из С++, а из сильно других языков.
M>а до возможностей C++ он не дорос и никогда не дорастет (он уже сейчас сложен, если в него добавить то, что есть в C++, он станет неподъемно сложен).
А вот с этого места подробнее.
Что такое может С++ чего не может раст?
M>Rust инструмент нишевой для фанатиков — любителей головоломок и тем, кому хочется попробовать что-то новое. Ну и до кучи, в коммерческом программировании разработчики выбирают инструмент, чтобы решить задачу, а не для того, чтобы гордиться, что они там что-то "осилили". То, ради чего в Rust приходится в каждой строчке бороться с borrow checker
Напрягал он меня только в первый день.
Дальше только помогал.
В более 90% кода я его просто не замечал. Я на нем реально писал как на немерле с немного другим синтаксисом.
Может опыт разработки на С++ просто приучил меня не делать UB вот раст меня и не напрягает.
M>(и включать unsafe, когда побороть его не получается, например, для двусвязного списка),
Зачем тебе двусвязный список?
Мне, правда, интересно. Я написал очень много сложных алгоритмов и двусвязный список не использовал ни разу.
M>в C++ решается использованием статического анализатора типа coverity. Людей, которые борются со своим инструментом разработки (с переменным успехом) и гордятся, когда "осиливают" его, я уже давно перестал понимать.
Просто, прежде чем писать на языке, нужно понять его философию. Тогда ты сможешь брать этот язык под задачу, которую на нём хорошо решать. И будешь её решать в том стиле, который поощряет данный язык. Тогда и бороться будет не с чем.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, andmed, Вы писали:
WH>>У go даже эмблема со зверюшкой, у которой явно синдром дауна. A>Спасибо за анализ. Я замечал что растаманы активные, а они еще и злобные оказывается
Здравствуйте, andmed, Вы писали:
A>- обработка ошибок. например у меня передается буфер и я делаю в методе несколько записей в него. мне все равно на какой по счету записи я сфейлюсь, мне нужно выкинуть ошибку а количество записанных символов не важно (ответ по http скажем шлем). так бы я поставил try/catch и все, а в го нужно If на каждую запись. и дело не в сборке стека. если в го есть семантика сигнализирования об ошибке то хотелось бы механизмы удобной их аггрегации и без сбора стека A>- традиционно сюда относят отсутствие дженериков.
Это будет поправлено в следующих версиях, сейчас идут обсуждения и эксперименты. В целом, по прикидкам получится неплохо.
A>- долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction
Умеет, в Go сейчас точный GC с уплотнением. Он также умеет возвращать память обратно системе.
A>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем.
Есть atomic.Value и сотоварищи.
A>- управление зависимостями. тема известная. авторы языка не сидят на месте. здесь пусть выскажутся те, кто пишут большие проекты в продакшн с многими зависимостями. вроде как работа ведется постоянно. без конфликтующих зависимостей проблем нет как с GOPATH так и с новыми модулями (с модулями есть баги, допиливают)
Новая система модулей вполне логичная, ничем не хуже Maven для JVM. Про модули в Java 10 я вообще умолчу — уродство ещё то.
A>- девелоперское сообщество. когда пытаются перенести практику ООП. с интерфейсами и тайп кастингом в го можно можно накрутить, но в таких случаях непонятно, зачем берут именно го, если нужен энтерпрайз то это другие языки. на го это получается.. плохо
Не надо на Go писать в стиле Java. Собственно, и на Java не надо писать в стиле Java.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, andmed, Вы писали:
A>>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. C>Есть atomic.Value и сотоварищи.
физически они-то есть конечно, но на них гарантий нет. то есть разработчики не гарантируют их работу (например, в части оптимизаций компилятора и видимости других переменных). https://golang.org/ref/mem
Здравствуйте, andmed, Вы писали:
A>>>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. C>>Есть atomic.Value и сотоварищи. A>физически они-то есть конечно, но на них гарантий нет.
Есть. atomic.Value гарантированно работает. Нет гарантий, если делать присваивания вручную.
Здравствуйте, Cyberax, Вы писали:
Ops>>Атомарность есть, а барьеров нет. Хрен знает, что там компилятор и/или процессор переупорядочит. Все же привычный atomic — это еще и барьеры. C>atomic.Value является барьером, он не переупорядочивается. Все методы в atomic аннотированы как //go:noinline. Это планируется официально кодифицировать как барьер, но у пока разработчиков руки не дошли ( https://github.com/golang/go/issues/5045#issuecomment-412714313 ). На практике всё работает.
Тут скорее речь о том, что в том же C++ ты можешь явно задать тип синхронизации (хрен знает как по-русски правильно будет) атомарных переменных: https://en.cppreference.com/w/cpp/atomic/memory_order. В Go, похоже что, по умолчанию везде встроенна модель аналогичная std::memory_order_seq_cst.
Здравствуйте, kaa.python, Вы писали:
KP>Тут скорее речь о том, что в том же C++ ты можешь явно задать тип синхронизации (хрен знает как по-русски правильно будет) атомарных переменных: https://en.cppreference.com/w/cpp/atomic/memory_order. В Go, похоже что, по умолчанию везде встроенна модель аналогичная std::memory_order_seq_cst.
Да, именно так. В Go всё очень примитивно, хотя в стандартной библиотеке и рантайме используются более продвинутые механизмы. Можно и самому, но это будет уже зависимость от деталей работы компилятора.
KP>Тут скорее речь о том, что в том же C++ ты можешь явно задать тип синхронизации (хрен знает как по-русски правильно будет) атомарных переменных: https://en.cppreference.com/w/cpp/atomic/memory_order. В Go, похоже что, по умолчанию везде встроенна модель аналогичная std::memory_order_seq_cst.
вот ведь.. в плюсах подробная документация. спасибо за ссылку!
Здравствуйте, WolfHound, Вы писали:
WH>Нужна не скорость, а параллельность, инкрементальность и спекулятивность (это когда ИДЕ компилирует код, пока ты пишешь). В этом случае даже если ты начал работать с проектом, в котором гигабайт исходников то компиляция завершиться мгновенно.
К сожалению, это фантазии, который не практике не работают. Инкрементальность не дает гарантированно быстрой компиляции при изменении любого участка кода. А если этого нет, будет возникать куча ситуаций в процессе разработки, когда программист из команды поменял одну строчку кода, и у всех полностью перекомпилируется проект. Единственный способ бороться с долгой компиляцией (инкрементальной в том числе) — делать как можно меньше зависимостей между компонентами, и компилировать их отдельно. Какие бы хорошими ни были программисты, если сам по себе язык не способствует написанию слабо связного кода (loosely coupled), то любой большой проект скатится к долгой компиляции. А не способствуют этому все ООП языки. В rust в этом плане плохо сделаны traits, поскольку при описании реализации нужно явно указывать имя trait. В интерфейсах Go реализован duck typing вместо явного указания интерфейса при описании реализации, что уменьшает связность кода. Но в Go много других проблем. Нет дженериков например.
По-хорошему в языке должен быть единый синтаксис для описания обобщенных конструкций, должны быть контракты, которые накладывают ограничения на множество типов одновременно, а не по контракту на каждый отдельный тип (интерфейсы, traits). В зависимости от режима компиляции (можно добавить PGO, JIT) должен автоматически выбираться динамический или статический способ реализации обобщенных функций. В крайнем случае можно добавлять необязательные подсказки компилятору. Это позволит как сократить объем генерируемого машинного кода и отладочной информации (в случае динамической реализации), что напрямую влияет на время компиляции, так и оптимизировать узкие места (статическая реализация).
Пока ни Go, ни Rust не являются идеальными языками. В Go решали (и частично решили) проблему со сложностью кода проектов и скоростью компиляции, но не реализовали часть других нужных фичей. Кроме этого, из-за сборки мусора язык не может быть системным или подходящим для высокопроизводительных приложений. В Rust решали проблему безопасного управления памятью без накладных расходов в runtime. Проблему эту решили, но с точки зрения простоты кода и монолитности (я не имею в виду локальную сложность, связанную с borrow checker) кода язык не далеко ушел от C++. Как мне кажется, в больших проектах на С++ на миллионы строк основная проблема не безопасная работа с памятью. При достаточной квалификации программистов и использовании различных инструментов для тестирования (санитайзеры, фаззеры) ошибки работы с памятью отлавливаются. Основная проблема в нарастающей сложности проекта и замедлении разработки.
Здравствуйте, Aleх, Вы писали:
A>К сожалению, это фантазии, который не практике не работают. Инкрементальность не дает гарантированно быстрой компиляции при изменении любого участка кода. А если этого нет, будет возникать куча ситуаций в процессе разработки, когда программист из команды поменял одну строчку кода, и у всех полностью перекомпилируется проект.
Вот тут ты не прав. У всех не будет.
Будет у одного. Причем он будет использовать для этого все машины в конторе.
А когда остальные обновляться, то всё уже будет скомпилировано. К ним бинарники по гигабитной сетке приедут.
A>Единственный способ бороться с долгой компиляцией (инкрементальной в том числе) — делать как можно меньше зависимостей между компонентами, и компилировать их отдельно. Какие бы хорошими ни были программисты, если сам по себе язык не способствует написанию слабо связного кода (loosely coupled), то любой большой проект скатится к долгой компиляции. А не способствуют этому все ООП языки. В rust в этом плане плохо сделаны traits, поскольку при описании реализации нужно явно указывать имя trait. В интерфейсах Go реализован duck typing вместо явного указания интерфейса при описании реализации, что уменьшает связность кода. Но в Go много других проблем. Нет дженериков например.
Теперь попробуй придумать сценарий, в котором в случае с go не придётся все перекомпилировать, а в случае с раст придётся.
И главное оцени его реалистичность.
Ну и не забывай что трейты в расте намного мощнее.
Например, можно прицепить к типу свой трейт. Даже если это не твой тип.
Далее можно реализовывать трейты для трейтов. Таким образом, если ты реализовал один трейт то в подарок получаешь ещё несколько.
А когда у нас появляются генерики, то всё становиться ещё интереснее.
Реализацию трейтов можно сделать зависимой от того какие трейты реализуют параметры типа.
A>Ещё в rust некрасивая двойственность синтаксиса:
хъ A>По-хорошему в языке должен быть единый синтаксис для описания обобщенных конструкций,
Небольшой сахарок. Не более того. Вообще не проблема.
И вообще данная фича используется почти исключительно для возвращения итераторов из функций.
A> должны быть контракты, которые накладывают ограничения на множество типов одновременно, а не по контракту на каждый отдельный тип (интерфейсы, traits).
Пример можно?
Если это что-то интересное, то можно в раст RFC запилить. Если плюшки будут стоить мороки с реализацией то наверняка сделать.
Там даже non lexical lifetimes сделали. А мороки с ними очень много.
Правда, до стабильной версии они ещё не доехали, но как я понял из переписки это вопрос ближайшего времени.
A>Пока ни Go, ни Rust не являются идеальными языками.
Это вообще не возможно. Для каждой задачи оптимальным является язык заточенный для этой задачи.
A>В Go решали (и частично решили) проблему со сложностью кода проектов и скоростью компиляции, но не реализовали часть других нужных фичей.
Они решили задачу использования программистов, для которых вот это
for trans in state_set.iter()
.flat_map(|state| vars.signal_transitions.get(state))
.flatten()
нереально сложный код.
При этом в реальности код проектов становится сложнее. Ибо если переписать это на циклах, то тут будет гора кода.
A>В Rust решали проблему безопасного управления памятью без накладных расходов в runtime. Проблему эту решили, но с точки зрения простоты кода и монолитности (я не имею в виду локальную сложность, связанную с borrow checker) кода язык не далеко ушел от C++.
Монолитность кода зависит исключительно от разработчиков, а не от языка.
Есть, конечно, языки где нет возможности декомпозировать код. Там всё плохо. Но раст и С++ к ним не относятся.
A>Как мне кажется, в больших проектах на С++ на миллионы строк основная проблема не безопасная работа с памятью. При достаточной квалификации программистов и использовании различных инструментов для тестирования (санитайзеры, фаззеры) ошибки работы с памятью отлавливаются. Основная проблема в нарастающей сложности проекта и замедлении разработки.
Каждый раз, когда кто-то начинает разговор в стиле git gud то люди открывают его код или трекер и сразу находя кучу ошибок, которые может устранить более умный язык.
Рискнёшь свой код показать?
Проблема больших проектов в том, что они создают очень большую ментальную нагрузку. Которая умножается на ментальную нагрузку создаваемую языком.
А раст по сравнению с С++ создаёт намного меньшую ментальную нагрузку даже в обычном коде. А когда дело доходит до многопоточности разница просто колоссальная.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
A>>- долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction C>Умеет, в Go сейчас точный GC с уплотнением. Он также умеет возвращать память обратно системе.
не смог найти упоминания compaction в гошном gc. наоборот, здесь прямо разрешается передача пойнтеров в сишный код, что при уплотнении было бы небезопасно https://golang.org/cmd/cgo/#hdr-Passing_pointers
для больших данных не менее важно и то что гошный gc не generational. вижу много жалоб на медленную работу гц при больших мапах. там же есть некоторые решения, но для себя сделал вывод что пытаться с го работать с большим хипом — это использование этого языка не по назначению. пока не впилят generational гц (и если, да)
Здравствуйте, andmed, Вы писали:
A>>>- долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction C>>Умеет, в Go сейчас точный GC с уплотнением. Он также умеет возвращать память обратно системе. A>не смог найти упоминания compaction в гошном gc.
Действительно, я ошибся. GC в Go точный (не консервативный) и параллельный, но не уплотняющий: https://golang.org/src/runtime/mgc.go
A>наоборот, здесь прямо разрешается передача пойнтеров в сишный код, что при уплотнении было бы небезопасно https://golang.org/cmd/cgo/#hdr-Passing_pointers
C code may not keep a copy of a Go pointer after the call returns. This includes the _GoString_ type, which, as noted above, includes a Go pointer; _GoString_ values may not be retained by C code.
Рантайм автоматически пришпиливает указатели при вызове С-кода.
Здравствуйте, Zhendos, Вы писали:
Z>А так разве можно в Go просто дернуть системный вызов?
Да, можно.
Z>Там вроде для вызова системных вызовов нужно отдельный пул потоков городить и прочее, Z>потому что корпоративная многозадачность пойдет лесом, если прямо взять и вызвать системный Z>вызов который потенциально может текущий поток усыпить на неопределенное количество времени.
Это все автоматически делается под капотом, совершенно прозрачно для программиста (но не бесплатно, к сожалению).
Не ожидал что настолько в точку попаду. 
