LINUX.ORG.RU

Опрос о состоянии Rust 2020

 


2

8

Сообщество Rust запустило опрос о состоянии языка и экосистемы 2020 State of Rust Survey.

Цель опроса – выявить слабые и сильные стороны языка и определить приоритеты разработки.

Опрос опубликован на нескольких языках, участие анонимно и потребует около 10-15 минут. Ответы принимаются до 24 сентября.

Результаты прошлого года

Ссылка на форму 2020 State of Rust на русском языке

>>> Подробности

★★★★★

Проверено: alpha ()
Последнее исправление: unfo (всего исправлений: 3)

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

Вы не отличаете компилятор от системы сборки?

Ведь в C/C++ как раз есть компилятор

И в расте как раз есть компилятор. Называется rustc.

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

Вы не отличаете компилятор от системы сборки?

Я отличаю. А вы?

Это был ваш анонимный комментарий? Была же просьба развёрнутого ответа.

Но раз уж вы ответили, то расскажите, как вы собираете ваши проекты без cargo. С живыми примерами, пожалуйста.

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

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

Говоря короче: «взглянули звери на пейзаж, и прошептали: ералаш.»

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

Мы имеем четыре основных компилятора (да, мне нужны все эти ос):

  • GCC (Линукс)
  • MSVC (винда)
  • Clang (Андроид)
  • Apple Clang (iOS, Mac). Да-да, у него даже версии и список поддерживаемых функций отличаются

https://en.cppreference.com/w/cpp/compiler_support

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

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

Да, можно свести всё к Clang (msvc/clang, linux), но версия в ндк от этого быстрее не обновится, версия аппле на общую нумерацию не перейдет.

Модули? Какие модули? В стандарте есть говорите? В стандарте всякое есть. В компиляторах появляется? Ок. Но модулей от этого в жизни не прибавится. Может, лет через десять либы и переползут. Но сейчас модулей нет.

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

А что же Раст? Есть текущая стейбл версия, которую использует большинство. Ну или, возможно, чуть раньше, или ночнушка. В целом, небольшой +-, совершенно не критичный. Появилась новая фича? Доступна, можно активно использовать. На новый синтаксис async/await все переползли на удивление максимально быстро. Есть модули, активно используются, без них никак. Карго помогает подтянуть зависимости, без него сложно (но возможно). Можно завести либу разных версий в одном проекте без проблем. Это всё радует, поскольку не нужно тратить время на регулярную борьбу с зависимостями, а заниматься непосредственно бизнес-логикой. Но если вдруг встретится биндинг к сишной либе, то вновь привет, боль и страдания, особенно вне линукса. Растолибы собирать одно удовольствие, все мелкие зависимости без проблем подтягиваются, и резко не перестанут работать, поскольку подтягиваться будет нужная версия. Не говорю уже о самом языке и его удобствах (трейты, серде и т.п). И нет, дело не в безопасности, а в самом языке, его инфраструктуре, подходе.

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

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

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

И опрос совершенно не противоречит этому тезису :)

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

Если с 7кой было более менее, хоть и тупо с точки зрения прогарммиста, то в 8ке - полная жопа.

Вы правы.
Почему так?
Потому что у многих - «Горе от ума».

1С, конечно не панацея /но содержит и неплохие идеи /.
Их УФ /управляющие формы/ - а-ля HTML, а 1С - browser.
60000 классов в 1С.
Это

Горе без ума

Владимир

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

Плох тот разработчик, что не выслушивает своих пользователей.

Плох тот разработчик, который покупает тонну попкорна и трепится в ЛОР.

Работать НУЖНО!

Владимир

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

Как только начинаю подписывать свои посты, появляются посты от другого Владимира …
Растовцы

Вы панике не поддавайтесь. 
Спааасайтесь!  
Организованно.

Владимир

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

Растовцы

Сорри не удержался :) rustman - растаманы же.

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

Ведь в C/C++ как раз есть компилятор, а я уж сам разберусь как и что мне в мой проект добавить и как собрать зависимости.

Можно еще и без VCS писать и делать ежедневные срезы кода в качестве бэкапов, а обмениваться кодом с помощью диффов по e-mail, но зачем? Уже есть Java с Maven и там решение зависимостей отлично работает. После этого подтянулся .Net. Свое костыльное решение предложил nodejs: его неприятно использовать (oneliner’ы в качестве «библиотек», куча ненужного хлама), и тем не менее, еле-еле, но работает.

