В чем смысл Rust?

Во времена моей работы на прошлой работе, мы столкнулись с Go на Эльбрусе. Нужная нам программа была на Go. И хуже того, аха-ха! Программу эту писал наш бывший сотрудник. Т.е. наша же программа, была нам нужна теперь под Эльбрус, а компилятора на тот момент не было и не предвиделось. Весело. Вендор-лок язык.

вкусный сыр бывает только в мышеловке.

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

Если завтра неугодная Америке страна сделает свой проц,

То и форк rust’а и crates.io тем более осилит.

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

Это плата за скорость. Когда тупо ничего нет то и тормозить нечему.

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

В С массив это вообще не структура данных, С-массив не знает даже свой размер. Массив в С это соглашение о том что будем считать непрерывный выделенный участок памяти - массивом. Ни размера, ни метаданных, ни операций над элементами. И они называют «это» массивом. Тьфу!

Выход за границы массива - не проверяется, передача массива в функции - все сам, поиск по массиву, не не слышали. Сортировка - реализуй сам, ты ж учил 100-500 вариантов сортировок, ну вот вперёд и с песней. Динамический массив - 3 из 5 сишника накодят его с утечкой памяти.

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

Иногда лучше на ассемблере, чем вестись у вашего нового поколения пепси, эмо еще там кого, шут вас разберет квадроберов, Щас я все вам перепишу на Расте, Гоу и прочих новомодных штуках. А потом хренак, надо же, удивительно – ничего не работает, спасите-помогите. Никогда такого не было и вот опять.

В целом, согласен. Добавлю

Это плата за скорость.

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

Пьёте?

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

Вне контекста текущего обсуждения:

1. У эльбруса ж был режим совместимости с x86. Отменили?

2. А как же gccgo?

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

Это все-равно все некоторая шляпа. Есть компилятор gcc –> lcc, есть два языка Си и С++, на которых писать легко и нормально. Питон перенесли, потому что там компилятор на С++. Зачем еще себе трудности создавать, пиша на каких-то экзотических языках? И потом героически их решать.

что насчёт обыденного жонглирования?!

ващет квиксорт вроде как в стандартной либе - которая часть типо язычка

ну да лол с

a[i] и i[a] которые в обоих случаях просто сахар для *(a+i*sizeOftype) 

уж лучше на таких https://t.me/memokard/2334

в котором можно (на самом деле нужно) контролировать каждую мелочь Это плата за скорость.

Это не всегда так. Про раст не могу примеров привести, но в тех же плюсах иногда абстракции ускоряют код. Например инстанцирование шаблонов вместо сишных void* или девиртуализация методов вместо сишного ООП на указателях в структурах. Тут по-разному бывает.

С-массив не знает даже свой размер

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

Массив в С это соглашение о том что будем считать непрерывный выделенный участок памяти - массивом

Это так почти в любом компилируемом языке, в том числе и в расте.

Ни размера, ни метаданных, ни операций над элементами.

Метаданные есть, операции чтения/записи элемента есть.

передача массива в функции - все сам, поиск по массиву, не не слышали

Это лишь синтаксический сахар и убогость стандартной библиотеки. На скорость это вообще никак не влияет.

в том что теперь

только так :

https://t.me/memokard/2313

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

И у С есть ниша (примерно такого же уровня)

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

Когда тупо ничего нет то и тормозить нечему.

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

С-массив не знает даже свой размер

Неправда, знает. sizeof подтвердит. А если завернёшь в структуру, то даже сможешь воспользоваться оператором присваивания для копирования массивов.

Ни размера, ни метаданных, ни операций над элементами. И они называют «это» массивом. Тьфу!

Действительно, тьфу. Более жёсткая модель массива дала бы больше свободы компилятору по оптимизации, как у фортрана, к примеру.

Иногда лучше на ассемблере

Ты что, это же вендор-лок!!11

Не совсем понял, что имеется ввиду. Если сам с/с++ можно в асм перевести.

Я бы с удовольствием работал бы на асме, если бы такие работы еще остались. Кто-то скажет, что много рутинного, но можно автоматизировать. Там тоже есть макросы.

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

А, в этом смысле. Это можно обыграть. В принципе Си так и появился, ассемблер с макросами.

llvm чем не асемблер

али wasm какой тож

да и jvm тож ассемблер хоть и dalvik смуту внёс в «заведомую» стековость машины

да и clr тоже машина повсеместная

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

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

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

Кодить прям на ast я пока не пробовал ))))

Неправда, знает. sizeof подтвердит.

Вот, в этом весь С. Массивов нет, но есть буффер в памяти и набор битовых операций, так что можно притвориться, как будто массивы есть.

В развитых языках тип определяется через набор операций над ним. Массив — это штука, соответсвующая протоколу массивов. Что за операции и как оно там внутри устроено — тут можно обсуждать и спорить. Но это уж точно не «вот вам указатель на начало области в памяти, а дальше как хотите».

Кажется тут конфликт математиков с программистами. У программиста есть выбор на кого опереться, на математиков или на физиков. Математики говорят, что массив – все, что соответствует протоколу массивов. А физики говорят, что вычислительные машины устроены не так.

Вот отсюда и спор. И тут я по своему жизненному, профессиональному опыту ближе к физикам. Математическая хрень конечно хорошо, не не здесь.

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

Массивов нет

Так вот же, положила: sizeof массива знает его размер, есть набор операций вроде доступа к элементу массива.

вот вам указатель на начало области в памяти, а дальше как хотите

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

Так вот же, положила:

TEST1> (defvar *a* (make-array '(3 4) :initial-element 42))
*A*
TEST1> (array-rank *a*)
2
TEST1> (array-dimensions *a*)
(3 4)
TEST1> (setf (aref *a* 1 2) 43)
43
TEST1> *a*
#2A((42 42 42 42) (42 42 43 42) (42 42 42 42))
TEST1> (reduce #'max (make-array (array-total-size *a*) :displaced-to *a*))
43

Вот это массив. А в С — буффер в памяти.

Это лишь одна точка зрения, не истина последней инстанции

Джоэл Спольски – «Абстракции всегда текут». Закон дырявых абстракций. Какую бы абстракцию ни придумали, идеальной нет и не будет. Всегда придется спускаться на уровень машины. Всегда. Если хочешь быть хорошим программистом, пиши на чем предлагает работодатель, но имей ввиду, что все-равно придется дружить с физиками, а не с начальством.

Ну, в Си мало встроенных функций, но делает ли это массивы не массивами? Так ведь можно договориться и до того, что структуры в Си - просто буферы в памяти.

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

В Си точно так же. Что можно делать с указателями, в стандарте написано (разыменовыать валидный, сдвигать, но не раньше начала и не после указателя на после-последнего, вычитать один из другого, сравнивать указатели на один и тот же объект, и т.д.). Указатели — это не числа: есть provenance, а ещё стандарт не гарантирует, что каст указатель -> uintptr_t -> указатель вернёт тот же указатель: https://nullprogram.com/blog/2016/05/30/.

Вот тебе и абстракция, разнообразие реализаций и т.д.

Вообще можно почитать тут (https://begriffs.com/posts/2018-11-15-c-portability.html) — в частности, про то, что была лисп-машина, на которой запускалась сишка, на которой касты указателя в/из числа не работали так, как мы сегодня этого ожидаем. Но оно соответствовало стандарту.

А у вас тут разговор слепого с глухим (ab surdus).

но делает ли это массивы не массивами?

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

Мой ответ: вещь определяется через то, что ей делают. Буфер — это штука, которую можно выделить, заполнить, прочитать весь, прочитать частично, удалить. Массив это то, на чём удобно делать операции с массивами. Хотя бы простейшие матричные операции: транспонирование, скалярное, векторное умножение и т.п. Строки это то, что позволяет удобно работать с текстом.

Всегда придется спускаться на уровень машины. Всегда.

Именно поэтому самыми популярными языками программирования являются питон и джаваскрипт. Да.

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

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

Кто как конечно. Но это же фу

Массив это то, на чём удобно делать операции с массивами.

Это слишком грубое определение. Под него и хешмапы какие-нибудь могут подойти.

Ну это ширпотреб быдло-кодинг.

Отмазка «мы не маргиналы, мы элита» была зарезервирована за лисперами решением комитета по дурацким отмазкам при ООН от 4-го декабря 1989-го года. Придумайте что-нибудь своё.

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

Вообще, позиция защитников сишки напомнила мне строчки из руководства по gforth:

3.32 Arrays and Records

Forth has no standard words for defining arrays, but you can build them yourself based on address arithmetic. You can also define words for defining arrays and records (see Defining Words).

One of the first projects a Forth newcomer sets out upon when learning about defining words is an array defining word (possibly for n-dimensional arrays). Go ahead and do it, I did it, too; you will learn something from it …

Интерпретирующие машины машины интерпретирующие фундамент прогресса

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

и это - обычный асм это всё таки сплошная построчная императивщина меняющее состояние некоторой абстрактной машины - и прикол именно в том что для писания на асме нет необходимости в доскональном знании сей машины

AST ближе всёж к «идеальному»(без set*) лиспу

ps. всякие докерцы досбоксы вайны оне не без интерпретации - и очередное подтверждение что существенная часть кода просто не требует raw мощи

Это лишь одна точка зрения, не истина последней инстанции

@

Джоэл Спольски – «Абстракции всегда текут». Закон дырявых абстракций.

/thread, тему можно закрывать )

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

Этот спор изначально не имеет смысла тк каждый язык предлагает свою картину мира:

С - давайте думать с помощью адресов участков памяти и указателей на них.

Lisp - давайте думать с помощью ячеек и списков.

Javascript - давайте не думать, а просто делать.

итд.

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

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

Не напрягайтесь так

И с чего Ви взяли, что я напрягаюсь?

С - давайте думать с помощью адресов участков памяти и указателей на них.

Каких ещё адресов? Есть вот реализация Си на лисп-машине (подробности по моей ссылке выше). На этой машине нет никаких адресов, есть только лисп-объекты. Указатель, в этой реализации Си — лисп-объект. Ты его можешь конвертировать в число, получится какая-то ерунда. Но если ты эту ерунду преобразуешь обратно в указатель — ты получишь какую-то ерунду вместо указателя на исходный объект.

Стандарт позволяет реализовать витуальную машину Си без всяких адресов.

Lisp - давайте думать с помощью ячеек и списков.

И что, связные списки везде использовать? А как получать элемент за O(1)?

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

с доступом по индексу за O(1).

Если мы добавляет это правило к понятию «удобно работать», то асссоциативные массивы сразу же вылетают из определения. Всё продумано.

ЕМНИП, в PHP массивы сделаны через ассоциативные массивы потому что фрактал плохого дизайна там где используют PHP доступ за O(1) не важен.

Вы, кстати, свой ответ так и не предоставили: чем буфера, массивы и строки отличаются друг от друга?

Почему же тогда Lisp SBCL самый последний в Benchmarks Game?

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

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

Какие ещё примеры, которые мне нравятся? Это среднее по всем бенчмаркам на Benchmarks Game. Там ЛNСП самый последний. Это очень известный проект.

Авторы Benchmarks Game пристрастны? Или что ты хочешь сказать?