The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Новая версия языка программирования Nim 0.20

10.06.2019 23:41

Состоялся релиз языка системного программирования Nim 0.20.0. Язык использует статическую типизацию и создан с оглядкой на Pascal, C++, Python и Lisp. Исходный код на языке Nim компилируется в представление на C, C++ или JavaScript. В дальнейшем полученный C/C++ код компилируется в исполняемый файл при помощи любого доступного компилятора (clang, gcc, icc, Visual C++), что позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора. По аналогии с Python в Nim в качестве разделителей блоков применяются отступы. Поддерживаются средства метапрограммирования и возможности для создания предметно-ориентированных языков (DSL). Код проекта поставляется под лицензией 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" и выходом за границы индекса массива;
  • Запрещено изменения длины таблицы в процессе итерации.


  1. Главная ссылка к новости (https://nim-lang.org/blog/2019...)
  2. OpenNews: Новая версия языка Nim 0.19.0
  3. OpenNews: Новая версия языка программирования Nim 0.18.0
  4. OpenNews: Новая версия языка программирования Nim 0.17.2
  5. OpenNews: Новая версия языка программирования Nim 0.17.0
Лицензия: CC-BY
Наводку на новость прислал opqx
Тип: Программы
Ключевые слова: nim
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (50) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 00:02, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Кто-то юзает в продакшне, как оно?
     
     
  • 2.3, Зщз (?), 00:21, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Логическая цепочка: продакшен = энтерпрайз = текучка = новички не знают nim.
    Сможете сами сделать выводы?
     
     
  • 3.18, Лапчатый девляпс бубунтёнак (?), 09:47, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Пытаюсь сделать выводы:
    - В ним - почти все мы - новички, язык не попсовый, и это нормально. Дайте юзкейс, и я его освою. На го у меня ушло пару недель, например.
    - энтерпрайз = текучка - прямой зависимости нет, но в большинстве нынешних шараг - таки текучка(когда я арботал в сиске, то даже выполнял роль HR, собеседуя будущих неу-дачников, в том числе и на своё место). Там же, где я арботаю - пока-что нет текучки.
     
  • 2.5, ZXC (?), 00:38, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я использую. Очень пригодились AST макросы.
     

  • 1.2, Андрей (??), 00:07, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    В 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

     
     
  • 2.15, Аноним (-), 09:00, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Он один из контр. https://github.com/nim-lang/Nim/graphs/contributors
     

  • 1.4, Аноним (4), 00:23, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > "Not" теперь всегда является унарным оператором, т.е. выражения вида "assert(not a)" теперь недопустимы и допускается только указание "assert not a";

    Как из первого следует второе? Поясните.

     
     
  • 2.6, Аноним (6), 00:43, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Более того, почему в первом варианте not не считается унарным?
    В общем, очередной язык, чья главная фича - это пРиКоЛьНыЙ))) синтаксис
     
  • 2.8, Junior frontend developer (?), 01:37, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Видимо неявный приоритет операторов. Скорее всего имелось ввиду что скобки теперь опциональны.
    Согласен с оратором выше, язык довольно безыдейный, лучше брать мейнстримный язык или Rust.
     
     
  • 3.9, Sw00p aka Jerom (?), 02:29, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Скорее всего имелось ввиду что скобки теперь опциональны.

    и где тут логика? то у них отрицание "не унарное", а теперь скобки не обязательны? так скобки на то и нужны, чтобы задать явно приоритет вычислений при равных приоритетах операторов.

     
     
  • 4.37, Ordu (ok), 19:01, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я не знаю как там было дело, но я возился с парсерами и поэтому предположу. Строчка 'assert not a' по идее, должна парсится в AST вида assert(not(a)). В смысле применение оператора not к a, после чего результат засовывается аргументом к assert. Но у них получалось не assert(not(a)), а not(assert, a), после чего понятно, компилятору становилось плохо.

    Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже без них строит корректное AST.

     
     
  • 5.42, Sw00p aka Jerom (?), 22:10, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже
    > без них строит корректное AST.

    в статье написано, "т.е. теперь допускаются выражения вида "assert not a", которые ранее приводили к ошибке;"

    то есть, раньше такое выражение без скобок трактовалось как? вы предположили как not(assert(a)), но вопрос в том, что если даже и так "assert not a", то левосторонний парсер должен был понять как  assert(not(a)), не так разве?

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

    "Побитовое отрицание (или побитовое НЕ, или дополнение) — это унарная операция", она что у них была не унарной? где логика?

    пс: 1.7, Аноним отметил, что это неточность перевода.

     
     
  • 6.45, Ordu (ok), 23:12, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже
    >> без них строит корректное AST.
    > в статье написано, "т.е. теперь допускаются выражения вида "assert not a", которые
    > ранее приводили к ошибке;"
    > то есть, раньше такое выражение без скобок трактовалось как? вы предположили как
    > not(assert(a)), но вопрос в том, что если даже и так "assert
    > not a", то левосторонний парсер должен был понять как  assert(not(a)),
    > не так разве?

    Это смотря как понимать слово "должен" в этом контексте. Он должен был в смысле "ought", и исправление парсера указывает на то, что действительно новое поведение правильно, оно должное поведение (хотя в русском можно было бы сказать "парсеру следовало бы понять", вы сказали не так, то есть наверное не этот смысл имели в виду?). Но вообще парсер никому ничем не обязан, и он может спокойно падать с сегфолтом, забивая на все попытки программиста убедить его продолжать работу стоя.

     
     
  • 7.47, Sw00p aka Jerom (?), 01:27, 12/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Но вообще парсер никому ничем не обязан

    как так? хотите сказать, что он до сих пор не знал что такое функция как аргумент функции?


     
     
  • 8.49, Ordu (ok), 02:01, 12/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А вот так Нет, спасибо, не хочу ... текст свёрнут, показать
     
  • 5.43, Sw00p aka Jerom (?), 22:36, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    not у них - логическое отрицание, bitnot битовое, суть не меняется - всегда была унарной. А у них только стала судя из статьи :)

    в документации proc 'not'(x: bool): bool {.magic: "Not", noSideEffect.} - один аргумент, - унарная.

     

  • 1.7, Аноним (7), 00:51, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это просто странный перевод. Вот оригинал

    >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

     
  • 1.10, Аноним (10), 03:51, 11/06/2019 Скрыто [﹢﹢﹢] [ · · · ]
  • –2 +/
     
     
  • 2.11, Аноним (11), 06:24, 11/06/2019 Скрыто
  • +/
     
     
  • 3.12, Аноним (12), 06:30, 11/06/2019 Скрыто
  • –1 +/
     

     ....нить свёрнута, показать (2)

  • 1.13, Аноним (13), 07:48, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Разлечение не более. Без отладчика жизни нет. Проще уже c++ осилить и жить припеваючи.
     
     
  • 2.14, Аноним (14), 08:52, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Без отладчика жизни нет.

    А что, gdb не работает? Если nim транслируется в C, для этого транслятору всего-то и надо, что директивы #line расставить.

     
     
  • 3.22, Аноним (13), 10:34, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Привет, писатель helloworldow, тебе может быть нормально писать на одном языке, а отлаживать на другом, но нормальным людям надо работать
     
     
  • 4.28, Аноним84701 (ok), 13:15, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Привет, писатель helloworldow, тебе может быть нормально писать на одном языке, а
    > отлаживать на другом, но нормальным людям надо работать

    Привет Экспертам Опеннета -- Знатокам обсуждаемой темы (и принципов работы GDB)!

    [code]
    % cat hello.nim
    let
        x:int = 5
        y:string = "hello"
    var
        z:int = x + 1337

    z += z;
    echo y, "World!", z

    %  nim c --debugger:native  hello.nim
    % gdb hello
    >>> b hello.nim:7

    Breakpoint 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
    [/code]

     
  • 4.30, Аноним (30), 13:37, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > нормальным людям надо работать

    Если тебе некогда разбираться, как работает дебаггер, так и скажи, а не пытайся умничать.
    Для очень занятых: gdb с nim работает, проверил. Но, что предсказуемо, не умеет показывать значения элементов массивов, последовательностей и т. п.

     
     
  • 5.31, Аноним84701 (ok), 13:52, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > gdb с nim работает, проверил. Но, что предсказуемо, не
    > умеет показывать значения элементов массивов, последовательностей и т. п.

    В смысле?
    [code]
    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}
    [/code]
    Единственно, name mangling немного мешает.

     
     
  • 6.32, Аноним (30), 15:00, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, понятное дело, что если разобраться в манглинге, можно заставить работать. Я просто поленился препарировать сгенерированный код. Зато переменные не манглятся.
     
  • 5.35, Аноним (13), 15:58, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне хватило времени изучить C++, а но на извращения времени не хваатет
     
     
  • 6.44, Аноним (14), 23:11, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Мне хватило времени изучить C++

    Зачем обманываешь, а? C++ невозможно изучить за конечное время.

     

  • 1.16, Wilem (?), 09:03, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    > Pascal, C++, Python и Lisp

    Всё то, что надо было выкинуть и использовать только как примеры «как не надо делать».

    Из питона взяли систему отступов — неудачную фичу, ломающую навигацию по коду, его читаемость и написание.

    Из чего вывод один: автор языка не вполне понимает, что и зачем он делает. Ему просто прикольно.

     
  • 1.17, Попугай Кеша (?), 09:38, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Курсовая работа: "Как сделать ЯП"
     
     
  • 2.39, Anonim (??), 19:49, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ладно... Вполне на диплом тянет!
     

  • 1.19, Аноняшка (?), 10:19, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > использует статическую типизацию

    на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже
    > и создан с оглядкой на Pascal, C++, Python и Lisp

    а что общего у этих четырех (весьма достойных) языков программирования?
    хипстер-смузи решил скрестить ужа с ежом?
    > код на языке Nim компилируется в представление на C, C++ или JavaScript

    что общего между С и JavaScript? (так и представил веб-макаку, гордо пишущую в резюме: "умею писать hello world на Nim и компилить его в JS, претендую на зарплату на 20% дороже"
    > По аналогии с Python в Nim в качестве разделителей блоков применяются отступы\

    ну почему, почему из Пихтона взяли худшее??
    хотите легкости написания - делайте динамическую типизацию, отите качества - делайте С-подобный синтаксис....
    > Код проекта поставляется под лицензией MIT.

    Столлман ворчит неодобрительно и призывает громы небесные на Несвободных

     
     
  • 2.20, Аноним (20), 10:26, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    наверно потому что статическая типизация как бы быстрее скомпилиреутся чем динамическая не? правда тогда можно и на си писать.
    и чем всем так помешали отступы? тем, что заставляют писать аккуратнее?
     
     
  • 3.23, Аноним (6), 10:51, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Представь, что вместо явных знаков "обгон запрещен"/"конец зоны запрещения обгона" придумали вот какую штуку: "если трасса, идущая с запада на восток, вдруг сместилась на 20 метров к северу, то на смещенном участке трассы обгонять запрещено".
     
     
  • 4.27, Аноним (20), 11:57, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну да, это видимо у каждого по своему. не испытывал проблем с отступами. единственное, что - обратно возвращаться тяжело, опять же решаемо несколькими днями практики.
     
  • 3.24, yet another anonymous (?), 11:07, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ... статическая типизация как бы быстрее скомпилиреутся чем динамическая ...

    О, боги!

     
     
  • 4.26, grsec (ok), 11:17, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Запятая лишняя.
     
  • 3.38, Ordu (ok), 19:20, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > наверно потому что статическая типизация как бы быстрее скомпилиреутся чем динамическая не?

    Не. Динамическую проще компилировать: не надо высчитывать типы выражений и сверять их с типами переменных куда результаты вычисления выражений складываются. Вот глянь на попытку запилить комбинаторы парсеров в rust[1], если ты пролистаешь вниз ближе к концу, ты найдёшь интересный поворот в сюжете[2], когда время компиляции улетело в бесконечность, и чтобы с этим справится, пришлось переходить к динамической типизации, жонглируя в рантайме ссылками на трейты, вместо ссылок на объекты конкретных типов.

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

    [1] https://bodil.lol/parser-combinators/
    [2] https://bodil.lol/parser-combinators/#so-close-now

     
  • 2.21, frthrjt (?), 10:29, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Столлман ворчит

    И пусть. GPL запрещает некоторые другие свободные лицензии совместно использовать. Из-за этого у ZFS проблемы были.

     
  • 2.29, Аноним84701 (ok), 13:25, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> код на языке Nim компилируется в представление на C, C++ или JavaScript
    > что общего между С и JavaScript? (так и представил веб-макаку, гордо пишущую

    Если вы не знаете, что такое бэкнэнд ЯП/компилятора, то возможно, не стоит пока и обзывать кого-то "веб-макакой"?

    > ну почему, почему из Пихтона взяли худшее??
    >  отите качества - делайте С-подобный  синтаксис....

    Ну-ну
    [code]
    volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
    [/code]
    к-кааачеееествооо!

     
  • 2.33, Аноним (30), 15:02, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже

    Зато ошибки потом вылавливать дольше на порядки.

     
     
  • 3.34, Аноним (34), 15:18, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    +100500
     
  • 3.41, angra (ok), 21:58, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну разве что пишутся килобайты кода, а потом сразу отдаются пользователям без каких-либо проверок на работоспобность и правят ошибки уже на основе баг репортов. У вас так работают?

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

     
     
  • 4.46, funny.falcon (?), 01:25, 12/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Питон ведь со строгой типизацией?
    Давным давно одну либо пытался заюзать. Видимо, позвал метод, который разрабам давно не был нужен в их ежедневной работе. И в каких-то недрах либо вполне себе TypeError вылетел. Заглянул в сырую: очевидно, что раньше там из внутреннего метода одиночное значение возвращалось, и в месте падения ожидалось. Где разрабам нужно было, они поправили. А нужный мне метод оказался сиротинушкой.
    Конечно, если бы у них были тесты на этот метод, они бы заметили. Но если бы была строгая типизация, они тоже бы заметили.
     
  • 2.48, funny.falcon (?), 01:31, 12/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже

    Проще писать если не нужно руками типы прописывать. Но динамическая типизация не единственный путь к такому счастью. Есть ещё автоматический вывод типов.

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

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

     
     
  • 3.50, Аноним (14), 21:15, 12/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть много языков, где это реализовано элегантнее и приятнее для программиста.

    Заинтриговал.

     
  • 2.51, Junior frontend developer (?), 21:16, 12/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> и создан с оглядкой на Pascal, C++, Python и Lisp
    > а что общего у этих четырех (весьма достойных) языков программирования?
    > хипстер-смузи решил скрестить ужа с ежом?

    Взял фичи из разных языков

    >> код на языке Nim компилируется в представление на C, C++ или JavaScript
    > что общего между С и JavaScript?

    В оба языка актуально компилироваться (нативная и веб платформы соответственно)

     

  • 1.36, Нанобот (ok), 17:49, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    как-то слишком много внимания на опеннете языку с полтора пользователями. не то, чтобы я был против, просто непонятна причина
     
     
  • 2.40, Anonim (??), 20:02, 11/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    +100500
     
  • 2.52, Andrey Mitrofanov_N0 (?), 13:42, 13/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > как-то слишком много внимания на опеннете языку с полтора пользователями,

    Как-то слишком много внимания вашему непонимаию -- аж целый каммент.  Не то, чтобы я был против, но тут на опенете каждый первый не понимает каждой второй новости...

    >не то,
    > чтобы я был против, просто непонятна причина

    ... и ничего-ничего-ничего.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру