LINUX.ORG.RU

Zig 0.8

 , ,


2

5

После 7 месяцев работы и 2711 коммитов вышла новая версия Zig: 0.8

Zig это:

  • Современный компилятор С

  • Современный компилятор С++

  • Компилятор языка Zig

  • Сборочная система для C, C++, языка Zig

  • (Планируется) Пакетный менеджер для С, C++, языка Zig

Zig разрабатывается под лицензией MIT: https://github.com/ziglang/zig/blob/master/LICENSE

Язык Zig – это язык общего назначения, который старается быть простым. Нет макросов, скрытых аллокаций, скрытого потока управления.

Небольшая заметка, которая пытается объяснить зачем нужен Zig, когда уже есть C++, D, и Rust: https://ziglang.org/learn/why_zig_rust_d_cpp/

Даже если вам не интересен язык Zig, возможно вам будет интересен Zig как кросскомпилятор С или С++.

#include <iostream>
int main() {
    std::cout << "Hello World!\n";
    return 0;
}
$ zig c++ -o hello hello.cpp -target riscv64-linux
$ qemu-riscv64 ./hello
Hello World!

Ещё про использование zig как кросскомпилятора: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

В новой версии:

  1. Обновление LLVM до LLVM 12.

  2. Поддержка arm64 macOS (aka the Apple Silicon) и также поддержка кросскомпиляции C, C++, и Zig в arm64 и x86_64 macOS.

  3. Zig также разрушает миф, что вам нужен Mac и Xcode для компиляции кода для Mac OS. Заголовочные С файлы Apple выложены под Apple Public Source License которая разрешительная.

Так что вы можете собирать бинарники для Apple из-под Linux/Windows/FreeBSD без XCode:

#include <iostream>

int main() {
   std::cout << "Hello World!\n";
}
$ zig c++ main.cpp -o test -target x86_64-macos
$ file test
test: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

Подробнее: https://ziglang.org/download/0.8.0/release-notes.html#macOS-Support

и

https://github.com/ziglang/fetch-them-macos-headers

  1. Добавлена поддержка WASI libc

  2. Начальная поддержка Haiku

  3. Изменения в языке: https://ziglang.org/download/0.8.0/release-notes.html#Language-Changes

  4. Изменения в стандартной библиотеке: https://ziglang.org/download/0.8.0/release-notes.html#Standard-Library

  5. Zig поддерживает Position Independent Executables, даже когда компилируются статические бинарники

  6. Изменения в сборочной системе: https://ziglang.org/download/0.8.0/release-notes.html#Zig-Build-System

  7. Обновление musl до 1.2.2, mingw-w64 до 9.0.0, возможность нацеливания glibc 2.33

Полный список изменений: https://ziglang.org/download/0.8.0/release-notes.html

>>> Официальный сайт

★★★★★

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

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

После просмотра лекции хотел сказать «продано», но обнаружил, что язык разрабатывается с 2015 и до сих пор не дошёл до релиза. При том как минимум с 2019 это постоянная работа автора. Видать он немного лукавит, когда говорит, что просто убрал из Си всё кривое и получил Zig.

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

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

Сборщик мусора и связанный с ним API для работы с памятью не панацея.
Имеются разные походы для создания allocator, которые много упрощают /а не усложняют/ работу с памятью.
Не буду стараться создавать «серебряную пулю».
Allocator упростит работу с API, обеспечивающего работу с объектами.
Для иных целей будет использован иной allocator, но программист об этом и знать не будет.

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

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

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

Имеются разные походы для создания allocator, которые много упрощают /а не усложняют/ работу с памятью.

Я понимаю, тут можно много чего интересного сделать. Сам такие вещи делаю на стероидах. Моё сугубое имхо в том, что С++ здесь лучше С на голову, так как предоставляет полноценный процессор раскладки данных по памяти (мономорфная обобщенная value-семантика). На С такого не добиться без сложного внешнего кодогенератора. Лучше сразу С++ как хост-язык.

Rust в этом отношении откровенно слабоват. По крайней мере, был. Мало того, что они забили на очень полезные HKT, так еще и поленились сделать поддержку числовых обобщенных параметров. Мол, а зачем? Кому-то надо что-то сложнее std::vector? Представьте, себе, надо. Эпичнее в этом плане только Go. Был. Теперь исправляется.

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

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

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

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

или нечто смоллтоко-подобное: spry – поверх Nim.

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

хотя это не совсем смоллток

гитхаб с примерами.

нужна автоматизируемая платформа, изначально заточенная на метапрограммирование

собсно сам смоллток и есть такая платформа по сути – не столько язык, сколько ОО метаязык (на метаклассах вот это всё).

