А Гослинг был главным консерватором в Джаве — тоже известный факт.
Прочитайте статью — там многое написано, про их объяснения в том числе. Почему другие языки смогли а вот в Джава ну вот никак нельзя. Ну точнее можно, но только спустя лет 10.
Здравствуйте! На самом деле я Раст сознательно не разносил в посте. Во-превых, не знаю в чем его недостатки, очень мало игрался, но очень хочу. Во-вторых, на первый взгляд у него нет недостатков :) В-третьих, его сообщество выглядит действительно реальным а не бутафорским.
Вот только что в голову приходит. Вот, например, Go мы обсуждаем. А почему он есть вообще? Почему Rust его не убил. И кроме гугла, есть одна забавная причина — Go выбрали как язык для DevOps. Очень много тулов на нем написано и вцелом идет процесс замещения Python на Go у DevOps. Я спросил у них (DevOps'ов) почему не Rust или что-то другое? Ответ был такой: Rust немного сложноват своим борроунгом, если бы этой «лабуды» не было, то мы бы писали на нем скрипты и тулы. И вот я думаю, нельзя ли сделать так, чтобы бороунг был опциональный, типа если пишешь без него, то какой-то там Боэм GC включается и все норм.
Просто ^ как мысль, не знаю, классная это идея или нет.
Разработка языка — это все-таки не фича. Это весь проект скорее. Проект состоит по сути из архитектуры основной и набора фич. По крайней мере в моей голове. Так вот проекты идут и 3 и более лет в моей жизни тоже. Ни одна фича не может занимать сама по себе более 3 месяцев. Это либо плохое разбиение на фичи, либо я не знаю что…
По поводу го и дженериков. Слушайте, во многих языках дженерики были сделаны без переписывания компилятора и довольно быстро. Быстро уже в Go не получилось. А что там с переписыванием мы узнаем когда будет Go 2.
А теперь Kotlin показывает, что не обязательно надо выражать асинхронность в системе типов (Task[T], Future[T]) и иметь какие-то специальные инструкции. Можно писать асинхронный код как обычный. По крайней мере идея такая и реализация похожа. Идея интересная и может стать стандартом.
Java Primitive Types же? Что не так? Примитивы = Примитивные типы = Primitive types…
Не обязательно писать на C++, можно иметь GC и при этом иметь кастомные примитивные типы.
Со всем согласен. Я пытался в очень простую логику. Енамы — это далеко не лябда функции и не какие-нибудь сложные дженерики. Это довольно простая фича языка, которая есть почти везде.
Теперь, если они не нужны — то не понятно, зачем их добавляют (помните у нас ведь есть Enumeration в Scala из коробки...). Если они нужны, то не понятно, почему так поздно и что это за лажа была c Enumeration.
Погодите, тогда получается еще хуже — в язык совершенно без надобности добавляют новое ключевое слово спустя долгие годы его существования. Т.е. это нормально взять и чего-нибдуь ненужного добавить в язык?
Я был в ситуации где нужны енамы и совместимость с Java и все остальные нормальные характеристики енамов, которых ныне существующие костыли не имеют. Я завидую вам, что вы не бывали.
Я ваше мнение уважаю.
Напрягает, что всякими подобными аргументами мне объясняли отсутствие «синтаксического сахара» в Java, в то время как C# уходил далеко вперед. Теперь вы говорите, что люди не пересаживаются на новые версии Java — с чего бы это?
Вобщем, наш разговор через 5 лет: в Java в очередной раз пытаются догоняя добавить все недостающее, но это не особо и надо, потому что те кому было надо сегодня: поменял стек/пересел на Kotlin/пересел на Scala. И мы опять говорим, что проблема не в языке, а в том, что последние версии Java не так бодро адаптируются.
Как вам такая мысль?
Если конкретно про кастомные примитивы, то:
Лично я почувствовал боль, когда пересел с C# на Java (в 2013 году) и обнаружил, что DateTime в Java — это reference type. В .Net всегда были кастомные и ими пользовались по делу, например для DateTime и Guid.
Вцелом, если не нужны кастомные, то может быть и некастомные не нужны тоже? Зачем какие-то исключения вообще — здесь у нас reference, а тут у нас primitive. Это заставляет разраба думать об этом, у этого должен быть какой-то профит…
В финансах (критичных к внезапной сборке мусора) очень важно не создавать мусора, из-за этого там DateTime — это всегда long unix-time только в UTC. И куча helper-функций чтобы ч ним нормально работать… С кастомным примитивом DateTime этот огород был бы не нужен.
Это интересная мысль. Думаю да — если везде был хотя бы базовый набор, я бы даже не замечали что переключаюсь между языками. Ну за исключением переключения ООП-ФП-Нативщина…
Предсказываю передним числом: Java нужна null-safety и тому есть множество причин и сигналов. Null-safety с болью тащат в C# (тоже толго, особенно учитывая когда появился Nullable тип). Однако по ряду причин, описанных в статье в Java не будет null-safety в ближайшие 5 лет.
Вобщем, я с вами согласен. Но некоторые примеры настолько очевидны, что уже сложно спорить. Например ближе к концу есть абзацы про Java, C# и enum'ы в Scala. Те, кто спорил потом переобулся без объяснения причин. И говорим мы о прошлом только потому, что ретроспективна очевидна их неправота.
Ход и направление мысли одобряю.
Мне лично интересно это направление со стороны микросервисов. Там последние несколько лет решаются (с переменным успехом) все проблемы которые выше самого сервиса, подразумевая, что все что внутри — это не проболема — оно же микро. Однако на практике я вижу, что люди такое городят внутри микросервиса, что очень хочется выдать им что-то вот вроде твоей штуки и принудить их к единому стандарту в котором все четко и понятно.
Но мы далеко ушли от темы, с языком в котором целая индустрия использует long вместо DateTime что-то явно не так — все, что я хотел сказать.
Прочитайте статью — там многое написано, про их объяснения в том числе. Почему другие языки смогли а вот в Джава ну вот никак нельзя. Ну точнее можно, но только спустя лет 10.
Вот только что в голову приходит. Вот, например, Go мы обсуждаем. А почему он есть вообще? Почему Rust его не убил. И кроме гугла, есть одна забавная причина — Go выбрали как язык для DevOps. Очень много тулов на нем написано и вцелом идет процесс замещения Python на Go у DevOps. Я спросил у них (DevOps'ов) почему не Rust или что-то другое? Ответ был такой: Rust немного сложноват своим борроунгом, если бы этой «лабуды» не было, то мы бы писали на нем скрипты и тулы. И вот я думаю, нельзя ли сделать так, чтобы бороунг был опциональный, типа если пишешь без него, то какой-то там Боэм GC включается и все норм.
Просто ^ как мысль, не знаю, классная это идея или нет.
По поводу го и дженериков. Слушайте, во многих языках дженерики были сделаны без переписывания компилятора и довольно быстро. Быстро уже в Go не получилось. А что там с переписыванием мы узнаем когда будет Go 2.
Не обязательно писать на C++, можно иметь GC и при этом иметь кастомные примитивные типы.
Теперь, если они не нужны — то не понятно, зачем их добавляют (помните у нас ведь есть Enumeration в Scala из коробки...). Если они нужны, то не понятно, почему так поздно и что это за лажа была c Enumeration.
В .Net они называются «Value Types»: docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/value-types
Я был в ситуации где нужны енамы и совместимость с Java и все остальные нормальные характеристики енамов, которых ныне существующие костыли не имеют. Я завидую вам, что вы не бывали.
Напрягает, что всякими подобными аргументами мне объясняли отсутствие «синтаксического сахара» в Java, в то время как C# уходил далеко вперед. Теперь вы говорите, что люди не пересаживаются на новые версии Java — с чего бы это?
Вобщем, наш разговор через 5 лет: в Java в очередной раз пытаются догоняя добавить все недостающее, но это не особо и надо, потому что те кому было надо сегодня: поменял стек/пересел на Kotlin/пересел на Scala. И мы опять говорим, что проблема не в языке, а в том, что последние версии Java не так бодро адаптируются.
Как вам такая мысль?
Лично я почувствовал боль, когда пересел с C# на Java (в 2013 году) и обнаружил, что DateTime в Java — это reference type. В .Net всегда были кастомные и ими пользовались по делу, например для DateTime и Guid.
Вцелом, если не нужны кастомные, то может быть и некастомные не нужны тоже? Зачем какие-то исключения вообще — здесь у нас reference, а тут у нас primitive. Это заставляет разраба думать об этом, у этого должен быть какой-то профит…
В финансах (критичных к внезапной сборке мусора) очень важно не создавать мусора, из-за этого там DateTime — это всегда long unix-time только в UTC. И куча helper-функций чтобы ч ним нормально работать… С кастомным примитивом DateTime этот огород был бы не нужен.
Мне лично интересно это направление со стороны микросервисов. Там последние несколько лет решаются (с переменным успехом) все проблемы которые выше самого сервиса, подразумевая, что все что внутри — это не проболема — оно же микро. Однако на практике я вижу, что люди такое городят внутри микросервиса, что очень хочется выдать им что-то вот вроде твоей штуки и принудить их к единому стандарту в котором все четко и понятно.