URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 136544
[ Назад ]

Исходное сообщение
"Для Nim 3.0 развивается новый компиляторный бэкенд на основе формата NIF"

Отправлено opennews , 06-Апр-25 18:41 
В процессе разработки версии 3.0 языка программирования Nim ведётся работа над обновлённым компилятором, использующим промежуточный формат NIF (Nim Intermediate Format). В новом компиляторе будет решено несколько технических задач, среди которых улучшение инкрементальной компиляции и упрощение управления зависимостями между модулями. Дата релиза Nim 3.0 пока не определена...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63031


Содержание

Сообщения в этом обсуждении
"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 18:42 
> позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора

В nim к слову их несколько. Включая arc/orc счётчики ссылок, которые работают даже на обычных микроконтроллерах без rtos.
Если gc не нужен, его можно и вовсе отключить. Стандартная библиотека от него не зависит.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Карлос Сношайтилис , 06-Апр-25 19:16 
К сборщикам мусора принято относить компоненты языка, что делают stop the world. Иначе С, С++ и Rust тоже языки с GC, т.к. имеют (или могут иметь) счётчики ссылок.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 19:42 
> компоненты языка

Может быть всё таки компоненты рантайма?

> К сборщикам мусора принято относить stop the world

Это где так принято?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 20:31 
>> К сборщикам мусора принято относить stop the world
> Это где так принято?

В ябловском свифте, то ли ушлыми маркетолухами, то ли самими фанатами ябла.
Рассказы и заверения о том, что сборка мусора по счетчику - совсем не сборка мусора
> Swift does not use garbage collection. It uses automatic reference counting (ARC)

пошли (хоть это и чисто субъективное имхо) именно оттуда. До этого, почему-то считалось:
https://homes.cs.washington.edu/~bodik/ucb/cs164/sp12/lectur...
https://www.researchgate.net/publication/2534368_A_Pure_Refe...

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 11:43 
> До этого, почему-то считалось:
> https://homes.cs.washington.edu/~bodik/ucb/cs164/sp12/lectur...
> https://www.researchgate.net/publication/2534368_A_Pure_Refe...

Первая ссылка - 2012-й год. Задолго до этого подсчёт ссылок считался "управлением жизни объекта" https://learn.microsoft.com/en-us/windows/win32/com/rules-fo... (смотреть следует дату не публикации, а реализации COM - это прошлый век). Плюс, это учебный курс, где сравнение различных подходов полезно (и при подсчёте ссылок остаётся в прямом смысле мусор, если ссылки циклические, и не предпринимать мер).

По второй ссылке что, если в двух словах? Впрочем, оно опять не "до", а "после".


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Страдивариус , 07-Апр-25 21:05 
Не ссорьтесь, горячие финские парни.

Счетчик ссылок может разрулить циклические ссылки. А garbage collector может. Ну нормальный во всяком случае.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 11:12 
>Счетчик ссылок может разрулить циклические ссылки

У вас "не" потерялось


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Добрый самаритянин , 08-Апр-25 13:46 
GC почистил ;)

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Страдивариус , 10-Апр-25 17:45 
Да, спасибо

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 20:22 
счетчик ссылок и есть алгоритм сбора мусора..

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 11:30 
Это алгоритм автоматического управления памятью, как и сборка мусора.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 20:39 
> К сборщикам мусора принято относить компоненты языка, что делают stop the world.

В (C)Python, перле, луа тоже нет "stop the world". Внезапно, да?

> Иначе С, С++ и Rust тоже языки с GC, т.к. имеют (или могут иметь) счётчики ссылок.

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 23:05 
В Питоне есть GC и stop the world тоже

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 23:35 
> В Питоне есть GC и stop the world тоже

В питоне - основным идет "счетчик ссылок".
Плюс опциональный (отключаемый) GC для сборки циклических зависимостей - без него никаких "stop the world" (ну, типа - потому что на самом деле затык будет еще и в стандартной библиотеке аллокатора, т.е. тут даже с ручным malloc-free можно вполне "нарваться").
Прям как в сабже (ARC и ORC).


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 06-Апр-25 21:09 
> Иначе С, С++ и Rust тоже языки с GC, т.к. имеют (или могут иметь) счётчики ссылок.

Там счетчики ссылок работают детерминирванно: четко сказано когда будет вызван "деструктор", если счетчик ссылок станет 0. В питоне, например, он вообще может быть не вызван.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 07:05 
Ты не можешь знать, что вот именно в этом месте счетчик станет нулевым

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 08:30 
> Ты не можешь знать, что вот именно в этом месте счетчик станет нулевым

Тем не менее, неотключаемый GC - это очень четкая граница водораздела, отделяющая НеСистемных от системных. Контроль над происходящим В ДЕТАЛЯХ - это и есть системное программирование. А если вы все это не хотите - апликухи пишите, используя прослойки "от богов" которые за вас и разберутся как вон то внутрях работало.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 11:56 
Как можно проконтролировать отсутствие фрагментации кучи при вызовах malloc() и free()?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 14:20 
https://habr.com/ru/companies/otus/articles/889020/

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 16:16 
Надо взять за правило: не ходить по ссылкам без пояснений. Сорцы glibc и без них открыты.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 17:19 
там какой-то чел на зарплате гундосит про работу malloc и free, в т.ч. про фрагментацию

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 17:20 
странно, что ты сам не сходил и не почитал те сорцы, а побежал на опеннете вопросы задавать

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 08-Апр-25 09:17 
Естественно, я сначала изучил glibc, и даже немножечко реализацию mremap(), а потом задал вопрос.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 08-Апр-25 22:52 
блин, это же было очевидно. прости

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 09-Апр-25 10:04 
Ну да, можно было сравнить моё описание флага с man mmap

/**
* Если разрешен overcommit, не резервируется место в подкачке для
* отображений с обычным размером страниц памяти.
* Для файловых отображений с большими страницами не резервируется всегда.
* Для анонимных отображений с большими страницами игнорируется.
* Наличие резерва гарантирует отсутствие #SIGSEGV при попытке записи,
* иначе может не найтись свободной физической страницы.
* см\. \c do_mmap() в \c linux/mm/mman.c.
*/
#define MAP_NORESERVE   0x4000

https://github.com/STrusov/Ussury/blob/a6a5c54c2640a365e8ef2...


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 10:59 
Это совершенно никак не отвечает на вопрос, как бороться с состоянием, когда последовательно чередуются небольшие места с свободной и занятой памятью

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 08-Апр-25 22:52 
я и не пытался. скинул рандомную статью, вдруг поможет

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 15:26 
> Как можно проконтролировать отсутствие фрагментации кучи при вызовах malloc() и free()?

Не делая эти вызовы, например! В си как системном ЯП так можно. То-есть я сам решаю какая аллокация памяти будет в моей программе. Для фирмвар вполне нормально "static memory allocation" практиковать. Когда все заранее раздали статичкски - и тогда не только нет непредсказуемых лагов, да и закончиться память - не может. Такого понятия просто нет.

Остаются конечно еще рекурсии и VLA всякие, но сие при нужде опять же обязательно не делается. И при нужде гасится на уровне анализатора или ключей компилера вообще.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 16:09 
> Ты не можешь знать, что вот именно в этом месте счетчик станет
> нулевым

Это не важно. Важно, что будет когда счетчик станет нулем. В языках с gc момент сборки мусора недетерминирован (если только руками не звать gc).


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 19:15 
Зачем нужны языки высокого уровня, компилирующиеся в другие языки высокого уровня?
Разрабам этой штуки не даётся компиляция в IR llvm/gcc?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 06-Апр-25 19:39 
1) попиши на нём и узнаешь, зачем
2) автор языка так не хочет. у него есть какие-то аргументы, но всем на них закономерно пофиг

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 15:09 
"Попишите чтобы понять нафиг поделка вообще нужна" и "какие-то аргументы" - такой себе маркетинг.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 17:18 
а это не раст, чтобы тебе что-то продавать

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Андрей , 07-Апр-25 08:11 
Дешевле получить более высокоуровневые фишки с интеграцией широко распространённых и кроссплатформенных языков/инструментов. Фактически, если это всё ручками писать/переписывать(алгоритмы преобразования кода, оптимизации), то автоматически закладываешь 10+ лет отставания, всё это время отставая одновременно и по скорости внедрения новых возможностей, так и по скорости работы кода. Плюс бонусом транспилируя в Си/плюсы можно сверхлегко получить интероперабельность с ними, вместе со всеми библиотеками на нём.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 11:00 
llvm уже изобретён

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 10:17 
У llvm есть фатальные недостатки, тут обсуждали https://www.linux.org.ru/forum/development/17699718

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 13:24 
Читал тот тред.
Аргументов "чем плох llvm" так и не увидел.
Куча безосновательных "а давайте все транслировать в сишку, а потом компилять".

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 12:01 
Потому что Си и создавался, что бы в него "компилировали" другой язык высокого уровня - "препроцессор языка Си". Следующим широкоизвестным ЯВУ, "компилирующимся" в Си был Cfront Страуструпа.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:19 
>Потому что Си и создавался, что бы в него "компилировали" другой язык высокого уровня

Не перевирай.

>Следующим широкоизвестным ЯВУ, "компилирующимся" в Си был Cfront Страуструпа.

Самый первый "компилятор языка C++" был ООП надстройкой над компилятором Си. Причина банальная, Страуструп не умел писать компиляторы. Чтобы писать компилятор надо знать архитектуру компьютера, машинные коды, ассемблер. А Страуструп знал только высокоуровневые языки.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 16:34 
>>Потому что Си и создавался, что бы в него "компилировали" другой язык высокого уровня
> Не перевирай.

5.1.1.1 Program structure

1 ... After preprocessing, a preprocessing translation unit is called a translation unit.

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

>>Следующим широкоизвестным ЯВУ, "компилирующимся" в Си был Cfront Страуструпа.
> Самый первый "компилятор языка C++" был ООП надстройкой над компилятором Си.

Он был "препроцессором", как и обсуждаемый транслятор из новости.

> Причина
> банальная, Страуструп не умел писать компиляторы. Чтобы писать компилятор надо знать
> архитектуру компьютера, машинные коды, ассемблер. А Страуструп знал только высокоуровневые
> языки.

Какая чушь.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:47 
>> Причина банальная, Страуструп не умел писать компиляторы.
> Какая чушь.

Интересно, а что бы на это сказал сам Страуструп?
Вдруг что-то вроде
"C plus plus has been evolving from day one because it's design Choice back in about
1979
because I realized that there was no way I could build a perfect language from scratch
I didn't have the resources I didn't have the knowledge and the world changes all along"
?

Из недавнего интервью
youtu.be/eLLi0nWMUMs?t=208


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 08-Апр-25 09:25 
Страуструп _написал_ транслятор. Что по этому поводу сказали Даннинг и Крюгер?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 15:55 
Когда К. Топсон созлавл язык Би, он знал машинный язык и ассемблер. Когда Д. Ритчи создавал Си, он знал машинный язык и ассемблер. Когда Б. Страуструп _написал_ транслятор С++, он знал только высокоуровневые языки.

Когда растаманы создавали Rust, они не знали архитектуру компьютера, не знали машинный язык, не знали ассемблер. Они просто взяли готовый компилятор LLVM.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 15:57 
Любой компилятор первым делом делает лексический парсинг в AST. Они просто стандартизировали этот этап, чтобы можно было обработать AST любыми внешними инструментами. До IR тут еще даже не подошли.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 06-Апр-25 19:38 
не решает главную проблему языка: отсутствие отладчика. автору предлагали реализовать клиент к gcc, безуспешно

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 19:50 
Забей на отладчик, выводи всё в консоль.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 20:21 
640 KB и printf хватит всем.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 21:04 
В Боинге тоже так думали. Пока не перестали так думать.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 08:32 
> В Боинге тоже так думали. Пока не перестали так думать.

Так и представляю себе - прогер прицепил дебагер, степает программу... боинг застывает в воздухе, ждет пока программер отстепает код бортового компьютера :). Вот была бы красота, если б это еще и катило. Жаль что законы физики хрен убедишь...

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 13:32 
Боинг большой)
Там есть много систем и далеко не все должны фурычить в риалтайме.
Например сортир или мультемедийная система.

И их можно дебажить сколько угодно. Даже ассертов понапихать, если лениво разбираться где все-таки оно ломается
Возможно тогда нам не приходилось бы читать новости "хакер взлома самолет через вайфай телевизора в сиденье"


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:33 
> Боинг большой)
> Там есть много систем и далеко не все должны фурычить в риалтайме.

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

> Например сортир или мультемедийная система.

Этих вообще можно и не отлаживать по сути. Даже если что и факапнется - not a big deal.

> И их можно дебажить сколько угодно. Даже ассертов понапихать, если лениво разбираться
> где все-таки оно ломается
> Возможно тогда нам не приходилось бы читать новости "хакер взлома самолет через
> вайфай телевизора в сиденье"

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

Т.е. вы и этот топик тоже - не понимаете.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 21:09 
К GDB может?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 06-Апр-25 22:46 
нет, ему предлагали реализовать компиляцию через уже существующие компиляторы, например, gcc (хотя автор работает в амазон, так что, думаю, если и будет делать, то через llvm, чисто всем назло. так же, как он свои книги продаёт)

автор настаивал на какой-то нелепой фигне, уже не помню. типа, мол, зачем, если можно выплюнуть C/C++, obj-c или java и компилять или запускать чем хочешь. а то, что в gdb при отладке помойка, - это почему-то его не волнует


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:02 
> а то, что в gdb при отладке помойка, - это почему-то его не волнует

Абсолютная неправда. Зачем печатать ложь? Прекрасно дебажится как в гдб, lldb, так и с помощью санитайзеров. И на номера строк указывает, и имена типов Nim сохраняет в читабельном виде. В мануале компилятора описаны все необходимые ключи для этого


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 22:00 
Этот шаг, в первую очередь, направлен на улучшение инструментария языка программирования (на что неоднократно ныли неосиляторы без плагина под их любимую IDE). Каким местом вы читали новость?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 06-Апр-25 22:44 
при чём тут направление шага и чтение новости, если описанное не решает главную задачу - отсутствие отладчика?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 07:08 
При том, что для нового бэкенда можно будет улучшить состояние отладчика, как и lsp и т.д.

Можете почитать ветку форума: https://forum.nim-lang.org/t/12693


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 09:44 
> However, I expect in practice we'll just use NIFC-to-LLVM instead of NIFC-to-C and get the typical debugging experience of all the other compiled languages.

таки я был прав, чел завендорлочит всё на llvm


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 15:11 
> отсутствие отладчика. автору предлагали реализовать клиент к gcc, безуспешно

Понятно, очередной мистер "путь самурая". На язык я хотел посмотреть, но с таким автором вижу что пустая трата времени.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:03 
Все отладчики работают, не надо печатать бред

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 20:21 
> если не учитывать затраты на выполнение сборщика мусора

