LINUX.ORG.RU

Посмотрел я этот ваш Rust

 ,


6

8

Вобщем, дошли руки потыкать палочкой.

Я вот что не пойму - зачем и кому он нужен, ну правда?

Это же новый C++. То есть, чрезмерно переусложненный язык, в котором, как говорил Луговский, разобраться может разве что хорошая зубрилка, а не хороший программист, но при этом не дающий никаких бонусов к продуктивности, и никакими киллер-фичами не обладающий.

Close to metal? Нет, извините, мне когда надо будет close to metal - я пойду сишку возьму. Которая реально, и Close To Metal, и со стабильным ABI, так важным для низкоуровневого программирования, и так далее. А если просто производительности не будет хватать, в том числе там из-за GC, так ведь - что в Java, что в Common Lisp, есть огромное количество возможностей затюнить производительность до нужного уровня, при этом не стреляя себе в ногу.

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

Наконец, ну безопасность чтоли, хваленая? Ну, опять нет. Взять тот же unsafe. Если вам нужна прямо таки безопасность-безопасность - берите что-нибудь вроде хаскеля(или какого-нибудь Coq, или что-нибудь подобное, с зависимыми типами, если совсем упоролись), ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.

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

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

Нет, это ABI конкрентной реализации стандартной бибилотеки, а не языка, которая легко обходится определением макроса.

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

Если у тебя неожиданно возникла потребность поменять по всей кодовой базе float на my_float, то есть лишь два варианта. Либо она свалилась как снег на голову, тогда это и не должно быть легко (Вопрос «как мне легко заменить Gtk на Qt в кодовой базе» столь же абсурден), либо возможность такой замены предполагалась изначально, и то, что у тебя уже захардкожен float везде – твой косяк.

impl Float for MyFloat {
    // ..
}

fn foo<F: Float>(x: F) {
    // ...
}
Siborgium ★★★★★
()
Ответ на: комментарий от Siborgium

Напомню, что речь о коммерческой либе.

С точки зрения продавца исходники будут. Просто нужно пересобрать объектные файлы. А то, что покупателю придется прийти к продавцу за новой версией объектных файлов для другого компилятора или даже другой операционки - только плюс. Появляется привязка. Продавец становится частью пищевой цепочки, на него завязан процесс, а иначе нахрен ему сдалось что-то делать, тратить свое время, если он не сможет получить вознаграждение. Хотя бы для того, чтобы продолжить заниматься своим делом, может быть, даже любимым делом, что у него получается лучше, чем у других.

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

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

Создание нового - это не одномоментный акт, это целый процесс во времени, часто длительный процесс. А жизнь так устроена, что деньги нужны. Фиг с ними, не так важна сумма на счету в банке, важна сама возможность быть на плаву и продолжать заниматься свои делом, а для этого нужна, повторюсь, финансовая подпитка. Модель опенсорса эту задачу не решает и не может решить в принципе. Поэтому коммерческим либам быть!

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

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

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

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

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

Божечки, у нас тут клиника. Вызывайте санитаров.

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

Задел чувства верующего? Ну, звиняй!

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

В коммерческой среде все используют MSVC, так что проблема остаётся.

Начиная у 2015, 2017 и 2019 бинарники совместимы (по крайней мере по утверждениям MS). Поэтому если все поголовно используют MSVC, проблемы тоже нет.

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

Речь шла о том, что в С++ нет единого, стабильного ABI. Поэтому подключить левую либу к проекту так просто не получится, в отличии от сишки.

PS: если у MSVC стабильный ABI, то зачем Qt собирают под каждую версию отдельно?

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

И компилятор гарантирует что список всегда будет на стеке? Даже если я заходу очень большой массив?

это что, попытка троллинга такая? кто у нас там даст разместить офиглиард элементов в стеке? раст? компилятор конкретного ЯП может и даст, и кому от этого будет хуже?

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

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

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

PS: если у MSVC стабильный ABI, то зачем Qt собирают под каждую версию отдельно?

