The V Programming Language Simple, fast, safe, compiled language for developing maintainable software
Язык программирования V — самый молодой среди успешных и самый успешный среди молодых, начало разработки где-то в феврале 2018, initial release на гитхабе 2019-06-22 и уже 15k звёзд в январе 2020.
Сейчас на нём уже написаны компилятор V, текстовый редактор vid, пакетные менеджеры vpm и vpkg, мессенжер volt (пока только mac os), движок форума vorum и множество других вещей.
Чего вообще полезного/интересного из либ можно запилить для языка? Полистал гитхаб и сайт проекта, помощи (кроме как материальной) вроде не требуют, хотя в истории коммитов ники кроме двух авторов иногда проскакивают. Полторы забавных софтин (Vid) на нем написали, но если и дальше будет так уныло, то без нескучных обоев проектов он не взлетит (т.к. фичи языка "компенсируются" его недоделаностью).
>>1578241 Что угодно можно. Возьми любой допиленный язык, тот же Ruby, сравни что есть и чего нету. Сейчас, например, в стандартной либе V дат нету, только time.
>>1578242 Охуеть там срач развели на 10 страниц, и даже без Малахова. В гите ещё к тому же автор альтернативного говна (Zig) ещё летом высказал свое охуенно важное мнение в виде простыни, обличающем пиздежь автора V (впрочем, по делу, т.к. свои говноидеи высирать нужно в блокнотик, а не на всеобщее обозрение, да ещё и в такой манере, будто это всё уже реализовано).
ОПу: Нужно было таки один тред для нескольких подобных языков пилить, тогда можно было бы тут специальные олимпиады устраивать, чье говно лучше байтики сгенерирует.
>>1578252 Замечание с потолка. V не имеет отношения к Go кроме похожего синтаксиса, он транспилится в Си. С версии 1.0 будет транспилиться сразу в байткод.
>>1578253 Ладно, вечером уже буду думать, чего хорошего запилить, в слон клонит уже. Сейчас может чутка поковыряюсь ещё, хочу глянуть, насколько хуевый там interop. Но в стандартную либу я вряд ли что-то пилить буду, т.к. не хочу потом лицезреть, как мой код поганят хипстеры-аутисты с их понятиями читабельности кода и его обязательной идиоматичности. А вообще можно всем тредом высрать им чего-то в библиотеку, с каждого по сниппету, а потомки уже потом перепишут идиоматичненько, когда эту идиоматику, собственно, сформируют.
>>1578256 >Уже взлетает Уже взлетел, тащемта. Почти в 2 раза обогнал по звездам Nim, который гораздо более зрелый, и в 3 с чем-то раз Zig, чем и вызвал бугурт его автора.
>>1578266 Кстати, от переписывания из-за отступов есть встроенная защита:
You don't need to worry about formatting your code or style guidelines. vfmt takes care of that: v fmt file.v It's recommended to set up your editor, so that vfmt runs on every save.
>>1578266 Тащи лучше реальное что-то Nim, D, Cristal, Concurnas, Zig (хз что это, проверь) Похер без шапки, потом лучше пастой о языках побампаешь тред.
>>1578266 >Уже взлетел, тащемта. Почти в 2 раза обогнал по звездам Nim, который гораздо более зрелый, и в 3 с чем-то раз Zig, чем и вызвал бугурт его автора. У меня даже есть теория почему. Гоферы свои проекты активно лабызают звездами, тут увидели что похож на го, но даже получше и зазвездили его (а парень сливки с донатов снимает)
>>1578270 Тащемта донатов не так много как звезд. Язык действительно приятен, если разовьется до уровня "можно использовать в реальных проектах", то убьет и го, и раст, и крестам достанется.
>>1578269 Вечером притащу. Я не ОП треда, если что. Там вчера анон на утро вроде нормальную шапку для пачки C-подобных языков готовил, но может это он и есть, решил только по одному языку запилить. Сейчас на ночь тогда займусь исследованием, хочу специальную олимпиаду таки устроить, т.к. хоть V и самый хайповый, но в текущем виде едва ли самый интересный.
>>1578270 >а парень сливки с донатов снимает Автор Zig летом в 2 раза больше с хомячков на патреоне снимал. Но вот только создатель V - наш соотечественник (вроде как), а автор Zig - американин из NY, так что кто на деньги с донатов живет, а кому только на бургеры с колой - понятно сразу.
>>1578272 Ничего там никуда не разовьется. Парень прочел книгу по интерпретатору на сях и нафантазировал синтаксис (мы тут все можем любимые конструкции собрать).
Очередной язык уровня Дениса Попова. Имело бы смысл если язых хотя бы транслировался в го, а так даже базиса нет.
>>1578285 Побугуртить и с хэллоуворлдов можно. Там у половины языков онлайн-playground'ы есть, но оценить выхлоп таким образом не представляется возможным. Ладно, сейчас для сравнения напишу рекурсивную функцию для подсчета факториала числа (без проверок на ошибки), а вечером уже буду компиляторы колупать и разбиратся с передачей аргументов. Вот базовый пример такой функции в чистом C (согласно стандарту, указание типа данных int в некоторых местах можно опускать):
>>1578278 Вообще, как-то с коллегами думали запилить голосовалку по разным конструкциям синтаксиса и потом собрать типа такой идеальный язык.
Но мы все макаки, нам мозгов не хватит запилить язык, но на рабочем месте собрали такого прикольного уродца, на базе синтаксиса си, получился какой-то груви (сейчас больше котлин напомнит) c помесью питона.
>>1578288 Там проверок на ошибки дофига, для сравнения слабо подойдет. Я максимально топорный алгоритм использую для удобства его сравнения в разных языках.
>>1578304 Да нахер эти факториалы, есть же стандартная хрень, построчное чтение из файлов, работа с датой (хотя бы форматирование), лямбды, короткие записи листов, мап. Это можно сравнить визуально и насколько вообще парились разработчики
>>1578314 Вообще странно, что ты для факториал в int вычисляешь. В V есть u64, с ним уже до fac(65) без переполнения, хотя на 64 значения тоже рациональнее массив готовых ответов сделать, а не разогревать проц.
>>1578318 Код в моем примере нужен скорее для сравнения языковых конструкций и количества бойлерплейта, а не для реальных вычислений. Само собой, в продакшене я бы высчитал массив из нужного количества значений в Nim или D (или других языках, которые поддерживают компайл-тайм рассчеты) итеративным методом, а не стал баловатся рекурсией.
>>1578313 Вечером накачаю компиляторов, мануалов и попробую сотворить что-то поинтереснее. Вообще, реализовывать в соло сразу в 6-7 языков немного неудобно, учитывая что на половине из них ничего сложнее helloworld я не писал (а вот на Сишечке понаписывал будь здоров сколько, можно её будет использовать в качестве эталона - мерила для сравнения, т.к. они все от неё наследуются; Nim тоже пописал немного, а вот по D хотя бы доку успел изучить).
В любом случае, до вечера, т.к. после более чем суток без сна моя сообразительность опустилась до весьма низкого уровня.
>>1578359 Кого дробить? Никакие нимы с зигами не вытянут конкуренции с V. Этот тред — задел на будущее. Уже через полгода он утопит говнарей с педерастами.
Более абстрактной фразы найти не могли? Можно более нормальное описание нахуй он нужен. Для "developing maintainable software" эффективней было написать спек и линтеров на существующий язык.
>>1578369 Одна из особенностей V - if/else даже с одиночным предложением требует фигурных скобок {}. По мнению автора языка, это увеличивает читабельность и уменьшает вероятность ошибок. Однако там есть присвоением через if (а-ля тернарочка ?: в других языках), хоть в доках этого и не указано нигде, так что можно записать ещё вот так:
fn fac(n int) int { return if n < 2 { 1 } else { n ∗ fac(n-1) } }
Если сократить, то можно и так записать, но из-за скобок всё равно не слишком живо смотрится:
fn fac(n int) int { return if n < 2 { 1 } else { n * fac(n-1) } }
>>1578592 Ещё раз, язык с болезненным делением на expressions и statements не нужен в принципе. Зачем нужен ещё один язык программирования, если это - не лисп?
Краткое сравнение компиляторов и размера бинарников helloworld (Windows, 64-bit):
V: Вместе со стандартной библиотекой и докой занимает <5 МБ в несжатом виде, заработал без проблем. Бинарник HW занимает 123 KB, с флагами -g -prod 87 KB (без -g не компилируется с -prod), -compress декоративный. Сырой пиздец, на чем-то сложнее простой компиляции нормально не работает, я даже указать имя выходящего бинарника через -o не смог (просто не создает ничего). Использует libc и gcc для компиляции файлов.
Zig: Занимает 167 МБ (~8400 файлов), вместе с собой тащит стандартные библиотеки C и крестов. Бинарник вышел почти полМБ, но зато с флагом --release-small - всего 8 КБ!
Nim: 69 MB, ~2700 файлов (из которых 1700 это тесты компилятора, которых мне нахуй не нужны). Бинарник - 136 KB, с флагом на релиз и оптимизацию - 87 KB.
>>1578702 Судя по более чем сотне постов за полсуток рабочего дня (из которых большая часть пришлась на утро, когда постинг не слишком активен) - оптимизм не излишен. Но этот тред изначально планировался в виде объединенного для нескольких C-подобных языков, хоть V и самый хайповый из них.
>>1578709 Знаю, анонче. Использовал то, что уже стояло, тем более это вроде как самая официальная реализация. Так же и с Go - есть их говнокомпилятор без линкера, а есть gccgo с линкером и всеми оптимизациями gcc (я жмушные компиляторы больше люблю, хоть llvm и перегоняет по оптимизациям в некоторых случаях). Бинарники GDC под виндой работать не будут, судя по их сайту. LDC потестил, 226 мегабайт, но бинарники уже на полмегабайта выдает, а оптимизации (-O -release) размер не режут вообще.
>>1578710 >пока что сидим в этом, а после бамплимита общий? This. V всё равно будет иметь первостепенную роль в шапке как самый популярный, как мне кажется.
>>1578729 Звёздочки на гитхабе не показатель популярности. D уже в продакшене используют, а V ещё не стабилизировался. Ну набежали гитхаберы на интересное описание с плюшками, понаставили звёздочек, и что? Пусть хотя бы в двадцатку tiobe войдёт.
>>1578724 >напоминает болгенос Болгенос - нагло спизженный продукт с переклееными этикетками. V - это скорее Антивирус Попова™, т.к. заявленного функционала чуть более, чем дохуя, а на деле он либо только в мануале, либо пыль в глаза (флаг -compress, на котором заглушка стоит, или неработающее самообновление).
>>1578738 У D изредка даже свой тред всплывает, но на плаву достаточное время продержатся не способен, быстро тонет. V явно побольше интереса вызывает у проходящих мимо анонов. С объединенным тредом нормально будет.
>>1578705 Этот тред в виде объединения не планировался. Тот анон, что упоминал V вчера днём и рассказывал, что уже пишет шапку, ко мне отношения не имеет. Я не согласен с идеей объединения этих языков в одну категорию, т.к. в отличие от остальных V пилится фанатичным двачером. Ни Nim, ни Zig, ни D зачем это старьё вообще сюда тащить не стремятся сразу закрыть все ниши — REPL, текстовый редактор, веб-фреймворк, встроенная ORM, движок для форума, либа для GUI. В то же время Zig даже пакетным менеджером не разродился, хотя предложения добавить висят в issues с 2017. V заюзал короткое стильное и запоминающееся (хоть и не в первый раз взятое для названия ЯП) имя. Набиря v -v ты понимаешь, что это не npm --version, здесь другие ребята, хоть и настолько же амбициозные и склонные к принципу FITYMI.
>>1578793 На винде у меня не работает: V panic: exec failed (CreateProcess): The system cannot find the file specified. TODO: print_backtrace_skipping_top_frames_mingw(2) print_backtrace_skipping_top_frames is not implemented on this platform for now.
Может mingw не той версии (у меня не самый новый, но и не слишком старый должен быть; впрочем, у меня там пара инсталяций, и хуй знает, какую оно решило использовать). В любом случае, было бы неплохо получить хотя бы неотфильтрованную ошибку mingw, а не сообщение о том, что функция для фильтрации вывода не реализована.
>>1578813 >ФП очень сильно связанно с желанием индивида самоутвердиться. Как будто ойти и программирование в целом не связаны, лол. Программистишки бегают туда-сюда и пытаются всем доказать, что вот они то настоящие программисты, а <языкнейм>-программисты -- не программисты.
>>1578804 У него, кстати, какое-то фанатическое нежелание добавлять новые ключевые слова (впрочем, это объяснимо, учитывая собранный на коленке парсер). Можно было бы вообще извращение по типу такого придумать: x, y, z := slice(a) На отмену от := a это не выглядит как попытка присвоить массив переменным, к тому же можно версию с указанием длинны сделать, что бы можно было инициализировать новый массив из куска другого: dst := slice(src, 8) Его решение для массивов с более чем 5 элементами будет напоминать создание псевдословарей из C, или даже чего похуже - заполнение словаря парой десятков элеметов в C#.
>>1578816 Ой, слушай, спасибо что напомнил. У Медведникова же ещё пилится https://github.com/vlang/vos со своим гибридным ядром. Но это затея настолько ебанутая, что контрибьютора там всего три.
Автор V мне напоминает того шизика из хабра, который 12 лет (по его словам) свой говноЯП пилил (cine), тоже в Сишечку компилируется кстати. Но V явно поуспешнее будет, уже донатов и звезд успел понахватать, хоть они оба сырые.
>>1578854 Он же вроде перегоняет код в C и дальше компилирует его при помощи gcc, разве нет? Свой код он в C транспилировать может, а вот когда научится бинарники делать - хуй его знает.
>>1578690 >Бинарник HW занимает 123 KB, с флагами -g -prod 87 KB (без -g не компилируется с -prod), -compress декоративный. Ты сегодня это тестил? На какой платформе? У меня не hello world, конечно, но простенькая утилита с запросами по сети (import term, time, net, os) после -prod -compressed занимает 19400 байт. При этом для -compressed требовалось поставить upx. Такое решение, да, не нативное, но зато strip'ом больше нечего чистить.
>>1578941 Сегодня, там в первом предложении платформа (Win, архитектура x86-64), но версия V немного не актуальная (впрочем, автор яблопидор и приоритеты у него другие, так что не особо жду). Флаг -compress реализован только на *nix, в Windows декоративный (выводит сообщение, что пока не поддерживается). strip - утилита ЖМУ, а они практически все портированы на винду, так что почистить уже готовые бинарники и я могу, god bless rms. Почему с этим не справляется линкер языка - для меня загадка, но это уже больше не к V вопрос, а к D и прочим языкам, у которых бинарники по полмегабайта. У Go хотя бы оправдание есть - у них линкера нет вообще (слишком сложная тема для гугловских трансгендеров и альтернативно белых), и простой вывод в консоль добавляет 2 мегабайта мертвого груза.
Глядя на все эти нововасянские языки, у меня почему-то возникает желание не бежать выбирать самый захайпленный и ждать с моря погоды, а как бы вопреки всему напридумывать свой, который будет ищщо быстрее/проще/компактнее/сахарнее и вообще утрёт носы. Хоть и не суждено этим фантазиям сбыться.
Прикольная штука, но непонятно, что делать, если в одной либе есть interface bar с функцией foo, а в другой либе есть interface baz с функцией foo. Да и куча других проблем вылезет на больших проектах. А для хелловордов и олимпиадок удобно, конечно.
>>1579991 А нахуй оно нужно? Для целочисленных типов есть implicit конверсия (даже кастовать не нужно, не кресты), так что функция, принимающая long будет точно так же работать и на int, и на short (разве что переполнение возвращаемого числа чуть по другом может работать). А для чисел с плавающей запятой всё равно придется отдельную функцию пилить, если там что-то нетривиальное, т.к. 5 / 2 != 5.0 / 2.0.
>>1578789 Zig тёплый и уютный. А v для впереди паравоза бегущих хипстеров.
Автор уже заполнил анкету?
Аноним21/01/20 Втр 23:38:18№1580160185
Итак, Вы собираетесь создать новый [] функциональный [] императивный [] объектно-ориентированный [] процедурный [] стековый [] мультипарадигменный [] быстрый [] статически-типизированный [] динамически-типизированный [] чистый [] богатый [] не-искусственный [] наглядный [] простой для новичков [] простой даже для не-программистов [] абсолютно непостижимый язык программирования.
Не получится. И вот почему. Вы, скорее всего, верите, что: [] Синтаксис — это то, что делает язык сложным [] Сборка мусора бесплатна [] Компьютеры имеют бесконечную память [] Никому на самом деле не нужны: [] параллельность, [] интерактивность, [] поддержка отладчика, [] IDE, [] ввод\вывод, [] взаимодействие с кодом на других языках. [] Весь мир общается в 7-битном ASCII [] Масштабирование для больших проектов будет простым [] Убедить программистов пользоваться новым языком будет просто [] Убедить программистов пользоваться новой IDE будет просто [] Все программисты любят шаблоны [] Вам не аукнется обозначение некоторого поведения как «неопределенного»
К сожалению, в Вашем языке есть (нет): [] нормальный синтаксис [] точка_с_запятой_в_конце_строки [] проблема табов\пробелов [] макросы [] неявное преобразование типов [] явное преобразование типов [] наследование [] goto [] исключения [] замыкания [] хвостовая рекурсия [] подпрограммы [] рефлексия [] подтипы [] множественное наследование [] перегрузка операторов [] алгебраические типы данных [] рекурсивные типы данных [] полиморфические типы данных [] монады [] зависимые типы данных [] префиксные\постфиксные операторы [] вложенные комментарии [] переносы строк [] регулярные выражения [] вызовы по имени [] вызовы по адресу.
И еще возникают такие вот философские препятствия: [] Программисты не обязаны полностью понимать теорию относительности и квантовую механику чтобы написать на Вашем языке «Hello, World!» [] У программистов не должен развиться туннельный синдром за время написания «Hello, World!» на Вашем языке [] Пока что самая выдающаяся программа на Вашем языке — это компилятор Вашего языка [] Пока что на Вашем языке Вы не можете написать даже компилятор Вашего языка [] А еще у Вас нет никаких спецификаций [] Реализация — вот спецификация [] но реализация закрытая, [] защищена патентами, [] не принадлежит Вам [] Ваша система типов дефектна [] Некоторые конструкции Вашего языка, возможно, не могут быть трактованы однозначно [] и есть конкретные примеры таких конструкций [] и они валят Ваш компилятор [] Название Вашего языка делает невозможным его поиск в Гугле [] Ваш язык — интерпретируемый, а значит никогда не будет столь быстрым как С [] Ваш язык — компилируемый, а значит никогда не будет гибким [] Для компиляции Вашего языка требуется искусственный интеллект [] Вы рассчитываете на оптимизации, которые, откровенно говоря, не способны реализовать [] В мире меньше 100 программистов, достаточно умных, чтобы использовать Ваш язык [] Задача ________________, которая у всех решается за полиномиальное время, на Вашем языке реализуется только за экспоненциальное [] А задачу __________________ и вовсе реализовать нельзя
Кроме того, Ваша реализация имеет следующие недостатки: [] CPU работает не так, как Вы думаете [] RAM работает не так, как Вы думаете [] VM работает не так, как Вы думаете [] И компиляторы не работают так, как Вы думаете [] Более того — они даже в принципе никогда не смогли бы так работать [] Конфликты «сдвиг-свертка» по ходу парсинга решаются методом rand() [] Вам зачем-то понадобилось присутствие компилятора в рантайме [] Вам зачем-то понадобился рантайм в компиляторе [] Ошибки, выдаваемые Вашим компилятором, загадочны и непостижимы [] Компилятор падает даже от брошенного на него косого взгляда [] Вы не понимаете базовые принципы оптимизации [] Вы не понимаете базовые принципы системного программирования [] Вы не понимаете указатели [] Вы не понимаете функции
И еще есть и некоторые маркетинговые проблемы: [] Вам нечего ответить на просьбу увеличить скорость работы [] Вам нечего ответить на просьбу упростить язык [] Вы внаглую сфальсифицировали бенчмарки [] в компилятор были вшиты вычисленные заранее значения расчетов, симуляций или тестов [] в тестах строковых операций Вы незаметно использовали Perl [] в мат. тестах Вы незаметно использовали BLAS [] Хотя это не помогло и никто всерьёз не поверил, что Ваш язык быстрее, чем [] Ассемблер [] С [] Фортран [] Java [] Руби [] Пролог [] Вы бездоказательно отбросили классическую теорию разработки языков программирования [] Вы бездоказательно отбросили основы системного программирования [] Вы бездоказательно отбросили теорию алгоритмов [] Да Вы вообще все компьютерные науки отбросили
Смотря на всё это в общем, следует заметить, что: [] Ваш «короткий» пример на 2 десятка строк можно реализовать одной строкой в языке __________ [] Уже существует небезопасный императивный язык [] Уже существует безопасный императивный язык [] Уже существует безопасный статически-типизированный функциональный язык [] Вы переизобрели Lisp, только хуже [] Вы переизобрели Javascript, только хуже [] Вы переизобрели Java, только хуже [] Вы переизобрели C++, только хуже [] Вы переизобрели PHP, только хуже [] Вы изобрели что-то лучше, чем PHP, но это не оправдание [] Вы переизобрели Brainfuck, вот только в отличии от его авторов — на полном серьёзе
Ну и вот что я о Вас думаю: [] Вы молодец, у Вас есть кое-какие интересные идеи. Но это не взлетит. [] Получился плохой язык и Вам должно быть стыдно за него. [] Программирование на этом языке — самое адекватное наказание Вам за его изобретение.
>>1580160 Создание ЯП - аутизм ещё тот. Продумывал парочку, на деле дошел до рабочего прототипа только один (ИСЧХ, в него я вложил меньше всего усилий - буквально несколько часов; чуть не переизобрел стаковый язык по типу Forth с облегченным синтаксисом). Что я из всего этого извлек:
1. Хорошая и обширная стандартная библиотека очень важна; 2. Компилироватся язык должен прямиком в машинный код, а не в C, иначе это просто большой макросов с кастомным парсером; 3. Ключевые слова языка должны быть предсказуемыми и иметь однозначный смысл для всех возможных применений (плохой пример - static в чистом C), на конструкции по типу for, while, iter жлобится не стоит; 4. Флаги компилятора (кроме самых базовых), если не планируется встроенная система сборки, лучше разрешить указывать в самом коде - здесь хороший пример C с его #pragma.
>>1580208 Проектировал свой язык, но уперся в том что не хватает нового составного типа данных. Не ООП (в том числе, наследование, агрегация, делегирование) и даже простые структуры не решают вагон встречаемых задач без костылеварения.
Поэтому вся эта сахарщина херня и не имеет смысла (привыкнуть можно ко всему). Если нет гибких "кирпичиков" из которых будешь строить туже стандартную библиотеку. Начинать даже не стоит
>>1580275 Мне даже читать неохота, но представлю, что один обмудок на zig понял, что если принтинь хеллоу-ворд с минимальным числом сисколов, то это будет, неожиданно, очень быстро. И решил оптимизировать именно этот участок, чтобы померятся пиписьками.
Возможно, это безумие осталось бы незамеченным, но в соседней палате, кто-то бомбанул от этого, и побежал тоже оптимизировать то, что в нагруженном проекте никогда и не используется (поэтому и не оптимизировано).
Пока нормальные проекты замеряют свои писюны в вебе, или в число-дробилках, где-то в другом месте, отважные, но не очень умные, меряются принтами.
> - Loading complex 3D objects with textures wip > - Camera (moving, looking around) wip > - Skeletal animation wip > DirectX, Vulkan, and Metal support is planned. > Coming soon: > - a Delphi-like visual editor for building native GUI apps > - iOS/Android support with native controls > - a declarative API similar to SwiftUI and React Native. wip, wip, coming soon, planned. Охуенные плюсы!
>>1580522 ОП-хуй этот тред запилил, пока шапку для общего пилили, сейчас уже нет смысла раскалывать на два. Тут половина треда обсуждение всяких Zig'ов с Nim'ами, но адепты этих языков не так часто забегают, т.к. не могут найти. Вот можешь почитать, что ОП спизданул: >>1578789
>>1580543 Этот тред выглядит как тред для V. Народ уже по-проигрывал и забил болт. Никаких Nim и D тут обсуждать не будут, потому что красуется заголов V и все проходят мимо.
>>1580569 Очередной ждущий всего готового. Хочешь быстрее — садись и помогай пилить. Пулл-реквесты в master каждые полдня вливаются. Всё растёт, всё меняется, баги фиксятся, добавляются новые, фичи пилятся, ломаются старые, это живой блядь организм, посмотри на график контрибьюторов.
>>1580638 Давай гитхлам я тебе про D залью, раз ты обосрышь один не можешь. Он согласился создать, за язык не тянул никто. Первую тему можно без шапки бампать инфой по языкам.
Разобрался, почему make компилятора v не работал на винде (самообновление по той же причине скорей всего). Оно требует установленный и помещенный в PATH бинарник git. Уебанство ещё то, как по мне, т.к. оно ради одного (!) файла из другого репозитория требует эту хуйню, причем в зависимостях нигде не указано (указан только gcc). В итоге ручками собрал (насчет <1 секунды на сборку компилятора автор неплохо так наебал).
>>1580670 Хуй с этими обновлениями (хотя git в зависимостях нигде нет, что бы понять, нужно в сурцы этой обновлялки лезть). Нахуй один файл компилятора было в отдельный репозиторий выносить? Когда я клонирую репу, я жду, что зависимости либо там присутствуют, либо указаны явно.
>>1580686 Шизик, как ты можешь работать с опенсорцом и не иметь в PATH бинарника git? Может надо было в докер образ тебе завернуть с предустановленным гитом? А чтобы ты смог запустить докер, надо было написать положить его рядом в репозиторий?
Давайте разберем по частям написанное автором V в его репозитории на гитхабе:
>Simplicity: the language can be learned in less than an hour При условии, что ты уже хорошо знаешь хотя бы один C-подобный язык, конечно.
>Fast compilation: ≈100k — 1.2 million loc/s Пиздежь.
>Easy to develop: V compiles itself in less than a second На моем 4-ядерном i5 компиляция компилятора v компилятором v заняла ~22 секунды.
>Performance: within 3% of C Не нужно быть писателем бенчмарок, что бы понять, что язык который предоставляет абстракции поверх C и компилируется в него же, сможет работать с такой же скоростью в исключительно редких случаях.
>C to V translation Пиздежь, нет вообще ни в каком виде. Зачем выдавать запланированное за действительное - хуй его знает.
>C and JavaScript backends Никакого JavaScript бэкенда там нет, так что очередной пиздеж.
>>1580690 Мне обязательно нужно иметь его в path? Обязательно пользоватся той самой реализацией? Она обязательно должна быть названа git, а не wingit, g, git-v2? Только красноглазый пидорас или яблопидор мог додуматся тащить в зависимости бинарник на сотню мегабайт ради одного текстового файла с кодом.
>>1580708 Ну это пиздос конечно. Вообще-то так и есть, ты не программист. И эти люди потом в соседнем треде девочку из Яндекса называют взятой по гендерным квотам. Так девочка в Яндексе пишет код в виме под i3, а местные "программисты" собирают код из подсказок IDE и коммитят мышкой.
>>1580761 Не программист так не программист. От своих слов не отказываюсь, даже будучи линуксоидом, ебущимся с консолью и гитом каждый день. При чём тут вообще гендер? Раздел, вроде, про программирование, а не про врождённые особенности анатомии людей.
>>1580780 делаешь/думаешь не как мейнстрим - не погромизд а так как сообщество чсвшное, с какого хуя правда не особо понятно, то это принимает пугающие формы.
>>1580761 Ох уж эти борщехлебы, определяющие настоящесть программиста по тому, насколько колючий кактус он себе в жопу вставил без всякой на то причины.
>>1580842 А автор V не программист, а эффективный рекламщик. Вместо того, что бы запилить нормальную платформу, он с работающим через раз компилятором и незаконченным синтаксисом полез пилить обертки для отрисовки GUIшек. Зато можно пост на Patreon высрать о том, что в языке теперь GUI можно рисовать - и срубить очередную порцию бабла с хомячков, т.к. они в сорцы всё равно не смотрят. А на деле за два года написан только большой набор макросов для C с костыльным парсером и обертку вокруг gcc, а автор целыми днями сидит в конфочках, насасывающих его поделию - орошает почву для потенциальных инвесторов, так сказать.
Если он восхищается языком Го - он неопытен и глуп. Если он пишет на vim - он ограниченный и фанатик с которым будет трудно работать (потому что он особенный и код у него особенный).
Предположим, в V из функции мне нужно было бы вернуть массив и какое-то число. Что я бы мог потенциально сделать: 1. Передать ссылку на массив аргументом, а вернуть число. Мутабельные массивы перестают работать, когда передаются в функцию (for now it's not possible to append an element to a mutable array argument либо ошибка C). 2. Вернуть кортеж (tuple). Их в языке нет, так что облом. 3. Вернуть struct. Они аллоцируются на стэке, так что не получится. Аллоцировать заранее тоже нельзя, см. пункт 1.
Вот и всё. Единственный способ - записать изменение в какой-то из элементов массива, но это возможно только для числовых массивов, и нужно делать проверку на переполнение (к примеру, i8 хранит только числа до 127, так что такой массив размером 128+ не вернешь уже без кучи извращений).
>>1581425 Типы данных в массиве должны совпадать. Если первый элемент возвращаемого массива - массив стрингов, в нулевой уже не положишь ни число, ни числовой массив.
>>1581446 Map тоже не вариант, в этом языке это словарь. Перечитал доку по страктам, там таки можно на куче их аллоцировать, так что вполне себе вариант.
Объясните кто-то этому пидарасу (который автор V), что количество байтиков в UTF-8 (в котором его говностринги хранятся) != количеству букв. Слово "хуй" - 3 буквы, а не 6. Почему 3-байтовые символы там имеют длинну 4 - я вообще не ебу.
А почему об отсутствии сборщика мусора он так тактично умалчивает? Стал бы кто-либо пользоватся языком, если бы на его страничке было написано, что все аллоцируемые массивы не освобождаются, а память в любой программе с ними течет не хуже, чем пизда феминистки во время месячных? Самый крупный проект на V - блокнотик vid, весит меньше vim, а вот в памяти через 15 минут работы весит как полноценная IDE, т.к. течет не переставая.
>>1578220 (OP) Почему опенсурс сообщество совместными усилиями не запилит наконец полноценную замену С/С++? Почему ноунейм одиночки считают, что им это под силу? Вот Линус, например запилил свой гит, потому что другие системы контроля не устраивали, да и C++ он не любит.
>>1581659 Потому что сообщество, походу, нихуя не может. Даже вся экосистема лялеха, которая тащится энтузиастами, по большей части была придумана ещё в прошлом веке, и до сих пор глюкнутая и не юзер-френдли. Кто может? Крупные компании, у которых есть миллионы человекочасов, но им некогда, денежки кто-то уже сейчас приносить должен. Вот тот же голанг такой не потому, что у гугла нет ресурсов на допиливание, а потому что он решает их бизнес-задачи, а большего и не нужно.
>>1581659 Да потому что у всех програмиздов баг: подавляющее большинство слабосоциальные интроверты, которым очень сложно коммуницировать и искать компромиссы объединяясь в одно большое сообщество, но гораздо проще форкнуть/переписать или сделать свою реализацию.
В итоге имеем горы языков, форков, дублирующих софтин, библиотек, фреймворков, дистрибутивов и сотни самописанных парсеров json/xml/cfg и етц. Комплекс бога "я сделаю лучше" — только всё усугубляет. Было бы иначе — то каждая опенсорсная софтина/либа/дистр/фреймворк в редких случаях имела бы максимум 1 форк/реализацию... А так имеем десятки, сотни тысячи вариаций и комбинаций одного и того же...
ЗЫ: речь сугубо про открытые нонпрофитные сообщества, а не проприетарщину и ентерпрайз в которых надо делать, что скажут.
>>1582000 Наглый пиздёж про интровертов. Чтобы где-то опубликовать свой велосипед, уже нужно быть экстравертом, который с лёгкостью может договориться с остальными. Дело только и исключительно в "комплексе бога".
>>1582158 > Чтобы где-то опубликовать свой велосипед, уже нужно быть экстравертом, который с лёгкостью может договориться с остальными. Нет. Можно держать гитхаб как зеркало и ни с кем не договариваться.
>>1582140 Городские стандарты на благоустройство: везде реальные требования одни и те же, но у каждого города свой стандарт. Да любые законы в целом, натуральные форки. Хотя казалось бы, чиновники постоянно на совещания должны кабанчиками скакать. В искусстве вообще брать чужое на грани зашквара. Бизнес? Да такая же хрень, постоянно изобретаются велосипеды и люди сидят на работе скриптов, пока не придет программист и не автоматизирует. Попробуй зайди в магазин для электронщиков и охуей от разнообразия микросхем, микроконтроллеров и прочей поебени. И это кто-то произвел с вложением десятков и сотен тысяч долларов, а не просто нажал кнопку fork на гитхабе.
Просто ты открыл для себя молоток типа "программисты не умеют общаться" и дальше везде видишь гвозди, хотя это большей частью манямирок в твоей голове.
>>1581996 Потому что C++ многие не любят, в том числе уважаемые люди, как Линус. А Си устарел и не очень подходит для разработки крупных проектов. Игровые движки, 3д пакеты, фото/видеоредакторы и прочий высокопроизводительный софт на чистом Си практически никогда не пишется.
>>1582257 Заменить C очень сложно, т.к. он близок к идеалу. Все те языки, которые в этом треде обсуждались - всего лишь расширения/дополнения/макросы (superset) для оригинального C, иногда хорошие, иногда несущие слишком много ограничений в замену пары новых фич. Причем достигнуть близкой к C производительности будет очень сложно, т.к. C фактически портируемый ассемблер, и 90% его фич очень хорошо натягиваются на инструкции архитектуры x86, а там половина "убийц C" генерирует какой-то невнятный код на том же самом C с кучей оверхедных конструкций и тяжелыми либами для простых возможностей языка, и все это потом компилируется отполированным компилятором C, ибо все, что они могут высрать - это трансляторы. ООП возможности крестов вполне может заменить C#, однако что-то низкоуровневое пилить на нем неудобно, а куча абстракций привносит своих оверхеды (Java ещё хуже, т.к. низкоуровневость почти такая же, и при этом генерации нативного кода я в ней не видел, так что только JVM, что уже сосет на распостраненных архитектурах). Комплексной (полноценной) замены не планируется, т.к. всё, что пилят сейчас - это абстракции поверх, а не горизонтальные альтернативы.
>>1582263 >ООП возможности крестов вполне может заменить C# Ёбнулся совсем? В том же абзаце пишешь > невнятный код на том же самом C с кучей оверхедных конструкций и тяжелыми либами для простых возможностей языка, и тут же на голубом глазу про сиришётку. Аллё, друг, там виртуальная машина, сборка мусора и рантайм, который жрёт на диске больше, чем библиотека стима.
>>1582445 >виртуальная машина Байткод C# умеет компилироватся в нативные бинарники (причем под конкретную архитектуру, аналог -march=native в C) - гугли ngen (MS сама прогоняет через него библиотеки .NET при установке).
>сборка мусора Ты прав, но за последние несколько лет я очень редко встречал бинарники на винду на чистых крестах, а не C++/CLI (managed C++).
>рантайм, который жрёт на диске больше, чем библиотека стима. Тем не менее, он зачастую уже включен в винду с момента установки. И если уж макаки дорвались до написания приложений, пусть лучше пользуются широкой стандартной библиотекой самого языка, чем тащат две сотни зависимостей (как на говНоде) или вообще целиком инстанс хрома (electron) - там обычный блокнот будет весить столько, как клиент-версия библиотеки .NET.
>>1582472 В ноябре выйдет новая версия дотнета, которая будет единой и опенсорсной (дотнет полностью перейдет на опенсорс). Скринте, топ язык 20ого десятилетия.
>>1582504 На бэке у него сто тысяч конкурентов, так что рынок на бэке вряд ли сильно у него как-то изменится, разве что место джавы пододвинет, как язык для десктоп-приложух он и так весьма значимую долю имеет
>>1582507 Всегда радует реакциях этих из криогенной камеры. Оказывает дотнет уже теснит пхп, а они все там думают как на жаба-коболе спринг запустить так, чтоб не тормозил, или как на го делать кодогенерацию, пробрасывая ошибки ручками верх по стеку, как веселые мартышки.
>>1582543 Шаред хостинг в 2020, когда vps на пару центов дороже. Попробуй продвинуть в поисковом ранжирование сайт на шаред хостинге, где на одном IP 10К таких же сайтов, половина из которых флуд/спам/скам.
>>1582550 Ставлю тебя перед фактом. В компании, где я работал, более 30 linux серверов для шаред хостинга, на каждом по ~500 сайтов. Из них 99.9 на PHP. 15к сайтов на PHP, живых, блядь, оплачиваемых, наполняемых, продвигаемых и поддерживаемых кем-то сайтов. И это ни разу не топовый хостинг провайдер РФ. В каком у тебя манямирке все вдруг метнулись на .NET, когда допиливание сайта на .NET обходится владельцу в разы дороже,— понятия не имею.
>>1583376 >Если это у жабы всё плохо, то об остальных языках вообще говорить не стоит Логика уровня программист. Конечно, ведь все 3 квинтиллиона дивайсов работают на жабе.
>>1583456 Хотел написать на джаве в энтерпрайзном ООП стиле, но заебался уже на предметной области и проектировании. Пикрелейтед схема моего небольшого пет-проекта по генерации капчи.
>>1583492 Сама java EE это продукт фантазии бородатых дядек, которые скорее всего даже уже код реальный не пишут, а рисуют интерфейсы, ради интерфейсов.
Программирую серьезно херову тучу лет, до сих пор не могу нормально проектировать сверху вниз. То что уже писал ни раз, легко могу, но новую предметную область - нет. Постоянно приходится переосмысливать, переписывать (абсолютно пустая трата ресурсов). Коллега говорит я тупой у меня функциональное/процедурное мышление, но качественнее код я пишу именно снизу верх.
>>1583515 Джава ЕЕ хоть и морально устарела, но и появилась она давным-давно, в те времена, когда из альтернатив был только убогая CGI-лапша на языках типа перла.
>>1583520 Если сама генерации это что-то сложное, его тоже делишь на части и пишешь сначала самое простое, что можешь из этих частей. Но так же снизу вверх потом собирая.
>>1583521 Это можно сказать про сервлеты. Они были настолько практичны, что даже пилили отдельной контейнер, который не включал весь EE, а только часть сервлетом. Все остальное в ЕЕ это поток говно фантазии (и как и половина ранних w3c творений)
>>1594724 Он с момента создания был обречен сдохнуть. Целых 250 постов понадобилось что бы распробовать V и понять, что он - недоделанное говнище, ибо его создатель столько всего напиздел, что целого треда не хватит для опровержения его пиздливых высеров.
>>1595929 Будто у кого-то были сомнения. Программисты, будучи одним из самых платежеспособных слоев населения в этой стране, предпочитают тратить деньги на потреблядство (в первую очередь из-за комплексов, полученных благодаря бедному/неполноценному детству - по крайней мере я пока не встречал кодеров, выросших в богатых благоприятных семьях, кроме тех случаев, когда это было ещё во время того, когда вычислительная техника была роскошью). Даже те единицы, которые решают вкатится в бизнес, чаще всего обречены на провал из-за наивности мышления и полного непонимания процесса продажи товара (в котором 80% зависит от маркетинга, и лишь 20% от качества и всего остального) - парадокс, вызванный тем, что все потенциальные айтишники с предпринимательской жилкой ещё на стадии выбора профессии ушли в кабанчики, оставляя лишь маленький процесс исключений - хоть и незначительный, но активно расхайпленный СМИ в виде историй успеха отдельных айтишников, которые при выяснении обстоятельств часто имеют опосредствованное отношение к непосредственно написанию кода.
>>1595938 Жабу-то не трогай. У них просто традиции - перекатыватся после 1000 поста.
>>1578220 (OP) Как эти конченные умудряются каждый раз делать другой синтаксис, уже столько языков создали и все равно находится залупа которая делает другой синтаксим
>The new compiler can finally compile itself! >The old backend will now be removed after all tests pass. >The new AST based backend is much cleaner, easier to develop/maintain, and ~2 times faster. >Special thanks to @joe-conigliaro and all other contributors who helped make this happen.
Реальной рандомный васян решивший создать язык при помощи щитпостинга
>>1581659 Твой вопрос надо разделить на два: >С Нахуя? Любая адекватная замена сишки - это просто чуть более лучшая сишка. Ну можно улучшить проверку типов, можно добавить кортежи, можно подкрутить синтаксис хотя синтаксис - это число вкусовщина, у всех свои критерии, можно сделать нормальные модули, но это же всё мелочи.
Если внести какие-нибудь радикальные изменения, например, поменять управление памятью, то это будет уже не сишка. Несишек и так дохуя, есть Rust, есть языки с мусоросборниками.
Я, как человек часто использующий Хаскель, периодически имею дело с сишкой. И для меня сишка - это просто такой примитивный инструмент, типа молотка, нужный чтобы гвоздь забить. Ну да, теоретически можно сделать у молотка прорезиненную рукоятку, можно неодимовый магнитик поставить. Но, сука, она и так работает, нахуй мне изъябываться, чтобы раз в полгода забить гвоздь?
А если мне нужен не молоток, а гидравлический пресс, то я и возьму гидравлический пресс. При этом гидравлическим прессом гвозди забивать тоже не оче, он хоть и дохуя продвинут, но для забивания гвоздей лучше взять что-нибудь попроще.
Вот так и сишка. Её фишка в её примитивности. Простые инструменты тоже нужны. Компилируется на любом говне, полно библиотек, свои задачи решает. Неудобная ручка, выпиленная дедом из пня, занозы? Так надень перчатки, в чём проблема вообще?
>C++ C++ и так на данный момент очень нишевый инструмент. Люди, которые используют C++, и так хорошо понимают, почему им нужен именно C++. Те, кому C++ не нужен, пишут на языках с мусоросборниками, пишут на скритовом гоне, выбора тащемта вагон, бери любой язык под задачу. Поэтому что такое "полноценная замена C++" мне не понятно. Альтернатив крестам полно со своими фишками и заёбами, но если человек взял кресты, то, наверное, именно кресты ему лучше и подходят.
>>1578852 Автор cine это классическая такая история. Каждый кодер пока вырастет, чем-то таким переболеет. Только у этого парня хватило чсв свои наивные юношеские фантазии и открытия выдать за что-то всерьёз полезное. А 12 лет это норма, по строчке кода в месяц, как раз и выходит что пилил ты свой язык аж целых 12 лет.
> Memory management > The compiler cleans everything up during compilation > If your V program compiles, it's guaranteed that it's going to be leak free.
Какая-то неубедительная хуйня. А если я создаю циклические ссылки? А если создаю объекты в куче? Там что, весь стейт программы нужно через стек протаскивать?
>>1776695 Мне нравится, идея с " a:= 5; a: int = 5" была позаимствована у блоу, который наверное тоже откуда-то позаимствовал, прикольная идея как по мне. Синтаксис поинтеров немного непривычен, но как утверждает создатель, взят из паскаля.
>>1776695 Что ты несешь, кого там блять раст победил?) Его как не юзали в проде, так и не юзают, а пока Сишка на 1 месте в TIOBE, кресты на 4, и кресты дохуя где используются и продолжают использоваться. В этом языке столько киллер-фич, построенных гениями, что убить его не получится еще очень, очень долго. Покажи мне еще один ЯП, который больше половины вычислений может перекидывать на компайл тайм, имеет возможность бесплатного по рантайму полиморфизма и имеет нечто похожее на темплейты (нет, дженерики далеки от темплейтов), а темплейты, напоминаю, Тьюринг полные, это фактически отдельный язык программирования внутри плюсов. И, внимание, резолвинг ВСЕГО, что связано с темплейтами, происходит во время компиляции - 0 футпринта на рантайм. А variadic templates? Короче, говорить можно об этом долго.
Вердикт таков - даже у раста нет шансов, это мертворожденная хуйня для борщехлебов-хипстеров, которую ждет максимум участь языка D, и это в лучшем случае.
>>1777484 Это не присваивание, как ты подумал из-за знания паскаля, а объявление переменной с выводом типа. Этот синтаксис высрали в Go, затем сабж его спиздил.
>>1578220 (OP) Все еще не понимаю смысла существования V. Nim уже придумали. Какой смысл в V? Появится смысл только если будет куча либ, гейм-движков и кросплатформеннолсть. впрочем как и у нима
>>1777548 Ну так можно относительно легко сделать себе имя написав несколько самых насущных либ. Такое ощущение что на дваче сидят не гребцы, а сплошные капитаны галер.
>>1776969 > Что ты несешь, кого там блять раст победил?) Я же сказал: победил уебищностью синтаксиса. Это совершенно другая олимпиада, чего ты сразу загорелся?
>>1578441 >Более абстрактной фразы найти не могли? Можно более нормальное описание нахуй он нужен. Если авторы языка, пытаясь описать, зачем он нужен, и чем он лучше существующих, не в состоянии придумать ничего содержательного, значит, их язык ничем не лучше и не нужен, по их же собственному мнению.
- армяне лучше, чем грузины! - чем же они лучше? - чем грузины!
>V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.
>Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
Только вот непонятно, как это всё на самом деле работает. Про autofree еще можно поверить, но действительно не всегда можно статически вычислить время жизни переменной. Дальше он пишет про reference counting, но reference counting тоже не поможет при циклических ссылках, например.
И откуда такая скорость конпеляции - тоже не понятно. Тем более если он делает при конпеляции какой-то анализ для вычисления времени жизни объектов.
>>2022036 >И течёт тоже быстрее. Не проверял конечно, но вроде не течет. Покрайней мере по отзывам. > Этим всё сказано. Ну чел, это тебе не это. Если бы это дико текло, вой бы стоял по всем интернетам. А тут только парочка озлобленных шизов с хакерньюс ноют.
>>2022071 Штош, вопрос с GC вроде решился. Хуякнуть escape analysis, когда он не работает, хуякнуть reference counting, сверху заполировать Boehm-ом. Ну, ладно, допустим такой подход имеет право на жизнь, осталось понять, как там устроена кодогенерация.
Парсер ручной и очень страшный, очевидно никаких абстракций язык не поддерживает.
AST фронта большой и страшный.
Единственный чекер чекает прямо по AST-у фронта. Причем прямо всё подряд чекает вручную, титянический труд наверное было его напейсат. Ну может это и нормально, если в языке нет какого-то сложного вывода типов. Похоже, вся конпеляция вообще однопроходная.
Сишный бэкэнд хуярит сишку writeline-ми. Autofree - похоже действительно примитивный escape analysis, причем скоупом считается скоуп в языке, прямо как вы его задали. Анализа присвяивяний не могу найти. Возможно его нiт. Объясняю, что происходит на пикрелейте. Допустим у вас есть:
a = malloc(хуй) x = f(* a) { retun a; } return x
Вот тут очевидно нельзя добавлять free(a), нужно знать, что было внутри f. Афтор решил эту задачу, да как красиво! Создаёт переменную tmp в которую копирует стурктуру целиком, теперь можно удалить все выделенные переменные (если, конечно, внутри функции f они куда-нибудь не утекли). Собственно, для этого, наверное, и нужно, чтобы функции были "чистыми" и не было глобальных переменных. Потому что какого-то явного assignment analysis я там не вижу.
Некоторые оптимизации тоже встроены в генератор. Однопроходные, естественно, матчит ноды AST-а и заменяет на более "оптимальные" на его взгляд.
Нативный генератор недописан. Вернее там вообще почти пусто, кругом заглушки. Есть такое ощущение что это вообще не должно конпелироваться, потому что есть вызовы несуществующих функций. Или я в глаза долблюсь. Интересно, про какие миллионы строк в секунду на нативном генераторе они говорили. Миллионы строк в секунду на заглушках?
>>2022114 По какому всему интернету? V - это накроенная поделка 20 детнего русского студента,юез какого либо серьезного опыта в разработке - он буквально учится программировать, создавая V.
Язык по существу никому неизвестен и никем не используется.
>>2022241 Короче, котятки, мои выводы по данному языку.
Начну с плохого.
Полностью согласен с людьми, которые "воспринимали язык как мем". Это и есть мем. Это вовсе не "безопасная сишка" for developing maintainable software, это очень опасный препроцессор сишки, который расставляет free() по своему усмотрению. Четкой концепции управления памятью нет.
Этот >>1578240 прав. free() расставляются в кодогенераторе по каким-то одному автору известным критериям. Этот >>1578240 не прав. Т.к. статически определять точное время жизни объекта в тьюринг-полных языках невозможно (из-за проблемы остановки), это не будет полностью работоспособным никогда. Будут постоянные сегфолты. По мере добавления новых правил их будет всё меньше, но количество правил тут бесконечно.
Язык не сильно течёт. По крайней мере после того, как прикрутили Boehm.
Про скорость конпеляции - пиздёж. Если на выходе код на Си, то полная конпеляция по определению не может быть быстрее работы финального конпелятора Си. Что имелось ввиду под нативным кодогенератором - я не совсем понял. Я его тупо не нашел (может в глаза долбился).
Генератор Си - однопроходный препроцессор. Он может быть быстрым, но он, сука, почти ничего не делает, поэтому и быстрый. Но чтобы решать подобные https://github.com/vlang/v/issues/9881 проблемы, нормальный тайпчекер нужен и type inference.
По мере реализации нужных фич появится необходимость и в развитии AST, возможно, в добавлении нескольких промежуточных AST, во многопроходном конпеляторе и в применении алгоритмов с большей вычислительной сложностью. Как сейчас это написано - это полный ахтунг. Модули по 7 тысяч строк с закатами и восходами солнца в ручном режиме и непонятным образом размазанной по ним функциональностью (вроде оптимизаций AST на стадии кодогенерации). Это всё надо будет рефакторить, чтобы это можно было развивать и сопровождать, следовательно когда язык достигнет зрелости, никакой скорости там уже не будет. О чём думают разработчики нативного кодогена, я вообще не знаю, они хотя бы аллокацию регистров осилят? (хотя, это решаемо, ведь можно генерировать LLVM IR)
Во-первых, востребованность подобного языка. Автору не нужно доказывать, зачем нужен этот язык, все и так это прекрасно понимают. Всем нужен язык "как Сишка, но лучше." И мы знаем, как успешно это взлетает. Вот есть Java, есть Kotlin - это как Java, но лучше (тоже поначалу критиковали). А Котлина для низкоуровневого программирования нет. Rust - это не Kotlin для низкоуровневого программирования, это скорее Scala. И Go - это не Kotlin для низкоуровневого программирования, это низкоуровневый Groovy. А автор V очень хорошо определил хотелки к низкоуровневому Котлину, прямо угодал, что люди хотят (хоть и не смог этого реализовать). Возможно ему бы следовало назвать свой первый релиз не pre-alpha, а "Здраствуйте. Я, Alexander Medvednikov. Хотел бы чтобы вы сделали язык, Си-подобный суть такова..." и продавать саму идею.
Впрочем, идею он продал на отлично. 23k звёзд. 1.4k форков. У GHC 2.5k звёзд. Конечно, разработка GHC хостится на собственном сайте, на гитхабе только зеркало, но автор безумно успешен. Продолжу в следующих постах.
Я категорически не согласен с >>2022251. Вернее, с посылом, что мол у автора нет опыта разработки, поэтому всё плохо. Да нет, всё хорошо. Да, сам пару часов потратил, чтобы изучить исходники, и они, сука, гениальны. Да, я там найду 100500 миллионов проблем, о части из которых я писал выше, но это всё не важно.
А важно то, что автор - ёбаный гений пиара, ёбаный гений анализа потребностей и ёбаный гений создания MVP. Ну и как программист он тоже хорош.
Это становится понятно, если анализировать его код не с точки зрения дизайна, а с точки зрения подхода к решению конкретной задачи - создать продукт. Хуйнуть идею, продемонстрировать возможность её реализации, привлечь людей. Какая разница, насколько там всё хуёво внутри и какие есть сейчас "нерешаемые" проблемы в его концепции? Илон Маск сейсас какие-то силосные бочки на ракетном двигателе запускает, обещая полёты к Марсу. Так вот, автор V - это тот же Илон Маск на минималках.
Что такое MVP? Это minimum viable product. Это когда ты не задротсвуешь, а конпелируешь и запускаешь Tetris, Doom, веб-сайт и текстовый редактор на всех патформах на недописанном языке, который который хочешь продать. Это когда ты запускаешь в небо силосные бочки, а через год, когда привлёк ресурсы, уже вполне нормальные ракеты. Вот только так это и работает. Теперь только от автора зависит, как он распорядится привлеченным к нему вниманием, сможет ли он грамотно распорядится ресурсами и довести проект до ума.
Linux - это кривая поделка. Linux изначально был сделан на коленках и хуёво. Таненбаум сделал Minix ОС правильно, и вообще, он явно лучше шарил в разработке ОС, чем его ученик. Но взлетело именно кривое поделие Торвальдса.
PHP - это крайне хуёвая поделка. Да, но она смогла себя продать, она была крайне бездарно спроектирована, но как MVP могла демонстрировать себя лучше Перла и уж тем более лучше чем Си, как язык для разработки веб-страниц. В итоге язык получил развитие, его подтянули и он стал очень популярным.
Ведь секрет успеха не в правильных инженерных решениях, а в правильном PR. Будут люди, придут и инженеры, создай продукт и раскрути его, а недочёты в нём уже исправят те, кто в этом шарит.
Какие объективные проблемы есть у V?
Например, объектвно кривая работа с памятью. Но это реальная проблема? Допустим, сидит какой-то сыч, который знает, как правильно работать с памятью. Однако, он никогда не будет пилить свой язык, потому что он никогда не привлечет людей и никогда его не раскрутит. А что мешает ему присоединиться к команде V и сделать правильное управление памятью? Ведь достаточно всего одного компутерсаентиста, чтобы спроектировать грамотную систему управления памятью. Более того, ему даже программировать не придётся, достаточно пейпера, если есть комьюнити, которое всё за него закодит.
Или вот их ебанутые потуги в разработки нативных бэкэндов, которые даже мой не очень профессиональный взгляд не очень жизнеспособны. Но даже если хоть один грамотный бэкэндщик присоединится к их команде, он легко решит их проблемы, даже я примерно знаю, как их решить.
Или проблемы с промежуточной оптимизацией. Ну придёт к ним специалист, скажет ваша оптимизация хуйня, сейчас я вам покажу как правильно, и сделает core-to-core.
Был бы лидер проекта, остальное всё нарастёт, если проект окажется востребованным.
-------------
Теперь мои мысли относительно жизнеспособности V.
Сейчас я вангую, что проект не доживёт до реализации нативного кодогенератора, потому что в этом плане они двигаются в очень неправильном направлении и никогда не смогут переизобрести llvm. Но, как я уже писал, будет достаточно всего одного человека, который в этом шарит. A у них 23k звёзд.
Сейчас я вангую, что их подход к управлению памятью очень кривой и опасный и такую хуйню никто не примет, но что если придёт человек, который её препроектирует?
И это возможно. Ведь недавно они пиздели, что им не нужен AST, а в итоге кто-то пришел и сделал им AST. Ведь дело не в технических проблемах, а в том, смогут ли они собрать людей, которые захотят их решить.
У Скалы 13k звёзд, у них 23k. Это очень серьёзная заява, посмотрим, смогут ли они переварить внимание к своему гениальному хайпу и конвертировать его в успешный инструмент, или всё проебут.
>>2022397 >Вот только так это и работает Это так никогда не работает. Нет ни одного успешного масс продукта, который на стадии mvp был говно говном, а потом когда привлек ресурс еге перепилили как следует. Всегда все наоброт, и говно становится еще большим гвном. А когда степень говна доходит до критической отметки, происходит форк, который перепиливают с нуля, и часто совсем другие люди, может быть лишь косвенно связанные с первоначальной версией. После чего изначальный прдукт либо умирает вместе с компанией, либо форк не взлетает, и гвоно продолжает плавать, до следующей попытки форка. И эти процессы дляться десятилетиями. А пока они дляться, появляться новый говенный mvp очередной идеи, который затмевает уже потребность перепиливать прежнее говно, и все начинается с начала.
>>2022428 И по итогу, ты просто всю жизнь пользуешься ГОВНОМ-MVP в красивом фантике, потому что на рынок они выходят быстрее. Но они никогда не становятся в конечном счёте качественым продуктом.
>>1578813 Желание самоутвердится очень сильно связано с несоответствием представлений индивидума о его возможностях с его реальнымы доходами. Программисты в Германии по скилам примерно равны программистам в Белоруссии или Казахстане.
Однако, сытый бюргер, программирующий на Джаве и едящий свои сосички, вряд ли захочет что-то менять и тратить время на самоутверждение. А белорусский программист спросит: "0уле я такой умный, но бедный, может быть во мне что-то не так, может быть мне надо стать функциональной илитой?"
На самом деле, самые безбашенные функциональщики живут в Индии. Ты только на это посмотри https://eta-lang.org/ Полный порт Хаскеля на jvm. Просто снос башки по трудозатрам. И сделал это всего один индус со своей женой (или со своими женами, я не знаю, как у них устроено).
Но Индия выглядит на карте как страна ООП просто потому, что там дохуя аутсорса, который перекрывает таких поехавших. А так-то да, чем беднее страна, тем больше программистов, которые ищут себя в альтернативах мейнстриму. Такая моя теория.
>>2022428 >Нет ни одного успешного масс продукта, который на стадии mvp был говно говном А Linux? А Windows? А Delphi? А PHP? А ёбаный в рот и в жопу Oracle, который Ларри не просто недоспиздил, но ещё и назвал своё недоспиженное говно "версией 2", чтобы всех наебать и показать, что, мол, первая версия была, а его украденное и недособранное говно ещё лучше?
Все современная индустрия - это mvp-говно, я даже не могу найти обратных примеров.
>>2022434 >linux Ты на полном серьезе не знаешь, какое адское адище представляет собой набор костылей?
>windows Ты не в курсе про ветки 9x и полностью перепиленнный с нуля форк windows nt? Или ты не читал пост? А про развитие всех последующих версий винды на базе nt ты действительно считаешь полноценным допиленым продуктом? vista? 8? м?
>php Про полностью перепиленный с нуля php 4 в который впилили ООП, и новый с нуля написанный для него zend ты тоже не в курсе?
>>2022435 >Ты на полном серьезе не знаешь, какое адское адище представляет собой набор костылей?
Знаю. Я же о том и писал, что Linux был говном с самого начала. Ты ведь просил представить масс продукт, который на стадии mvp был говно говном. Вот, Linux. Был говно говном. Сейчас он один из самых популярных и востребованных продуктов.
>Про полностью перепиленный с нуля php 4 в который впилили ООП, и новый с нуля написанный для него zend ты тоже не в курсе?
Да в курсе. В том-то и поинт, что сделали говно, но привлекательное для людей говно. А когда люди начали на нём программировать, появились и ресурсы, чтобы его перепилить.
> Сейчас я вангую, что проект не доживёт до реализации нативного кодогенератора, потому что в этом плане они двигаются в очень неправильном направлении и никогда не смогут переизобрести llvm. Но, как я уже писал, будет достаточно всего одного человека, который в этом шарит.
Автор here.
Неделю назад наняли толкового человека с большим опытом, который работает только над нативным x64/arm64 бэкендом.
> Про скорость конпеляции - пиздёж. Если на выходе код на Си, то полная конпеляция по определению не может быть быстрее работы финального конпелятора Си.
Может, так как в Си нет модулей, хедеры ужасно замедляют компиляцию.
В V модули аккуратно кэшатся, и не надо при компиляции репарсить тысячи одних и тех же строк в хедерах.
> О чём думают разработчики нативного кодогена, я вообще не знаю, они хотя бы аллокацию регистров осилят? (хотя, это решаемо, ведь можно генерировать LLVM IR)
конечно осилим
а юзать LLVM IR, который ровно в 10 раз медленнее натива аля tcc, + Сpp зависимость, мы не будет
>>2022461 Автор, раз ты здесь, поясни, что за хуйня с нативным кодогенераторм и заявой что он якобы очень быстрый? Я просто ничего не понял. Я не нашел рабочего кода на вашем гитхабе, он у вас есть и я что-то упустил, или это просто ваш vision, что мол вы предполагаете сделать какой-то супер быстрый нативный кодогенератор?
>>2022463 Т.е. вы всираете в конпелятор Си исходники в более удобном для него формате? Ну да, там можно что-то ускорить, но я бы не стал заморачиваться. Я бы всё-таки разделил сферы ответсвенности. Если конперяторы сишки как-то плохо работают с хедерами, то это проблема конпеляторов сишки, авторы конпеляторов Сишки с этим сами разберутмя. Я бы сосредоточился на самом языке. Демки все посмотрел.
>>2022465 >конечно осилим Но зачем? Вы просто повторите работу, которая была сделана в llvm. Ну как бы да, это можно сделать, если очень захотеть и если llvm по каким-то причинам не устраивает. Но сам же пишешь, что есть tcc, который быстрее хотя, за счет чего быстрее? может просто хуёво оптимизирует, магии ведь не бывает
Короче, есть такое чувство, что на кодогенерации вы обосрётесь. Но будет очень забавно, если не обосрётесь. Наблюдаю за проектом.
> Но зачем? Вы просто повторите работу, которая была сделана в llvm.
потому что ровно в 10 раз быстрее и не С++
> Если конперяторы сишки как-то плохо работают с хедерами
все компиляторы. затести например компиляцию sqlite3.c. в одном файле vs sqlite проект
> Автор, раз ты здесь, поясни, что за хуйня с нативным кодогенераторм и заявой что он якобы очень быстрый? Я просто ничего не понял. Я не нашел рабочего кода на вашем гитхабе,
нативный кодогенератор сейчас поддерживает вызовы функций, for, if, while
на ранней стадии, но над ним активно работает человек с опытом
>>2025806 >Ты должен спрашивать у разрабов llvm и gcc почему они в 10 раз медленнее tcc.
Вопрос не о tcc, а вашем нативном бэкэнде. TCC быстро работает потому что он однопроходный и не применяет многих оптимизаций. Или вы хотите сделать как в TCC? Но это же ограничит область применения языка.
>Ты только что скинул ссылки на 1100 строк кода и пишешь, что там пусто.
Ну да. Ваш сишный бэкэнд 10+к строк. В нативном я не нашел аллокации регистров, опимизацинных проходов, и главное, всей этой истории, связанной с автоматическим управлением временем жизни объектов. Или всё это не планируется?
Если будете делать оптимизирующий компилятор, вам потребуется делать его нормально, с IR и оптимизирующими проходами. И тогда скорость станет как у gcc/llvm. Плюс, это просто безумный объём работы, который команда llvm уже сделала.
Компилятор, который работает быстро, но ничего не оптимизирует, полезен на стадии разработки (хотя, интерпретатор даже лучше). А для продуктовой компиляции всё равно потребуется оптимизирующий компилятор. Допустим я напишу на V программу, а потом захочу, чтобы она была скомпилирована со всеми оптимизациями и работала быстро. Что мне тогда делать?
TCC - это очень специализированный инструмент. Он быстрый не потому, что авторы gcc/llvm дураки, а потому, что он изначально задизайнен чтобы быть очень маленьким быстрым. И применяется он там, где нужен очень маленький и быстрый компилятор, чтобы что-нибудь бутстрапнуть, или чтобы на лету что-нибудь компилировать.
Отсюда вопрос к языку. V позиционируется как язык общего назначения, или это аналог специализированному инструменту TCC с измененным синтаксисом?
>>2022428 >Нет ни одного успешного масс продукта, который на стадии mvp был говно говном, Есть некоторые продукты которых до сих пор говно, лол. Че несешь, шизло
> Если будете делать оптимизирующий компилятор, вам потребуется делать его нормально, с IR и оптимизирующими проходами. И тогда скорость станет как у gcc/llvm.
нет, не станет. case in point: Go
> Вопрос не о tcc, а вашем нативном бэкэнде. TCC быстро работает потому что он однопроходный и не применяет многих оптимизаций. Или вы хотите сделать как в TCC?
у нас уже как в tcc, прямая генерация машинного кода, конечно компилирует процентов на 40 медленнее из-за дополнительных проверок, так как tcc не чекает ничего, даже уникальность филдов в стракте.
для производительных билдов есть -prod (использует -O2), наш родной бэкенд только для дев билдов пока, оптимизация будет только через пару лет
>>2026973 >нет, не станет. case in point: Go За счет чего не станет? Вы придумали какой-то охуенный способ оптимизировать программы, не тратя на это процессорное время?
>у нас уже как в tcc, прямая генерация машинного кода Так tcc - это пиздец марахайка. Он никогда не дизайнился для того, чтобы генерировать быстрый код. Он дизайнился, чтобы генерировать код быстро. Он и используется в тех случаях, когда код надо генерировать быстро. Поэтому для продуктовых билдов люди будут брать другой компилятор. Более медленный, но оптимизирующий.
>оптимизация будет только через пару лет Т.е. за джва года вы сделаете аналог gcc/llvm? Но нахуя, а главное, зачем? И что заставляет вас думать, что по достижению того же качества оптимизации вам удастся сохранить скорость?
>v -prod file.v лол Я так понимаю, это перенаправит выхлоп в какой-нибудь оптимизирующий конпелятор Си лень перечитвать ваш код?
Наверное, уточню вопросы.
Есть задачи: 1. Генерировать код быстро (для dev-билдов). 2. Генерировать быстрый код (для prod-билдов).
Есть решения: 1. tcc бэкэнд 2. gcc/clang/llvm бэкэнд На самом деле, можно взять ваш выхлоп для tcc и просто перенаправить его в оптимизирующий конпелятор. Фактически, у вас эта задача уже решена, у вас есть транслятор V -> C, а дальше вы либо перенаправляете его в tcc для скорости, либо в clang/gcc для оптимизаций.
Поэтому я не понимаю, для чего вы создаёте собственный нативный генератор и какую нишу он займёт? Это конкурент tcc или конкурент gcc/clang или что-то среднее?
>>2034016 > Поэтому я не понимаю, для чего вы создаёте собственный нативный генератор и какую нишу он займёт? Не могу говорить за авторов, но сишечка как целевой язык - это пиздец в плане тулинга. Если gdb еще как-то можно заскриптовать, то лицезрение в vtune ебанины с покорёженными именами просто вымораживает. Разработка же простенького ssa ir бэкэнда - это от месяца до трёх, и откроет интересные возможности типа edit-and-continue, корутин и тому подобного, вполне в струю изначальных обещаний. Сам язык от этого менее ненужен не станет, но всё же.
>>2034678 >Разработка же простенького ssa ir бэкэнда
У них там нет ssa, у них очень своеобразный кодогенератор в стиле TCC. Т.е. про аллокацию регистров там вообще речи нет. Там как-то так:
>TCC compiles every statement on its own, and at the end of each statement register values are written back to the stack and must be re-read even if the next line uses the values in registers (creating extraneous save/load pairs between statements).
Вот и они что-то похожее нарисовали. Я сам очень удивился, когда не нашел ничего связанного с раскраской регистров в коде, поэтому и подумал, что это недописанная хуйня. На самом деле, хуйня вполне дописана. Но она очень своеобразная. Так конпелировать можно, но зачем, если это не оптимально и есть TCC, который ровно это и делает?
>от месяца до трёх Но есть же нормальный ssa ir в llvm, в который уже въебали человеко-столетия. Ну да, за 3 месяца можно сделать свой, но это же будет просто упрощенный llvm. Аргумент про скорость конпеляции - странный, llvm конпелирует медленно не потому что с ним фундаментально что-то не так, а потому что он применяет много оптимизаций. По мере взросления самопального ssa -конпелятора он так же будет замедляться и стремиться к llvm. И вот вопрос, нахуя нужен еще один, если для скорости и так есть TCC, а для оптимизации - взрослые конпеляторы?
>>2035214 >и тут Джон решил в энный раз поменять синтаксис объявления типов или длбавить/убавить оопэшности и/или метапрограммирования >релиз открытой беты отложился ещё на год
>>2035233 >register values are written back to the stack and must be re-read Я вот подумал, а со store forwarding'ом это даже не так медленно получится, как изначально кажется.
>>2035233 > И вот вопрос, нахуя нужен еще один, если для скорости и так есть TCC, а для оптимизации - взрослые конпеляторы? Да даже независимость от tcc стоит того, всё же это игрушка, а не инструмент. golang вот неплохо справился: ssa ir компилятор и lowering при помощи матчинга деревьев. Пишется подобное - элементарно, по производительности код, навскидку, вровень с джавой, а больше для не-мэйнстримного языка ничего и не нужно.
> Аргумент про скорость конпеляции - странный, llvm конпелирует медленно не потому что с ним фундаментально что-то не так, а потому что он применяет много оптимизаций.
абсолютно неверно
llvm c 0 компиляций (-O0) компилит ровно в 10 раз медленнее tcc
> >нет, не станет. case in point: Go За счет чего не станет? Вы придумали какой-то охуенный способ оптимизировать программы, не тратя на это процессорное время?
>>2044894 >в Go не стало, и у нас не станет Go — хуёвый пример.
В Go ложили и ложат хуй на выборочное включение функций из импотрированных библиотек, из-за чего helloworld на нём весит несколько мегабайт. Но вы, конечно, покруче, и решите эту проблему без трейдоффа скорости на размер или наоборот.
Вы, конечно, в регистры вместо стека сможете (в отличии от tcc) без замедлений скорости. Ведь ещё одна неконстантная операция с ветвлениями на каждый второй генерируемый опкод — это дёшево.
В Go есть сборщик мусора, а в C ручное управление памятью. Ты же хочешь управлять памятью ещё в compile-time — для тебя это тоже бесплатно.
Ты ещё не видишь в этом проблем, а я уже замечаю кучу подводных в виде алгоритмов с потенциально квадратичной сложностью.
У тебя нет возможности выиграть по сложности алгоритмов — обогнать их ты сможешь только за счёт полного их выбрасывания (вместе с функционалом или оптимизациями, как в tcc). Но спонсорам языка это знать не обязательно, конечно.
>>2050317 >Как пофиксил? Подставил символ ∗ вместо звёздочек *. А пробелы тоже заменять на nbsp или что-то подобное предлагаешь? Их компилятор Nim не жрёт, например.
>>2050392 Так Python их тоже не переваривает, например — хотя если скажешь, что он тоже васянское поделие, то я не смогу не согласиться. При этом считает nbsp символами названия, и падает с SyntaxError: invalid character in identifier.
Можно ^H пройтись до постинга и при копировании, конечно, но это такой же костыль, как и со звёздочками. Работающий тег code был бы лучше.
>>2051515 >Их макаба заменяет на обычные. Хуясе, не знал — теперь буду использовать их. Правда, большую часть ЯП отсутствие пробелов не сильно огорчает (и есть кнопка Reformat в случае чего).
>А его компилятор жрёт? Нет, это левый символ (хоть и похожий внешне). Но это лучше, чем ничего — особенно когда ты код с указателями в C-тред скидываешь.
>>2051672 > Хуясе, не знал — теперь буду использовать их. На этом приколе основан мем «newfags can’t teiforce», так что это классика, это знать надо.
> Правда, большую часть ЯП отсутствие пробелов не сильно огорчает (и есть кнопка Reformat в случае чего). Обычно копировать в IDE лень, поэтому надо, чтобы уже в посте код выглядел читабельно. Если изначально код выглядит хорошо, тогда как раз намного больше вероятность, что клиент скопирует код в IDE (уже чтоб потестить, например), а если код выглядит как каша, то он вообще им не заинтересуется.
> Нет, это левый символ (хоть и похожий внешне). Но это лучше, чем ничего — особенно когда ты код с указателями в C-тред скидываешь. Это да. Обидно, что нет нормального решения, чтоб нормальные звёздочки отображались.
>>2052378 >На этом приколе основан мем «newfags can’t teiforce», так что это классика, это знать надо. Да трифорсить я умел; но как-то не задумывался, что те пробелы потом в обычные превращаются. Хотя в ретроспективе это выглядит логичным, иначе ньюфаги просто бы копировали эту хуйню.
>>2082640 Половина веб-разрабов 2д игру и на шарпах/джаве/го/чем угодно еще не реализуют. На самом деле для создания своего движка с нуля нужно знать много паттернов, которые типичный CRUDодел или фронтенд-макака и знать не знают.
>>2090957 Буквально позавчера закончил делать первую версию игру на первой версии своего многопоточного движка (2d) на C# с изолированной от логики отрисовкой кадров на процессоре (потом перепилю на OpenGL или вулкан). Из общеизвестных заюзанных паттернов только синглтон и делегирование, остальное не вписывалось в архитектуру и приходилось придумывать своё. Так что на чисто знании паттернов далеко не уедешь, нужно знать ещё и платформу на достаточном уровне.
>>2123083 Порвался? C# может работать ничуть не медленнее, чем плюсы. Да, графон уровня фростбайта на нём выдать нереально, но я и не претендую как бы. Юношеский максимализм - очень скверная штука, молодой человек. Ну да ладно, тебе пора бежать формочки доделывать.
>>2123740 GC никак не влияет на скорость работы. По сути, это просто минус головняк с указателями. И тут уже только о тебя зависит - создаёшь ли ты GC лишнюю головную боль или нет.
А вот, например, проверка на out of range при каждом обращении к элементу массива - влияет. Но у C# есть unsafe. Можно при желании запилить свои структуры данных (что мне и пришлось сделать).
>>2124102 Единственное, на что влияет реально GC - это расход оперативки. С в C++ объект можно сразу удалить если он не нужен, в GC-имущих языка объект просто провисит в памяти какое то время.
>>2124124 >в GC-имущих языка объект просто провисит в памяти какое то время. И куда он оттуда денется? Его оттуда святой дух удалит? Или он сам не выдержит несовершенства мира и решит удалиться? Долбоёб, сука! Почему unity говорит всем игроделам использовать object pools? Не потому ли, что в играх приходится не использовать GC _вообще_, иначе привет фрейм хитчи по несколько сотен миллисекунд пока GC проходит по графу твоих объектов?
>>2234314 Как же быстро активизируются маги чистой воды в этом книжном рынке. То книга по шарпу 2022 года, выпущенная 2021 году под итерацию шарпа 2020 года.
То книг пхп 6 насрали столько, что парням пришлось с 5 на 7 переходить, чтобы не вводить в заблуждение ньюфагов языка.
>>2255311 > Simple, fast, safe, compiled language for developing maintainable software. Если бы авторы всех существующих языков реально преследовали какую-то обоснованную цель, их бы не расплодилось так много.
>>2255703 Такие квази языки создаются, чтобы потешить свое самолюбие. Если раньше хоть старались, то сейчас откровенно непригодное говно делают, но пихают и подгоняют под все тесты, создавая иллюзию реального ЯП.