А если учитывать?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 07:06 
Нет, давай лучше не учитывать. Выгодно сравнивать скорость, когда память не особождается

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 06-Апр-25 21:19 
Они что собираются программировать на этом языке одну систему на все платформы?
Или "фактический код мы запишем за Вас"

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 06-Апр-25 21:34 
Насколько хорошо подходит промежуточное представление, чтобы генерировать из него высокоуровневый Си код? Он же высокоуровневый в итоге?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 06-Апр-25 22:51 
интересно, насколько описанное в mastering nim после этого превратится в тыкву, там немаленькая часть книги касается именно пайплайна компиляции. язык и так страдает от полного отсутствия высокоуровневой документации, по сути есть только форум и дока на api

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Vorobej , 06-Апр-25 23:29 
Язык системного программирования, компилирующий в язык системного программирования... а JavaScript и без того высокоуровневый. Да еще макросы, всё усложняющие. И графики своей нет, как есть у Питона. Печально, но это провал (

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 06-Апр-25 23:48 
> а JavaScript и без того высокоуровневый

Возможность сложить строки с числами и оператор тройного равенства - это сколько по шкале высокоуровневости?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 02:36 
по сравнению с perl 6 это практически asm

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:36 
>> а JavaScript и без того высокоуровневый
> Возможность сложить строки с числами и оператор тройного равенства - это сколько
> по шкале высокоуровневости?

Да не сильно много. Склыдывать строки вообще что попало умеет по сути.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:52 
>> Возможность сложить строки с числами и оператор тройного равенства - это сколько  по шкале высокоуровневости?
> Да не сильно много. Склыдывать строки вообще что попало умеет по сути.

Это до момента
console.log(NaN === NaN); // Output: false
console.log(+0 === -0); // Output: true

или (!+[]+[]+![]).length === 9

Вообще там куча приколов, чего только banana стоит.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 17:16 
> console.log(NaN === NaN); // Output: false
> console.log(+0 === -0); // Output: true

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:05 
>> Да не сильно много. Склыдывать строки вообще что попало умеет по сути.
> Это до момента
> console.log(NaN === NaN); // Output: false
> console.log(+0 === -0); // Output: true
> или (!+[]+[]+![]).length === 9
> Вообще там куча приколов, чего только banana стоит.

Это вы про JS чтоли? Тут кто-то постил список приколов, значительно колоритнее.

Но вот например строки складывать умеют даже совсем педальные вещицы.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 01:27 
Это какая графика есть у питона? Биндинги к С/С++?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 04:49 
Во во, тоже удивляюсь. Иногда хочется гуй на питоне сделать, думаю, мож появилось чего, иду гуглить, а там все тот же список биндингов к кутям и прочий пайгейм с тсл/тк. Грустно, вот как раз на питоне самое то графику делать, а всякое высокопроизводительное уже в нативе.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 08:27 
> Во во, тоже удивляюсь. Иногда хочется гуй на питоне сделать, думаю, мож появилось
> чего, иду гуглить, а там все тот же список биндингов к кутям и прочий пайгейм с тсл/тк.

Вон там RenPy есть. Но лучше б он биндингами к годоту был, и то менее позорно было бы... :)


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:08 
> RenPy

Там под капотом тот же PyGame.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:07 
Гражданин вероятно имеет в виду питонобиндинги к Tcl/Tk.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 15:12 
Это какая такая своя графика у питона? Только не говори что tkinter, который, во-первых, не своя, во-вторых графикой-то не назовёшь.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 04:00 
Пытался писать что-то на нём. А так как я начинающий программист, то использую много копипаста из своего кода(и не только своего). Но из-за использования отступов для разделения блоков очень затрудняется весь процесс. В то время когда я на нём что-то пробовал не было автоформатирования. Надо было постоянно суетиться с этим форматированием. Я же новичок. Не пишу программу сразу целиком, что-то надо добавить что-то перенести из одной функции/процедуры в другую и если у них отступ на разном уровне, то опять сидишь выравниваешь это все пробелами вручную.
Даже в то время имея в пример ещё один язык с такими отступами(питон) я понимал, что люди как-то решают или обходят эту проблему, а в nim это есть?
А примеры gui кода видели? Вложенные отступы за пределами экрана, если что-то сложное хочешь. То есть нужно мотать ещё и горизонтальную прокрутку.
Вот это все и оттолкнуло меня.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 12:18 
Очень ценный опыт. Насколько понимаю, такой синтаксис сделали намеренно, что бы "научить начинающих хорошему". В итоге люди уходят из-за траты времени на выравнивание. Оно, конечно, важно, но ещё важнее, что бы программа работала, так? Остаются "эстеты".

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 11:06 
>Насколько понимаю, такой синтаксис сделали намеренно, что бы "научить начинающих хорошему"

Дрессировать программистов?
>В итоге люди уходят из-за траты времени на выравнивание

Правильно делали. В нормальных языках форматировать вручную не нужно, всё форматирование делается автоматом. Попробовать можно на https://try.ocamlpro.com/


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 08-Апр-25 11:23 
Так в OCaml отступы не влияют на смысл программы. Хотя и внешне чем-то похоже на Python. Наверное, поскольку имеется научная база, а не одно лишь желание повторить успех бейсика.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 12:23 
>В нормальных языках форматировать вручную не нужно

Может, это всё же зависит не от языка, а от утилиты структурной распечатки? (Pretty printer, code formatter, называйте как хотите)


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 12:43 
От языка. Если пробелы играют управляющую роль, то поставить их может только программист, и только вручную. Возьмём пример, который человек скопирует с форума, который удаляет лишние пробелы

let () = if true then
print_endline "1";
print_endline "2"

Утилита форматирования понимает, что хотел сказать пользователь, и форматирует текст

let () = if true then
    print_endline "1";
  print_endline "2"

Далее, пользователь решает дописать два символа в первой строке

