товарищи, а как научить vscode понимать, где vendor папка лежит?

чем он лучше echo?

тоже интересно. по мне так джин и эхо хорошие

тоже интересно. по мне так джин и эхо хорошие

ну вот парни говорят что chi полностью соответсвует net/http если я правильно понял, а gin и echo нет

верно

Все ж разные юзкейсы

а какие юзкейсы предпочтитльнее делать на ноде, чем на Гоу?

когда надо сделать что-то за вечер, а не за неделю ))

почему с нодом то сравниваете - думаю го всетаки замена плюсам

Лол

Сравнивать язык с гц и без гц

лол это сравнивать го с js.

Всё это неадекватно.

лол это сравнивать го с js.

Да норм

Есть фигурные скобки? Да

асм лучше

Вот и все

когда надо сделать что-то за вечер, а не за неделю ))

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

но блевать тянет у многих, и тут тревожный звоночек!

вот именно

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

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

но блевать тянет у многих, и тут тревожный звоночек!

если многие думают одинаково, то кто-то не думает:)

Можно функционально поговнякать на js)

Единственный распространенный функциональный язык.

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

js прост, сделал генерацию приложения с expressjs, подрубил sequelize и за вечер наговнякал апи

@XaveScor секси - в смысле ебёт жостко? это да.

@XaveScor секси - в смысле ебёт жостко? это да.

Нет, приятно пользоваться, особенно после всех процедурных и ооп языков.

В нём, конечно, дохренища минусов. Но для фронта отлично заходит.

js прост, сделал генерацию приложения с expressjs, подрубил sequelize и за вечер наговнякал апи

да в роде как в Гоу примерно так же всё выглядит - взял echo, подрубил gorm -> в продакшен -> профит

ну для фронта ничего больше зайти и не может

ну для фронта ничего больше зайти и не может

Даже в теории.

а питончик тот же?(

а питончик тот же?(

Для фронта? Ну хз. Для меня просто js с появлением реакта открылся по-новому.

Для фронта? Ну хз. Для меня просто js с появлением реакта открылся по-новому.

ну ты ж про теорию уже сказал. ну да ладно)

ну ты ж про теорию уже сказал. ну да ладно)

Я просто представить его не могу.

а питончик тот же?(

никому не говори, что ты питонист

а я не могу представить фронт без JS'а ) что там, CoffeeScript? один хрен потом транслировать в JS придется же

кофе сделали наисилившие рубисты

я не знаю, почему с ES6 на нём еще пишут

а я не могу представить фронт без JS'а ) что там, CoffeeScript? один хрен потом транслировать в JS придется же

Посмотри на реакт. Это офигтельная вещь. И он поверх кучи языков ложится.

(я писал на кофе, пару месяцев каждый день, было круто, а потом надоело)

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

сколько эльм проектов есть в реальности?

Посмотри на реакт. Это офигтельная вещь. И он поверх кучи языков ложится.

я смотрел :( страдал чуть более, чем всегда jquery остается самым пиздатым из всего, что я видел, но признаваться в этом еще хуже, чем признаваться в том, что я питонист я еще когда-нибудь vue потыкаю, когда будет желание-возможность, но они будут неизвестно когда, а к тому времени все забудут и про ангуляр, и про реакт, и про вью %)

лучше не лучше, не хочется быть программистом на kphp

я смотрел :( страдал чуть более, чем всегда jquery остается самым пиздатым из всего, что я видел, но признаваться в этом еще хуже, чем признаваться в том, что я питонист я еще когда-нибудь vue потыкаю, когда будет желание-возможность, но они будут неизвестно когда, а к тому времени все забудут и про ангуляр, и про реакт, и про вью %)

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

https://pp.userapi.com/c638616/v638616006/cf3d/EUP4UZZLZFs.jpg

https://pp.userapi.com/c638616/v638616006/cf3d/EUP4UZZLZFs.jpg

шутки про типизацию в жсе никогда не потеряют актуальность))

Вот реально пописав немного на фронте я понял, что имутабельность - это круто.

я смотрел :( страдал чуть более, чем всегда jquery остается самым пиздатым из всего, что я видел, но признаваться в этом еще хуже, чем признаваться в том, что я питонист я еще когда-нибудь vue потыкаю, когда будет желание-возможность, но они будут неизвестно когда, а к тому времени все забудут и про ангуляр, и про реакт, и про вью %)

кстати да, raw js + jquery более гуманно выглядит

Вот реально пописав немного на фронте я понял, что имутабельность - это круто.

ну вот в elm настоящая иммутабельность, попробуй))

ну вот в elm настоящая иммутабельность, попробуй))

Не) Спасибо)

а какие юзкейсы предпочтитльнее делать на ноде, чем на Гоу?

Когда производительность не важна. На ноде разработка быстрее и проще.

Когда не нужен паралеллизм

В общем в случаях когда делаем что-то сравнительно простое и не особо нагруженное

ну вот в elm настоящая иммутабельность, попробуй))

лучше purescript тогда

лучше purescript тогда

сущетсвенная разница с elm там только для ментальных онанистов и дрочеров на трихомонады) elm значительно проще и практичнее чем ps. например встроена редакс-архитектура и бесшовная поддержка webgl

мне elm не нравится тем что в нем реакта нет)

и предлагаются свои подходы

тобишь если purescript это надстройка над языком

то elm это фреймворк по сути

мне elm не нравится тем что в нем реакта нет)

ты что! там офигенно красивый и удобный vdom, на много лучше чем в богомерзком jsx. "фреймворк по сути" - ну да. и хорошо, меньше в js - меньше говнокода и граблей. Свои подходы - фишка в том. что ни кто не придумал подхода для фронта с vdom лучше чем редакс. Остальный подходы на практике ущербны. Ну и elm умеет в реакт если что

