golang

[metaclass]

Вы тащемта, как хотите, но golang - это современный Delphi, настолько же простой и пригодный для промышленной разработки.
Надеюсь, гугл не проебет все полимеры, как борланд, а всякие олдфаги со своими C, C++ и жабой будут задвинуты на задворки истории и всех нас нахрен уволят на мороз за то что overqualified и заменят выпускниками БГУИР, которые будут клепать на go микросервисы в докерах.

Comments

[metaclass.livejournal.com]

UI пишут на жабаскрипте фронтендщики, туда унылых бек-ендщиков с грязными руками и отсутствием понятия об UX не пускают.

[jakobz.livejournal.com]

Так при нормальном фронте, от бекенда вообще только спинной мозг требуется - достал с базы, сохранил в базу. Я вот жду кто уже сделает нормальную универсальную прослойку - чтобы я прям с фронта ходил за чем мне надо, через тоненький слой про security. Какой-нибудь там graphql-клиент, или вообще вон какой-нибудь там datomic прозрачно в клиента засасывать.

[kurilka.livejournal.com]

RethinkDB на вас нет

[henu3detb.livejournal.com]

Его действительно уже нет.

[kurilka.livejournal.com]

аминь

[volodymir-k.livejournal.com]

уже сделали, попробовали и отказались
https://msdn.microsoft.com/en-us/library/ms188266%28v=sql.105%29.aspx
http://docs.oracle.com/cd/B28359_01/appdev.111/b28369/xdb_web_services.htm
https://wiki.postgresql.org/wiki/HTTP_API

[buddy-ekb.livejournal.com]

Ах, если бы, ах, если бы...
Есть такие прослойки, даже с security, да хоть тот же Firebase.

Но, предположим, что обычным скучным людям всё-таки чаще хочется привычного SQL в JSON-REST-обёртке. И вот там сразу несколько проблемок вылазит. Они вроде небольшие, решаемые, но оставляют ощущение какой-то бессмысленной суеты.

Первая проблема - это отображение сущностей базы данных в JSON-сущности. И если для общих случаев небольших CRUD вполне можно сделать типовые сервисы, то любой шаг влево-шаг вправо приводит к написанию уникальных отображений. А это либо набор хранимок, либо набор метаданных, которые сопровождаются одинаково хреново.

Вторая проблема - ORM на клиенте. Их есть, но чаще всего это вещи для какого-то внутреннего сиюминутного потребления под частный случай. И, конечно, они по определению будут составной частью выбранного фреймворка под "нормальный фронт".

Третья проблема - безопасность в целом. Она и в традиционной-то связке СУБД с бэкендом довольно узкое место, а здесь так вообще приходится о ней постоянно думать в каждом сервисе. Ну или сразу почтить минутой молчания.

И это только с данными.

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

Но что делать, если захочется чуть-чуть большего? Отправить письмо? Послать SMS? Сделать из картинки thumbnail? А пачкой? Запросить внешний сервис с дополнительной авторизацией? А на регулярной основе?
Добро пожаловать в реальный мир с очередями сообщений и прочим серверным геморроем.

[fortness90 (from livejournal.com)]

Турусонаколесостроению быть !
PS Все-таки заменять С , таща жиирный браузер это конгениально !

[thedeemon.livejournal.com]

Visual Studio Code так устроен. Даже MS делает это. Зачем-то.

[worm-ii.livejournal.com]

Ну, тогда это не Delphi Way.