let () = if true then (
    print_endline "1";
  print_endline "2"

утилита форматирования меняет исходник

let () = if true then (
    print_endline "1";
    print_endline "2"

Далее, пользователь дописывает конец условия

let () = if true then (
    print_endline "1";
    print_endline "2"
)

Опять же, срабатывает автоформатирование

let () = if true then (
    print_endline "1";
    print_endline "2"
  )

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

let () = if true then (
    print_endline "1";
  print_endline "2";
  print_endline "3"

Какую тут строку нужно двигать только "2"; "2", "3"; или никакую? В Ocaml можно без проблем передвинуть все строки, поскольку как только будет набран закрыващий символ, то исходник будет снова правильно отформатирован.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 09-Апр-25 16:04 
>всё форматирование делается автоматом

Получается, не автоматом


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 09-Апр-25 16:28 
> Если пробелы играют управляющую роль, то поставить их может только программист, и только вручную.

Я могу согласиться с исключительно ролью программиста, но насчёт "только вручную" тут ты загнул. Текстовый редактор запросто может поддерживать изменение идентации для выделенных строк, автоматизируя таким образом ручную работу. Да и с текущей строкой, компилятор может сделать всё проще, позволив для этой строки менять идентацию, добавляя/удаляя сразу столько пробелов, сколько надо чтобы засунуть её в if, или вынести оттуда.

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 04:51 
Только честно, есть крутые проекты, использующие этот ним(как и какой нибудь д)?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 07:37 
https://github.com/search?q=language%3ANim&type=reposit...

Не всё крутое, но посмотреть есть что.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 07:45 
https://github.com/niv/neverwinter.nim

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 07-Апр-25 23:57 
> Только честно, есть крутые проекты, использующие этот ним(как и какой нибудь д)?

Не то, чтобы крутой, но когда-то я им пользовался https://github.com/zedeus/nitter


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 08:26 
> Язык Nim ориентирован на решение задач системного программирования,
> использует статическую типизацию и создан с оглядкой на такие языки, как Python, Ada и Modula

Ориентирован на задачи системного программирования - поэтому ориентировался на то что для системнщины меньше всего подходит и используется. Оок!


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 08:36 
> Согласно спецификации NIF, опубликованной в репозитории проекта, новый формат позволяет хранить код
> в виде абстрактного синтаксического дерева (AST)

И все это - вообще зачем? Слава объектников не давала покоя, но поскольку это транспилер то объектные файлы не вырисовывались?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено cheburnator9000 , 07-Апр-25 09:32 
Там у разработчиков языка и основных авторов популярных библиотек страстная любовь поанонировать на кодогенерацию. Вот пример https://github.com/ba0f3/telebot.nim/tree/master полностью обмазанная возможностями AST. Пока программисты на других ЯП что-то там вручную собирают библиотеку для телеги для json для network и т.д, эти просто описали все API. Такое дебажить очень сложно, да собственно толкового дебага в Nim никогда не было.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 12:39 
Но почему оно требует отладки? Сама идея "генерировать код по описанию" возникла, что бы избежать ошибок при кодировании. То есть при этом либо как-то доказывается корректность, либо генерируются тесты.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено cheburnator9000 , 07-Апр-25 13:51 
> Но почему оно требует отладки? Сама идея "генерировать код по описанию" возникла,
> что бы избежать ошибок при кодировании. То есть при этом либо
> как-то доказывается корректность, либо генерируются тесты.

Оно не требует. Моя программа бота для телеги когда я пробовал пару лет назад написать - требовала. И вместо отладки там когоденерированная лапша, которая накладывается поверх транспилированной лапши самого ЯП Nim. Ровно такой же проблемой страдает Vala один в один.

Я лично жду Carbon, но там в разработчиках сплошное LGBT (запрещенная в россии организация (лол)). Ждать еще будем минимум лет 10 если оно не рипнится быстрее.

Лучше всего дебаг реализован здесь https://plugins.jetbrains.com/plugin/15128-nim но судя по всему разработчик там один да и плагин забросили печально.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 14:37 
> Я лично жду Carbon,

Я бы не сильно ждал)

Во-первых это замена для плюсов.
"Carbon is fundamentally a successor language approach, rather than an attempt to incrementally evolve C++. It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers."

Во-вторых он пилится и пилится, но разрабы советуют ипользовать другие ЯП при возможности
Смотрим их README.md на github com/carbon-language/carbon-lang
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.
Т.е создатели карбона сами советуют использовать другие языки где можно, а вот где совсем "не можна" - то там использовать его.
Думаю у них экспертизы больше и их словам я поверю)

Ну и еще один аргумент против - carbon-lang#project-status
Carbon Language is currently an experimental project. We are hard at work on a toolchain implementation with compiler and linker.
Это конечно исправимо (время + деньги), но в данный момент ситуация такова.

> но там в разработчиках сплошное LGBT (запрещенная в россии организация (лол)).

Иногда лучше работать с открытыми gay'ми чем с крысами-321ми
Ты же с ними будешь код писать, а не спать)

> Ждать еще будем минимум лет 10 если оно не рипнится быстрее.

Скорее всего рипнется))


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 01:12 
Не жди - неактулен. Всё нужное завезли в сишку. А в плюсах - уже давно.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:08 
> Не жди - неактулен. Всё нужное завезли в сишку. А в плюсах
> - уже давно.

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

Да, и с веб серверами тоже так можно прикалываться. Прям на сишке. Тоже в полстранички умещается.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 17:11 
> На сишке минимальный бот p2p чата токс - полстраницы текста.

Лол, что ты говоришь. На сишке 2 строки сконкатенировать - полстраницы текста. strlen, strlen, malloc, strncpy, strncpy/strncat, не забудь коды возврата проверить, а при ошибке всё что нааллоцировал освободить, для этого ещё кучу goto напиши, и не дай бог тебе перепутать где длины строк или под \0 место не учесть :))


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:06 
>толкового дебага в Nim никогда не было.

Мануалы читать надо, и станет понятно что все дебагеры работают с кодом Nim


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено cheburnator9000 , 07-Апр-25 09:25 
Блд. А для Дебага хоть что-то было сделать? Ну хоть что-то?? Там ведь реально дебажить нельзя толком проект. Все через дикие позорные костыли.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 21:46 
Зачем тебе дебаг у шняги, которую ты никогда не будешь использовать.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 11:09 
>Там ведь реально дебажить нельзя толком проект

Так это ж хорошо. Язык надёжно защищён от реального применения, возьмите любой нормальный


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 09:25 
Реалии таковы, что без реальной поддержки со стороны IT гигантов, всё это нафиг никому не нужно! И да, это означает что Rust уже победил все эти zig, vlang и т.д.

