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

Ну лучше IDE пока ничего не придумали.

Использование мета данных.
Они и сейчас используются в виде xml, json, …, но речь скорее о метадата базе в которой …

К примеру подход к использованию мета данных в 1С.

Владимир

anonymous
()

Если благодаря этому меньше будут писать на цепепе, то уже хорошо :-) Лол :-)

anonymous
()

Краткое изложение треда:

- Эпичная реклама исключений, заканчивающаяся перечислением их косяков

- Измерение (не)адекватности разраба через его способность пердолиться на busybox+vi

- Лучшие практики из мира разработки на 1С

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

Сам результат возвращается отдельно. Result возвращает пару.

Не большое дело, особенно, когда в Result<> суют тоже самое число без другой инфы

Код возврата можно пропустить и обратится к неверным данным. С Result (в расте) - нельзя.

Но это варнинг. Я тут недавно прожект один с гитхаба собирал, там варнингов на 100500 экранов было. Ах ну да .. «это кривой код!!», «так никто не пишет!!!» и другие сказки Шахерастазады.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f3f37f00689b84bd6570301c953811bc

ЧТД. Тоже самое пердоление, да еще и некорректное. с какого перепою ты MainErr енумом сделал, если это совершенно другая оишбка? Да и реализацию From<> ты упохаешься писать для всех возможных ошибок всех возможных кретов,которые ты натянул в свой прожект.

В общем молодец, доказал то, что и так понятно было.

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

Если благодаря этому меньше будут писать на цепепе

Что значит «если»? Плюсовики уже почти все перешли на сабж, кроме пары олдфагов с C++2a.

anonymous
()

так выпьем же за …, который убьет биф, который убьет раст, который убьет кресты, которые убьют цэ!

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

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

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

Если благодаря этому меньше будут писать на цепепе, то уже хорошо

Не будут. Языком beef будет пользоваться только его автор. Но, заглянув в исходный код проекта beef, я увидел то, что и ожидал: он разрабатывается на C++.

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

В нормальных языках - нормальные строки. Переизобретать там нечего. Unicode один для всех.

String, &str, OsStr, OsString и потом обмазываешься to_string_lossy() как плебс и вот это все. И потом еще Path/PathBuf, который тебе все засирает этими OsStr/OsString. Короче сделали как могли, но строки сами по себе не простая штука, из-за портабельности, архитектур и ОС

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

А что вы ожидали там увидеть? LLVM же на плюсах. Вот и получаем. Это изменится только когда автор перепишет компилятор на сам beef.

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

OsString нужен только для работы с системными путями. В типичном коде их нет.

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

Как в С++ мусорка строк, так в Rust - мусорка фреймворков для ошибок. failure, snafu, error-chain, thiserror, anyhow и все с разным уровнем совместимости с друг другом

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

Но это варнинг.

И его можно пропустить. Пропустить Result нельзя.

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

Учим основы Rust.

для всех возможных ошибок всех возможных кретов

А это и не нужно. man модульность.

В общем молодец, доказал то, что и так понятно было.

По вам не видно. Типичный пример «ну я же пишу нормальный код, так что всё ок».

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

Они не в std и они абсолютно опциональны. В отличии от строк.

все с разным уровнем совместимости с друг другом

Почти все реализуют трейт Error, а большего и не надо.

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

Молодой человек, у вас исключение заполыхало

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

Но совсем другая ситуация с serde - он божественнен и намного меньше причин делать его альтернативы. Только если схема language agnostic - Thrift, Protobuf. Так же сильно доминирует regex над другими фреймворками регулярок. Просто сделано нормально (при небольших недостатках - и тогда есть альтернативы). Тот же clap/structopt - главный недостаток что они жирные. Ты даже легкую альтернативу сделал. Но какой второй недостаток, а?

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

Просто отличный порядок, я считаю.

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

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

Thrift, Protobuf

Еще есть нативный бинарный tarpc (c bincode). Он красивее укладывается в растовые структуры данных. В качестве бреда думаю заюзать его в браузере, обрабатывая websockets пакеты через WASM

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

Всё это не интересно. Надо бенчи.

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

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

он божественнен и намного меньше причин делать его альтернативы

А люди всё равно делают.

Но какой второй недостаток, а?

Ты про pico-args?

Никто не знает как их готовить

С одной стороны - да. С другой, enum Error {} достаточно в 95% случаев.

Пользовался failure

Все эти обёртки для конечных приложений, а не для либ. Поэтому меня это мало волнует.

Просто отличный порядок, я считаю.

Критикуешь - предлагай. Ошибки уже 100500 обсуждались. Ничего лучше enum Error {} не придумали. Оно или жирное, или дорогое, или оба. Если ошибка требует аллокацию - сразу в утиль.

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

Все эти обёртки для конечных приложений, а не для либ. Поэтому меня это мало волнует.

Вот и приехали, ты сразу и рассказал почему проблемя ДЛЯ ТЕБЯ не проблема, а остальным нужно просто сделать вдоль.

Если что, то мне достоверно известно из анонимного источника что люди иногда пишут приложения.

Плюс, сделали бы нормально и стандартно, то даже в библиотеках ты мог бы пользоваться. Хоть бы стандартными derive макросами обмазали Error trait.

Мое пока идеальное решение чтобы все сообщество стандартизировалось на https://docs.rs/thiserror/1.0.9/thiserror/.

Thiserror deliberately does not appear in your public API. You get the same thing as if you had written an implementation of std::error::Error by hand, and switching from handwritten impls to thiserror or vice versa is not a breaking change.

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

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

RazrFalcon в ореховой скорлупке: исходит на хорошие вещи, с пеной защищает и сует везде свой раст, и вот теперь ещё торжественно принес какой-то ноунейм-велосипед, лишь бы не D.

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

лишь бы не D

С GC и без особого упора на производительность уже есть Go с колоссальными инвестициями и сообществом. Он состоялся как язык полностью. Недостатки уже почти не играют роли на практике.

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

vertexua ★★★★★
()

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

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

Я не толстый, и не унылый. Сейчас человек-метапрог (ну хз как его звать) доделает умные массивы, и наделаю примеров показывающих превосходство визуального программирования.

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

Вот и приехали, ты сразу и рассказал почему проблемя ДЛЯ ТЕБЯ не проблема, а остальным нужно просто сделать вдоль.

Почалося. Обработка ошибок на реддите обсуждается наверное раз в неделю. И всё всегда сводится к enum Error {}. Да, это проблема. Но решения нет.

Плюс, сделали бы нормально и стандартно

Ещё раз: что значит «нормально»? У вас есть RFC в загашнике?

Хоть бы стандартными derive макросами обмазали Error trait.

Ну пробрасывай Box<dyn std::error::Error> и всё.

Мое пока идеальное решение

Так это просто сахар над std. Работает он так же. Пусть добавляют. Я не против. Ибо тянуть процедурные маркосы в либу я не буду.

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

У D разве есть какие-то преимущества над Rust?

RazrFalcon ★★★★★
() автор топика
  • Но не гарантирует null-safety.
  • Проверяет проблемы с памятью в рантайме в отладочной сборке. В релизной сборке всё как в C/C++.

Тогда в чем смысл?

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

Автор из gamedev. У них там своя атмосфера. Обернули всё в ECS и горя не знаю (по рассказам).

В любом случае автор сам говорит, что может ещё всё поменяется. Но основная цель - это C# без GC.

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

Если на этом ЯП неудобно писать в busybox vi, выкидываешь ЯП.

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

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

А где-нибудь у автора есть что-то на тему обоснования почему и зачем он делает именно так (что-то вроде раздела Rationale/Motivation)?

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