Подготовлен (https://blog.rust-lang.org/2017/03/16/Rust-1.16.html) релиз языка программирования Rust 1.16 (http://www.rust-lang.org), развиваемого проектом Mozilla, обеспечивающего автоматическое управление памятью и предоставляющего средства для высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo (https://www.opennet.me/opennews/art.shtml?num=44712), написанный (https://github.com/servo/servo/) на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model). На Rust также разрабатывается (https://www.opennet.me/opennews/art.shtml?num=43105) операционная система Redox (https://www.redox-os.org/), использующая концепцию экзоядра и продвигающая принцип "все есть URL".В подготовке нового выпуска приняли участие 137 разработчиков. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...):
- В пакетном менеджере Cargo реализована команда "cargo check", при указании которой компилятором выполняются все совершаемые при сборке проверки кода, но пропускаются достаточно ресурсоёмкие стадии, связанные с генерацией исполняемых файлов. Для некоторых проектов "cargo check" может выполняться в несколько раз быстрее обычной сборки, что позволяет значительно сэкономить время разработчика при выполнении тестовых пересборок, обычно используемые в процессе разработки чтобы убедиться, что добавленный код компилируется;
- В команды "cargo build" и "cargo doc" добавлен флаг "--all" для сборки и документирования всех исполняемых контейнеров (crate) одной командой. По аналогии с rustc в cargo также добавлены флаги "--version" и "--verbose";
- В cargo и репозиторий crates.io добавлена возможность использования не только заданных в произвольной форме ключевых слов, но и предопределённых фиксированных категорий (https://crates.io/categories);
- Для обеспечения работы "cargo check" в компилятор rustc добавлена поддержка нового типа файлов ".rmeta", в которых сохраняются только метаданные об исполняемых контейнерах (crate), необходимые для проверки типов и сопутствующей сборке информации о зависимостях. В будущем файлы ".rmeta" планируется задействовать в сборочном сервере Rust Language Server и возможно в некоторых других утилитах;
- Удалена диагностическая подсказка "consider using an explicit lifetime parameter", выводимая при проблемах с lifetime-аннотациями, которая только запутывала новичком, в некоторых ситуациях давая ложный совет, не приводящий к устранению проблемы;
- Диагностические подсказки об опечатках в именах теперь не ограничены именами функций, локальными переменными и полями в структурах, и также применяются (https://github.com/rust-lang/rust/issues/30197) для имён импортируемых модулей, crate и inline-блоков;
- В разряд стабильных переведена новая порция (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...) функций и методов. В том числе стабилизированы VecDeque::truncate,
VecDeque::resize,
String::insert_str,
Duration::checked_*,
str::replacen,
str::repeat,
SocketAddr::is_ipv4/6,
IpAddr::is_ipv4/6,
Vec::dedup_by*,
File::set_permissions,
String::split_off и т.д.- По аналогии с "println!" добавлена новая форма "writeln!" без указания аргументов, выводящая перевод строки;
- Во все структуры стандартной библиотеки добавлено поле fmt::Debug.
Напомним, что язык Rust сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий. При этом Rust обходится без использования сборщика мусора или runtime, что делает возможным создания на Rust библиотек, которые могут выступать в роли прозрачной замены библиотекам для языка Си. Для распространения библиотек на языке Rust, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек введён в строй репозиторий crates.io (https://crates.io/).
По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Rust поддерживает смесь императивных, процедурных и объектно-ориентированных методов с такими парадигмами, как функциональное программирование, обобщённое программирование и метапрограммирование, в статических и динамических стилях.
URL: https://blog.rust-lang.org/2017/03/16/Rust-1.16.html
Новость: http://www.opennet.me/opennews/art.shtml?num=46221
Чем он лучше С++?
Да ничем. Просто прикрутили автоматическое управление памятью для тех, для кого это проблема.
>>при этом обходясь без использования сборщика мусора и runtimeзаметку не читал но осуждаю.
Откровения о языках программирования! Только на opennet!
За счет встроенных возможностей статического анализа позволяет применять оптимизации работы с памятью, которые в с++ не возможны или требуют очень сложного анализа. И вне секций unsafe обеспечивает безопасность.
>> За счет встроенных возможностей статического анализа- У кого-то проблема запустить статистический анализатор в другом ЯП?
Значит проблема не в коде....
> статический анализаторсорри
Речь не о статических анализаторах ошибок и уязвимостей в коде. Речь об анализе кода компилятором. В С++ нет встроенного динамического массива. Массивы работают через указатели. Указатели же не несут данных о памяти, на которую указывают. Компилятор в ряде случаев не может определить перекрываются ли копируемые диапазоны и применить соответствующие оптимизации. В Rust данная ситуация исключена.
> В С++ нет встроенного динамического массива. Массивы работают через указатели.- Поэтому я и спокоен за С++, когда вижу какие глупости пишут его критики, расхваливая сырые поделки на замену :)
То анализатор не знают как запустить, то массивы в современном С++ хорошего стиля - "через указатели", которые "перекрываются"...
Дело в том, что возможности и сложность реализации статического анализатора сильно зависит от языка.Для C++ сколько анализаторов не писали, пока не могут гаранитровать безопасность данных, потому что с одной стороны в языке богатый синтаксис (всё не проверишь), а с другой стороны мало ограничений на корректную программу.
В Rust же благодаря налагаемым ограничениям на корректную программу, безопасность данных гарантировать удалось.
> Чем он лучше С++?На бенче-игрищах наконец-то обогнал плюсы и идет теперь сразу после сишечки:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
ХЗ, может это просто LLVM лучше оптимизирует на этих задачах.
Но зачем, если есть си? Тот же вопрос относится и к любому другому языку, кстати. А теперь, хейтеры, внимание. Даю команду атаковать ненавидимый вами си и лично меня.
В си очень просто отстрелить себе ногу, а раст это шотган с предохранителем.
>Напомним, что язык Rust сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий.
ИЧСХ, про скорость уже не говорится. :-)
> ИЧСХ, про скорость уже не говорится. :-)о рили?
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
Сразу после сишечки и перед плюсиками.
Учитывая, что используется llvm и тот же clang так и не догнал gcc, вполне неплохой результат.
Синтетические бенчмарки сосут. Чтобы понять с какой скоростью оно реально работает и сколько при этом жрёт - запусти демку "нового" FF или распиаренный redox. Гарантированно получишь разрыв шаблона.
> Синтетические бенчмарки сосут.
> Чтобы понять с какой скоростью оно реально работает и сколько при этом жрёт - запусти демку "нового" FFИ с чем ты собирался его сравнивать?
> или распиаренный redox.По сравнению с чем он "сосeт", умник? С линухом? Ты не в курсе, что такое микроядро или Proof of Concept, причем реализованый считай что "в одно рыло"?
По сравнению со "старым", негодным FF на c++, который ужас-ужас.> Ты не в курсе, что такое микроядро или Proof of Concept
Твои маняманёвры очень забавны. Впрочем так обычно и бывает, когда растофанатика приземляют на грешную землю.
> По сравнению со "старым", негодным FF на c++, который ужас-ужас.Верни машину времени на место!
>> Ты не в курсе, что такое микроядро или Proof of Concept
> Твои маняманёвры очень забавны. Впрочем так обычно и бывает, когда растофанатика приземляют на грешную землю.Т.е. ты даже с мат.частью перед вбросом не ознакомился? Или просто очередной ыксперд опеннета?
Да не верещи ты так, уши закладывает. На вот тебе, просвещайся: https://www.opennet.me/opennews/art.shtml?num=44712
> На вот тебе, просвещайся: https://www.opennet.me/opennews/art.shtml?num=44712О, увидел знакомое слово и опять пукан переклинило?
Дорогой ыкспердус, движок огнелиса все еще на плюсиках. И ты все еще не сказал, с чем ты там что и как сравнивать собирался. Похоже не просто теплое с мягким, а фиолетово-легкое с кисло-широким?
Кстати:
https://www.opennet.me/opennews/art.shtml?num=43872
ОС Браузер Расход памяти Год назад
Ubuntu 16.04 LTS Chrome 54 1,478 MB 944 MiB
Ubuntu 16.04 LTS Firefox 55 – 2 CP 765 MB 525 MiB
Ubuntu 16.04 LTS Firefox 55 – 4 CP 817 MB
Ubuntu 16.04 LTS Firefox 55 – 8 CP 990 MB
Теперь ты нам расскажешь, что плюсы уже тоже не те и «старые плюсы были огого, а новые только для хипстеров» или предпочтешь обтекать молча?
>> Ты не в курсе, что такое микроядро или Proof of Concept
>Твои маняманёвры очень забавны. Впрочем так обычно и бывает,
>когда растофанатика приземляют на грешную землю.Ты просто жирный тролль? Про переключения контекста первый раз слышим? Ну тогда посмотри как тормозит микроядерный minix по сравнению с линем, minix на твоем любимом C написан. Или Hurd. Тоже на Си.
А создатели редокса, кроме напоминания о недостатке микроядер в виде большого числа переключений контекста, еще пишут:
"
Unfortunately, Redox isn't quite there yet. We still have a relatively slow kernel since not much time has been spent on optimizing it.
"
В курсе, в курсе. Только вот валить всё на микроядро тут не выйдет, в посте выше есть ссылка на демку сервы, которая тормозит и жрёт точно так же.ИЧСХ, только растофанатики могли повестись на развод с микроядром, хотя тухлость этого направления была продемонстрирована ещё два десятка лет назад.
> ИЧСХ, только растофанатики могли повестись на развод с микроядром, хотя тухлость этого направления была продемонстрирована ещё два десятка лет назад.Дык корни явлений одинаковые: поиски серебряной пули и обязательно чтобы не как у всех.
Кому нужна свобода - Си. Кто готов к дополнительным правилам и ограничениям, обеспечивающим безопасность и увеличение скорость за счет большего количества возможных оптимизаций компилятором - Rust.
Можно и в Rust'e с unsafe писать.
Только с ним и получается.
> Только с ним и получается.Дай угадаю - ты из тех, кто и на плюсах будет писать в сишном стиле, а потом резать правду-матку про негодность «надстройки над Си» на форумах?
Сам придумал, сам опроверг. Возьми с полки пирожок.
"Тот кто жертвует свободой ради «безопасности» в итоге не получает ни того ни другого" © :-)
К данной ситуации это не относится
Еще как относится.
> Еще как относится.Что, тоже хотят заставить платить налог на защиту?
Для деревянных поясняю, любой нетривиальный софт на русте будет содержать преизрядное количество unsafe'ов, а bdsm с компилятором при этом никуда не денется.
Т.е. и свободу отняли и безопасности не завезли.
> Для деревянных поясняю,Специально для одаренных поясняю: цитаты из контекста вырывают только чудаки. Да, я про цитирование Франклина.
> любой нетривиальный софт на русте будет содержать преизрядное количество
> unsafe'ов, а bdsm с компилятором при этом никуда не денется.Т.е. и свободу отняли и безопасности не завезли.Реальный опыт или предположения с высоты дивана?
https://github.com/RazrFalcon/svgcleaner
Что-то я тут не вижу вообще ни одного ансейфа.
https://github.com/kondrak/rust64
Тут аж 2 штуки, причем в одном месте. Но видимо эмулятор с64 слишком тривиален.
> Для деревянных поясняю, любой нетривиальный софт на русте будет содержать преизрядное количество unsafe'ов, а bdsm с компилятором при этом никуда не денется.Т.е. и свободу отняли и безопасности не завезли.
А зачем выеживаться ? Скользкие аппаратно-зависимые вещи проще (и переносимее) закодить на ассемблере. А заниматься на2.17ыванием компилятора синтаксическим сахаром конечно можно, но аргументировать это аргументом "гибкость" как-то язык не поворачивается.
Одни обезьяны не могут нормально в своем коде ссылки считать, другие явно и неявно типы где нельзя но очень хочется приводят. У первых потом от чудо решений программа память жрет как слон веники, что лучше бы ресурсами текла, вторые себе в ногу стреляют.
Дисциплины программирования и проектирования нету в итоге ни там ни здесь.
> "Тот кто жертвует свободой ради «безопасности» в итоге не получает ни того ни другого" ©Обратное тоже верно. ©
Подскажите, кто в теме. Вот безопасное управление памятью я ещё представляю без gc и runtime. Concurrency я ещё представляю без рантайма, но как без него может работать параллельность (многопоточность) кода?
А в чем видится проблема?
В невозможности без рантайма организовать green threads. То бишь придется ограничится потоками и процессами ОС. Хотя это как раз к concurrency, а не к распараллеливанию.
вы неправильно понимаете что имеют ввиду под runtime в новости. Имеется в виду что это базовая возможность языка.
А может стоит пользоваться общепринятым значением термина, а не изобретать своё?
Это вопрос к автору новости. Либо читайте оригинал.
Да, именно в этом.
Из новости в новость пишется о высоком распараллеливании без рантайма. Как это работает?
Напомню, что concurrency совсем не параллельность. А то, что разные горутины могут выполнятся одновременно - это заслуга операционной системы.
> А то, что разные горутины могут выполнятся одновременно - это заслуга операционной системы.Ну тогда уже это заслуга не ОС, а наличия нескольких процессоров и/или нескольких полноценных(не hyperthreading) ядер в одном процессоре.
>>>> Concurrency я ещё представляю без рантайма
>>> А в чем видится проблема?
>> В невозможности без рантайма организовать green threads.
> Напомню, что concurrency совсем не параллельность.Ребята, я вас не понимаю. Green threads - это как раз реализация concurrency и есть. Как вы его представляете без рантайма? Обязательно должен быть менеджер зелёных тредов в процессе.
Я как бы об этом и сказал.
> Я как бы об этом и сказал.Да я адресовл это вообще-то к анониму #6 и #16
>>>>> Concurrency я ещё представляю без рантайма
>>>> А в чем видится проблема?
>>> В невозможности без рантайма организовать green threads.
>> Напомню, что concurrency совсем не параллельность.
> Ребята, я вас не понимаю. Green threads - это как раз реализация
> concurrency и есть. Как вы его представляете без рантайма?
> Обязательно должен быть менеджер зелёных тредов в процессе.Я не использовал термином green threads т.к. не знаю его, я подумал, что товарищ понял мой вопрос и согласился с ним.
Возможно я чего-то недопонимаю. В Rust новостях пишут о высокой возможности распараллеливания без рантайма. Еще раз говорю, concurency - это далеко не параллельность. То, что, скажем, golang несколько go-рутин вешает в разные потоки ОС и по факту они работают параллельно - это заслуга runtime golang. Без рантайм я могу себе представит просто concurrency, но без него не могу понять параллельность (многопоточность) - то, о чем пишется в каждой новости.
Давайте тогда уж использовать полностью русские термины.
concurency - конкурентность, когда поток(нить) один и задачи конкурируют между собой за доступ к нему. Всегда должен быть планировщик который будет разруливать кто сейчас работает.
Multithreading - паралельность, когда много потоков, один поток одна задача. Планировщик встроен в ОС.>> то, о чем пишется в каждой новости.
на заборе тоже пишут, надеюсь мысль ясна.
И что из этого есть в Расте?
Параллелизм это физическое одновременное исполнение кода на разных процессорах или ядрах. Он не является неотъемлемым свойством ЯП или даже ОС. Если у нас физически один процессор с одним ядром, то никакие действия со стороны ОС или ЯП не позволят параллельное исполнение. С другой стороны при наличии физической возможности, но без поддержки со стороны ЯП можно получить параллельное исполнение кода за счет запуска нескольких его экземпляров. Хотя тут уже небольшая поддержка нужна со стороны ОС, она должна уметь использовать более одного ядра/процессора и раскидывать по ним процессы. Для параллелизма runtime не нужен.Concurency это модель написания программы. Она может быть реализована по разному. И вот для реализации ее в виде green threads(goroutines, erlang processes итд) уже нужен runtime(специальный код, добавляемый компилятором к основному коду программы для реализации определенных фич).
> Concurency это модель написания программы. Она может быть реализована по разному. И
> вот для реализации ее в виде green threads(goroutines, erlang processes итд)
> уже нужен runtime(специальный код, добавляемый компилятором к основному коду программы
> для реализации определенных фич).Согласен, вот только хочу уточнить, что не обязательно компилятором. Зелёные треды вполне могут быть реализованы в виде модуля. Не знаю, может, это подразумевалось, но всё-таки обычно лучше, если очевидные вещи произнесены.
> green threadsКстати, green threads - это, насколько мне известно, явовский термин. Не подскажете, как называют зелёные треды в других языках программирования? Есть общее слово?
это просто название абстракции. green threads, coroutines, fibers, goroutines. Суть одна это event loop.
Под event loop обычно имеется ввиду совсем другая техника.
Ну вот давайте процитирую из главной gevent.
"gevent is a coroutine -based Python networking library that uses greenlet to provide a high-level synchronous API on top of the libev event loop."
И что? То, что какая-то либа в питоне одно маскирует под другое, как то меняет, что event loop это другая техника?
Ну и отлично. Опять в интернете кто то неправ.
> Кстати, green threads - это, насколько мне известно, явовский термин.Нет.
Термин (как ссылка на реализацию) означает "как-бы нити без поддержки (или без использования поддержки) нитей в операционной системе". Реализация сводится к сохранению/восстановлению контекста процесса (setjmp/longjmp calls) или, более современная, но основанная на тех же setjmp/longjmp --- makecontext/getcontext/setcontext.
Реализация сама по себе очень стрёмная --- очень легко разнести себе стек без шансов понять что и откуда произошло.
Зелёные нити проталкивались GNU во времена, когда Линус считал нити полной херьнёй и не собирался их реализовывать. Впрочем, во многих операционках нитей тогда тоже не было.
Начальная идея, по всей видимости, происходила от Sun Microsystems.Видимо поэтому они и попали в Яву --- дабы не зависеть от наличия нитей в операционке.
> В невозможности без рантайма организовать green threads. То бишь придется ограничится потоками
> и процессами ОС. Хотя это как раз к concurrency, а не
> к распараллеливанию.А кто сказал что оно green threads делает?
Грин или не грин, по-моему, не важно совсем. Псевдо-потоки нужны для тех сред, которым нужно минимально с ОС взаимодействовать (той же Яве). Вот просто по концепции. Это их "фича". А коль такой задачи не стоит, то просто компилятор может некую предложенную на уровне грамматики языка конструкцию переделать в фактическую конструкцию целевой среды исполнения (где-то процессов ОС налепить, где-то потоков в процессе ОС). Вроде так.
Действительно, как отмечали выше, runtime в Rust есть, но он легковесный и опциональный (ОС же пишут на Rust).Что касается многопоточности и конкурентного доступа к данным - то тут действительно нужен runtime. Например, он отвечает за работу механизма std::sync::Arc - atomic reference counter.
printf в си является runtime?
нет, но работать без runtime-а не будет т.к. ввод/вывод.
Следуя вашей логике, функции из сторонних библиотек не являются runtime, а что мы получим если программа не сможет найти эту функцию в библиотеке? сделали call, а там не правильный адрес.
В моём грубом понимании runtime - это только тот код, который компилятор добавляет к программам для обеспечения работы синтаксических конструкций языка. Всё остальное может зависеть от рантайма, как, например, функции работы с вводом/выводом, а может не зависеть, как большинство математических функций.
В случае си часть рантайма реализована в crt0.o (https://en.wikipedia.org/wiki/Crt0) - если интересно.Что касается "не сможет найти эту функцию в библиотеке" - если функциям для работы требуется runtime, это ещё не значит что они его часть. И вообще, если библиотека статическая - runtime для поиска функций не нужен.
да, все так. Я просто не особо слежу за растом и хотелось понять, понимает ли собеседник о чем говорит.
> Следуя вашей логике, функции из сторонних библиотек не являются runtime, а что
> мы получим если программа не сможет найти эту функцию в библиотеке?
> сделали call, а там не правильный адрес.Получим невозможность использовать эту функцию и вероятно эту отдельную программу. Отдельная программа может нуждаться в специфическом runtime...
Они бы еще параллельно инструменты развивали. Например Qt Creator заточить, добавить в него подсветку синтаксиса и доки. Servo конечно хорош как доказательство состоятельности языка (будет, если допилят), но без нормальных инструментов язык не взлетит.
Qt пусть допилят обещанный PySide2 лучше, чем распыляться на это
Python признан неисправимым тормозом. Все потихоньку переходят на Go. Инвестировать в заведомо умирающую технологию - очень глупый шаг.
Все потихоньку переходят на Go <=> Инвестировать в заведомо умирающую технологию - очень глупый шаг.
Вы сами себе противоречите.
А ещё вы себе противоречите сравнивая разные сферы. Вы ещё HTML и Go по скорости сравните. Причём только по скорости, а читаемость, гибкость и прочее игнорируете конечно же
Для скорости есть C/C++, которые и пытается подменить Go, но я всё ещё не вижу, чем он лучше уже знакомых и выпиленных до блеска инструментов.
> Для скорости есть C/C++, которые и пытается подменить Go, но я всё
> ещё не вижу, чем он лучше уже знакомых и выпиленных до блеска инструментов.Писать и читать код на Go практически также легко как на python. Писать на нем конкурентный код проще чем на python и тем более на C/C++. А скорость лишь немного уступает плюсам и значительно обходит python.
Справедливости ради, Go медленнее даже чем java, ибо компилятор и VM последней совершенствовалась очень много лет. Компилятор Go пока не обладает инструментами оптимизации. Взамен нам предлагают скорость самой компиляции, она практически мгновенна. Надеюсь, в будущем будут варианты на выбор
Ну давай посмотрим на циферки:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
В четырех случаях быстрее java, в шести - go. Во всех случаях go потребляет значительно меньше памяти.
NumPy, SciPy, Matplotlib уже переводят на Go?
Делают аналоги, с разной степенью успешности. А ви таки зачем спрашиваете? :)
> NumPy, SciPy, Matplotlib уже переводят на Go?А ты считаешь, что там скорость является заслугой питона? Разочарую, скорость там от С и Fortran, а от питона лишь обвязка над либами blas, lapack итд. При этом как только тебе в задаче понадобятся вычисления за пределами реализованных в либах функций, то скорость резко падает.
> Python признан неисправимым тормозом. Все потихоньку переходят на Go. Инвестировать в заведомо
> умирающую технологию - очень глупый шаг.Ядра предпочитают делать на С/C++, обвязки - на Python или C#, бизнес-логику и БД - на Java.
> Qt пусть допилят обещанный PySide2 лучше, чем распыляться на этоВы не поняли. Это не проблема Qt, это целиком проблема раста.
У Qt нет проблемы отсутствия фреймворка или отсуствия языка(ов) :)))
Есть https://github.com/phildawes/racer, который можно использовать в плагинах к редактору.
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!() }
Прежде чем понять код ПО нужно расшифровать стопицот ненужных аббревиатур. write отрицает аргументы?
println... тяжёлое детство, деревянный паскаль...
let we_dont_use_camel_case
Опять же зачем нужен let и затем указывать тип, если можно сразу указать тип и код будет более читаемый и компактный.>> It's possible to declare variable bindings first, and initialize them later.
Вообще вещь стрёмная и ненужная.
Короче куда ни ткни, непонятно чем этот ЯП лучше тех, которые давно и надёжно засели в TOP10 и почему все вокруг него так трясутся. Даже Go на его фоне смотрится лучше
> Даже Go на его фоне смотрится лучшеЧто значит "Даже"? Golang - великолепен.
Чем?
Почти всем :)
Тут проще перечислить недостатки: размер бинаря, проблемное взаимодействия с Сишными либами, отсутствие прямого контроля за горутинами.
> Тут проще перечислить недостатки: размер бинаря, проблемное взаимодействия с Сишными либамиВас почитать, так становится непонятно, почему Go более популярен по сравнению с тем же OCaml. :)
Я перечислил недостатки, а не преимущества. Даже если у ocaml не было бы недостатков, это не означало бы, что у него достаточно преимуществ.Ну и конечно нельзя недооценивать фактор поддержки корпорацией.
> Ну и конечно нельзя недооценивать фактор поддержки корпорацией.Ну да. В это всё как правило и упирается. Большая корпорация анонсирует новый язык, стимулирует людей на него переходить, нанимая объёмистый штат людей, заинтересованных в нём. Его начинают перенимать к себе другие крупные компании... Постепенно наращивается критическая масса специалистов в данном конкретном языке, и наконец малому и среднему бизнесу становится выгодно вести разработку именно на них, ибо для него важнее всего - заменяемость работника. А они появляется тогда, когда на рынке много специалистов.
Иными словами, языки, технологии и программные продукты чаще выстреливают не за счёт технического превосходства, а за счёт поддержки со стороны больших корпораций.
http://www.dedoimedo.com/computers/software-development-canc...Хорошая статья попалась, как раз.
> http://www.dedoimedo.com/computers/software-development-canc...
> Хорошая статья попалась, как раз.Очень благодарен. Утащил в коллекцию.
"Большие корпорации" обеспечивают то, чего катастрофически не хватает энтузиастам. Время. Т.е. масштабный проект можно успеть реализовать до того, как он морально устареет, а его разработчики выйдут на пенсию. Для того чтобы ЯП "взлетел" ему нужна куча прикладных библиотек, масса публикаций, удобные IDE и хорошая информационная поддержка, понижающая уровень входа для начинающих. Тогда формируется большое комьюнити. Основная мотивация подавляющего большинства программистов, начинающих изучение нового ЯП - это перспективность его применения в будущем с целью использования его для зарабатывания денег. И лишь единицы выбирают ЯП как оптимальное средство решения конкретной задачи. Поэтому в форумах и идет нескончаемый холивар сторонников заколачивать гвозди микроскопом с сторонниками ремонтировать часы кувалдой.
Мне непонятно, поэтому я и спрашиваю. Иначе не спрашивал бы. Вроде всё логично
... отсутствием генериков, убогостью кастомных типов, error'ом(!) при неиспользуемой(!) переменной, хипстоватым сообществом... Вы продолжайте, продолжайте.
Вообще интересно, чем люди мотивируются, создавая кучу костылей в каждом "новом великолепном ЯП". Они как бы забывают, что ЯП вообще делаются не для машин, а для людей. Конечно гибкость инструмента хочется иметь максимальную, но это не должно идти в ущерб читаемости кода и скорости разработки. Языков программирования уже создавалось вагон и маленькая тележка на волне хайпа "вау, компы приходят в жизнь простых смертных!". Из них выкристаллизовались самые удачные в соотношении читаемости/гибкости, стали классикой, заняли свой честный TOP10, на их основе соответственно сформировались огромные комьюнити, написано масса документации, их изучают в ВУЗах. И тут приходит контора и такая "Мы решили что во всех наших ошибках виноват ЯП, мы запилим свой и будем совать его во все места, мы ж корпорация бобра, мы могём". А потом выясняется, что "во все места" только воткнуты "// TODO(user_name): implement this", в итоге работают только какие-то примитивы, документацию найти фиг, структура библиотеки не позволяет на бегу исправить архитектурный косяк
Да не стесняйся ты так, скажи открыто: "мне лень понимать и учить новые ЯП".
TOP10 ЯП сегодня и TOP10 10/20/30/40/50 лет назад мягко говоря различаются. А с твоим подходом надо было остановится еще в 60-х.
А что "новые языки" это какая-то самостоятельная ценность и их обязательно все учить ?
Нет, необязательно. Можно было выучить Fortran 60 лет назад или APL 50 лет назад и программировать на них по сей день.
В текущих реалиях можно выучить пару основных для десктопа, и php/python, html+js+css для веба, и ещё останется лет на 30 что в процессе разработки продуктов по мере появления доп. вопросов (от code style, тестовых фреймворков и инструментария аля IDE, нужных API, до всяких RFC, алгоритмов подавления шумов и специфики железа). И этого будет достаточно чтобы учиться постоянно и не скучать по фортрану.
> В текущих реалиях можно выучить пару основных для десктопа, и php/python, html+js+css
> для веба, и ещё останется лет на 30 что в процессеЗадним умом мы конечно все крепки, но только вот 20 лет назад в основных для десктопа, вполне возможно мог быть дельфи, вместо пыха или питона - перловочка, а JS c CSS были забавными, но маргинальными новинками.
Согласен. Добавлю, что через пять лет может оказаться, что js и css все-таки не способны удовлетворительно решить большинство задач и индустрия вернеттся к идее написания под веб на других ЯП с последующей трансляцией в webassembly или еще что-то. И все js и css фреймворки разом отправятся на свалку истории.
> в основных для десктопа, вполне возможно мог быть дельфи, вместо пыха или питона - перловочкаИ мы ничего бы не прогадали!
> JS c CSS были забавными, но маргинальными новинками
CSS в котором десять только основных рецептов центрирования блока, и еще костыли в отдельных случаях.
> Да не стесняйся ты так, скажи открыто: "мне лень понимать и учить
> новые ЯП".
> TOP10 ЯП сегодня и TOP10 10/20/30/40/50 лет назад мягко говоря различаются. А
> с твоим подходом надо было остановится еще в 60-х.Мне лень начинать каждые 2 года с джуниора (с соответсвующей зарплатой) ради языка, который ещё через 2 года загнётся (в лучшем случае в честь нового стартапчика того же гугла, в худшем - просто загнётся).
По топам: за 10 лет не сильно они изменились, потому что индустрия сформировалась более-менее со всеми её требованиями (как в части десктопа, контроллеров и мобильных, так и в части веба) и более правильный подход нынче - не пилить на каждый чих с нуля какую-то ересь, а обоснованно дорабатывать уже имеющиеся средства, если необходимость реально есть.
Я не могу относиться к этим стартапчикам серьёзно, когда там элементарные вещи либо не работают, либо работают только у разработчика оного опуса, либо сделаны ещё хуже чем в софте сделанном 20 лет назад, например из golang-гугльгруппы
>> Also, make sure you do not put spaces between directories listed in the path variable.Шёл 2017-ый год...
> Да не стесняйся ты так, скажи открыто: "мне лень понимать и учить новые ЯП".
> TOP10 ЯП сегодня и TOP10 10/20/30/40/50 лет назад мягко говоря различаются.
> А с твоим подходом надо было остановится еще в 60-х.Ну знаете ли. Этих новых языков в последнее время попёрло столько, что нет ни времени, ни сил на них на все. :)
К тому же, разработка нового языка - задача не такая уж сложная. Берёшь flex+bison (или если не на Си пишешь, но соответствующую своему языку связку lex/yacc), определяешь грамматику и синтаксис - и готово. Таким образом начать разработку нового языка - дело в общем-то плёвое. Вот их и расплодилось столько.
Другое дело, что потом наступает долгая и ответственная фаза оптимизации производительности и вылизывания генерируемого компилятором кода. Она может затянуться на годы. К тому же, языку нужна коллекция стандартных библиотек, что тоже займёт порядочное время.
В общем, я не знаю, когда вылижут Rust, но для начала надо дождаться хотя бы нескольких больших FOSS-проектов, написанных на нём. А кидаться учить все новинки, особенно с учётом лёгкости их появления - дело гиблое. Пусть сначала зарекомендуют себя хорошо.
> Ну знаете ли. Этих новых языков в последнее время попёрло столько, что
> нет ни времени, ни сил на них на все. :)Да не больше, чем в иные времена. И никто не говорит про полноценно учить всё подряд. Но если какой-то язык из года в год увеличивает свою долю, то можно потратить одни выходные на базовое ознакомление, вдруг понравится.
> Берёшь flex+bison (или если не на Си пишешь, но соответствующую своему языку связку lex/yacc), определяешь грамматику и синтаксис - и готово. Таким образом начать разработку нового языка - дело в общем-то плёвое. Вот их и расплодилось столько.
Ты бы хоть поинтересовался в каком году появился yacc.
>> Ну знаете ли. Этих новых языков в последнее время попёрло столько, что
>> нет ни времени, ни сил на них на все. :)
> Да не больше, чем в иные времена. И никто не говорит про
> полноценно учить всё подряд. Но если какой-то язык из года в
> год увеличивает свою долю, то можно потратить одни выходные на базовое
> ознакомление, вдруг понравится.Я думаю, лучше это делать по мере необходимости. Вот пользуешься ты программой, захотел доработать и отправить фикс - вот тогда и ознакомился с языком, на котором она написана. Это подход практического императива, и он часто себя оправдывает.
>> Берёшь flex+bison (или если не на Си пишешь, но соответствующую своему языку связку lex/yacc), определяешь грамматику и синтаксис - и готово. Таким образом начать разработку нового языка - дело в общем-то плёвое. Вот их и расплодилось столько.
> Ты бы хоть поинтересовался в каком году появился yacc.Какое же это имеет значение? Я ж не про утилиту yacc, а про класс ПО, к которому в частности относятся такие вещи, как bison, ocamlyacc, menhir.
Я к тому, что написание парсеров за счет существования lex/yacc и аналогов стало простой задачей не пять, не десять и даже не двадцать лет назад. А ты привел их существование как одну из причин появления множества новых ЯП в последнее время. На мой же взгляд появление новых ЯП почти никак не связано с легкостью их первичной реализации. Новые ЯП появляются во множестве, когда набирается достаточно много новых задач, которые старые ЯП решают неудовлетворительно. Потом идет период стабильности, а потом развитие технологий создает новые проблемы и как следствие провоцирует создание новых ЯП.
> А ты привел их существование как одну из причин появления множества новых ЯП в последнее время.Не совсем. Я лишь пояснял, почему их пишут все, кому не лень. Я понятья не имею, почему в последнее время их стало появляться особенно много.
> На мой же взгляд появление новых ЯП почти никак не связано с легкостью их первичной реализации.
> Новые ЯП появляются во множестве, когда набирается достаточно много новых задач, которые старые ЯП решают неудовлетворительно.Ну да, ну да. Perl5 "неудовлетворительно" решал задачи динамической генерации web-страниц, а PHP был "венцом" инженерной мысли.
> Потом идет период стабильности, а потом развитие технологий создает новые проблемы и как следствие провоцирует создание новых ЯП.
Интересное мнение, но я такого не наблюдаю. Ваше рассуждение подразумевает, что график развития технологий монотонно возрастает со временем. Тем не менее, мы можем наблюдать заметные спады время от времени.
Поясняю примером: в 60х были разработаны первые версии Lisp. Их потыркали в продакшене и бросили. Хотя по выразительной силе они и сейчас превосходят все прочие языки. В начале 90х было дано начало ML-подобным языкам, предоставляющим ни с чем не сравнимую систему вывода типов. ML-и в продакшен тоже пошли слабо.
А что в продакшен пошло? Да хоть та же ява, которая появилась в середине девяностых и была медленным интерпретируемым языком с си-подобным синтаксисом и ООП без множественного наследования. Не самая лучшая затея. Не понятно для чего нужная. Её пилили много лет, не зная, куда её пристроить. Пытались и гуёвые приложения, которые получили малое распространение из-за тормозов и непомерно большого рантайма, пытались внедрять её в качестве плагинов для браузеров, да не тоже не вышло. Много лет прошло прежде, чем она заняла свою нишу серверных приложений.
И в основном продакшен вместо того, чтобы развивать действительно мощные новые технологии, развивает популярные старые. Ну взяли старый модный язык, слегка улучшили, получилось новое, решило часть старых проблем, о большем никто и не просит: все в восторге, все бегут в новую пустующую сферу рынка труда.
Суть в том, что языки лепят все, кому не лень. В большом количестве и каждый божий день. Потому что это реально просто. А вот какой из языков станет популярным, или какой из них окажется хорошим - вот это совершенно не понятно. Популярность и качество - вещи не совсем коррелирующие. А языков со временем становится всё больше, и появляться они начинают, кажется, гораздо чаще. Вот к чему я писал всё это.
>>Ну да, ну да. Perl5 "неудовлетворительно" решал задачи динамической генерации web-страниц, а PHP был "венцом" инженерной мысли.а всё дело в том, что чем дальше тем меньше кода будут писать, и будущему поколению просто в лом писать это всё, если в ЯП (точнее в стдлиб ЯП) нет того функционала который допустим нужен для веб страничек - это плохой ЯП для веба, на нём бабла быстро не срубишь. Кто пишет на асм веб странички - тот дурак.
>>PHP "венец" инженерной мысли
уже не найти разработчика который бы писал с нуля какой нить форумный движок, всем подавай ларавелы, ЙИИ, кодигнайтеры, "чур меня чур" писать на плейн пхп движок. И всем до лампочки, что вконтакте выпилило "ООПешное Г" из пхп и запили всё в процедурном стиле.
> Ну да, ну да. Perl5 "неудовлетворительно" решал задачи динамической генерации web-страниц,
> а PHP был "венцом" инженерной мысли.Практически так и было. Код на perl времен cgi.pm(и тогда это еще был очень хороший вариант) и современный различаются как небо и земля. По сравнению с ним PHP со всеми его родовыми травмами действительно был шагом вперед.
> Интересное мнение, но я такого не наблюдаю. Ваше рассуждение подразумевает, что график
> развития технологий монотонно возрастает со временем. Тем не менее, мы можем
> наблюдать заметные спады время от времени.Нет, я говорил про цикличность в появлении новых ЯП, а не про монотонное возрастание.
>> Ну да, ну да. Perl5 "неудовлетворительно" решал задачи динамической генерации web-страниц,
>> а PHP был "венцом" инженерной мысли.
> Практически так и было. Код на perl времен cgi.pm(и тогда это еще
> был очень хороший вариант) и современный различаются как небо и земля.
> По сравнению с ним PHP со всеми его родовыми травмами действительно
> был шагом вперед.Современный - это какой? Perl5 несколько десятилетий был неизменен. Не вижу особой разницы.
>> Интересное мнение, но я такого не наблюдаю. Ваше рассуждение подразумевает, что график
>> развития технологий монотонно возрастает со временем. Тем не менее, мы можем
>> наблюдать заметные спады время от времени.
> Нет, я говорил про цикличность в появлении новых ЯП, а не про монотонное возрастание.Да нет. Судя по тому, что Вы написали, выглядит это как монотонное возрастание:
1) накопилось проблем, начинаем развивать технологию быстрее (резко вверх)
2) развили, осваиваем технологию, отлаживаем (медленно вверх)
3) отладили, поняли, что есть не решаемые проблемы -> возвращаемся к п.1
> Современный - это какой? Perl5 несколько десятилетий был неизменен. Не вижу особой разницы.Может потому, что ты не пишешь на нем сейчас и не писал тогда. Поэтому всё, что ты видишь, это мажорная циферка версии. А для меня он десять лет был основным ЯП, так что я вижу совсем другую картину.
> Да нет. Судя по тому, что Вы написали, выглядит это как монотонное
> возрастание:
> 1) накопилось проблем, начинаем развивать технологию быстрее (резко вверх)
> 2) развили, осваиваем технологию, отлаживаем (медленно вверх)
> 3) отладили, поняли, что есть не решаемые проблемы -> возвращаемся к п.1А, в этом смысле. Да, всё именно так. Могут быть конечно небольшие флуктуации, но в целом идет развитие.
>> Современный - это какой? Perl5 несколько десятилетий был неизменен. Не вижу особой разницы.
> Может потому, что ты не пишешь на нем сейчас и не писал тогда.Нихт. Сейчас я на нём почти не пишу. Много писал как раз лет 8-10 тому назад.
> А, в этом смысле. Да, всё именно так. Могут быть конечно небольшие флуктуации, но в целом идет развитие.
А я как раз и пишу, что топовые технологии активно не развиваются, развиваются в основном среднячковые, которые лоббируются корпорациями. Ладно, проехали.
> В общем, я не знаю, когда вылижут Rust, но для начала надо
> дождаться хотя бы нескольких больших FOSS-проектов, написанных на нём.Без поддержки ТНК уровня фейсбука - никогда.
Но подобным организациям нужна прикладуха, существующие ядра/системные либы их полностью устраивают.Игроделы не будут переделывать популярные и отлаженные движки на вырвиглазную хрень без либ.
Руст - язык без ниши. Как системный, для игр и вычислений - он запоздал на 30 лет, как прикладной не состоятелен.
> Руст - язык без ниши. Как системный, для игр и вычислений -
> он запоздал на 30 лет, как прикладной не состоятелен.Почему же без ниши? У него есть вполне определённая ниша. Правда вот беда, она в точности совпадает с нишей, занятой C++. И чтобы его оттуда вытеснить, языку надо иметь очень много преимуществ. А у rust оно ровно одно — модель памяти. Сомневаюсь, что этого хватит, хотя — время покажет.
>>но это не должно идти в ущерб читаемости кода и скорости разработки.какой ещё скорости разработки? что это за понятие "быстро разработать"? писать строки кода (кодинг) это разве разработка?
>>>но это не должно идти в ущерб читаемости кода и скорости разработки.
> какой ещё скорости разработки? что это за понятие "быстро разработать"? писать строки
> кода (кодинг) это разве разработка?На С++ програмист напишет сложную систему медленней, чем на Java, #C, Python, Ruby.
На уровне одной формы/мелкой утилиты разницы никакой. Чем сложней программа - тем больше будет разница.
Rust не дает преимуществ перед С++, наоборот усложняет нечитабельностью.Это факт. Зачем Вы хотите отрицать очевидное?
>>На С++ програмист напишет сложную систему медленней, чем на Java.Проектировать ПО и писать код - разные задачи. И сей факт в том, что время тратися в основном на проектирование (обдумывании всего функционала, или конкретно алгоритма). Вы же не напишите код если не спроектируете заранее.
>>На уровне одной формы/мелкой утилиты разницы никакой.какая разница на каком ЯП написан алгоритм, он будет выполнять ровно то, на что он задуман.
>>Чем сложней программа - тем больше будет разница.
ну конечно, война и мир на русском будет содержать 1к страниц, а на китайских иероглифах 10к страниц - и что? нужно отказаться от китайского, китайских хуже русского?
К примеру определение функции в одиних ЯП пишем function function_name(x) в других func name(x), в-третьих f name(x), name(x) в итоге (x) и т.д. - и что разница только в количестве нажатий на клавиши при наборе текста кода, ЭТО РАЗВЕ ПОКАЗАТЕЛЬ "БЫСТРОТЫ" РАЗРАБОТКИ ПО?
>>Rust не дает преимуществ перед С++
преимущества в этом случае оценивается только лишь в машинных кодах, в потребление процессорного времени (скорость выполнения), в потреблении памяти и т.д. (не забываем про сложность алгоритмов О-большое), на сколько эффективно генерируется конечный код (при этом не забываем про различия компиляции, интерпретации, трансляции и т.д.).
>>наоборот усложняет нечитабельностью.
Не читабельность это самый "нубский" аргумент, конечно для русскоязычного китайский будет не читабелен пока он его не выучит, всё упирается в то, на сколько хорошо вы знаете ЯП. В первом классе вы же тоже читали по слогам предложения, а сейчас?
>>Это факт. Зачем Вы хотите отрицать очевидное?
Ничего я не хочу отрицать, для себя я сделал очевидный вывод (моё мнение), что все эти ЯП - не нужны, есть машинные коды и есть вполне "читабельный" транслятор (ага АСМ). А холивары на тему ЯП будут всегда, разработка ПО давно уже из науки перевалилась в сруб бабла, и подчиняется закону бабла - "время деньги", чем "быстрей" вы напишите на какомто лэго ЯП программу тем быстрей получите своё бабло.
> Не читабельность это самый "нубский" аргумент, конечно для русскоязычного китайский будет
> не читабелен пока он его не выучит, всё упирается в то,
> на сколько хорошо вы знаете ЯП. В первом классе вы же
> тоже читали по слогам предложения, а сейчас?Большую часть времени разработчик не стучит по кнопкам, а именно читает код и думает, читает документацию и думает, читает. Очевидно что читать то, что написано на нормальном языке, нормальным стилем, гораздо легче и приятнее, чем э слыш чотенька тут вот а тут так там тыгыдым акошка мне запили хопа гангнамстайл (далее 50 экранов страниц сплошной портянки из однобуквенных переменных, двухбуквенных функций и одной строкой, это любители JS "оптимизировали" весь исходник). А нктрые думт чт мжн ещ тк скрщт прдлжн чтб мнш псть. И без межстрочных интервалов, вот прям весь код одной портянкой, а лучше чтобы строки друг на друга залезали - ТАК ЖЕ БОЛЬШЕ ВЛЕЗАЕТ НА ЭКРАН!
И таких вредных советов - вагон и маленькая тележка. Но зачем их использовать как руководство к действию?
Для любителей чтива, приближенного к одному из естесственных языков, придумали COBOL. Его конечно ругают очень-очень сильно, но пока си пытается указателем в указатель на переменную попасть, COBOL рулит транзакциями на миллиарды.
>>Очевидно что читать то, что написано на нормальном языке, нормальным стилем, гораздо легче и приятнее, чем э слыш чотенька тут вот а тут так там тыгыдым акошка мне запили хопа гангнамстайлвот к этому я и вёл ))) слеш точка запятая - китайская грамота, русскому не понять если он её не изучит как родной язык.
>>(далее 50 экранов страниц сплошной портянки из однобуквенных переменных, двухбуквенных функций и одной строкой, это любители JS "оптимизировали" весь исходник)
.min.js )))) а что вы хотели ? я просто не понял вы сторонник (x) или function function_name(argument x)? Лично для меня без разницы, итог один (в опкодах) в принципе.
>>а именно читает код и думает, читает документацию и думает, читает.1) время на чтение + время на "думает" + опять время на чтение = быстрая разработка.
вывод: человек должен уметь быстро читать, быстро думать, и повторно быстро читать (избыточностью попахивает) - то он быстро разработает ПО, и ЯП тут как видимо ни какой роли не играет.
2) хорошо второй юзкейс:
человек читает по слогам + человек тугодум + человеку лень повторно читать по слогам = ну очень медленная разработка
вывод: такому разработчику ПО нужен такой "быстрый ЯП", где не нужно читать, думать и повторно читать.
>> 1) время на чтение + время на "думает" + опять время на чтение = быстрая разработка.
>> вывод: человек должен уметь быстро читать, быстро думать, и повторно быстро читать (избыточностью попахивает) - то он быстро разработает ПО, и ЯП тут как видимо ни какой роли не играет.Чтобы быстро думать - не должно ничего отвлекать. Ты не должен спотыкаться на каждом чихе и думать "почему тут изобрели какой-то велосипед, которого нет у остальных для решения вполне канонической задачи?". Языковые правила, в том числе правила китайского языка, формировались сотни, а то и тысячи лет, в процессе развития коммуникации между людьми. И "шмяк-шмяк мы тут на коленке за пол часа придумаем новый язык, а вы просто выучите его" - не прокатит. Нельзя писать 95% на C++, а потом по щелчку пальца (т.е. мгновенно) переключиться на какой-нибудь SP-Forth или брейнфак и продолжить разработку как ни в чём не бывало, даже при условии что ты и то, и то знаешь /* тут стоит принять тот факт, что шизофреники могут, как могут и в уме сумасшедшие числа считать, но врядли стоит брать это за самоцель */
И тут ещё стоит принять во внимание тот факт, что китайский как бы не часто становится базовым для сфер в которых нужно быстро и ёмко описывать алгоритм. Как впрочем и русский. А вот английский (который из всех выбранных самый упрощённый, в т.ч. по историческим причинам) оказался как раз кстати /* вот тут конечно за державу обидно, но как есть */.
На эту тему интересный опус был у Фейнмана, он сначала тоже для записи формул и рассчётов использовал "свою нотацию", но потом вдруг выяснилось, что надо ещё и с людьми общаться хотя бы иногда.
> я просто не понял вы сторонник (x) или function function_name(argument x)? Лично для меня без разницы, итог один (в опкодах) в принципе.- для стиля xyz - должен быть комментарий (Y - квартальное начисление по % от косвенной условной задолженности...), чтобы код оставался сопроводжаемым.
В стиле function_name(argument x) - большинство комментариев оказываются избыточными и код в целом получается КОРОЧЕ и читабельней (не нужно искать определение x и комментарий над ним). Внезапно :)
>>- для стиля xyz - должен быть комментарий
>>В стиле function_name(argument x) - большинство комментариев оказываются избыточныминет я не это имел ввиду, акцент на обьявлении функции, а не её имени. Суть в синтаксической конструкции языка - что правильней обьявлять function, fun, def, или просто что-то на подобии (x) ->. Разница, как я уже говорил, в количестве символов, и если мы говорим о так называемой "быстрой разработке", то вариант (x) -> с таким синтаксисом ЯП довольно короткий и быстро вводится, но как заметили он якобы не читаемый, конечно не читаемый тому кто не "в теме", тому кто не знает синтаксиса ЯП. И возникает вопрос, а нужна ли эта "самодостаточность" new function definition f(x) { } которую человек "не в теме" спокойно прочтёт и поймёт в чём суть или "лаконичная" (x) -> - коротко и ясно тому кто "в теме".
Опять таки если всё сводить к "самодостаточности (само за себя говорящее)", то существовал бы всего один ЯП.
пс: Я был бы только рад этому одному "самодостаточному (самоописывающему синтаксис)" ЯП.
пс2: По поводу коментариев, они скорее нужны для описания алгоритма, а не описания какой символ на какой заменили. Внизу в коменте http://www.opennet.me/openforum/vsluhforumID3/110728.html#129 я привёл код функции и закрасил её имя, нужно определить что эта функция выполняет. По имени достаточно легко можно было бы понять для чего она предназначена. А по алгоритму трудно тому кто "не в теме". И тут конечно не только имя играет роль у функции ну и сопровождающий коментарий описывающий алгоритм этой функции.
Правильно объявлять function или func, если вы хотите функцию, а не класс, объект или ещё стопицот вариантов синтаксического сахара, не (x) и тем более не fun. Если вы хотите фана, то вам конечно без разницы на чём писать. А если чтобы работало, было читаемо, сопровождаемо и вообще не стыдно было показать, то нужно чтобы намерение было чётко задекларировано. Все эти огрызки и экономия на спичках - зло. Сиди потом, гадай, fn - это function или filename, или ещё что-то. Например, если нужно быстро найти функцию, но не помнишь точного её имени, внезапно все эти скобочки, косточки, звёздочки в ряд начинают мешать, а не помогать. Равно как и аббревиатуры, ты помнишь что оно в имени функции было что-то про перемножение, ищешь multiple, а потом выясняется что народ так "сэкономил оперативы и времени", что в коде оно mlt. И как бы автор каждого такого кастратика кричит "достаточно один раз выучить", но таких методов десятки в каждом классе, классов сотни, да ещё и проектов вагон и маленькая тележка и сводится всё к зубрению вместо понимания.
Код должен быть самодостаточный и наглядный. Тогда его можно реально показывать "людям не в теме" и они смогут сказать "вот тут у тебя ошибка в рассчётах". А если чтобы одну функцию понять и поправить нужно сначала пару томиков intro изучить и месяц хелловорлды грызть, то это фейл и конечно придётся вариться в собственном соку. И у меня такие случаи в жизни были, когда приходилось обсуждать алгоритм глядя на незнакомый (тогда ещё) язык.
Возьмите тот же SP-Forth, там как бы ничего сложного, "в тему" вникнуть легко - ложим всё на стек, потом выполняем нужные операции. Но вынос мозга на сколь нибудь большом и сложном коде я вам обещаю.
>>Правильно объявлять function или func,Без доказательное утверждение, замена одних символов на других - дело вкуса, и если даже заменяем, то заменяем в одно-однозначном отношении, без противоречий. Форма записи (x) может приводит к неоднозначному отношению. Поэтому, чтобы этого всего избегать нужно придумать синтаксис из конечных предложений типа
new function definition function_name_blabla(Argument X) {}
а не просто func blabla(x) в этом случае имя "неправильно подобранное" имя функции может ввести неоднозначное соответствие к её алгоритму. Поэтому добавил вначале префикс function_name_USER_DEFINED_FUNCTION_NAME. Вызов функции ранее обьявленной также -
call user defined function function_name_blabla(Argument X) и тд.
Но такой подход, как показывает практика "ленивых программистов", символьно избыточен.
>>Если вы хотите фана, то вам конечно без разницы на чём писать.Да, без разницы, потому-что итог должен быть один, оптимальный конечный машинный код.
>>А если чтобы работало, было читаемо, сопровождаемо и вообще не стыдно было показать, то нужно чтобы намерение было чётко задекларировано.Чтобы удовлетворить ваши критерии языка - ЯП должен быть фактически схож с естественным человеческим языком, но даже если так и будет, что мы обычными предложениями естественного языка писали алгоритмы, то не было бы на данный момент никаких проблем с машинным переводами. Но, что будет делать ЦП (центральный процессор) когда он встретит предложения антиномии (парадоксы)?
>>Код должен быть самодостаточный и наглядный.Опять утверждаете, но не то чтобы доказательств нет, пример банальный не приводите.
>>Тогда его можно реально показывать "людям не в теме" и они смогут сказать "вот тут у тебя ошибка в рассчётах".
Людям нужно показывать псевдо код, если мы ищем логические ошибки, а если показывать конкретно код на конкретном ЯП - то это только поможет найти синтаксические ошибки, которые за нас ищет сам ЯП (компилятор и т.д.). В математике тоже самое - есть формула достаточно короткая и под ней её полное доказательное описание на естественном языке, никто не пытается создавать самодостаточные формулы, а если это делать то мы придём к естественному языку.
>>"достаточно один раз выучить"
Выучить что? если есть одно-однозначное отношение между new function definition и func, то почему бы и нет ? Типичная символьная замена.
>>Возьмите тот же SP-Forth, там как бы ничего сложного, "в тему" вникнуть легко - ложим всё на стек, потом выполняем нужные операции. Но вынос мозга на сколь нибудь большом и сложном коде я вам обещаю.
Зачем должен быть вынос мозга если стоит задача разобрать код программы?
И плюс хорошей практикой является документирование кода, не просто коментарии к коду а именно документирование. Как в математике, когда пишется формула - то описываются все входящие в неё символы и какой смысл они носят.пс:
>>Сиди потом, гадай, fn - это function или filename, или ещё что-то.
не придётся гадать если есть описание этой замене символов. Вы в праве использовать как f, fn, fun, func, function и т.д., но дайте описание по использованию этих символов (сокращений) на естественном языке, ибо ваши замены ясны только лишь ЦП (ЯП), отсюда выводится очевидное, что код программы пишется для машины (хотя утверждают, что код должен писаться "понятным" для человека). Машина не способна понять естественный человеческий язык, хотя человек спокойно разберётся с любым языком предназначенным для машины (даже если он состоит из 0,1).
блин у комента кажись ограничение по длине текста хмммм
скока текста порезалось ((((((
Титеретик или тролль?
Ну реализуй любой готовый алгоритм на брейнфаке и сравни со временем его же реализации хотя бы на С.
> Титеретик или тролль?
> Ну реализуй любой готовый алгоритм на брейнфаке и сравни со временем его
> же реализации хотя бы на С.к чему это? к тому, что не смогу или "быстро написать" не получится?
Это яркий пример, иллюстрирующий ошибочность твоих разглагольствований о том, что проектирование занимает основное время и выбор ЯП почти не сказывается на времени написания программы. Конечно разница во времени между написанием программы на С и python будет не такой большой как в случае с brainfuck, но тем не менее она будет весьма существенной.
> Это яркий пример, иллюстрирующий ошибочность твоих разглагольствований о том, что проектирование занимает основное время и выбор ЯП почти не сказывается на времени написания программы.Время написания алгоритма во всех языках будет занимать одинаковое время, и это время будет в основном затрачено на "обмозговывание" алгоритма. Если вы будете уметь спокойно писать и читать как на русском так и на китайском, то вам не составит труда написать конкретное предложение.
>Конечно разница во времени между написанием программы на С
> и python будет не такой большой как в случае с brainfuck,
> но тем не менее она будет весьма существенной.Опять таки, вы щас сравнимаете "готовое", если у меня есть готовая функция (написанная до меня) на питоне, и таковой нет на си и которую я должен реализовать, то конечно со стороны выглядит, что на питоне я "быстрей" напишу. А если эта же функция уже "готова" на си, то разницы - ни какой. Но суть программирования не в "использовании готового". И ниже привёл вам пример функции косинуса угла. И не ужели никогда не появлялась мысль о том, а что там за cos(a) и у неё под капотом?
Таки титеретик. Причем случай крайне запущенный, если даже пример с brainfuck не заставил хоть чуть-чуть подумать.
тады уж на ТМ, брейнфак в сторонке курит
> тады уж на ТМ, брейнфак в сторонке куритдополнение: если про ТМ не в курсе
> Титеретик или тролль?static const double
one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
C1 = 4.16666666666666019037e-02, /* 0x3FA55555, 0x5555554C */
C2 = -1.38888888888741095749e-03, /* 0xBF56C16C, 0x16C15177 */
C3 = 2.48015872894767294178e-05, /* 0x3EFA01A0, 0x19CB1590 */
C4 = -2.75573143513906633035e-07, /* 0xBE927E4F, 0x809C52AD */
C5 = 2.08757232129817482790e-09, /* 0x3E21EE9E, 0xBDB4B1C4 */
C6 = -1.13596475577881948265e-11; /* 0xBDA8FAE9, 0xBE8838D4 */double
ЧТО_ЗА_ФУНКЦИЯ(double x, double y)
{
double hz,z,r,w;z = x*x;
w = z*z;
r = z*(C1+z*(C2+z*C3)) + w*w*(C4+z*(C5+z*C6));
hz = 0.5*z;
w = one-hz;
return w + (((one-w)-hz) + (z*r-x*y));
}
>> Титеретик или тролль?
> static const double
> one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
> C1 = 4.16666666666666019037e-02, /* 0x3FA55555, 0x5555554C */
> C2 = -1.38888888888741095749e-03, /* 0xBF56C16C, 0x16C15177 */- Хуже, преподаватель. Сам в реальных проектах не писал, не сопровождал, но имеет мнение и "опыт", хрен оспоришь :)
> - Хуже, преподаватель. Сам в реальных проектах не писал, не сопровождал, но
> имеет мнение и "опыт", хрен оспоришь :))))) ментор. Ждал этот аргумент ))
Давайте спросим у Д. Кнут-а сколько кода он написал ))) Суть программирование не в объёме кода. Вы можете в вотсапа написать килограммами текста за всю жизнь, но не напишите никогда Войну и мир, и возникает вопрос, если вы столько пишите в вотсапе, то почему вы не написали Отцы и дети и не считаетесь писателем?
пс: https://github.com/freebsd/freebsd/blob/386ddae58459341ec567...
о господи. Ну хорошо хоть в одном файле уместилась
> Давайте спросим у Д. Кнут-а сколько кода он написал )))Много.
)))
>> И сей факт в том, что время тратися в основном на проектирование.- На тестирование, отлаживание, сопровождение (многочисленные доработки по запросам). Внезапно. 90% объема работ.
Есть, конечно, категория архитекторов высокого полета - "напроектировал и сбежал", пока рутина не началась (из которой работа системы и состоит).
UML и ОО-скелет все равно на чем набросать, лишь бы в языке структуры/классы были, а они даже в ассемблере есть. Можно и на русте, не вопрос :)
> - На тестирование, отлаживание, сопровождение (многочисленные доработки по запросам).
> Внезапно. 90% объема работ.Внезапно до вас дошло, что синтаксис ЯП и его стдлиб никакой роли не играет.
>>Можно и на русте, не вопрос :)
Ну вотъ, ЯП значения не имеет.
>>>>но это не должно идти в ущерб читаемости кода и скорости разработки.
>> какой ещё скорости разработки? что это за понятие "быстро разработать"? писать строки
>> кода (кодинг) это разве разработка?
> На С++ програмист напишет сложную систему медленней, чем на Java, #C, Python,
> Ruby.
> На уровне одной формы/мелкой утилиты разницы никакой. Чем сложней программа - тем
> больше будет разница.
> Rust не дает преимуществ перед С++, наоборот усложняет нечитабельностью.
> Это факт. Зачем Вы хотите отрицать очевидное?На Питоне или Руби -- нет. У них нет даже зачаточных инструментов сборки и управления проектом. А на подобные процедуры уходи три четверти времени.
>[оверквотинг удален]
>>> какой ещё скорости разработки? что это за понятие "быстро разработать"? писать строки
>>> кода (кодинг) это разве разработка?
>> На С++ програмист напишет сложную систему медленней, чем на Java, #C, Python,
>> Ruby.
>> На уровне одной формы/мелкой утилиты разницы никакой. Чем сложней программа - тем
>> больше будет разница.
>> Rust не дает преимуществ перед С++, наоборот усложняет нечитабельностью.
>> Это факт. Зачем Вы хотите отрицать очевидное?
> На Питоне или Руби -- нет. У них нет даже зачаточных инструментов
> сборки и управления проектом.Потому что это своеобразный индикатор - как только появилась надобность в таких инструментах, значит, прототип слишком разжирел и пора писать нормальну версию.
Ну или кто-то использует ЯП не по назначению.
Зачем указывать тип, если переменная объявленная через let, как вы написали - будет константа. Не константы объявляются так let mut variable
Зачем константы называть variables в документации и делать иммутабельными из коробки?
Константность - только чтение. Мутабельность - чтение и запись. Т.е. любую переменную мы можем читать, а запись - это дополнительное свойство, которое и надо задавать. В С++ эта логика нарушена.
Как говорят знакомые атеисты: ОГОСПАДЕ!
Переменная (англ. Variable) имеет в основе слово МЕНЯТЬ. Логично что то что меняется не может быть иммутабельным. В противном случае говорят "документация врёт и не соответствует коду".
Прежде чем учить языки программирования, выучи хоть один человеческий, хотя бы на уровне базовой школы
ОГОСПАДЕ.
Филолог в треде о программировании. Зря ты ссылаешься на толковый словарь английского языка, надо было отследить этимологию глагола to vary назад к латыни и древнегреческому, и сослаться на то, что Сократ думал о мутабельных и константных переменных.
Переменная может быть константной и меняться. Тут вообще большое поле для демагогии. Но всё это будут придирки к словам. Факт остается фактом, объект должен быть читаем всегда, а вот изменяем нет.
Константа не может быть переменной. Это тавтология.Есть язык - интерфейс общения. Его ценность в том, что один объект однозначно и по возможности лаконично (чтобы быстро и эффективно) объяснить что-то другому объекту. Будет объяснять человек человеку, человек программе, программа человеку - не важно. Важно чтобы не было путаницы и неоднозначно понимаемых абстрактных бредней. И именно инженеры обязаны это понимать, у них масса технических терминов именно по этой причине. Ты же не называешь системный блок процессором? Ну пожалуйста, скажи что не называешь?
> Константа не может быть переменной. Это тавтология.Зато переменная может быть константНой или по-русски неизменяемой.
> Константа не может быть переменной. Это тавтология.Нет, это оксюморон.
> Как говорят знакомые атеисты: ОГОСПАДЕ!
> Переменная (англ. Variable) имеет в основе слово МЕНЯТЬ. Логично что то что
> меняется не может быть иммутабельным. В противном случае говорят "документация врёт
> и не соответствует коду".
> Прежде чем учить языки программирования, выучи хоть один человеческий, хотя бы на
> уровне базовой школыПонимаете, есть некая разница между логикой предикатов и логикой высказываний. В данном случае неизменяемая переменная -- честный полноценный предикат. Потому что это не константа и может быть задана непредсказуемо. Но вот измениться после такого, как задана, уже не может. И вы спокойно в таком случае пользуетесь аппаратом логики предикатов.
> Зачем константы называть variablesЭто в Си-подобных языках традиция такая. Многие языки семейств Lisp/Scheme/ML называют это дело binding, т.е. связыванием. Потому что они связывают текстовое имя (символ) с каким-то местом в памяти.
Константы и read-only переменные -- это разные вещи. Просто подумай об этом, и -- я верю в тебя -- ты увидишь разницу.
Про константы не я вбросил, я то знаю разницу
> Про константы не я вбросил, я то знаю разницуЧуть ниже видно было,
> это по сути read only переменная"знаток".
> Зачем константы называть variables в документации и делать иммутабельными из коробки?Помому что под const обычно подразумевается что-то, вычислямое еще на этапе компиляции. Еще, конкретно в ржавчине у const нет какого-то определенного адреса, он инлайнится. https://doc.rust-lang.org/book/const-and-static.html
А вот let может быть присвоена уже в рантайме, но только один раз. Типа
let foo = user_input_bar(...);
Ты удивишься, но константы инлайнились ещё во времена ассемблера.
Вот выше человек правильно написал - это по сути read only переменная, getter - очень распространённая вещь во многих языках.Короче печально всё, от понимания "зачем оно", до документации (и терминологии в частности).
> Ты удивишься, но константы инлайнились ещё во времена ассемблера.Ты удивишься, но я не удивлюсь - я в курсе.
Правда, никакими const там не пахло (не надо кивать на .const секции, это немного из другой оперы), но объявления, в зависимости от диалекта, типа "foo EQU x" или "foo = y" как бы намекали нам об этом. Опять же, никакого конкретного адреса, всем все ясно.> Вот выше человек правильно написал - это по сути read only переменная,
Еще раз, для тех кто в танке - это не переменная. Первое отличие - вычисляемость в компайлтайме. Второе - отсутствие конкретного адреса и прочих "мест обитания", причем "по умолчанию", а не в следсвии оптимизации.
> Короче печально всё, от понимания "зачем оно", до документации (и терминологии в
> частности).Во-во. Согласен.
Много кто умеет вычислять не меняющиеся переменные на этапе компайлтайма, причём по умолчанию, но они это называют "оптимизация на этапе компиляции", а не делают из этого культ мордования терминологии
Культ тут разве что ты делаешь. Насколько я понял, с С/C++ ты знаком. В них дефолтное поведение для переменной это изменяемость, а невозможность изменений задается ключевым словом const. В rust наоборот, дефолтное поведение для переменной это невозможность изменений, а изменяемость указывается при помощи ключевого слова mut. То бишь если отбросить нюансы с указателями, то разница лишь в том, какое поведение по умолчанию, а какое требует ключевого слова. При этом в обоих случаях речь идет о переменных(именованная ячейка памяти), не о настоящих константах. Скорее всего тебя в заблуждение вводит само слово const.
Он дятел - сиречь не понимает даже что в правильных Ёзыках константы не имеют не то что адреса, но и даже например типа :)
Дополнительные правила и ограничения - плата за безопасность и увеличение производительности. Пример, как и все подобные, высосан из пальца.
Безопасность иллюзорна ибо любой нетривиальный алгоритм будет полон unsafe'ов.
Увеличение производительности пока что не продемонстрировано.
Вот вам концепция, на которой С++ гарантированно проиграет Rust'у: http://www.gamedev.ru/flame/forum/?id=156989
> Вот вам концепция, на которой С++ гарантированно проиграет Rust'у: http://www.gamedev.ru/flame/forum/?id=156989Я там что-то не нахожу большой кучи хвалебен в честь Rust. Где там это обосновано? Дай прямую ссылку. Или бенчмарк конкретный.
Тебе надо, ты и пиши, в чем проблема? Почему на операциях с памятью Rust оказывается быстрее тебе ответили.
Пруф или не было.
> Безопасность иллюзорна ибо любой нетривиальный алгоритм будет полон unsafe'ов.95% кода — это тривиальные алгоритмы. Вот там и будет выигрыш в безопасности.
Плата за безопасность - открытость и понятность кода. Когда начинается магия и ересь - безопасность и надёжность заканчивается, начинается security through oscurity и появляются "крайне редкие специалисты", требующие за разруливание этих клубков магической лапши баснословные деньги.
> Плата за безопасность - открытость и понятность кода. Когда начинается магия и
> ересь - безопасность и надёжность заканчивается, начинается security through oscurity
> и появляются "крайне редкие специалисты", требующие за разруливание этих клубков магической
> лапши баснословные деньги.Истину глаголишь. Стартап на чем-то экзотическом, только потому что пареньку с горящими глазами нравится perl, окамл, хруст и т.д. - это проблемы для всего коллектива в будущем и громадные перезатраты усилий.
>> Плата за безопасность - открытость и понятность кода. Когда начинается магия и
>> ересь - безопасность и надёжность заканчивается, начинается security through oscurity
>> и появляются "крайне редкие специалисты", требующие за разруливание этих клубков магической
>> лапши баснословные деньги.
> Истину глаголишь. Стартап на чем-то экзотическом, только потому что пареньку с горящими
> глазами нравится perl, окамл, хруст и т.д. - это проблемы для
> всего коллектива в будущем и громадные перезатраты усилий.Скала, кстати, тоже сюда. Хотя вроде бы хороший язык и с фреймворками все в порядке - получается плохо разгребаемая магическая лапша.
https://en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)#The_Blub_paradox
"cargo build", "cargo doc", "cargo check" ... Какой-то прямо "cargo cult"...
Ломающие новости. Это специально именно так и названо.
Когда QT на раст перепишут, тогда он и зарешает, а пока - язык выходного дня.
Qt на Rust не перепишут, к счастью.
Ага, тогда им еще и гуи придумывать, а они и язык пока не могут до стабильного состоянию допилить.
У Qt есть GUI же. И у них нет причин переписывать себя на Rust.
Если же мозилловцы захотят написать на Rust аналог Qt, то это будет не Qt, а другая библиотека. Максимум - у них будет схожее API/ABI и похожие алгоритмы.
К тому же вообще не понятно зачем с нуля создавать то, что и так прекрасно работает, лишь бы была нормальная возможность подключать нужные библиотеки, которая конечно же есть у всех нормальных языков.
Это и не требуется. Элементы, требующие производительности и безопасности, можно выделить в отдельные либы на Rust'e. Остальное оставить на с++.
Можно популярнее про производительность и безопасность? Вот прям с примерами. Добавление зоопарка должно добавить или стрёмный, по сравнению со стандартным для Qt, код?
Вполне возможно, что весь гномостек на него портируют (включая GTK+). librsvg переписывают уже сейчас.
Сомневаюсь, что начнут переписывать glib
уж куда лучше на Swift переписать, которому всего 3 года, но он уже юзабельный с версии 3.
Он А-огороженный и никому кроме заднеприводных не уперся, увы.
> Когда QT на раст перепишут, тогда он и зарешает, а пока
> - язык выходного дня.Крику много, но они сами не знают зачем им Rust.
Сферическая вырвиглазность в вакууме.
Знают.
Но никому не скажут.
Руст - это агрессивная реклама вырвиглазного, неудобного и ненужного.Фактически аналог хорошего стат. анализатора подается как преимущество, при отсуствии фрейморка, IDE и прочих инструментов.
1. Раст, не руст.
2. Стат. анализатор и есть преимущество. Но оно не всем нужно ценой потери свободы.
3. IDE и прочие инструменты еще впереди. Пока на этом языке нет ни одного взлетевшего проекта, т.ч. рано еще.
Dropbox. Впрочем, там еще много чего на Go, но весь core - уже на Rust.
Dropbox. Впрочем, там еще много чего на Go, но весь core - пока на Rust.(fixed)
У кого что болит, как гриться... Пока я вижу лишь твою повышенную активность подозрительно напоминающую оказать влияние на мнение других.
По каждому языку здесь раскручивается холивар. Я полагаю из-за того, что люди боятся, что язык взлетит и его придется учить, чтобы не оказаться в отстоиниках. Как считаете?
Считаю, фигню сказал. Разве боятся апологеты Жабы прихода C#? Кто-то из "сипиписников" оглядывается на D? Нет и нет. Каждый работает в своей нише. Мир ИТ, несмотря на свою кажущуюся стремительность, на деле крайне инертный (как стандарты для патронов). Есть столько легаси кода на древних языках, что практически любой найдёт себе работу по поддержке старого *овна мамонта. Да ещё и оплачивать будут выше из-за "уникальности специалиста".Радует то, что наметились здоровые тенденции - видны языки-аутсайдеры и языки с явным психическим уклоном создателей - такие просто медленно загнутся. Но любой новый выскочка никогда не заменит существующего болота, так что не переживайте - продолжайте похапэхать. :)
> Разве боятся апологеты Жабы прихода C#? Кто-то из "сипиписников" оглядывается на D? Нет и нет.Не знаю, абсолютно. Я сужу по только по наблюдаемой здесь истерике. Людям плевать на объективные аргументы. И так и по Python и по Go и по Rust. И при том четкая тенденция - держатся за старое (Python) и категорически отвергают всё новое (Go, Rust).
Я уверен, что половина плюющих на аргументы -- тролли, оставшиеся -- хомячки, которые не имеют собственного мнения и субъектности. Нет какого-то глубинного смысла в том, чтобы обращать внимание на тех или этих.
> По каждому языку здесь раскручивается холивар. Я полагаю из-за того, что люди
> боятся, что язык взлетит и его придется учить, чтобы не оказаться
> в отстоиниках. Как считаете?Языку для взлёта нужно десятки лет. Нужны иструментарии сборки и развёртывания, тестирования, отслеживания изменений и прецедентов, нужны средства управления жизненным циклом. Ничего этого у новых языков нет. Вот тот же Питон, Руби или Пых потрепыхались, но так на корпоратив и не вышли, потому что нет у них ничего подобного мавену-шмавену, жире, дженкинсу и т.д. и т.п. И не будет никогда. Ну и каркасы, конечно же.
> ... обеспечивающего автоматическое управление памятью и предоставляющего средства для высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime.
> ... В пакетном менеджере Cargo ...
> ... В будущем файлы ".rmeta" планируется задействовать в сборочном сервере Rust Language Server и возможно в некоторых других утилитах;Не понял. Какое отношение имеет "пакетный менеджер" к ЯП (да ещё и без "runtime", что тоже херня какая-то --- собственная терминология?)?
Что прикольно, сто лет как существует D - такой же "с менеджером памяти" и не менее подходящий для "системное программирование". ГДЕ ВЫ, хипстеры и гонщики за новомодным? Вот же, стабильный язык с кучей библиотек - пишите! Или вам нехватает в ушах рекламы?
Ну видимо разница есть, раз не слетаются на такой крутой, "столетний" язык
D растерял кучу людей, когда показал свою несостоятельность как языка в процессе своего развития (история с двумя стандартными библиотеками это вообще нечто, нужно придумать что-нибудь покруче для того чтобы отбить желание его учить еще в начале). Ни одному "хипстеру и гонщику за новомодным" (да и вообще кому угодно) такие запары с маргинальным языком в самом начале пути не нужны и нужны никогда не были.
Я пишу. Шикарный язык, да.
> Что прикольно, сто лет как существует D - такой же "с менеджером
> памяти" и не менее подходящий для "системное программирование". ГДЕ ВЫ, хипстеры
> и гонщики за новомодным? Вот же, стабильный язык с кучей библиотек
> - пишите! Или вам нехватает в ушах рекламы?D пролетел с названием. Такое амбициозное название, а под обложкой жаба, компилируемая в натив-код. Разрабы просто наcpали в душу. Им поскромнее бы быть, может чего и вышло бы.
> D пролетел с названием. Такое амбициозное название, а под обложкой жаба, компилируемая
> в натив-код. Разрабы просто наcpали в душу. Им поскромнее бы быть,
> может чего и вышло бы.D пролетел из-за отсутствия ответа на вопрос "зачем?". Александреску в полный рост.