ПС: хотя, тут выше кто-то писал, что автор работает в Амазоне, так что посмотрим, может со временем будут его использовать как Гугл использует Go для решения своих бизнес задач. Хотя опять же, зачем если уже есть Rust!?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 09:33 
> Rust уже победил

Огласите все критерии победы, пожалуйста, я записываю.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено kravich , 07-Апр-25 09:54 
Критерии победы Rust заключаются в том, что ты приготовился записывать критерии победы Rust, а не критерии победы Nim или Zig

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 09:55 
Я уже огласил самый важный критерий для современного IT (всё остальное вторично!):
>>> реальной поддержки со стороны IT гигантов <<<

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 10:47 
Критерий не засчитан. Непонятно самое главное - над кем/чем объявлена воображаемая "победа". Гиганты тоже могут ошибаться (особенно учитывая кто ими сейчас управляет). Несколько смущает и культура "современной" разработки.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 11:06 
Можно ли считать, что активная фаза военных действий уже пройдена? Или планируются дополнительные наступательные операции для объявления окончательной победы?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 13:37 
> Можно ли считать, что активная фаза военных действий уже пройдена?

Нет конечно! Все только начинается.
Пока намечен плацдарм в ядре, планируется высадка и захват территории.
Сопротивление подавили, хоть и не без потерь.

> Или планируются дополнительные наступательные операции для объявления окончательной победы?

Естественно.
В этом может помочь правительство, недовольное бекдорами от ЖинТиянов.
Т.е бекдоры должны быть только от родимых Джонов и Смиттов.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 14:58 
>> Можно ли считать, что активная фаза военных действий уже пройдена?
> Нет конечно! Все только начинается.
> Пока намечен плацдарм в ядре, планируется высадка и захват территории.
> Сопротивление подавили, хоть и не без потерь.

Ваша организованная диверсионно-подрывная деятельность рассчитана на отсутствие у врага средств для борьбы со ржавчиной, которая со временем проникнет глубже и разрушит структуру ядра?

>> Или планируются дополнительные наступательные операции для объявления окончательной победы?
> Естественно.
> В этом может помочь правительство, недовольное бекдорами от ЖинТиянов.
> Т.е бекдоры должны быть только от родимых Джонов и Смиттов.

Джоны и Смитты - надеюсь, современные вайб-кодеры, модной ориентации?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:34 
> Ваша организованная диверсионно-подрывная деятельность

Не слишком она уж организована. Да и диверсий мы не делаем.
Так иногда пуканчики подрываем, тут согласен.

> рассчитана на отсутствие у врага средств для борьбы со ржавчиной,

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

> которая со временем проникнет глубже и разрушит структуру ядра?

Ядро и так в, мягко говоря, в не самом лучшем состоянии.
Если получится растом залеплять самые плохие мест, то это покажет разработчикам (и главное их спонсорам) "а что так можно было?!".
Ну типа жить без постоянных RCE и прочей радости.

> Джоны и Смитты - надеюсь, современные вайб-кодеры, модной ориентации?

Вот чесно, мне абсолютно плевать с кем спит разработчик.
И веган ли он, мне тоже пофиг. И есть ли у него дети, бьет ли он свою жену, шутит про тещу.
Я использую его код, он может быть хорошим, может плохим.
Этого достаточно.

Не знаю откуда на этом форуме взялась такая мания заглядывать разработчикам в штаны, то ли АУЕшные фильны повлияли, то ли какие-то неудовлетворенные фетиши.
Ты же не паришься какой слесарь будет ремонтировать твое авто (ну кроме БМВ), змаужняя или нет пекарь что печет хлеб или какого цвета волосы у кассира в пятерочке?



"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 05:26 
>[оверквотинг удален]
> Вот чесно, мне абсолютно плевать с кем спит разработчик.
> И веган ли он, мне тоже пофиг. И есть ли у него
> дети, бьет ли он свою жену, шутит про тещу.
> Я использую его код, он может быть хорошим, может плохим.
> Этого достаточно.
> Не знаю откуда на этом форуме взялась такая мания заглядывать разработчикам в
> штаны, то ли АУЕшные фильны повлияли, то ли какие-то неудовлетворенные фетиши.
> Ты же не паришься какой слесарь будет ремонтировать твое авто (ну кроме
> БМВ), змаужняя или нет пекарь что печет хлеб или какого цвета
> волосы у кассира в пятерочке?

Модной ПРОФЕССИОНАЛЬНОЙ ориентации. А ты что подумал?

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

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

Негативные аспекты вайб-кодинга (использования ИИ для написания кода) связаны с техническими, профессиональными и социальными рисками.

Ухудшение фундаментальных навыков программирования. Деградация понимания кода. Разработчики, полагаясь на ИИ, могут перестать глубоко разбираться в алгоритмах, оптимизации и архитектуре.

Потеря способности отлаживать код. Если ИИ генерирует большую часть кода, программисты хуже учатся находить и исправлять логические ошибки вручную.

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

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

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

Проблемы с поддержкой. Генерация "одноразового" кода усложняет его долгосрочное сопровождение.

Юридические риски. Нарушение лицензий. ИИ-модели иногда воспроизводят фрагменты чужого кода без соблюдения лицензий (например, GPL).

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 10:53 
Критерии победы, он один: язык и компилятор должен быть rust.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 11:01 
Если выпустили кукую нибудь программу на rust, то обязательно в самом заголовке будет упоминание Rust в отличие от других языков.
Более того правительство США призывает отказаться от небезопасных языков.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 11:16 
Правильно ли я понимаю, что правительство США выразит глубокую озабоченность, если кто-то осмелится использовать "небезопасный" язык?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 07-Апр-25 12:41 
Не выразит - оно сменилось.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 00:46 
> Огласите все критерии победы, пожалуйста, я записываю.

