Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
Это просто прекрасно! Дождались!
Я понимаю что язык молодой, но может к нему уже есть какие-либо быстро развивающиеся инструменты? Интересуют IDE с синтаксически корректным автокомплитом и хороший дебагер.
Rust до первых бета-версий был динамично развивающимся на столько, что код, работающий еще вчера, можно было не скомпилировать уже сегодня.
Однако есть некоторые движения в этом направлении, в частности racer — движок для автокомплита из любого редактора (плагин под atom, на пример). Также есть плагин под IDEA.
Однако есть некоторые движения в этом направлении, в частности racer — движок для автокомплита из любого редактора (плагин под atom, на пример). Также есть плагин под IDEA.
Добавлю:
— Visual Rust — плагин для VS.
— Scrawl (очередной платный редактор? хотя выглядит вкусно) пилит поддержку Rust (Rust is very likely to be a first-class citizen. Community tooling is promising and should mature quickly now that Rust is 1.0)
— Visual Rust — плагин для VS.
— Scrawl (очередной платный редактор? хотя выглядит вкусно) пилит поддержку Rust (Rust is very likely to be a first-class citizen. Community tooling is promising and should mature quickly now that Rust is 1.0)
Visual Rust классный плагин, однако не поддерживает 2015 студию… Фиг с ним, попрограммировал бы и в блокнотике, но не нашел подсветку синтаксиса для раста. Не подскажете, может знаете, как можно из такой ситуации выйти, не снося 2015 студию?
Хм, VS Community 2013 хорошо уживается рядом с 2015-й студией. Если не хотите ставить студию ради Rust, ещё есть, например, подсветка синтаксиса в Sublime.
Нашел оптимальный способ — прямо на сайте языка: play.rust-lang.org
Из плюсов: подсветка синтаксиса, запускается везде, где есть интернет, внятные сообщения об ошибке — в студии большая часть ошибок фактически пишет только RS1234 в таком виде, или type mismatch, без указания, собственно, типов, что усложняет отладку и без того непростого языка с не таким уж большим числом документации и примеров, можно шарить шортлинками исходники.
Минусов как таковых разве что необходимость фигачить всё в один файл, для более-менее сложных проектов непригодно, но вот разобраться самое оно.
Из плюсов: подсветка синтаксиса, запускается везде, где есть интернет, внятные сообщения об ошибке — в студии большая часть ошибок фактически пишет только RS1234 в таком виде, или type mismatch, без указания, собственно, типов, что усложняет отладку и без того непростого языка с не таким уж большим числом документации и примеров, можно шарить шортлинками исходники.
Минусов как таковых разве что необходимость фигачить всё в один файл, для более-менее сложных проектов непригодно, но вот разобраться самое оно.
Ещё забыли упомянуть SolidOak — редактор с претензией на IDE, основанный на NeoVim и racer.
Кроме того к расту подходят многие инструменты, подходящие к Си, в частности gdb и kcov прекрасно работают, равно как и всё, что основано на них.
Давно уже используем emacs + rust-mode.
Полет отличный!
Полет отличный!
Поздравления всей команде и всем вовлеченным людям! 1.0 это важная веха.
Полку мертворожденных языков прибыло.
Я человек измученный нарзаном, т.е. джавой. И раст мне показался чем-то действительно свежим и новым, хорошо продуманным и инновационным, с приемлемой сложностью, быстрым рантаймом и без сборщика мусора. На мой взгляд раст одна из самых значимых ступеней современного языкостроения.
Уверен, что количество комментариев к этому топику примерно коррелирует с количеством заинтересованных в этом языке людей. То же самое можно сказать и про D (который мне нравится больше). Думаю у обоих этих языков было бы намного больше шансов если бы сейчас сам С++ не развивался семимильными шагами. Да, «плюсы» это естественно легаси, но последние подвижки плюс то что должно в скором времени выйти (например модули) может поставить С++ примерно на уровень C#/Java, хотя конечно и с поправкой на то что все равно уровень комфорта этих языков так просто не достичь.
Как минимум у Rust больше шансов на успех чем у D поскольку за ним стоит Mozilla, которая на нем делает серьезный проект (servo). Т.е. это не язык ради языка. Да, для плюсов есть статические анализаторы, но когда они встроены в язык они как бы направляют программиста на путь истинный с первых «Hello worldов».
+ Как следствие, тут создатели языка заинтересованы в стабильности и единообразии в отличии от D. Который имеет две несовместимых версии и две доминирующих библиотеки с одинаковой функциональность.
Интересно, сколько лет будет повторяться этот стереотип?..
Никаких активных изменений в D1 уже давно не происходит, а проблема со стандартными библиотеками решена несколько лет назад, сейчас даже вроде есть порт Tango на D2, совместимый с обычной стандартной библиотекой. А также менеджер пакетов и репозиторий для них (code.dlang.org).
В любом случае, D и Rust — очень разные языки, так что сравнивать тут особо нечего.
Никаких активных изменений в D1 уже давно не происходит, а проблема со стандартными библиотеками решена несколько лет назад, сейчас даже вроде есть порт Tango на D2, совместимый с обычной стандартной библиотекой. А также менеджер пакетов и репозиторий для них (code.dlang.org).
В любом случае, D и Rust — очень разные языки, так что сравнивать тут особо нечего.
но последние подвижки плюс то что должно в скором времени выйти (например модули) может поставить С++ примерно на уровень C#/Java
Да ни в коем случае! Вы же просто шутите, верно? Я не могу говорить за Java, но недавно вынужден был пописать на C#, и для меня, пришедшего из С++, он просто ужасен.
• Темлэйты. Пока в C# нет аналога темплэйтов, проекты (недавно и я) обречены на написание огромного кол-ва повторяемого кода. Вы же, надеюсь, не будете утверждать, что аналог темплэйтов — это дженерики, правда? ;)
• Мутная типизация числовых типов. Это просто убийственно — я занимался тем, что портировал относительно несложный код с С++ на C#, и подобные вещи меня убивали — попробуйте скомпилировать следующий код:
UInt16 two = 2;
UInt16 foo = two + 2;
У вас будет выбор: либо писать, используя правильные размеры, но кастуя в каждой третьей строке, либо писать неправильно, зато без кастов. Прелестно.
• Полурабочий «sizeof». Он не может брать размеры переменных, только размеры типов. Это означает, что, если у меня в структуре есть переменная х типа UInt16, и я однажды ее поменяю на UInt32, мне придется перерывать весь код в поисках, где я делал «sizeof(UInt16)», подразумевая «sizeof(x)».
Вообще в C# знатный бардак с размерами типов. Например мне пришлось потерять как-то кучу времени на отладку, прежде, чем я понял, что хваленный, и везде рекомендуемый «Marshal.SizeOf(myStruct)» в моем случае не работает. Он возвращал мне неправильный размер структуры из-за того, что там был массив байтов — а с массивами он работает неправильно, причем в компиляторе нет даже предупреждения на эту очевидную ошибку (ибо кому может понадобиться брать размер массива, если заведомо вернется неверное значение?). При этом «Marshal.SizeOf()» применяется на объекте, а не на типе, т.о. логично ожидать, что возвращать он будет размер, занимаемый объектом.
Да, безусловно, например в полюбившимся последнее время Хаскелле, мне тоже неизвестно ничего подобного — но, черт подери, это же Хаскелл! Это сущая мелочь, в сравнении с тем, что ты получаешь. Что я получаю взамен в С#?
• Watchpoint'ы. Недавно мне крайне необходимо было воспользоваться подобным функционалом, и… Как выяснилось, их нет в C#. То есть не то, что их нет в конкретном дебаггере от Моно, или от Студии, либо еще где-то — словам людей с SO они принципиально невозможны в связи с устройством сборщика мусора, который имеет полное право двигать существующие объекты, приводя к ложным срабатываниям.
• В С++ есть любопытная малоизвестная конструкция стиля «if (const char* foo = myFunc()) {puts(foo)}»(disclaimer: внутри скобок «if» провозглашается переменная, и используется далее в блоке). Штука спорная, но мой опыт показывает, что плюсы использования перевешивают минусы. Потому что, когда у вас есть несколько функций 50-100 строк, которые вызывают одна другую, и в какой-то из них, вы точно знаете, есть ошибка — вам приходится тщательно проследить за каждой переменной, что бы понять, что с ними происходит. И, чем уже область видимости подобных переменных, тем меньше боли вам это доставит. Надо ли говорить, что аналога C# не имеет.
• Деструкторы. О-о, да, одно из самых слабых мест C#. Деструкторы вызываются в рэндомный момент, и потому не несут практически никакой пользы. Что же делать? Я не слышу, кто-то упомянул Disposable? Это аналог деструкторам, да? Это же великолепно, давайте напишем класс, которому жизненно необходим освобождать какой-то ресурс при выходе за область видимости, и обнаружим, что… эту функцию мы должны вызывать вручную! Какой смысл в нем, если мы должны делать все руками? Нет, я знаю, мы можем написать конструкцию в стиле «using (var x = new myDisposableType()){/*code*/}», вот только единственное место, откуда пользователь класса об этом узнает — один из комментариев в документации к классу. И дай Бог, что бы он был очень внимательным, когда будет читать это тысячное описание, т.к. компилятор даже предупреждения не вставит, если он забудет использовать подобного рода конструкцию, а об этом маленьком нюансе он узнает только после длительной и муторной отладки (потому что не всегда проблема, вызванной не-удалением ресурса, может быть очевидно, как было в моем случае).
• Кроссплатформенность. Нет, не упоминайте Моно, прошу, даже мое несложное приложение не работает там, как хотелось бы, из-за древнего бага, касающегося таймаута в серийных портах.
Это только то, что я смог вспомнить навскидку, но моя память говорит, что это были не единственные проблемы такого рода. Вы же ведь не серьезно это С++ сравнили с C#, вы просто шутили, верно?
P.S. Ох, как много текста… Прошу прощения, вынужден кодить какое-то время на этом языке, просто уж очень сильно накопилось :)
Проблемы которые вы ощущаете вполне реальны но все же весьма специфичны. То есть например как раз с типизацией все спорно т.к. в С++ непонятно что такое int вообще (т.е. сколько оно бит). Все что я хотел сказать это то что по степени комфорта общего программирования, не вдаваясь в сложные кейсы, С++ может дойти почти до уровня C#/Java.
Вполне себе понятно — для «int» определена только нижняя граница в 2¹⁶. У него нет верхней границы, он может сколь угодно простираться, вы видите очень длинную прямую, чей хвост скрывается и меркнет вдали под влиянием Допплеровского эффекта. Если необходимо знать битность числа, то еще великие древние, что кодили на чистом С, использовали типы из стандартной библиотеки, вроде «int32_t» (limits.h)
Должно быть, вы хотели сказать «снизойти»? Потому что, даже, когда я мысленно вычеркиваю все упомянутое, и ставлю, казалось бы, вровень, эти языки — у меня остается в памяти, что в C# на каждой пятой строчке, я должен не забыть создать объект с помощью слова new. И да, вполне допустимо умудриться где-то не инициализовать поле, и обнаружить это только в рантайме. Какой вообще смысл использовать сборщик мусора, если я должен писать в полях класса это слово, тогда как, в столь, почему-то, принижаемом вами С++, поле с объектом в простейшем случае само о себе позаботится (для наглядности, создайте в C# класс с объектом List<>, и в С++ класс с объектом std::vector<>).
В С++ я могу провозглашать объекты на стеке, не пользуясь словом new, и делая свой код намного меньше, и, в то же время, будучи уверенным, что за меня об инициализации объекта позаботятся добрые дяди из GNU (ведь случаи использования кучи так же специфичны, как и прошлые примеры, верно?;).
Все что я хотел сказать это то что по степени комфорта общего программирования, не вдаваясь в сложные кейсы, С++ может дойти почти до уровня C#/Java.
Должно быть, вы хотели сказать «снизойти»? Потому что, даже, когда я мысленно вычеркиваю все упомянутое, и ставлю, казалось бы, вровень, эти языки — у меня остается в памяти, что в C# на каждой пятой строчке, я должен не забыть создать объект с помощью слова new. И да, вполне допустимо умудриться где-то не инициализовать поле, и обнаружить это только в рантайме. Какой вообще смысл использовать сборщик мусора, если я должен писать в полях класса это слово, тогда как, в столь, почему-то, принижаемом вами С++, поле с объектом в простейшем случае само о себе позаботится (для наглядности, создайте в C# класс с объектом List<>, и в С++ класс с объектом std::vector<>).
В С++ я могу провозглашать объекты на стеке, не пользуясь словом new, и делая свой код намного меньше, и, в то же время, будучи уверенным, что за меня об инициализации объекта позаботятся добрые дяди из GNU (ведь случаи использования кучи так же специфичны, как и прошлые примеры, верно?;).
Вы же, надеюсь, не будете утверждать, что аналог темплэйтов — это дженерики, правда? ;)Буду. В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.
Мутная типизация числовых типов.Нахрена в методах использовать что-то меньше int? И ничего мутного нет, вся арифметика проводится только в int, и это даже отчасти хорошо. А в ваших short x + 2 вы наверняка забыли checked, да?
Он не может брать размеры переменных, только размеры типов.Marshal.SizeOf
с массивами он работает неправильноВы не понимаете, что возвращает Marshal.SizeOf. Почитайте документацию.
Деструкторы. О-о, да, одно из самых слабых мест C#.Это сильная сторона C#, потому что это фича из низкоуровнего мира в высокоуровневом языке.
Потому что, когда у вас есть несколько функций 50-100 строк, которые вызывают одна другую, и в какой-то из них, вы точно знаете, есть ошибка — вам приходится тщательно проследить за каждой переменной, что бы понять, что с ними происходит.Разделите на классы и методы. Привет, ООП.
компилятор даже предупреждения не вставит, если он забудет использовать подобного рода конструкциюПредупреждение входит в базовый пакет Code Analysis.
Извините, но вы бред пишете. Не пишите больше, пожалуйста.
Буду. В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.
Простите… «Костыли»? Серьезно? Напишите-ка мне на C# функцию, принимающую объект любого класса, и вызывающую функцию foo() из этого класса. Если у вас это получится, я возьму свои слова назад.
Нет, это в самом деле смешно — то есть тот факт, что я могу сделать больше на С++, и, при этом, сделать проверку во время компиляции, вы считаете костылем? Простите, у меня официальный опыт программирования всего год, но даже я уже знаю, что ошибки надо по максимуму находить во время компиляции, а не в рантайме. Вы, должно быть, новенький?
Нахрена в методах использовать что-то меньше int? И ничего мутного нет, вся арифметика проводится только в int, и это даже отчасти хорошо.
«Зачем делать α, мне никогда не нужно было… о.о» Простите, но вам не кажется, что это детский вопрос. Если оно вам не нужно было, вероятно это не означает, что оно не нужно совсем ни кому. Конкретно в моем случае, у меня есть протокол передачи данных по каналам связи, и каждое поле там определенного размера. Зачем такого маленького размера? Да, что бы у вас же, уважаемый a553, не тормозил ютьюб. То есть, это, конечно, утрированный пример, с моим приложением вы, скорее всего, никогда не встретитесь — но заголовки пакетов надо делать настолько маленькими, насколько это возможно.
Вы не понимаете, что возвращает Marshal.SizeOf. Почитайте документацию.
Сейчас я понимаю, но, когда ты пытаешься написать приложение, следуя многочисленным гайдам и туториалам, где проблема совершенно однозначно решается неким способом, причем даже название метода соответствует тому, что все идет правильно — ты сначала пишешь код, а потом удивляешься, почему все хреново. Должно быть вы идеальный программист, кто после туториалов сразу кропотливо перечитывает документацию на каждую примененную функцию?
Разделите на классы и методы. Привет, ООП.
Все уже за вас продумано, и разделено. Это не отменяет, что есть некие функции размером в 50-100 строк, которые делить еще дальше просто нет смысла по разным причинам. У вас такого, должно быть, не бывает?
Предупреждение входит в базовый пакет Code Analysis.
Простите… Что? Я использую IDE Mono, и редактор Емакс. Для особо проблемного дебага запускаю Студию. Где там, для чего это, говорите, плагин? Емакса? Ах, нет, должно быть Моно?
Извините, но вы бред пишете. Не пишите больше, пожалуйста.
Если учесть, что я не увидел ни одного серьезного довода, зато вы обозвали меня юродивым, должно быть у вас что-то не в порядке с логикой. Не пишите сюда больше ;)
Лень отвечать на всё, вот вам ваши самые большие ошибки:
Напишите-ка мне на C# функцию, принимающую объект любого класса, и вызывающую функцию foo() из этого класса.Да пожалуйста.
void M(dynamic o) { o.foo(); }
у меня есть протокол передачи данных по каналам связи, и каждое поле там определенного размераТекст не читай @ сразу отвечай. От ваших вычислений в short-ах у меня ютуб и тормозит :)
название метода соответствует тому, что все идет правильноИменно. Прочитайте всё-таки. Там абсолютно явно написано Marshal.
Я использую IDE Mono, и редактор Емакс.ССЗБ
Да пожалуйста.void M(dynamic o) { o.foo(); }
Что ж… Беру слова назад — я не знал про это. Любопытно.
Я использую IDE Mono, и редактор Емакс.ССЗБ
Я просто к чему говорю — этот ваш пакет, это сторонняя утилита. Я не должен для элементарных вещей искать статический анализ кода, а подобное предупреждение именно элементарно. Откуда разработчик может знать об этом? Должно быть, из случайного комментария на хабре?
Единственный валидный пункт у вас — это то, что темплейты выполняются на этапе компиляции. Но именно это и есть самый большой костыль: большинству программ требуется, чтобы темплейты выполнялись на этапе компиляции, поэтому темплейты реализованы именно так. (Посмотрите, кстати, какое количество проблем из-за этого появилось.)
На самом деле вам не нужно знать факториал какого-то числа на этапе компиляции. Вас в этом убедил сам язык С++. Называется синдром жертвы. :) Это самому С++ нужны списки типов (потому что средств описать тип в рантайме очень немного, и они достаточно бедны), и это именно С++ нужны вычислимые константы, чтобы, скажем, выделить память нужного размера на стеке.
В большинстве случаев от темплейтов вы ожидаете константной и минимальной сложности выполнения какой-то операции. Например, вычисления факториала. Это — самая основная и главная цель метапрограммирования: взять себя, посмотреть внимательно и получить какую-то информацию, в данном случае, способ оптимизировать алгоритм. И программы на Java и C# реализуют метапрограммирование превосходно.
На самом деле вам не нужно знать факториал какого-то числа на этапе компиляции. Вас в этом убедил сам язык С++. Называется синдром жертвы. :) Это самому С++ нужны списки типов (потому что средств описать тип в рантайме очень немного, и они достаточно бедны), и это именно С++ нужны вычислимые константы, чтобы, скажем, выделить память нужного размера на стеке.
В большинстве случаев от темплейтов вы ожидаете константной и минимальной сложности выполнения какой-то операции. Например, вычисления факториала. Это — самая основная и главная цель метапрограммирования: взять себя, посмотреть внимательно и получить какую-то информацию, в данном случае, способ оптимизировать алгоритм. И программы на Java и C# реализуют метапрограммирование превосходно.
дженерики это костыль который был привнесён в java что бы добавить немного метапрограммированияНу а это полная чушь. Дженерики, тем более в Java, не относятся к метапрограммированию.
У вас прям микс получился из спорных определений и логических противоречий %)
Про размещение в памяти. Вы размещаете объекты в памяти в рантайме, компилятор этим не занимается для вашей программы. Проблема в том, что в С++ вы фактически не имеете информации о размере типов в рантайме, поэтому компилятору приходится выдавать «подсказки» программе: выдели 16 байтов на стеке, положи по смещению 0 инт, по смещению 4 вот этот шорт, а по смещению 8 — вот этот лонг. Но вашей программе на самом деле глубоко наплевать, сколько там байтов что занимает, и где конкретно оно расположено. Требование одно: три переменные! И пожелание: пусть доступ к ним будет быстрым. И всё это можно реализовать в рантайме, удобно и эффективно. И C#, в общем-то, так и поступает.
Мне кажется, у вас лишь поверхостное знание того, что такое метапрограммирование в управляемых языках, и что из себя представляют дженерики. Будет время — изучите обязательно, очень интересно! Советую начать с обзоров АОП-фреймворков, например — вот где настоящее метапрограммирование!
Про размещение в памяти. Вы размещаете объекты в памяти в рантайме, компилятор этим не занимается для вашей программы. Проблема в том, что в С++ вы фактически не имеете информации о размере типов в рантайме, поэтому компилятору приходится выдавать «подсказки» программе: выдели 16 байтов на стеке, положи по смещению 0 инт, по смещению 4 вот этот шорт, а по смещению 8 — вот этот лонг. Но вашей программе на самом деле глубоко наплевать, сколько там байтов что занимает, и где конкретно оно расположено. Требование одно: три переменные! И пожелание: пусть доступ к ним будет быстрым. И всё это можно реализовать в рантайме, удобно и эффективно. И C#, в общем-то, так и поступает.
Как пример, структура алгоритма может зависеть от свойств некоторого числа N. Конечно это не ряд фибоначи, это может быть что-то более сложное, вроде разложения на примитивные корни по модулю m.Вы вычисляете сложные алгоритмы, зависящие от разложения чисел, используя компилятор? Я считаю, вам надо пересмотреть подход к проетированию вашей программы, и вынести этот алгоритм в отдельную библиотеку. И после этого уже можно заниматься инлайнингом результатов.
И это никак не связано с отсутствием рефлексии, даже если бы она была, это не помогло бы исключать ненужные ветви выполнения кода без условных переходов и vtable.
Нет, цель метапрограммирования — создавать программы которые создают программы. С таким успехом можно и javascript называть языком с метапрограммированием. Там тоже интерпретатор присматривается во время синтаксического анализа к коду, что бы для числовых массивов использовались оптимизированную реализацию. Но это не метапрограммирование, абсолютно.Определение некорректное. Кроме того, вы хотите сказать, JS — язык без метапрограммирования?
Ну эта тема много раз поднималась на стековерфлоу, так что просто приведу ссылки:Вопрос по ссылке: «можно ли в C#/Java выполнять код на этапе компиляции?» С ответами не поспоришь, нельзя. Однако именно в этих языках появился АОП, например.
дженерики это костыль который был привнесён в java что бы добавить немного метапрограммированияНу нет же. Дженерики в джаву были введены для упрощения статического анализа, а следовательно избежания многих популярных ошибок, а также избежание вездесущих кастов.
дженерики являются элементом обобщенного программирования т.н. generic programming. А generic programming это одно из путей развития идеи метапрограммирования.Это разные понятия. Обобщенное программирование — это подход к написанию программ, а дженерики — это фича языка. Они зачастую используются вместе, но вы также можете выбрать что-то одно. Более того, вы же не считаете использование opaque pointer в С/С++ метапрограммированием, верно?
сам James Gosling автор Java указывал что generics это «kind of like templates»Нет, он говорит, что реализация типового полиморфизма в джаве похожа на типовой полиморфизм шаблонов. В этом плане они действительно похожи.
Мне кажется, у вас лишь поверхостное знание того, что такое метапрограммирование в управляемых языках, и что из себя представляют дженерики. Будет время — изучите обязательно, очень интересно! Советую начать с обзоров АОП-фреймворков, например — вот где настоящее метапрограммирование!
Ссылки на стековерфлоу доказывают не «отстутствие метапрограммирования», а скорее, то, что в C# и Java оно реализовано по-другому.
upd: отредактировал комментарий, потому что из родительского поста на время почему-то пропали ссылки на стековерфлоу, а потом появились обратно.
upd: отредактировал комментарий, потому что из родительского поста на время почему-то пропали ссылки на стековерфлоу, а потом появились обратно.
Are we web yet?
Берем Node.js, Go или что-то аналогичное. Обработку запросов делаем на них, а уже они пусть пробрасывают данные в Rust. Можно растовую часть скомпилировать как аддон или библиотеку, а можно общение между Node/Go и Rust сделать по bsd-соккетам или ZeroMQ, например.
Но вообще смысл HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобным.
Но вообще смысл HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобным.
1. Предложенная Вами архитектура не снимает вопроса — вы все requests на одном соккете предполагаете обслуживать, для обслуживания request инициировать системный поток или event-callback диспетчер?
2.
2.
HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобнымGo statically typed.
Нет, серьезно, еще один язык программирования в 2015 году?
Какие задачи он позволяет решить эффективнее, чем существующие языки?
Говорите, на 5% эффективнее и безопаснее чем С++? Зато на С++ в 100500 раз больше библиотек и инструментов.
Судьба никому не нужного языка D никого ничему не научила?
Нет, я конечно понимаю, что на хабре сидят в основном вЭб-кодировщики, которые привыкли к выходу очередного кофи/тайп/wtf-script-a, который якобы исправляет недостататки изначально ущербного джаваскрипта, или каждый день новый никому не нужный css-говнопрепроцессор.
Но кто в здравом уме будет переписывать что-то на педеРаст? Или начинать новый проект. Кто будет переписывать библиотеки, писать биндинги к существующем? Я уже видел, как разрабатывают стандартную библиотеку языка D. Обкуренные студенты вобразили себя невесть что и пишут велосипеды, которые уже давно написаны и тщательно протестированы в других языках.
Друзья, давайте будем реалистами.
Какие задачи он позволяет решить эффективнее, чем существующие языки?
Говорите, на 5% эффективнее и безопаснее чем С++? Зато на С++ в 100500 раз больше библиотек и инструментов.
Судьба никому не нужного языка D никого ничему не научила?
Нет, я конечно понимаю, что на хабре сидят в основном вЭб-кодировщики, которые привыкли к выходу очередного кофи/тайп/wtf-script-a, который якобы исправляет недостататки изначально ущербного джаваскрипта, или каждый день новый никому не нужный css-говнопрепроцессор.
Но кто в здравом уме будет переписывать что-то на педеРаст? Или начинать новый проект. Кто будет переписывать библиотеки, писать биндинги к существующем? Я уже видел, как разрабатывают стандартную библиотеку языка D. Обкуренные студенты вобразили себя невесть что и пишут велосипеды, которые уже давно написаны и тщательно протестированы в других языках.
Друзья, давайте будем реалистами.
Ёлки-палки, чего ж вы все такие крутые сишники паритесь и, простите, на говно-то исходите? Я, конечно, нарываюсь на минуса в карму, но что ж вам так раст покоя не даёт? Ну не нравится он вам, не видите в нём смысла, но вас же никто не заставляет силком на него переходить! Если он вам так не нужен, что вы забыли в этом и аналогичных топиках? Вот вам этот языке не нужен и не нравится, а другим людям нужен и нравится. Ну так и пройдите себе мимо! Зачем и себе и другим нервы трепать? Вот нравится некоторым фигнёй с никому не нужными языками страдать, ну так а вас это как касается? Вас что, глубоко раздражает, что кто-то пишет не на Си++? Почему вы на питонщиков тех же так не наезжаете? Ведь си же круче!
Это же борьба за место под солнцем. Если вы придете со своим Растом и отберете у него заказчиков, уставших от сегфолтов, он потеряет ресурсы и деньги. Все как у зверей. Просто этот конкретный хабраюзер выразил свои неосознанные опасения толсто. Это еще не так плохо, более опасны те юзеры, которые придут и будут разумно и более вежливо (не нарываясь на минусы) пояснять Вам, что Раст это просто продукт бессмысленной деятельности людей без разума, без умений и без понимания нужд индустрии.
Не обращайте внимания. У этого товарища в профиле раньше было написано, что на php пишет. А сейчас он всеми силами стремится получить зелёную плашку.
Откуда сколько желчи? Такое впечатление что вас засталяют программировать на ___ (тут вставьте свой ненависный язык). По вашему так у всех дожна быть одна модель машины, один столовый прибор и тому подобное. При чем тут вообще реализм? Rust это часть эволюции языков программирования как и D. Да, он может не выстрелить, может оказаться ненужным, но даже это не значит что Rust это провал. Для создания новых языков нужно проверять идеи и хотя бы в этом плане Rust это однозначно успех.
А знает ли кто-нибудь, была ли в каком-то другом языке до Раста похожая система типов и видов указателей, как в Расте? Т.е. вот эта идея «сборщик мусора не нужен, потому что язык так построен, что сборщик мусора в нем вырождается в пустой код».
Потому что если нет, и это совершенно новое изобретение, то шансы Раста на успех ИМХО растут очень сильно (и они у него больше, чем у D, как бы все ни уважали Александреску).
Потому что если нет, и это совершенно новое изобретение, то шансы Раста на успех ИМХО растут очень сильно (и они у него больше, чем у D, как бы все ни уважали Александреску).
ru.wikipedia.org/wiki/Cyclone_(язык_программирования)
ru.wikipedia.org/wiki/BitC
ru.wikipedia.org/wiki/BitC
Ну битс, судя по описанию, закончился, не успев начаться, потому что главный автор на него просто забил. Хотя я не могу его за это судить, возвращаться к давно заброшенному, полузабытому и уже не интересному проекту — не сахар.
Вот циклон выглядел интересно, но судя по всему его убила излишняя академичность.
В любом случае ни один из них сравнивать с Растом до конца нельзя. У него открытая разработка, управляется он целой командой, а не одним BDFLом, который может потерять интерес к языку и забить, плюс достаточно большое и активное сообщество.
В общем посмотрим, что будет.
Вот циклон выглядел интересно, но судя по всему его убила излишняя академичность.
В любом случае ни один из них сравнивать с Растом до конца нельзя. У него открытая разработка, управляется он целой командой, а не одним BDFLом, который может потерять интерес к языку и забить, плюс достаточно большое и активное сообщество.
В общем посмотрим, что будет.
Он безопаснее и удобнее C++, сохраняя realtime-гарантии и почти не завися от специфического runtime (по этому параметру он даже превосходит C++ приближаясь к чистым C).
Есть области, где еще нет 100500 библиотек.
Там же, где они есть, С++ не предоставляет стандартных средств для управления ими — а для rust есть cargo.
Есть области, где еще нет 100500 библиотек.
Там же, где они есть, С++ не предоставляет стандартных средств для управления ими — а для rust есть cargo.
Описание языка внушает уважение даже количеством страниц.
Больше 1000 контрибьюторов! (по ссылке)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонс Rust 1.0