Чем Swift и Rust хуже C++?

Извините, но ваш юзерпик вопит о ваших страданиях.

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

Боюсь что сейчас код написанный на C++ 10

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

А есть ли хоть один язык, удачно сочетающий наличие GC и возможность рулить памятью самому?

Думаю, старый Rust был таким.

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

Носить цветочки на могилу прекрасной незнакомки - это так романтично.

Ставить диагнозы по юзерпику это так в твоем стиле.

Ставить диагнозы по юзерпику это так в твоем стиле.

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

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

Каждый раз смешно.

Заметно.

У нас есть C, C++, Java. Это все что нам нужно. Даже с лихвой.

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

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

Честно говоря, очень сомневаюсь, что GC в языке появится на уровне «указал что-то типа use GC и пишешь не задумываясь о лайфтаймах».

Давайте обсудим их темную сторону и поговорим не о преимуществах, а о недостатках.

Ну так выскажись первым. А так это больше на вброс похоже.

Честно говоря, очень сомневаюсь, что GC в языке появится на уровне «указал что-то типа use GC и пишешь не задумываясь о лайфтаймах».

use GC? Я думаю, оно будет работать как @-указатели Rust 0.9, только вместо @ будет Gc<>, но никакого «use GC и не задумываясь»

А так это больше на вброс похоже.

Это и есть вброс. Топикстартер - малахольный тролль.

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

Что для тебя удачное сочетание?

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

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

почему тогда сейчас, много C++ кода, написанного 10 лет назад, требует допилки напильником, что-бы оно собиралось?

Это сынок, фантастика

Например какого?

Что для тебя удачное сочетание?

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

зарплата у специалиста по нему - очень даже приличная.

Угу, у всех трех востребованных специалистов.

зря боитесь

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

use GC?

Ну я образно. Признаюсь - статьи типа «Designing a GC in Rust» скорее просматривал да и то не все, но впечатление сложилось, что они ещё далеки от финального дизайна. Если так, то поменяться может многое.

Да и честно говоря, несколько поменял своё отношение к «опциональному GC». Да, это может быть очень полезно, но в бесшовную интеграцию верится с трудом. В итоге, как мне кажется, это будет штука именно для затыкания мест, где без GC сложно, но никакого снижения порога входа не будет. Но посмотрим.

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

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

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

У швифта тулчейн и рантайм под что-либо кроме макоси есть? Вот прям сейчас? Если нет, то о чем говорить?

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

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

Вот прямо сейчас уже два дня как, вроде бы.

На самом деле разница между жабаскриптом и С сильно преувеличена(взять какой-нибудь tcc, наворотить туда динамическую генерацию кода прямо из выполняющегося кода, чтобы реализовать объект Function и всё, считай разнице конец. И представьте себе, такая магия даже на уровне ядра будет работать).

Да, веб можно писать на С. И да, он был бы гораздо шустрее и лучше. В качестве веб браузера был бы просто Xserver с удобным управлением сессий. Реальный хороший код мало отличается от языка к языку. Разные технологии? Это как? Что, в ядре не используются строки, потоки, блокировки, отложенные задачи и прочее? Используются. Указатели и прямой доступ? Ну это что, технология? Вот в NT ядре даже это сильно скрыто и уже не так явно.

Я не настолько сильно углублялся в изучение Rust и Swift, а потому мне интересно направить русло дискуссии вот в этом конкретном векторе.

Я не говорю что нельзя писать веб на си, но удобно ли? Безопасно ли? Такая же производительность?

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

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

Что касается строк, я уже говорил, достаточно в tcc добавить настоящий метапроцессор, так сразу будет одинаково. Вы скажете, но ведь такого нет. А я скажу, но ведь html5 тоже ещё надавно не было.

Писать нынешний веб на С?

внезапно http://fossil-scm.org , стандарт кодирования C89.

достаточно в tcc добавить настоящий метапроцессор

Простите, а что такое «метапроцессор»?

ну придумал слово, хотя может оно уже где-то использовалось. В общем если добавить возможность вызова tcc из самого кода, который отрабатывается tcc - это будет метапроцессор. В принципе это и так есть, но нужно чтобы было конструкцией языка как Function в javascript.

Я не настолько сильно углублялся в изучение Rust и Swift, а потому мне интересно направить русло дискуссии вот в этом конкретном векторе.

Ну так хоть что-то добавил бы от себя. Выбираешь более перспективный/денежный/интересный язык для обучения или зачем тебе это вообще? Какие-то мысли даже при поверхностном знакомстве должны ведь быть. Если бы перечислил какие недостатки видишь, то и толку больше было бы.