https://растпобеда.рф/


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 12:53 
Для более полной и надёжной победы заменить тянок на тянокунов.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 16:13 
> Для более полной и надёжной победы заменить тянок на тянокунов.

Может уже, нельзя знать наверняка пока не проверишь.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 16:36 
> Для более полной и надёжной победы заменить тянок на тянокунов.

С другой стороны самый мужиковатый мужыг может вдруг оказаться 321ом.
Я таких регулярно наблюдаю на одном из перекрестков моего города.

Так что (ИМХО) в программировании главное только качество кода.
А кто его писал - это пусть философы и прочие болтуны философствуют.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 14:28 
>> Огласите все критерии победы, пожалуйста, я записываю.
> https://растпобеда.рф/

Хм..
А какое отношение какой-то помойный сайт из .рф относится к rust'у, который придумали на западе, пишут на западе и актично используют на западе.
С тем же успехом могли бы примазаться к посадке на луну или марсоходам))

ps а вообще на этих деятелей надо написать тов. майору - вдруг это засланцы и шпионы.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 16:06 
>>> Огласите все критерии победы, пожалуйста, я записываю.
>> https://растпобеда.рф/
> Хм..
> А какое отношение какой-то помойный сайт из .рф относится к rust'у, который
> придумали на западе, пишут на западе и актично используют на западе.
> С тем же успехом могли бы примазаться к посадке на луну или
> марсоходам))
> ps а вообще на этих деятелей надо написать тов. майору - вдруг
> это засланцы и шпионы.

Да это шутка была :))


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 15:20 
> Реалии таковы, что без реальной поддержки со стороны IT гигантов

Поддержка IT гигантов нахрен никому не сдалась, тем более что поддерживают они только сами себя. Нужна поддержка сообщества, а сообщество мусор всякий подбирать не будет. Поэтому, например, взлетает rust и даже zig, за которым гигантов нет (нет, мозилла даже близко не гигант) но которые хорошо решает свои задачи. И не взлетает swift, за которым стоит аппле, но который нахрен никому не сдался. А nim так вообще никаких задач не решает и является игрушкой автора.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:58 
>>> Нужна поддержка сообщества <<<

Корпорациям пофиг на какое-то соообщество фриканов; они бабки пилят с обычных пользователей!

>>> Поэтому, например, взлетает rust ... за которым гигантов нет.<<<

Ага, Майкрософт и Гугл и вообще правительство США смотрят на вас c явным недоумением!

>>> swift, который нахрен никому не сдался <<<

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

>>> А nim так вообще никаких задач не решает и является игрушкой автора. <<<

Ну хоть в чём то мы с вами сошлись:) а весь весь мой посыл был именно об этом!)


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 18:53 
> Ага, Майкрософт и Гугл и вообще правительство США смотрят на вас c явным недоумением!

Так это не поддержка, это просто использование. Язык взлетел без ms и гугла, и когда он взлетел его стали использовать.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 19:01 
>>> взлетел без ms и гугла <<<

да неважно как он взлетел!!! руби вон тоже взлетел в своё время, но это ему как-то не сильно помогло! важна именно поддержка корпарасов и точка!


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 18:22 
> Поддержка IT гигантов нахрен никому не сдалась, тем более что поддерживают они только сами себя.

И что ты сделаешь без поддержки ядра дровами от IT гигантов?
Достанешь 8800 GT из кладовки)?

> Нужна поддержка сообщества, а сообщество мусор всякий подбирать не будет.

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

> Поэтому, например, взлетает rust и даже zig, за которым гигантов нет (нет, мозилла даже близко не гигант) но которые хорошо решает свои задачи.

Гиганты уже рассмотрели преимущества того что работает и собрались в раст фоундейшн.
Гугл так вообще пару миллионов строк кода написал в андроид.

> И не взлетает swift, за которым стоит аппле, но который нахрен никому не сдался.

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

> А nim так вообще никаких задач не решает и является игрушкой автора.

Зато удостоился новости))



"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 18:58 
> И что ты сделаешь без поддержки ядра дровами от IT гигантов?
> Достанешь 8800 GT из кладовки)?

Так мы не про дрова, а про языки.

> Гиганты уже рассмотрели преимущества того что работает и собрались в раст фоундейшн.

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

> Гугл так вообще пару миллионов строк кода написал в андроид.

Да хоть миллиардов - это код под его личные нужды который нигде более не переиспользуется, считай что его и нету. Код - это crates.io. Сходи и посмотри сколько там кода корпорашек.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 19:11 
>>>  код пишет сообщество <<<

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


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 17:04 
> да проснитесь вы уже! что-то реально полезное пишет не сообщество, а сотрудники компаний которые юзают опенсоурс для решения своих бизнес задач; посмотрите кто является спонсорами этого вашего опенсоура и прекратите себя обманывать.

Слушай, мы в этот опенсорс контрибутим и им пользуемся, мы постоянно видим коммит логи, и не видим там никаких корпораций. А вот ты кто такой и зачем этот FUD распространяешь?


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 17:28 
> Слушай, мы в этот опенсорс контрибутим и им пользуемся,

А эти "мы" сейчас с тобой в одной комнате?

> мы постоянно видим коммит логи, и не видим там никаких корпораций.

Удивительно!
А вот тут написано lwn.net/Articles/1004998/
что только 12.0% By lines changed написано не корпами.
Надеюсь твой манямирок не сильно пострадал.