На всякий случай, наверное. К тому же в их компиляторах частенько бывают баги, и никто точно не знает, какая сборка самая правильная, по причине багов, например, в 5.15 из релизов 2017 выкинули (заменив на 2019), а 2015 оставили

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

кто у нас там даст разместить офиглиард элементов в стеке?

Размер стека, вообще-то, настраивается при запуске процесса (или даже потока), ЯП как бы не при делах.

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

кто у нас там даст разместить офиглиард элементов в стеке

Ось даст. Или не даст. В общем случае причин не дать нет, стандартный размер стека отлично твикается тем же ulimit.

компилятор конкретного ЯП может и даст

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

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

Вообще не понял к чему все это было. Ты либо читать учись, либо додумывать отучивайся.

Мысль была следующая: у конечного юзера есть коммерческая либа и хэдеры к ней. Сырцов нет, они у вендора. Вендор собрал либу своим компилятором с одним ABI, юзер использует компилятор с другим ABI. Все, приплыли. В такой ситуации, вовсе не редкой,

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

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

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

Размер стека, вообще-то, настраивается при запуске процесса (или даже потока), ЯП как бы не при делах

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

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

Ось даст. Или не даст. В общем случае причин не дать нет, стандартный размер стека отлично твикается тем же ulimit

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

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

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

Там же шаблоны, которые из текстов собираются всегда, так что без сырцов кресты в принципе не собираются. По этой причине был создан COM мелкомягкими — иначе как приложениям взаимодействовать? Хотя, по моему мнению COM дало ровно две полезные фичи: возврат значения произвольной длины и подсчет ссылок у публичных интерфейсов.

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

Ось даст. Или не даст.

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

Если он не даст, то он плохой компилятор.

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

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

В этом и смысл. Пусть конечный юзер идет к вендору, хамло

dave ★★★★★
()

что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами

Думаю, пользователю сервиса будет фиолетово, почему [i]у него ничего не работает[/i]: сегфолт ли это всего бакенда или просто конкретно ему вылетает exception. В Java слишком убогая система типов, чтобы называть этот язык безопасным.

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

В общем случае причин не дать нет

Как передать указатель на объект в стеке соседнему потоку?

DonkeyHot ★★★★★
()

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

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

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

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

Именно Lisp curse. Раст ему, кстати тоже очень сильно подвержен. На лиспе очень легко написать крутые штуки в которых никто не будет разбираться, проще написать заново.

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

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

Есть основания? Всю безопасность что дает обычная джава есть в safe rust. Safe rust исключает часть ошибок, которые в джаве допустить очень легко.

PS. если что в джаве (не в языке, а в стандартной библиотеке) тоже есть unsafe который позволяет стрелять себе в ногу не хуже чем в плюсах и сильнее чем в unsafe rust, но почему-то никто про это не помнит или не знает.

maloi ★★★★★
()

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

Virtuos86 ★★★★★
()

ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.

Громко ржу и неистово лорчую. :)))

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

Я не про популярность. Есть языки мощные, типа лиспа, где ты сам себе лепишь воздушные замки. Есть языки тупые типа Go, где всё делается квадратно-гнездовым единственно верным способом. И спектр между ними.

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

Раст с одной стороны достаточно мощен чтобы на его системе типов и макросах можно было слепить себе практически что угодно, с другой это самое слепленое поддерживать смогут только те кто это написали. Плюс крайняя скудость стандартной библиотеки которая прямо провоцирует делать свои велосипеды, если нет общепопулярной библиотеки. А потом получается как с actix, автор эморейжнул и грохнул проект. Потом восстановил, но осадочек остался.

Вот именно это и является той самой близостью к Lisp curse.

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

В итоге нужны и те и другие.

Нет, не нужны. Это одна из главнейших ошибок современного IT - создание языков для дебилов.

Лисп это для одиночек или небольших крепких команд, которые делают что-то малыми ресурсами.

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

В Symbolics, наверное? В Texas Instruments? Или где?

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

Это не работает, в принципе.

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

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

