Пожалуй, одно из самых заметных изменений для каждого разработчика. Борьба с boilerplate вышла на новый уровень.
Наконец-то можно забыть про обязательные public static void main(String[] args) для простых скриптов и утилит. Язык становится более доступным для новичков и приятным для опытных разработчиков, которые ценят лаконичность.
void main() { IO.println("I'm still java. For now");}
Просто революция не меньше. Теперь не нужно писать public static и String ...args ровно в одном месте программы. К черту неконсистентность языка ровно для одного места. К черту то, что Java настолько boilerplate что без сторонней утилиты (lombok) невозможно писать нормально. Главное что в методе main теперь на пару слов меньше писать. Борьба с boilerplate вышла на новый уровень однозначно.
Официально прощаемся с 32-битными x86-системами.
При этом команда разработки демонстрирует взвешенный подход, не ломая обратную совместимость.
А сможете вы это быстро реализовать на Rust? Не слишком ли компилятор для этого требователен?)) На Python то только ленивый за 15 минут не реализует))
Ключевой вопрос в определении слова - быстро.
Если быстро за 15 минут то Python в победителях, с последующим выкидыванием решения на помойку.
Если быстро чтобы работало, тот тут с Rust будет тяжело тягаться GC языкам.
Так Python то сейчас и самый популярный/востребованный))
Удивительно что подавляющее большинство ключевых библиотек для этого языка написаны и пишуться на C/C++/Rust а не самом замечательном языке.
Да и Go то не вполне для этого. Но на Go я за 15 минут клон телеги сбацаю из стандартной библиотеки.
Странно сравнивать языки из разных миров с разными задачами. Можно с таким же успехом попросить сбацать на Go что-то высокопроизводительное, и окажется что для этой задачи Go станет внезапно сложным и неудобным.
Я попробовал вдупляться в Rust и Scala. И понял что это сложнее, чем моя математика. И перебор в смеси абстракций.
Со Scala соглашусь, а что в Rust сложного кроме системы заимствования? Ну так это у всех языков без сборщика мусора здесь всегда сложности в силу самой проблемы безопасного и эффективного управления памятью.
Какие там еще сложности и абстракции? Классов нет, наследования нет, исключений нет, даже перегрузок функций нет. Ну макросы да, но никто не заставляет.
Я, как project‑менеджер, сам так думал, пока не понял, что работу опытного специалиста надо оценивать не по количеству строк кода, а по общему результату.
Подскажите, а до того как Вы это поняли, как оценивали собственную работу? По количеству созвонов в день? Если созвонов было мало, не задумывались:
«А не зря ли я получает свою зарплату?»
Или Вам зарплату не за созвоны платят все-таки? А если так то откуда мысли про то что кому то зарплату должны за строчки кода платить?
Мне не нравится подход C++, в котором std::string это такая сишная структура, обмазанная в три слоя темплейтами, которые делают вид, что это такой строковый тип.
Компилятор реально видит сишную структуру. Отладчик видит сишную структуру. А человек видит строку, и это обман, потому что реально там никакой строки нет, а есть сложная сишная структура.
Иметь в языке хотя бы небольшой, но встроенный, набор высокоуровневых абстракций (в Go это строки, map-ы, слайсы, каналы и гороутины) оказывается весьма удобно.
Тревожно Вам это показывать, но это стандартная библиотека Go:
type file struct {
pfd poll.FD
name string
dirinfo atomic.Pointer[dirInfo]
appendMode bool
}
Вроде бы файл, а видим структуру, выходит что обман?
А вот мютекс и еще один обман:
type Mutex struct {
_ noCopy
mu isync.Mutex
}
А вот процесс:
type Cmd struct {
Path string
Args []string
Env []string
Dir string
...
}
Ну процесс же это процесс а не структура, почему не сделали волшебным ключевым словом?
Там где нет подтипив все лежит в стандартной библиотеке а где нужны - вынесено как магические части языка. Совпадение?
Нет. Это просто банальный провал разработчиков языка которые осилили дженерики только через 10 лет после релиза языка. Без дженериков написать типизированные коллекции нормально никак, поэтому были сделаны такие откровенно "волшебные" костыли.
C# это исторически язык, который делался в качестве конкурента java, и, как по мне, он всё ещё гораздо хуже. Ещё больший разрыв можно почувствовать, если попытаться сравнить C# с вышеназванным Kotlin.
Не понятно зачем делать такие выводы если очевидно что с языком Вы не очень то знакомы.
где, помимо сборщика мусора и горутин, в го магия?по-моему, го это как раз «антимагия», ни хитроумных наследований, ни макросов препроцессора, которые непонятно во что разворачиваются,…весь flow явный и прозрачный
Базовые конструкции языка через магию и костыли. Слайсы, мапы, каналы не структуры стандартной библиотеки а магические вшитые в язык конструкции, чтобы посмотреть реализацию которых нужно идти в исходники языка, тоже самое про функции для их обслуживания.
До последних версий удаление элемента из слайса было сопряжено с каких то ахтунгом.
Неявный возврат по имени.
В языке есть пустой указатель и ссылочный тип string но последний почему то по умолчанию инициализируется пустой строкой.
Язык работает со строками в UTF-8 формате но по факту позволяет хранить там что угодно.
Когда нужно создать структуру то нет никакой гарантии где она будет выделена.
Главный вопрос - а зачем? Чтобы у группы не взаимосвязанных языков был похожий синтаксис. Ну так синтаксис вторичен, главное как раз семантика, которая будет отличаться. Причем отличается не от языка к языку а внутри любой комбинации любого варианта этого языка. По итогу получите бесконечное количество языков каждый со своими правилами но со сходными синтаксисом что есть проблема. И какой в этом смысл? Приходить в компанию и каждый раз учить новую вариацию одного и того же языка?
Командный игрок — старший разработчик с достаточными хардскиллами и сильными софтскиллами. Он умеет общаться, выстраивать конструктивные отношения с мидлами и другими сеньорами, с менеджментом, и при этом не рушит атмосферу в команде.
«Доктор Хаус» — специалист с запредельными техническими знаниями, который при этом может быть токсичным в общении, самоуверенным, нелюдимым, но способен закрыть критически важные задачи для бизнеса компании. Его возьмут, потому что без него проект встанет или вовсе пойдет под откос. Но брать таких людей — это исключение, а не правило.
В нынешних реалиях «Доктор Хаус» - это скорей специалист с адекватными для уровня сеньора знаниями.
Командный игрок - это очень часто балабол, который в старых реалиях еле дотягивал до мидла а сейчас получил возможность вместо скиллов успешно лить в уши работодателю.
Достаточно провести с десяток собеседований или хотя бы посмотреть их записи чтобы открыть для себя что современные командные сеньоры чаще всего не знают толком ни базовую базу ни даже язык программирования на котором они пишут но зато очень уверенно несут ахинею.
В программировании важны такие качества как: уситчивость, внимательность, дотошность, последовательный и вдумчивый подход и так уж вышло что такие качества ну очень часто есть у людей спокойных и замкнутых. Сливать таких людей в пользу болтунов, это конечно потрясающая логика.
Может быть так эффективнее работать? Ну например когда вместо того чтобы хороший специалист молча решил проблему за час, мы ее будем неделю обсуждать на созвонах, потому что все умеют обсуждать но никто не умеет решать. Главное же не решение проблем а создание видимости их решения. Или просто так комфортнее менеджеру которому меньше работы своей делать, меньше там разруливать, меньше находить подход к людям? Путь все вокруг станут приятными и беспроблемными болванчиками, так и напрягаться меньше. Интересно, что может пойти не так с таким подходом?
Представьте себе уголовный кодекс в котором написано что преступление карается правосудием, но при этом сам кодекс не содержал бы полного определения понятия преступление. Был бы от такого кодекса толк? Вроде и написано все правильно - нельзя совершать преступления, вот только что такое преступление не очень понятно и у каждого гражданина, правоохранителя, прокурора, адвоката и судьи свое понимание что это. Очевидно что всех внешней правильности, практического смысла от такого полезного кодекса нет.
Ровно тоже самое и с SOLID. Буквы - красивые, призывы - пафосные, толку - ноль. SRP - у класса должна быть одна ответственность. Какой смысл от принципа если нет методики определения этой самой ответственности? Если так то у каждого разработчика свои критерии что будет делать класс а следовательно, уберите SRP и ничего не поменяется - у каждого разработчика остануться свои критерии что будет делать класс. ISP - тоже самое. Без методики как понять сколько много а сколько мало - толку нет. Каждый будет делать столько сколько посчитает нужным. Зачем тогда ISP? OCP - напоминает очередное делай хорошо плохо не делай а что делать и как забыли подвести и все начинают трактовать как сами понимают.
Проблема SOLID что это просто мнение одного единственного человека 20 летней давности из которого сделали священную корову в придачу с религией, о котором уже 20 лет пишут статьи и шпаргалки и все никак не могут постигнуть. Причем мнение в стиле не делай плохо - делай хорошо, а как что такое хорошо я вам не скажу. Почему вроде бы инженерные принципы не могут постигнуть уже 20 лет? Да потому что они стали религиозными.
Просто революция не меньше. Теперь не нужно писать
public staticиString ...argsровно в одном месте программы. К черту неконсистентность языка ровно для одного места. К черту то, что Java настолько boilerplate что без сторонней утилиты (lombok) невозможно писать нормально. Главное что в методе main теперь на пару слов меньше писать. Борьба с boilerplate вышла на новый уровень однозначно.В одной и той же статье.
Ваш план в том чтобы предложить заказчику дождаться светлого будущего?
Ключевой вопрос в определении слова - быстро.
Если быстро за 15 минут то Python в победителях, с последующим выкидыванием решения на помойку.
Если быстро чтобы работало, тот тут с Rust будет тяжело тягаться GC языкам.
Удивительно что подавляющее большинство ключевых библиотек для этого языка написаны и пишуться на C/C++/Rust а не самом замечательном языке.
Странно сравнивать языки из разных миров с разными задачами. Можно с таким же успехом попросить сбацать на Go что-то высокопроизводительное, и окажется что для этой задачи Go станет внезапно сложным и неудобным.
Со Scala соглашусь, а что в Rust сложного кроме системы заимствования?
Ну так это у всех языков без сборщика мусора здесь всегда сложности в силу самой проблемы безопасного и эффективного управления памятью.
Какие там еще сложности и абстракции? Классов нет, наследования нет, исключений нет, даже перегрузок функций нет. Ну макросы да, но никто не заставляет.
Подскажите, а до того как Вы это поняли, как оценивали собственную работу?
По количеству созвонов в день? Если созвонов было мало, не задумывались:
Или Вам зарплату не за созвоны платят все-таки? А если так то откуда мысли про то что кому то зарплату должны за строчки кода платить?
Забавно как быстро чаша весов перевесила с:
"ИИ подстраивается под разработку и помогает ей"
на
"Разработка подстраивается под ИИ и помогает ему".
Может быть я старомоден, но когда хвост виляет собакой то это не к добру.
Тревожно Вам это показывать, но это стандартная библиотека Go:
Вроде бы файл, а видим структуру, выходит что обман?
А вот мютекс и еще один обман:
А вот процесс:
Ну процесс же это процесс а не структура, почему не сделали волшебным ключевым словом?
Там где нет подтипив все лежит в стандартной библиотеке а где нужны - вынесено как магические части языка. Совпадение?
Нет. Это просто банальный провал разработчиков языка которые осилили дженерики только через 10 лет после релиза языка. Без дженериков написать типизированные коллекции нормально никак, поэтому были сделаны такие откровенно "волшебные" костыли.
Никто про недостатки и не говорил.
Переформулирую корректнее. В языке нет никаких гарантий при работе со строкой в какой она вообще кодировке.
Не понятно зачем делать такие выводы если очевидно что с языком Вы не очень то знакомы.
Базовые конструкции языка через магию и костыли. Слайсы, мапы, каналы не структуры стандартной библиотеки а магические вшитые в язык конструкции, чтобы посмотреть реализацию которых нужно идти в исходники языка, тоже самое про функции для их обслуживания.
До последних версий удаление элемента из слайса было сопряжено с каких то ахтунгом.
Неявный возврат по имени.
В языке есть пустой указатель и ссылочный тип string но последний почему то по умолчанию инициализируется пустой строкой.
Язык работает со строками в UTF-8 формате но по факту позволяет хранить там что угодно.
Когда нужно создать структуру то нет никакой гарантии где она будет выделена.
и т.д.
Наверное то что весь мир не сводиться к Java. Можно же также задаться вопросом - что мешало в Java добавить указатели, ведь явное лучше чем неявное?
То что в Go есть название interface это еще не значит что это interface из Java.
Почему одного там же их несколько?
Вот только почему то java уходят на Go а не наоборот
По логике да. На практике язык растет и отъедает долю рынка у Java, и этому есть причины. И это даже не мага фичи языка.
Python - это скорее обертка для библиотек написанных на других языках, как самостоятельный язык без костылей он не так чтобы много для чего подходит.
Все так, если заменить слово Java а C#.
Главный вопрос - а зачем? Чтобы у группы не взаимосвязанных языков был похожий синтаксис. Ну так синтаксис вторичен, главное как раз семантика, которая будет отличаться. Причем отличается не от языка к языку а внутри любой комбинации любого варианта этого языка. По итогу получите бесконечное количество языков каждый со своими правилами но со сходными синтаксисом что есть проблема. И какой в этом смысл? Приходить в компанию и каждый раз учить новую вариацию одного и того же языка?
Разумеется идеально, если не упоминать что на этом все плюсы микросервисов заканчиваются а все остальное превращается в сплошные минусы.
Микросервисы - это по сути жертва, на которую идут потому как по другому в сложившихся обстоятельствах никак, а не какое-то идеальное решение.
Ну между знает и не говорит и говорит но не знает я бы выбрал первое. Потому как первое еще можно исправить.
В нынешних реалиях «Доктор Хаус» - это скорей специалист с адекватными для уровня сеньора знаниями.
Командный игрок - это очень часто балабол, который в старых реалиях еле дотягивал до мидла а сейчас получил возможность вместо скиллов успешно лить в уши работодателю.
Достаточно провести с десяток собеседований или хотя бы посмотреть их записи чтобы открыть для себя что современные командные сеньоры чаще всего не знают толком ни базовую базу ни даже язык программирования на котором они пишут но зато очень уверенно несут ахинею.
В программировании важны такие качества как: уситчивость, внимательность, дотошность, последовательный и вдумчивый подход и так уж вышло что такие качества ну очень часто есть у людей спокойных и замкнутых. Сливать таких людей в пользу болтунов, это конечно потрясающая логика.
Может быть так эффективнее работать? Ну например когда вместо того чтобы хороший специалист молча решил проблему за час, мы ее будем неделю обсуждать на созвонах, потому что все умеют обсуждать но никто не умеет решать. Главное же не решение проблем а создание видимости их решения. Или просто так комфортнее менеджеру которому меньше работы своей делать, меньше там разруливать, меньше находить подход к людям? Путь все вокруг станут приятными и беспроблемными болванчиками, так и напрягаться меньше. Интересно, что может пойти не так с таким подходом?
На этом можно и закончить.
Представьте себе уголовный кодекс в котором написано что преступление карается правосудием, но при этом сам кодекс не содержал бы полного определения понятия преступление. Был бы от такого кодекса толк? Вроде и написано все правильно - нельзя совершать преступления, вот только что такое преступление не очень понятно и у каждого гражданина, правоохранителя, прокурора, адвоката и судьи свое понимание что это. Очевидно что всех внешней правильности, практического смысла от такого полезного кодекса нет.
Ровно тоже самое и с SOLID. Буквы - красивые, призывы - пафосные, толку - ноль.
SRP - у класса должна быть одна ответственность. Какой смысл от принципа если нет методики определения этой самой ответственности? Если так то у каждого разработчика свои критерии что будет делать класс а следовательно, уберите SRP и ничего не поменяется - у каждого разработчика остануться свои критерии что будет делать класс.
ISP - тоже самое. Без методики как понять сколько много а сколько мало - толку нет. Каждый будет делать столько сколько посчитает нужным. Зачем тогда ISP?
OCP - напоминает очередное делай хорошо плохо не делай а что делать и как забыли подвести и все начинают трактовать как сами понимают.
Проблема SOLID что это просто мнение одного единственного человека 20 летней давности из которого сделали священную корову в придачу с религией, о котором уже 20 лет пишут статьи и шпаргалки и все никак не могут постигнуть. Причем мнение в стиле не делай плохо - делай хорошо, а как что такое хорошо я вам не скажу. Почему вроде бы инженерные принципы не могут постигнуть уже 20 лет? Да потому что они стали религиозными.