Если не Go, то что?

Если не Go, то что?

Уроки в школе, очевидно же

Меня смущает, что rust среди широкой аудитории получает образ почти универсального языка. Якобы он подходит ко многим практическим задачам. Мне же он видится системным языком. Или языком для больших, сложных алгоритмов. Но широкая аудитория, 99,99% программистов в мире - это среднего ума (как я) прикладные программисты. В том-то и дело, что большинство программ не требуют этой производительности. Они ничего не теряют, если написаны на Python или JVM. Может быть люди хотят просто из принципа чтобы код всей прикладной программы был нативным, но тогда есть GC языки вроде D. PyQT или Swing программы воспринимаются пользователем как достаточно быстрые. Ускорения требуют конкретные операции, конкретные процессы. Чтобы пользователь ждал не 100 секунд, а 20. Но в прикладном массовом программировании это не так часто бывает. А когда бывает, зачастую это сводится к достаточно примитивным алгоритмам, в которых нет каркаса остальной программы, нет т.н. бизнес-логики. В отдельных случаях даже не приходится выделять дополнительную память к той, которую выделила managed сторона. Что остается в С? Неинициализированные переменные и выход за пределы? Но контроль выхода за пределы тех же массивов, там где он есть, насколько я понимаю, не бесплатный. Да, в C уродливость и ненужная сложность исторически обусловленная, тут действительно нужна альтернатива. Но rust ли это. Возможно мой опыт ограничен и я многого не понимаю.

Что остается в С? Неинициализированные переменные и выход за пределы?

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

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

В любой непонятной ситуации вызываешь clone(). И так делай до тех пор, пока не изучишь язык намного лучше. Даже при таком тяп-ляп программы будут эффективнее и надежнее Python, при не особо больших усилиях.

Если не Go, то солдаты НАТО.

Не посоветуете англоязычную книгу по C для тех, кто имеет опыт программирования на нескольких высокоуровневых языках? Многие книги «учат программированию», объясняют на пальцах указатели. Из-за этого книга страдает, мало пользы.

Смотрел K&R, но как-то необъяснимо не нравится она (бывает такое). Еще слышал (может врут), что это книга вредных советов небезопасного программирования и якобы современных реалий не учитывает. Вы как думаете?

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

Ты обидел меня! Я уйду с форума!

metaprog

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

Кстати да, идеально подходит %)

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

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

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

Моя позиция такова - сложнее потому что пытаются все заоптимизировать. Rust им тыкает в лицо - вот 10 неэффективных мест. Они бегут из исправлять, потом сдаются - Rust плохой. Python просто в это время прячет 10000 неэффективных мест. Надо успокоиться и писать просто, а потом оптимизировать по мере надобности

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

Я вот заменил для интерактивной работы

• grep -> ripgrep
• roxterm -> alacritty
• Приглашение bash -> starship
• ls -> exa
• cat -> bat
• du -> dust
• ps -> procs

Просто alias вкатал с парой дефолтных ключей. Прямо все в разы удобнее вменяемее и быстрее. Написано на Rust. И врядли там все приседали со штангой чтобы экономить на каждом чихе (разве что ripgrep), просто брали и писали обычный понятный код, в пару проектов я заглядывал. Хорошая экосистема позволяет писать такой крутой софт очень быстро и просто

C

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

Rust тут при том, что эти штуки по 20 лет до ума доводили, а на Rust высрали их более мощные и равно-эффективные (а то и быстрее) эквиваленты за месяцы-год. Потому что формошлеп-формошлеп, cargo install и побежал

на Rust высрали

Вот это ты хорошо и точно сказал, да.

И что? Все работает в разы лучше и удобнее. Консоль прямо преобразилась

Ну в прямом в Го нельзя создать либу

А это чем не либа?

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

Однако это не отменяет тот факт, что это либа.

У тебя, что ни сообщение, то лютейшее 4.2.

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

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

Вопрос. Если бы их переписали на Go, Dlang или еще какой-то язык, то получилось бы так же хорошо и ты бы отзывался аналогично?

я поддержу всех православных ^)

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

