LINUX.ORG.RU

beef - новый системный ЯП

 , ,


1

8

https://www.beeflang.org/

Особенности:

  • По заявлению автора, представляет собой смесь C++ и C#, с небольшими вкраплениями Rust.
  • Без GC, JIT и тому подобного.
  • Развивается параллельно с IDE (написана на самом beef и собственном тулките). Дизайн языка развивается с учётом удобства разработки IDE.
  • Автор делает упор на удобную отладку с помощью дебаггера, а не print.
  • Умеет все модные фичи: ADT, pattern matching, лямбды, дженерики, миксины, кортежи, опциональные типы и тд. Но не гарантирует null-safety.
  • Поддерживает рантайм рефлексию.
  • Не использует исключения. Используется тот же подход что и в Rust: Result + panic.
  • Проверяет проблемы с памятью в рантайме в отладочной сборке. В релизной сборке всё как в C/C++.
  • Предоставляет лёгкое взаимодействие с C/C++ кодом (не уверен в каком виде).
  • Основан на ворованном LLVM. Как будто кто-то сомневался.
  • Автор пилит язык последние 5 лет full-time.

Простой пример:

static Result<uint> GetMinusOne(uint i)
{
    if (i == 0)
        return .Err;
    return .Ok(i - 1);  
}

void Use()
{
    /* Handle result via a switch */
    switch (GetMinusOne(i))
    {
        case .Ok(let newVal): Console.WriteLine("Val: {}", newVal);
        case .Err: Console.WriteLine("Failed");
    }

    /* This invokes an implicit conversion operator, which will be fatal at runtime if an error is returned */
    int newVal = GetMinusOne(i);

    /* Result<T> contains a special "ReturnValueDiscarded" method which is invoked to facilitate failing fatally on ignored returned errors here */
    GetMinusOne(i);
}

В целом ближе к D, чем к Rust, так как содержит намного меньше гарантий.

★★★★★

Последнее исправление: RazrFalcon (всего исправлений: 3)
Ответ на: комментарий от Legioner

Язык моей мечты вообще должен позволять пробелы в идентификаторах.


inductive «Физическое лицо»
| mk : nat → list «Физическое лицо» → «Физическое лицо»
-- в этот божественный прувер float завезут только в четвёртой версии,
-- поэтому nat

meta def «Сумма пенсионных накоплений» : «Физическое лицо» → nat
| («Физическое лицо».mk «пенсионные накопления» «родственники») :=
  «пенсионные накопления» +
  list.foldl (+) 0 («Сумма пенсионных накоплений» <$> «родственники»)

https://leanprover.github.io/

anonymous
()
Ответ на: комментарий от anonymous

Ну или бомжественный. А Microsoft Research вообще много всего интересного делает, это не та орда индусов.

anonymous
()
Ответ на: комментарий от Deleted

Вот мы и пришли к тому, что городить огород со статическими типами в самом ЯП не нужно, если для вменяемого описания контрактов данных всё равно используются внешние инструменты.

Щас всем пох на то, прилетит из функции a в функцию b инт или флоат. Главное, чтобы в REST-запросе на функцию a данные прилетели в нужном формате. И если уж реализовывать проверки типов так, как они должны быть, то средства вроде вышеуказанного по ссылке должны быть частью стандарта языка.

anonymous
()
Ответ на: комментарий от RazrFalcon

Объясни тогда появление ошибок такого типа:

https://github.com/RazrFalcon/resvg/issues/196

https://github.com/RazrFalcon/resvg/issues/124

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

grem ★★★★★
()
Ответ на: комментарий от RazrFalcon

То есть ты заявляешь, что компилятор всё отловит и при этом пытаешься отшутиться по поводу ошибок в реализации? Ок.

Но куда смотрел компилятор?

grem ★★★★★
()
Ответ на: комментарий от RazrFalcon

Хочешь стабильности - пиши тесты.

