Нужно. Надо же в c++17 фичи откуда-то брать.

языка программирования со статической типизацией

оно будет меньше тормозить и жрать памяти? или это просто чтобы быдло-индусов на цепь посадить?

еще один мертворожденный язык

со статической типизацией

Бе.

не нужно, есть kotlin^W scala, java. Этим кто-то кроме красношапок пользуется?

Для бэкенда JavaScript можно включить и динамическую, с помощью блока dynamic, и для JVM хотят реализовать то же самое.

Другой вопрос, что тогда теряются те преимущества статической типизации, ради которых язык и разрабатывается.

Потом они перепишут на нем pulseaudio и systemd, и всем придется писать на этом языке все...

HTTP-сервер встроен в язык или как понимать написанное?

use clojure, Luke

Gavin King - быдлокодер же, он в хибернейте сделал все ошибки неопытного программиста, какие возможно, и теперь чтобы как-то это смягчить пишет новый язык.

Типизация параметров на этапе выполнения (реификация) для generic-типов. Эта возможность давно поддерживается в .NET, но не в Java.

А это разве не фича (или отсутствие оной) в JVM?

Похоже сейчас мода на типизированный яваскрипт пошла. Гугл свой запилил, потом микрософт и теперь вот ред хат

Называется type erasure. И как мне кажется, для некоторых языков типа Scala это не просто фича, а механизм реализации всяких вещей типа higher kind и variance. Полагаю, что одной из главных причин того, что Scala не пошла на .NET стало то, что в .NET нет type erasure, а есть честные генерики, но с довольно узкими возможностями, недостаточными для Scala. Могу и ошибаться. В общем, недостаток превращается в достоинство, и наоборот.

Чем оно лучше скалы?

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

По-моему в .NET есть type erasure (вспоминаю это в доке по F#).

Ну так можно при компиляции в CLR вообще же эти дженерики на низком уровне не использовать, а хуячить проедурной лапшой, разве нет?

Если бы там еще численные типы по спецификации не были ограничены только 64х-битной плавучкой, только хардкором, то платформа была бы еще более универсальной. А так и корпоративны е приложения идут мимо, так как никому не нужно, чтобы копейки/центы при расчете больших сумм терялись, да и на слабых устройствах гонять всю арифметику на FPU тоже медленно выходит.

как мне кажется, для некоторых языков типа Scala это не просто фича, а механизм реализации всяких вещей типа higher kind и variance

как type erasure этому помогает?

Потом они перепишут на нем pulseaudio и systemd, и всем придется писать на этом языке все...

Угу, встроенный HTTP-сервер уже есть, осталось добавить бинарные сообщения об ошибках и генератор QR-кода. )

И ведь никто не удосужился поздравить GNU/Столлмана.

"Frustra fit per plura quod potest fieri per pauciora"(с)

То, что можно объяснить посредством меньшего, не следует выражать посредством большего.

Кульхацкер-хелловордист детектед.

А Ceylon можно в нативщину перегонять? Они планируют такое в будущем?

Нативщина нинужна, нативщина должна остоваться в JITе виртуальной машины.

Нативщина нинужна, нативщина должна остоваться в JITе виртуальной машины.

Что ты имеешь против AOT? :) ну ты еще скажи что AOT не нужен в Mono/Android, насмеши меня

Большие возможности по runtime-оптимизации у JIT.

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

Gavin King - быдлокодер же, он в хибернейте сделал все ошибки неопытного программиста, какие возможно

А вот здесь подробнее, что в нём не так?

Хоть мне и побоку на нативный хибернейтовский API, я пользуюсь JPA.

HTTP-сервер встроен в язык или как понимать написанное?

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

Симпатичный и разумный язык - можно сказать глядя на синтаксис и обсуждение в reddit.

а зачем компилить все возможные функци, когда можно только используемые?

Сколько уже можно плодить языки?

По-моему в .NET есть type erasure (вспоминаю это в доке по F#).

Нет. Там можно объявить IEnumerable и IEnumerable<T>. Это будут два разных типа.

как type erasure этому помогает?

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

Я думаю, что главная проблема в интероперабельности. Язык должен как-то взаимодействовать с окружающей средой, в данном случае c .NET. На модель генериков .NET язык Scala точно не ложится - последняя явно богаче. Представим, что генерики Scala реализованы без генериков .NET, имитируя type erasure. И как после этого код на Scala будет выглядеть из обычного C#? Например, код на F# из C# выглядит вполне неплохо, особенно если добавить атрибут CompiledName.

Первый раз слышу про «type erasure», хотя писать на цэшарпе с генериками это никак не мешает.
Да и в целом, кто пишет под дотнет, какать хотел на всякие скалы и уж тем более на Целофаны из ортогонального мира красноглазых шапок.

Type erasure в .NET и нет. Он - в JVM.

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

а, так мы про компиляцию динамического языка

то пишет под дотнет, какать хотел

Логический вывод - все кто пишет под дотнет - засранцы. Да мартышка?

Я думаю, что главная проблема в интероперабельности.

вот поэтому то в scala type erasure. Кстати там же есть Manifest, вполне себе решение для житья-бытья в .Net

Озабоченный нищеброд перешел на Brainfuck? Похвально, растешь!

Ты тупой. Фича JVM - отсутствие низкоуровневой поддержки джинериков. Type erasure - фича компилятора Жабы. Никто не мешает убивать джинерики во время компиляции в любой другой рантайм.

Нет, тупононимус, ваще всё перепутал! Жабствуй дальше, этот трэд не для средних умов.

вот поэтому то в scala type erasure. Кстати там же есть Manifest, вполне себе решение для житья-бытья в .Net

Type erasure происходит и в Java, и в Scala потому, что в байт-коде нет параметрических типов. Наприме, запусти к примеру jad - там все будет видно.

Попробую повторить еще раз свою мысль. Модель генериков .NET слаба для представления генериков Scala. В то же время, убогая модель генериков Java оказалась в самый раз для генериков Scala, потому что в этом случае не возникает (больших?) проблем с интероперабельностью с Java. Парадокса здесь нет. В .NET могут быть проблемы с интероперабельностью Scala и C#.

брысь обратно в клоаку!

Еще я хочу сказать, что дизайн Scala привязан к Java, так же как дизайн F# - к C# и .NET. Дело и в модели генериков на самих хостовых платформах, да и в том, что модель генериков Scala слишком богата для них (variance, к примеру), но в случае Java это не так заметно.

Манифест тут с боку-припеку, да и у него есть ограничения.

Типизация параметров на этапе выполнения (реификация) для generic-типов.
Типобезопасная метамодель.
Аннотации, определённые пользователем.

Взаимоисключающие фичи.

Сериализация.

До сих пор нет!?!? Как с этим работать???

Ты тупой. Убогая модель Java - подмножество убогой модели .NET. Тебя, лошара, никто не заставляет использовать нативные джинерики в .NET. Вбейся в стеночку, убогий.

Обоснуй, отродье свиньи. Кто тебя ЗАСТАВЛЯЕТ использовать нативные джинерики в .NET?

Взаимоисключающие фичи.

Почему?