Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю
Плюсы:
— свежим глотком после 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. Людей, которые борются со своим инструментом разработки (с переменным успехом) и гордятся, когда "осиливают" его, я уже давно перестал понимать.
Не ожидал что настолько в точку попаду. 