в туториалах по squeak/pharo by example начинается с «создадим через class browser новый package из подсистем-классов и отсортируем в новую category (руками или из меню «отсортировать все неотсортированные» новые методы (=объектно-ориентированного метаобъектного протокола)»

опять же, <primitive: N> в Pharo/Squeak VM.

опять же, сам компилятор/интерпретатор/платформа – это ещё один объект такой среды.

Тут нужно поднимать систему сборки до уровня распределенной дата-платформы (language server на стероидах и веществах)

ну то есть, смоллток образ сам по себе можно понимать например как такую ОО СУБД времени ещё одного (вдобавок к runtime/compile time/ = build time, времени конфигуряции :)

который чисто случайно можно выгружать в файлы (старомодным образом или через changes файлы или через montichello – кстати, эдакий СКВ метапроговый только нормально реализованный и работающий в отличие от).

по сути нужно какое-то управление конфигурацией уровня среды, времени фазы/стадии этой самой config/build time вдобавок к runtime/compile time.

опять же, ну вот spry реализовали метакомпиляцией поверх Nim поверх сишки. с возможностью расширения самописными примитивами написанными на Nim, сишке или макросах Nim.

аналогично оно могло бы быть реализовано и на чём-то типа Zig, или типа Rust, или типа цепепе с модулями с плагинами времени конпеляции.

Nim здесь как прозрачный минималистичный пример.

вот смоллтоковая эдакая среда типа spry даже интереснее в чём-то : можно взять и невозбранно экспериментировать с примитивами, ну или взять сишку и ОО систему в духе смоллтока (например, dynace ) воткнуть.

в общем, смоллток сам по себе эдакий конструктор и вполне подходит на роль такой среды. а spry более настраиваемый конструктор.

сюда бы ещё добавить что-то в духе Petit parser и прочую AST прозрачность и гомоиконность. и невозбранно прикручивать всякие DSLи метапроговы.

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

Кому-то надо что-то сложнее std::vector?

У меня свой API для работы с данными.
К примеру а-ля vector может содержать разные типы любой сложности данные в run-time.

Как-то так …

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

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

вот почитываю намедни Squeak by Example / Pharo by Example, про Morphic GUI объекты.

и хелловордный пример: игра пятнашки из 2 классов семи методов.

и прикидываю тут, как выглядел бы некий условный метапрог на Morphic-овском API.

вроде, очень просто и наглядно выходит.

такой метапрог по построению получается заодно и (а) и (б), и «сам на себе»

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

Все это можно переложить на метафункции

конпелируемые подфункции с СУВТами

и сделать часть проектов, эту автаоматизацию использующих.

метапрог сам-на-себе, конечно же =:-)

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

вот почитываю намедни Squeak by Example / Pharo by Example, про Morphic GUI объекты.

Теория и знания конечно нужны, а вот без применения их на практике
обычно все заканчивается

 - Раздуванием щек на конференциях;
 - В оффлайне
anonymous
()
Ответ на: комментарий от anonymous

метапрог сам-на-себе, конечно же =:-)

Ээээээ все не так.
Прототип Метапрога, который эмулирует в виртуальной машине разработанной на Метапрог, будущий Метапрог.

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

Еще AST нужен с хорошим API и документацией и возможность добавления в исходники ссылку на parent node, содержащий метаданные требуемого объекта и чтобы в run-time можно было извлекать эти данные

факториал в браузере (полный пример)

spry_vm как Nim библиотека (в идеале, опять же должно бы быть времени конпеляции)

поверх которой можно AST макросов накрутить не совсем примитивами на Nim

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

поверх которой можно AST макросов накрутить не совсем примитивами на Nim

НАКРУТИТЬ НЕ СЛОЖНО

Сложно реализовать хорошую архитектуру и API
anonymous
()
Ответ на: комментарий от anonymous

Пытался как-то жабосиньором в швейцарию

Я бы не рекомендовал сейчас ехать в страны с дорогой жизнью, типа Швейцарии или США. Если, конечно, нет политических мотивов и хочется просто лучшей жизни. Швейцария мало того, что дорогущая, так еще и скучная при этом. В Америку стоит ехать, если хочется поработать в «высокотехнологичной американской компании» или есть какие-то другие профессональные планы (производство чипов, SW/HW co-design, etc). Здесь всё, что имеет экспортные ограничения, автоматически требует гражданства или гринкарты. А это очень многое.

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

Я бы не рекомендовал сейчас ехать в страны с дорогой жизнью, типа Швейцарии или США.

Цель умереть сидя на золотом унитазе - так себе …

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