ты что! там офигенно красивый и удобный vdom, на много лучше чем в богомерзком jsx. "фреймворк по сути" - ну да. и хорошо, меньше в js - меньше говнокода и граблей. Свои подходы - фишка в том. что ни кто не придумал подхода для фронта с vdom лучше чем редакс. Остальный подходы на практике ущербны. Ну и elm умеет в реакт если что

я б все же предпочел если бы у них отдельно язык шел и отдельно все остальное

тобишь вот был бы elm как язык + к нему библиотеки.

Это точно чатик про го?:)

ок, у меня всё про эльм)

Я думал тут за джаву трут

ERROR: S client not available

В общем в случаях когда делаем что-то сравнительно простое и не особо нагруженное

имхо тут всё равно Гоу лучше ноды даже для очень простых проектов лоу-лоад, поскольку: - статическая типизация. Меньше хаоса, проще рефакторинг, не надо писать, тесты проверяющие типы - более качественные либы, - проще деплой. сборка программы в один самодостаточный бинарник без каких-либо внешних зависимостей рулит - не надо на каждый чих надо прикручивать интеграцию со сторонними инструментами на подобие redis или memcached

имхо тут всё равно Гоу лучше ноды даже для очень простых проектов лоу-лоад, поскольку: - статическая типизация. Меньше хаоса, проще рефакторинг, не надо писать, тесты проверяющие типы - более качественные либы, - проще деплой. сборка программы в один самодостаточный бинарник без каких-либо внешних зависимостей рулит - не надо на каждый чих надо прикручивать интеграцию со сторонними инструментами на подобие redis или memcached

А что вместо редис? Ембеддед что-то? Или мап писать хитрый?)

Решил тут поковырять примеры из книжки Кернигана Есть такой код, для него нужно написать автотест: https://play.golang.org/p/-KbUYn-WbG Собственно тут два варианта: - вынети основной код в функцию, которая принимает *io.Reader, и передать ей mock-объект, имплементирующий этот интерфейс - вынести в отдельную функцию только тот код, который подсчитывает кол-во рун, и тестировать только его Как правильнее поступить в данной ситуации?

имхо тут всё равно Гоу лучше ноды даже для очень простых проектов лоу-лоад, поскольку: - статическая типизация. Меньше хаоса, проще рефакторинг, не надо писать, тесты проверяющие типы - более качественные либы, - проще деплой. сборка программы в один самодостаточный бинарник без каких-либо внешних зависимостей рулит - не надо на каждый чих надо прикручивать интеграцию со сторонними инструментами на подобие redis или memcached

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

тем более когда на ранних этапах модель данных может менятся постоянно

я вполне допускаю конечно что я просто предвзят тут из-за того что с го у меня опыта всего ничего, а с нодой - годы.

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

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

модель и создают на этапе построения архитектуры.

а потом ее меняют

а потом еще раз и еще раз и еще раз

А как с помощью интерфейсов получить из БД произвольный набор данных записанный куда то?

имхо тут всё равно Гоу лучше ноды даже для очень простых проектов лоу-лоад, поскольку: - статическая типизация. Меньше хаоса, проще рефакторинг, не надо писать, тесты проверяющие типы - более качественные либы, - проще деплой. сборка программы в один самодостаточный бинарник без каких-либо внешних зависимостей рулит - не надо на каждый чих надо прикручивать интеграцию со сторонними инструментами на подобие redis или memcached

эти факторы значимы только в проектах поддержки . если нужно быстро налабать mvp в жертву скорости разработки приносится все. потом саппорт перепишет на го :)

А как с помощью интерфейсов получить из БД произвольный набор данных записанный куда то?

ну тогда map использовать

в БД то точный набор данных, я имею ввиду реляционные БД

структура таблиц ведь заранее известна

@scukonick а чего хитрый? обычный thread safe мап. по моему в разы проще чем прикручивать reddis

ну тогда map использовать

map же хранит данные одного типа

или я путаю что-то?

вроде бы при инициализации я задаю тип ключа и тип данных

myData := make(map[string]interface{}) for i := 0; i < len(row); i++ { myData[columns[i].Name] = row[i] } obj = append(obj, myData)

вот ример из мною использованного универсального сервиса, ему пофиг что за набор данных в БД

это будет работать далеко не всегда к сожалению

var obj []map[string]interface{}

например массивы из postgre возвращаются в качестве []uint8 строки

и ее нужно либо преобразовывать, либо записывать в специальный тип данных, который преобразует за тебя

@scukonick а чего хитрый? обычный thread safe мап. по моему в разы проще чем прикручивать reddis

Ну если ТТЛ надо, то уже всё сразу становится интереснее

Если ZRANGE всякие, то вообще хз?

а какая реализация существует в ноде?

а какая реализация существует в ноде?

ты просто получаешь JS обьект на выходе и все. ничего вообще делать не нужно

не знаю спорить что лучше что хуже не в моей компетентности, но перед нодой в го есть 1 сущестнвенное преимущество, это потоки

Решил тут поковырять примеры из книжки Кернигана Есть такой код, для него нужно написать автотест: https://play.golang.org/p/-KbUYn-WbG Собственно тут два варианта: - вынети основной код в функцию, которая принимает *io.Reader, и передать ей mock-объект, имплементирующий этот интерфейс - вынести в отдельную функцию только тот код, который подсчитывает кол-во рун, и тестировать только его Как правильнее поступить в данной ситуации?

А по моему вопросу кто-нибудь может подсказать? Как лучше тест написать?