> А вот ты кто такой и зачем этот FUD распространяешь?

Я? Почти такой же аноним как и ты)
Но у меня есть пруфы, а у тебя только пустобрехи.



"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 20:31 
> Удивительно!
> А вот тут написано lwn.net/Articles/1004998/
> что только 12.0% By lines changed написано не корпами.
> Надеюсь твой манямирок не сильно пострадал.

Я тебя (и его заодно) расстрою - 12% это "неизвестно, какой именно корп".

Не-корпов (None) там аж 3.2%


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 09-Апр-25 10:48 
> Я тебя (и его заодно) расстрою - 12% это "неизвестно, какой именно корп".
> Не-корпов (None) там аж 3.2%

Я просто взял по максимуму)
В прошлый раз анон мне начал втирать "да это люди может в корпе работают, но пишут в свободное время от имени сообщества, так что нищитово!!11".

Хотя цифра в 3% выглядит совсем уныло


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено n00by , 09-Апр-25 10:13 
>> да проснитесь вы уже! что-то реально полезное пишет не сообщество, а сотрудники компаний которые юзают опенсоурс для решения своих бизнес задач; посмотрите кто является спонсорами этого вашего опенсоура и прекратите себя обманывать.
> Слушай, мы в этот опенсорс контрибутим и им пользуемся, мы постоянно видим
> коммит логи, и не видим там никаких корпораций.

Линус Торвальдс не принимает коммиты от анонимов, зато анонимы любят писать "мы" вместо "я", для придания веса пустому месту.



"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:09 
> А nim так вообще никаких задач не решает и является игрушкой автора.

За всех говорить только не надо. Ваших задач не решает, потому что вы его не осилили и не оценили.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 22:03 
> nim так вообще никаких задач не решает и является игрушкой автора.

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

Nim в части науки не даёт шансов ни одному ЯП.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 09:52 
Они уже и на ELF покушаются?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 09:55 
> формат NIF (Nim Intermediate Format)

Где-то повернулась на другой бок Беседка с её .nif (NetImmerse File Format) и продолжила спать)


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 11:35 
Щас бы ещё на миллионы трёхбуквенных расширений оглядываться.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 10:45 
То есть он умеет JavaScript в исполняемый файл переводить?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 12:41 
ЯП, энфорсящий пробелы, идёт сразу ффтопку.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 14:15 
язык позволяет писать со скобочками. он позволяет делать с синтаксисом практически что угодно

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:13 
> позволяет писать со скобочками

Но наличие табов в исходнике — это сразу ошибка этапа компиляции.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 17:10 
я к тому, что ты можешь поменять синтаксис как хочешь, хоть на расте пиши. язык не форсит ни пробелы, ни табы

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 08:12 
> я к тому, что ты можешь поменять синтаксис как хочешь, хоть на
> расте пиши. язык не форсит ни пробелы, ни табы

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

Тот неловкий момент когда код на хрусте - читаемее чем ЭТО :)


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 11:25 
>язык не форсит ни пробелы, ни табы

Следовательно при чтении чтении чужих исходников будет жуткая мешанина


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 14:16 
ЛПП

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 00:07 
Свидетель секты писателей в одну строку и неиспользующих автоформатирование?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 01:08 
Свидетель       Секты   .editorconfig   Использующий    Только  Табы.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 11:15 
В нормальных языках, для форматирования достаточно нажимать только Enter, пробелы поставятся сами. Пример можно посмотреть https://try.ocamlpro.com/

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 12:19 
Открыл блокнот, начал писать на Ocaml, при переносе строк пробелы автоматом не ставятся. ЧЯДНТ?

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 12:25 
Не поставил плагин для автоформатирования, очевидно же

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 08-Апр-25 14:15 
В нормальных языках ломанное говно, которое элементарно превратить в 3, и при этом жрущее 4 байта, просто по желанию левой пятки BDFLа-вахтёра, не навязывают. Уже этого достаточно чтобы Nim всячески прикапывать. Потому что если он перестанет быть маргинальщиной, то нам придётся зависеть от хотелок мудаков.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:28 
Забавно, что столько реплик уже настрочено, но по ссылке в новости никто из комментаторов, судя по всему, не ходил.

Не поленился, и докладываю: раньше nim компилировался в сишечку, теперь же он будет компилироваться в лишп (а точнее кастомный диалект оного).

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

Занавес.


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 07-Апр-25 16:41 
Современный SICP использует JavaScript.

"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 00:00 
> Современный SICP использует JavaScript.

Нет никакого соврменного SICP как и курса вообще. Для js и python просто были адаптации. Да и вообще SICP не про язык, а про программирование в целом. Можно хоть SICP для С++ сделать: лямбы же там есть :))


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено 12yoexpert , 07-Апр-25 17:10 
> Не поленился, и докладываю: раньше nim компилировался в сишечку, теперь же он будет компилироваться в лишп (а точнее кастомный диалект оного).

похоже, ты понятия не имеешь, как там устроен процесс сборки


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Нуину , 08-Апр-25 00:06 
> он будет компилироваться в лишп

Как бы sexpr отлично подходят для (де)сериализации любой древовидной структуры, поэтому широко применяется в компиляторах (напрмер, Wasm, OCaml (https://dev.realworldocaml.org/data-serialization.html)).


"Для Nim 3.0 развивается новый компиляторный бэкенд на основе..."
Отправлено Аноним , 10-Апр-25 08:56 
> раньше nim компилировался в сишечку

И по прежнему будет компилироваться в Си. Никто это не отменяет