Представлен релиз языка системного программирования Nim 1.

0. Версия 1.0 преподносится как стабильный выпуск с длительным сроком поддержки для которого будет гарантировано сохранение обратной совместимости в стабилизированной части языка. Отдельно в компиляторе доступен экспериментальный режим, в котором будут развиваться новые возможности, которые могут нарушать обратную совместимость. Некоторые API в стандартной библиотеке также пока помечены как нестабильные и будут переводиться в разряд стабильных по мере готовности. Код проекта поставляется под лицензией MIT. Язык Nim использует статическую типизацию и создан с оглядкой на Pascal, C++, Python и Lisp. Исходный код на языке Nim компилируется в представление на C, C++ или JavaScript. В дальнейшем полученный C/C++ код компилируется в исполняемый файл при помощи любого доступного компилятора (clang, gcc, icc, Visual C++), что позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора. По аналогии с Python в Nim в качестве разделителей блоков применяются отступы. Поддерживаются средства метапрограммирования и возможности для создания предметно-ориентированных языков (DSL). https://nim-lang.org/ #codding

Комментарии

  • 24 сен 2019 19:46
    Нет языка который был бы не интересен. Но я для себя выбрала цепочку которой интересуюсь, это - ассемблер gas x86-64, C, go, haskell ну и кончно же сценарии в оболчке bash со всевозможными встроенными в утилиты языками в vim, bc, sed, awk. Большее мой мозг думаю не вывезет принимая во внимание что сейчас усиленно подтягиваю английский и все мануалы, книги или статьи стараюсь читать на бусурманском.
  • 24 сен 2019 19:50
    я думаю одной сишки и сишки с плюсами достаточно, от неё пока не отказываются ещё, более современный вариант rust и go
  • 25 сен 2019 00:18
    Если говорить о профессионализме то любого одного языка будет достаточно, но так как мои интересы чисто любительские и не подчинены эффективности заработка то выбранных мною инструментов хватит воплотить в жизнь любую программную идею. Все мои языки кроме Хаскеля очень компактные и уместятся все наверное в одной четвертой С++. Кстати к джава, питону, расту и плюсам имею предвзято негативное отношение. Любителю это позволено ))). Пыталась как то в период исканий познакомится с nim, не затянуло, а вот Хаскель если честно, то уже лишний в моем инструментарии, но он так сказать для души. Хаскель можно просто учить и получать удовольствие от этого. У меня даже есть поговорка - "Дома хорошо, дома кот и Хаскель". Всмысле уютно...
  • 28 сен 2019 12:50
    Согласен, С и С++ -- наше "всё" . Я начинал на Algol, Pascal, dBase и проч. Потом С и С++ , для программера "из окопов" тогда ничего больше и не требовалось. И вообще, в моё время все молились на объектно-ориентированное программирование, книгу Страуструпа распечатывали на больших похожих на танк принтерах. А сейчас об ООП все ноги вытирают, говорят оно неэффективно. И аббревиатуры MFC и ATL уже ничего никому не говорят.
    А по-моему большие проекты на Питоне -- намного больший кошмар, чем на С++  .
  • 28 сен 2019 16:46
    Я думаю все дело в том что не были продуманы ограничения в С++. В место того где можно обойтись чисто структурами стали плодить классы, то есть повысили абстракцию сразу через ступеньку и там где классы действительно необходимы там получилась обычная помойка. Если в С++ пользоваться только тем что необходимо и осмотрительно планировать проект то ему равных нет, но сама спецификация ни как не мотивирует программиста не бежать сломя голову и не усложнять проект преждевременно. А это в связи с совместимостью превратилось в западню. Обратно уже спецификацию не отматаешь, да и механизмы ограничивающие сложность на начальном этапе вообще не понятны. Ну и если вдруг будут разработаны рекомендации то нет ни какой гарантии что в одночасье все станут их придерживаться.
  • 28 сен 2019 16:53
    Даже для чисто функционального программирования я предпочитаю С++ вместо С -- из-за параметров по умолчанию для функций и библиотек классов (если сильно нужны) .
    А на ООП сейчас взъелись как на парадигму в целом. По принципу "посчитали на бумаге, да забыли про овраги" . Теперь стало модным считать, что внесение серьёзных изменений в структуру классов в больших проектах невозможно без жёсткого рубилова всех связей. Не знаю, по мне так питоновские функции, в которые лезут все параметры подряд -- намного больший источник головной боли, особенно если ищещь баги в чьём-то чужом "творчестве" .