Зачем? Пусть за меня это делает компилятор.

Так он же должен был отловить то, что должны были отловить тесты? Не?

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

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

grem ★★★★★
()
Ответ на: комментарий от anonymous

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

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

если для их использования не приходится писать какое-нибудь DirectoryCreatorInterfaceFactory и оборачивать всё в классы.

Бич той же жабы — туча бойлерплейта, не несущая никакой полезной нагрузки. Вот к чему у меня претензии.

Ну это бич не жабы, а стандартной библиотеки. И желания сделать её как можно более гибкой. Например в стандартной библиотеке идёт не XML-парсер, а интерфейсы для XML-парсера. Ну и какая-нибудь дефолтная реализация. При этом пользователь при желании может не меняя кода подставить другую реализацию. Понятно, что при этом нельзя просто написать new, нужны те самые Factory. Или взять Path. Штука абстрактная и универсальная. И это не просто слова, я могу легко написать код, который универсально работает и с файловой системой и с ZIP-архивом. Это удобно и полезно. Опять же понятно, что при этом нельзя просто написать new Path, неизбежно вытекает необходимость объекта-файловой системы, которая будет уметь работать со своими Path.

Где-то они перегнули палку. С тем же XML я не согласен, что там нужны эти Factory. Просто взять одну библиотеку и сделать её хорошо. Но смысл понятен. Да и не так всё страшно. Ну да, парсинг XML будет не в одну строчку, а в 4. Если это такая проблема - возьми да напиши утилитный метод и будет опять в одну строчку. Я раньше так и делал, потом, правда, решил, что в бойлерплейте, как таковом, ничего такого уж страшного нет в общем случае. А в отдельных случаях надо смотреть.

Да и, опять же, т.к. это всё в библиотеках, чаще всего есть альтернативы, порой более удобные.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

В модерн плюсах ничего не стоят, если их не кинуть

Это от реализации зависит, вход/выход в/из try{} вполне может иметь накладные расходы

anonymous
()

Без GC, JIT и тому подобного.
Развивается параллельно с IDE (написана на самом beef и собственном тулките)
Автор делает упор на удобную отладку с помощью дебаггера, а не print
Автор пилит язык последние 5 лет full-time.
static Result<uint> GetMinusOne(uint i)
...
int newVal = GetMinusOne(i);

Автор_языка_дебил-тред.

Если серьезно, то человек за 5 лет так и не понял, зачем нужны трассирующие оптимизаторы-компиляторы, почему мощная IDE - признак наличия недостатков языка, почему запись типов в стиле Си - это ошибка, которая упорно из десятилетия в десятилетие бездумно повторяется, и так далее. При чем тут LOR?

byko3y ★★★★
()
Ответ на: комментарий от Legioner

Язык моей мечты вообще должен позволять пробелы в идентификаторах. Вот бы я развернулся.

Тебя самого же быстро утомят эти пенсионные накопления. Сам не заметишь как оно мутирует в пенснак, а потом может и вовсе в пн. Меня вот уже в таком коротком примере они напрягают. Читается как бюрократическое арго.

bread
()
Ответ на: комментарий от byko3y

мощная IDE - признак наличия недостатков языка

Бред, на самом деле. Смотря как IDE использовать, конечно, но из личного опыта редактор+поисковик по коду вещь незаменимая. Не зная, о чём думают люди, утверждающие о положительной корреляции нужности IDE и недостатков языка

anonymous
()
Ответ на: комментарий от anonymous

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

bread
()
Ответ на: комментарий от anonymous

Главное, чтобы в REST-запросе

Только из-за широкого распространения строгой типизации, иначе было бы «Главное REST-запрос сформировать»

anonymous
()
Ответ на: комментарий от byko3y

Неверно.

Среда разработки включает в себя: текстовый редактор, компилятор и/или интерпретатор, средства автоматизации сборки, отладчик.

Есть ли IDE, включающие в себя компилятор и сборочную?

