The OpenNET Project / Index page

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

Выпуск языка программирования Nim 2.2.6

03.11.2025 22:19

Представлен релиз языка системного программирования Nim 2.2.6. Обновление вышло спустя шесть месяцев после релиза версии 2.2.4 и включает 141 коммит с исправлениями ошибок и улучшениями производительности. Nim – статически типизированный компилируемый язык программирования с синтаксисом, вдохновлённым Python, и возможностями метапрограммирования на уровне Lisp. Язык компилируется в C, C++ и JavaScript, обеспечивая производительность на уровне C при выразительности высокоуровневых языков. Код проекта поставляется под лицензией MIT.

Ключевые особенности Nim включают мощную систему макросов, работающих на AST во время компиляции, развитую систему обобщённого программирования с концептами, множественную диспетчеризацию (multiple dispatch), детерминированное управление памятью с поддержкой нескольких стратегий (ARC/ORC, refc, маркировка-и-подметание), встроенную поддержку async/await для асинхронного программирования и FFI для простой интеграции с C/C++/JavaScript. Nim позиционируется как системный язык, подходящий для разработки от встраиваемых систем до веб-серверов, с акцентом на эффективность, безопасность памяти и удобство разработки.

Ключевые изменения:

  • Оптимизация move-семантики для полей объектов. Компилятор научился распознавать возможность применения move-операций при возврате полей объектов. Ранее конструкции вида "return obj.field" приводили к копированию данных, теперь компилятор корректно применяет перемещение:
    
       proc getField(obj: MyObject): string =
         return obj.field  # Теперь move вместо copy
    

    Это особенно важно для тяжёлых типов данных (строки, последовательности, объекты с ресурсами), где устранение лишнего копирования даёт заметный прирост производительности без изменения кода.

  • Полная переработка closure-итераторов с обработкой исключений. Механизм трансформации замыканий-итераторов полностью переписан, что кардинально улучшило стабильность async-кода с обработкой исключений. Исправлены критические проблемы, включая SIGSEGV при использовании try/except не на верхнем уровне:
    
       iterator problematicIterator(): int {.closure.} =
         for i in 0..10:
           try:
             if i == 5:
               raise newException(ValueError, "test")
             yield i
           except ValueError:
             discard  # Ранее вызывало SIGSEGV
    

    Также решена проблема с некорректным пробросом исключений в finally-блоках внутри closure-итераторов.

  • Исправления, связанные с управлением памятью
    • Устранена фундаментальная проблема в сборщике мусора при обработке циклических структур данных, которая могла приводить к выводу ошибки "Illegal storage access". Проблема существовала с момента создания языка и проявлялась при сложных графах объектов с взаимными ссылками.
    • Исправлен некорректный порядок уничтожения объектов, который мог приводить к обращению к уже освобождённой памяти:
      
         type
           Resource = object
             data: ptr Data
           Container = object
             resource: Resource
             other: OtherResource
      
         # Теперь деструкторы вызываются в правильном порядке:
         # сначала other, затем resource
      
    • Сборщик ORC ошибочно помечал окружения некоторых замыканий как циклические, что приводило к задержкам освобождения памяти или утечкам. Теперь анализ циклов работает корректно.
    • Исправлена утечка сокетов в asyncnet при ошибках согласования TLS-соединения:
      
         proc handleClient() {.async.} =
           var socket = await server.accept()
           try:
             await socket.setupSSL()  # При ошибке здесь socket теперь корректно закрывается
           except SSLError:
             discard  # Сокет больше не утекает
      
  • Критические исправления в компиляторе.
    • Устранена регрессия, при которой глобальные переменные, объявленные внутри процедур с static-параметрами, переинициализировались при каждом вызове:
      
         proc test[N: static int]() =
           var global {.global.}: array[N, int]
           global[0] += 1
           echo global[0]
      
         test[5]()  # Выводило: 1
         test[5]()  # Должно: 2, но выводило: 1 (было переинициализировано)
      
    • Исправлена генерация кода для глобальных переменных в рекурсивных функциях, которая приводила к неопределённому поведению.
    • Решена древняя проблема генерации некорректного C-кода при использовании конструкторов для глобальных переменных внутри конвертеров:
      
         converter toInt(x: MyType): int =
           let global {.global.} = MyType()  # Генерировал невалидный C-код
           result = global.value
      
    • Устранено падение компилятора при генерации исключений типа Defect и использовании doAssert в определённых контекстах.
  • Улучшения в системе типов
    • Исправлена невозможность возврата lent-значений из case/if выражений:
      
         proc getBest(a, b: string): lent string =
           if a.len > b.len:
             return a  # Ранее: ошибка компиляции
           else:
             return b
      
    • Устранена проблема с некорректным сохранением значений lent-полей в обобщённых типах:
      
         type
           Wrapper[T] = object
             data: lent T
      
         proc process[T](w: Wrapper[T]) =
           echo w.data  # Значение теперь корректно сохраняется
      
    • Восстановлена проверка инициализации переменной result для типов с requiresInit, которая была сломана в версии 2.2: type MustInit {.requiresInit.} = object value: int proc test(): MustInit = discard # Теперь корректно выдаёт ошибку о неинициализированном result
    • Исправлено игнорирование некопируемости (".noCopy") базового типа:
      
         type
           Base {.noCopy.} = object
           Derived = object of Base
      
         var a: Derived
         var b = a  # Теперь корректно запрещено
      
  • Оптимизации производительности
    • Ускорение оператора "@" для тривиальных типов: устранена критическая деградация производительности при создании последовательностей из массивов простых типов:
      
         let arr = [1, 2, 3, 4, 5]
         let s = @arr  # Было крайне медленно, теперь оптимально
      
    • Оптимизация vmgen.sameConstant: значительно ускорена компиляция за счёт оптимизации сравнения констант в виртуальной машине компилятора и сокращения операций выделения памяти.
    • Разыменование результата cast в одиночном выражении больше не вызывает ненужное копирование:
      
         let data = cast[ptr MyType](address)[]  # Теперь без копирования
      
  • Исправления в бэкенде для компиляции в JavaScript:
    • =destroy для не-var типов: исправлена генерация деструкторов, которая ранее приводила к ошибкам компиляции.
    • cast[char] для значений > 255: теперь корректно выполняется усечение, как в C-backend.
    • Концепты в varargs: устранён вывод ошибки "internal error" при передаче концептов в varargs.
  • В бэкенде для компиляции в C++ восстановлена L-valueness для совместимых типов что было сломано в регрессии между версиями 2.2.2 и 2.2.4:
    
       # nim cpp
       var x: CppCompatibleType
       takeRef(x)  # Снова работает как lvalue
    
  • Исправления в бэкенде для компиляции в C (refc):
    • pthread на некоторых платформах: исправлена генерация кода для pthread_mutex_t с использованием .abi;
    • Обобщённые типы с GC-памятью: устранена генерация некорректного C-кода для generic-типов, содержащих управляемую память;
  • Виртуальная машина
    • Глобальные переменные и присваивания: множественные исправления работы с глобальными переменными на этапе компиляции.
    • Case-объекты из compileTime proc: исправлена передача вариантных объектов как static-параметров.
    • repr для длинных строк под refc: устранён RangeDefect при использовании repr.
  • Исправления в стандартной библиотеке
    • В strutils.formatSize исправлена работа с большими значениями, близкими к int64.high:
      
         echo formatSize(9223372036854775807)  # Теперь корректный результат
      
    • В deques восстановлена совместимость поведения итератора items между версиями 2.0.16 и 2.2.0.
    • В lists.SinglyLinkedList.remove устранён AssertionDefect при удалении элементов из односвязного списка.
    • В tables.withValue исправлено условие проверки в макросе withValue для неизменяемых таблиц.
  • Прагмы и области видимости
    • В "{.push raises: [].}" исправлено некорректное игнорирование лексических областей видимости для push-прагм с raises.
    • Устранён эффект «утечки» отключения предупреждений за пределы pragma-блоков:
      
         {.push warning[UnusedImport]: off.}
         import module1
         {.pop.}
         import module2  # Предупреждения теперь корректно включены
      
  • Прочие важные исправления
    • Сравнение cstring: добавлены отсутствовавшие операторы "<" и "cmp" для cstring.
    • Проверка диапазонов float: включена корректная проверка диапазонов для чисел с плавающей точкой
    • filterIt и rvalue: исправлено ошибочное возвращение rvalue вместо lvalue
    • Устранён FieldDefect при сравнении указателей на этапе компиляции.
    • hasCustomPragma после копирования typedesc: восстановлена работоспособность после копирования дескрипторов типов.
    • nim doc и приватные поля: исправлено использование комментариев от приватных полей для публичных.

