Состоялся (https://nim-lang.org/blog/2019/06/06/version-0200-released.html) релиз языка системного программирования Nim 0.20.0 (https://nim-lang.org). Язык использует статическую типизацию и создан с оглядкой на Pascal, C++, Python и Lisp. Исходный код на языке Nim компилируется в представление на C, C++ или JavaScript. В дальнейшем полученный C/C++ код компилируется в исполняемый файл при помощи любого доступного компилятора (clang, gcc, icc, Visual C++), что позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора. По аналогии с Python в Nim в качестве разделителей блоков применяются отступы. Поддерживаются средства метапрограммирования и возможности для создания предметно-ориентированных языков (DSL). Код проекта поставляется (https://github.com/nim-lang/) под лицензией MIT.
Выпуск Nim 0.20 можно рассматривать как кандидат в релизы первой стабильной версии 1.0, включающий несколько нарушающих совместимость изменений, необходимых для формирования первой стабильной ветки, которая зафиксирует состояние языка. Версия 1.0 преподносится как стабильный выпуск с длительным сроком поддержки для которого будет гарантировано сохранение обратной совместимости в стабилизированной части языка. Отдельно в компиляторе также будет доступен экспериментальный режим, в котором будут развиваться новые возможности, которые могут нарушать обратную совместимость.
Из предложенных в Nim 0.20 изменений можно выделить:
- "Not" теперь всегда является унарным оператором, т.е. теперь допускаются выражения вида "assert not a", которые ранее приводили к ошибке;- Включены жесткие проверки преобразования целых и вещественных чисел на этапе компиляции, т.е. выражение "const b = uint16(-1)" теперь приведёт к выводу ошибки, так как -1 не может быть преобразован в целый беззнаковый тип;
- Обеспечена распаковка кортежей для констант и переменных циклов.
Например, сейчас можно использовать присвоения вида 'const (d, e) = (7, "eight")' и "for (x, y) in f";- Обеспечена инициализация по умолчанию хэшей и таблиц. Например, после объявления "var s: HashSet[int]" можно сразу выполнить "s.incl(5)", что раньше приводило к ошибке;
- Улучшена информативность ошибок для проблем, связанных с оператором "case" и выходом за границы индекса массива;
- Запрещено изменения длины таблицы в процессе итерации.URL: https://nim-lang.org/blog/2019/06/06/version-0200-released.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=50828
Кто-то юзает в продакшне, как оно?
Логическая цепочка: продакшен = энтерпрайз = текучка = новички не знают nim.
Сможете сами сделать выводы?
Пытаюсь сделать выводы:
- В ним - почти все мы - новички, язык не попсовый, и это нормально. Дайте юзкейс, и я его освою. На го у меня ушло пару недель, например.
- энтерпрайз = текучка - прямой зависимости нет, но в большинстве нынешних шараг - таки текучка(когда я арботал в сиске, то даже выполнял роль HR, собеседуя будущих неу-дачников, в том числе и на своё место). Там же, где я арботаю - пока-что нет текучки.
Я использую. Очень пригодились AST макросы.
В Debian, похоже, фанат языка опакечивает, т.к. версия 0.20 уже 3 дня как доступна:> nim (0.20.0-1) unstable; urgency=medium
>
> * New upstream release
>
> -- Federico Ceratto <federico@debian.org> Fri, 07 Jun 2019 10:37:13 +0100
Он один из контр. https://github.com/nim-lang/Nim/graphs/contributors
> "Not" теперь всегда является унарным оператором, т.е. выражения вида "assert(not a)" теперь недопустимы и допускается только указание "assert not a";Как из первого следует второе? Поясните.
Более того, почему в первом варианте not не считается унарным?
В общем, очередной язык, чья главная фича - это пРиКоЛьНыЙ))) синтаксис
Видимо неявный приоритет операторов. Скорее всего имелось ввиду что скобки теперь опциональны.
Согласен с оратором выше, язык довольно безыдейный, лучше брать мейнстримный язык или Rust.
>Скорее всего имелось ввиду что скобки теперь опциональны.и где тут логика? то у них отрицание "не унарное", а теперь скобки не обязательны? так скобки на то и нужны, чтобы задать явно приоритет вычислений при равных приоритетах операторов.
Я не знаю как там было дело, но я возился с парсерами и поэтому предположу. Строчка 'assert not a' по идее, должна парсится в AST вида assert(not(a)). В смысле применение оператора not к a, после чего результат засовывается аргументом к assert. Но у них получалось не assert(not(a)), а not(assert, a), после чего понятно, компилятору становилось плохо.Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже без них строит корректное AST.
> Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже
> без них строит корректное AST.в статье написано, "т.е. теперь допускаются выражения вида "assert not a", которые ранее приводили к ошибке;"
то есть, раньше такое выражение без скобок трактовалось как? вы предположили как not(assert(a)), но вопрос в том, что если даже и так "assert not a", то левосторонний парсер должен был понять как assert(not(a)), не так разве?
""Not" теперь всегда является унарным оператором," - вот это предложение вообще жесть, из той же википедии
"Побитовое отрицание (или побитовое НЕ, или дополнение) — это унарная операция", она что у них была не унарной? где логика?
пс: 1.7, Аноним отметил, что это неточность перевода.
>> Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже
>> без них строит корректное AST.
> в статье написано, "т.е. теперь допускаются выражения вида "assert not a", которые
> ранее приводили к ошибке;"
> то есть, раньше такое выражение без скобок трактовалось как? вы предположили как
> not(assert(a)), но вопрос в том, что если даже и так "assert
> not a", то левосторонний парсер должен был понять как assert(not(a)),
> не так разве?Это смотря как понимать слово "должен" в этом контексте. Он должен был в смысле "ought", и исправление парсера указывает на то, что действительно новое поведение правильно, оно должное поведение (хотя в русском можно было бы сказать "парсеру следовало бы понять", вы сказали не так, то есть наверное не этот смысл имели в виду?). Но вообще парсер никому ничем не обязан, и он может спокойно падать с сегфолтом, забивая на все попытки программиста убедить его продолжать работу стоя.
> Но вообще парсер никому ничем не обязанкак так? хотите сказать, что он до сих пор не знал что такое функция как аргумент функции?
>> Но вообще парсер никому ничем не обязан
> как так?А вот так.
> хотите сказать, что он до сих пор не знал что
> такое функция как аргумент функции?Нет, спасибо, не хочу.
not у них - логическое отрицание, bitnot битовое, суть не меняется - всегда была унарной. А у них только стала судя из статьи :)в документации proc `not`(x: bool): bool {.magic: "Not", noSideEffect.} - один аргумент, - унарная.
Это просто странный перевод. Вот оригинал>let a = false
>
># v0.19:
>assert not a # Error: type mismatch: got <proc (cond: untyped, msg: >string): typed, bool>
>assert(not a) # workaround
># v0.20:
>assert not a
Фанаты nim ещё более больные чем фанаты ruby
И тем, и другим далеко до фанатов Rust.
Фанаты раста даже в туалет ходят идеоматически
Разлечение не более. Без отладчика жизни нет. Проще уже c++ осилить и жить припеваючи.
> Без отладчика жизни нет.А что, gdb не работает? Если nim транслируется в C, для этого транслятору всего-то и надо, что директивы #line расставить.
Привет, писатель helloworldow, тебе может быть нормально писать на одном языке, а отлаживать на другом, но нормальным людям надо работать
> Привет, писатель helloworldow, тебе может быть нормально писать на одном языке, а
> отлаживать на другом, но нормальным людям надо работатьПривет Экспертам Опеннета -- Знатокам обсуждаемой темы (и принципов работы GDB)!
% cat hello.nim
let
x:int = 5
y:string = "hello"
var
z:int = x + 1337z += z;
echo y, "World!", z% nim c --debugger:native hello.nim
% gdb hello
>>> b hello.nim:7Breakpoint 1 at 0x2126b6: file /tmp/nim/hello.nim, line 7.
─── Source ──────────────────────────────────────────────────────────────────────────────
1 let
2 x:int = 5
3 y:string = "hello"
4 var
5 z:int = x + 1337
6
7 z += z;
8 echo y, "World!", z>>> p z_
$1 = 1342
>>> n
>>> p z_$2 = 2684
>>> frame#0 NimMainModule () at /tmp/nim/hello.nim:8
8 echo y, "World!", z
> нормальным людям надо работатьЕсли тебе некогда разбираться, как работает дебаггер, так и скажи, а не пытайся умничать.
Для очень занятых: gdb с nim работает, проверил. Но, что предсказуемо, не умеет показывать значения элементов массивов, последовательностей и т. п.
> gdb с nim работает, проверил. Но, что предсказуемо, не
> умеет показывать значения элементов массивов, последовательностей и т. п.В смысле?
var
5 z = [1,2,3,4,1337]
>>> p z_<tab>[4]$4 = 1337
>>> p z_<tab>$1 = {[0] = 1, [1] = 2, [2] = 3, [3] = 4, [4] = 1337}
Единственно, name mangling немного мешает.
Ну да, понятное дело, что если разобраться в манглинге, можно заставить работать. Я просто поленился препарировать сгенерированный код. Зато переменные не манглятся.
Мне хватило времени изучить C++, а но на извращения времени не хваатет
> Мне хватило времени изучить C++Зачем обманываешь, а? C++ невозможно изучить за конечное время.
> Pascal, C++, Python и LispВсё то, что надо было выкинуть и использовать только как примеры «как не надо делать».
Из питона взяли систему отступов — неудачную фичу, ломающую навигацию по коду, его читаемость и написание.
Из чего вывод один: автор языка не вполне понимает, что и зачем он делает. Ему просто прикольно.
Курсовая работа: "Как сделать ЯП"
Да ладно... Вполне на диплом тянет!
> использует статическую типизациюна динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже
> и создан с оглядкой на Pascal, C++, Python и Lispа что общего у этих четырех (весьма достойных) языков программирования?
хипстер-смузи решил скрестить ужа с ежом?
> код на языке Nim компилируется в представление на C, C++ или JavaScriptчто общего между С и JavaScript? (так и представил веб-макаку, гордо пишущую в резюме: "умею писать hello world на Nim и компилить его в JS, претендую на зарплату на 20% дороже"
> По аналогии с Python в Nim в качестве разделителей блоков применяются отступы\ну почему, почему из Пихтона взяли худшее??
хотите легкости написания - делайте динамическую типизацию, отите качества - делайте С-подобный синтаксис....
> Код проекта поставляется под лицензией MIT.Столлман ворчит неодобрительно и призывает громы небесные на Несвободных
наверно потому что статическая типизация как бы быстрее скомпилиреутся чем динамическая не? правда тогда можно и на си писать.
и чем всем так помешали отступы? тем, что заставляют писать аккуратнее?
Представь, что вместо явных знаков "обгон запрещен"/"конец зоны запрещения обгона" придумали вот какую штуку: "если трасса, идущая с запада на восток, вдруг сместилась на 20 метров к северу, то на смещенном участке трассы обгонять запрещено".
ну да, это видимо у каждого по своему. не испытывал проблем с отступами. единственное, что - обратно возвращаться тяжело, опять же решаемо несколькими днями практики.
> ... статическая типизация как бы быстрее скомпилиреутся чем динамическая ...О, боги!
Запятая лишняя.
> наверно потому что статическая типизация как бы быстрее скомпилиреутся чем динамическая не?Не. Динамическую проще компилировать: не надо высчитывать типы выражений и сверять их с типами переменных куда результаты вычисления выражений складываются. Вот глянь на попытку запилить комбинаторы парсеров в rust[1], если ты пролистаешь вниз ближе к концу, ты найдёшь интересный поворот в сюжете[2], когда время компиляции улетело в бесконечность, и чтобы с этим справится, пришлось переходить к динамической типизации, жонглируя в рантайме ссылками на трейты, вместо ссылок на объекты конкретных типов.
Понятно, что это (то есть описание синтаксиса в системе типов, задавающее любому грамматически правильному выражению соответстующий тип) больше похоже на извращение, и в языках где невозможно создание рекурсивных типов, не будет возможность подобное сотворить и ситуация когда 200 строк кода компилируется десять минут не возникнет, но и тем не менее, суть остаётся той же: типизация -- это дополнительная работа компилятору.
[1] https://bodil.lol/parser-combinators/
[2] https://bodil.lol/parser-combinators/#so-close-now
>Столлман ворчитИ пусть. GPL запрещает некоторые другие свободные лицензии совместно использовать. Из-за этого у ZFS проблемы были.
>> код на языке Nim компилируется в представление на C, C++ или JavaScript
> что общего между С и JavaScript? (так и представил веб-макаку, гордо пишущуюЕсли вы не знаете, что такое бэкнэнд ЯП/компилятора, то возможно, не стоит пока и обзывать кого-то "веб-макакой"?
> ну почему, почему из Пихтона взяли худшее??
> отите качества - делайте С-подобный синтаксис....Ну-ну
volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
к-кааачеееествооо!
> на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно нижеЗато ошибки потом вылавливать дольше на порядки.
+100500
Ну разве что пишутся килобайты кода, а потом сразу отдаются пользователям без каких-либо проверок на работоспобность и правят ошибки уже на основе баг репортов. У вас так работают?Действительно трудноуловимые ошибки возникают в случае слабой типизации, которая вполне может сочетаться со статической.
Питон ведь со строгой типизацией?
Давным давно одну либо пытался заюзать. Видимо, позвал метод, который разрабам давно не был нужен в их ежедневной работе. И в каких-то недрах либо вполне себе TypeError вылетел. Заглянул в сырую: очевидно, что раньше там из внутреннего метода одиночное значение возвращалось, и в месте падения ожидалось. Где разрабам нужно было, они поправили. А нужный мне метод оказался сиротинушкой.
Конечно, если бы у них были тесты на этот метод, они бы заметили. Но если бы была строгая типизация, они тоже бы заметили.
> на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно нижеПроще писать если не нужно руками типы прописывать. Но динамическая типизация не единственный путь к такому счастью. Есть ещё автоматический вывод типов.
Правда, полный автоматический вывод часто приводит к росту времени компиляции. По-этому либо просят программиста хотя бы иногда типы вручную указывать, либо накладывают какие-нибудь ограничения на систему типов.
Но в целом, даже на убогом Go вывод типов экономит много ручной писанины. При этом, Go - это один из самых плохих примеров этой фичи. Есть много языков, где это реализовано элегантнее и приятнее для программиста.
> Есть много языков, где это реализовано элегантнее и приятнее для программиста.Заинтриговал.
>> и создан с оглядкой на Pascal, C++, Python и Lisp
> а что общего у этих четырех (весьма достойных) языков программирования?
> хипстер-смузи решил скрестить ужа с ежом?Взял фичи из разных языков
>> код на языке Nim компилируется в представление на C, C++ или JavaScript
> что общего между С и JavaScript?В оба языка актуально компилироваться (нативная и веб платформы соответственно)
как-то слишком много внимания на опеннете языку с полтора пользователями. не то, чтобы я был против, просто непонятна причина
+100500
> как-то слишком много внимания на опеннете языку с полтора пользователями,Как-то слишком много внимания вашему непонимаию -- аж целый каммент. Не то, чтобы я был против, но тут на опенете каждый первый не понимает каждой второй новости...
>не то,
> чтобы я был против, просто непонятна причина... и ничего-ничего-ничего.