anonymous
()
Ответ на: комментарий от bread

Можно сколько угодно бросаться в пуризмы(чистые концепции то бишь), только они никогда не работают на практике

anonymous
()
Ответ на: комментарий от anonymous

Есть ли IDE, включающие в себя компилятор и сборочную?

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

byko3y ★★★★
()
Ответ на: комментарий от eagleivg

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

anonymous
()
Ответ на: комментарий от anonymous

в каких условиях людям порой приходится писать и — самое главное — читать код?

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

foror ★★★★★
()
Ответ на: комментарий от foror

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

anonymous
()
Ответ на: комментарий от RazrFalcon

Но дальше то уже об ошибках реализации речь шла, где было брошено странное «На ЯП можно писать не только код, который складывает числа.» И всё это уже в контексте обсуждения логических ошибок и ошибок реализации.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от bonta

если ты бы знал, то не нёс бы тут хрень. Вот ты возьми и почитай вики или погугли.

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

foror ★★★★★
()
Ответ на: комментарий от anonymous

Приведи несколько примеров IDE для C++ с встроенными компилятором и сборочной

Visual Studio имеет собственные инструменты сборки и компилирует проект для целей разработки отдельно от сборки для запуска/отладки. Qt тоже собственные механизмы сборки разработали. CLion использует механизм:
https://sarcasm.github.io/notes/dev/compilation-database.html

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Нормальными языками можно прямо в мозге оперировать(целыми проектами)

Согласен, признаю свою промашку, уступаю вам место потролить местных анонов.

foror ★★★★★
()
Ответ на: комментарий от Legioner

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

За свои 15 лет кодинга пришел к выводу, что нам лгали. На самом деле это не удобно и не полезно.

foror ★★★★★
()
Ответ на: комментарий от RazrFalcon

А есть альтернативы? Или ловить произвольные исключения или пердолиться с кодами возврата как в 70-х

Дети мои, всё просто и придумано примерно 25-35 лет назад. Называется «вывод типов». Объявления выглядят вот так:

fn call1() -> {...}
fn call2() -> { call1()?; ...}
fn call3() -> { call2()?; ...}
fn call4() -> { call3()?; ...}

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Visual Studio

Компилятором c++ я бы это не назвал. Но да ладно, один есть

Qt тоже собственные механизмы сборки разработали

Всё так. Только Qt это не IDE

CLion использует механизм:

A compilation database is a database for compile options. It records which compile options are used to build the files in a project

Если я правильно понял из brief-а, сборочная в CLion есть. Но где остальное(я же не просто так спросил про компиляторы c++ в IDE)?

anonymous
()
Ответ на: комментарий от RazrFalcon

Unicode один для всех.

Вы ведь в курсе, что под Unicode подразумевают целую пачку различных стандартов на кодирование текста? UTF-8/UTF-32/UTF-16 - что из этого одно и для всех?

trex6 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Единственные нормальные строки для плюсов - это QString

Ну это уже слишком толсто. Особенно если плюсы для всякой встройки использовать.

trex6 ★★★★★
()
Ответ на: комментарий от anonymous

с какого перепою ты MainErr енумом сделал, если это совершенно другая оишбка?

Какое отношение это имеет к способу обернуть ошибки библиотек в ошибку более высокого уровня абстракции?

trex6 ★★★★★
()
Ответ на: комментарий от grem

Да, тоже зачёт

Оно ещё не сдохло даже:

Последняя версия 10.3.3 Rio (01.11.2019)

anonymous
()
Ответ на: комментарий от anonymous

что 95% населения — идиоты

Каникулы вроде закончились уже?

F457 ★★★★
()
Ответ на: комментарий от Legioner

Единственная проблема с исключениями это то, что оно может вылететь почти в любой строчке и поломать состояние. Но на практике в той же Java для меня это никогда не было существенной проблемой

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

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