И тут у нас есть C/C++ с его офигенной «экосистемой»… Вот честно, я так и не осилил сборку 64-битного wine. Даже в 32-битном у меня нет пары библиотек (FAudio, Vulkan и USB. Их нет в дистре и надо самому собирать из исходников), «разберусь как и что добавить сам» - ok, если вам не жалко своего времени (IIRC, у wine порядка 20 зависимостей). Использование cmake - боль, оно работает плохо, т.к. в разных дистрах dev-пакеты лежат в разных местах (и никто не обещает, что ваш дистр совпадет с дистром автора кода). И самое главное: нафига всё это? И с каждым новым пакетом нужно по-новой проходить этот ад… Почему нельзя ввести одну команду «build» и чтобы проект собрался?!

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

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

Или вы думаете cargo что-то магическое делает?

Магического конечно ничего он не делает, но он делает что-то, что нельзя легко и просто увидеть, понять и контролировать: лезет в интернет (куда-то) и загружает оттуда файлы (какие-то).

Сколько не задавался этот вопрос, ответ всегда ровно один и тот же. Да, ваш: «можно без cargo, но никто так никогда не лелал и не делает, ведь с ним удобней». Это не аргумент, а отмазка и просто брехня.

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

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

Вот честно, я так и не осилил сборку 64-битного wine

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

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

То есть make, cmake и co легко и понятно? Лул.

Имеено так.

Вы не устали демонстрировать глубины своей некомпетентности?

Про тред с бинарной арифметикой напомнить?

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

Имеено так.

Ну тогда откланиваюсь. Тут только в морг.

Про тред с бинарной арифметикой напомнить?

Не вижу ничего плохого в критике говнокода.

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

Можно еще и без VCS писать и делать ежедневные срезы кода в качестве бэкапов, а обмениваться кодом с помощью диффов

Всё это понятно и для этого всего делается много хороших и разных инструментов. Но разницу-то подходов вы улавливаете?

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

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

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

Ну тогда откланиваюсь.

Лоб не расшиби.

Не вижу ничего плохого в критике говнокода.

Вы уже в школе басню «мартышка и очки» проходили?

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

Магического конечно ничего он не делает, но он делает что-то, что нельзя легко и просто увидеть, понять и контролировать: лезет в интернет (куда-то) и загружает оттуда файлы (какие-то).

Было бы желание.

$ cargo --offline new --bin hello
$ cd hello
$ echo 'libc = "0.2.77"' >> Cargo.toml
$ cargo --offline generate-lockfile
$ grep -e name -e version -e source Cargo.lock
   name = "hello"
   version = "0.1.0"
   name = "libc"
   version = "0.2.77"
   source = "registry+https://github.com/rust-lang/crates.io-index"
$ wget 'https://github.com/rust-lang/crates.io-index/raw/master/config.json'
$ cat config.json 
   {
     "dl": "https://crates.io/api/v1/crates",
     "api": "https://crates.io"
   }
$ wget 'https://crates.io/api/v1/crates/libc/0.2.77/download' -O libc-0.2.77.crate
$ mv libc-0.2.77.crate ~/.cargo/registry/cache/github.com-1ecc6299db9ec823/
$ cargo --offline build -v
anonymous
()
Ответ на: комментарий от anonymous

make, cmake и co легко и понятно? Лул.

Имеено так.

А ничего, что есть 100500 вариантов реализации make? Причём каждая со своими тараканами. Тот кто пробовал - знает, как «легко» сделать кроссплатформенную сборку на «чистом» make :))) Авторы того же cmake его запилили только потому, что «простой и понятный» make ниасилили. Штольман и Ко автотулсы свои также от нефиг делать написали.

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

А , зачем чистый make нужен расто подобный сахарок для лучшей отладки наверное

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

Все они много хотяти атк бридж и карго без них работает на данный момент все

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

А ничего, что есть 100500 вариантов реализации make? Причём каждая со своими тараканами. Тот кто пробовал - знает, как «легко» сделать кроссплатформенную сборку на «чистом» make

Сразу видно, что ты не пробовал. Реализаций может быть сколько угодно, проблемы make с этим не связаны, ибо «кроссплатформенную сборку» ты даже в GNUMakefile не напишешь.

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

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

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

ибо «кроссплатформенную сборку» ты даже в GNUMakefile не напишешь.

Я писал GNUMakefile для Windows(msys и обычный cmd), Linux(Debian, Manjaro), FreeBSD, MacOS, OpenIndiana, OpenBSD, DragonFlyBSD, NetBSD, Haiku