Раст действительно сложнее, потому что заставляет организовывать работу программы в процессе написания кода, а не выполнения его в отладчике, как это делается в C/C++/etc.

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

по крайней мере это не python, js, php...

20 лет до ума доводили
эквиваленты за месяцы-год

Потому что доводить уже ничего не надо, просто нашлёпать.

Плюсану за паскаль.

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

Кусок хлеба прилетит, в отличии от хвалимого раст.

паскаль
Кусок хлеба прилетит

А хотелось нормальную зарплату. Так что лучше на Rust.

C++

А что, кстати, по Go для нубов можно почитать?

Rust тут при том, что эти штуки по 20 лет до ума доводили, а на Rust высрали их более мощные и равно-эффективные (а то и быстрее) эквиваленты за месяцы-год.

вы это серьёзно или правда не понимаете, что это так не работает?

«египтяне десять тысяч лет свою армию готовили, а славяне высрали её более мощные и равно-эффективные эквиваленты за месяцы-год»

По-моему ты бредишь

Так чего ж ты на С не напишешь сразу шикарно что-то современное? Вся же матчасть готова.

А нет, придется опираться на говнолибы, которые дрожащими руками барыга-мейнтейнер в подвале после того как в очередной раз упоролся. То-то Линукс DE разваливаются на ходу с года в год. Давно плазма не падала? Подожди 5 мин

И ещё вопрос: проги на go не требуют компилятора go в зависимостях?

https://www.golang-book.com/books/intro http://www.golangbootcamp.com/

Нет, полный статический линк. Им libc даже не надо

Работают в буквально пустом докере, без дистра

Нет.

С - морально устарел. Rust лучше. С++ лучше. D лучше. Всё лучше.

Но ваш пример - дурацкий - утилиты вроде ls в принципе, без разницы, на чём писать, если руки правильно растут. И 20 лет непрерывной разработки ls не велось - мелкие багфиксы и периодические мелкие правки согласно очередным модным веяниям.

То-то Линукс DE разваливаются на ходу с года в год

Давно плазма не падала?

лет 10

Подожди 5 мин

подождал. не упала

подождал. не упала

Undefined behavior он такой, иногда работает

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

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

по крайней мере это не python, js, php...

Нет, по сути это как раз питон с пхп. Просто эффективные профессионалы могли высвобождать память и использовать ее, или выделять и не высвобождать - выяснилось, что в больших проектах это уже никуда не годится, и нужно, чтобы какой-то программный сторож сам следил за говном. Этапы скатывания разработки соответствуют развитию железа, а никак не прогресса технологий софтостроения - в девяностые резко возник бум языков с GC, хотя большое кол-во аналогичных проектов всего 10 лет назад не взлетали: Java, Python, PHP, Ruby, JS появились именно в девяностые, когда был пик скорости роста вычислительной мощности ядра ЦП. И эти же технологии в нынешнее время не способны показать роста производительности на нескольких ядрах - они были изначально спроектированы под одно ядро, и только жабу с горем пополам удалось распалаллелить, и то в этом результате можно усомниться, поскольку однопоточная жаба работает значительно быстрее.

В 70-80-х годах язык со сборкой мусора не мог получить успех, потому говнокодили на C с его склонностью проглатывать ошибки и делать неявные преобразования типов незаметно для пользователя (вещественное в целое, целое в указатель, целое в символ).

С - морально устарел. Rust лучше. С++ лучше. D лучше. Всё лучше.

Очень большой вопрос. Когда у тебя программа в 10 строчек на крестах компилируется больше секунды, то возникет сомнение в том, что же лучше - C или C++. Разрабы хрома плачут кровавыми слезами, в очередной раз собирая хром по несколько минут на 32-ядерном сервере сборки.
Для мелких проектов C вполне может оказаться лучше. Для отдельных высокопроизводительных функций он может быть лучше. C++, как бы не был ужасен, для средних-крупных проектов лучше, чем C, но это уже соревнование сортов говна.

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

А тут (Стоит ли переписывать проект с Go на Rust? (комментарий)) ты пишешь, что переписывать проекты с X на Y не нужно.

У тебя раздвоение личности, или ты просто троллишь тупостью?

Это код какой то. Я хочу либу. so файл