Практически сразу после анонса языку стали пророчить светлое будущее в качестве замены не только Си, но и других ЯП. Однако энтузиазм разделили далеко не все участники ИТ-сообщества. В лагере скептиков оказались даже сами разработчики Hare.
Мы в T1 Cloud предлагаем решения для бизнеса и разработки, поэтому решили разобраться в ситуации и обсудить аргументы сторон.
Что еще за Hare
Это — системный язык программирования, заточенный под написание компиляторов и сетевого ПО. Его разработала команда под руководством Дрю Деволта, создателя платформы SourceHut и mail-клиента Aerc. В основу языка положена идея ручного управления памятью и статическая типизация. Исполняемые файлы генерируются на бэкенде компилятора qbe. В стандартную библиотеку Hare входят модули для работы с сетью, криптографические реализации (хотя используемые функции пока не прошли независимый аудит), парсеры и лексические инструменты для POSIX. Есть привязки к OpenGL и SDL2, а также библиотеке libui для построения кроссплатформенных GUI.
Что касается синтаксиса, то вот так может выглядеть программа для вывода Hello World! на нескольких языках:
use fmt;
export fn main() void = {
const greetings = [
"Hello, world!",
"¡Hola Mundo!",
"Γειά σου Κόσμε!",
"Привет, мир!",
"こんにちは世界！",
];
for (let i = 0z; i < len(greetings); i += 1) {
fmt::println(greetings[i])!;
};
};Для желающих познакомиться с языком поближе разработчики подготовили документацию и руководство. Оно последовательно переходит от разбора базовых параметров к более углубленным вещам — например, срезам (slices), типам, обработке ошибок. Также имеет смысл изучить исходники компилятора и стандартной библиотеки. Авторы передали их в open source под лицензиями GPLv3 и MPL соответственно.
(НЕ) замена другим
Когда авторы анонсировали Hare, то в своем блоге написали, что с функциональной точки зрения язык сильно напоминает Си, но значительно проще. Тогда крупные СМИ и тематические площадки подхватили идею о том, что Hare заменит известный язык общего назначения. На сложившуюся ситуацию даже пришлось отреагировать авторам Hare и внести ясность. По их словам, об отказе от Си речи пока не идет, по крайней мере, в обозримом будущем. Аналогичную мысль разделяют резиденты Hacker News. Один из пользователей площадки заметил, что для конкуренции с устоявшимися языками, Hare стоит обзавестись более богатой библиотекой. В качестве примера он привел Go, который позволяет относительно быстро построить веб-приложение «из коробки».
Помимо вопросов, связанных со стандартизацией, участники ИТ-сообщества отметили и другие «узкие места» нового языка программирования. Так, один из разработчиков NoSQL-решения RavenDB раскритиковал Hare за подход к структурам данных и хеш-картам в частности. По словам инженера, их построение — нетривиальная задача, которую редко можно решить в пару строк кода.
Авторов нового языка программирования также критикуют за позицию по работе с памятью. Hare продвигает концепцию полного доверия к действиям программиста. Но в ИТ-сообществе есть люди, которые убеждены, что разработчикам не стоит управлять памятью вручную — тогда резко возрастает риск ошибок, вызванных человеческим фактором. Работа с памятью — дискуссионный топик, и справедливости ради стоит заметить, что у создателей Hare была причина пойти по этому пути. Многие механизмы memory management отрицательно влияют на производительность кода, что противоречит концепции компактного и быстрого языка. В то же время авторы все же реализовали ряд защитных механизмов. Например, язык заставляет инициализировать все переменные, а в обработке ошибок применяются тип-суммы (tagged unions).
Что с перспективами
Хотя Hare во многом похож на старшего брата, можно ожидать, что ему еще предстоит столкнуться с «детскими болячками». Но разработчики планируют продолжать развитие продукта. В ближайшее время они закончат со спецификацией и будут вносить только обратно совместимые изменения в стандартную библиотеку.
Будут и другие изменения. В настоящий момент Hare поддерживает всего три архитектуры – это x86_64, riscv64 и aarch64, но этот список будет расширен 32-битными архитектурами. Также будут интегрированы функции для работы с TLS 1.2 и 1.3 и новые порты (они дополнят Linux и FreeBSD), но исключительно для свободных платформ. Хотя активные участники сообщества могут выпустить реализации для Windows или macOS.
Разработчики делают упор на формирование сообщества, в котором люди захотят общаться и обмениваться опытом — по их мнению, другим языкам еще предстоит много работы в этом направлении. Проекту Hare удалось вызывать интерес — обсуждению ЯП посвящен не один тред в социальных сетях, а программисты делятся мыслями в личных блогах. На Hare уже написано несколько простых инструментов — среди них, компактный движок для трассировки лучей, торрент-демон btqd и альтернатива cron — scheduled. Также можно выделить менеджер паролей Himitsu и микроядро Helios.
Но получится ли у языка набрать достаточно серьезную пользовательскую базу, станет видно в будущем. Поскольку ЯП ориентирован на разработчиков FOSS, он рискует остаться интересным, но нишевым проектом. Нам интересна дальнейшая судьба Hare, и мы продолжим следить за обстановкой в этой области, а также другими историями из мира open source — подписываетесь на блог T1 Cloud, где мы рассказываем про открытое программное обеспечение (и не только):
Комментарии (99)
GospodinKolhoznik
04.07.2022 21:24+31Для такого провокационного названия статья слишком уж пустая.
Я совершенно не понял, что за харэ, на кой чёрт оно нужно и почему оно должно заменить си, а не паскаль, например?
nikolas78
04.07.2022 22:11+10По моим наблюдениям, создатели новых языков все время допускают какие то стратегические ошибки в их дизайне, а потом годы тратят на их исправление. Некоторым везет больше (Go), некоторым меньше (D). Неужели нельзя сразу сделать хорошо.
bombe
04.07.2022 22:36Крошка сын к отцу пришел, и спросила кроха: - Что такое хорошо и что такое плохо?
Каким должен быть хороший язык? Возможно ли, что везение зависит не только от стратегических ошибок, а, например, еще и от парадигмы, ниши, екосистемы?
nikolas78
04.07.2022 22:54+1Да, и это тоже. Hare одновременно должен быть хорош и для железа, и для ОС, и для игр — я вот вообще в это не верю.
KaminskyIlya
04.07.2022 23:58+2Каким должен быть хороший язык?
Да Вы правы, "хороший" - это больше из области вкусовщины. Кому-то нравится функциональный подход, кому-то - императивный. Кто-то любит циклы, кто-то рекурсии. И т.д. В этих ваших интернетах только и споры об этом.
По моему скромному мнению, новый ЯП, претендующий на статус "хорошего", обязательно должен впитать в себя все сильные стороны других ЯП, учитывать их опыт, и по максимуму нивелировать выявленные недостатки. Хочешь ручную работу памяти - пожалуйста; хочешь сборщик мусора - тоже. Хочешь строгих типов - используй. Хочешь сейчас писать без типов - пожалуйста. Не мешать опытному программисту писать потенциально опасный системный код, но помогать неопытному (и опытному тоже) не допускать типовых и серьезных ошибок.
Хороший ЯП не должен иметь конструкций или предъявлять каких-то требований, от которых большая часть программистов будет страдать. Не должно быть перекоса в какую-то одну область или парадигму. Синтаксис языка не должен сильно отличаться от мейнстрима и вызывать боль.
Новый современный ЯП должен быть универсальным: позволять писать как драйвера и компоненты ОС, так и простые сценарии для веб-страниц, компьютерных игр.
И это лишь малая часть требований к хорошему языку. Но как я уже сказал ранее: термин "хороший" сильно завязан на вкусы.
AnthonyMikh
06.07.2022 00:27+1Хочешь строгих типов — используй. Хочешь сейчас писать без типов — пожалуйста.
Не существует такой ситуации, когда имеет смысл писать без типов. И да, gradual typing на практике немного не работает.
0xd34df00d
06.07.2022 03:00+2Не, ну почему. У меня вот есть
~/backup.shна десяток строк, вызывающий в циклеrsyncдля трёх целевых хостов — там без типов сойдёт.
yatanai
06.07.2022 18:29+1Хороший язык должен иметь прозрачную логику. В этом плане "базовые" языки ещё никто "нормально " не переплюнул. А новые языки должны ещё уметь компилировать базовые языки + иметь поддержку бизнеса, иначе не взлетает.
BlackJet
06.07.2022 21:34+1Ассемблер - лучший язык. Но больше НИКОГДА не хочу на нем ничего писать )))
WASD1
05.07.2022 16:45+1А какая стратегическая ошибка у D (на исправление которой создатели тратят годы)?
Так-то я вижу разве что "неверный таргетинг" (user-friendly С++ оказался не очень нужен), но тут проще этого выбросить и нового заделать, а не накромождать кучу костылей многолентим переделыванием.
Siemargl
05.07.2022 17:38+1Ну еще:
чехарда с версиями языка когда синтаксис по чуть-чуть постоянно меняется
ломающий переход D1->D2 с абсолютно новой стандартной библиотекой
не всем понравился Dub
плохенько с IDE
Но в целом, BetterC + ImportC это киллер фича для обновления С-программ и почти ничего не надо переписывать.
Gordon01
04.07.2022 22:14+20В основу языка положена идея ручного управления памятью и статическая типизация.
Но зачем, нам уже показали что борроу-чекер может заниматься выделением памяти автоматически одновременно защищая от любых ошибок с этим связанных?
Siemargl
05.07.2022 10:44-3Не автоматически, а очень-очень вручную и все время бьет линейкой по пальцам =)
Gordon01
05.07.2022 11:25+6Не автоматически, а очень-очень вручную
Вероятно ваше определение АУП отличается от общепринятого.
и все время бьет линейкой по пальцам =)
Новичкам в программировании все время что-то бьет по пальцам, это нормальный процесс обучения.
Siemargl
05.07.2022 12:41-1Строго говоря, borrow checker вообще не является инструментом выделения памяти, а всего лишь контроля.
Gordon01
05.07.2022 13:04+2И опять вы ошибаетесь.
BC — это и есть механизм автоматического управления памятью в Rust, который эволюционировал из "всего лишь контроля" в версии 1.0
Советую читать историю и делать фактчекинг, прежде чем утверждать что-то громкое, гугл в этом неплохо помогает, например по первым же трем ссылкам из запроса "borrow checker automatic memory management" выдаются неплохие статьи:
https://steveklabnik.com/writing/borrow-checking-escape-analysis-and-the-generational-hypothesis
https://blog.logrocket.com/introducing-the-rust-borrow-checker/
dayllenger
05.07.2022 15:27-1Выделением памяти занимается аллокатор, а не борроу чекер. Не видите разницы между выделением и управлением?
Gordon01
05.07.2022 16:22Перепутали кому отвечать? Да и в целом, все равно все понимают, какой смысл в том что вы тут надушнили, теперь проветривать придется (
dayllenger
05.07.2022 19:00Современные программисты игнорируют аллокаторы памяти, считая их какой-то жутко низкоуровневой штукой, в которую вообще не нужно лезть. При этом кастомные аллокаторы упрощают ручное управление памятью и дают больше контроля. Я не представляю себе альтернативу Си без возможности хотя бы контекстный аллокатор выставить.
Gordon01
06.07.2022 17:44Я не оч понимаю, на что вы отвечаете. Это точно мне или вы просто тестируете нейронку?
saipr
04.07.2022 22:15функциональной точки зрения язык сильно напоминает Си, но значительно проще.
Мне до сих пор казалось, что описание языка Си Эндрю Таненбаумом на 12 страницах самое крутое.
nmrulin
05.07.2022 01:10+3У Оберона краткое описание языка одну страницу вообще занимает. Правда полное больше , чем у Си, целых 20.
ReadOnlySadUser
05.07.2022 10:31Говорял Javascript умещается на кружке) К сожалению, это не делает язык универсальным)
DerRotBaron
06.07.2022 00:52-1Но язык, котороый он описывал, и для которого описание достаточно и корректно, уже лет 30 компилировать нечем.
Для реального современного Си надо указать еще сравнимый объем случаев, которые с буквоедской точностью надо помнить, чтобы довольно простой и очевидный код не превратился в тыкву при компиляции. Да, это не плюсы, но и этих граблей хватает чтобы считать Си чуть ли не вредным и точно крайне сложным языком.
OlegZH
04.07.2022 23:31+2Конечно, хотелось бы узнать, как мог бы выглядеть язык программирования ++C. Или C--. Или --C...
Начать новый язык следовало бы с концепции. Или прямиком с основной идеи. Например, LISP. А давайте сделаем так, чтобы каждый объект был списком! (Сейчас, разумеется, следовало бы создавать язык программирования GRAPH, где каждый объект является графом или сетью.)
Что еще за Hare
Это — системный язык программирования, заточенный под написание компиляторов и сетевого ПО.
Почему именно такое смешение? Если пишется под создание компиляторов, то, наверное, должны быть одни языковые средства, а если под создание сетевого ПО, то — другие средства.
И, вообще, раньше языки появлялись при решении конкретных задач. Было бы здорово однажды увидеть: мы взяли такую-то задачу, помучились при её решении, используя традиционные средства, и предложили новый подход, который преодолевает недостатки предыдущих решений.
Source
05.07.2022 00:03+1Конечно, хотелось бы узнать, как мог бы выглядеть язык программирования ++C. Или C--. Или --C...
Вот вы, наверно, пошутить хотели. А был такой язык C--, потом он в Haskell уехал.
Начать новый язык следовало бы с концепции. Или прямиком с основной идеи.
А это точно подмечено. Из статьи так и непонятно в чём основные фишки Hare, ради которых его задумали.
slonoten
05.07.2022 10:57+3Я помню другой C--, компилятор под MS-DOS который собирал на удивление компактные исполняемые модули, не exe, а com. Скомпилированный резидентный драйвер клавиатуры написанный на C-- весил меньше 256 байт. Давно это было. До 1997 года.
NN1
05.07.2022 00:35+20Сперва убийцей был назван D.
Версия продержалась недолго и назван был D2.
Потом подозрения пали на Haxe.
Следующим кандидатом стал Nim.
У Go было алиби и его исключили из подозрения.
Наконец большинство начало склонятся в сторону Rust.
С появлением Zig мнения разделились.
Казалось бы зачем нужен убийца убийцы, но Hare уже не остановить.
nmrulin
05.07.2022 01:04+16В итоге все "убийцы Си" в итоге проигрывают на tiobe "мёртвому" Delphi :-)
Aquahawk
05.07.2022 08:36+3Haxe? Подозрения могли возникнуть разве что у смузи программистов по отзывам из твиттера. Достаточно написать 100 строк кода на этом языке и скомпилировать под разные платформы, чтобы понять что этот язык вообще один маркетинговый буллшит.
AnthonyMikh
06.07.2022 00:28А что не так с Haxe?
yokotoka
07.07.2022 00:14Примерно всё.
Хорошая задумка — транслировать код и алгоритмы, написанный один раз на десяток других языков, но просто адски кошмарная реализация. Чтения результатов этой трансляции хватило, чтобы понять что не взлетело и уже не взлетит. В python, например, эта штука транслируется в кошмарно качества код с глобальными переменным (!). PHP и Java-бекенды аналогично.
Нормального интеропа по этой причине не будет, а стандартной библиотеки не хватает, хотя бы через фасады и адаптеры. Придется писать нужные библиотеки самому, то есть значит что не придется — возьмут другой язык.
Очень куцые возможности самого программирования из-за помешательства на одной-единственной парадигме — ООП через классы выдержки Java 5 и ActionScript, которым, по сути, Haxe и является. Очень не вкусно. И ладно бы только это — так эта единственная парадигма не помогла наверстать упущенное в том, что я перечислил выше. Ощущение от программирования, будто на дворе 1999-й, и ты сейчас своим Haxe накажешь соперников с Java 1 и Delphi.
Комьюнити маленькое и заточено на написание игрушек. Всё. Собственно, всё развитие языка и экосистемы крутится вокруг пары фреймворков для геймдева.
Очень пытался его полюбить и надеялся, что с его помощью уж напишу один раз либу по музыкальной теории под всё языки. Не вышло. То что получалось на выходе невозможно было использовать. Пришлось писать нативно несколько раз под каждый язык. В моём случае это были Python и JS.
funny_falcon
07.07.2022 09:48+1Haxe вроде убийцей С ни когда не был. Он точно целился (успешно) в ActionScript. Но тут назло тот сдох сам по себе.
Я общался раз с игроделом, который хвалил Haxe: типа, на клиенте в один язык компилится (наверное, как раз ActionScript), а на сервере - в C#.
Tanner
05.07.2022 01:14+2В общем, в качестве замены Си подойдёт любой относительно новый новый язык без стандарта и с неопределённым поведением.
dayllenger
05.07.2022 02:30+3Самый унылый язык из всех "альтернатив C или C++". Из новшеств только какая-то синтаксическая чепуха про массивы.
SergeiMinaev
05.07.2022 07:33В кач-ве альтернативы Си нравится Zig. Он достаточно компактный, разработчики не пытаются впихнуть в него всё подряд, но, при этом, он имеет всё необходимое для современной разработки. И над скоростью компиляции автор заморачивается - https://vimeo.com/491488902
Vlad2001MFS
05.07.2022 07:51+7Ну, прикольно, интересно. Правда, зачем нужен Hare, если уже есть Rust?
slonoten
05.07.2022 11:06Честно пытался освоить Rust, прочитал rust-book, выполнил все задания, потом наткнулся на статью как читать rust-book в правильном порядке, прочитал еще раз в правильном порядке. Потом отвлекся на месяц и все забыл ((( Основной язык сейчас python, много писал на C++, С#... Знакомился с java, kotlin, f#. Хочется иметь в своем арсенале компилируемый язык со статической типизацией, чтобы оптимизировать те 5% кода, которые выполняются 95% времени.
SergeiMinaev
05.07.2022 12:27Rust - замена не Си, а, скорее, С++. Для Си Rust слишком сложный.
fk0
05.07.2022 12:45-8Rust и близко к C++ не стоял. Многие свойства C++ в Rust просто не реализуемы. Казалось бы очевидный факт и спорить бессмысленно. Начиная с автоматического преобразования типов.
Вообще для меня все языки разделяются на "нежизнеспособные" по типу Паскаля, где средствами самого языка невозможно реализовать функцию "WriteLine", и "жизнеспособные" вроде C/C++, где printf/std::cout реализованы средствами самого языка, а не компиляторной магией.
Так вот в Rust -- компиляторная магия. Они говорят, мол у них макросы, на которых можно сделать что угодно. Но зарывшись в дебри поглубже видишь там "/* compiler builtin*/". Из чего понимаешь, что сам так -- не сделаешь.
К слову в C/C++ компиляторная магия в единичных местах. В голом C наверное и не скажешь где, не знаю. В C++ очевидными местами являются std::array и std::initializer_list (невозможно сделать собственные такие классы с другими именами). Есть какое-то третье место, но я не помню. Но это отнюдь не функция уровня printf, а какой-то очень базовый примитив.Gordon01
05.07.2022 13:28+5Начиная с автоматического преобразования типов.
Еще goto нормального нет!
Вообще для меня все языки разделяются на "нежизнеспособные" по типу Паскаля, где средствами самого языка невозможно реализовать функцию "WriteLine", и "жизнеспособные" вроде C/C++, где printf/std::cout реализованы средствами самого языка, а не компиляторной магией.
Так вот в Rust -- компиляторная магия.
https://os.phil-opp.com/vga-text-mode/
Они говорят, мол у них макросы, на которых можно сделать что угодно. Но зарывшись в дебри поглубже видишь там "/* compiler builtin*/". Из чего понимаешь, что сам так -- не сделаешь.
https://github.com/rust-lang/rust/blob/master/library/std/src/io/stdio.rs#L995
Макросы нужны для того, чтобы можно было print отдавать любое количество аргументов и делать другие полезные штуки, вроде именованных аргументов.
NN1
05.07.2022 13:29+2А какая магия в std::array? Там простой класс с массивом внутри.
Может имелось ввиду std::type_info ?
Компиляторной магии в основном можно найти в type_traits и там это вполне обосновано.
alexeibs
05.07.2022 23:33На самом деле и в type_traits значительная часть (а может и все - не проверял) шаблонов реализованы средствами языка
NN1
06.07.2022 00:05alexeibs
06.07.2022 00:31Например?
Нашел в доках LLVM: https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives
Хотя вот "чувство языка" подсказывает, что еще до С++ 11 часть этих проверок реализовывали разными языковыми хаками. Какой-нибудь __is_same к примеру0xd34df00d
06.07.2022 03:05+1is_sameкак раз очень легко реализовать руками, это вообще одно из базовых упражнений на шаблонное метапрограммирование.Другое дело, что реализация руками несёт оверхед, который компиляторный интринсик может избежать. Например, его совершенно не обязательно держать в кеше инстанциаций компилятора.
Реализовать нельзя (ну или, скажем так, мне такие способы неизвестны) всякие
std::is_union/std::is_standard_layout/std::is_trivially_constructible.
DirectoriX
05.07.2022 14:11+6Многие свойства C++ в Rust просто не реализуемы
Например, самоломающийся (пре переносе между платформами) код, если в описании структур использовать обычные типы вместо тех, что с фиксированной размерностью.
На днях у нас так сломался минипарсер WAV-заголовков — всё время запускали под Windows, а потом понадобилось под Linux погонять. Долго искали, что же там могло отвалиться, а это оказался unsigned long, который в Windows 4 байта, а в Linux — 8.
Зато C/C++ переносимый, а самое главное — стандартизованный да.Gordon01
05.07.2022 14:23+4Справедливости ради, в Си типы вроде int32_t называют переносимыми, и наоборот всякие unsigned long — непереносимыми.
DirectoriX
05.07.2022 17:08+2Это правда, но stdint.h появился только в С99, а некоторые проекты всё ещё сидят на C90, а многие библиотеки объявляют свои переносимые типы, например opus.
Ну и int32_t всё же вторичный для C тип, потому что он объявлен как typedef над int, а не наоборот.
DarkEld3r
05.07.2022 17:12Так вот в Rust — компиляторная магия. Они говорят, мол у них макросы, на которых можно сделать что угодно. Но зарывшись в дебри поглубже видишь там "/ compiler builtin/". Из чего понимаешь, что сам так — не сделаешь.
Если говорить конкретно о
println!, то в виде "compiler builtin" оно реализовано потому, что к версии 1.0 макросы ещё не были стабилизированы. Сейчас аналог можно написать самому.
alexeibs
05.07.2022 23:38А что плохого в компиляторной магии? На худой конец есть кодогенерация - там любой каприз за ваши
деньгивремя. Сборочные скрипты все равно на других языках пишутся
includedlibrary
05.07.2022 13:24+6Мне кажется, что rust проще, чем си. Как минимум не нужно думать про управление памятью, а про разыменовывание указателей думать надо только в unsafe блоках. Плюс отсутствие UB. После rust писать на си уже не очень хочется, единственная его проблема - раздутый рантайм, но она существенна только для неприкладного кода. Кресты для меня - это вообще страшный сон, о котором не хочется вспоминать.
Viknet
05.07.2022 13:39+1Про какой рантайм идёт речь? Про опциональную раскрутку стека?
includedlibrary
05.07.2022 14:26+2Я не особо подробно вдавался в вопрос, но когда последний раз писал на расте приложение под UEFI, у меня возникла проблема с
core::fmt. Из-за него бинарник выходил достаточно жирным, поэтому пришлось от него отказаться и использовать для вывода встроенные в UEFI функции. Надо будет попробовать использовать ufmt. Есть ещё целый репозиторий, посвящённый уменьшению бинарников на расте.
Pastoral
05.07.2022 07:52Пример меня огорчил.
Разве то, что в данном приложении функция выбрана точкой входа, является свойством функции? Ладно, думать сейчас не те времена чтобы. Но одновременно export, предполагающий использование функции где-то там далеко, и фиксированное имя для точки входа - это режет глаз.
Разве любая коллекция не должна уметь выполнять функцию для каждого своего элемента?
Может и взлетит, и тогда это будет, как писала Сэй Сёнагон, очень печально.
vaniacer
05.07.2022 09:21+3Название нового ЯП говорит само за себя. Хватит уже плодить новые ЯП, научитесь использовать существующие.
panzerfaust
05.07.2022 10:22+2Просто это уже стало самовыражением. Вы же не можете запретить художнику писать пейзаж Елисейских полей только потому, что таких картин уже тысячи. При этом покупать его картины вы тоже не обязаны.
vaniacer
05.07.2022 10:34-1Не совсем корректный пример. ЯП - это инструмент програмиста, продуктом же является код, программа. Картина(не зависимо от сюжета) - это продукт, инструментом же являются руки, кисти и краски, карандаши, мелки, палец обмокнутый в ... Но хороший художник и пальцем обмокнутым в ... нарисует такой пейзаж Елисейских полей что закачаешься.
ИМХО дело не в кисточке а в том кто её держит. Верно и для ЯПов. Можно бесконечно искать(изобретать) чудесный ЯП а можно просто еbashit'ь такие штуки как piu-piu )
JordanCpp
Реакция на язык X, который пророчат на замену си.
Red_Nose
Ну в свое время Паскаль был более востребованным и быстрым. Да и сейчас вполне даст просраться всяким Питонам :)
Но времена Борландов прошли :((
Этот - не взлетит. Т.к. " Это — системный язык программирования, заточенный под написание компиляторов и сетевого ПО." Т.е. охват - минимальный
0xd34df00d
Для компиляторов не нужно, можно закапывать.
includedlibrary
Я вот тоже хотел об этом написать. Больно представлять, как люди пишут компиляторы, на языках с ручным управлением памятью и без ADT. Смысла особого в этом нет, а боли добавляет. Да и сетевое ПО можно отлично писать на том же Rust, если хочется язык без GC
greenkey
Борланд не только паскалем занимался, но этот язык там всегда занимал особое место.
in_heb
pascal по каким-то причинам (говорят что из-за := вместо =) завоевал уважение в академической среде, его использовали для обучения, а потом студенты-выпускники несли в индустрию
кстати, будут пруфы что borland pascal был "быстрее" borland c и что это вообще значит? скомпилированный код похожих программ работал быстрее? (да скорее всего, у этих компиляторов вообще внутри было почти всё общее и тупо разные фронтенды)
kubrack
В данном контексте значит что компилировался сильно быстрее. Это заслуга не реализации борландовских компиляторов, а паскаля, для которого возможен однопроходный компилятор.
Код похожих программ работал сильно зависимо от ключей сборки и особенностей алгоритма, как и везде.
WASD1
Я думаю, что это всё-таки заслуга template и include *.hpp из С++.
И более продвинутого подхода с interface \ implementation из Pascal, который позволял не делать кучу работы.
ПС
Так-то парсер для Pascal попроще парсера C - но сам парсинг близко к о-малому в оптимизирующем компиляторе таких ЯП.
funny_falcon
Вообще-то C принципиально однопроходный. Например, tcc (Tiny C Compiler) реализован как однопроходный, и поддерживает весь стандартный С и много GCC расширений.
Проблема C в инклудах и макросах: каждый файл приходится компилить заново вычитывая и парься все include, т.к. их содержимое может в буквальном смысле меняться от определённых макросов.
Правда, tcc все равно делает это чертовски быстро. Но почти не оптимизирует код.
mad_nazgul
Нет. Это были разные компиляторы.
Выходцы из Borland создали компанию, которая под маркой TopSpeed как раз такую идею и хотели сделать. Один бакенд, и куча фронтендов.
А почему Borland Pascal не стал "промышленным стандартом".
Так всё просто. Библиотеки (.tpu) были не совместимы между версиями, даже минорными. Например библиотеки от Turbo Pascal 5 нельзя было использовать в Turbo Pascal 5.5. Это затрудняло распространение коммерческих библиотек. Грубо говоря нужно было поддерживать несколько вариантов .tpu под разные компиляторы.
А распространять библиотеки в исходных кодах тогда было ещё не модно.
Так что для коммерческой разработки Turbo Pascal не очень хорошо подходил.
vkomen
Мне кажется, Паскаль не особо подходил для реализации больших проектов. Или эти возможности были ему сильно "сбоку" добавлены. Так как исходная идея - это объемлющая процедура Program с бесконечной вложенностью подпроцедур, в С все же подход более "горизонтальный"
ABHuman
Тогда же завозили ООП в Delphi, было очень модным, а с 95-го и вовсе Oak(Java) подлетел с ещё более новой фишечкой многоплатформенности, подсадив на себя банковские структуры. И теперь эту джаву оттуда не выбить никак с таким багажом Легаси, но работающим относительно надёжно. Это и понятно, в таком бизнесе ради нового функционала никто рисковать не будет. Что-то менять там можно только через "деньги". Имеется в виду, когда выгода будет доказана и являтся ощутимой.
SpiderEkb
Не поверите, но знаю несколько банков из Топ-10 где джаву и близко не подпускают к mission-critical части - ядру АБС (а это самая критичная по скорости и устойчивости часть банка, где времена простоя/недоступности исчисляются минутами, жестко регламентированы регулятором и строго мониторятся).
И делается это не из нелюбви к джаве, а от того, что она проигрывает в эффективности (как по скорости, так и по потреблению ресурсов) специализированным языкам для коммерческих расчетов Тем, где нативно поддерживаются типы с фиксированной точкой (в том числе арифметика с ними типа "присвоение с округлением"), работа с датами во всевозможных форматах (например, одной строкой преобразовать число, представляющее дату в формате *CYMD в строку, представляющую дату в формате *ISO или *EUR). Где нет дикого динамического выделения-освобождения памяти на каждый чих. Где есть втреоненные средства работы с БД без SQL (и плюс к тому есть возможность встраивать SQL выражения непосредственно в код).
И все это появилось и развивалось с тех пор, когда создатели джавы были блеском в глазах из родителей.
ABHuman
Исключения известны и как бы даже логичны, никто и не говорил, что джава - лучший язык. При этом я как раз согласен и с замечаниями по скорости, и с потреблением, но оно и понятно, кроссплатформенность и поднятие JVM как бы изначально намекают на некую унификацию, которая неоптимальна в узких местах.
Но широта применения для всех остальных огромна и это не похоронить ни в ближашие 5 лет, ни в течении 10 лет.
Эффект джавы как раз в том, что сложнее и не надо, сели гребцы после полугодовых курсов и гребут джунами и мидлами без особой оптимизации памяти, без указателей и без желания копать "в железо". Вайтишникам другого и не надо, а бизнес ещё и на старом поживёт.
Миллионы леммингов не пересядут на "заточенное под написание компиляторов и сетевого ПО".
П.С. вы посмотрите ютуберские курсы, что не курс, то - "не надо "высшку" получать, я вас научу на практике как надо программировать". Фундаментальные знания не в приоритете, а без них редко кто влетает в "нелюбовь к джаве". И это очень печально!
SpiderEkb
Я полностью согласен. Прежде всего с тем, что для узкоспецифических задач (а коммерческие расчеты так или иначе имеют свою специфику) столь универсальное средство как Java не очень пригодно. Тем более, что есть специальные инструменты, оптимизированные именно под это класс задач. И тут уже нужна некоторая широта взглядов и умение использовать разные инструменты под разные задачи. У нас, к примеру (платформа IBM i), постоянно используется как минимум три языка - CL там, где требуется много манипуляций с системными объектами, RPG для реализации бизнеслогики и С/С++ для реализации низкоуровневых функций. Благо, на платформе есть "концепция ILE - Integrated Language Environment", позволяющая собирать модули на разных языках в один программный объект (например, из кода на RPG вызывать функции, написанные на С/С++, реализующие какие-то низкоуровневые операции). И это удобно и эффективно.
И опять же согласен, что найти хорошего разработчика под такие инструменты сложнее - "вайтишники" считают что "это не даст мне релевантного экспириенса и оно мне не надо". Ну действительно, для человека, основной целью которого является прыгать с проекта на проект с основной целью чтобы на следующем месте работы платили хоть чуть больше (при тех же, а лучше меньших, трудозатратах) чем на предыдущем, все это неинтересно - развиваться в рамках одной тематики временами бывает скучно.
И снова согласен, что такие вещи как С, Java уже настолько "набрали обороты" что похоронить их не получится. Да и не надо - они доказали свою применимость для решения широкого круга задач.
mad_nazgul
Вообще то ООП в Borland'овских Pascal был начиная с Turbo Pascal 5.5 ещё под DOS.
Насчёт легаси и java это было правда лет 5 назад. Сейчас я в основном вижу вакансии в стильномолодежных проектах с CI/CD и микросеврисами.
Ну и старые легаси-монолиты переводят на микросервисы.
ABHuman
Возможно, но вы смотрите только регионально. Мы же говорим о взлёте языка, а там на мировых "затворках" пока поиск джавистов живее всех живых. Легаси ещё на Делфи существует, но вайтишники уже не пополняют ряды, поэтому и дефицит на программеров тут никуда не делся.
Мне не совсем понятно почему вы решили микросервисы ставить против Джавы, да и в общем, разговор не только про неё, мне так C# более по душе. И волна перехода на микросервисы уже не так сильно набирает обороты, не всё так радужно оказалось с ними. Но где тут затесаться новому ЯП-у?
Касаемо ООП в ТП, то Делфи бы не взлетел, если так прекрасно было бы с ООП у Паскакаля. Да, какие-то фичи были реализованы, но не полностью вся концепция, да и на 7.0-версии ничего толком не поменялось, после которой "ждун" скончался. Это я вам из личного опыта озвучиваю, а не по рассказам. Я прекрасно помню DOS, тогда "окна" были лишь графической оболочкой до 95-й версии. Но тогда пользователи были другого покроя и каждый второй лично редактировал config.sys и autoexec.bat, чтобы память освободить. Сейчас тренда изучения языков программирования низкого уровня я не вижу. За счёт чего должны слететь монстры высокого уровня - непонятно.
Siemargl
А он есть. Даже Ассемблер в десятке Тиобе
ABHuman
Нет такого одного единственного Ассемблера. Изучение было и раньше, но тренд где?
Ну и Тиобе, такое себе... может на SO посмотреть или на PyPL?