Что там сложного?

ifeq ($(OS),Windows_NT)
    PLATFORM := $(shell uname 2>NUL; false)
    ifeq ($(findstring MINGW,$(PLATFORM)),MINGW)
        PLATFORM = "Mingw"
    else
        PLATFORM = "Windows"
    endif	
else
    PLATFORM = $(shell uname)
endif

Затем в зависимости от PLATFORM просто делаешь include где описан компилятор и все его флаги и все зависимости и как их находить(то есть обычный не кроссплатформенный makefile)

include mk/haiku_clang.mk

или 

include mk/dragonfly_gcc.mk
fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 2)
Ответ на: комментарий от fsb4000

cargo все равно удобнее :D до карго даже конан не дотягивает пока.

cargo это вообще единственное, что есть годного в раст.

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

Это была шутка.

Использую C/C++.
Для моих задач /разработка API/ он более чем подходит.
Зачем мне критиковать Rust или какой-то иной язык программирования?

Владимир

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

Что там сложного?

Ты сам же и показал, что сложно.

ifeq ($(OS),Windows_NT)

$(OS)

Код для дефайна OS ты не привёл. Нет, в GNU make нет такого.

PLATFORM := $(shell uname 2>NUL; false)

shell uname

Я писал GNUMakefile для Windows(msys и обычный cmd)

4.2

Уже плохо. Но для полноты картины можно ещё написать поиск библиотек, компилятора, получение версии компилятора, диспатч по флагам для release/debug сборок, подключение библиотеки к сборке, пересборку при передаче пользователем дополнительных флагов(и сам механизм передачи, кстати) и, конечно же, установку собранного на хост. Написать в принципе можно. Но не нужно.

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

Код для дефайна OS ты не привёл.

В Windows NT по-умолчанию такой дефайн есть. Так я нахожу Windows это или нет. В Debian и Haiku такого дефайна в env нет…

uname в msys есть, а в Windows cmd нет. Я перенаправил сообщение об ошибке в Windows /dev/null, чтобы при запуске make в cmd никаких ошибок не показывалось

https://imgur.com/a/62VGW2x

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

В Windows NT по-умолчанию такой дефайн есть

ok.

uname в msys есть, а в Windows cmd нет

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

anonymous
()

Это

Говно ваш раст.

Альфа-жируха.

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

Ада, по крайней мере, образца 2001г. (стандарт 95г.) ни «обещает», ни «гарантирует» целостность памяти, как то: утечки неосвобожденной памяти, повторное освобождение и обращение к null. Ошибки в тогдашних системах искались в рантайме с использованием отладочных пулов динамической памяти, что требовало также инструментации исходного кода, и приводило к заметному падению скорости выполнения. Что-то типа валгринда, но на уровне либы языка.

Мой поинт в том, что так оно и надо, т.е.:

  1. язык должен быть простым, без вундер-фич, но предоставлять встроенные средства защиты от банальнейшего прострела ноги (в Аде с этим лучше, чем в С, и, через совместимость, соотв. лучше, чем в C++); Система базовых типов в Аде к тому же более продуманная, чем в C/C++;

  2. желательно в одной парадигме (Ада - чисто ООП, без какой-либо примеси функциональщины). Это позволяет быстрее готовить квалифицированных программистов, не отвлекаясь на всякий шум, доносящийся из современного и не очень компутер-недосайнс;

  3. Недостающие инструменты реализуются при помощи библиотек или сторонних утилит;

  4. язык из-за 1) и 2) можно редуцировать до верифицируемого подмножества, и проверять код статически сторонней утилитой или динамически на моделях;

  5. языку из-за 1) не нужен толстый жирный рантайм, и его проще портировать на другие системы, в т.ч. без ОС.

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

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

А в Rust нет свободы писать хуже. Вернее, есть unsafe. Но на сколько я понял, если всю программу писать в unsafe, чтобы ее потом в safe вариант переделать, надо весь unsafe код выкидывать, и фактически все с нуля переписывать.

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

А в Rust нет свободы писать хуже.

Есть, но цена скорость получившегося кода. Везде используешь клонирование и RC не заморачиваясь со ссылками и борьбой с компилятором.

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

Кстати, недавно увидел результаты какого-то опроса для С++ программистов.

«Какую систему сборки вы используете?»

https://i.imgur.com/gWLozRS.png

Многие названия прочитал в первый раз :)

и make довольно высоко держится :)

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