Очень даже годно, если рассматривать это как языковой эксперимент. Что касается меня и моих задач, то я вот это вот всё хочу, но только для С++ и его zero-cost семантики. Понятное дело, что я слишком многого хочу, но кто мне запретит?))

можно понимать например как такую ОО СУБД времени ещё одного (вдобавок к runtime/compile time/ = build time, времени конфигуряции :)

Я это всё немного по-другму называю. Нужно следующее:

1. Высокопроизводительная мультимодельная БД, чтобы могла и в транзакции, и в аналитику (у меня есть такая). Чтобы могла эффективно хранить и предоставлять доступ как к данным проекта, так и к промежуточным результатам.

2. Обобщенный дата-пайплайн для трансформаций над (1), с компилятором, как одной из видов задач. Это будет системой борки артефактов.

3. Интеграция API (2) и (1) для доступа из метапрограмм.

4. Экспорт вот этого всего через FUSE для доступа из сторонних приложений, не адаптированных к платформе (например, Xilinx Vivado).

5. REST-like API для интеграции с IDE и поддержка типичных для интерактивной работы workflow. IDE-шки становятся просто веб-мордами к бекенду платформы разработки. Остальные тоже могут интегрироваться через API.

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

Цель умереть сидя на золотом унитазе - так себе …

Не будет золотого унитаза. Кончились))

Программистский народ себчас бежит из крупных городов. А кто-то — так и вообще из страны.

anonymous
()

Пример продвинутого метапрограммирования на практике

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

Есть такой генератор RISC-V SoC — Rocket Chip, написанный на hardware construction language Chisel3. Это такой DSL, построенный над scala-хостом. На входе ему дается конфигурация SoC, а на выходе получается прошивка этой SoC под целевую платформу (FPGA board, ASIC). Сделан берклийскими ребятами, сейчас подвизающимися в SiFive. А софтовым направлением у них занимается ни кто иной, как Крис Латтнер, создатель LLVM и Clang, который недавно свалил к ним с Гугла. Латтнер, кстати, сейчас делает Circt — расширение LLVM/MLIR для трансформации цифровых схем.

В чем суть? Сейчас мы вошли в ситуацию избыточного кремния. Наращивать количество суперскалярных OoO-ядер общего назначения особого смысла не имеет, нужно идти в направлении акселераторов: нейронки, графика, базы данных, защита памяти, даже тот же сборщик мусора (да-да, переслать два байта — это, оказывается, много работы). И тут возникает техника software/hardware co-design. Это когда софт и железка разрабатываются вместе под одну задачу. Но чтобы это взлетело, нужно очень разнородные компоненты объединить в интегрированную платформу. Rocket Chip использует Scala как хостовый язык, и это такое себе в плане близости к железу. Есть аналогичные эксперименты с Rust в качестве хостового языка, и это уже на много интересней в плане того, чтобы еще рядом с HDL внедрить High Level Synthesis (Circt!). А я думаю, что С++ с некоторыми расширениями синтаксиса (для лучшей интеграции микро-DSL) и нормальным метапрограммированием будет «самое то», так как охватывается еще и HPC.

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

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

Я в курсе про Швейцарию, сам в европе живу 20 лет. И на США у меня свои четкие планы, не мальчик уже. Одна проблема - не пролезть.

anonymous
()

Nim

Чем Zig лучше Nim? Для десктопного программирования. И отдельно для GUI. Можно ли вообще их сравнивать, с практической точки зрения? С позиции применения вот прямо сейчас, сегодня, как они есть. А не ждать каких-то релизов или обещанных фич.

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

После просмотра лекции хотел сказать «продано», но обнаружил, что язык разрабатывается с 2015 и до сих пор не дошёл до релиза. При том как минимум с 2019 это постоянная работа автора. Видать он немного лукавит, когда говорит, что просто убрал из Си всё кривое и получил Zig

ну с 2019 там очень много сделано, это хотя бы по новости видно. А что релиза еще нет - ну так люди никуда не торопятся и хотят сделать всё как надо. По-моему так лучше, чем по-быстрому выкатить какую-нибудь недопиленную непродуманную фигню и потом говорить «извините, у нас обратная совместимость», как в расте.

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

«извините, у нас обратная совместимость», как в расте.

То есть хорошая обратная совместимость, а она у раста после выхода версии 1.0 весьма неплохая, теперь никому не нужна?

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

раст в принципе никому не нужен, с обратной совместимостью или без.

Ну из всего ненужно что обсуждается в этой теме, раст как-раз самый нужный. А про перспективы zig пока рано говорить, надо подождать пока версия 1.0 выйдет.

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

Очень похожее по сложности языка, имелось в виду?

