Golang: Developer Experience, который превосходит Node.js

– Встроенная библиотека тестов ну просто РАБОТАЕТ, прям из коробки
– Есть встроенная библиотека бенчамарков
– Встроенный линтер и форматер (притиер)
– Библиотеки импортируются по URL например напрямую из github не то, что у некоторых (да да это я про тебя npm, псина)
– Хочешь узнать что делает функция библиотеки? Тыкнул на нее и вместо перехода в .d.ts с типами, ты сразу попадаешь на импелментацию (конкретный код) библиотеки и можеешь его изучить
– Написал название пакет.функция, а Го автоматически сам сделал импорт
– Встроенный парсер go кода с удобной работой с AST деревом + встроенный шаблонизатор позволяют любому человеку написать свой собственный кодогенерот
– switch case с предикатами на уровне case
– Хочешь какую-то библиотеку, скорее всего, та которую ты найдешь будет реально хорошо работать
– Никакой ебли с типизацией: никаких npm i -D @types/..., типизация настолько тупая, что никакой магии нельзя написать, каждый может прочитать и понять этот код

И много много маленьких фич, которые превращают написание кода в танец пальцев

Текст полностью не передает приятности всех этих вещей, это надо попробовать и тогда становится даже противно писать на Node.js (к TypeScript меньше вопросов, но пока он не обзаведется своей виртуальной машиной и отдельной инфрой он тоже соучастник)

Это ты ещё с PHP не сравнивал

Кстати вчера гениальную мысль про php выдал:
> Imaging you code on Java but with a lot of $$$$$ but you still have no money. I think people become angry and start to hate php.

Существование PHP – причина почему JS не самый худший язык в мире

НО в защиту PHP: это язык, разработавший serverless задолго до его появления (могу даже как-нибудь статейку на эту тему написать)

Ну в плане экосистемы js смачно сосёт перед php

И да, Symfony и Laravel – в категории фреймворков одни из лучших на рынке (среди всех языков)

На node.js всякие Nest.js выглядят как шутка

Я бы сказал, что Laravel дает за щеку RoR и Django, а Symfony добивает в углу ASP.net

Единственный органичительный фактор – это сам синтаксис и некоторые архитектурные решения PHP, почему он еще первым двум может что-то противопоставить, а вот ASP.net, Spring, etc. уже просто по факту более продвинутых языков выигрывают в определенных категориях

Но это все ИМХО, потому что подлежит дебатам

В частности, если человек уже Senior в каком-то язык, я не могу ему посоветовать идти в PHP / Java / C# / Python / Ruby, если он только не хочет в конкретную компанию, где пишут на них

Это все языки первой линии обороны

жду краткое впечатление про cargo(rust)

Я уже открыл rustlings ))

Если работаешь с небольшими более-менее стандантными проектами: апи, аутентификация, какая-нибудь обработка документов, может пара запросов к внешним апи - есть смысл рассмаривать Го в альтернативу Лараваель или Нест? Кажется что это увеличит скорость и простоту разработки (без учета убоств с линтерами, преттиерами и т.д.) - я прав, или это миф? Кто-то вообще это делает на Го на постоянной основе?

В этом фишка го: в отличии от всех на его кате и ниже, когда ты пишешь что-то простое он НЕ будет тебе мешать (даже не придётся писать горутины)

Единственное что придётся делать: писать тесты (причём лучше интеграционные), потому что го абсолютно не null-safety

Но это часто больше преимущество и писать на нем тесты одно удовольствие (скоро выложу бойлерплейт со всем что нужно по Го)

При этом любая библиотека будет суперкачественная - я очень заебался от проблем в Ноде стиле «axios / express / typeorm / knex - самые популярные библиотеки, но только с кучей багов и ломаются через раз по абсолютно неизвестной причине»

В Го такого просто нет

Простые API можно ПОЛНОСТЬЮ написать на стандартной библиотеке: в нем есть http, sql, logger и т.д. Прям в ЯЗЫКЕ

Тут скажу следующее:

1. Вокруг этого не образовалось никакой экосистемы готовых решений и плагинов, а главное коммьюнити и вакансий

То есть с RoR, Django, Asp, Symfony сравнивать нельзя

2. Непопулярно и никогда не станет, потому что слишком давно существует от слишком известного человека

И это в очередной раз проигрыш вышеназванным

3. Субъективно, но если что-то написано полностью на JS без TS то оно имеет право на существование только в случае платформы для разработки (Svelt как пример)

4. Там написано сначала «lightweight”, а потом самые тяжелые паттерны в мире «DDD, layered (onion) architecture, DI, SOLID and GRASP principles, contract-based approach;»

Превращать Ноду в Java / C# - очень плохая идея (говорю как человек, который когда-то это делал)

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

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

Если это к защите о \"DDD, layered (onion) architecture, DI, SOLID and GRASP principles, contract-based approach\" то они предполагают такую далекую абстракцию от источника данных и железа, что тебе приходится работать неоптимально с точки зрения инфры, чтобы поддержать \"чистоту бизнес логики\"

