Re: Nim lang
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 10.12.18 21:40
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Вполне секси, очень изящно можно использовать код на С, транслируется в него же. Какие же фатальные недостатки мешают ему стать популярным?


Прочитал весь топик. Решил посмотреть, о чем вообще речь — Nim, Go, Rust...

На работе некоторые коллеги подрачивают на раст, решил начать с него.

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

Скучно. Скучно и уныло. И что, вот на таких вот языках сейчас всё (или большую часть) продакшена пишут?

ЗЫ На что только люди не пойдут, лишь бы не изучать плюсики
Маньяк Робокряк колесит по городу
Re[2]: Nim lang
От: alex_public  
Дата: 10.12.18 21:53
Оценка:
Здравствуйте, Marty, Вы писали:

M>Прочитал весь топик. Решил посмотреть, о чем вообще речь — Nim, Go, Rust...


Только всё же Rust, D, Nim, если смотреть по порядку популярности... А вот Go не из этой песочницы — это управляемый язык, так что заменой C++ не может служить в принципе.

M>Прочитал за день RTPL. Ну — питон, да, только не такой анальный, чутка типизации есть, типа круто, и не трахают отступами. На работе пообщался с поклонниками раста — узнал, что борров чекинг, маттерн матчинг и что-то еще (а, да, еще ужебанские макросы) — это мега киллер фичи.


Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )
Re[3]: Nim lang
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 10.12.18 22:34
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Только всё же Rust, D, Nim, если смотреть по порядку популярности... А вот Go не из этой песочницы — это управляемый язык, так что заменой C++ не может служить в принципе.


Почему не может?


M>>Прочитал за день RTPL. Ну — питон, да, только не такой анальный, чутка типизации есть, типа круто, и не трахают отступами. На работе пообщался с поклонниками раста — узнал, что борров чекинг, маттерн матчинг и что-то еще (а, да, еще ужебанские макросы) — это мега киллер фичи.


_>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )


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

Раст произвел впечатление языка, который худо-бедно решает пару-тройку проблем из плюсового мира, напрочь отсекая все остальные возможности. А те проблемы, которые он решает — кажутся как минимум несколько надуманными. Ну, после питона наверно можно и растом попробовать пользоваться, благо нет анальных ограждений в виде отступов. Но ничего другого он не предлагает.
Маньяк Робокряк колесит по городу
Re[4]: Nim lang
От: alex_public  
Дата: 10.12.18 23:22
Оценка: +1
Здравствуйте, Marty, Вы писали:

_>>Только всё же Rust, D, Nim, если смотреть по порядку популярности... А вот Go не из этой песочницы — это управляемый язык, так что заменой C++ не может служить в принципе.

M>Почему не может?

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

_>>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )

M>А можно с примерами? Из доки как-то не очевидно. Дока вообще на полных ньюбов походу расчитана. Мне потом подсказали, что то, что меня заинтересовало, бульменее описано в каком-то супер-пупер адвансед кук-буке.

Примерами чего?

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


Нет, концептуально Rust может всё тоже самое, что и C++ и даже больше. Сейчас правда ситуация не такая, потому что его оптимизатор не способен пока бороться с C++ (даже с учётом использования llvm), многие библиотеки не доделаны, инструменты не доработаны и т.п. Но, как ты понимаешь, это всё временные проблемы и со временем всё станет как минимум на уровне C++, поскольку концепция (низкоуровневость) позволяет. Проблемы (на мой взгляд) у Rust немного в другом (см. ниже).

M>А те проблемы, которые он решает — кажутся как минимум несколько надуманными.


Rust оригинально решает ровно одну задачу: гарантированное управление памятью без сборщика мусора. Для C++ программистов это проще всего объяснить как встроенные в компилятор подобия unique_ptr, shared_ptr и другие, причём являющиеся единственным инструментом работы с памятью в safe режиме. В теории это всё звучит отлично, но на практике приводит к такому количеству "лишнего" кода, что на мой вкус цена таких гарантий становится слишком высока. Однако многие со мной не согласны и готовы платить такую цену за гарантии компилятором.

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