Да и наследующее многие недостатки C++.

Всё верно. Выразительный язык не получится сделать «простым».

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

Что касается линейных типов в Rust, то в будущем C++ будут lifetimes, что не то же самое, но то же хорошо.

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

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

Rust в этом отношении откровенно слабоват. В обобщенном шаблоном программировании да, но у него еще есть полноценные процедурные макросы, а с добавлением пары библиотек и нормальные ast макросы с квазицитированием, а это уже лучше шаблонов С++.

По крайней мере, был. Мало того, что они забили на очень полезные HKT, так еще и поленились сделать поддержку числовых обобщенных параметров.

Поддержку числовых обобщенных параметров добавили в стабильный компилятор в 1.51, const вычисления тоже улучшают постепенно, но медленно, HKT пока только в мечтах, но может и добьют потихоньку.

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

Rust в этом отношении откровенно слабоват.

В обобщенном шаблоном программировании да, но у него еще есть полноценные процедурные макросы, а с добавлением пары библиотек и нормальные ast макросы с квазицитированием, а это уже лучше шаблонов С++.

По крайней мере, был. Мало того, что они забили на очень полезные HKT, так еще и поленились сделать поддержку числовых обобщенных параметров.

Поддержку числовых обобщенных параметров добавили в стабильный компилятор в 1.51, const вычисления тоже улучшают постепенно, но медленно, HKT пока только в мечтах, но может и добьют потихоньку.

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

zig уже нужен, как отличная тулза для кросс-компиляции (или просто компиляции под виндой и макосью без лишних зависимостей) кода на сях и плюсах

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

Куда проще онанировать на «ещеодинсуперпуперезыгтакойжекаксинокруче», чем вести реальный продуктмвный r&d в области исследования езыгов и кимпиляторов.

Где можно почитать твои статьи в peer-reviewed журналах? Может хоть технические отчеты какие остались после твоего R&D?

seiken ★★★★★
()
Ответ на: Nim от anonymous

Чем Zig лучше Nim?

Не знаю.

И отдельно для GUI.

На Zig можно использовать сишные библиотеки. (в основном, но бывают ошибки с макросами С)

Так что можно использовать gtk или WinAPI для написания GUI:

вот пример на gtk-3: https://github.com/Swoogan/ziggtk (смотри на ветку latest с моим патчем https://github.com/Swoogan/ziggtk/pull/2 )

https://imgur.com/a/tY4FRfo

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

Другими словами серверных/финансовых/embedded/hpc приложений на C++ в промышленном обороте гораздо больше

тогда почему это незаметно по рынку труда?

И кстати не стоит манипулировать статистикой и объединять Qt c GameDev, где Qt не используется, а C++ очень активно используется.

С самого начала, я QT И геймдев называл

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

Поддержку числовых обобщенных параметров добавили в стабильный компилятор в 1.51, const вычисления тоже улучшают постепенно, но медленно, HKT пока только в мечтах, но может и добьют потихоньку.

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

но у него еще есть полноценные процедурные макросы ... а это уже лучше шаблонов С++.

Не совсем так. Макросы сами по себе (вычисления уровня AST) не заменяют вычислетния уровня типов. Иначе придется реализовывать полноценный мономорфизатор с HKT средствами макросов. А такой мономорфизатор, к слову, это где-то 20% (грубо) кодовой базы компилятора Clang.

Но, в целом, я согласен, что дженерики раста (+ поддержка числовых параметров) + макросы с квазицитированием — это гораздо лучше одних только шаблонов С++ для тех случаев, когда сложные вычисления уровня типов не нужны или их легко можно заменить вычислениями уровня AST. А это, наверное, 95% практических случаев (генерация бойлерплейта, биндингов и т.п.).

Но можно уровень композиции AST добавить к Clang в качестве частного расширения компилятора (в виде метафункций) и получить вот это вот всё, мощный мономорфизатор и выход на огромную кодовую базу и аудиторию в несколько миллионов программистов, изголодавшихся по современным фичам. За Rust останутся линейные типы и unsafe, но без этого можно жить.

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

Ахаха. Вот он я. Поскольку я тут что-то пишу раз в несколько лет (ленивый я), то лень заходить.

aist1 ★★★
()
Ответ на: Nim от anonymous

Например тем, что ему не нужен C? Nim же просто компилируется в С код.

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

> но в этом и бенефит кода, что его НЕ НАДО ИЗМЕНЯТЬ, если ты вдруг решил, что вместо поля тебе нужно проперти

Проблема в том, что при чтении такого кода ты не можешь сказать, меняет ли он что-то ещё, кроме a

