Василий Банников

Например метод map_err. Статейка

pub fn build_server_config(&self) -> Result<Config, ConfigError> {
    let socket_addr_v4 = self.socket_addr.parse::<SocketAddrV4>()
        .map_err(ConfigError::WrongSocketAddr)?;
    Ok(Config {
        // инициализация полей Config
    })
}

DTO объекты часто пересекают границы Языков (Java/JavaScript/GWT) и сетевых протоколов (Rest/Graphql/SOAP/Avro).

И эти объекты могут нести на себе семантику только чистых данных. Вы не сможете через сеть
из Java в C# например передать интерфейс или объект с методами.

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

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

Да. Это отчасти правда. Основные заказчики Java разработки - это банки. А они не любят миграции версий
без какой-то особой причины. Я работал с тремя банками и я могу сказать что большая часть кода - это
легаси. И совершенно нет никакой надежды что будет bump версии языка. Product owner-ы в таком случае
задают вопрос - "а что мы с этого будем иметь". И обычно для банка - ничего особенного. В некоторых
случаях (использование CORBA или JAXb, com.sun.*) повышение версии чревато проблемами. Что-то
может резко отвалиться в новой версии.

Самые интересные новшества после JDK8 с моей точки зрения были не в языке а в других слоях JRE/JDK (GC, FFI, vectorization, unmanaged memory). Но вы еще попробуйте эти новшества продать бизнесу. Успехов вобщем.

На какой версии лучше всего практиковаться в написании кода, да и обучаться в целом?

Да. Ты можешь брать самую последнюю LTS-версию. Брать preview нет никакого смысла. Очень
сомнительно что для учебы тебе кто-то даст в туториалах экспериментальные фичи. Скорее наоборот.

Есть ли вообще предпосылки на переход большей части энтерпрайза в ближайшем будущем (ближе к 2030) на более современную версию? Почему тезис о дорогом переходе не нивелируется тем, что за 10 лет со времён восьмёрки завезли достаточно "контента", например, новый синт.сахар и обновленный GC?

Никакого глобального перехода на самом деле нет. Потому что нет такой проблемы.
По сути проблемой например для Java 21 может стать "end of extended support" а он условно отмечен
например на 2031 год. Вы еще попробуйте доживите до этого года и попробуйте сидеть на одном проекте
столько лет.

Java может стать COBOL-ом XXI столетия. Но у нее будет даже меньше проблем чем у Кобола, потому что
байткод и стек-машина имеет больший потенциал. Тоесть пока жива концепция байт-кода и пока существуют
процессоры Фон-Нейман архитектуры, можно сказать что Java неубиваема.

Вообще не стоит вам сильно циклиться только на языке. Параллельно существуют Scala, Kotlin, Groovy, Clojure
и их само существование делает много альтернатив. Одна JVM - бесконечное число языков.

Забавно вы как-то подменяете местами причины и следствия.
Вам надо научиться бэкенду, чтобы написать проектов и забить ими гитхаб профиль, чтобы вас взяли на работу?
Надо понимать. что освоить придётся дохрена информации, повысить свою эрудицию и непрерывно учиться. Единого исчерпывающего источника всей необходимой информации не бывает, а бэкенд (даже питонячий) - это большая и широкая область, в которую в глубину можно копать тоже в любом направлении.

Есть ряд простых и действенных советов.
1) Блокнот терминов.
Вы слушаете много всяких лекций по теме, читаете статьи, изучаете код других проектов и при этом встречаете много незнакомых слов, терминов, названий библиотек и технологий. Нужно выписывать эти слова в блокнотик. Не важно будет ли он бумажный или цифровой. Важно регулярно выделять время на сортировку его содержимого и изучение (хотя бы поверхностное) всего, что там написано. Это сформирует эрудицию.
2) Читать чужой код. Искать инетресные вам проекты библиотек и вообще софта на гитхабе и разбираться как там внутри и что. Это пополнит ваш блокнот из п.1 и повысит насмотренность кода. Если что-то не понятно почему оно так как есть, то стоит лбо поразбираться в этом, либо отложить до лучших времен.
3) Писать свой код. Если вам не интересно, то вы не достигнете никакого успеха. А если интересно, то вы будете этим заниматься, если не позволите себе прокрастенировать.
Выберите интересны вам проекты и направления и пишите помаленьку код. Начните с простого, с MVP, потом развивайте. Если уже на этом шаге трудности, то впору задуматься надо ли оно вам. Если надо, то трудности можно преодолевать. Я не буду сейчас тут сочинять и придумывать за вас ваши трудности. Приходите с конкретными вопросами. Этот пункт про написание кода, которым за одно и заполнится ваш гитхаб. Выберите задачу, которая вам интересна, и делайте. Если на знаете с чего начать - сформулируйте в маркдауне бизнес-требования, выделите MVP, сформулируйте ТЗ, разбейте на крупные задачи, декомпозируйте их до выполнимых подзадачек. Если не писать код, то вы не научитесь это делать и у вас не будет кода. Если писать его, то всё будет.
4) Идите в джуны и на стажировки. От вас там особо никто не будет требовать каких-то особых знаний, но может попасться хороший ментор, и, если вывезите, то будет хороший старт. Да, мало кто рискует и выделяет ресурсы чтобы учить джунов, но ищущие обрящут. см. п.6
5) Читайте классику (книги по алгоритмам, технологиям, фреймворкам и т.д. Спорный пункт. но если читать такие книги как художественную литературу, то вы можете начать мыслить в контексте изучаемых технологий и нужными терминами.
6) Ходите на собесы, решайте задачи публикуемые с собесов. Это позволит найти местечко для стажировки. перестать бояться собеседований и неудач, понять что нужно рынку и индустрии, пополнить блокнотик словами, которые следует изучить.
7) Не путайте цели и средства. Пишут код. чтобы научиться, а не чтобы забить гихаб и благодаря этому устроиться. Работодателю пофиг на гитхаб, ему важно, чтобы вы делали его задачи из трекера и собеседвоание призвано вы]вить вашу способность к этому. Если какой-то конкретный работодатель предложил вам пойти сперва заполнить свой гитхаб, то это значит что он так вежливо вам намекнул, что ваша квалификация и опыт его не устраивают. Гитхаб - это предлог. Однако и индикатор, кстати, тоже.

Неси и чини по гарантии

И нет, не безопасно! Скорее всего конденсатору кирдых, но он мог за собой потащить в Вальхаллу и еще что-то.
Стоимость блока питания обычно на порядок меньше стоимости всех остальных компонентов, которые он должен питать правильными токами и напряжениями.
Так что Вам решать, пользоваться ли неисправным блоком питания...

Если мы говорим, про C#, то грубая кривая такая:
1. Проходишь метанит - поверхностное понимание C#
2. Проходишь ULearn - уже более менее норм владеешь (все 2 курса)

Нас в вузе по юлерну учили, он нам полностью заменял и пары и дз (отметки по нему ставили)

Но ты указал еще Unity. Я не unity разраб, но:
1. Приступай к нему ПОСЛЕ освоения C# (всех шагов выше)
2. Можешь видео у Романа Сакутина посмотреть (+ он книгу выпустил, но не знаю можно ли советовать)

PS: C и C# - это совершенно разные языки
PPS: столько красных флагов в одном вопросе - simplecode и itvdn как основа, странное преподношение материала на ulearn, unity сразу после основ C#. Как по мне это все надо инвертировать и получится более менее полезные советы