Выбор языка/платформы для full-stack веб-приложения

С таким ником очевидно Golang.

Как альтернатива: Erlang.

С таким ником — только Go.

korvin_ опередил…

Есть вариант Scala с Akka + Play Framework. Это просто как альтернатива, сам не использовал.

Clojure и Clojurescript

Кложура. Го не порадовал, нода вариант только если хочешь посетить лечебницу, но не знаешь как туда попасть.

Limbo

theNamelessOne

Есть вариант Scala с Akka + Play Framework

Спасибо, отметил Akka.

zz

Го не порадовал

В каком плане?

На данный момент обозначено два варианта: Node.js, Golang.
Требования: конкурентность, надёжность, производительность, масштабируемость, лёгкость в поддержке

Golang это само воплощение конкуретности, надежности, масштабируемости и легкости поддержки.

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

Единственное преимущество node.js над golang - больше стороннего кода сейчас на нем, с другой стороны сомневаюсь, что в вашем случае в нем будет какая-то серьезная необходимость (много помойных и бесполезных библиотек).

У ноды, имхо, есть только одно достоинство: если знаешь js то можешь «фронтэнд» и «бэкенд» писать на одном ЯП. Это к вопросу о целостности.

Лично я так и не понял в чём фишка ноды. Мне оно кажется жутким костылём и подход «сделаем всё на колл-бэках» приветом из девяностых. Голосую за go.

Требования: конкурентность, надёжность, производительность, масштабируемость, лёгкость в поддержке;

Node.js, Golang

WTF?

Потому что возможные ответы: Erlang, C#

Хацкель, очевидно. Snap/Yesod

На данный момент обозначено два варианта: Node.js, Golang.

Выбор по критерию хипсторности? Тогда Go.

Go. Go. Go!

Бросьте сомневаться, если вопрос в этом, и берите Go. Одного его рантайма для вас будет достаточно практически наверняка — а это в свою очередь целостность, и навряд ли сейчас есть и в скором времени появится что-то благоразумнее по отношению к вашим требованиям. Ну а там, конечно, смотрите сами, думайте. Голосую за Go, да и под сервер-сайд его загоняют конкретно, всё-таки гугл как ни странно в этом плане на передовой. В общем, удачи.

Ну с натяжкой Erlang ещё ладно, но C# (да, mono, и чё?). Да и что Erlang, у него всё же ниша. Не думаю, что это был бы хороший выбор для full-stack.

Выбор по критерию хипсторности?

Вы так говорите, как будто это что-то плохое. Хипстерность приходит и уходит. Хороший, основательный язычок остается.

Вы так говорите, как будто это что-то плохое. Хипстерность приходит и уходит. Хороший, основательный язычок остается.

Вы точно о поделках гугла говорите? Сколько там он всего поматросил и бросил?

Выбор по критерию хипсторности?

Вы так говорите, как будто это что-то плохое.

Да, это плохое.

Хороший, основательный язычок остается.

Те, кто выбирает «хороший, основательный язычок», даже не рассматривают Javascript.

но C#

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

Те, кто выбирает «хороший, основательный язычок», даже не рассматривают Javascript.

Ну, может быть. Но я о Go.

Вы точно о поделках гугла говорите? Сколько там он всего поматросил и бросил?

Какие языки программирования гугл «поматросил и бросил»?

Да, это плохое.

Хипсторность или Go?
И, кстати, почему такая категоричность — Go, говорите для каких-то хипстеров, — глядя на его публичную аудиторию складывается обратное впечатление, совсем.

sharepoint for linux?

Какие языки программирования гугл «поматросил и бросил»?

С++, Python активно меняет на Go же. Было бы странно, если наоборот.

С++, Python, Java активно меняет на Go же. Было бы странно, если наоборот.

fixed

Есть опыт использования? Поделишьcя?

Да, это плохое.

Хипсторность или Go?

Я процитировал то, на что отвечал. Впрочем, язык Go тоже так себе - язык без параметризуемых типов, а ведь XXI век на дворе.

Go, говорите для каких-то хипстеров,

Я не говорил этого. А то, что хипсторы в последнее время любят Go, вполне очевидно.

Нет.Да. ответ был в контексте Роба Пайка

Я процитировал то, на что отвечал. Впрочем, язык Go тоже так себе - язык без параметризуемых типов, а ведь XXI век на дворе.

Во первых, не «параметризуемые», а «параметрические». И появились они не в 21 веке, а раньше. А, во вторых, изучи сначала интерфейсы в Го и не говори ерунды о «несовременности».

С го дела не имел.

Нода не катит вот по этой причине:

конкурентность, надёжность, производительность, масштабируемость, лёгкость в поддержке;

Три чая этому господину. Один с солью — за грамоту и ненужную запятую.

По теме — бери go или java, go в контексте задачи интереснее и, наверное, выигрышнее (в лёгкости сопровождения уж точно).

И появились они не в 21 веке, а раньше

Я не говорил, что они появились в 21-м веке.

изучи сначала интерфейсы в Го

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

Если в языке нет какой-либо фичи, потрудись сначала понять причину этого. В maillist Go полно объяснений на этот счет. А обобщенное программирование в 1970 появилось или раньше. Причем тут 21 век ?

В догонку : Шаблоны или генерики вводят в основном для поддержки обобщенного программирования, а оно в Го на интерфейсах базируется.

Ну не будешь же ты просить добавить параметризуемые типы в Питон или Objective-C. Там утиная типизация имеется. В Го та же фигня, только в профиль.

Scala + Play (при желании, добавить Akka) или Scala + Akka + Spray.

ой, а шарпике и акторы есть, не такие классные как akka, но есть же, будем посмотреть.

А как в Go без дженериков коллекции делают?

Если коротко, то в Го есть такое понятие как пустой интерфейс (interface {}) к которому можно преобразовать любой тип без потери информации о нем. Но есть и понятие специализированного интерфейса со строгой проверкой типов. Получается гибрид статической и динамической типизации.

http://golang.org/doc/effective_go.html#methods

Интерфейсы + встроенные в язык полиморфные хэш-таблицы.

Легко.

В maillist Go полно объяснений на этот счет.

Всего одно: не решили как правильней это сделать.

Причем тут 21 век?

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

И это всё при том, что встроенные типы [], map и chan вполне себе параметризуемы.

Шаблоны или генерики вводят в основном для поддержки обобщенного программирования, а оно в Го на интерфейсах базируется

Что не всегда удобно.

Ну не будешь же ты просить добавить параметризуемые типы в Питон или Objective-C. Там утиная типизация имеется. В Го та же фигня, только в профиль.

В пистоне динамическая типизация, в отличие от. А кроме Objective-C есть еще Objective-C++ например.

Всего одно: не решили как правильней это сделать.

Всего 2 :

1. Есть интерфейсы, которые решают те же задачи и необходимость ввода еще одной сущности в язык под вопросом. 2. http://golang.org/doc/faq#generics

В пистоне динамическая типизация, в отличие от. А кроме Objective-C есть еще Objective-C++ например.

В Go используются идеи динамической типизации «by design». Не даром в разработке языка принимал участие Robert Griesemer, - специалист по динамическим языкам. И я ничего не говорил о Objective-C++, С++ это совсем другой язык.

На данный момент обозначено два варианта: Node.js, Golang.

Да. Не фортануло. А ведь шли к успеху.

Есть интерфейсы, которые решают те же задачи и необходимость

«many cases» ≠ «all cases»

В Go используются идеи динамической типизации «by design».

Как будто кто-то мешает использовать рефлексию в Delphi, C# и Java например, тем не менее, предпочитаю дженерики. Тупо удобней. А в некоторых случаях и без «a cost in ... run-time».

И я ничего не говорил о Objective-C++, С++ это совсем другой язык.

Угу, а O-C++ появился от исключительного удобства O-C, да?

Как будто кто-то мешает использовать рефлексию в Delphi, C# и Java например, тем не менее, предпочитаю дженерики. Тупо удобней. А в некоторых случаях и без «a cost in ... run-time».

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

Угу, а O-C++ появился от исключительного удобства O-C, да?

O-C++ появился для привлечения C++ разработчиков. Некогда популярность O-C была довольно низкая, но это время прошло.

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

И всё же лучше выпустить без полиморфизма, чем со сделанным абы как.

Интерфейсы в Го сильно отличаются по своей сути от того что используется в других языках.

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

И аналогия с рефлексией в других языках не катит.

Отчего же? Что с помощью интерфейсов Go можно сделать такого, что нельзя или очень затруднительно — с помощью «обычных» интерфейсов в вышеупомянутых языках?

И всё же лучше выпустить без полиморфизма, чем со сделанным абы как.

А потом переделывать стандартную и кучу других библиотек, как это сделали в джаве, если таки добавят?

в Golang их подход с автоприменением к типу подходящих интерфейсов очень похож на хаскел , а если точнее на математику

где если интерфейс(набор аксиом) применим то и теоремы(методы интерфейса) .

то , что ненужно программисту самостоятельно указывать что тип Т реализует интерфейс И - это реально очень мощное решение.