Ха))) Несмотря на в чём-то похожий синтаксис, Rust концептуально является скорее противоположностью Питона. Во всяком случае если говорить о практике. На Питоне решение задачи обычно самое быстрое (в смысле написание, я не исполнения кода). На C++ для решения той же задачи потребуется заметно больше усилий (хотя она и работать будет намного эффективнее). А на Rust'е потребуется написать ещё больше кода, чем на C++, при сравнимой производительности. Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).
Re[5]: Nim lang
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 10.12.18 23:50
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ха))) Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).


Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.
Отредактировано 10.12.2018 23:50 kaa.python . Предыдущая версия .
Re[6]: Nim lang
От: alex_public  
Дата: 11.12.18 00:16
Оценка: 1 (1)
Здравствуйте, kaa.python, Вы писали:

_>>Ха))) Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).

KP>Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.

Ничего даже близкого там нет. Есть только простейшая возможность обеспечить гарантированно не одновременный доступ на запись к одной области памяти из нескольких потоков. https://doc.rust-lang.org/nomicon/races.html

Насколько малый процент всех возможных случаев возникновения дедлоков покрывает данное решение, думаю ты и сам прекрасно представляешь...
Re[7]: Nim lang
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 11.12.18 00:31
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ничего даже близкого там нет. Есть только простейшая возможность обеспечить гарантированно не одновременный доступ на запись к одной области памяти из нескольких потоков. https://doc.rust-lang.org/nomicon/races.html


ааа, это банальные атомарные операции, я почему-то ожидал чего-то сопоставимого с гарантиями по памяти

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


Да, жаль, конечно
Re[6]: Nim lang
От: so5team https://stiffstream.com
Дата: 11.12.18 05:55
Оценка: 3 (1)
Здравствуйте, kaa.python, Вы писали:

KP>но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.


Не дедлоков (с этим Rust не может справится в принципе), а гонок. В дополнение к ссылке, которую уже дали, вот еще одна ссылка для общего понимания: https://doc.rust-lang.org/book/ch16-03-shared-state.html (ну и еще до кучи: https://doc.rust-lang.org/book/ch16-04-extensible-concurrency-sync-and-send.html).
Re[4]: Nim lang
От: Слава  
Дата: 11.12.18 06:19
Оценка: +2
Здравствуйте, Marty, Вы писали:

_>>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )


M>А можно с примерами? Из доки как-то не очевидно. Дока вообще на полных ньюбов походу расчитана. Мне потом подсказали, что то, что меня заинтересовало, бульменее описано в каком-то супер-пупер адвансед кук-буке.


"Бульменее"
Ты б более серьёзно отнёсся к прочитанному, тогда возможно и увидел бы и типизацию, и прочее. А то ты пишешь тут на албанском в духе "встал-посрал", книгу он за день прочитал и ничего не понял. Читать надо медленнее. Если ты глядишь в книгу и видишь фигу, то виноват в этом ты, а не книга, и не язык, которому она посвящена.
Отредактировано 11.12.2018 6:39 Слава . Предыдущая версия .
Re[14]: Nim lang
От: WolfHound  
Дата: 11.12.18 19:24
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Кстати, могу рассказать некий забавный момент. Я был знаком с парочкой C++ программистов, которые утверждали что их напрягает использование unique_ptr своей излишней многословностью (в каком-то смысле тем самым мусорным кодом) — типа с голыми указателями код выглядит более лаконично и читаемо. Так вот я послал их изучить как выглядит работа с памятью в Rust... Они ТАК впечатлились увиденным, что после этого начали считать unique_ptr идеалом удобства при работе с памятью.

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