Исходники linker Microsoft имеются в сети?

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

и make довольно высоко держится

Это потому, что из CMake генерится makefile и потом собирается make-ом. Другой вариант, генерить build.ninja. Не думаю, что кто-то руками ninja файлы пишет. А если посмотреть на гистограмму, там make+ninja~=CMake.

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

Разработка ЯП без корпорации за спиной это курам на смех

цитата с wikipedia.org: «Microsoft’s language of choice for secure and safety-critical software components»

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

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

Похоже на низкоуровневый системный ЯП?

use actix_web::{web, App, HttpRequest, HttpServer, Responder};

async fn greet(req: HttpRequest) -> impl Responder {
    let name = req.match_info().get("name").unwrap_or("World");
    format!("Hello {}!", name)
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/", web::get().to(greet))
            .route("/{name}", web::get().to(greet))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}
freecoder
()
Ответ на: комментарий от freecoder

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

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

А какого уровня кодеру по вашему в принципе возможно такое читать и поддерживать? То, что возможно - сомнений нет: я читаю и поддерживаю Rust-код в продакшене уже не первый год, и никаких трудностей с этим не испытываю.

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

Потому что у многих - «Горе от ума».

1С, конечно не панацея /но содержит и неплохие идеи /. Их УФ /управляющие формы/ - а-ля HTML, а 1С - browser. 60000 классов в 1С. Это Горе без ума

до нас всегда доходит с опозданием – в несколько десятков лет (песня какая-то).

они повторно изобретают уже изобретённое: v7 Visual Basic 6.0 и полумодулу недоберон перепаскаль, в v8 – VisualBasic.NET под CLR.

тащем-та, если поискать, та же Euphoria или Lua в целом первое переплюнула (есть и кириллические диалекты). да даже BlackBox Component Pascal – переплюнул v7 из-за расширяемости DLL-ками в полпинка и POINTER TO ABSTRACT RECORD, неTAGGED указателей (обычные тегированные). то есть, FFI там с C dll довольно прозрачный.

то же самое про управляемые формы и БСП. недоXAML, пененедо паттерны. подсистемы в том же BBCP имхо понятнее чем вся БСП в целом.

60000 классов в 1С.

сколько там в .NET CLR ? в девятке весь .NET велосипед целиком переизобретать будут?

NIH синдром он такой.

а вот упрощать в например 2-3 модуля оберона базовые – не, не слышали.

самое смешное, что в том же ABAP или там Navision – даже хуже.

в Axapta X++ вроде бы более-менее продвинутый, да и всё.

смешное в том, что все эти 4GL языки 90x в итоге в никакое такое 5GL толком и не вырулили. ну или узок круг их и далеки они от народа.

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

Зачем мне критиковать Rust или какой-то иной язык программирования?

ну как же, изучать чего-то новое. а зачем? когда С++ и так 20 лет назад (я 28) на каком-то уровне «освоили».

тут вот в соседнем треде неосиляторы vi/emacs с неосиляторами nano вяло переругиваются. типа, зачем вообще этот «сложный», vi, мы уже блокнот типа «освоили».

или вот пожилые любители С++ которые кроме него никаких других языков не знают как-то в бложиках отписывались про «сравнение языков программирования с С++» : eax.me, еухений с агентами SObjectizer, кто-то ещё.

сравнение D, Eiffel, ещё там чего в духе: хорошие языки, но не С++. поэтому – не зайдёт.

фигня это какая-то неосиляторская, а не сравнение. так вам скажу.

если эксперимент – так давайте эксперимент. всё целиком писать на другом языке.

а то со своим уставом – да в чужой монастырь, и ноги не вытирают. а ещё лезут кудахтыть.

я так понимаю, критиковать чтобы – нужно какие-то 5-10 проектов целиком на другом языке сделать, и postmortem какой-то написать. типа вот это вот удачно было, в языке, в окружении, в утилитах поддержки ЖЦ и прочего. а вот тут кривизна или не осиляторство. а вот тут фичи полезные, практичные. а вот тут намудрили. а вот тут не дозрел до намудривания.

усложнять просто, упрощать сложно. всем этим любителям С++ нужно посмотреть на аду с оберонами. взять к примеру тот же BBCP и BCF фреймворк его расширяемый, и постепенно с оберона на аду переписывать. получится примерно в духе обёрток к С++, только модульно и контролируемо, потом и SPARK формалистику можно накрутить.

ну или там раст с магическими макросами. или ещё чего.

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

