LINUX.ORG.RU

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

 , ,


0

1

Специфика: социальная сеть, биллинг;

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

Не требуется и вопрос не стоит: фреймворк, хостинг;

Со временем на проект и в выборе технологии, - цитирую, - «определяйтесь сами»; т.е. проблемы нет;

На данный момент обозначено два варианта: Node.js, Golang.
(и оба (точнее один из них), если что, придётся осваивать в процессе)

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

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

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

Вообще в Go есть проблемы с зависимостями: сложно сказать, что тебе нужна библиотека конкретной версии. В ноде с npm лучше (не то, чтобы я был за ноду).

И вообще, я не удивлюсь, если компилятор выдаст «Войдите в Google+, чтобы включить оптимизацию [Подробнее] [Зарегистрироваться].»

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

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

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

Не так уж и похож: в Хаскелле тайпкласс можно реализовать для любого типа в любом модуле, в Go — только в том же пакете, что и сам тип. Соответственно, если автор типа не реализовал какой-то нужный тебе метод, тебе придется создавать новый тип и кастовать/оборачивать его тип. Для единичного значения это еще не так напряжно, но для коллекций (слайсов, мапов и т.д.) уже нужно будет обходить всю коллекцию и создавать новую.

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

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

А что в стандартной библиотеке, помимо containers, нужно будет переделывать? Или с вашим параметрическим полиморфизмом код, который его не использует, работать не будет? Тогда спасибо, не надо.

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

Вообще в Go есть проблемы с зависимостями: сложно сказать, что тебе нужна библиотека конкретной версии.

Там нет проблемы с зависимостями - они вообще не поддерживаются.

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

go get. Например, go get github.com/what/ever. Но с версиями беда.

Можно заюзать что-нибудь вроде https://github.com/mattn/gom, но стандартов нет.

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

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

Явная декларация может потребовать объявления десятков интерфейсов с идентичными методами. Механизм принятый в Го позволяет нескольким интерфейсам использовать общие для них методы и писать их ровно один раз. Тип неявно может быть преобразован к интерфейсу, например, при вызове функции. При условии, что тип поддерживает заданный интерфейс. Кроме того интерфейсы кроме методов могут включать в себя другие интерфейсы. В других языках надо тип приводить к интерфейсу явно, вызывая соответствующий конструктор или нечто подобное.

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

Упрощается процесс разработки программ, особенно для «programming in large».

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.