Не могу И НЕ ДОЛЖЕН. В этом и суть пропертей, что есть скрытые действия, которые тебе не надо видеть.

Хочешь «видеть всё» - пиши на асме! Только вот производительность твоя будет на уровне времён перфокарт.

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

раст в принципе никому не нужен, с обратной совместимостью или без.

Большая БЕДА, что создали Rust не знают вашего мнения да и вовсе не читают ЛОР.
В противном случае они бы ДАВНЫМ ДАВНО прекратили его разработку.

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

Хочешь «видеть всё» - пиши на асме!

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

Другое дело, что компиляторы дожны давать возможность, при необходимости, посмотреть все промежуточные состояния программы. Не для проверки корректности, а для осведомленности о процессе. Чего, в целом, нет. Нужны сторонние инструменты типа godbolt, дающие возможность интерактивной навигации по структуре промежуточных представлений. Эволюция в этом направлении идет в рамках концепции language server, но пока «из коробки» с этим все еще плохо.

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

дак они и прекратили, мозилла всего через 5 лет после выхода версии 1.0 выкинула раст на мороз. С новым вас, как говорится, годом :))

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

дак они и прекратили, мозилла всего через 5 лет после выхода версии 1.0 выкинула раст на мороз.

С первым сентября вас.
На мозиле свет клином не сошелся …

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

Не могу И НЕ ДОЛЖЕН. В этом и суть пропертей, что есть скрытые действия, которые тебе не надо видеть.

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

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

придурок, ты начал что-то там говорить про создателей раста. Создатели раста - мозилла. За свои слова будем отвечать, или как?

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

Если на то пошло, то изначальный создатель вообще «частное лицо», это уже потом мозилла подключилась.

Ну и мозилла состоит в Rust Foundation, не уверен, что это можно назвать «выкинула на мороз».

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

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

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

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

Мозилла переживает не лучшие времена, может даже загибается. Тем не менее, членство в Rust Foundation стоит денег. Могли бы совсем оттуда выйти, но нет.

и манагеров из гуглов с майкрософтами. То есть там, где стоит задача освоить деньги, а не заработать их.

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

Это всё, что нужно знать об этом недоязыке.

Обидно, наверное, наблюдать как любимые пере-языки проигрывают недо-расту?

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

Ну я могу немножко сказать про использование этого языка (Rust).

Уже существующую нишу для него найти довольно сложно, так как он не так чтобы на голову был выше других. Реальной доказуемой защиты памяти он НЕ предоставляет, так как всё равно требует блоков unsafe, неопределенное поведение из которых может распространяться далеко за пределы этих блоков. Т.е. код на rust безопасен только при условии, что unsafe блоки безопасны. В случае со связным списком эти блоки можно сделать очень маленькими, а вот в моих случаях (сложная работа с памятью), очень большая и сложная часть кода попала бы в unsafe (по крайней мере, если переносить с С++ на Rust не переделывая радикально структуры данных).

С линейными типами связано еще много неудобств, они принципиально не могут в обобщенные графы. И для многих практических случаев сборщик мусора оказывается более удобным в разработке, и обеспечивающем лучшую защиту памяти (умеет в графы). Поэтому некоторые люди предпочитают Go Расту.

Но появляются новые ниши, где у языка есть неплохие перспективы. Дело в том, что сейчас начинает снова наблюдаться относительный дефицит вычислительных мощностей и дисковой памяти. Поэтому появляется спрос на те же веб-фреймворки, которые сособны на одном ящике зарулить сотни тыщ запросов в секунду с жестким SLA. Системы со сборщиком мусора тут (SLA) разведут руками и скажут, что не могут. На С++ веб-фреймворк, конечно, написать тоже можно. Но тулинг совсем слабый для типичного стартапера.

Меня тут в NYC пытались хайрить и на Go, и на Rust. И пока субъективное впечатление, что спрос на первый раз в 10 больше, чем на второй. В пользу обоих языков говорит то, что они довольно таки простые. И изучить их можно за пару месяцев максимум. Что обычно происходит во время онбоардинга. Относительная доля Rust будет расти за счет возникновения новых ниш, в котрые С++ не может залезть из-за слабого тулинга.

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

Это Rust то простой?

Относительно С++ — очень даже. И синтаксически, и условным отсутствием UB в безопасном коде. Писать на нем будет несколько сложнее из-за линейных типов, но это уже другое.

И поподробнее можно, куда С++ не может залезть?

В веб-фреймворки, например. То, что они физически есть, не значит, что я могу прийти в условный стартап и сказать «А давайте это всё напишем на С++, а не на Go». Со мной не будут разговаривать даже укуренные обитатели Долины.

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