Опубликован релиз языка системного программирования Rust 1.40, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52081
> макросов "bang!()", напримерИ чем думали разработчики? Слово "bang!" явно пропагандирует насилие и убийства, особенно в отношении темнокожих афроамериканцев. Им необходимо исправить эту ошибку, пока мы не подали в суд на Mozilla за оскорбление чувств оскорблённых.
Проблема философии XXI века: кто или что было появилось раньше оскорбление или оскорбленные...
Раньше такие долго не жили.
С++ хватит всем.
+100500 Зачем нужен еще один монстр
Ну как зачем? Нужно больше языков, больше говнокурсов, больше некому не нужных кодеров, а самое главное больше книжек
> Ну как зачем? Нужно больше языков, больше говнокурсов, больше некому не нужных
> кодеров, а самое главное больше книжекЕще мозилла очень хочет свой маленький но гордый клон Apple Store. Ну или хотя-бы репу cargo, если с продажей приложений и огораживанием девайсов не задалось...
Ересь!
ANSI C наше всё.
как быть с абстракциями? файл по старинке изображать в виде чехарды буффера, структур и разбросанных функций?
Обструкцию вашим абстракциям.
Потому на Луну больше не летаем, что абстрагируемся, абстрагируемся да никак на абстрагируемся.
Гонишь ведь, ООП позволяет писать и тестировать программу по кускам, что не позволяет С
Тогда лучший выбор - интерпретаторы бейсиков и пайтонов и прочих.
Позволяют по одной команде писать.
Сам понял че сказал? Где я говорил о скоросте и простоте написания программы?
А я где?
Написал print(2+2) и тут же протестировал, нажав Enter.
Такой код, безусловно
Это не С виноват, а кривые руки.
ООП это часть языка, а не рук
да как бы Си не запрещает ООП... немного некрасиво будет выглядеть, то в принципе много где реализовано... вот чего реально не хватает в сях - так это темплейтов, иногда макрос сильно неудобно дебажить
Инкапсуляцию и наследование как реализовать без магии?
--point.h--
struct Point;--point.c--
#include "point.h"struct Point
{
int x;
int y;
};--main.c--
#include "point.h"int main()
{
struct Point p1;
p1.x = 10; //ERROR
return 0;
}О чудо, неужели это инкапсуляция!? Но как такое может быть???
Наследование тактично не заметили да? И фразу "без черной магии" видимо тоже, то есть штатными средствами
Боюсь показаться придирчивым, но есть ощущение, что сообщение при ошибке компиляции только неявно укажет на проблему.
> Гонишь ведь, ООП позволяет писать и тестировать программу по кускам, что не позволяет СЧего бы это не позволяет? Вполне себе, я так и делаю зачастую. А так то и ООП можно использовать правой пяткой в левый глаз, видал пару колоритных примеров.
> Потому на Луну больше не летаем, что абстрагируемся, абстрагируемся да никак на абстрагируемся.Да ладно, дело вовсе не в этом. В компьютере Apollo было 5-7 виртуальных машин[1], причём полностью софтварных, потому что аппаратной виртуализации ещё не придумали. И это несмотря на то, что оперативки было всего 2Kb. Ты недооцениваешь программистов, думая что они не напихали в аполло абстракций.
Мы не летаем на Луну, потому что это коммерчески невыгодно. Летать туда за патриотизмом -- моветон: весь патриотизм, какой там был, оттуда уже вывезли пендосы. Хотя китайцы может и подберут, что осталось на донышке. Если успеют.
[1] https://www.theatlantic.com/science/archive/2019/07/underapp.../
> как быть с абстракциями?/* car.h */
struct car;
enum car_drive_direction { FORWARD, BACK };
enum car_door { FRONT_LEFT, FRONT_RIGHT, REAR_LEFT, REAR_RIGHT };struct car *car_alloc ();
void car_free (struct car *);
void car_engine_on (struct car *):
void car_engine_off (struct car *):
void car_gearbox_set_gear (struct car *, unsigned);
void car_drive (struct car *, car_drive_direction);
void car_door_open (struct car *, car_door);
void car_door_close (struct car *, car_door);> файл по старинке изображать в виде чехарды буффера, структур и разбросанных функций?
Встречный вопрос: в плюсах приватные методы и поля всё ещё принято светить в заголовочных файлах?
Префикс не панацея, а жесткий костыльЗаголовочный файл каким образом влияет на инкапсуляцию?
Не нужна никому твоя инкапсуляция, хоспаде
Функции тогда выпили, инкапсуляция как никак хоть и примитивная
Функции - естественно и небезобразно, в отличие от натужных инкапсуляций и прочих объектно-ориентированных извращений.
Чем Классы противоестественны если функции естественны?
Даже не знаю как ответить.
"Не следует множить сущее без необходимости"? (Оккам)
Функции выкидываем? Goto наше все?
void foo(){}
int main(){ foo(); return 0;}===
call foo
foo:
ret===
Что-нибудь подобное с классами и прочей ахинеей?
> Что-нибудь подобное с классами и прочей ахинеей?NOP с классами? Do-o-oh.
Тогда мне https://duckduckgo.com/?q=%22Lisp+1.5+manual%22+&#...
заверните "первые" четыре тома Кнута.
Упарываться только не надо, раста с головой
А теперь надо расширить
struct car
до
struct super_carИ добавить пару ф-ций к super_car
void super_car_wings_open (super_car car *);
void super_car_wings_close (super_car car *);Причем super_car должна содержать все атрибуты car таким образом, что если позднее в car добавят атрибут, он должен появиться и в super_car. Список атрибутов car должен определяться в одном месте (без дублирования).
Ну и, соответсвенно, комплект функций car_* должен корректно работать с super_car
Причем афтар не шарит шо c99 является подмножеством C++, и даже так быдлокодить кресты ему не запрещают
Причем ответчик или не в курсе разницы ANSI C и C99 или читать не умеет, а потому переходит на личность, обвиняя в быдлокодерстве.-- Программы Клюга выглядят просто жутко. Там полно соплей, которые он
не удосужился подчистить. Но он был гением, и его программы работают
безукоризненно, хотя вас и не покидает недоумение, как же это они все-таки
работают. Служебные программы у него так написаны, что у меня мурашки по
спине бегали, когда я с ними разбиралась. Жуть! Но по-настоящему хорошее
программирование такая редкость, что его недоделки выглядят лучше, чем та
гладкая чепуха, которую пишут середнячки.Джон Варли. Нажмите "ВВОД"
Путаешь с K&R C, ANSI C это как раз C99
?
(gcc -ansi) == (gcc -std=c89)
Нет?
Пруф в виде флага компилятора очень убедителен эт да, а ничо шо именно K&R C был положен в основу стандарта C89, а C11 вполне себе ANSI?
The original ANSI C standard (X3.159-1989) was ratified in 1989 and published in 1990.
Не подскажете, где находится ANSI C11?
В качестве стандарта ISO/IEC 9899:2011
"... ISO/IEC 9899:201 ..."
Никак ANSI не разгляжу в этой строчке.
Сейчас стандартизацией С не только ANSI занимается
Рад за Вас и за стандартизацию.
Вот только наверху я написал "... ANSI C ...".
ANSI C такого языка не существует, есть стандарт с кодовым обозначением, а название историческое шоб не путали c99 принятый ANSI с c89 принятый все тем же ANSI, C11 при участии ANSI и чо не ANSI да?
"ANSI C такого языка не существует..."
Хера се!
Вы раскрыли мне глаза!
До сих пор я прозябал в неведении.
Процитирую свою же запись ранее прозябавшего меня двумя этажами выше:
"The original ANSI C standard ..."
Лол C99 тоже ANSI пилил, так какой из них ANSI C или все таки конкретизируем на полном наименовании ANSI X3.159-1989 а не на сленге?
> Джон Варли. Нажмите "ВВОД"Охренеть. Я думал не осталось уже людей, которые читали эту книгу.
Охренеть. Я думал так же.
(po.ke) (li.ve)
Пошаговая инструкция, как покончить жизнь самоубийством при помощи микроволновки.
А потом на 8 уровне таких вложений программист скажет нет лучше уж раст)
глянет на раст и скажет ну нахер
Нет, ну ты видел? ВИДЕЛ?!Да ну нахер.
Синтаксис настолько жесткий шо нет слов, страшно правда
Да, синтаксис, конечно, не c#. Но можно немного покрутить настройки rustfmt, тогда код становится более читаемый. Но, справедливости ради, в плюсах такая же каша
> Синтаксис настолько жесткий шо нет слов, страшно правдаИ то ли дело:
#define MAP_LIST(f, ...) EVAL(MAP_LIST1(f, __VA_ARGS__, ()()(), ()()(), ()()(), 0))
volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
или
if(!C) {
l=(o=S].O)?S].I:0; I=o?S].l%9+1:(S].O=i%9+1);
for(;l<81;l++,I=S].O,o=0) if(!(s]>>10)) {
for(;;I=I%9+1,o=1) {
l0=0; if(o&&I==S].O) goto O;
if(s]>>I&1) {
S].l=I; S++].I=l; S]=S-1];
N(I,); O>w&&(w=O); goto lO;
}
}
}
😏
Все это отлично решалось еще во времена динозавров с помощью макросов, которые легко и просто раскрываются либо в сишные структуры со списками функций (включая виртуальные), либо в классические плюсовые классы. При этом ни капли не теряя в читабельности.https://www.cs.rit.edu/~ats/books/ooc.pdf (c) 1993(!!!) год.
Хотя о чем это я, современные "программисты" же книг не читают...
Программисты читают книги в которых пишут вещи поумнее, чем тут описаны.Эмуляция наследования через агрегацию, ха-ха ктобы сомневался.
Вот пример оттуда.
struct Point {
const void * class;
int x, y;
};
struct Circle { const struct Point _; int rad; };В результате использовать поля объекта приходится так
static void Circle_draw (const void * _self)
{ const struct Circle * self = _self;
printf("circle at %d,%d rad %d\n",
self —> _.x, self —> _.y, self —> rad);
}Это типичное не то.
Сколько уровней наследования, столько промежуточных обращений, чтобы добраться до поля.
> Программисты читают книги в которых пишут вещи поумнее, чем тут описаны.
> Эмуляция наследования через агрегацию, ха-ха ктобы сомневался.Ха-ха, кто-бы сомневался, что макака-неосилятор спрыгнет на "мне же неудобно". Чтобы макаке было удобно, макака может написать макрос, который спрячет все эти неудобности.
Спасибо, крутая книжка, почитаю
>Встречный вопрос: в плюсах приватные методы и поля всё ещё принято светить в заголовочных файлах?Нет, в плюсах мы используем pimpl: https://en.cppreference.com/w/cpp/language/pimpl
.. который до сих пор даже студия не умеет скипать при дебаге; да и вообще:Access overhead: In pImpl, each call to a private member function indirects through a pointer. Each access to a public member made by a private member indirects through another pointer. Both indirections cross translation unit boundaries and so can only be optimized out by link-time optimization. Note that OO factory requires indirection across translation units to access both public data and implementation detail, and offers even fewer opportunities for the link time optimizer due to virtual dispatch.
Space overhead: pImpl adds one pointer to the public component and, if any private member needs access to a public member, another pointer is either added to the implementation component or passed as a parameter for each call to the private member that requires it. If stateful custom allocators are supported, the allocator instance also has to be stored.
Lifetime management overhead: pImpl (as well as OO factory) place the implementation object on the heap, which imposes significant runtime overhead at construction and destruction. This may be partially offset by custom allocators, since allocation size for pImpl (but not OO factory) is known at compile time.
>который до сих пор даже студия не умеет скипать при дебаге; да и вообще:Это всё описание старого подхода. В современном С++ никто не мешает использовать статический pimpl без перечисленных оверхедов.
>>который до сих пор даже студия не умеет скипать при дебаге; да и вообще:
> Это всё описание старого подхода. В современном С++ никто не мешает использовать
> статический pimpl без перечисленных оверхедов.это уже не pimpl.
https://www.youtube.com/watch?v=_AkF8SpUV3k вот вам pimpl без хипы
видосик? серьезно??
> Нет, в плюсах мы используем pimpl"Мы" это кто? Хотя бы 10% плюсовиков так делают на постоянной основе?
>>Встречный вопрос: в плюсах приватные методы и поля всё ещё принято светить в заголовочных файлах?
> Нет, в плюсах мы используем pimpl: https://en.cppreference.com/w/cpp/language/pimplВау. То есть таки решили (причём лишь частично, при изменении публичных интерфейсов один фиг потребуется рекомпиляция потомков) одну из проблем кривой реализации объектной модели в C++, да и то ценой потерь в рантайме и усложнением сопровождения кода. Класс. Обожаю кресты.
Урри, что-нибудь получше в крестах изобрели, не подскажешь? А то я давно в этот лес не лез, и если честно, не особо хочу.
Без пространств имен нафиг не сдался
скажи это линуксам
И чо? Все внезапно станут ядрописателями или как то смысл твой не уловил
Пространство имён хорошо помогло герою Мягкова в фильме "Ирония судьбы ...".
Единственный известный положительный случай.
Конфликт имен тебе обеспечен
Там модули, это лучше namespace-овю
Более того, без модулей в rust не добавить файлы с исходниками (привет инклудам), и структуру файлов надо, о ужас, продумывать заранее.
Сначала после мышления в стиле плюсов выглядит дико, но потом начинаешь понимать изящество решения.
Rust сольется в первой же партии не трать время на спор, лучше глянь на предыдущего убийцу цепепе
C++20 Modules так то, православные тоже не стоят на месте
В плюсы сейчас много идей заимствуют из современных языков, из раста в том числе.
Посмотрел что предлагалось на встрече комитета - так штук 5-6 предложений - дежавю после раста.
Годиков через 5-10 эти 2 языка будут больше похожи друг на друга)
Но у С++ есть много наследия из прошлого, с которым будет трудно.
Тем временем появится армия безработных растаманов, то шо их прелесть стала никому не нужна, вот я о чем, на C++ работа будет всегда, а мейстрим ЯП пока популярно, имхо C++ никогда не был популярен, а ему скоро ему сорокет стукнет
ах из раста... модули в плюсы с 2000 года пытаются впихнуть, тогда не то что растом, мазилой даже еще не пахло.
C++ видите ли не молодежный
Тут не в молодёжности дело, а в самом c++
Ломать совместимость с Си предлагаешь или о каком фатальном недостатке C++ идет речь?
Модули немного для другого, а именно для замены инклудов, пространства имен в модулях юзаются еще как, представь себе Qt поставляемый в виде модулей без данной технологии
А вот нечего все валить в кучу.
Описывай паблик интерфейсы, разбивай проект на независимые части и собирай отдельно. Заодно электричество на пересборке сэкономишь.
Ну так собстенно и делают, другого выхода нет, раздельная компиляция
Другой выход, само собой, есть. Например, макросы со сменой префикса.Просто именно такой способ - простой и правильный.
Черной магии и без макросов хватает
Ну почему магии? Макросы бывают очень удобными и наглядными https://github.com/swansontec/map-macroЯ вот подобный макрос использовал чтобы сделать более наглядными ассемблерные вставки (да, иногда и такое по работе приходилось делать), без засоряющих код "\n" и "\t". Причем, заметьте, мне не пришлось для этого изобретать новый язык.
Функциональные макросы наглядные? Да ладно, шоб я сдох
Хм, вы предпочитаете __asm__("\tmov a,b;\n\tmov b,c\n"), а не __ASM__("mov a,b", "mov b,c")?Занятно...
Предпочитаю не использовать в C++ асемблер и Си-специфичный синтаксис, я манал изобретать уже изобретенное, да и с компилятором шо ты шо я шо сам линус деточка с лапаткой в песочнице, сомневаюсь шо в вашей конторе используют процессоры отличные от x86
Ну ты манал, а я изобретаю еще НЕ изобретенное и иногда приходится писать даже на ассемблере (причем в позапрошлом году за такое мне гугл, например, деньги платил).Ну а вообще, про libffi слышал, деточка? можешь посмотреть на список поддерживаемых платформ: https://github.com/libffi/libffi/tree/master/src
Переизобретаешь COM? Ну ну деточка
> Ну почему магии? Макросы бывают очень удобными и наглядными https://github.com/swansontec/map-macroЯ конечно всё понимаю, но после того, как взглянул на макросы в лиспах, смотреть на пляски с сишным препроцессором уже довольно-таки больно. Не, я понимаю, когда слаще репы не едали -- это выглядит, как рокет-сайнс, да. Но это же жуть на самом деле, Урри. Даже окамловый PPX выглядит лучше, чем это, хотя он на самом деле тоже жуть, но он хотя бы типизирован и гарантировано формирует корректный AST.
> #[non_exhaustive]Ну, ООП не настолько плохо :)
ООП вообще тема особенно в плюсах, если бы не шаблоны(
Ага, особенно в геймдеве. Пилишь игру по принципам ООП, а через год нужно добавить фичульку, а хрен ты что добавишь не переписав все по новой, так как все данные уже разбиты на объекты с методами.
Надо просто не г**нокодить, а писать нормально в ООП. Все кто плюются на ООП просто неосиляторы, которые не умеют и в функциональщине нормально кодить, а потом так же, нифига не умея, пытаются натянуть ООП на быдлокод и удивляются, что там ещё сложнее писать отстойный код.
чес слово ооп жуткая вещь. если ты заранее не продумаешь весь проект с заделкой на добавление/изменение, то это гемор страшный. а про поддержку вообще молчу. лучше уж на функциональщине.)) а раст все равно страшен как..... извини какой образ представить чтоб пояснить? наверно как редактить данные в консольном tex)) освоить можно, но стремно до жути. за последние годы придумали столько всего нового, а все тарые языки типа с/с++ остались в тренде. причем часто слышу , что говнокодящие в плюсах на ооп часто имеют большой нагоняй от начальства.
Ничего не страшная, для тех фич которые забыли в классе но не хотите в него лезь есть наследование, хотя корректнее всеже расширение существующего класса новыми методами свойствами, так что класс вполне себе может обрастать костылями если с проектированием все плохо
Есть принцип обобщенного интерфейса public например sendMassage, а внутри класса уже должна содержаться конкретная реализация sendEmail, sendXMPP, sendTelegram и прочие тонкости того как реализовать внешний интерфейс класса он же API
C++ без классов и шаблонов это почти Си, так что те кто говорит шо ООП плохо или не рубят нифига в нем либо не рубят нифига в нем, иначе зачем писать на C++ в стиле Си, если есть Си
Хруст такая же подделка как гоу и всякие D, пара лет хайпа и на кладбище к остальному мейнстриму
В том и драма что нифига они на свалке не оказываются, а всякие васяны на них в своиъ маня мирках дальше изобретают. Го уже поболее 2х лет и все никак блин :(
Плюсую, зачем на каждую проблему переизобретать целый язык, один фарс
вот зачем тебя папа с мамой сделалали, васяна с детского сада вполне хватило бы, ты ничем не лучше
Лол што? я же не претендую на массовость
Плох тот Васян, который не мечтает выйти в тираж!
Я же не Страуструп
Лолшто? Чем тебе не угодил брат анон труп страуса и почему ты это пишешь в одно слово?
Мал ты еще шоб об ООП с шаблонами с тобой говорить
> Мал ты еще шоб об ООП с шаблонами с тобой говоритьКакое-то у тебя шаблонное мышление, анон!
> Плюсую, зачем на каждую проблему переизобретать целый язык, один фарсБоюсь, это не фарс, а просто мир перестраивается под новые реалии. А реалии таковы, что IT-сообщество на 99.99% состоит из армии обезьян. Вот поэтому эти языки и появляются. Также, как когда-то появлялись Fortran и C. Их тоже поначалу хаяли. А затем стали повсеместно использовать. И с этими будет так же.
Дык есть же джаваскрипт. Зачем два языка для обезьян?> Также, как когда-то появлялись Fortran и C. Их тоже поначалу хаяли. А затем стали повсеместно использовать. И с этими будет так же.
Кроме фортрана и цэ появилось еще 100500 языков - http://helloworldcollection.de/ - подавляющее большинство из них помнят единицы. И с этими будет так же.
Да, помнят лишь единицы. Но у этих единиц есть кое-что общее: поддержка бизнеса.
Но вы же не такой, да?
Нет, почему же. Я очень даже такой. =)
А можно пруфы про хаяние С ?
> А можно пруфы про хаяние С ?О, боюсь, что это весьма затруднительно. С архивами 70х-80х -- это уже даже webarchive не поможет. Тут уже нужно поднимать библиотеки вполне себе технических и научных журналов. Вполне вероятно, что нам дорога на Sci-Hub.
Уж кого-кого, а Дейкстру мы там скорее всего отыщем. Но одного человека, хоть и с именем, имхо, как бы мало.
Пара лет? А ничего что Go уже лет 8-10 используется?
Где он используется, кроме пачки хелловордов на гитхабе и ненужнодокера? Ах, нигде...
Корпорации пилят на Go платформы. Как у нас, например.
Типа веб, типа очень нужный и полезный, с софтом что хре упакуеш для переноса, ага понятно
Lamoda, Mail.Ru, Joom - это только те, кого я знаю лично. Если походишь на московские Go митапы, услышишь про Avito, Badoo и многих других.
DropBox помню.
А вообще, мне кажется не так то сложно погуглить.
> DropBox помню.Не, конкретно Dropbox -- на Rust-е.
А так в целом плюсую. Полно народу на гошечке сидит. Вон те же aptly, kubernetes -- всё на golang.
Да уже почти в любой IT компании.
Docker, не?
Синтаксис конечно у ржавого будто кресты изнасиловали
Почему как? Даже обидно.
Насиловали жестко
Тяжело живётся в чужой стране, когда не умеешь читать на её родном языке, не так ли?
Хз, а тебе? Ты в стране хрустонии наверное обитаешь, да?
Похоже, понятие "аналогия" для вас слишком сложно. И что это за мода такая - коверкать название языка? Детский сад какой-то, хорошо ещё меня Березовским не дразните.
Аналогия с чем?
согласен.
просто какой-то взрыв мозга.. извращенцы..
Зато какой клевый у плюсов синтаксис, для того чтобы отстрелить себе ногу на ровном месте.
Не смей обижапть синтаксис ХРУСТА!!!
Мы обижаемся на его синтаксис
На хрусте можно наконец то войти в айти?
> На хрусте можно наконец то войти в айти?Обычно это айти входит в тебя, а не наоборот...
Все никак не пойму чем Rust так обожаем? Может синтаксисом, так не такое же уг в стиле C++ с синтаксическим сахаром от которого диабет уже начиная с C++11, может безопасностью, так нет мешанина unsafe и safe кода по определению не может быть безопасной, объясните пожалуйста зачем оно?
Для того чтобы это понять, нужно очень хорошо знать С++, и работать со сложными проектами где проблемы С++ вылазят и доставляют много боли.
После этого посмотреть на раст и понять, как он большую часть этой боли решает, в т.ч. благодаря пониманию программистом идей и способов написания корректно работающего кода.
Перечисли будь добр не проблемы C++ потому что это и фига языка одновременно, а именно то шо хруст решает
Совместимость с С та еще фига в кармане)
Вся суть C++ это борьба с тем уродством который называют няшным Си, тут тебе и указатели, и строки-массивы, и сегфолты, и ацкий синтаксис со звездочками, и упоротые макросы и стопитсот другого гемора
Чего стоит альтернативный синтаксис указателя vasyan[0] вместо *vasyan, итого массив как бы тупо указатель, но передается в другой указатель как не указатель, можно невозбранно херачить *vasyan=vasyan[0], при том что правильно было бы **vasyan=vasyan[0] и такого сладкого хлеба в Си и следовательно в плюсах хватит каждому братишке
Сам хоть понял че написал?)) сразу видно что ты не разбираешься в Си, более того, банально путаешь такие понятия как массив и указатель. И самое печальное, что вас таких умников дохера и больше!
Ну давай расскажи чем vasyan[1] отличается от *vasyan++ или почему для "массива" не нужен оператор адреса *vasyan=mas работает как же так, если только mas не адрес на первый элемент участка памяти в котором лежат данные? Ты же гуру все знаешь, обьясни по пацански
Не путай тёплое с мягким!
Сперва ответь себе на следующие вопросы, что такое в языке Си:
1) объект
2) указатель
3) массив
А затем спроси себя, чем отличаются эти понятия:
1) указатель и адрес
2) массив и имя массива
Ты ведь понимаешь, что это разные понятия?
Читая твои предложения, складывается стойкое очущение что нет!
K&R не читал да? Риччи сам пишет шо массив есть альтернативная форма записи указателей или ты самый умный?
Не надо врать и вводить в заблуждение других!
Идите и сами для начала прочитайте эту книгу в оригинале - такого бреда там нет!
Если я не прав, давай сюда номер страницы где это сказано?
Глава 5.3 Указатели и массивыНачиная с...
Между индексированием и арифметикой с указателями существует очень тесная связь. По определению
значение переменной или выражения типа массив есть адрес нулевого элемента массива. После
присваиванияМожет наконецто дойдет
А что у нас может хранить адрес? Напомни будь добр
А вы странный:)))
Теперь сравните это с тем бредом, что вы написали выше:
>>>Риччи сам пишет шо массив есть альтернативная форма записи указателей<<<Если вы не в состоянии увидеть разницу - то увы, я тут ничего не могу поделать:(
Васян ты питоном упоролся или в терминологии полный ноль?
Объект в Си? Ну разве что файл как единица трансляции, больше никаких объектов в нем нет
object is a region of data storage in the execution environment.
В таком понимании в Си объектов нет
Идите и читайте стандарт языка си, хотя об этом также сказано и в K&R
Приведи главу, а не разглогольствуй
В книге есть такая вещь, которая называется Index.
Пожалуйста, сделайте самому себе одолжение и научитесь им пользоваться - уверяю вас, это очень полезно.
Че сам не научишься и требуешь пруф?
Пруф за пруф
> Пруф за пруфХех, а я помню этот момент, так что намекну, где искать, и где товарищ лукавит.
Такое определение объекта и правда было дано в стандарте/драфте ISO/IEC емнип 2005го что ли года. Тогда пошла серия шуточек из разряда "смотрите, в С тоже есть объекты". Но они в общем-то были тухлыми, поскольку все понимали перегруженность термина object, и воспринимать его буквально было уделом людей в общем-то недалёких.
Что собственно понятно, потому что у K&R понятие объекта тоже было. Но не в таком виде. У них было что-то вроде "именованной области памяти". Вот собственно тут и есть лукавство, ибо товарищ заявляет, что "это ещё у K&R было". И скорее всего именно по этой причине он никогда не предоставит пруф.
Но в общем и целом, тут всё равно надо понимать, что слово object -- оно буквально должно пониматься как объект, вещь, сущность, штука. Так что да, когда человек говорит об "объекте в языке Си", в котором обычно этот термин в повседневной работе с ним не употребляется от слова совсем, тыкая собеседника в его якобы "некомпетентность", а сам аппелирует при этом к стандарту ISO -- то надо этого буквоеда ссаными тряпками хлестать, пока у него катарсис не случится.
>>>Такое определение объекта и правда было дано в стандарте/драфте ISO/IEC емнип 2005го что ли года. <<<Определение понятия объект, именно в таком виде, дано ещё в самом первом стандарта языка С языка (ISOC90).
Так что не нужно писать, того в чём вы не разбираетесь!
Запомните, если в какой-либо книге сказано одно, а в стандарте говорится другое - то любой профессионал вам скажет, что нужно верить тому, что написано в стандарте, а не в книге!Так что, можете все ваши пожелания в мой адрес, успешно адресовать самому себе и балбесам вроде вас!
> Так что не нужно писать, того в чём вы не разбираетесь!
> Так что, можете все ваши пожелания в мой адрес, успешно адресовать самому себе и балбесам вроде вас!О, какие мы горячие. Надо же.
> Определение понятия объект, именно в таком виде, дано ещё в самом первом стандарта языка С языка (ISOC90).
Я конечно мог попутать год стандарта, поскольку эти писульки в основном предназначены для разработчиков компиляторов сей, и посему в чтение оных я никогда особо не вдавался. Но я не мог попутать определения, данного K&R. И я готов предоставить пруф хоть сейчас, поскольку уж что-что, а исходный вариант K&R мы найдём весьма легко, в отличие от драфта C90.
Вот K&R, пожалуйста, найди там данное тобой определение: http://www2.cs.uregina.ca/~hilder/cs833/Other Reference Materials/The C Programming Language.pdf
Ты не сможешь этого сделать. А вот я своё -- легко найду. Потому что я-то не балабол, и за слова пруфлинком отвечу.> Запомните, если в какой-либо книге сказано одно, а в стандарте говорится другое - то любой профессионал вам скажет, что нужно верить тому, что написано в стандарте, а не в книге!
Ага, вот то-то ребята в институте Макса Планка который год уже сидят и находят противоречия в стандарте, да никак вылизать до конца его не могут. То-то у нас такая тьма неопределённого поведения.
Я вот что тебе скажу по этому поводу: вы, буквоеды драфтовые -- не специалисты ни разу; любой хакер знает, что верить надо исходнику либо тесту. Потому что реализация всегда впереди стандарта.
Мог бы молча проглотить и убраться подальше. А теперь обтекай, ламер.
>>>эти писульки в основном предназначены для разработчиков компиляторов сей, и посему в чтение оных я никогда особо не вдавался.<<<Тогда нам не о чем дальше разговаривать!
P\S: Продолжайте и дальше ссылаться на K&R словно это библия какая-то - я не против:)))
> Тогда нам не о чем дальше разговаривать!Вот и молодец. Правильное, разумное решение.
>>>поскольку уж что-что, а исходный вариант K&R мы найдём весьма легко, в отличие от драфта C90.<<<Ну и совсем напоследок: вот держи для саморазвития, любитель пруфа:))
http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2...
>>>>поскольку уж что-что, а исходный вариант K&R мы найдём весьма легко, в отличие от драфта C90.<<<
> Ну и совсем напоследок: вот держи для саморазвития, любитель пруфа:))
> http://read.pudn.com/downloads133/doc/565041/ANSI_ISO%2...Клёво, спасибо! Извинения приняты, Иван.
Если есть понятие объекта как ты утверждаешь, должен быть и класс? Где классы?
Вы ведь должны понимать, что одно и тоже понятие, необязатально везде и всегда, будет обозначать тоже самое!
Можешь в конкретику? образы это удел питона
И главное, приоткрой занавес тайны почему индекс первого элемента массива равен нулю? поржу хоть
Ловите паскалиста реликтового !
Pascal как язык программирования, более продуман по сравнению с С. Он не стал столь массовым только из-за хайпа UNIX.
> И главное, приоткрой занавес тайны почему индекс первого элемента массива равен нулю?
> поржу хоть---
> A postfix expression followed by an expression in square brackets [] is a subscripted
> designation of an element of an array object. The definition of the subscript operator []
> is that E1[E2] is identical to (*((E1)+(E2))).Оно?
Ну да индекс это смещение указателя относительно начала участка памяти
> Ну да индекс это смещение указателя относительно начала участка памятиНу дык - из этого определения следуют очень интересные "возможности", которые (имхо) намного нагляднее примера "*foo vs. foo[0]" демонстрируют "синтактический сахаризм" (или скорее -- наследие ограничений древних компиляторов):
#include <stdio.h>
int main(void) {
int bar[6];
4[bar] = 10;
char* foo[2] = {"hello","hello"};
1[foo] = "world";
int y = 2334;
int *x = &y;
0[x] = 1337;
puts(*foo);
puts(1[foo]);
printf("%d\n",0[x]);
return 0;
}% gcc -Wall -Wextra hw.c && ./a.out
hello
world
1337 10
;)
Ладно спойлер, а то эксперт загрузился, ноль в качестве индекса на первый элемент обозначает нулевое смещение с начала участка памяти на которую он указывает, компилятор просто преобразовывает vasyan[0] как *vasyan, так работает адресная арифметика
Массив это просто синтаксический сахар над указателями, с некоторыми фичами, но это больше про многомерные массивы, такими как выделение памяти под индекс с указателями, к которым хрен доберешься из языка, такая условность
> Чего стоит альтернативный синтаксис указателя vasyan[0] вместо *vasyan, итого массив как
> бы тупо указатель, но передается в другой указатель как не указатель,
> можно невозбранно херачить *vasyan=vasyan[0], при том что правильно было бы **vasyan=vasyan[0]Вы не понимаете основ.
Все просто: любой указатель указывает на массив. Но в большинстве случаев это массив из одного элемента.
Поэтому для доступа к первому элементу массива придумали специальный синтаксис со звёздочкой.
А ещё указатель можно сдвинуть, поэтому *(arr+x) эквивалентен arr[x].
Поэтому и индекс первого элемента 0.
Ну вот ещё один:(((
Причина всех этих, казалось бы на первый взгляд странностей в том, что в языке Си, по банальной причине неэффективности, отсутствует возможность работать с массивом целиком!
Что значит отсутствует? Тут их целых две сразу.
Давайте, удивите меня очередной порцией бреда:)
Прошу в студию ваши две возможности!
Вы не можете работать с массивом целиком, означает: что вы не можете скопировать массив просто написав a1 = a2. Следовательно, также Вы не можете передать массив целиком в функцию в качестве аргумента; вы также не можете вернуть массив целиком из функции, просто потому что это неэффективно каждый раз копировать массив целиком!
А ты не думал почему так? Может быть потому что имя массива это указатель который передается? А?
Чувак, без обид, но ты просто безнадёжен:))
Однако, Например в том же языке Rust такая возможность есть, хотя опять же вы должны понимать что это неэффективно.
Там много чего ненужного есть и шо? Копировать массивы в функцию/метод считай создавать новый массив, память жрет, софтина тормозит
ЩИТО?
Массив это как бы по определению участок последовательно размещеннных ячеек памяти, таким образом даже тип int, можно представить как массив из 4 байт и невозбранно записать туда четыре charint i=0;
char *s=(char*)&i;
*s='a',*(s+1)='n',*(s+2)='a',*(s+3)='l';
for(int i=0;i<4;i++){
cout << *(s+i);
}Таким образом мы получили массив char из 4 элементов, а вообще массив это просто сырая память которая и не в курсе шо она int, char и тд
Ну да, я про это и говорил нулевое смещение относительно начала, только мне ли ты ответил?
> Чего стоит альтернативный синтаксис указателя vasyan[0] вместо *vasyan, итого массив как
> бы тупо указатель, но передается в другой указатель как не указатель,
> можно невозбранно херачить *vasyan=vasyan[0], при том что правильно было бы **vasyan=vasyan[0]
> и такого сладкого хлеба в Си и следовательно в плюсах хватит
> каждому братишкеНу это... Вы по-видимому не понимаете основ сишного синтаксиса. Когда объявляется массив vasyan -- этот символ как раз указатель, раскрывается при использовании как раз в адрес. *vasyan -- это как раз взятие первого элемента по адресу vasyan. vasyan[i] -- это эквивалент *(vasyan+i). Следовательно vasyan[0] -- это и есть *vasyan. А вот **vasyan -- это уже *(*vasyan). То есть сначала надо взять первый элемент по адресу vasyan, трактовать его как адрес и взять уже значение по этому адресу. И это, как видите, ни разу не vasyan[0], который в сущности есть *vasyan.
И таки да, поскольку такие вещи, как оказалось, молодому программисту для понимания слишком сложны -- как раз и создаются новые языки типа Rust или Go. Вам дай в руки чистый C, так вы ж с ним наворотите невесть чего. Поэтому новые языки -- как раз для вас и писаны. Изучайте. =)
Смеешься чтоли? Я же написал что синтаксис массива сахар над указателями
> Смеешься чтоли? Я же написал что синтаксис массива сахар над указателямиРазумеется сахар. И что? Ведь ты также написал, что
> правильно было бы **vasyan=vasyan[0]
А это прямо говорит о непонимании арифметики указателей. С чего вдруг "правильно было бы"? Правила раскрытия этих конструкций не позволяют такой трактовки -- и точка.
Уверен? А спорим, что данное утверждение имеет правду только в случае многомерного массива, когда создается индекс с указателями на участок памяти, я об этом писал, если ты не видишь смотри лучше, случае одномерного массива используется обычный указатель *vasyan, в двумерном **vasyan, потому что он содержит адрес первого указателя индекса, который в свою очередь ссылается на участок памяти
> Уверен? А спорим, что данное утверждение имеет правду только в случае многомерного
> массива, когда создается индекс с указателями на участок памяти, я об
> этом писал, если ты не видишь смотри лучше, случае одномерного
> массива используется обычный указатель *vasyan, в двумерном **vasyan, потому что он
> содержит адрес первого указателя индекса, который в свою очередь ссылается на
> участок памятиЧувак, да в одном твоём сообщении больше символов, нежели нужно для банальной проверки твоего утверждения. Почему тебе не лень написать сообщение, но лень написать меньшее количество символов для его проверки? Хочешь я напишу? Это займёт от силы минуту. =/
В студию!
> В студию!И кто меня за язык тянул... Всегда ведь, всегда найдётся кто-нибудь, кто поймает на слове... И слово придётся держать... =/
freehck@home:~$ cat test.c
#include <stdio.h>
typedef unsigned long ul;
int main(void) {
ul arr[2][2] = {{1,2},{3,4}};
printf("%lu %lu %lu %lu %lu\n", (ul)arr, (ul)*arr, (ul)arr[0], **arr, arr[0][0]);
return 0;
}
freehck@home:~$ gcc -Wall -Wextra test.c
freehck@home:~$ ./a.out
140732652187392 140732652187392 140732652187392 1 1
> Уверен? А спорим, что данное утверждение имеет правду только в случае многомерного
> массива, когда создается индекс с указателями на участок памяти, я об
> этом писал, если ты не видишь смотри лучше, случае одномерного
> массива используется обычный указатель *vasyan, в двумерном **vasyan, потому что он
> содержит адрес первого указателя индекса, который в свою очередь ссылается на
> участок памятиПозвольте вмешаться :)
О каком "индексе с указателями" идёт речь?
В объявлении int arr[N][M]; нет никаких указателей.
Объявляется массив из N массивов (а не N указателей на массивы).
И занимает он память в N*M интов.А вот как определяется массив из указателей:
int x[2] = {1,2};
int y[2] = {3,4};
int (*a[2])[2] = {&x,&y}; // можно и {x,y}, но будут предупреждения компилятора
int *b[2] = {x,y}; // можно и {&x,&y}, но будут предупреждения компиляторану и доступ к элементам
a[0][0][0] // 1
или
***a // 1 ведь * - это "сахар" над [0] :)))b[0][0] // 1
или
**b // 1
> Смеешься чтоли? Я же написал что синтаксис массива сахар над указателямиНее, "синтаксис массива сахар над указателями" - это ошибочное утверждение, в корне неверное и искажающее всю суть языка С :)
Всё с точностью наоборот :)
Как я сказал, указатель - это массив (например из одного элемента).
Обратное утверждение, что массив - это указатель, не имеет смысла.Массив первичен, а указатель - лишь средство передачи ссылки на массив (технически, адреса массива, который совпадает с адресом первого элемента массива).
Т.е. '*' - это "сахар" для массива, для взятия первого элемента, чтобы писать не arr[0], а *arr.
А потом ещё определили и арифметику над указателями (ещё один "сахар"):
- прибавление N к указателю даст ссылку на под-массив, начинающийся с N-ого элемента от начала исходного массива.А ведь в некоторых языках, например в Pascal, арифметика над указателями не определена.
Кстати, начните с изучения Pascal, а уже потом беритесь за более сложные вещи, такие как C.
Массив это не более чем сырая память, можно массив int mas[10], внезапно сделать типа char, просто обращаясь к нему как char* x=(char*)mas, и получим массив из 40 символовНасчет обратных утверждений массив это вполне себе память, переменная тоже память, попробуем найти разницу между массивом и переменной, возьмем int x=0 и обратимся к ней как char* s=(char*)&x и внезапно переменная становится массивом
Синтаксический сахар это обращения к значению как имя[index]
>> Массив это не более чем сырая память, можно массив int mas[10], внезапно сделать типа char, просто обращаясь к нему как char* x=(char*)mas, и получим массив из 40 символовС точки зрения компилятора массив это не просто сырая память, а набор элементов определённого типа. И кастинг "char* x=(char*)mas" нарушает strict aliasing rules и как следствие может приводить к UB (но для char * вроде пока? есть исключение из правил). Но не суть.
>> Насчет обратных утверждений массив это вполне себе память, переменная тоже память, попробуем найти разницу между массивом и переменной, возьмем int x=0 и обратимся к ней как char* s=(char*)&x и внезапно переменная становится массивом
Ага. Оператор & создаёт ссылку на массив. Хотя опять нарушение strict aliasing из-за кастинга к char*. Только не обращайтесь к переменной x через указатель s - получите UB.
>> Синтаксический сахар это обращения к значению как имя[index]
Не-а.
Это _базовая_ операция обращения к элементу массива - даже в Java такая есть.
А "сахар" - это *ptr (эквивалент ptr[0]) или ptr-> (эквивалент ptr[0].) - этого в Java нет.
И арифметика указателей тоже "сахар" - и этого ни в Pascal ни в Java нет.
Поинтер в C - это алиас массива.И это особенность C по сравнению, скажем с Java, где всё кроме примитивных типов - объект, а ссылка на объект вроде как и поинтер (может быть null), но с этим поинтером нельзя работать как с массивом.
А еще только C++-сники, в массе своей не знающие C, пишут * возле типа, что не правильно :)
Пример:
int x;
int(*a) = &x; // - объявление поинтера,
(int*)b = &x; // - не компилируется :) Ибо (int*) b не есть l-value.
(int*)(a = &x); // - наверно так? Но это не объявление поинтера.
*(int*)a = x; // - а можно ещё так. Но это тоже не объявление поинтера.
(int*)(c) = &x; // - и так тоже не компилируется.
Ничего такой кастинг не нарушается, значит когда память аллоцируешь и приводишь ее к нужному тебе типу с помощью указателя так это видите ли нормально, а когда массив плохо? Для указателя абсолютно фиолетово с каким типом работать, привет void*, насчет расставления звездочек оно имеет значение в константных указателях, ну и в указателях на указатель указателем погоняющим, в простых без разницыВся соль в том, что из таких багофич C/C++ состоит чуть менее чем полностью
> Ничего такой кастинг не нарушается, значит когда память аллоцируешь и приводишь ее
> к нужному тебе типу с помощью указателя так это видите ли
> нормально, а когда массив плохо?Когда память аллоцируешь, у malloc есть специальный атрибут __attribute__((malloc)), который подсказывает компилятору, что возвращаемую память можно кастить к любому типу и проблем со strict aliasing не будет.
Массив или другой объект это не важно. Важен тип объекта.
> Для указателя абсолютно фиолетово с каким
> типом работать,Ага, только вдруг с новым компилятором ломатся код, работающий годами.
А читать про strict aliasing вам лень.
Ну вот хотя бы 3-я ссылка в гугле: https://habr.com/ru/post/114117/> привет void*,
А для void*, как и для char* сделали исключение :)
Интересный пример про string aliasing (из https://stackoverflow.com/questions/2958633/gcc-strict-alias...):unsigned long a;
a = 5;
*(unsigned short *)&a = 4;- компилятор может выкинуть последнее присвоение, т.к. ему понятно, что указатель unsigned short * ну никак не может указывать на переменную a, ведь её тип - unsigned long.
> насчет расставления звездочек оно имеет значение в
> константных указателях, ну и в указателях на указатель указателем погоняющим, в
> простых без разницыну это про стилистику, как отличить программиста на C от программиста на C++ :)
> Вся соль в том, что из таких багофич C/C++ состоит чуть менее
> чем полностьюПолностью согласен.
Через void* любой тип можно кастовать в любой тип вполне легально, так как void* не проверят тип на который ссылаетсяНасчет С и С++, я искреннее рад шо си в крестах из года в год все меньше
https://www.reddit.com/r/rust/comments/dzyceo/what_advantage.../
вот весьма политкорректная подборка, советую почитать
Посмотрел главные доводы, он просто лучше... Серьезно? Вот так просто, капец, он безопаснее, он эффективнее, где когда применялся, откуда инфа, чисто теоретически Haskell лучше C++, но это же не так
На реддите люди достаточно компетентные пишут. В т.ч. авторы самого языка rust, а также популярных crate-ов. Им можно верить, хотя бы на столько чтобы попробовать самому)
Авторы самого языка ясен пень будут петь песни какой он огого, ну и фанатики как и всего нового тоже есть
Я очень хорошо знаю С++, давно работаю со сложными проектами - вообще не понимаю зачем Раст нужен.Вся эта мифическая боль отлично решается в С++ всевозможными библиотеками. А если что-то еще не решено (хотя так не бывает, ибо все уже давно написано на С++), то всегда можно взять и самому решить.
Кроме того, С/С++ более лаконичен и красив; как на больших кусках кода, так и на маленьких. Не верьте мне - сходите на https://www.rosettacode.org/wiki/Category:Rust и сравните решение типичных задач на расте и других языках программирования. Заодно если там наговнокожено - напишите свой, красивый вариант, а мир оценит.
Как зачем? Ради еще одного не нужного языка, каждый год какой то убийца чего то появляется, вон даже на жабу покушались камень скала котлин какой то диалект лиспа, плюсы не исключение
человеческий мозг устроен так что он ищет и жажде постоянно чего то новое
если завтра появится какой то язык фейспалм, продвигаемый какой то не бедной компанией
появится много одептов его и считающие что это решение всех проблемесли посмотреть на одептов раста
это в большинстве случаев молодые люди студенты или недавние выпускники вузов
Их то и жаль
Решите диагностику использования инвалидированных итераторов в compile time.
Во-первых, Rust - это не то чтобы улучшенный C++ (частично, конечно, это так). Скорее это прагматичный Haskell и Rust имеет более консистентный дизайн, чем плюсы. Язык избавлен от легаси и имеет довольно целостную экосистему, достаточно элегантно решая при этом множество проблем других языков.Во-вторых, все плохие практики разработки на низкоуровневом языке в Rust отключены по умолчанию (мутабельность, прямое управление памятью и т.д.). Благодаря этому ты не можешь накосячить случайно, а там, где ты хочешь сделать что-то стремное, ты должен явно об этом сказать компилятору - дальше, если что-то пойдет не так, ты сам себе злобный Буратино. Более того, оказалось, что 99% процентов кода можно легко написать на безопасном подмножестве Rust, так еще и дизайн кода выйдет лучше просто за счет соблюдения ограничений safe-подмножества Rust. Кроме того, соблюдая ограничения, нацеленные на обеспечение безопасности работы с памятью, ты еще и бесплатно получаешь потокобезопасность, которую, насколько я знаю, другие существующие языки предоставить не могут.
В-третьих, система типов Rust предоставляет достаточно информации компилятору, чтобы потенциально обогнать C++, а возможно и C.
Благодаря этим качествам в низкоуровневое программирования становится гораздо легче вкатиться новичкам (предполагаю, что это главная и тщательно скрываемая причина хейта к Rust - он подрывает элитарный флёр C/C++ разработчиков, ведь теперь даже любой JS-дев может при достаточных усилиях написать эффективный безопасный низкоуровневый код и не страдать).
Синтаксис не слишком чистый, с этим спорить не стану. Но это не то чтобы самое главное в языке. Мне плюсовый синтаксис подавно не нравится, уж лучше чистый C, чем плюсы.
Сам себе противоречишь вначале синтаксис конфетка, в последнем абзаце констатация унылости
Я скорее говорил о системе типов, чем о синтаксисе, когда перечислял достоинства. Не путайте одно с другим.
Классный дизайн и отсутсвие легаси это не про синтаксис? Почему тогда если можно было создать офигенный ЯП без легаси создали гомункула от которого кровь стынет в жилах?
Вкусовщина, конечно, но про "кровь стынет в жилах" никак не соглашусь. Я лишь сказал, что синтаксис не слишком чистый. Тем не менее, он и не ужасный. Наоборот, есть много приятных деталей. Та же философия everything is expression зачастую позволяет решать некоторые задачи более элегантно.Меня лично смущает лишь обилие спецсимволов ('!?$), но к этому привыкаешь, потому что они играют важную роль. Ну и зря они притянули как есть синтаксис дженериков с угловыми скобками - без type алиасов сложные выражения с дженериками читать сложно.
Отсутствие нормального ООП не смущает?Кровь стынет в жилах на полном серьезе, он же совершенно не читаем
ООП в расте реализовано в полной мере, кроме наследования типов. Разделение поведения производится посредством типажей (трейтов), которые можно имплементировать для разных типов или даже сделать generic blanket имплементацию для множества типов, удовлетворяющих определенным условиям. Наследования же нет совершенно намеренно. Причина - наследование многими считается антипаттерном, в том числе создателем Java:https://www.javaworld.com/article/2073649/why-extends-is-evi...
> If you could do Java over again, what would you change?
> I'd leave out classes
> Кровь стынет в жилах на полном серьезе, он же совершенно не читаемНу, тогда язык не для вас. У меня ничего не стынет и все читаю. Зачем желчь попусту пускать?
Как код повторно используете?
> Как код повторно используете?Сказали ж т-те: трейты в крейтах! Ч-чо не понятоно-то?77
Я непонял, а полиформизм?
Полиморфизм на уровне трейтов. Причем, благодаря опциональному динамическому диспатчингу можно, например, даже создать массив из объектов разных типов, но имплементирующих указанные трейты.
Класс мало было прототипов JavaScript которые таки перепилили в классы, теперь залупень в виде трейтов, боже мой куда мы катимся
> Я непонял, а полиформизм?Трейты в крейтах с поли-хери-тансом.
Прекрати уже, иди учиться коммунизму настоящим образом.
Кхм. Полиморфизм в ООП -- это только одна из разновидностей полиморфизма, полиморфизм подтипов.
> ведь теперь даже любой JS-дев может при достаточных усилиях написать эффективный безопасный низкоуровневый код и не страдатьА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА!
Собственно, реакция, подтверждающая мои слова.
Собственно, реакция, подтверждающая мой громкий хохот.Эффект Даннинга-Крюгера во всей своей красе.
Как скажете.
Да, в данном случае именно как скажу - ибо чтобы писать "эффективный безопасный низкоуровневый код" надо уметь программировать и понимать, что ты делаешь; а не иметь "правильный" инструмент.Это как чтобы делать "эффективную и безопасную операцию на селезенке" надо иметь хирургическую практику, знать что такое селезенка, как она функционирует, как функционирует весь организм, что можно и что нельзя с ней делать.
Вы же сейчас открытым текстом заявили, что любой дворник может делать операции на селезенке, если ему дать умный скальпель, который не позволяет делать некоторые ошибки (например, не позволяет взять себя не той стороной).
Во-первых, я сказал "при достаточном количестве усилий". Для этого JS-деву придется хотя бы понять разницу между стеком и кучей. Но по крайней мере, он сможет это сделать не потратив годы на развитие навыка уклонения от подводных камней C/C++. Тем не менее, я совершенно не имел в виду, что код такого дева будет также хорош и эффективен, как код настоящего системного программиста, получившего неоднократное посттравматическое расстройство после работы с C/C++.> Вы же сейчас открытым текстом заявили, что любой дворник может делать операции на селезенке, если ему дать умный скальпель, который не позволяет делать некоторые ошибки (например, не позволяет взять себя не той стороной).
В общем-то да. Я надеюсь и верю в будущее, когда благодаря технологиям люди смогут сами себя лечить от серьезных болезней, не выкладывая огромные деньги медицинским картелям.
> Для этого JS-деву придется хотя бы понять разницу между стеком и кучей.Для того, чтобы научиться программировать JS-деву надо не "хотя бы понять разницу", а учиться программировать. И точка.
> не выкладывая огромные деньги медицинским картелям.Вкупе с JS выше это утверждение выглядит довольно органично. Это ничего, что хирурги овладевают профессией очень долго и очень сложно?
> Для того, чтобы научиться программировать JS-деву надо не "хотя бы понять разницу", а учиться программировать.Не спорю, только считаю, что с Rust у него это получится проще.
> Вкупе с JS выше это утверждение выглядит довольно органично.
А ваши рассуждения отдают банальным консерватизмом: язык, который завещали деды, медицина, которую зевещали деды. И не важно, что деды тех самых дедов жили свосем иначе и завещали совсем другое.
> Не спорю, только считаю, что с Rust у него это получится проще.С питоном - проще. С С или Паскалем - тоже проще. С Растом - однозначно нет.
> А ваши рассуждения отдают банальным консерватизмом
Жаль, что у вас сложилось такое мнение. Я никакого повода этому не давал; более того, выше я кому-то писал что очень люблю C#, хотя писать на нем сейчас нечего.
> С питоном - проще. С С или Паскалем - тоже проще. С Растом - однозначно нет.Мы ведь говорили об эффективном по потреблению вычислительных ресурсов надежном коде. С Python, при всех его достоинствах, такой код написать нельзя. Python защитит от UB, но динамическая типизация подарит вам океан других сложностей, не говоря уж о производительности и потреблении памяти. С прост, но вообще ни от чего не защитит, а навык написания дойстойного кода на C требует немалой практики.
Rust же имеет далеко не единственный механизм обеспечения надежности кода, помимо borrow checker. В Rust нет null (уже минус огромный класс фатальных и поразительно часто встречающихся ошибок). В Rust нет исключений, неявно нарушающих поток управления и не дающих разработчику понять, что вообще может произойти, когда он вызовает ту или иную функцию. Благодаря концепции владения, RAII в Rust позволяет достигать великолепных гарантий. Например, вы можете быть уверены, что открытый вами файл будет закрыт в любом случае, где бы не завершилось его время жизни, даже если поток запаниковал - при этом от вас не требуется ничего. И это на самом деле только вершина айсберга.
Да, Rust требует определенную цену за эти гарантии. Но гораздо проще и быстрее учиться, если плохой код попросту не компилируется, чем писать неправильный код, который будет спокойно себе работать годами в типичных условиях, а потом может стать слишком поздно узнавать, что на самом деле код неправильный.
Люди обращаются к простым высокоуровневым языкам не потому, что не могут осились C/C++, а потому, что не желают страдать и учиться ходить по канату над озером из лавы, жонглируя бананами. Из-за этого в мире на сегодняшний день целая гора ужасно неэффективного кода, потребляющего чудовищные ресурсы ради тривиальных задач. С другой стороны, с каждым годом в системном софте накапилвается все больше и больше ошибок и уязвимостей в силу дефектов проектирования C/C++. Rust имеет все возможности, чтобы это изменить: в мире станет больше низкоуровневого кода, а сам он станет надежнее. А в ответ только насмешки и мелочные поиски любых надуманных недостатков.
Дак и говорится о том, что теперь ему придётся потратить напорядок меньше усилий на обучение.мимо
Но согласись, что если тот же хирург будет "вооружён" специальным режущим прибором, который хотя бы компенсирует тремор, то эффективность операций повысится.
> Это как чтобы делать "эффективную и безопасную операцию на селезенке" надо иметь хирургическую практику, знать что такое селезенка, как она функционирует, как функционирует весь организм, что можно и что нельзя с ней делать.Я слаб в бестолковых сравнениях, Я правильно понял, что вы имели в виду следующее:
Это как чтобы функционирует делать эффективную и безопасную операцию организм, функционирует весь на селезенке надо иметь хирургическую практику, знать что такое селезенка, как она нельзя, что можно и что с ней делать и как.
?
При всей высокоуровневости JavaScript, нужно признать что язык ацки упоротый в отличии от питона и руби, C++ от мира веба
Щас вас макаки захейтят. Это же единственный язык, который они знают, а значит объективно посмотреть на дизайн они в принципе не могут.JavaScript действительно имеет худший дизайн из всего мейнстрима.
То шо они могут на JS вывести alert ниче не значит, там API умом тронешься и тебе мультимедиа, и звук, и 2d, и 3d, и DOM, и websocket, и webworker, и столько всего шо смело заявляю JS быдлокодоустойчивый язык
Нравится синтаксис С но не нравится C++? Ну ты петросян, а ниче шо у них один синтаксис на двоих?
> уж лучше чистый C
> чистыйВдумывайтесь, когда читаете, пожалуйста.
C99 грязный? или что тебя смущает?
На словах про консистентный дизайн подавился бутербродом. Не неси больше такой чуши, кто-нибудь и умереть может ненароком. На что уж C++ свалка, но ржа даже его переплюнула. На секундочку, плюсы стандартизируются комитетом профессионалов. У раста же нет вообще никакого ни стандарта, ни общего документа, ни-фи-га. Есть пачка противоречащих друг другу RFC, за которые хрен пойми кто когда-то проголосовал. В итоге мы имеем стабильный компилятор, в котором половина доступных фич доступны через фич-гейты, которых в стабильном компиляторе нет (хотя на самом деле они есть и используются, но как будто бы их там нет - само по себе ситуация идиотская и говорит об уровне "консистентного дизайна"). Да блин, язык системного программирования БЕЗ МОДЕЛИ ПАМЯТИ спустя десять лет (!!!) разработки - это очень, очень сильно.
> У раста же нет вообще никакого ни стандарта, ни общего документа, ни-фи-гаhttps://doc.rust-lang.org/reference/index.html
Язык C. Год рождения: 1972. Год появления первого официального стандарта: 1989. Год включения модели памяти в стандрат: 2011.
Язык C++. Год рождения: 1985. Год появления первого стандарта: 1998. Год включения модели памяти в стандрат: 2011.
Язык Rust. Год рождения (первая стабильная версия): 2015.
Основная причина, зачем С и C++ нужна была модель памяти состоит в том, что до ее появления многопточность в этих языках была попросту некорректной. В Rust даже без готовой модели памяти (над которой сейчас работают профессионалы с PhD) многопоточность находится на фундаментально ином уровне корректности, чем тот, какой когда-либо сможет позволить себе C или С++.
Над Rust работает не больше человек, чем работали над стандартами C/C++, так что ожидать появления полноценного стандарта намного раньше, чем оно было с C/C++ нечестно, особенно учитывая, что Rust куда более формальный язык, чем вольные C и плюсы.Извините, но выпад довольно дешевый.
Даже у мерзких крестов синтаксис и то человечнее
Ну что вы такое говорите. Как может быть нечеловечным такой красивый и интуитивно понятный синтаксис из "Getting started" с официальной страницы растпрограмминг?use ferris_says::say; // from the previous step
use std::io::{stdout, BufWriter};fn main() {
let stdout = stdout();
let out = b"Hello fellow Rustaceans!";
let width = 24;let mut writer = BufWriter::new(stdout.lock());
say(out, width, &mut writer).unwrap();
}
Глаза вытекли спасибо
да здесь-то как раз на плюсы похоже, а вот в самой новости реально что-то крючково-загогульное...
Про изнасилованный C++ выше
> Глаза вытекли спасибоА как на счёт ocaml:
let _ = print_endline "hello world";;Что-то мне подсказывает, что глаза с крестов вытекать не начнут после такого hello world-а.
Хотя казалось бы должны. =))
Беспощаден.
На любом языке можно писать на фортране, но зачем?fn main() { println!("Hello world"); }
Вы хотите сказать, что авторы раста на официальном сайте в разделе "getting started" специально говнокодят?А зачем, позвольте вас спросить?
Я хочу сказать, что искренне не понимаю, из какого наркоманского пособия этот код выдрали. В современном растбуке этого нет.
> Я хочу сказать, что искренне не понимаю, из какого наркоманского пособия...Так и запишем - "Getting started" с официальной страницы" является наркоманским пособием. И это все, что надо знать про этот модный молодежный язык.
Вот вам прямая ссылка: https://www.rust-lang.org/learn/get-started
Вы текст то читали? это не 'hello world'. Это пример вызова ранее созданной библиотеки, куда stdout передается в качестве параметра.
Читал, само собой.
А вы хотите сказать, что Раст обязан быть невырвиглазным только на хелло-ворлд примерах?Больше того я вам скажу, я исходники редокса смотрел (это уж точно не хелло-ворлд, правда?) - ужас-ужас-ужас просто. Идея у языка была хорошая, но отсутствие дизайна (модномолодежное уяк уяк и в продакшен) превратили простой и понятный хелло-ворлд язык в страшного франкенштейна.
А то ли еще будет...
В хрусте безопречный синтаксиссс
Кажется ИТ движется куда то не туда, есть C++ который постоянно допиливается, есть более лаконичные C# и Java, но тормозные, есть более тормозные и лаконичные Python и Ruby, но где место Rust я не понимаю, как и гоу ди эликсирам скалам и тд и тп, ужас вообщем не индустрия а супермаркет с тысячей наименований((((((((((
Go нужен чтобы питонщик в глаза С++ не видевший написал мега хайлоад из своего готового питон проекта. Например уперся в производительность, а денег на новый сервер нет (владелец сервиса сказал что нет денег). Особенно это актуально когда высь смысл бека обратится в базу отдать джейсон или получить реквест и положить данные в базу.
Ну как бы да, но как бы есть C# который более человечнее того же гоу, вопрос зачем, в гоу есть типы, есть компиляция
C# при рождении убил майкрософт своей привязкой к единственной расово верной платформе.А такой язык был, такой язык...
Как бы нет, в экосистеме винды он стал зрелым и без стопитсот кала от апача и прочих JavaEE, а чисто с некрософтофскими фреймворками, что уж очень облегчает обучение и разработку, сейчас просто выкатила на юникс в пику оракелю
Зрелым он был уже в момент выпуска, ибо его перед тем как писать сначала спроектировали (а не как эти расты, питоны и т.п.); я его тестил и восхищался.
Зрелым он не мог быть в момент выпуска, так как зрелость это опыт использования языка, C# прошел самый сложный тест... временем
Во-первых, нет, не опыт. Опыт использования C# принес по большому счету только правильные библиотеки. А язык программирования - это язык программирования, не библиотеки.Сам C# не изменился. Он оброс полезным сахаром (linq, ням-ням, обожаю), но не изменился так, как это делают всякие расты.
И во-вторых, как видите, не прошел. Поезд ушел, хотя я был бы только рад, если бы шарп наконец стал мейнстримным - я на моно, в свое время, достаточно времени и сил потратил; жалко.
Лол што? Тиобе пересмотрел? C# не прошел? Ну да поэтому наверное MS слила VB.NET, F# как тестовый полигон фич для сисярпа оставила, это же логично сливать васик который каждый бедуин знает в пользу какого то непопулярного ЯП да? Тиоб закройте пожалуйста, это фейл
Этот аноним порвался, несите следующего.
Ты типичный быдлокодер спорящий о плюсах и шарпе, хотя они из разных миров, давай JS vs PHP, а че бред должен быть абсолютным
C++ vs Python битва началась
Ты тот же порванный, или это уже второй сегодня рвется?Я не спорю о плюсах и шарпе, я пишу на плюсах и люблю шарп. Просто некоторые оторваны от реальности, вот я и объясняю как дела обстоят на самом деле.
Давай делись опытом как ты пишешь на плюсах любя шарп, просто интересно как в тебе две сущности уживаются?
У меня просто сложный мозг из сотни миллиардов нейронов, и они умеют выбирать инструмент под задачу.А у вас не так?
Работает из миллиардов сколько? Или ты давишь числом?
эмм... dotnet core и mono как бы уже много лет, вы там размораживайтесь, размораживайтесь
И джава, но питонщик быстро их не освоит. И тем более если это не банк, ни внутренняя CRM предприятия, а сайт по поиску дешевых авиабилетов. Заработало и хорошо, упало ну и пусть полежит.
Джава более упоротая, C# более прост, логично ведь создавался с учетом недостатков джава, а та крестов
На жаве я могу писать под пачку Ос, от серверных до мобил и встройки.Даже Питон выглядит привлекательней обрубка от корпорации.
Шарпей и рядом не валялся и обречен существовать принудительно на откаты корпорации.
Слушай фанатик не один из существующих ЯП не покрывает все области, Java может только Android, полное дно на дестопе, сервер зоопарк апаческий поделок+JavaEE+Spring вместо единого ASP.NET это лучше по твоему? Java может в игры? C# может и в Unity, CryEnginge, Godot, MonoGame? Java может в wasm? C# может бери Blazor и пользуйся, да C# не может в Android и все, но при этом может в нормальный пакетный менеджер nuget, плюсы перевешивают андроид, как не крути
> C# не может в Androidxamarin native же
Я не пробывал вот и не утверждаю
>Особенно это актуально когда высь смысл бека обратится в базу отдать джейсон или получить реквест и положить данные в базу.
>Ну как бы да, но как бы есть C# который более человечнее того же гоу, вопрос зачем, в гоу есть типы, есть компиляцияВот у меня бэк крутится исключительно на Linux.
Смотря шо, если тупо микросервис с API, go вполне себе, а если с намеком на интерфейс тут без ASP.NET как без рук
Ну стоит так категорично заявлять. Гуёвин вских под Го уже нормально так. Причём, что примечательно -- в 95% случаев без танцев с бубном собирается только под линями. (странно, что пигвинятники не подняли Го на щит)
C# умеет загибаем пальцы в нормальный десктоп, веб-дев аля MVC, микросервисы без гемороя и бесплатно
Бесплатно -- это очень громко сказано. Когда МС сделает очередной накат на СПО -- поздно будет пить боржоми. Вообще, трогать что-либо сделанное МС -- это подрыв скреп СПО.
Oracle наверное только ласкает но не входит да?
>Смотря шо, если тупо микросервис с API, go вполне себе, а если с намеком на интерфейс тут без ASP.NET как без рукДа микро, UI - vue.js вродебы неплохо, реактивно, молодежно.
Хороший выбор
C# -- заточены все тулзы под вендой. Нет уж, спасибо. Лучше го (да и вкуснее, прямо скажем).
Гонишь MS не сцит в отличии от прорицателя, а перепиливает NET Framework до внятного разделения на C#, базовые классы NET Standard, кроссплатформенные фреймворки ASP.NET, ADO.NET, EF и выпиливает нахрен WebForms, WCF и прочую "радость", четко выделяя виндовс специфичные фреймворки WPF/UWP из самого .NET, так шо не надо ляля
МС когда это всё разделит -- я уже на пенсию уйду. И вот могу поспорить на пару тысяч -- прежде, чем станет понятно, что они тупо бросили C# -- начнут пилить что-то вроде Y-lambda.
Круто в следующем году тебе, мне еще лет 25 пахать
> Круто в следующем году тебе, мне еще лет 25 пахатьНу так мне тоже ещё лет 50. Несмотря на стаж без малого 25 лет))
> что они тупо бросили C# -- начнут пилить что-то вроде Y-lambda.эM-эS-раст https://www.opennet.ru/openforum/vsluhforumID3/119137.html#133
нЭдорого! Скорее, пока не насалось123
А ничо шо MS пилит F#, последнее время забила VB.NET но было время, недораст и все переносит в C# ниочем не говорит? А powershell и вся инфраструктура винды под какой яп заточена?
>А
> powershell и вся инфраструктура винды под какой яп заточена?Под Апач-могильник.
Хотя может, и холмик Winux Fo. позолотят сообразно статусу.
Вас, у6*гих, поди разбеори.
Ты AES-ом смысл шифровал или как?
> Ты AES-ом смысл шифровал или как?Тьюрингом. Тестом Тьюринга.
Ну спасибо им за одолжение. Только эти потуги больше похоже на натягивание овечьей шкуры на волка.
Ну да анально огороженый андроид и чудо jvm которой без доната оракелю в комерсе не поюзаешь хорошая альтернатива проклятым балмерам, капец...
openjdk хватит на всех.
это как моно второсортность, вот NET Core это уже эталон который MS сам юзает и который будет основой NET5
Forth еще не проснулся вот придет и сотрет весь чет за хейт Раста.
Никто толком не может обьяснить зачем он нужен, еще один ЯП ну ок и чо? как то так
1) Уже всё сто раз объяснили, но недалекие всё равно ничего не поняли.
2) Типичное нытье "зачем нужен ещё один ЯП" уже всех достало. Лично вам не нужен этот ЯП, сидите дальше на своём js мусоре с "красивым" синтаксисом.
3) Хули вы не байткодите? Зачем вам столько ЯПов, когда у вас есть старый добрый байт-код?
На вопрос не ответил, так зачем он нужен?
А ты зачем нужен? Но да ладно, вебмакаки же не могут в поиск, вот тебе ссылка на статью 2010го года, там все расписали https://www.opennet.ru/opennews/art.shtml?num=28837
Но толку-то, ты все равно не умеешь читать, ибо с его основания веберастам доходчиво все поясняют, на что они тупо клипают глазами и говорят "я ничего не понял, так зачем нужно". Может хватит ума и научишься пользоваться поиском, а то растет поколение недо"программистов", которые даже гуглить не умеют.
Да какой поиск, эти "программисты" даже в комментах под этим тредом ничего не видят!
unsafe режим ставит раком всю безопасность и ржавый становится уродливой калькой на C++
Да, если ты вебмакака, то нехер объявлять функции и блоки кода как unsefe, ибо тут нужно понимание того, что ты делаешь.
Если ты не вебмакака и юзаешь safe он же по дефолту, значит ты дно в unsafe и большая вебмакака?
Ты дно, если юзаешь unsafe там, где его юзать нельзя. И ты такое же дно, если в плюсах/джаэсе/любомдругомЯП напихиваешь в код лишней херни, которая под конкретный случай нахрен не нужна. И ты дно, если обощаешь фичу под некоторые задачи до уровня всего ЯП.
Какой смысл юзать unsafe там где не нужно можешь обьяснить?
Вот в этом и суть, вы даже простое сообщение на русском языке правильно прочитать не можете, а в программирование лезете.
язык межнационального общения, так что знаю насколько могу
Эх, а так все хорошо начиналось.Вот что происходит, когда сначала пишут, а потом проектируют - язык все больше и больше напоминает франкенштейна, которому пришивают дополнительную руку, чтобы нога не отваливалась.
Синтаксис жесть
Делушко Вирт уже давно всем объяснил, почему эти ваши Си/С++ -- дрянь.
Язык -- конструируется. Си/С++ были сочинены. Это -- дурной пример инженерии.
Вы ведь даже не читали, что именно Вирту не понравилось в С++.
> Вы ведь даже не читали, что именно Вирту не понравилось в С++.Я вот не читал. Но у меня есть список весьма убедительных аргументов и без дедушки Вирта... =)
https://yosefk.com/c++fqa/index.html
Дичь какую то мозилла втирает, давно уже есть гибрид плюсов и удобства, JAVA и C#, менее известный D, зачем еще один? блин ну зачем
У создателя D скорее всего нет общего виденья, что нужно его детищу. Он уже пытается впихнуть борроу чекер в язык насмотревшись на руст.
У C++ тоже не было вектора развития, но в таких языках киллер фичей является шо он появился первый нах
Просто в мазиле не могли написать нормальный браузер на С++ он у них все время падал они решили что это не руки кривые, а язык плохой. Собственно за 9 лет развития они смогли написать на расте только парсер каскадных таблиц. ЧТД писать браузеры не их.
А писать просто либу для С++ как-то не кошерно.
При том что главным аргументом была МНОГОПОТОЧНОСТЬ, которая по дефолту в том же C++11 есть, велосипед велосипедом погоняет
> Просто в мазиле не могли написать нормальный браузер на С++ он у них все время падал они решили что это не руки кривые, а язык плохой.Пользуюсь мозиллой со времён первого фурифокса для работы и развлечений, а в хроме периодически пользуюсь гугл митом. Хром на плюсах падает чаще, чем гибрид раста и плюсов. ЧЯДНТ?
> Собственно за 9 лет развития они смогли написать на расте только парсер каскадных таблиц.
Ведь это настолько просто, что весь гитхаб забит реализациями парсера на различных языках. Нет чтобы хеллоуворлды на жеесе выкладывать.
> ЧТД писать браузеры не их.
Ждём ссылку на правильную реализацию браузера от Анонима. Форк хромиума не предлагать.
Хромиум бывает падает но сам процесс не вылетает (там такие смешные картинке он рисует про то что все сломалось, Опаньки и т.д.) И это плюс многопроцессорной организации и еще как побочный плюс хромиум всегда быстро стартует точнее рисует главное окошко. И на взгляд обывателя это и означает быстрее работать. При том что по бенчмаркам особого преимущества по скорости у фф и хромиума нет. Так что так, кто-то пишет браузеры кто-то пишет языки. И эти люде не пересекаются.
многопроцессной*
> Хромиум бывает падает но сам процесс не вылетает (там такие смешные картинке он рисует про то что все сломалось, Опаньки и т.д.)Да вот как раз валится основной процесс, со стектрейсом и прочим. Я как-бы умею отличать "опаньки" от падения собственно приложения.
> И это плюс многопроцессорной организации и еще как побочный плюс хромиум всегда быстро стартует точнее рисует главное окошко.
Как там в 2015? Даже тут на опеннете эксперты уже давно бугуртят на лису за многопроцессность.
> При том что по бенчмаркам особого преимущества по скорости у фф и хромиума нет.
Тут я согласен, на нормальной тачке они работают неотличимо на глаз. А вот если на машине мало памяти стоит, то лиса тут выигрывает за счёт меньшего потребления оперативки (примерно менее 4 гигов уже заметно). При дохлом процессоре оба лагают примерно одинаково.
> Так что так, кто-то пишет браузеры кто-то пишет языки. И эти люде не пересекаются.
Как это не пересекаются? Одни пользуются трудами других. И если люди начинают ходить в соседний бордель, то это означает, что в твоём борделе что-то не так. Если бы си, плюсы и прочие жавы были бы идеальны, то никто не изобретал бы расты с котлинами.
Затем, что D - это не меньший разброд и шатание, чем C++, только они обходятся без стандартизации и комитетов. Это я говорю, как бывший фанат D. Бывший потому, что надоело, что баги компилятора и языка не чинят годами и даже десятилетиями, усилия малочисленного ядра команды разработчиков тратятся на всякую хрень, абсолютно некритичную, новые фичи часто виснут в состояннии вечной недоделанности и прикрученности сбоку (т.к. там всего пара человек разбираются в теории типов и остальной релевантной computer science), экосистема очень вялая и неоднородная (многие библиотеки забрасывают, даже не доведя до состояния беты), общий подход к критике сводится к: мы тебе ничем не обязаны, пиши DIP, делай PR, а мы когда-нибудь посмотрим, если будет время, и вообще отстань, у нас много работы, надо кровь из ануса интеграцию с C++ делать, а не язык чинить.
Экскурс в будушее ржавого... спасибо
Не. Бесшовная интеграция с плюсами - это безнадёжное дело. Только D ставит себе такую цель.
Помню сколько пафоса было вокруг Go, какой он классный, быстрый модный молодежный, и не взлетел, а его гугель проталкивал всем чем мог, раст протянет скорее меньше
Эммм.... Чтот я сомневаюсь. Парсеры, лексеры, компилятры, оси, интерпретаторы, венда/линукс/ведроид/макось/фряха/равсберии/бареметалл, графика, многопоточка, нейронные сети, распозноание и наше всё -- сети. Компьютер -- это сеть! (* если что -- это не я придумал *)
ЧЯДНТ?
> Go … не взлетелЩито?
Если у анонима на локалхосте чего-то нет - значит нинужно и не взлетело.
Значит он не знает, что жирный кусок из того что у него есть собран на том, чего он не знает)
Просветил бы
Java/C#/C++ ржут стоя
Говорят, Java, как истинное мамонтово, уже окаменела ей пора на свалку
И да и нет, древний ЯП с кучей легаси, как и C++ только без минигана и лимонок, тем не менее развитие единственного конкурента медленно но верно толкает локомотив Java вперед, единственное что действительно древнее и говно так это JavaEE, вот это жесть да, именно из-за одного упоминания о легаси с JavaEE я Jav-ой брезгую, а так вкусовщина
Это докеры, кубернетисы и прометеи не взлетели? Ну-ну...
Это явно не тот уровень Go который гугл задумывал
Да... и иногда хочется верить что этого "Прометея" жустко накажут... с Графаной заодно.
Я конечно веб-программист ненастоящий (точнее, не очень близок к данной теме), но зачем вообще оборачивать проект на Go в докер? Поставить на фронт nginx-unit, вписать туда бинарник и делов-то. Ведь Go-бинарник самодостаточен и вообще ничего не требует (даже не виндовых системах, Карл). Неужели, просто чтобы в доцкере сразу была предустановленная БД или что? Так лучше будет как раз один сервис mysqld с несколькими БД держать, чем размазывать по контейнерам по несколько штук - по одной MariaDB на каждый сервис, блин (дайте угадаю, доступ будет организован через localhost:3306, а не через unix socket, да?). В случае же с SQLit, это просто одна из библиотек, которой не нужен сервер и которая уже будет встроена в бинарник.
Вообще-то, кроме бинарника ещё есть и специфические настройки окружения. И при перетаскивании бинаря с серванта на сервант каждый раз руками что-то перенастраивать тяжко. А ещё очень простая мысль, а что, кроме Го нет баз данных, других программ на серверах? И они не требуют своего окружения?Дизлайк вот за это. За эгоизм))
А так, да. Го -- один бинарь.
если вам не нужно - не оборачивайтея просто привел примеры крайне взлетевшего софта, написанного на Go как контр-аргумент тому, что Go не взлетел
> Опубликован релизКуда пропал аноним-бот с "зачастили что-то релизы хххх"?
Вернись, МоФоКо ещё не прод**сталась.> языка системного программирования Rust 1.40, основанного проектом Mozilla.
Пересобирание rust-"мирка" -- увлекательнейшее занятие часов на то ли 70, то ли 90.... "Иногда" arm, pppc и прочие i686 отваливаются.
В мае http://git.savannah.gnu.org/cgit/guix.git/commit/?id=4ed20d3...
"цепочка" была из 16-ти (c .19 по .34) колен. Этим солитёром собирают icecat-68 (~unmozilled-firefox)Маньяки, как собрали (почти уже совсем) icecat-68 [ESR] с rust-1.34 так и бросили эту беготню.
Или где-то был новый (опять!) mrustc, "укорачивающий" (опять!1) цепочку с 18 до 9 (кажется?)?
Ну, за ентерпрайзный Мозила-ESR! За стабильность!12 До дна.
2018-09:It took my fastest laptop about 36 hours to build the chain of 5 rust
compilers required to get to the latest Rust release, and to build
IceCat.https://lists.gnu.org/archive/html/guix-devel/2018-09/msg002...
>компилировать на лаптопеяснопонятно
У меня на 4-ядерном лаптопе за несколько минут игра собирается. Игра, карл! Сотни файлов. Надо будет ещё OpenMW и Сауэрбратен покомпилять. :D
Голова кругом от этих языков, убийца за убийцей
Rust имел бы перспективу как функциональный язык, концепция владения близка концепции неизменяемости, собственно если писать на чистых функциях, то никаких проблем с борров-чекером не возникнет. Для функций с сайд-эффектами есть умный указатель. А вот если начать писать на Rust в императивном или того хуже в ООП стиле - траходром с лайфтаймами обеспечен. В ржавой функциональщине по сравнению с той же скалой - оверхед по памяти и производительность должны быть лучше.
Печальную статистику Haskell стоит напомнить?
> Печальную статистику Haskell стоит напомнить?Вообще странно, Scala и Rust показывают рост (на фоне спада всех мейнстримных языков), а Haskell не показывает, при том что он вроде самый быстрый. https://madnight.github.io/githut/#/pull_requests/2019/3
Потому шо фап на хаскель прошел ему уже 30 лет
Что доказывает, главное не быть лучшим, главное быть молодым, и дать вовремя :))
Я успел, а ты?
Неа
Пока не поздно брызни в кого нибудь
> Пока не поздно брызни в кого нибудьКогда ты начинаешь вбрызгивать в пропасть, пропасть начинает вбрызгивать в тебя...
Тоже задумывался над тем куда девается сперма, ведь судя из всемирного равновесия если гдето убывает гдето прибывает
Маэстро, так Вы согласны, что из Rust может получиться шикарный функциональный язык ?
Может и скорее всего уже получился, но участь ФЯ незавидная
Но ФЯ с таким остервенением пихают в вузовскую программу, что как только последний императивщик умрет, хаскель воспарит :)
Было уже но как и раньше или ты можешь в ООП или идешь в известном направлении, а преподам похрен главное показать какие они умные, а то что модель ФЯ в отличии от ООП никак не ложится на реальный мир всем так же реально класть
SPARK взлетел, бигдаты все больше, а там функциональщина со всяким map/reduce самое оно
Как же задолбали уже своей бигдатой, это вещь весьма специфичная в силу того что она просто так и нахрен не нужна, там нужна аналитика(R/Python) и машинное обучение(Python/C++) и не одно комплексное решение для работы с бигдатой не построено на базе ФЯ
Охренительный F# с ООП примочками мелкие закапывают так как понимают шо это слишком сложна, а кодеры нужны здесь и сейчас
Зато scala полезла вверх, по числу вакансий на HH уже выше котлина.
Хайп на функционал сейчас, было уже 30 лет назад еще как было, можно смело забить болт на все это
Просто с Haskell быстро сваливают, когда понимают, что он слишком радикален со своей чистотой, и что многие алгоритмы гораздо проще писать и читать с мутацией состояния. Тем временем, прибывают новые, чтобы через полгода-год свалить следом. Вот и получается, что его популярность застряла на одном уровне. Зато Haskell хорош как трамплин в computer science, где всё математично и иммутабельно, он для этого и сделан.
С растом аналогично, многие тыкали палочкой, но пошли деньги зарабатывать на шарпах и JS, и аж три вакансии на всю РФ. Функциональщина на расте могла бы взлететь именно потому, что на этом расте можно не только функциональщину, ну и нет GC, хотя похоже у хаскеля тоже нет проблем с GC, судя по бенчам.
> С растом аналогично, многие тыкали палочкой, но пошли деньги зарабатывать на шарпах
> и JS, и аж три вакансии на всю РФ. Функциональщина на
> расте могла бы взлететь именно потому, что на этом расте можно
> не только функциональщину, ну и нет GC, хотя похоже у хаскеля
> тоже нет проблем с GC, судя по бенчам.Ребят, вы не поверите, но таки да. Функциональщина -- признак человека с мозгами. А человек с мозгами рано или поздно задаётся вопросом: вот я дофига умный вроде бы, а чего ж я так мало зарабатываю, может я на что-то не то жизнь трачу. Вот я тоже много лет писал на диалектах лиспа, схемы, ML-ей (да-да, и Haskell тоже). Но вот уже два года как свалил в девопсы. И это было лучшее решение, что я принял. Так что да, народ с эзотерики и функциональщины соскакивает, причём по весьма прозаичным причинам: он соскакивает в более денежные области. Потому что кроме абстрактной радости созидания иногда хочется и пожить немного.
Не уверен что функциональщина сложнее каких-нибудь микросервисов. Совокупная сложность кучи стейтфулл-акторов может даже превысить какие-нибудь монадки, и логично что девопсы должны зарабатывать больше :)
> Не уверен что функциональщина сложнее каких-нибудь микросервисов. Совокупная сложность
> кучи стейтфулл-акторов может даже превысить какие-нибудь монадки, и логично что девопсы
> должны зарабатывать больше :)Угу-угу. Какие стейтфул-акторы, родной? Тут у меня кучка обезьян на пыхе захерачила проект, который работает через жопу, и тридцать три костыля его подпирают, чтобы хоть как-то ворочалось. И ничего, полтора лимона зелени в месяц. Мы тут про какие-то акторы-херакторы, а жизнь устроена проще: чтобы зарабатывать деньги не нужен никакой рокет-сайнс, вот в чём открытие-то.
>> Печальную статистику Haskell стоит напомнить?
> Вообще странно, Scala и Rust показывают рост (на фоне спада всех мейнстримных
> языков), а Haskell не показывает, при том что он вроде самый
> быстрый. https://madnight.github.io/githut/#/pull_requests/2019/3Ничего странного. На Scala и Rust завязан большой бизнес с деньгами и вакансиями. На Haskell -- нет.
Я только вчера потыкал палочкой производительность scala в с равнении с rust (статья пока на хабро-модерации), но в сухом остатке - императивные алгоритмы на скале очень быстры (всего на 25% медленней раста), а чистая функциональщина на скале почти в 5 раз тормознутей аналогичной функциональщины на расте, и jvm память жрет как не в себя. Так что непонятно стало - нафига эта скала. А растишка оказался неожиданно хорош, я даже готов простить ему избыточное многобуквие.
Дык никто и не спорит, что Rust хорош. Однако есть очень много интересных и хороших языков, которые не выстреливают. Haskell, Ocaml, Racket, SBCL, Erlang, Elixir -- весьма клёвые вещи, но всё это остаётся в своих нишах среди учёных, гиков, фриков, ну и изредка контор, которые на них когда-то завязались, а потом вдруг выстрелили, ибо звёзды удачно сложились. Короче, они в некотором смысле мертвы. А странные среднячки с большой финансовой поддержкой разных компаний -- выстреливают и идут в широкие массы. Почему? А потому что на успех языка на рынке влияют прежде всего не качества самого языка, а финансовые вложения в него. Посему Java и Scala будут жить ещё очень-очень долго. Rust -- поживёт. Всё-таки иногда в него начинают вкладываться разные компании, типа того же Dropbox-а. Go -- выстрелил и будет жить 100%. А так вообще время рассудит, к какой категории язык будет отнесён. =)
у плюсовиков сегодня передых, вернее у полуплюсовиков это те кто застрял посередине 20-ти летнего цикла познания дзен языка с++
наверное их пятая точка в подсознании сжимается осознавая что по окончанию срока они окажутся на свалке истории
не останемся.
вас, новичков, даже запоминать нет смысла - вы каждый год разные. а мы все пишем и пишем, все пишем и пишем...
А могли бы как тру макакакодеры - дописать, срубить бабла и свалить в новый стартап. А вы всё пишете и никак не допишете )
Альтруисты, что поделать.А так да, мир все еще развивается - и мы, надеюсь, писать будем всегда.
> а мы все пишем и пишем, все пишем и пишем...Ну и пишите. Респект вам и уважуха. Я думаю, с учётом количества кода, написанного на крестах, до конца вашей жизни сфера не загнётся, и на краюху хлеба вам всегда хватит. Но вообще-то, на свалке истории вы рано или поздно всё-таки останетесь. Мейнстрим уже давно не плюсами пишется. Вы вымираете, и это заметно.
Мейнстрим загибается быстрее чем развивается, сколько убийц TCP/IP было офигеть, сколько принципьно новых убийц Unix/Windows офигеть, сколько убийц SOAP и все говно, так или иначе превращающиеся в тот же SOAP, с C++ ситуация та же, не убийцы, а сплошные самоубийцы
Ты забыл сколько покушались на электронную почту, она отстой говорили они, правда вспомнить их уже не могу
> Ты забыл сколько покушались на электронную почту, она отстой говорили они, правда
> вспомнить их уже не могуВон, в соседней новости, на-коней-ц-то!, окончателоьный убийца е-мейла -- " мессенджер, работающий с-на-под-поверх е-мейла, переписан на Rust в версии 1.0 " </окончательная фактическая бумажка>
> Мейнстрим загибается быстрее чем развиваетсяА когда и в какой области, собственно, было иначе?
Зачем тогда на него ровняться?
>В режиме Rust 2015 активирован вывод ошибки для проблем, выявленных при проверке заимствования переменных (borrow checker) c использованием техники NLL (Non-Lexical Lifetimes). Ранее предупреждения были заменены на ошибки при работе в режиме Rust 2018. После распространения изменения и на режим Rust 2015 разработчики получили возможность окончательно избавиться от старого borrow checker. Напомним, что система проверки на основе нового механизма учёта времени жизни заимствованных переменных дала возможность выявлять некоторые проблемы, которые оставались незамеченными старым кодом проверки. Так как вывод ошибки для подобных проверок мог повлиять на совместимость с ранее работающим кодом, вместо ошибок первое время выдавались предупреждения.И какие ещё проблемы остались незамеченными, но уже для нового borrow cheker? Я думал это фундаментальная вещь решающая проблемы с доступом к памяти, а не заплатка.
Сложный язык с накрученным рантаймом (а будем честны -- все вот эти вот ваши барроу чекерс -- это и есть размазанный рантайм) -- нежизнесопособен.
Ядро языка должно быть простым, тупым, проверяемым. Лучшее, из всего, что видел -- Оберон от дедушки Вирта. Уже не молод (оба), но жару дают.
последняя версия Оберона от 2016 года.
Тоже мне лучший язык - который умер при рождении.Позвольте угадаю - вы как паскаль в школе учили, так больше ничего осилить так и не смогли?
Паскаль вообще ни в школе, ни в институте не учил. Басики всякие, питоны, ассемблеры.
Тогда к чему ваше упоминание оберона, который даже просто выйти в мир не смог? На розеттакоде всякой фигни навалом, каких только языков не сыщешь; так для оберона всего пара десятков страничек с реализациями - у брейнфака и то больше.
Потому что он читал про его простое ядро. А книжки про Оберон были даже в советское время.
В расте Borrow Checker - это *только* этап компиляции.
Ну так старая версия что-то пропускала. Где гарантии что новая версия не будет пропускать. Если это фундаментальная штука, а не заплатка, то определённый класс проблем ей решить под силу.
Наоборот, была ограниченной и не давала сделать столь любимый народом двусвязный список, приходилось обращаться к unsafe чтобы обойти ограничение формальной модели чекера.
Чекер NLL это дело сильно улучшил.
А где гарантии, что произвольно выбранная программа когда-нибудь остановится вместо зацикливания?
Доказательствами корректности занимается проект "RustBelt" http://plv.mpi-sws.org/rustbelt/То, что система типов Rust'а предотвращает data races, уже было доказано. Доказательство корректности новой реализации borrow checker'а в процессе - это дело небыстрое.
Печально конечно, что обычный программист проглотил идею, что для решения сложных задач нужны сложные инструменты.
> Ядро языка должно быть простым, тупым, проверяемым.Brainfuck. Ядро - машина Тьюринга, классика.
Хочется быстро C++, хочется красиво C#, хочется в телефоны Java, хочется войти в айти PHP, хочется все и сразу СЮРПРАЙЗ МАЗЕФАКА PL/1
Го же?!
PL/1 кошернее, а ведь был еще Prolog бомба ваще
Негоже.
В телефоны уже давно Котлин же
JVM это не отменяет или как она там в гугле зовется один фиг байткод стандартный, а для JVM родной таки Java
Dalvik - не jvm и никогда ею не был. Образовывайтесь: https://en.wikipedia.org/wiki/Dalvik_(software)
Несовместимость на уровне байт-кода ничо себе, да упустил не слежу за андроид, но теперь хоть понимаю суть предъяв оракеля к гуглу, сан в свое время мелких засудила за J++ за поломанную совместимость
Нет, судятся они за идентичное АПИ. Сам дальвик никто никак не трогал и трогает.
Ну конечно какого фига гугл юзает API джавы при этом поломав байткод, MS тем же промышляла
Единственная практическая польза от Go и Rust то шо они как никак, но все же заставляют шевелится левиафана C++
И чем оно лучше Kotlin?
Оно как бы PL/1 только с компилятором
Какое же здесь токсичное комьюнити. Но я всё же как нетру питон программист напишу здесь своё скромное мнение, которое разумеется никого не волнует.
Я рад тому что Раст развивается и даёт возможность входа в системное программирование новым людям. Я рад что смогу писать нейронки и сложные проекты без 20ти летнего опыта в плюсах. Я рад, что мне не придётся в холодном поту искать ошибку в либе с утечкой памяти, отлаживать миллионы строк абсолютно нечитаемого кода, и гуглить абсолютно нечитаемые ошибки. Я искренне желаю расту, удачи, чтобы он завоевал своё место на рынке, а плюсы начали это самое место терять, ибо плюсы это переусложнёный, непрактичный инструмент который требует слишком много времени и сил для того чтобы написать даже простой проект. Поэтому вместо решения интересных задач, тебе приходится бороться с проблемами самого языка.
Пойми анон если бы Rust был хоть чем то объективно лучше крестов, его бы на руках носили, а не хейтели, а то что предлагают тот же уродливый C++ если не жосче, без нормального ООП, с гемороем переключения в unsafe который ставит раком все преимущества Rust и спрашивается, а нафиг оно надо?
Те, кто на нём пишут, носят на руках. Блоги пишут, объясняя, почему, разрабатывают библиотеки, кое-кто и в продакшен пишет. Хейтят же те, кто не написал ни строчки, только прочитал кусок кода, не переварил синтаксис и побежал блевать в комменты с видом знатока, вангуя налево и направо. Классический ООП с наследованием в подавляющем большинстве случаев нафиг не нужен, а трейты и структуры понятнее и гибче.По поводу unsafe, в тысячный раз для особо одарённых: если ты словил сегфолт, сразу знаешь, что причину нужно искать в одном из unsafe блоков. Остальной код гарантированно ни при чём и его безопасность никуда не девается, никакого позиционирования раком не происходит. А в проекте на C или C++ проблема может быть где угодно, удачи в отладке. Какое там "переключение" в unsafe, в чём геморрой - сложно напечатать "unsafe {}"? Зачем делать это ещё легче, если 99.9% кода не требуется работа с указателями и FFI? Смысл unsafe именно в том, чтобы отделить опасные куски от остального года, а не сделать стрельбу по ноге лёгкой и приятной.
Давай расскажи про классический ООП и как он не нужен, а то в JS добавили не выдержав наверное необъективной критики да?сколько кода для работы с unsafe кодом Си будет, не дай бог C++, он же системный, одним словом херню не городи, был уже unsafe в C# кроме крайняка им никто не пользуется, так как он полностью рушит концепцию безопасного языка и хруст не исключение
> Давай расскажи про классический ООП и как он не нуженПардон, но я вот видел довольно много ООПов на своём веку, и они все дофига какие разные. Какой-такой из них "классический"-то? А то ведь Вы явно не про Smalltalk говорите, вижу же. Какой же из ООПов спровоцировал синдром утёнка конкретно у Вас, что Вы его нарекли, блин, "классическим"? =)
Давай расскажи сколько "много" ты реализаций ООП видел и добавь что смолтолк вообще нехрена не ООП язык в классическом его понимании, а скорее набор микросервисов с единым IPC
> Давай расскажи сколько "много" ты реализаций ООП видел и добавь что смолтолк
> вообще нехрена не ООП язык в классическом его понимании, а скорее
> набор микросервисов с единым IPCЯ видел ООПы с объектной моделью на классах, где новые объекты строятся по заранее описанному шаблону, и ООПы основанные на прототипах, где новые объекты порождаются от уже существующих. Я видел ООПы со множественным наследованием и без оного. ООПы, в которых надо примешивать свойства классов. ООПы, требующие обязательного приведения к родительскому кассу, и ООПы с утиной типизацией. Я видел расширения ООП посредством теории категорий, позволяющие создавать на лету новые типы данных.
И всё это кардинально разные ООПы, не похожие друг на друга. Это ООПы из С++, Perl, Racket, SBCL, Smalltalk, Scala, Ocaml... Они не похожи друг на друга настолько, что зачастую практики, используемые в одном, оказываются бесполезными в другом. И поскольку всё это называется ООП, я искренне не понимаю, какой из них считается каноническим, если речь не о Smalltalk.
Костыли из ФЯ с прикрученным сбоку ООП и классическим C++ ООП и производных Java/C#, норм сравнение, а еще Perl в которое ООП добавили через одно место, классный у тебя опыт слушай, ах да еще JavaScript с прототипами, которые замаскировали под классы в новых стандартах, опять же C++ стайлЕсли ты думаешь, что прочитав бред Буча про ООП именно в стиле смолтолка, ты понимаешь ООП, ну печалька тогда, ООП это не какая то куча объектов обменивающихся между собой сообщениями это жирный монолитный скомпилированный код, а ООП благодаря инкапсуляции средство управления его размазанными исходниками на Си, тестирования, раздельной разработки, а также при помощи полиформизма и наследования средство для повторного использования кода без дублирования, теперь ты хоть понял?
Угу, вот оно что. "Классический C++ ООП". ООП в крестах -- один из самых плохо спроектированных. Вот, почитайте: https://yosefk.com/c++fqa/index.htmlКстати, весьма забавно, что Вы говорите о пользе инкапсуляции, и одновременно молитесь на кресты, в которых с ней как раз немаленькие проблемы. Ещё более забавно то, что я вот знаю о том, что полиморфизм не имеет никакого отношения к ООП, а Вы -- нет. =)
Ты знаешь еще хоть одну реализацию ООП ставшую массовой кроме C++?Бред из головы выкинь парень или начинай писать программу как множество процессов с IPC это и есть та хрень которую назвали ООП, но вот в чем жопу, понимаешь ли смолтолк при всей своей крутости нереально тормозил, из за чего сыграл в ящик раньше чем обрел славу, ну или пиши код для Plan9 там вроде такой же подход, ах да есть еще микроядра которые тормозят
А то, что кому то не нравятся некоторые технические, а не концептуальные детали ООП в C++, так он компилируется в машинный код и должен быть настолько быстрым насколько это возможно, впрочем что тебе объяснять растобабуину завтра выйдет очередной шлак и все дружно бросятся его жрать
> Ты знаешь еще хоть одну реализацию ООП ставшую массовой кроме C++?Массовыми становятся языки, а не их реализации ООП. Но ежели желаете, то пожалуйста: Java, JavaScript и Scala -- массовые языки, реализация ООП в которых от крестов весьма отличается. Впрочем, Вы уже назвали их почему-то "производными от C++", так что хрен знает, о чём и как с Вами говорить. Может быть Вы лучше пройдёте прямо и немного направо, компетентный Вы наш критик?
Scala популярный? Это нонсенсВ каком первом языке появились классы, наследование и полиформизм? Java как упрощенная версия чего создавалась? JavaScript со своими прототипами был такой удачный, что аж второй язык пришлось создавать TypeScript, пока до ECMA не дошло и таки запилили как надо
Производные значит базирующиеся на идеях предшественников, Java на базе смолтолка пилился или ты в край упоролся?
> Scala популярный? Это нонсенсКак Вам кажется, пусть так и будет.
> В каком первом языке появились классы, наследование и полиформизм?
Кек. =)
Ну, за первый язык с полиморфизмом мне сказать трудно... Полиморфизм функций был наверное в Lisp, то бишь это у нас емнип 58й год... Но это из динамически типизированных языков, разумеется. Если мы про статически типизированные языки, то полиморфизм типов по-моему впервые появился в ML, то бишь в 73м. Емнип, кресты появились в 84м... И поэтому я как-то не уверен, что Страустрапа корректно называть изобретателем полиморфизма. =)
> Java как упрощенная версия чего создавалась?
Не могу знать. Расскажите.
> JavaScript со своими прототипами был такой удачный, что аж второй язык пришлось создавать TypeScript
Ммм, так вооооот почему TypeScript появился. А я как-то по наивности своей думал, что хотели строгой типизации для JS.
> Производные значит базирующиеся на идеях предшественников, Java на базе смолтолка пилился или ты в край упоролся?
Не, я думаю, что производные -- это мгновенные отношения приращения значения к приращению аргумента. =)
Полиформизм в отрыве от классов и наследования? жги ещеTypescript создавался не только для статической типизации, а еще для нормального ООП
> Полиформизм в отрыве от классов и наследования?Естественно. Я ж ещё в самом начале написал, что полмирфизм к ООП отношения не имеет вообще. С добрым утром! Сударь, идите изучать матчасть. Вы ведь не знаете элементарных вещей, какую мысль Вы хотите донести всеми этими сообщениями? =)
Полиформизм к ООП не имеет отношения? Иди проспись пьянчуга
> Полиформизм к ООП не имеет отношения?Третий раз говорю: да, не имеет.
> Иди проспись пьянчуга
Окей. Вы сказали достаточно. Наш ресурс прямо запрещает оскорбления. Вы получаете предупреждение. Начиная со следующего сообщения в подобном ключе -- буду вырезать.
Ветвь сворачиваю. Я повеселился, конечно, но это явно скучный и никому не интересный флейм. Можете начинать ныть о модераторском произволе.
> Полиформизм к ООП не имеет отношения?Т.е. вот это вот на самом деле ООП? Или не полиморфизм?
function Add(x, y : Integer) : Integer;
begin
Add := x + y
end;function Add(s, t : String) : String;
begin
Add := Concat(s, t)
end;...
writeln(Add(1, 1337));
writeln(Add('World of', 'Anonns'));
Это перегрузка функций, а не полиформизм
> Это перегрузка функций, а не полиформизмWut?! Перегрузка -- это ведь частный случай полиморфизма же! По определению, блин! Нахера, зайчики, Вы вообще пишете это всё. У вас ни опыта, ни знаний терминологии даже. И ведь вы могли хотя бы просто прочитать статью на Вики. Там уже лет пять как всё корректно написано, причём даже на русском. Но нет, давайте чушь пороть в комментариях...
> Это перегрузка функций, а не полиформизмУ анонима это может быть и жопоморфизмом, но в остальном мире принята несколько иная терминология:
http://www.ics.uci.edu/~jajones/INF102-S18/readings/05_strat...
> There seem to be two main classes, which can be called ad hoc polymorphism and parametric polymorphism.
> In ad hoc polymorphism there is no single systematic way of determining the type of the result from the type of the arguments.
> There may be several rules of limited extent which reduce the number of cases, but these are themselves ad hoc both in scope and content. All the ordinary arithmetic operators and functions come into this category. It seems, moreover, that the automatic insertion of transfer functions by the compiling system is limited to thisЕще, в остальном мире есть такие обозначения как monomorphism, homomorphism, heteromorphism и прочее.
Это все от "morph(ism)" - отображение, форма. Poly - много, mono - одна.
Искользуется и в математике и в биологии, откуда идея именования и заимствовалось.
Полиформизм это когда интерфейс один, а реализаций много.Ты привел перегрузку из вики типо самый умный? Так в данной перегрузке два интерфейса и две реализации
> Полиформизм это когда интерфейс один, а реализаций много.Нет. Полиморфизм -- это способность интерфейса обрабатывать сущности разных типов. Или же проще: способность функции обрабатывать разные типы аргументов.
Реализаций не обязательно будет много. Параметрические типы, например, обеспечивают полиморфность функций, но реализация будет одна.
> Ты привел перегрузку из вики типо самый умный?Я ее еще задолго до появления вики видел и писать умел - это паскаль классический.
> Так в данной перегрузке два интерфейса и две реализации
> Полиформизм это когда интерфейс один, а реализаций много.http://www.stroustrup.com/glossary.html#Gpolymorphism
> polymorphism - providing a single interface to entities of different types. virtual functions provide dynamic (run-time) polymorphism through an interface provided by a base class. Overloaded functions and templates provide static (compile-time) polymorphism. TC++PL 12.2.6, 13.6.1, D&E 2.9.Но у анонимов опеннета, как обычно, есть своя, собственная, "единственно верная" терминология.
НедоC++ + НедоC# + Haskell = RustСадитесь жрать господа
Ну да Си-шные системные вызовы ядра вообще не требуют указателей, ага да иди в раст со своим раст, херню нагородили
<преждевременно отправил, удалено>
Я смотрю у нас на опеннете сплошь ядрёныё разработчики, пишут только максимально низкоуровневый код и думают максимально низкоуровневые мысли. Ну оберни ты системный вызов - unsafe { syscall(..) } - и пиши дальше свою мега-систему в своих влажных фантазиях. По чепухе, которую ты и остальные антирасты несёте, сразу понятно, что весь ваш опыт - пачка лаб, курсач и казуальная игра в занюханной локальной гейдев-конторе. У тебя что, весь код из одних сисколлов состоит? Деление на уровни абстракции отсутствует, потому что абстракции - для хипстеров, и вообще слишком высокоуровнево? Ты весь код пишешь, используя как можно больше указателей чисто из принципа (это же так эффективно - копировать указатель), и всё обвешано проверками на NULL для надёжности? Ты - джедай со световым мечом, сделанным из пустого кристалла (void*)?Я просто вас не понимаю, такое ощущение, будто вы соревнуетесь, кто придумает наиболее натянутый пример, на котором Rust внезапно сломается и окажется говном. Такого не будет. Вы из одной крайности бросаетесь в другую и уже сами не знаете, чтобы ещё такое вякнуть по теме, а фантазии хватает только на то, чтобы придумать проблему, но не хватает соображалки, чтобы найти тривиальное решение. Напоминаете школьников-паскалистов, только что на каникулах прочитавших книжку по С и уже воображающих себя мегахакерами, пишущими ядра да прошивки для тостеров, и думающих, что ничего лучше C на свете нет и никогда не будет.
И напоследок, на Rust целую операционную систему Redox пишут, вообще-то. Сисколлы там, драйверы и т.д. Так что вашими унылыми однообразными аргументами можно только подтереться, но даже для этого они не годятся без помощи принтера.
С наступающим. Пусть в Новом году вы все будете писать столько кода на С, чтобы у вас не было времени на Опеннет.
> И напоследок, на Rust целую операционную систему Redox пишут, вообще-то.Сходи в сорцы глянь, сначала; а уже потом говори. Ансейф на ансейфе и кровь из глаз везде, где можно и нельзя. Я такой ужас видел разве что в индусских драйверах мыши под древний WinCE. Хотя даже там не так глаза кровоточили..
При чем здесь это, просто есть ЯП системные их два C/C++ и прикладные с удобными библиотеками Java/C#, а то что в системном программировани с POSIX или WinAPI придется работать постоянно тебе любой сишник и плюсовик скажет, поэтому у каждого ЯП своя ниша, а Rust хочет быть удобным как C# но с уродским синтаксисом C++, не получится
Плюсую мало гемора обертывать системные вызовы так еще и заморачиваться с unsafe, капец
Это заморочки? o_Olet mut ts = libc::timespec {
tv_sec: 0,
tv_nsec: 0,
};
unsafe { libc::clock_gettime(libc::CLOCK_MONOTONIC, &mut ts) };Да вы совсем обленились.
Сейчас тебе напишут, что, мол, приплюснутым не нужны все эти unsafe и &mut, и без них всё работает, а так только палки в колёса. Открывающие скобочки на той же строке - фу, иммутабельность по умолчанию тоже. Короче, всё не как у людей. Люди - это, конечно, приплюснутые, у них тут правит их знаменитый самоконтроль (все ж читали "55 способов не обделаться при попытке чихнуть"), дисциплина и глубокое знание архитектуры, а остальные - так, ленивые макаки-быдлокодеры, которые хотят меньше думать и писать. И вообще, у нас тут легаси кода понаписано, не выкидывать же. В общем, С++ 2100 ещё выйдет, а все эти хипстерские языковые стартапы вымрут за ненадобностью, потому что в C++ будет всё, что есть во всех других языках вместе взятых. А то, что полностью знать язык будут всего три человека в мире - это даже плюс, меньше дураков останется. Так что, растоманы, готовьтесь точить гайки на заводе.Надеюсь, я правильно изложил основные тезисы критики Rust, выведенные мной из многочисленных и ожесточённых баталий с местной элитой разработки ПО.
Мешанина unsafe и safe это тот еще лядский цирк, вот есть в C# но так скорее шоб было и уж когда очень нужно с сишным кодом пообщаться, но это такая боль
Ну смотри, с таким синтаксисом как у ржавого на нем дестоп и веб пилить нихто не будет, даже Qt какой бы он клевый не был на плюсах это боль и слезы, остается работа с системным API с которым нужно будет мучаться в unsafe и всякие DirectX, Vulkan, OpenCV, OCR, TensorFlow, CNTK, GPU-вычисления но они все на плюсах, вопрос а нафиг оно нужно?
> если бы Rust был хоть чем то объективно лучше крестов, его бы на руках носили, а не хейтелиТы сделал мой день! Ты действительно думаешь, что хейтерство на опеннете хоть как-то связано с объективными преимуществами и недостатками объекта хейта? Нет, здесь чистый хейт ради хейта, чем он собственно и приколен. Никакой связи с реальностью, маленький информационный пузырёк незамутнённого хейта.
>> если бы Rust был хоть чем то объективно лучше крестов, его бы на руках носили, а не хейтели
> Ты сделал мой день! Ты действительно думаешь, что хейтерство на опеннете хоть
> как-то связано с объективными преимуществами и недостатками объекта хейта? Нет, здесь
> чистый хейт ради хейта, чем он собственно и приколен. Никакой связи
> с реальностью, маленький информационный пузырёк незамутнённого хейта.Поддерживаю многократно!
Представь что завтра появляется язык с синтаксисом в лучших традициях Perl в качестве более лучшей замены Python, твоя реакция?
Тебя за яйца тянуть кодить на Perl? А теперь представь себе, кодишь на Perl, тебя все устравивает, никого не трогаешь, набегают вебмакаки о начинают вопить "Perl не нужон! есть жаэс! афтар перлы убейсо!111", твоя реакция?
Perl привел как пример уродливого синтаксиса которому поможет только эфтаназия, JS на фоне Perl просто конфетка, как и впрочем почти любой ЯП так что да послал бы Perl по объективным соображениям, а не модным
Синтаксис - тупо вкусовщина, некоторым синтаксис ассемблера милее любой новомодной херни.
стопудов вот оно че, а я то думал синтаксис это средство выражения своих мыслей в язык команд процессора, ну тогда C#/Java закрываемся ведь вкусовщина
Читаемость кода это тоже вкусовщина? Да что ты такое блин несешь
> Читаемость кода это тоже вкусовщина? Да что ты такое блин несешьЭх. Старые байки времён обфускейшен контестов. =)
А ведь в CPAN всё чин по чину, читаемо и красиво. Но нет, "перл нечитаемый", "фу писать на перле". =)У перла есть десятки настоящих причин, почему он мёртв. Но нет. Анонимус конечно легион, но он помнит далеко не всё. Он, увы, помнит только байки. )
Именно в силу его уродливого синтаксиса состоящего наполовину из регекспов его люто ненавидит каждый кто видел перлы на перле
> Именно в силу его уродливого синтаксиса состоящего наполовину из регекспов его люто ненавидит каждый кто видел перлы на перлеНадо же, в языке, основное назначение которого -- обработка текстов, люди активно используют регэкспы... =)
Для обработки текстов есть сами регекспы, нефиг их с синтаксисом мешать, отдельная либа и юзай как хочешь
> Для обработки текстов есть сами регекспы, нефиг их с синтаксисом мешать, отдельная либа и юзай как хочешьГлавное, чтобы инструмент хорошо решал задачи, под которые заточен.
А о вкусах можете с фанатиками поспорить, они с удовольствием составят Вам компанию, ибо их мнение никому больше не интересно.
Уже поспорили двадцать лет назад, фанатики как и перл в пролете
Какая разница, какой язык вообще? Сегодня один, завтра другой.
Не забывай стандартную библиотеку, фреймворки, тестирование, документирование, системы сборки, пакетные менеджеры, зависимости, IDE, GUI и стопитсот других весьма различных вещей в разных ЯП, и сегодня один завтра другой? серьезно?
В некоторых есть фундаментальные отличия такие как ФЯ и ООП, которые вообще меняют подход к проектированию и написанию кода
Про #[non_exhaustive] в новости ересь написана. Всегда можно добавлять новые поля. Это атрибут в библиотеке будет заставлять _пользователей_ этой библиотеки ("downstream projects") добавлять обработку случая "по-умолчанию" ("_"), даже если всё имеющиеся варианты уже перечислены. Ошибка компиляции будет не при добавлении полей, а при компиляции такой структуры без обработки по-умолчанию. Это сделано что как раз избежать ошибки компиляции при добавлении новых полей.
Ерундой страдают. В С++ модули на подоходе, вообще идеальный язык станет
Без единого пакетного менеджера в стиле "твоей либы там нет? твоей либы нет" это всё бессмысленно
Бессмысленно со своего жаваскрипта лезть к серьезным дядям, пакетных мендежеров для C++ есть много, но они популярностью не пользуются
Git+CMake вот и весь пакетный менеджер, большего для C++ не нужно
Отсутствие дефолт пакет менеджера - один из ключевых недостатков плюсов.
git+cmake - колхоз
Кроме того, далееко не для всех либ есть cmake
Ты удивишься, но maven аналогичный колхоз, и ничего, неговоря уже об откровенно кривом npm и прочих говновысерах, единственный годный из всей этой своры nuget и тот дотнет-only
Пакетный менеджер в C++ невозможет в том виде как в других ЯП, так как нет байткода, компилишь под нужную платформу иначе ABI не сойдется, хотя есть типо байткод LLVM но чет сомневаюсь шо сильно взлетит так как GCC и MSVS такую фичу не поддерживаю
Можно как в Rust. Компилить нужно при сборке
vcpkg так и работает, но объективно нужен ли плюсам пакетный менеджер большой вопрос
Как бы язык не был хорош, он может взлететь, только если обвешан кучей библиотек. C# взлетел из-за мудрости микрософта, который реализовал лучшую стандартную библиотеку на все случаи жизни. С++ вообще будет бессмертным, ибо если в долларах оценить все написанные для него библиотеки, то даже сложно представить сумму. А руст будет в той же помойке, что и D и другие мертворожденные идеальные языки
>А руст будет в той же помойке, что и D и другие мертворожденные идеальные языки10 лет уже эту херь несёте, смените уже пластинку.
Раст выживет, ибо он практичный язык.
И С++ выживет, вот только изменится так что учиться писать на нем придется заново. Очередной раз)
Зачем иметь два монстра, тебе C++ мало? Сплошное дублирование
Раст нужен, чтобы иметь гарантии, которые кресты не дают.
Кресты нужны, для того, чтобы те, кто не осилил раст, могли заняться чем-то условно полезным.
Я тебе секрет открою, в C++ есть unique_ptr
Ну вот вы "коренные плюсовики" хаете Rust в каждом тренде, не надоело еще? А ведь Rust потихоньку отнимает рынок плюсов, а вы и дальше продолжайте ныть про синтаксис, про никому не нужный, про блаблабла. Денозаврам пора на свалку истории. Rust уже несколько лет лидирует в разделе любимых языков https://insights.stackoverflow.com/survey/2019#technology-_-... А вы и дальше все хайте пока не опоздаете на последний поезд...
Гоу тоже везде лидирует, но как то по стелсухе, он вроде как бы есть и как бы нет
Хайп go был в году 14-15, сейчас приутихли как мне кажется. И то любовь к нему в основном проявляется среди devops и некоторых C-программистов, так как с одной стороны (devops) не надо писать на питоне и тянуть зависимости с интерпретатором, когда можно написать на go и закинуть один бинарь в докер (и как бонус статическая типизация), с другой (C-программисты) добавляет немного сахарку, безопасные указатели и GC, не надо учить "сложные" концепции выразительных современных языков, чтобы получить тот же эффект.
Сам же go по сравнению с другими очень странный в плане многих решений, заметно сильное влияние Роба Пайка и его длительной работы над plan9. В итоге вышел язык "не от мира сего". Взять хотя бы interface{} вместо дженериков, по сути толстый сишный void-указатель из 70-ых. Причём небезопасный, так как два указателя внутри не атомарны при изменении (один указывает на тип, другой на данные). Хотя внутри самого go для мапов используется некое подобие дженериков, просто недоступное простому смертному программисту. И таких примеров в go много.
Наблюдаем как очередной убийца плюсов исчезает
Rust говно, очевидно же
Ты не понимаешь, мозилла решила в очередной раз переизобрести C++/CLI, так же как COM в свое время в виде XPCOM, ну любят люди велосипеды шо поделать