[Программирование, Java, Совершенный код, C#, Kotlin] Лучший язык программирования
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Этот вопрос на первый взгляд звучит вызывающе, едва ли не табуирован, на него часто всплывает заезженный ответ, что все субъективно и зависит от задачи. Так ли это на самом деле?
Возвав к логике и здравому смыслу, попытаемся выявить наиболее объективные критерии сравнения языков программирования. Кто не боится разочароваться, увидев свой любимый язык заклейменным и преданным позору, давайте рискнем порассуждать, что лучше подходит для индустриальной разработки?Принципы отбораЭкосистем много, начинать с выбранных достоинств какой-то одной глупо, поэтому действовать будем методом исключения по ясным пунктам. Все сравнения опираются на объективные бенчмарки.ПоддерживаемостьПрежде всего, язык должен быть достаточно мейнстримным, чтобы проект на нем был поддерживаемым. Сразу выбрасываем за борт всю экзотику и функциональщину вроде Haskell, Elixir, Nim, Erlang… умирающий Ruby туда же. По этой же причине отбрасываем и всевозможные языки закрытых (Swift) и тем более окукленных по паспорту (1C например) экосистем.ТипизацияОбщая практика в индустрии показывает что слабая типизация однозначно вредит читаемости, поддерживаемости и порождает большое количество ошибок, поэтому выкидываем JavaScript и PHP. Далее, замечаем что динамическая типизация ухудшает скорость работы, а варианты компиляции традиционно динамических языков, отличаются плохой поддерживаемостью, и выглядят скорее как извращение приделанное сбоку костылями, поэтому за бортом остаются и строго-типизированные, но динамические Python и TypeScript.В сухом остаткеУ нас остались мейнстримные, строго-статически-типизированные C#, Java, C++, C и восходящие в последнее время к ним Kotlin, Go и Rust. Не каждый пожелает (а еще меньше смогут) использовать C++ в большом проекте, поэтому, несмотря на лучшие пока показатели по скорости, отложим его вместе с более низкоуровневым Си для узких мест.Java vs C#C# и Java близнецы. Экосистемы обоих языков на данный момент открыты и очень развиты. Java здесь выходит вперед за счет большего количества инструментов, библиотек, конкуренции и вариантов выбора. Но C# более стройный синтаксически, в нем исправлены известные проблемы Java (слабые дженерики пропадающие на этапе компиляции, отсутствие пользовательских значимых типов на стеке, сочетаемость значимых и ссылочных типов как List). Кроме того у .NET в целом лучшие показатели по скорости и памяти.KotlinДолгое время C# выглядел практически идеальным по кроссплатформености, высокоуровневости абстракций и скорости приближающейся местами к С++. Однако практика с Kotlin показала, что он превосходит C# и по концепциям, и по синтаксической стройности. И вот почему. Если C# идет по пути добавления в ядро языка все новых и новых абстракций и ключевых слов, то в Kotlin весь синтаксический "сахар" базируется на встраиваемых лямбдах и функциях области видимости и вынесен в стандартную библиотеку. В чем здесь преимущество? Почти любую фичу, казалось бы языка, в Kotlin можно прочитать в стандартной библиотеке и понять как любой другой код. Kotlin, правда, немного уступает C# по скорости, но лишь потому что компилируется в байт-код Java.Go?Несмотря на успех в своей нише, в целом тут все так грустно и очевидно, что без лишних слов перейдем дальше к Rust.Rust?Начать следует с того что у Rust порог входа выше чем у C++, уже потому что на C++ сразу можно писать как на любом другом высокоуровневом ЯП, предоставив стандартной библиотеке разруливать работу с памятью. Rust же не даст спрятаться от решения вопросов безопасности и размещения в памяти и из-за этой необходимости, он (внезапно!) превращается в достаточно низкоуровневый язык, сравнимый скорее даже с Си, чем с C++.ВыводМы по возможности непредвзято рассмотрели объективные факторы способствующие индустриальной разработке. Вывод из них все же неизбежно будет субъективен. Поэтому привествуются альтернативные выводы!
Итак, по моему мнению, на текущий момент, для написания большинства кроссплатформенных приложений удобнее всего использовать Kotlin, дополняя его C++ в тех случаях когда требуется скорость. Kotlin прекрасно подходит для бекендов, язык экосистемы Android по умолчанию, без проблем компилируется в JS и WebAssembly для браузеров, с небольшими приседаниями может быть использован для iOS, а с помощью jpackage легко подготовить самодостаточный исполняемый файл для Windows, macOS, Linux в "родном" формате.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Java, Scala, Apache, Natural Language Processing] Программируемые NER компоненты
- [Python, API, Программирование микроконтроллеров, Разработка для интернета вещей] Опыт написания IDL для embedded
- [JavaScript, ООП] Создание квадратизированной галереи проектов на JS v 2.0
- [Разработка мобильных приложений, Разработка под Android, Kotlin] Стоп рефакторинг. Kotlin. Android
- [Совершенный код, .NET, API, C#, Микросервисы] Паттерн CQRS: теория и практика в рамках ASP.Net Core 5
- [Ненормальное программирование, JavaScript, Разработка игр] Свежий взгляд на честное 3D в браузере
- [JavaScript, Программирование] Полезные расширения VS Code для JavaScript-разработчиков (перевод)
- [.NET, C#] Реализация Minecraft Query протокола в .Net Core
- [.NET, C#] IQueryable порождает сильную связанность (перевод)
- [Программирование, Lisp, Emacs, Clojure] Что не так с Лиспом? (перевод)
Теги для поиска: #_programmirovanie (Программирование), #_java, #_sovershennyj_kod (Совершенный код), #_c#, #_kotlin, #_c#, #_java, #_kotlin, #_rust, #_go, #_c++, #_.net, #_jvm, #_clr, #_perfomance, #_programmirovanie (
Программирование
), #_java, #_sovershennyj_kod (
Совершенный код
), #_c#, #_kotlin
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:38
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Этот вопрос на первый взгляд звучит вызывающе, едва ли не табуирован, на него часто всплывает заезженный ответ, что все субъективно и зависит от задачи. Так ли это на самом деле? Возвав к логике и здравому смыслу, попытаемся выявить наиболее объективные критерии сравнения языков программирования. Кто не боится разочароваться, увидев свой любимый язык заклейменным и преданным позору, давайте рискнем порассуждать, что лучше подходит для индустриальной разработки?Принципы отбораЭкосистем много, начинать с выбранных достоинств какой-то одной глупо, поэтому действовать будем методом исключения по ясным пунктам. Все сравнения опираются на объективные бенчмарки.ПоддерживаемостьПрежде всего, язык должен быть достаточно мейнстримным, чтобы проект на нем был поддерживаемым. Сразу выбрасываем за борт всю экзотику и функциональщину вроде Haskell, Elixir, Nim, Erlang… умирающий Ruby туда же. По этой же причине отбрасываем и всевозможные языки закрытых (Swift) и тем более окукленных по паспорту (1C например) экосистем.ТипизацияОбщая практика в индустрии показывает что слабая типизация однозначно вредит читаемости, поддерживаемости и порождает большое количество ошибок, поэтому выкидываем JavaScript и PHP. Далее, замечаем что динамическая типизация ухудшает скорость работы, а варианты компиляции традиционно динамических языков, отличаются плохой поддерживаемостью, и выглядят скорее как извращение приделанное сбоку костылями, поэтому за бортом остаются и строго-типизированные, но динамические Python и TypeScript.В сухом остаткеУ нас остались мейнстримные, строго-статически-типизированные C#, Java, C++, C и восходящие в последнее время к ним Kotlin, Go и Rust. Не каждый пожелает (а еще меньше смогут) использовать C++ в большом проекте, поэтому, несмотря на лучшие пока показатели по скорости, отложим его вместе с более низкоуровневым Си для узких мест.Java vs C#C# и Java близнецы. Экосистемы обоих языков на данный момент открыты и очень развиты. Java здесь выходит вперед за счет большего количества инструментов, библиотек, конкуренции и вариантов выбора. Но C# более стройный синтаксически, в нем исправлены известные проблемы Java (слабые дженерики пропадающие на этапе компиляции, отсутствие пользовательских значимых типов на стеке, сочетаемость значимых и ссылочных типов как List). Кроме того у .NET в целом лучшие показатели по скорости и памяти.KotlinДолгое время C# выглядел практически идеальным по кроссплатформености, высокоуровневости абстракций и скорости приближающейся местами к С++. Однако практика с Kotlin показала, что он превосходит C# и по концепциям, и по синтаксической стройности. И вот почему. Если C# идет по пути добавления в ядро языка все новых и новых абстракций и ключевых слов, то в Kotlin весь синтаксический "сахар" базируется на встраиваемых лямбдах и функциях области видимости и вынесен в стандартную библиотеку. В чем здесь преимущество? Почти любую фичу, казалось бы языка, в Kotlin можно прочитать в стандартной библиотеке и понять как любой другой код. Kotlin, правда, немного уступает C# по скорости, но лишь потому что компилируется в байт-код Java.Go?Несмотря на успех в своей нише, в целом тут все так грустно и очевидно, что без лишних слов перейдем дальше к Rust.Rust?Начать следует с того что у Rust порог входа выше чем у C++, уже потому что на C++ сразу можно писать как на любом другом высокоуровневом ЯП, предоставив стандартной библиотеке разруливать работу с памятью. Rust же не даст спрятаться от решения вопросов безопасности и размещения в памяти и из-за этой необходимости, он (внезапно!) превращается в достаточно низкоуровневый язык, сравнимый скорее даже с Си, чем с C++.ВыводМы по возможности непредвзято рассмотрели объективные факторы способствующие индустриальной разработке. Вывод из них все же неизбежно будет субъективен. Поэтому привествуются альтернативные выводы! Итак, по моему мнению, на текущий момент, для написания большинства кроссплатформенных приложений удобнее всего использовать Kotlin, дополняя его C++ в тех случаях когда требуется скорость. Kotlin прекрасно подходит для бекендов, язык экосистемы Android по умолчанию, без проблем компилируется в JS и WebAssembly для браузеров, с небольшими приседаниями может быть использован для iOS, а с помощью jpackage легко подготовить самодостаточный исполняемый файл для Windows, macOS, Linux в "родном" формате. =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_java, #_sovershennyj_kod ( Совершенный код ), #_c#, #_kotlin |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:38
Часовой пояс: UTC + 5