В 32-битной x86 try-except-finally требовало записи в Thread Information Block, что дешево, но не бесплатно. В x64 сделали отдельные записи, которые читаются только при исключениях и не добавляют никаких команд в функцию при нормальном исполнении:
https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64?view=vs-2019
Из-за того, что никаких фреймов явно не формируется во время выполнения x64, при исключении обработка становится весьма дорогой - дороже чем на 32 битах.

byko3y ★★★★
()
Ответ на: комментарий от Legioner

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

Нет, я хочу видеть инструменты, сделанные для профессионала, а не для макаки. IDE под мейнстримные ЯП — это попытка впарить второе под видом первого.

Ну это бич не жабы, а стандартной библиотеки.

Нет, это бич в первую очередь именно самой жабы. В которой даже хей-лох-ворлд не напишешь без объявления класса и дичи вроде public static void main. Сам язык поощряет бессмысленное многословие и даже в самых простых примерах к оному принуждает, что, естественно, сразу повышает ценность IDE.

И в то же время всю жабовскую стандартную библиотеку можно использовать, например, из Groovy, в котором одной-единственной строчки println "Hello World" более чем достаточно для выполнения той же задачи, не плодя никаких лишних сущностей. Feel the difference, как говорится.

P.S. Это я о языках поверх JRE говорю. А ведь есть куда более мощные вещи, где проблемы с бойлерплейтом вообще не появляются.

anonymous
()
Ответ на: комментарий от anonymous

Всё так. Только Qt это не IDE

Qbs сделали для Qt Creator-а.

Если я правильно понял из brief-а, сборочная в CLion есть. Но где остальное(я же не просто так спросил про компиляторы c++ в IDE)?

Да систем сборок огромное множество наплодилось, и все - говно, например, потому что C++ невозможно в общем случае распарсить на машине тьюринга, и попробуй только заинклудь заголовки не в том порядке. Такой вот язык прикольный. В итоге они со своего колхозного парсера переходят на clangd, который по сути представляет огрызок компилятора, сделанный таковым для повышения шанса на успешный парсинг.
CLion имеет родную поддержку CMake, Gradle, Bazel, но для того, чтобы эффективно распарсить файлы проекта из другой системы сборки, ему нужен универсальный инструмент - потому сделали БД компиляции.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от byko3y

Qbs сделали для Qt Creator-а

Только вот creator в итоге на cmake перешёл. Но да ладно, считаем сборка есть

В итоге они со своего колхозного парсера переходят на clangd

Парсеры во многих IDE для подсветки синтаксиса. Да, ошибки они тоже показывают, только на компилятор это никак не тянет

Итого из комбайнов только msvc и borland. Все(наверное) остальные под критерии с википедии не подходят(в том числе qtcreator). Напоследок, для протокола(с той же википедии):

Qt Creator — кроссплатформенная свободная IDE

Лол

anonymous
()
Ответ на: комментарий от crutch_master

Да, искали недавно utf строки для плюсов, так ничего путного и не нашли. Хотя казалось бы, зоопарк, и т.д

UTF-8 строки во внутреннем представлении не нужны, ибо неудобны. UTF-16/UTF-32 строки в плюсах есть, насколько мне известно.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Сам язык поощряет бессмысленное многословие и даже в самых простых примерах к оному принуждает, что, естественно, сразу повышает ценность IDE

Поясни, каким образом многословность повышает ценность IDE

anonymous
()
Ответ на: комментарий от byko3y

UTF-16/UTF-32 строки в плюсах есть, насколько мне известно.

Нет(utf16, можно сказать, были). Ну и преимуществ перед utf8 совсем никаких

anonymous
()
Ответ на: комментарий от anonymous

Парсеры во многих IDE для подсветки синтаксиса

В случае C++ это уже не парсер, а компилятор, который выполняет функцию парсера. А в идее это еще и велосипедный компилятор с функцией парсера.

Итого из комбайнов только msvc и borland

Идея ещё как минимум.

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.