Один из главный экспертов по C++ и автор D: Go - безнадёжно уныл и годится только в качестве клея, а Rust - страшный и пропускал «дни ног»

Ну,слова говно там не было

По-моему,

Go — фундаментально тормозной из-за косвенных вызовов функций и GC. Фактически ничего вразумительного без них написать на этом ЯП нельзя.

выглядит именно как не слишком завуалированное сравнение с кучей ненужного.

в контексте замены С, и тут D и правда выглядит лучше, чем безальтернативный GC в go

Невозможность использовать stdlib, если крайне нежелательно связываться с GC, разумеется, никак не ограничивает D, так, досадная мелочь.

Дизайн Rust'а не строится вокруг guaranteed memory safety? Это является самой главной проблемой в разработке ПО?

А какая самая главная проблема в разработке ПО?

А какая самая главная проблема в разработке ПО?

В разработке ПО есть всего две главных и неразрешимых проблемы:

1. Выбор хороших имен в качестве идентификаторов.

2. Предсказание сроков разработки.

3. Плюс-минус единичка.

Набросом удовлетворен.Следующий!

А какая самая главная проблема в разработке ПО?

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

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

Это узкое горлышко, когда ты хочешь написать безопасный и нетекущий код

полгода назад мой научник и его аспирант тоже делали на фортран77

почему не на fortran 90..2008?

Понял, наверное научник сподвиг.

С другой стороны f77 тоже ничего, особенно, если размеры данных, которые нужно читать из файла известны, а они как правило известны. Их просто запихивают в начало файла. Главное редактор кода под рукой иметь для удобства с подсветкой 6-й позиции и смириться с common-блоками.

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

А какая самая главная проблема в разработке ПО?

Линус говорит что dumb suckers.
Как по мне, то Го тут ближе всех к победе.

Чьё мнение кстати?

скорость разработки

А ты сам-то понял, что сказал?

да, и это подчеркивает ))

Есть разница между невозможно вообще и можно, но без stdlib.

Дизайн Rust'а не строится вокруг guaranteed memory safety?

Нет.

Это является самой главной проблемой в разработке ПО?

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

Синтаксис Rust привычен для разработчиков на других ЯП?

Да.

Понял, наверное научник сподвиг.

Ну да, его решение, но я свою часть всё равно отказался делать на чём-то кроме крестов, на выбор были си и f77, но я убедил его на кресты.

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

Синтаксис Rust'а раздражает. Он намеренно чужероден без всяких очевидных на то причин.

+
Его синтаксис целиком состоит из синтаксического мусора. Что за упоротые работают в мозилле?

синтаксис целиком состоит из синтаксического мусора

Это фильтр, очевидно же. И ты в нем застрял.

У копрофгов тоже свой фильтр.

У копрофгов тоже свой фильтр.

Верю тебе на слово. Но вообще, много где есть свой фильтр - от универов до монастырей.

Просто нужно не быть криворукой обезъяной и уметь программировать на Си.

Судя по CVE - никто не умеет

Вам двойка по формальной логике.

Ну так почитаешь - одни мегаспецы на С пишут. А на деле сплошной говнокод.

Ну и вот задачу по моделированию кинетических уравнений для Бозе-Конденсата полгода назад мой научник и его аспирант тоже делали на фортран77

Смысл писать на фортран77, когда есть человеческий фортран90 (и более свежие стандарты)?

На перфокарты небось набивают

долгое время были проприетарными

Код был выложен, были ограничения наложенные не им.

PM to I60R, in response to:

В TIOBE Swift сейчас на 20-м месте, красная стрелка указывает, что он вот-вот из 20-ки вылетит.

22.11.2017

Глазки у бабушки совсем плохи стали, подскажи внучок что там в TIOBE за декабрь пишут? Таки вылетел из 20-ки то?

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

IF (IN) 111, 111, 101

Здесь упомянули Golang? Ок. Теперь объясните, кто такой Александреску и что это за язык такой - Дэ?

Написано же, один из главных экспертов по C++ с опытом в несколько десятков лет, автор ряда фич. Автор собственного ЯП. Уже за это его мнение интересно послушать. А вот спорить уже надо с аргументами (про политику в Go, негодность косвенных вызовов / неотключаемого GC для замены C, скучность ЯП), а не переходить на личность.

Что ещё за дни ног? WTF?!

Я так понимаю собираются горе-программисты и стреляют себе в ноги

Чувак, яж не против аргументов. Но это

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

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

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

Я референс читал. И в посте емко передана суть. Или ты сам сомневаешься, что точно её передал?

в посте емко передана суть

Я ничего не придумывал, но намеренно надёргал кусков таким образом, чтобы максимально чётко донести именно свою повестку (aka agenda) в стиле 1го анала / CNN. Удивлён, что меня не только никто носом в этот факт не ткнул, но ещё похвалили за точность передачи первоисточника.

Ну, чувак, значит, я не твоя ЦА. Сорян за то.

Или, наоборот, - твоя. Спасибо за это.

Да и вообще - делись оно нулем. Не понимаю, на какую драму ты рассчитываешь. Статья протухла, да и срачи Rust_vs_Go_vs_D_vs_C_vs_C++ уже давно не столь интригующи.

Я ничего не придумывал, но намеренно надёргал кусков таким образом, чтобы максимально чётко донести именно свою повестку (aka agenda) в стиле 1го анала / CNN.

Это хорошо, что ты сознался в провокации.

lol no generics

Конечно не им. Код вообще нечасто что-то ограничивает. Обычно ограничивают его.

Во-первых это не про Си, а про Си++. А во-вторых Александреску ты похоже не читал.

Unironically и без набросов, вот это тебе PHP по степени угара ничем не напоминает?

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

var substrRegexp = regexp.MustCompile("...")

func findShit(filepath string) []byte {
	bs, _ := ioutil.ReadFile(filepath)
	return substrRegexp.Find(bs)
}

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

// Читаем содержимое файла.
bs, _ := ioutil.ReadFile(filepath)

// Находим подстроку.
substr := substrRegexp.Find(bs)

// Копируем подстроку, чтобы оригинальная строка могла
// быть освобождена.
// Для этого сначала (1) выделяем память под нашу подстроку,
// затем (2) производим само копирование***.
res := make([]byte, len(substr))
copy(substr, res)

// Лишь затем возвращаем результат.
return res

*** - По ссылке выше на полном серъёзе как вариант предлагается самостоятельное посимвольное копирование необходимой подстроки:

for i := range substr {
	res[i] = substr[i]
}

Как будто нам недостаточно в коде всех этих if err != nil и стоит задача сделать его ещё красивей.

Это ли не упоротость? Для (по мнению Коммандера) простого высокоуровнего ЯП, предназначенного для людей, которые не могут постигнуть все эти ваши высокие концепции из CS.