Почему Rust должен стать функциональным языком программирования

Нет, вы не правы. Хаскель ничего не будет делать со списком, пока не потребуется результат. RA никакого отношения к ленивости не имеет.
О какой семантике речь, если в хаскеле [a] это явное описание связанного списка. У вас в С++ есть RA по связанному списку? Нет.
Т.е у вас нет никакой классификации и вы сравниваете мягкое и теплое.

Почему Rust должен стать функциональным языком программирования

Что значит "в c++ честная ленивость". По какой классификации вы делите ленивость, и как определить честную/нечестную? Насколько я знаю в c++ вообще нет ленивости на уровне языка(или в новых версиях появилась?).
А хаскель, насколько я знаю, ничего с последовательностью умноженной на 2 делать не будет, пока не понадобится результат.

Is Delphi Dying — False

А в чем заключается "хорошая поддержка веба"? Не лучше чем в любом другом языке, да и кроссплатформенностью никого не удивить уже

Is Delphi Dying — False

Ну, такого динозавра как Java же используют и ничего…

Is Delphi Dying — False

А в чём проблема размещать на хабре?

Место enum в современном изменчивом мире

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

Место enum в современном изменчивом мире

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

Место enum в современном изменчивом мире

То, что перечислил автор — не проблемы. Обновить клиент? Это проблема?
Ошибка при десериализации нового значения в базе на старом клиенте? Это нормально, так и должно быть.
Тип это в любом случае ограничение, на которое можно опираться в дальнейшем. Если это становится невозможным, выход один — рефакторинг, пускай он иногда и бывает сложным.
Опять же, «унисекс» это не пол. И если предусматривать возможность отвязки одежды от пола, это не означает что нужно убирать пол у персонажа. Как в ПАБГ, где мужчина может надеть платье, но выглядеть оно будет как платье на мужике. Таким образом типы делают своё дело, ограничивая нас от необдуманной логики «унисекс», которую можно не реализовывать.

Место enum в современном изменчивом мире

И все они применимы не только к данному enum, а значит нужно более общее решение

Место enum в современном изменчивом мире

Чем Вас не устраивает решение с Optional? Даже для одного поля, это будет работать. Не нужно захламлять Enum лишними сущностями, подобную логику возможно использовать и для других полей.

Место enum в современном изменчивом мире

Для этого есть специальный термин, называется overengineering. Всё предугадать невозможно, и в данном случае использование enum будет вполне оправдано.
«Не определен» это не пол. Если есть такое поле, значит есть и другие поля, которые «не определены», и нужно вводить тип для отображения этого состояния на другие объекты. Возможно, «не определен» будет возраст. Что тогда — не будем использовать int для хранения возраста?
Можно сделать тип Optional/Maybe a, и отображать пустое значение в базе как null.
null для пола не занят, как Вы ошибочно предположили. Для сущности HasSex null можно трактовать как пустое значение NotPresent/Nothing, а для сущности не HasSex его вообще не надо никак трактовать.

Место enum в современном изменчивом мире

Определенно, объекты, к которым применимо понятие «пол», будут реализовывать интерфейс HasSex, например. А как это будет в базе — другой вопрос, зависящий от модели данных бд, принятый подход к выбору стратегии отображения наследования, итд. В данном случае, если учесть что нужно сохранить совместимость(и обратные миграции не используются), в базе это можно отобразить как нулевое поле.

Место enum в современном изменчивом мире

Если пол не применим к объекту, следует отделить объекты, к которым пол применим, для других enum просто не потребуется. Что вы имеете в виду под «унисекс»(ваше пояснение непонятно)? Объекты, находящиеся в тени так же не относятся к множеству тех, для которых применимо понятие пол.
В конце концов можно добавить что-либо в перечисление, и если при откате на старую бд произойдет ошибка при работе с новым вариантом — это нормальная ситуация.

Вкалывают роботы — счастлив человек

Удобно для проверки на null в конструкторах:
this.$VAR$ = Objects.requireNonNull($VAR$, "$VAR$ must not be null");

Место enum в современном изменчивом мире

Да, наверное вы правы. Разделил бы поля sex и gender, и для первого использовал enum =)

Место enum в современном изменчивом мире

Для гендеров как раз удобно использовать enum. Т.к. их всего два.