_>P.S. Тут в соседней темке подкинули забавную ссылку (http://smallcultfollowing.com/babysteps/blog/2018/11/10/after-nll-moving-from-borrowed-data-and-the-sentinel-pattern/) почти по теме. Хотя там уже не про "мусорный код", а про архитектурные проблемы, но и то и то происходит из одной первопричины — излишнее переусложнее базовой концепции.

Тут скорее недоусложнение.
Они пытаются на этапе компиляции определить момент удаления каждого объекта. Делают они это при помощи построения дерева владения.

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

А в совсем клинических случаях нужен ГЦ. Чтобы он не мешал нужно разделять программу на легковесные процессы, что позволит собирать мусор в каждом процессе отдельно.
Причем по умолчанию ГЦ можно выключить. И по желанию программиста либо включить в автоматически режиме. Либо запускать вручную в те моменты, когда известно, что большая часть мусора была зачищена детерминированным удалением.

Ещё одна проблема, которая у них появилась это простота реализации деструктора в каждом объекте. Null тоже появился по тому что было легко сделать. А теперь всем очевидно, что это зло.
Нужно на уровне системы типов разделять объекты с деструкторами и все остальные.
Практика показывает, что это вполне возможно. В .НЕТ хоть и нет поддержки этого на уровне системы типов. Но на уровне соглашений такое разделение есть. И оно мне ни разу не мешало.

Их желание сделать код, в котором гарантированно не будет паники похвально, но боюсь, что тут понадобится что-то типа https://github.com/Microsoft/dafny
Более простые решения работать не будут.
Кроме того для не паникующих функций придётся сделать запрет на выделение памяти и определить максимальный размер стека который нужно будет проверять при вызове не паникующего кода из паникующего. Ибо нехватка памяти и переполнение стека это паника.
Короче для простого кода ограничения слишком сильные. Но для низкоуровневых библиотечных выкрутасов вполне адекватны.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Nim lang
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 11.12.18 20:31
Оценка:
Здравствуйте, kaa.python, Вы писали:

_>>Ха))) Зато если код на Rust всё же заставить скомпилироваться, то можно быть уверенным, что он будет работать правильно (во всяком случае в работе с памятью).


KP>Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.


Да, тоже об этом слышал краем уха. Это действительно выглядит интересно
Маньяк Робокряк колесит по городу
Re[5]: Nim lang
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 11.12.18 20:43
Оценка: :))
Здравствуйте, Слава, Вы писали:


_>>>Хы, ну типизации там не чутка, а побольше чем в C++. Причём настолько, что становится уже неудобно писать... )


M>>А можно с примерами? Из доки как-то не очевидно. Дока вообще на полных ньюбов походу расчитана. Мне потом подсказали, что то, что меня заинтересовало, бульменее описано в каком-то супер-пупер адвансед кук-буке.


С>"Бульменее"

С>Ты б более серьёзно отнёсся к прочитанному, тогда возможно и увидел бы и типизацию, и прочее. А то ты пишешь тут на албанском в духе "встал-посрал", книгу он за день прочитал и ничего не понял. Читать надо медленнее. Если ты глядишь в книгу и видишь фигу, то виноват в этом ты, а не книга, и не язык, которому она посвящена.

Я вполне серьезно сначала относился. Прочитав RTPL так и не понял, в чем прикол, чего народ так на этот раст мастурбирует. Потом мне объяснили, что есть три мега-фичи — борроу-чекинг, паттерн матчинг и крутые макросы. Этим вопросам посвящены мелкие разделы где-то в конце мануала. Я пробежался по ним, но глубоко не вникал — они не показались мне какими-то важными. Даже если эти мега-фичи реально полезны (а я сомневаюсь — на плюсах с некоторой гигиеной борроу-чекинг не нужен; паттерн матчинг вообще непонятно зачем нужен — с минимумом оверхеда реализуется на плюсах — да и вообще не нужно — мне такой функционал раз в пять лет нужен; крутые макросы — возможно получше плюсовых шаблонов, тут — хз), остальной язык какой-то убогий. Это как с питоном — первый день пишешь — вроде всё круто, второй — норм, третий — ну ё-маё, верните мне мои плюсы, я на них быстрее (и по скорости разработки, и по скорости выполнения) напишу.

Как я понял, это мозилла-тормозилла не осилила нормально написать свой бравзер на плюсах, и решили что проще запилить свой язык, и на нем переписать бравзер. И что, таки переписали на расте?
Маньяк Робокряк колесит по городу
Re[13]: Nim lang
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 11.12.18 20:47
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)


А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).
Маньяк Робокряк колесит по городу
Re[13]: Nim lang
От: WolfHound  
Дата: 11.12.18 20:52
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Хотя если у тебя есть время, то советовал бы глянуть с начала, чтобы сравнить с аналогичной реализацией в D (особенно про GPU наверное интересно будет).

По сравнению с этим http://halide-lang.org/ ренжи детский сад ясельная группа.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Nim lang
От: AlexRK  
Дата: 11.12.18 21:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Нужно на уровне системы типов разделять объекты с деструкторами и все остальные.


Что это даст?