Скажу конкретно про раст.
- Синтаксис, надо признать, довольно зашумлённый. Не то, чтобы у С++ он был лучше, но всё же.
- Проверка заимствований бывает недостаточно умной/гибкой, а иногда и вовсе спотыкается на ровном месте (SEME сгладит это в будущем)
- Система типов не столь мощна, как шаблоны С++. На шаблонах можно накостылять даже зависимые типы, когда же в расте нету и HKT. С другой стороны, грамотная система типов лучше мощных костылей. В будущем, макросы над типами и поддержка HKT сгладит эту проблему.
- Маленькая инфраструктура — ну это обычная проблема новых языков.

Я смотрю, есть ли достойный преемник C++, который не нарушает следующие принципы (выдержка из философии C++):

• Получить универсальный язык со статическими типами данных, эффективностью и переносимостью языка C.
• Непосредственно и всесторонне поддерживать множество стилей программирования, в том числе процедурное программирование, абстракцию данных, объектно-ориентированное программирование и обобщённое программирование.
• Дать программисту свободу выбора, даже если это даст ему возможность выбирать неправильно.
• Избегать особенностей, которые зависят от платформы или не являются универсальными.
• «Не платить за то, что не используется» — никакое языковое средство не должно приводить к снижению производительности программ, не использующих его.
• Не требовать слишком усложнённой среды программирования.

«Ты мне буишь рассказывать» (с) лол. Рубить именно дрова, а не сух. веточки для костра и не старые доски от сарая, чаще всего не приходится :) Не-а. Маффынку готовых привозят, потому что вырубка в сколько-нибудь крупных размерах — дело ни разу не самостоятельное (браконьерство не предлагать). А на заготовках давно ничего не «рубят» вручную: даже днища «аутсайдеры» обзавелись хускварнами (днища «Урал» с гидроклином всяко себе добудут за пузырь в ближайшей деревне), а норм. люди — «Валметами» и лесовозами. Так что потребитель получает дрова уже нормально напиленые под известные среднебольничные размеры печи. И опять таки — «ржавый топор» не при чем, кроме твоих фонтазий: ржавый он у тех, кто им редко пользуется, настолько, что топорище рассохлось и хранился в бочке :)

Я смотрю, есть ли достойный преемник C++, который не нарушает следующие принципы (выдержка из философии C++):

Отлично. Про свифт я мало что знаю, а про раст немного рассказать могу. По пунктам:

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

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

3. Тут можно спорить. Тем не менее, unsafe есть, так что свобода «выбирать неправильно» имеется.

4. «Zero-cost abstractions» на главной странице языка написано первым пунктом. Ну и в дизайне языка про это тоже говорится.

5. Что это значит? Возможность писать без ИДЕ? Ну а кто мешает. Другое дело, что мне на плюсах писать «в блокноте» не слишком комфортно. Так что как по мне, этот пункт вообще устарел. Много ли языков, которые этого не позволяют?

Мне плевать, какими лесовозами к тебе привозят дрова. Честно. И на твои лесозаготовки тоже плевать, потребитель. Деревья, если ты не в курсе, имеют свойство расти. И по весне приходится лишние ветки пилить, что-то рубить. Какие-то вовсе сохнут, если не поливать, их приходится выкарчовывать совсем. В саратовской квартире, конечно, ничего не растёт. Так что полезай назад в свою бочку.

Что конкретно не нравится?

Некроссплатформенно (mono не предлагать).

Или ты имел замену шарпа конкретно на платформе эпол?

Лично меня пока только linux интересует.

Азаза, дачнег, уже деревья в ход пошли — так бы и сказал, что в дровах ты днище :)

В саратовской квартире, конечно, ничего не растёт. Так что полезай назад в свою бочку.

Децтво мое прошло в таежной архангельской деревне, ванга, так что твой бугурт совершенно понятен :)

Децтво мое прошло в таежной архангельской деревне

...тяжелое деццтво, деревянные игрушки, колун вместо складного ножика?

Под HOT подпишусь,а вот GC нафиг не нужен.

но никакого «use GC и не задумываясь»

А чем оно тогда будет принципиально от Rc/Arc отличаться?

А вообще в Rust-е пока не хватает нормальной кросс-платформенной сборки, задолбали эти пляски возле LD_LIBRARY_PATH. Ещё не хватает стабильного select! и убранного thread::scoped (не понимаю, почему не внести scoped из crossbeam). Ещё бесит неопределённость с обработкой ошибок на итераторах: https://github.com/rust-lang/rust/issues/27802#issuecomment-161101475

А чем оно тогда будет принципиально от Rc/Arc отличаться?

Если ты о std::sync::Arc - не понял, причем тут он. От Rc оно будет отличаться простотой использования. Насчет «приницпиально» - не знаю, что ты считаешь принципиальным.