Недостаточно мощен. Его макросы, как и макросы скажем Scala, по ряду причин банально неюзабельны. А слепить на нем, как и на C++, можно разве что неподдерживаемое говно, вот именно, в стиле приколов Александреску.

Вот именно это и является той самой близостью к Lisp curse.

Нет никакого Lisp Curse, это придумали те кто лиспа в глаза не видел, и историю развития IT не знает.

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

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

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

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

Нет, не нужны. Это одна из главнейших ошибок современного IT - создание языков для дебилов.

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

Это не работает, в принципе. Замена одного программиста на другого никогда не бывает простой, и это зависит совершенно не от языка программирования. Потому что программирование это не конвейер на тракторном заводе.

Это залог долгосрочной перспективы, чтобы когда программиста переедет автобус и bus factor станет близок к неприличному уровню, найти программиста было делом дней-недель, а не месяцев-годов.

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

Недостаточно мощен.

Достаточно чтобы можно было сделать неподдерживаемое говно. Недостаточно мощен чтобы это говно было обязательно к использованию.

Нет никакого Lisp Curse, это придумали те кто лиспа в глаза не видел, и историю развития IT не знает.

Как метафизического понятия нет. Как «социальная» проблема да, существует «Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.»

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

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

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

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

С чего бы? А так то, в любом проекте велосипедов полно, это не от языка зависит.

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

«За деньги на C# не писал, но не за деньги ковырялся с Си применительно к встраиваемому линуксу в частности». Смешно просто.

То что ты называешь «языками для дебилов» означает только то что ты слабо понимаешь зачем и для чего они были сделаны.

Во-первых, отлично понимаю, а во-вторых, автор того же Go признает, что это язык для дебилов прямым текстом, пусть и политкорректно. Вот тут отличный перевод с политкорректного на английский: https://twitter.com/16kbps/status/1195081752659865615

Это залог долгосрочной перспективы, чтобы когда программиста переедет автобус и bus factor станет близок к неприличному уровню, найти программиста было делом дней-недель, а не месяцев-годов.

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

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

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

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

На ассемблере только в путь можно сделать неподдерживаемое говно. Мощен ли ассемблер?

Как метафизического понятия нет. Как «социальная» проблема да, существует «Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.»

Еще раз, это бред собачий. Непопулярность лиспа объясняется исключительно историческими случайностями - во-первых, бумом и закатом исследований AI в 80х, а во-вторых, маломощностью рядовых компьютеров в то время.

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

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

От языка тоже. Чем более «мощный» язык тем чаще на нём написана какая-то странная, но очень нужная хрень.

«За деньги на C# не писал, но не за деньги ковырялся с Си применительно к встраиваемому линуксу в частности». Смешно просто.

Ты если уж пытаешься в иронию делай это лучше. поставил бы тогда уж C# и C++ было бы точнее и смешнее.

с политкорректного на английский

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

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

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

Ты вообще не понял что и о чём я написал. Перечитай ещё раз, потом ещё два раза, может быть хоть тогда ты сможешь понять.

На ассемблере только в путь можно сделать неподдерживаемое говно. Мощен ли ассемблер?

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

Непопулярность лиспа объясняется исключительно историческими случайностями - во-первых, бумом и закатом исследований AI в 80х, а во-вторых, маломощностью рядовых компьютеров в то время.

s-expr - вот почему лисп непопулярен. Все боятся скобочек. Не единожды наблюдал. Всё лишь бы не скобочки!

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

найти программиста было делом дней-недель, а не месяцев-годов

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

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

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

Если популярной библиотеки нет, то откуда нужная функциональность в стандартной возьмётся? У разработчиков раста банально не хватит ресурсов на всё-всё, даже если бы они и хотели.

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

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

Это не работает, в принципе.

Это может не нравиться (мне вот не нравится), но гугл, наверное, знает, что и зачем делает.

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

Это может не нравиться (мне вот не нравится), но гугл, наверное, знает, что и зачем делает

В гугле есть топовые программисты, но большинство сотрудников — это совершенно обычные програмисты/менеджеры/одмины, которых набирают из подручных мест. Это к понаехавшим очень высокие требования.

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