WH>Кроме того для не паникующих функций придётся сделать запрет на выделение памяти и определить максимальный размер стека который нужно будет проверять при вызове не паникующего кода из паникующего. Ибо нехватка памяти и переполнение стека это паника.


Можно выделять память без паники, просто с проверкой.
Re[16]: Nim lang
От: WolfHound  
Дата: 12.12.18 01:38
Оценка:
Здравствуйте, AlexRK, Вы писали:

WH>>Нужно на уровне системы типов разделять объекты с деструкторами и все остальные.

ARK>Что это даст?
Позволит удалять объекты пачками, не разбираясь, что там.
Пять пример с тем же результатом работы парсера.
Там вполне может быть клубок из десятков тысяч объектов. Расту придётся при удалении этих объектов потрогать каждый объект чтобы вызвать все деструкторы.
Но там нет деструкторов. Там только память, которую нужно освободить. И если компилятор об этом знает, то он выделит память для этих объектов в одной куче. После чего удалит всю кучу которая состоит из нескольких блоков размером десятки или сотки килобайт.

И что характерно я вообще не могу вспомнить ситуацию, когда объект с деструктором, который делает что-то кроме удаления памяти, был бы не на стеке. Максимум что приходит в голову тонкая обёртка.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Nim lang
От: anton_t Россия  
Дата: 12.12.18 09:54
Оценка:
Здравствуйте, Marty, Вы писали:

M>Здравствуйте, alex_public, Вы писали:



_>>Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)


M>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).


Как на плюсах написать выделенное жирным?
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let p = Point { x: 0, y: 7 };
    let Point { x, y } = p;
    assert_eq!(0, x);
    assert_eq!(7, y);
}
Re[14]: Nim lang
От: alex_public  
Дата: 12.12.18 10:46
Оценка:
Здравствуйте, Marty, Вы писали:

_>>Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)

M>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).

В C++ более менее неплохое сопоставление с образом можно организовать с помощью этой https://github.com/solodon4/Mach7 библиотечки.

Так же с приходом последнего стандарта появилась возможность сделать такой https://en.cppreference.com/w/cpp/utility/variant/visit (см. пример) забавный хак, который по сути является одним из видов сопоставления с образцом.

Однако поддержка данного механизма на уровне конструкций языка безусловно была бы приятнее. Но это естественно совершенно не критичное усовершенствование (скорее синтаксический сахар), так что без него никто особо не страдает.
Re[15]: Nim lang
От: alex_public  
Дата: 12.12.18 10:56
Оценка: +1
Здравствуйте, anton_t, Вы писали:

_>>>Ну наверное продвинутое сопоставление с образцом (pattern matching) не помешало бы. Может ещё что, так навскидку трудно сказать)

M>>А что это такое? В расте, как я понял, это тупой кейс по типу union'а (в плюсах было бы отдельное поле typeTag и по нему бы был case).
_>Как на плюсах написать выделенное жирным?
_>
_>struct Point {
_>    x: i32,
_>    y: i32,
_>}

_>fn main() {
_>    let p = Point { x: 0, y: 7 };
_>    let Point { x, y } = p;
_>    assert_eq!(0, x);
_>    assert_eq!(7, y);
_>}
_>




Данный код записывается на C++ буквально так:
struct Point {
        int32_t x;
        int32_t y;
};

int main()
{
    auto p=Point{0, 7};
    auto [x, y]=p;
    assert(0==x);
    assert(7==y);
}


И к сопоставлению с образом это не имеет ни малейшего отношения. )
Re[8]: Nim lang
От: alex_public  
Дата: 12.12.18 11:30
Оценка:
Здравствуйте, kaa.python, Вы писали:

_>>Ничего даже близкого там нет. Есть только простейшая возможность обеспечить гарантированно не одновременный доступ на запись к одной области памяти из нескольких потоков. https://doc.rust-lang.org/nomicon/races.html

KP>ааа, это банальные атомарные операции, я почему-то ожидал чего-то сопоставимого с гарантиями по памяти

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

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

KP>Да, жаль, конечно

Кое-какие продвижения в данной области наблюдаются как раз в C++ (http://clang.llvm.org/docs/ThreadSafetyAnalysis.html) и помнится ещё в Go что-то было на эту тему. Но в общем случае задача естественно не имеет автоматического решения.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.