LINUX.ORG.RU

Если не Go, то что?

 , , , ,


1

7

Что там имеется в той же нише несложных, компилируемых ЯП с явной стат. типизацией и умеренным потреблением памяти, ставших более-менее мейнстримовыми?

Ответ на: комментарий от Deleted

Давно надоел, но теперь когда он по умолчанию отправляет статистику использования приватных модулей в Гугл, думаю, нужно подыскать что-то ещё. Тем более, что возможности трудоустройства (по крайней мере, в наших местах) с ним весьма ограничены.

ComradeMajor ()

несложных, компилируемых ЯП с явной стат. типизацией и умеренным потреблением памяти

Red/System, только с мейнстримовостью проблема, пока они до релиза не дошли.

Обычный Red, кстати, тоже компилируемый, но там указание типов опционально.

rebforce ()
Ответ на: комментарий от Difrex

За сишечку у нас не платят. Да и я - дурачок, смогу ли памятью рулить? Думал между Swift и C# (самый высокооплачиваемый). Ну или уже тогда выкинуть все эти требования и обмазаться Python / TypeScript.

ComradeMajor ()

несложных

Haskell

компилируемых

Python

ЯП

Bash

с явной стат. типизацией

Javascript

умеренным потреблением памяти

Java

ставших более-менее мейнстримовыми

Nim

PolarFox ★★★★★ ()

Kotlin Native но пока очень мало библиотек
Java потерпи пока GraalVM yлyчшат в плане потребления памяти
D, Dart если слегка снизишь планкy мейнстримовости

Deleted ()

Что там имеется в той же нише несложных, компилируемых ЯП с явной стат. типизацией и умеренным потреблением памяти, ставших более-менее мейнстримовыми?

Pascal.

Alve ★★★★★ ()

Если не Go, то что?

Чтобы что?

ставших более-менее мейнстримовыми?

Сишечка же.

Когда язык (Go в данном случае) все переварят и высрут, чтобы можно было убедиться, что его можно есть, - будет уже немного поздно, потому что появятся новые требования к разработке, новые языки и будут возникать те же самые вопросы уже по ним.

beaver ()
Ответ на: комментарий от feofan

Вопросов больше не имею.

Вообще-то это я должен был написать после твоего ответа.

Л-логика.

Вопрос: Мальчик как тебя зовут?
Ответ: Вопросов больше не имею. pokerface.jpg

MaxPower ★★ ()
Ответ на: комментарий от anonymous

OCaml

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

Потом дочитал что он однопоточный с Global Lock.

???

!!!

ЧТО. ЗА. ДЕРЬМО?

В принципе он был важен в свое время, но современные языки уже абсорбировали у него лучшее, пора на пенсию

P.S. Я знаю про костыль сбоку с названием Multicore OCaml

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от th3m3

Слышал мнение, что руст зашкаливающе сложен и создает слишком высокую нагрузку в процессе программирования. Программу длиннее хелло-ворлда на нем могут написать считанные единицы. Если саму программу на нем написать очень сложно, тогда для rust остаются отдельные высокоскоростные участки, встраиваемые в другие языки (Python, Java). Так мы воспользуемся одним процентом возможностей языка. Но зачем тогда весь этот монстр, если такие «вставки» можно было написать на C.

anonymous ()
Ответ на: комментарий от Deleted

Kotlin Native

В чего ценность вообще? Он я так понял без JVM, а значит без WORA. Стандартной библиотекой Java, я так понял, воспользоваться тоже не сможет, так же как и сторонними библиотеками Java. И что там остается? Возможность генерировать нативной код? Ну этим никого не удивишь.

anonymous ()
Ответ на: комментарий от anonymous

Не, там просто Rust тычет в лицо всеми 1) небезопасными кусками 2) неэффективными кусками.

Первые не скомпилируются. Значит нужно исправить. В С++ ты просто забиваешь и ждешь пока поверх твоего работающего с горем пополам кода вкоммитят еще пару безобидных строчек другие люди, и вот тогда это взорвется.

Второе просто создает психологический дискофорт. Move-semantics by default, каждую копию нужно делать явно. И тут нуб начинает оптимизировать обмазываясь ссылками и лайфтаймами в погоне за абстрактным «быстрее». В итоге забивает и возвращается на свой Python, стократно более неэффективный, но зато не бросающий это тебе в глаза. Если пересилить себя и использовать копии, Arc, Rc, то программировать приходится просто. Если что, врубаешь профайлер и оптимизируеть только что надо и когда надо. Но на 99% до этого не дойдет, потому что даже з этими прибамбасами оно работает очень быстро, твои допущения что нет были не верны

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от anonymous

Haskell - по своему, для исследований ФП. Rust - только эффективные части. Elm, Scala - тоже только то что имело смысл

https://en.wikipedia.org/wiki/OCaml

Influenced: ATS, Coq, Elm, F#, F*, Haxe, Opa, Reason, Rust, Scala

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от anonymous

В контексте сравнения с Go в его нише, Kotlin лyчше сам по себе как язык. У Go тоже не гиганская библиотека.
Но это пока вариант на перспективy.

Deleted ()
Ответ на: комментарий от Deleted

В контексте сравнения с Go в его нише, Kotlin лyчше сам по себе как язык.

Котлин очередная помойка вроде си-шарпа. Бездумно натащить фич ещё не значит создать хороший язык.

hbee ★★★ ()
Ответ на: комментарий от MaxPower

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

Ну и лично мне кажется, что у человека, который выбирает

сферу -> фреймворк -> язык.

неинтересные задачи. Но это сугубо мое мнение, никому его не навязываю.

feofan ★★★★★ ()