Дополнение: Опубликован компилятор Nimony 0.2, развиваемый как основа для будущего Nim 3.0. Автор проекта попробовал написать игру крестики-нолики на основе, которая уже есть. Цели Nimony.

  1. Главная ссылка к новости (https://nim-lang.org/blog/2025...)
  2. OpenNews: Представлены принципы дизайна компилятора Nimony для будущего Nim 3.0
  3. OpenNews: Для Nim 3.0 развивается новый компиляторный бэкенд на основе формата NIF
  4. OpenNews: Релиз языка программирования Nim 2.0
  5. OpenNews: Выпуск языка программирования Crystal 1.16
  6. OpenNews: Выпуск языка программирования Julia 1.12
Автор новости: User097
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64173-nim
Ключевые слова: nim
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:51, 03/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > и возможностями метапрограммирования на уровне Lisp
    > Язык компилируется в C, C++ и JavaScript,

    Нужно перестать стесняться и сказать вслух очевидное: нужен Common Lisp, компилируемый в представление на любом мейнстримном языке.

     
     
  • 2.10, ZloySergant (ok), 23:51, 03/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >...Common Lisp, компилируемый в представление на любом мейнстримном языке.

    Был такой. ECL, но после самоотвода jjgarcia скатился в унылое.
    До этого gcl, ccl и др.

     
  • 2.19, Кошкажена (?), 01:14, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > нужен Common Lisp,

    У него заморожен стандарт. Как же без обновлений? На что выделять деньхи?

     
     
  • 3.21, Аноним (21), 01:35, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А что, если создавать новые библиотеки? ... Да ну на! Лучше синтаксис каждые 3 недели ломать!
     
     
  • 4.74, Аноним (74), 22:33, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >А что, если создавать новые библиотеки?

    Не всё можно решить библиотеками, иногда придётся править ядро языка

     
  • 2.29, Аноним (29), 04:09, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Common Lisp слишком переусложнен и переполнен всяческой абракатаброй.

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

     
     
  • 3.30, Аноним (30), 06:06, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Спасибо не надо, ваши не осилившие паскаль первоклашки потом вкатываются в ойти через пейтон и уже вовсю пишут калькуляторы на 30ГБ ОЗУ.
     
     
  • 4.47, Аноним (74), 12:37, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >ваши не осилившие паскаль первоклашки

    Паскаль не надо осиливать, паскаль надо закапывать. Если уж и брать компилируемые языки, то хотя-бы современные SML, Go, Ocaml, другие подставить по вкусу.

     
     
  • 5.62, Аноним (62), 16:20, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    паскаль нужен не для программирования, а для освоения концепций. см. столярова.
    а в одном рядоу go с ocaml, конечно, странно выглядят.
     
     
  • 6.77, Аноним (74), 23:14, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Устаревших ещё в 80-ых Поскольку уже в 80-ых были изобретены языки гораздо лучш... большой текст свёрнут, показать
     
  • 3.36, Аноним (-), 08:18, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Но вот Scheme - это то, что надо.

    Scheme - это стандарт на бумаге, его не заюзаешь. Юзайте реализацию Guile.

     
     
  • 4.67, Аноним (67), 19:10, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Scheme - это стандарт на бумаге, его не заюзаешь. Юзайте реализацию Guile.

    Guile это GUI Light Environment?

     
  • 2.31, morphe (?), 06:07, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > нужен Common Lisp

    Не нужен, большая часть программ в сборщике мусора не нуждается.

     
     
  • 3.68, Аноним (74), 19:48, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вот как раз сборщик мусора большинству программ не помешает, так как реглярно всплывают проблемы, что в очередной программе намудрили с ручным управлением памятью.
     
  • 2.34, Аноним (34), 07:56, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Julia?
     

  • 1.2, Аноним (2), 23:00, 03/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Будучи программистом с опытом более 15 лет и комфортной зарплатой, я ничего не понял из описания. Слишком сложно, а значит, не выстрелит.
     
     
  • 2.3, bdrbt (ok), 23:16, 03/11/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вот если бы ты не программы там всякие 15 лет писал, а каждый раз придумывал почему убогий с/с++/c#/жаба/<ещёчегонибудь> не подходит под высокий полёт твоей мысли, вот тогда бы ты всё понял.
     
     
  • 3.12, Аноним (-), 00:05, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот если бы ты не программы там всякие 15 лет писал, а каждый раз придумывал
    > почему убогий с/с++/c#/жаба/<ещёчегонибудь> не подходит под высокий полёт
    > твоей мысли, вот тогда бы ты всё понял.

    Да еще синтаксис - очень разный может быть. И в этом смысле никогда не знаешь что получишь на вход. Это конечно по своему забавно - но только не в случае если код поддерживать придется.

     
  • 2.5, Аноним (5), 23:38, 03/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это ок.

    Тут люди с опытом по 30 лет на С, не могут понять, зачем нужен раст. Уже их ошибки на уровне ЦПУ хотят решать, а им невдомек.

     
     
  • 3.13, Аноним (-), 00:07, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут люди с опытом по 30 лет на С, не могут понять, зачем нужен раст. Уже их
    > ошибки на уровне ЦПУ хотят решать, а им невдомек.

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

     
  • 3.23, Аноним (23), 02:04, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Выбор корпораций решать си-ошибки на уровне ЦПУ является признанием того, что раст не нужен. Иначе зачем бы им решать си-ошибки на уровне ЦПУ, вместо изучения раста их сотрудниками.
     
     
  • 4.32, Аноним (5), 06:27, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Выбор корпораций решать си-ошибки на уровне ЦПУ является признанием того, что раст не нужен.

    Решать в рантайме то, что должно решаться на этапе компиляции?

    > Иначе зачем бы им решать си-ошибки на уровне ЦПУ, вместо изучения раста их сотрудниками

    Потому, что очень много написано на С, и, в ближайшем будущем, от этого не избавится.

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

     
     
  • 5.78, Аноним (74), 23:19, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Решать в рантайме то, что должно решаться на этапе компиляции?

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

     
  • 3.25, Аноним (-), 02:46, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Тут люди с опытом по 30 лет на С, не могут понять, зачем нужен раст. Уже
    > их ошибки на уровне ЦПУ хотят решать, а им невдомек.

    Не беспокойтесь, мы с удовольствием предложим адептам Rust выбросить их старый хлам, точно так же как это делают сейчас они. Ибо долг платежом красен :)

     
  • 2.7, 12yoexpert (ok), 23:41, 03/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    это новость про патч-релиз. вопросы по изложению к автору новости
     
     
     
    Часть нити удалена модератором

  • 4.33, Аноним (33), 07:42, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А что, разве питон может компилироваться в js или wasm? Или может в Си код, сопоставимый с нативным? Работать на микроконтроллерах без такого сжирания ресурсов, тоже близком к Си?
    Нет.
     
     
  • 5.51, минона (?), 12:56, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, разве питон может компилироваться в js или wasm? Или может
    > в Си код, сопоставимый с нативным? Работать на микроконтроллерах без такого
    > сжирания ресурсов, тоже близком к Си?
    > Нет.

    Ну, есть транспайлер py2many, но заставить его работать на скрипте, большем чем hello_world.py, мне не удалось.

     

  • 1.16, Уникум (?), 00:18, 04/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Язык на пробелах не нужен
     
     
  • 2.24, Кошкажена (?), 02:44, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильно. Нужно писать без пробелов, в одну строку желательно.
     
  • 2.44, Аноним (44), 11:41, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Для человека структурирование через отступы — естественный приём. Так пишут списки, планы, вложенные элементы.

    Конечно, можно так:
    if (x > 0) {
        printf("Positive\n");
    } else {
        printf("Non-positive\n");
    }

    Но я человек, и мне удобнее так:
    if x > 0:
      echo "Positive"
    else:
      echo "Non-positive"

    Языки с отступами формируют повышенную дисциплина кодирования. Программист не может "сломать стиль" случайными пробелами и код различных авторов в проекте выглядит более единообразно. Кроме того, меньше конфликтов при совместной разработке (например, при слиянии веток в Git).

     
     
  • 3.45, Аноним (45), 12:26, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    При вставке кода могут появиться трудно уловимые ошибки, которые будут проходить синтаксическую проверку.
     
     
  • 4.56, Аноним (56), 13:57, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, если вставлять в MS Word, то, пожаоуй, да 🙂‍↕️
     
  • 4.60, Аноним (-), 15:36, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В Nim с его чувствительным компилятором это вряд ли возможно. Для написания программ на языке Nim нужна высокая культура кодинга и чутьё при применении типов.
     
  • 3.49, Аноним (74), 12:54, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не можно, а нужно Вместо скобочек можно end использовать, но это дело вкуса Ес... большой текст свёрнут, показать
     
  • 3.53, anonymous (??), 13:44, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  Конечно, можно так:
    >  if (x > 0) {
    >      printf("Positive\n");
    >  } else {
    >      printf("Non-positive\n");
    >  }

    это для детей, вообще то надо так:

       printf( x>0 ? "Positive\n" : "Non-positive\n");

     
     
  • 4.57, _kp (ok), 14:33, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Более того, вместо x может  быть и "функция" объявленная здесь же, в массив, и мало ли что.
    А выше предлагают ВМЕСТО сокращения портянок исходников, те же портянки разукрасить пробелами, что бы хотя бы издали было красиво. :)

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

     

  • 1.20, cheburnator9000 (ok), 01:29, 04/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > теперь компилятор корректно применяет перемещение

    Там нет компилятора. Там транспайлер. У них была и до сих пор есть возможность перейти на LLVM для полной поддержки сборки и дебага, вместо костылей.

     
     
  • 2.38, Аноним (-), 08:22, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >У них была и до сих пор есть возможность перейти на LLVM для полной поддержки сборки и дебага, вместо костылей.

    Что за бред ты несёшь?

     
  • 2.43, Аноним (44), 11:06, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В профессиональной литературе и документации сам Nim называют именно компилятором, а не транспилятором.

    Причина в том, что конечный результат — исполняемый бинарный код. Наличие промежуточного языка (C) лишь часть внутреннего процесса компиляции и архитектурно Nim ближе к традиционным компиляторам, чем к чистым транспиляторам вроде TypeScript→JS.

     
     
  • 3.46, Аноним (45), 12:28, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    так а в чём разница? Компилятор - из исходного кода в машинный код, транслятор - из исходного на одном языке в исходный на другом. А транспилятор - из исходного кода в?
     
     
  • 4.54, Аноним (56), 13:53, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ...в самодостаточный читабельный текст программы на другом ЯП, очевидно же.

    Цель компилятора Nim таки давать на выходе бинарник.

     
     
  • 5.75, Ан6оним (?), 22:43, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >в самодостаточный читабельный текст программы на другом ЯП

    Это транслятор делает.

     
  • 4.61, АнонимичныйАноним (?), 16:02, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    По вашей логике clang - это компилятор, или же транслятор? Поскольку сборка, изначально, происходит в другой язык - IR LLVM.
     
     
  • 5.76, Ан6оним (?), 22:45, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, уж промежуточные представления в расчёт брать не стоит, а то так каждый компилятор строящий АСТ станет транслятором.
     
  • 4.65, Медведь (ok), 17:54, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > так а в чём разница? Компилятор - из исходного кода в машинный код, транслятор - из исходного на одном языке в исходный на другом. А транспилятор - из исходного кода в?

    И компилятор, и транспилятор -- трансляторы. Компилятор: исходный код -> машкод/байткод; транспилятор: исходный код на языке A -> исходный код на языке B.

    По моему мнению, Nim таки ближе к транспилятору, хотя назовите как хотите, на суть происходящего не влияет. ;)

     
     
  • 5.69, Аноним (69), 19:52, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не. 97% программистов не интересуются, что там посередине. Есть код на Nim - получаем исполняемый файл.

    С такой логикой любой компилятор можно назвать детективным словом «транспилятор», потому что он так или иначе чего-то там получает между исполняемым файлом и исходником.

     
     
  • 6.71, Медведь (ok), 21:34, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть код на Nim - получаем исполняемый файл.

    А в случае трансляции в javascript?

     
  • 2.63, Шизгорин (-), 16:42, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты просто прицепился к словам. Сами они называют это компилятором, а использование промежуточного Си преподносят как фичу.
     
  • 2.66, Аноним (66), 18:43, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    clang, получается, тоже транслятор?
     

  • 1.52, Аноним (74), 13:03, 04/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >детерминированное управление памятью с поддержкой нескольких стратегий (ARC/ORC, refc, маркировка-и-подметание)

    И получение граблей на ровном месте
    >Оптимизация move-семантики для полей объектов

    Но всё же, у них там ещё и сборщик мусора зачем-то нужен
    >Устранена фундаментальная проблема в сборщике мусора при обработке циклических структур данных

    Видимо слишком простым язык получился, перед крестами стыдно.
    >Исправлена утечка сокетов в asyncnet при ошибках согласования TLS-соединения:

    Ошибка в сетевых соединениях исправлена в языке, не в библиотеке, а в языке. Особенно приятно будет во всяких дебианах, ждать ещё года два.
    >Устранён эффект «утечки» отключения предупреждений за пределы pragma-блоков:

    Похоже, они действительно решили догнать кресты по сложности.

     
  • 1.70, Аноним (70), 20:46, 04/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    очень уж много критических ошибок в новости. Значит ещё не готов.
     
  • 1.72, BrainFucker (ok), 21:55, 04/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну идея-то хорошая, только непонятно зачем было изобретать новый язык. Раз всё равно идею отступов без скобок заимствовали из питона, просто использовали бы питонячий синтаксис как есть, добавив какой-то синтаксический сахар по необходимости.
    Но в целом выглядит лучше Rust.
     
     
  • 2.73, 12yoexpert (ok), 22:15, 04/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    чисто технически в nim ты может делать с синтаксисом что угодно, хоть через begin/end всё писать, хоть в плюсы его переделать

    а так - он отличается от питона

    гугли доки про их AST

     

  • 1.79, Vorobej (?), 00:19, 05/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для ЯВУ сложные макросы, язык в языке - это провал
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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