оно кое-как, но будет работать. Но здесь слишком много телодвижений и сложность именно в этом

enjoy your C++. и си-подобные.

портировал намедни LambdaMOO под winsock. ну как бы есть старый WinMOO под 1.8.0, но тут уже 1.8.3+ в транке с уникодом.

а ещё winsock 2.0 с асинхронностями бывает.

обнёс всё #define-ами, начал сначала тупо под второй winsock с асинхронностями писать. потом плюнул и из старого транка с винсоком в новый с уникодом и линуксизмами тупо пересадил вендоособенности.

в итоге код на Сишечке (без ++, емнип) – костыли вокруг #define-ов (если msys и mingw, тогда winsock, и т.п.). если win32 то … если win64 то … если msvc (ну тут вроде без особенностей обошлось, собирается обеими).

дык, код на сишечке – хрупкий. среда сборки на автолулзах и makefile – хрупкая. сборка yacc + свой велосипед – тоже.

не, оно конечно всё допиливается. и даже работает, портированное-то. куда оно денется.

но как-то — неаккуратненько. только ткни – сразу сломается.

ради хохмы, наткнулся на какой-то инсталлятор на powershell, и увидет там вебсервер в три строчки вокруг HttpListener. наколбасил под кураж свой недоMOO на сисярпе вокруг TcpListener за пару часов (а тот порт дня три допиливал, на няшной сишечке).

теперь вот думаю переписать ещё раз – на аде и пони, а затем на расте. с task-ами, с акторами и с lend/borrow и lock-free телнет-сервером с асинхронщиной.

ради хохмы.

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

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

то зачем нужен первый хрупкий язык. и этот ваш С++ впридачу, ога.

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

Ада это грубо говоря паскаль или модула, только с С++-сложностями. вот берём например дельфи или турбопаскаль. массовая, популярная попса же. среди паскалей.

берём модулу, и получаем системный язык с раздельной компиляцией модулей. потом Вирт решил опять всё упростить и начал изобретать Обероны – добавил сборщик мусора который нужен ради загрузки/выгрузки модулей, простую и понятную модульность, фреймворки вокруг неё в BBCP. потом опять упростил в Oberon07. Недоря в 90х писал диссер по реализации компилятора оберона на модуле, потом совмещённого модула/оберон. с SSA. это стало XDS Modula/Oberon-2/C++ компиляторами.

паскалевские языки – модула, оберон постпаскали пошли в сторону минимализма (но не примитивизма). упрощения. настолько, насколько возможно (но не проще этого).

Ада – пошла в направлении усложнения формальной части, в сторону С++.

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

оно Object-based, но не Object-oriented. типа как 1Cv7 или VB v6 объекты – полноценного наследования нету, но можно изобразить композицией.

в Ada95,Ada2005 и выше – это поправили. и опять кинулись усложнять. пошли по пути С++.

только тут синтаскис более человекочитаемый.

ну ещё есть SPARK и ASIS. второе – стандартный способ для компиляторов написать рефлексию, с ограничениями. первое – добавить формальной верифицируемости, например контрактное программирование (есть в стандарте Ada2010/2015).

в общем, используя SPARK – из паскаля сделали условный хаскель. или там Idris. в сторону метаинформации, и формальной верификации, а не совсем про зависимые типы.

см. на сайте AdaCore публикации с примерами. там где-то тетрис на SPARK разрабатывали, под носимый Android watch или аналоги на микроконтроллерах. и формально верифицировали сей тетрис, ога.

на уровне языка есть задачи, асинхронности, дженерики, исключения, полиморфизм уровня модулей, раздельная компиляция. что-то вроде зависимых типов или type-driven development как в Idris можно на SPARK изобразить, но с ограничениями.

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

GNAT компилятор = GCC C++ / Ada. биндинги пишутся в полпинка. есть кроссплатформенность, тот же mingw/lin/mac.

в общем – такой вполне себе полноценный язык программирования, эта современная Ада.

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

у него ещё и синтаксис вырвиглазный, поначалу запомнить сложно это всё. ну и с мутабельностью/иммутабельностью по дефолту – прикол. непривычно поначалу.

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

тесты синтетика, у каждого примеры свои.

поэтому делаете макеты/примеры, свои проектики пытаетесь на другом языке целиком реализовать. после 10-20 проектиков уже что-то можно будет более объективно (интерсубъективно), и менее предвзято утверждать, по результатом post mortem-ов, на своём личном опыте..

типа тенденция.

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