Энергия - не конкурент Шаттлу вообще. Она могла вывести 100т чего угодно, а Шаттл при примерно тех же габаритах - 24т (и 70 тонн скорлупы и кожаные мешки) ограниченного размера. 24т на НОО может вывести банальный Протон.

Главная стоимость - стоимость двигателей первой ступени. Твердотопливные ускорители Шаттла можно было ронять в океан (а вот F1 нет, что и привело к забвению).

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

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

Корабль без системы спасения.

Бессмысленный для большинства случаев - типичная работа "Шаттла" это вывод пары десятков тонн спутников на НОО вручную. Корабль, оправданный для разовых операций, типа ремонта Хаббла, использовался в основном для операций, не требующих присутствия человека вообще.

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

И ради этого была вечная гонка - потому что любая остановка приводила к гигантским расходам. А не остановка - привела к двум катастрофам.

4 года назад мне был интересен свой сервер. Но сейчас мне уже не надо.

Но буду знать, спасибо.

Про себя ничего рассказывать не надо, качаете с оф.сайта и ставите.

Просят рассказать. Обманывать? Или есть прямая ссылка для скачивания?

Вопрос ущербности каждый сам решает для себя.

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

У вас есть self-hosted Slack сервер?

Нет. А надо?

Только бесплатная версия ещё ущербнее, чем для слак, а платная стоит дорого.

Плюс бесплатную - ставит самому и так просто не дают - надо всё о себе рассказать.

Чем это лучше слака?

kotlin/jvm + rust

Тут путаница в терминах. Я против перегузки: https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%B4%D1%83%D1%80_%D0%B8_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B9

Она не нужна для ОПП. Более того, это некоторая замена ООП для процедурных языков типа C (не C++).

Ничего плохого про методы по-умолчанию не скажу.

Я ругаю только перегрузку методов.

Не троллинга ради, но можно простенький пример?

Я ж писал - когда есть два метода с типами-интерфейсами и класс, который наследует оба интерфейса.

И если код написан не в ИДЕ, то такие методы сильно усложняют понимание написанного

Ну не сильно - потому что, опять же, всегда есть ровно один метод и его проще найти.

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

Вы про перегузку? Можно пример, когда они помогают (т.е. никак нельзя назвать два метода разными именами)?

А в чём проблема назвать их по-разному? У них разная суть - объём цилиндра и объём куба.

То, что второй использует целые числа - просто бред.

 Вы хоть раз сталкивались с реальными багами, которые вызваны выводом типов?

Да. Много раз. А совместно с extension-методами в kotlin это создаёт ещё больше проблем.

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

Нет.

Потому что метод остаётся один. И в наследнике он будет ровно такой же.

Смесь множественного (по факту дефолтных методов) наследования и перегрузки - это плохо.

Вы так говорите будто это что-то плохое. 

Всё имеет свою цену. Сахар тоже. Когда он приводит к запутанности вывода типов (и это не только компилятор/анализатор путается, люди тоже) - это дорогая цена.

Это весьма полезная возможность, особенно в отсутствии дефолт-параметров

Вот, кстати, лучше б дефолт-параметры были.

А для конструирования объектов так вообще необходимая, так как у конструкторов нет имени.

А кто их запрещал иметь? Ну кроме зацикленности авторов на С++

Конечно нет никакого тру-ООП.

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

Зато создаёт проблемы- как в выводе типов, так и с null'ами.

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

Мда, про перегруженные методы ещё Мейер писал, что это несовместимо с ООП.

Но создатели java не читатели были :(