golang

[metaclass]

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

Comments

[vit-r.livejournal.com]

Да полноте.

var i, j int = 1, 2

Все предпосылки для бангалорских кудесников в наличии. Жаба и С++ тоже были сначала "простыми и пригодными"

[jamhed.livejournal.com]

Когда это c++ то был простой и пригодный?

[psilogic.livejournal.com]

кстати, да :)

когда сделали C++, то кое в чем упростили жизнь, но при этом вхреначили хтонический ужас под названием STL

[vit-r.livejournal.com]

Когда появился С++ и когда STL?

[psilogic.livejournal.com]

ну вот именно... что засрали язык

и еще засрут - глядя на C++11

[vit-r.livejournal.com]

Так никто не обязывает использовать всякую срань.

[psilogic.livejournal.com]

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

так что приходится использовать, плакать и колоться :)

[http://users.livejournal.com/_slw/]

что хорошего в автоматизированном копи-пастинге?

[nealar.livejournal.com]

Меньшее число ошибок, по сравнению с ручной копипастой.

[psilogic.livejournal.com]

автоматизированность! :)

[vit-r.livejournal.com]

Дописывал ли благородный дон руками результаты работы cfront?

С++ и сейчас хорош в правильном профиле, если обрезать всякие ложноножки и за применение всякой дряни больно бить канделябром.

[enternet.livejournal.com]

В студенчестве судя по быстроте нанёмписания, он явно был простой и годный.

[plumqqz.livejournal.com]

PLI жил, PLI жив, PLI будет жить!
Исключения они там сделают или так и будет, по старинному рецепту?

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

[aamonster.livejournal.com]

А что, есть простой годный RAD с толковыми библиотеками компонент и возможностью малой кровью делать свои компоненты (так, чтобы прямой путь их создания был очевиден - так, чтобы два выпускника БГУИР слепили бы компонент одинаково)?

[fortness90 (from livejournal.com)]

А у Go c UI уже лучше , чем у Фортрана ??

[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.

[volodymir-k.livejournal.com]

для фортрана был только вин32 биндинг
у го их несколько

[fortness90 (from livejournal.com)]

http://www.winteracter.com/
http://www.gino-graphics.com/

[fortness90 (from livejournal.com)]

Врете , их минимум 3 , 2 - живые

[avnik.livejournal.com]

А я все надеюсь, что он наконец сдохнет.
Потому что dependency management методом "скопируем все к себе в Godeps/..." я уже видел году так в 95.
Возможность написать `import "github.com/khuy/pizda/jigurda" приводит к тому, что у тебя при сборке чего нибудь большого приезжает все написаное для го на гитхабе. И к дивным макаронам.

И да, генериков нет, и не будет. Довольствуйтесь копипастой.

[wildman.livejournal.com]

glide
gb
go vendoring начиная с 1.5

go generate

[avnik.livejournal.com]

И что -- это glide уже съело конкурентов? (godep пока вроде доминирует в умах пациентов)
Хотя за счет "Support aliasing packages (e.g. for working with github forks)" оно выглядит разумнее прочих. Если их научить генерить .nix из их файла с версиями -- наверное вообще будет праздник

[avnik.livejournal.com]

А вот go generate это не замена генерикам увы.
list of string и list of int им не сделаешь, только копипасту нагенерить можно

[d4s.livejournal.com]

Да полноте.
Недостаточно знать язык, чтобы заниматься промышленной разработкой без надзора.

Ребе, ну что вы как маленький:
cmd := exec.Command("rm", "-rf", path)
только так! только хардкор!

[metaclass.livejournal.com]

Всем пофиг давно, не модно же :)
Докеры, про безопасность думают девопсы, программисты херачат непойми что.
Я вчера вот на тему правильного обращения к системным путям виндовс с молодежью срался - не понимают, почему нахрен все захардкодить, вместо вызова апи - это плохо.

[rdia.livejournal.com]

Ну, а реально, какая разница? В Windows так ведь заведено, ну напишите вы в C:\Windows\system32, а бравые парни в MS сделают очередную прослойку виртуализации, которая это всё съест и правильно обработает.

Windows ведь и так капуста - ядро в слоях виртуализации и обработки чужих косяков.

И, главное, бравые парни из МС всё равно напишут очередной слой виртуализации, пиши с использованием функций API или жёстко забитых путей.

[http://users.livejournal.com/_valerka_/]

а еcли винда на другой диск переедет? или дано, вы попали в облако, и там вообще диска нет.

[rdia.livejournal.com]

Ну бравые парни из МС что-то придумают, чтобы и в таких случаях софт не сыпался. Или пользователю будет предложено непереезжать, тк. у него пол системы отвалится.

[besm6.livejournal.com]

Безотносительно к остальным комментариям: у гугла сейчас наблюдается как раз этап острого проеба полимеров. Так что, я думаю, проебет и этот.

[justy-tylor.livejournal.com]

Наброс ок. Но факта, что это очередная жаба, не отменяет.

[vp.livejournal.com]

"очередная жаба" - это в смысле массовой доступности и популярности? или в смысле архитектуры?

[justy-tylor.livejournal.com]

Архитектурно. Это практически старая жаба (до дженериков), только без печально-энтерпрайзного исторического багажа.

[vp.livejournal.com]

Охрененный вывод.

[nivanych.livejournal.com]

> микросервисы в докерах

Новый мем рождается? ;-)

[denis dmitriev (from livejournal.com)]

Вы были в коме последние пару лет? :)

[ynot.livejournal.com]

предпосылки для бангалорских кудесников
PLI жил, PLI жив, PLI будет жить!
А у Go c UI уже лучше , чем у Фортрана ??
Возможность написать `import "github.com/khuy/pizda/jigurda"

Чета ржу. Набросъ ок, ответы дважды ок.

[d4s.livejournal.com]

вы еще не видели, как это в rpm/dpkg собирается :(
только вот сегодня отправил программульку в дистр, так пришлось 20 пакетов собрать :(

[alex bubnoff (from livejournal.com)]

Цитирую предыдущий же пост:

>> Как без метапрограммирования нормально делать опердени, где 99% кода - это бойлерплейт
>> по перекладыванию между полями разных объектов и БД - хрен его знает.

По этому критерию Go для написания оперденей предельно непригоден, а какая без них "промышленная разработка" я даже и не знаю. Как к ней относятся "микросервисы в докерах" я не понимаю тем более.

[slonopotamus.livejournal.com]

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

Ковыряли тут кишки gitlab'а (на ruby). Это ад пиздеца какой-то. Единороги, воркеры, мессадж-басы, хуй знает что еще. И ради чего? Вебсайтика, который не способен показать diff на 10kloc, видите ли слишком много.

[metaclass.livejournal.com]

Зоопарк заебывает, да.
mq смысл на самом деле имеет, некоторые задачи к нему хорошо сводятся.
Но люди вместо того чтобы сделать что-нибудь одно, тащат все что попадется из опенсорсных либ, даже если всю их функциональность можно было у себя в 10 строчек реализовать.