И именно из-за них раньше приходилось держать гигантские тачки, чтобы можно было \"выгрузить весь аггрегат сделать 1 транзакционное изменение, а потом второй и тоже самое и если что, откатиться сделав компенсирующую транзакцию\"

А вот когда ты перестаешь создавать кучу слоев абстракций и в HTTP контроллере (ну максимум выделить функции от интерфейса например в \"features\") пишешь 1 оптимальную SQL команду на UPDATE FROM SELECT, итерируешь по результатирующему курсору отправляя каждый готовый кусочек данных в сокет HTTP ответа, ты тратишь минимум ресурсов, так еще и логика намного понятнее

Кому понятнее ? Инженеру за рейт от 5000$ ?

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

А если нужен будет супер хайлоад , то вход пойдет С или Раст

Хорошо, рад что это кому-то помогает

Так может есть что то , что может больше помочь и вы об этом знаете?

Ну возьмем к примеру быстрорастущий стартап с командой из 15 чел. 5 из них бек , 2 инфра , остальные моб разраб.

1.Как не терять темпы добавления новых фичь?

2.Как организовать код и совместную разработку?

3. как делать быстрый онбординг новых инженеров в команду?

Я постарался описать все лучшие техники удобного, простого и понятного написания кода и сложил их в книгу https://fop.davidshekunts.ru/

Не буду говорить что это «для всех», это для тех кому откликнется

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

Сейчас мы командой из 7 бэков и 3-х фронтов пилим уже 3 High load проекта, а до этого делали на базе подобный методологии в компании где 300 разработчиков и тоже хорошо работало

Ознакомлюсь

Буду рад комментариям)

«А вот когда ты перестаешь создавать кучу слоев абстракций и в HTTP контроллере (ну максимум выделить функции от интерфейса например в "features") пишешь 1 оптимальную SQL команду на UPDATE FROM SELECT, итерируешь по результатирующему курсору отправляя каждый готовый кусочек данных в сокет HTTP ответа, ты тратишь минимум ресурсов, так еще и логика намного понятнее»

А зачем тогда нужна абстракция «база данных»? По этой логике, можно в файликах всё хранить и самому строить индекс. Зачем всё в строки преобразовывать каждый раз? Столько ресурсов сгорает! 😂

Если я правильно понял вопрос, то ответ: "База данных" – это абстракция в виде технологии, а я говорю об абстракциях в твоем собственном коде

Поэтому БД – это натуральная сложность, а "свои слои абстракции" – это искусственная сложность (писал об этом в книге)

И зная, что ты любишь ФП, сразу скажу комментарий: когда мы делаем слоистую работу с IO (сначала IO, потом логика, потом IO, и так далее) то это хороший подход, потому что он не про "абстракцию", а про control-flow, где мы хотим больше оставаться в области чистых функций

Пример: паттерн "репозиторий" абстрагирует БД, а если ты делаешь SQL запрос, потом его значение передаешь в чистые функции, потом результат функций опять в SQL запрос – это просто разделение флоу работы с IO

"Зачем всё в строки преобразовывать каждый раз?" – не совсем понял)

«Пример: паттерн "репозиторий" абстрагирует БД, а если ты делаешь SQL запрос, потом его значение передаешь в чистые функции, потом результат функций опять в SQL запрос – это просто разделение флоу работы с IO»

Репозиторий не нужно делать или нужно? Я что-то не понял. 🤔

«"Зачем всё в строки преобразовывать каждый раз?" – не совсем понял)»

SQL про строки же. Сначала преобразуешь данные в строку запроса, потом её посылаешь в БД. С ответом та же ситуация, получаешь строки и парсишь. 🥸

Я много лет использовал паттерн "репозиторий" но со временем понял, что он дает больше проблем, чем помощи (если хочется подробнее, то лучше опишу отдельной статьей)

"SQL про строки же." – если тебе нужно сделать запрос в БД (если у тебя SQL БД), тебе надо будет сформировать SQL с правильной последовательностью аргументов и приложить вместе с аргументами в коннекшен, несомненно стоит делать это через Query Builder (kysely) или генеративный (sqlc)

А если ответ от БД тебе надо тоже как-то преобразовать, ты будешь его получать из курсора, модифицировать и отправлять клиенту

Или о чем ты?

Я к тому, что можно же в файлах хранить байтики, зачем эта прослойка. 😁

Зачем строить абстракные запросы и использовать сложные сериализации/десериализации? Захотел получить сущность — прочитал файл, спарсил в объект и готово. 😁

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

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

Как сайд-эффект станешь автором новой крутой БД 😎

Если возникнут вопросы производительности и т.п., то можно использовать lmdb или аналоги. И репозиторий будет крайне простым. 😁

Зато не надо искать DBA специалиста по SQL. Сразу пул специалистов расширится. 😂

Я кстати сейчас изучаю исходник https://github.com/dgraph-io/badger, очень интересные чтиво