Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Як і для чого вивчати Golang. Переваги і недоліки мови

Привіт! Мене звати Ігор, і я займаюсь програмуванням от вже 14 років. Зараз працюю в компанії Blackbird Lab. Чи помічали ви, як одні технології знаходяться на ринку вже багато років, а інші з’являються та зникають дуже швидко? Нам як розробникам постійно потрібно вивчати щось нове для того, щоб бути конкурентоспроможними на ринку праці. Але чи траплялося у вас так, що технології, які вивчаєш заради задоволення, потім знадобляться вам для роботи? Так сталось у мене.

Я почав працювати у 2008 році та довгий час займався платформою .NET. Тоді ще не було front-end чи back-end розробників, не було DevOps інженерів, не було бізнес-аналітиків. Того часу я обіймав посаду Web Developer та робив усе, що казав PM: трохи back, трохи front, трохи бази даних та всяке інше. Потім було багато різних проєкт, різних компаній.

У 2018 році я почув про мову програмування Go. На той час я працював у EPAM Systems, де деякі замовники вже використовували цю технологію. І як завжди відкрив якісь туторіали, подивився, щось написав — стало цікаво! Але реального проєкту не було, тож вивчення цієї мови було більш як хобі. Раптом одного дня мені запропонували проєкт, який вже був написаний на Go, але мігрував на .NET. Дивна ситуація, але я погодився. Так почалась моя карʼєра Go розробника.

Для чого створювався Golang

Спочатку мова програмування Go створювалась як внутрішній продукт у компанії Google. Вперше мова була представлена у 2009 році, а перший реліз відбувся у 2012. Основною метою створення цієї мови програмування було поєднання високої продуктивності компільованих мов з легкістю написання коду з підтримкою Garbage Collector. Мова вийшла досить лаконічна, але при цьому код залишається легким для читання і сприйняття.

За основні переваги мови програмування Go можна вважати наступне:

  • Простий та лаконічний синтаксис.
  • Статична типізація.
  • Швидкість компіляції.
  • Паралелізм.
  • Дуже потужна стандартна бібліотека.
  • Можливість писати у функціональному стилі.

Варто сказати трохи детальніше про паралелізм. Go надає механізм горутин (goroutines) та каналів, який є кілер-фічею цієї мови програмування для роботи з багатопотоковістю та паралельних обчислювань.

Чому Golang є актуальним сьогодні

Через те, що я дуже давно працював з платформою .NET в деяких аспектах я буду порівнювати Go із C# або подібними мовами. На цю мить мова програмування Go досить популярна на IT-ринку. Можна з упевненістю сказати, що попит на Go розробників перевищує пропозицію. Але чому ця мова стала популярною?

Як вже було зазначено раніше, Go — проста і лаконічна, але має переваги компільованих мов та таких платформ як .NET та Java, які керують пам’яттю та займаються прибиранням сміття. З популярністю мікросервісної архітектури Go дає можливість швидко створювати сервіси, мінімізуючи кількість написаного коду в багато разів, у порівнянні з іншими мовами. До речі, всім відомий Docker написаний на Go.

Окрім того, Go працює дуже швидко та її іноді порівнюють за швидкістю виконання з С++. Тому ця мова дуже актуальна в обчислюваннях, де критична швидкість. Дуже багато проєктів для Blockchain та криптовалют використовують цю мову програмування. Також застосовують її ті проєкти, де використовується системне програмування або взаємодія з мережею.

Go має дуже велике ком’юніті, де є величезна кількість безплатних бібліотек та фреймворків, якім можна завантажити та додати до свого проєкту. Взагалі ця мова має відкритий код, тож будь-хто може подивитись, як влаштовані ті чи інші аспекти.

Щодо вакансій на ринку України, звісно Go не може поки конкурувати з PHP, Java або .NET. Відповідно до знайденої мною статистики кількість вакансій Go розробників приблизно дорівнює кількості вакансій на iOS/Adroid або Ruby.

Але варто зазначити якість цих вакансій. Через те, що Go дуже часто використовується у стартапах або у проєктах, де необхідна швидкість обчислювань та багатопотоковість, скоріш за все вакансії будуть від відповідних компаній. Тобто майже всі вакансії повʼязані з новими проєктами у різноманітних галузях. Вірогідність, що ви будете працювати з найновітнішими суміжними технологіями дуже велика. Відповідно заробітна платня може бути у верхньому сегменті ринку та на 15-30% більша ніж у великих конкурентів.

Недоліки Golang

Попри те, що мова програмування Go є досить потужною та дозволяє писати менше коду, є певні недоліки, які потрібно згадати. Я не буду детально вдаватися в подробиці, але зазначу лише дві основні проблеми на мою думку.

Перша проблема полягає в тому, що в Go не імплементований класичний підхід ООП. Так тут можна створювати свої типи та додавати їм певні функції, але це відбувається через механізм вбудовування, та немає класичного успадкування. Це може бути незрозуміло, якщо ви вже маєте досвід, або навчити вас «неправильному» підходу, якщо ви початківець.

Друга проблема полягає в тому, що в Go немає єдиного фреймворку для розробки. Річ у тім, що коли у Google створили Go, вони віддали її у ком’юніті, щоб мова розвивалась. Тому існує безліч фреймворків для різноманітних задач. Через це вам потрібно самим ретельно підходити до вибору того чи іншого фреймворку.

Вивчення Golang з нуля без попереднього досвіду

Важливе зауваження: якщо ви вивчаєте будь-яку технологію або мову програмування, знайдіть хороші курси, де ви можете онлайн чи офлайн навчатися та консультуватися з викладачем, та/або знайдіть ментора, який допоможе вам вибудувати правильний шлях навчання. Також я вважаю, що дуже бажано мати базові знання з архітектури комп’ютера, дискретної математики та основ програмування. Але це тема для окремої статті.

На мою думку, Go достатньо проста мова програмування для вивчення в цілому, але є нюанси у порівнянні з класичними ООП мовами, такими як С# або Java. Якщо розглядати поглиблене вивчення Go, то воно може бути складніше, ніж, наприклад, JavaScript, бо вимагає глибоких знань, як працювати з терміналом та файловою системою. Але якщо ви добре орієнтуєтесь в операційній системи та вигляд термінала не викликає у вас паніки, то у вас все вийде.

Go досить дружня мова с точки зору початку вивчення. Почати писати можна, відкривши The Go Playground прямо у браузері! Але все ж таки я б порекомендував встановити Go на компʼютер. Після цього можна встановити Visual Studio Code. Це безплатний редактор коду, який дозволить писати код та запускати ваші програми.

Далі можна зануритись у вивчення за допомогою того формату, який вам підходить більше. Це може бути перегляд відеоуроків на YouTube, курси на Udemy чи Pluralsight, або проходження матеріалу у книжках. Памʼятайте головне — пишіть більше коду. Перегляд відео уроків або читання книг саме собою не дає результатів та не відкладає знання, доки ви не відкриєте IDE та не напишете код.

Ще дуже важлива навичка — це виправлення помилок у вашому коді та вміння вирішувати труднощі. Для цього потрібно буквально вміти гуглити вашу проблему та знаходити вирішення. Звісно тут може дуже допомогти ментор, який скерує ваші зусилля.

Можу сказати, що будь-яка книга з Go буде корисна, але маю порекомендувати:

Відеоуроки на YouTube:

Курси на Udemy:

Вивчання Golang як другої мови програмування

Якщо ви вже досвідчений програміст, то вивчення Go має буди для вас легкою задачею. По суті потрібно вивчити синтаксис та деякі нюанси цієї мови програмування. Але в цілому їх в рази менше ніж, наприклад, у C# чи Java.

Для професіоналів я б лише додав книгу Mihalis Tsoukalos — Mastering Go — Third Edition, також є у російському перекладі, має назву «Golang для профи». І наостанок — дуже корисний ресурс з прикладами Go by Example.

Висновок

На мою думку, мова програмування Go дуже перспективна та займатиме надалі суттєву долю ринку. Через те, що багато хто недооцінює цю технологію, поки ще відчувається дефіцит спеціалістів. Тому є можливість отримати цікавий проєкт зі свіжими технологіями на борту. Так, поки що це навряд буде великий ентерпрайз та проєкт на 150 осіб. Цю нішу ще довгий час будуть займати .NET та Java проєкти. Але якщо подивитись на перспективу розвитку back-end проєктів, то використання Go з кожним роком стає все цікавішими.

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному8
LinkedIn

Найкращі коментарі пропустити

Друга проблема полягає в тому, що в Go немає єдиного фреймворку для розробки.

Як впізнати .net-івця за однією фразою :-)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
має переваги компільованих мов та таких платформ як .NET та Java, які керують пам’яттю та займаються прибиранням сміття

Якщо нічого не змінилося — там є збір сміття. Просто GC зашит в 1 МБ скомпільваного файлу — не дуже крутий.

Статична типізація.

цей аргумент такий частий, і як я розумію розрахований на початківців.

берем просто приклад, ось, з Gorm:

type Product struct {   gorm.Model   Name: string   Code  string   Price uint } db.First(&product, "foobar = ?", "D42") // find product with code D42

Питання:
буде помилка компіляції?

Gorm — як на мене — один з самих наочних прикладів, як суворо обмежена Go у статичній типизації.

Хоча, досвідчені у перевагах Go швидко можуть написати код ліби, яка б викинула помилку на рівні статичного аналізу, коли ми робимо запит по неіснуючому у моделі полю.
Навіть без дженериків обійдуться, то для адепта «простоти Go» непотріб!

P.S.
сігнатура:
func (db *DB) First(dest interface{}, conds ...interface{}) (tx *DB)

The interface{} type (or any with Go 1.18+), the empty interface is the interface that has no methods.

any — от такий взірець статичної типізації...

Питання:
буде помилка компіляції?

А должна быть? В этой либе, как и в XORM, юзается рефлексия. И там это ключевой момент, что запрос к БД составляется в зависимости от декларации переданной структуры. Что в свою очередь уместно в парадигме статической типизации.

А должна быть?

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

Даже на Java — не самом крутом в этом плане ЯП можно создать Typesafe SQL:
пример из jOOQ
Result<?> result = create.select()                          .from(AUTHOR)                          .where(AUTHOR.ID.in(select(BOOK.TITLE).from(BOOK)))                       //                     ^^^^^^^^^^^^^^^^^^                       // AUTHOR.ID is of type Field<Integer> but subselect returns Record1<String>

И там это ключевой момент, что запрос к БД составляется в зависимости от декларации переданной структуры

Извините, такое «чудо» в рантайме можно соорудить в любом ЯП. При этом на ЯП с дин типизацией даже проще.

Говорю ж, аргументы адептов Go звучат как
Мы изобрели деревянное колесо!

Поэтому и непонятно: они малограмотные что-ли, не в курсе что:
колесо давно известно
и давно изготавливается из тьмы материалов, дерево на сейчас, далеко не лучший материал для изготовления колес. Даже на деревенской телеге — можно увидеть автомобильные колеса из стали с покрышками.

или просто тролят :)

Что в свою очередь уместно в парадигме статической типизации.

Статическая типизация — это когда проверки работают — ДО запуска приложения, а не во время.

Даже PHP с его тайпхинтингом, позволяет описать типы более точно чем Go, что позволяет задействовать PHPStan или Psalm

а проверки во время выполнения

function foo(arg) {
if (typeof arg === «string») ...
}

это никак не статическая типизация.

это никак не статическая типизация

На самом деле в Go — строгая статическая типизация, в отличии например от C++, где нестрогая. Приведение типа возможно только с явным указанием. Критика лаконичности функциональных возможностей языка — не совсем уместна, поскольку в этом как раз одна из ключевых его идей. Сделать язык настолько простым, насколько это возможно, с применением в задачах промышленной разработки. Появление Go на рынке именно в том виде, что есть, уже давно назрело: глядя на простыни кода с неуместным нагромождением классов и темплейтов в C++ или Java, невольно возникает вопрос — а нельзя ли всё это как-то упростить, поскольку в конечном счёте ожидается от кода выполнение простых по сути вещей. И Go здесь является идеальным на сегодняшний день решением. Он прост как javascript, и даже ещё проще. То есть решена практически невозможная задача — как сделать язык проще известного и доступного каждому js, и при этом чтобы получить компилируемый высокопроизводительный код, где имплементирован опыт лучших практик разработки. Да, всё именно так: в Go собрана выжимка лучших практик разработки:
— стандартные библиотеки просты, эффективны и интуитивно понятны.
— простая и эффективная модульная система. Любая новая библиотека подключается просто, и без проблем. В отличии например от библиотек C/C++, где подключение в проект чего-либо нового просто чтобы скомпилилось — это зачастую целый аттракцион.
— единый стиль кода, исключающий стилистические разногласия между разработчиками.
— сведено к минимуму дублирование логики в языке, конструкции могут быть написаны только одним способом.
— в целом философия языка придерживается принципа бритвы Оккамы: не создавать сущностей сверх необходимого.
— все параметры оптимизированы таким образом, чтобы разработчик мог сделать хорошую «рабочую лошадку» — сервисы на Go могут стабильно работать месяцами, при этом не разрастаться по объёму используемой памяти, с эффективной работой GC, с высокой производительностью, сравнимой с чистым C, и при этом с управляемым кодом.

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

Практика рассудит, жизнь покажет :)

— простая и эффективная модульная система. Любая новая библиотека подключается просто, и без проблем. В отличии например от библиотек C/C++, где подключение в проект чего-либо нового просто чтобы скомпилилось — это зачастую целый аттракцион.

Типа C/C++ это бенчмарк в области dependency management?

Сравни, например, с C#, Java, nodejs или Rust.

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

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

Дублирования кода в Go более чем предостаточно, более того, это даже активно пропагандируется: A little copying is better than a little dependency.

— все параметры оптимизированы таким образом, чтобы разработчик мог сделать хорошую «рабочую лошадку» — сервисы на Go могут стабильно работать месяцами, при этом не разрастаться по объёму используемой памяти, с эффективной работой GC, с высокой производительностью, сравнимой с чистым C, и при этом с управляемым кодом.

Копиум, которым закидываются гоферы, когда видят результаты бенчмарков.

все параметры оптимизированы таким образом, чтобы разработчик мог сделать хорошую «рабочую лошадку» — сервисы на Go могут стабильно работать месяцами, при этом не разрастаться по объёму используемой памяти, с эффективной работой GC, с высокой производительностью, сравнимой с чистым C, и при этом с управляемым кодом.

При цьому на Ноді, .НЕТ і інших платформах зі збором сміття — не можуть (вірніше можуть, але далеко не завжди). Чи це якась магія?

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

Та вони усі оптимізовані. Але так, як ви зауважили, що zero heap alloc це мабуть єдиний надійний спосіб не встрягнути у проблеми з GC

З суто практичної точки зору ,зараз відсутній нормальний інструментарій для перевірок коректності ADT в Compile Time — є хіба що Scala з розпаковкою макросів, десь у Quill, й більше нічього толком не може підєднатись до БД, завантажити схему, та зробити всі необхідні перевірки типів, прямо під час компіляції. Ще невідомо як й шо буде з тим в Dotty...

От лінтера, дійсно, можна написати до чого завгодно... тому порівнювати з GORM’ом дуже некоректно, бо Сompile Time є хіба що лише в одній мові та бібліотеці... JooQ не рахую за повноцінний ORM, бо там кодогенерації Active Record з 60 табличок на 20К LoC.

З точки зору «статичної типізації», роздутість TypeScript’a вже давно стала мемом. Раніш всі глузували з фронтендерів, а зараз складність місцевих типів вже давно перевершила очікування навіть того що є у скалі... з іншого боку треба розуміти що як всі ті делитанти на ринку йдуть в складну мову, нічього окрім ANY ніхто й не отримає... але гірше за саме ANY, — це те, що до того ANY ніколи не буде корректної та повної спеки для тестування.

Тому я повністю підтримую Клімова в цьому плані: гоніння за статичної типізацією, особливо у випадку з TypeScript’ом, — є лише надолугою ідеологічною мастурбацією, та типовим Карго Культом. Тести все одно доведеться писати, що з типами, що без, й перевіряти коректність спек. Все інше, — просто тупі відмовки та виправдання, в стилі «не можу писать нормально там де ANY»...

З суто практичної точки зору

Та це зрозуміло що недоліки то переваги, в залежності від сценарію використання.

JooQ не рахую за повноцінний ORM

GORM та Jooq — я використав як приклади потужності мови.

З точки зору «статичної типізації», роздутість TypeScript’a вже давно стала мемом

Де стала, у кого стала мемом?

Але так, переваги то недоліки в залежності від бажання аргументації :)

а зараз складність місцевих типів вже давно перевершила очікування навіть того що є у скалі...

так, у TS зараз найпотужніші можливості роботи з типами серед мейнстрім мов.

Але так, як хочется — то найпотужніше стає недоліком. Залежить від того що хочеться довести ;)

Наприклад — інтегровані засоби роботи з HTTP та HTML у PHP — його хейтери вважають за недолік.

Так і тут — щоб довести що навмисно збідена можливостями Go найкраща, треба аргументувати що все що зроблено краще, потужніге в інших мовах — то їх смертельний недолік.

І вуаля — ми довели що електроний мікроскоп не треба, зайвий а от молоток — то найуніверсальніший інструмент і найвеличайше досягнення технічного прогресу!

гоніння за статичної типізацією, особливо у випадку з TypeScript’ом, — є лише надолугою ідеологічною мастурбацією, та типовим Карго Культом

ну тоді давайте перемістимо

За основні недоліки мови програмування Go можна вважати наступне:
Утілітарно примітозована семантична виразність.
Статична типізація.

Тести все одно доведеться писати, що з типами, що без, й перевіряти коректність спек

Це головний аргумент ЗА мови з дінамічною типізацією :D
так що таки недолік у Go — статична типізація...

Де стала, у кого стала мемом?

Наприклад тут, для користувачів ESLint’a.

Наприклад так.
Як раз таки із-за складності типізації та високого порогу входження, його переваги до сих пір багато кому незрозумілі та невідомі.

Якщо 30% часу роботи витрачається на розплутування тайпінгів, то може не варто їх розплутувати й почати працювати ? Або ж взяти нормальну не роздуту мову ?... там Kotlin.js / Scala.js / ClojureScript тощо.

Тай сам TSC на стільки повільний що вже краще просто відкинути типи та компіляцію самим TSC — були ангулярні проекти що суто із-за наявності перевірок типізації через TSC збирались по 2-3 години. Та й людям тяжко написати щось суттєве. Сам вже давно не використовую tsc та пересів на babel-preset-typescript та swc.

переваги то недоліки в залежності від бажання аргументації

Не плутайте відсутність аргументації з знеціненням тверджень.

Якщо 30% часу роботи витрачається на розплутування тайпінгів,

30%? це ви таку статистику у групі вайтішників робили, чи що?

Як раз таки із-за складності типізації та високого порогу входження, його переваги до сих пір багато кому

як раз тому що від типізації коли складно — легко відмовитись за допомогою // @ts-ignore та any — проблему з TS вигадують чи перфекціоністи чи упороті.

Або ж взяти нормальну не роздуту мову ?

а в них під капотом мова з дін типизацією як у TS?
в них так же легко вибирати перевірку типізації?
її суворість, детальність, або взагалі гранульовано відмовитись?

ClojureScript

мертвий давно.
А на Scala.js — нехай пишуть «академіки» :)
а навіщо Kotlin,js коли є TS — мені взагалі незрозуміло.
Kotlin як замінник Java — зрозуміло. А от чим він кращий за TS, за яким стоїть команда Хейлсберга...

Мова сама по собі зараз нічого не вирішує.

Мова з об’язкою тулзів, підтримки в IDE — ось що має практичний сенс.
це призводить до популярності використання, а не властивості мови.
Ті часи, коли поява просто мови «С++» робила революцію — пройшли і не повернуться.

Той же Коtlin так і залишився б невідомим, як і були вже до нього, якби його автори не були авторами відомих IDE, куди вони зразу додали його підтримку.
Покращених Джав було вже купа.

ай сам TSC на стільки повільний

повільний не він, а зазвичай вебпак з купою всього що він запускає.

Але так, можна зробити його швидше:
... we’ve found TypeScript 5.0 Beta only takes 81% of the time it takes TypeScript 4.9 to build VS Code.
«Announcing TypeScript 5.0 Beta»

Я ж кажу, щиро, без тролінга
Адепти чогось — це типові демагоги та невігласи.
Щоб довести щось — вони на ходу вигадають проблеми яких не існує, створюють солом’яне опудало, а потім пропонують рішення проблем. Того опудала, яке самі собі вигадали, або отримали дитячу травму на все життя, бо не змогли чогось опанувати.
А те що їх знання проблем відстало від сьогодення на роки, у кращому випадку — й гадки не мають.

у розробці на JS/TS є купа проблем, притаманих тільки цьому стеку.
Але вони точно не в складності системи опису типів та повільності TS.

І у кожного стека на зараз — є спеціфічні проблеми та біль, які — ніяки пропозиції вирішити дріб’язкові проблеми не можуть.

30%? це ви таку статистику у групі вайтішників робили, чи що?

Є внутрішня статистика з декількох консалтингів та продуктових компаній.

проблему з TS вигадують чи перфекціоністи чи упороті.
вони на ходу вигадають проблеми яких не існує

Ignorance is a bliss.

а навіщо Kotlin,js коли є TS — мені взагалі незрозуміло.

Щоб писати фронт, бек й мобільні додатки на одній мові з однаковим інструментарієм.

ClojureScript мертвий давно.

Ну в Києві продуктових вистачало наче...

А на Scala.js — нехай пишуть «академіки» :)

Варто глянути там Outwatch під Airstream / Colibri, доволі цікаво працює під fs2-grpc та Protobuf-es.

Всякі DSLки на free monad’aх та Coyoneda Trick’и то вже давно не «академічні забаганки», а реальні речі які «поточне покоління розрбників» використовує в своїй роботі. Те що ви схильні знецінювати речі яких просто не розумієте, або ж звикли ігнорувати — чи то із-за необачності, чи то із-за типової Безвідповідальності, просто показує стагнацію розвидку відповідних технічних навичок та Ригідність — то ж лише у Москалів «не все так однозначно».

Cуто для власного розвитку варто глянути котів з ефектами й третю скалу.

а в них під капотом мова з дін типизацією як у TS?

JS же ж.

в них так же легко вибирати перевірку типізації?

ЇЇ не потрібно обирати — або вже є типізація, така ж як в TS, або ж транслюють з TS’a.

а зазвичай вебпак з купою всього що він запускає.

В мене немає проблем з вебпаком — я вмію його нормально налаштувати що під babel-preset-typescript що під SWC, не гірше ніж це робить верцель, ще невідомо що вони будуть там робити з TurboPack’ом, та чи завезуть підтримку buildkit’a під LLB (я б завіз). TS5 tsc не набагато швидший — просто «завезли трохи backtrack’у та мемоїзації»... хоча б краще вже окремий рантайм з планувальником IO, кешем та інкрементальною компіляцією, й бажано на Rust’і, в Kotlin/Scala точно не полізуть.

Академ складність TS вже перевалила давно за функціонал тої ж скали — так, можна звичайно ідеологічно мастурбувати на «команду Хейлсберга», але питання ж навіщо така складність, якщо суто з практичної точки зору від того не так багато користі, та дуже багато людей сумнівається в доцільності... Карго культ TypeScript’a давно всім відомий — його нема сенсу заперечувати.

Я не здивуюсь якщо в 5.5 з’являться там усілякі залежні типи на Сепараційній Лозіці або ж якійсь Кріпке Монади щоб пахло F*... бо комусь «дуже кортіло» зробити «стильо-модно-молодіжно».

Є внутрішня статистика з декількох консалтингів та продуктових компаній

Ніфігасє, яку деталізацію затрат часу зловили. Не буду навіть питати про методику, NDA ж, всі діла.

Щоб писати фронт, бек й мобільні додатки на одній мові

Що зазвичай не має сенсу, бо у команд бекендерів та фронтендерів різні експертизи у домену. Але так використання Node.js вирішує проблему, коли вона є. Хоча фулстеки — теж можуть, на різних мовах.

Ну в Києві продуктових вистачало наче...

Так, так, аргумент блондинки — «А от я знаю випадок!» — обов’язковий :)

то із-за типової Безвідповідальності

як і застосування етичних оцінок у обговоренні технологій :)

Ото ж і кажу роками — апологетика та хейтинг то особливий жанр риторики, і майже не має ніякого вдношення до самого предмету, який захищається або хейтиться.
Демагогія та невігластво, академінча маргінальність та «я не розумію навіщо для написання Hello world фреймворки» — головні ознакі цього жанру.

Те що ви схильні знецінювати речі яких просто не розумієте

На взаєм :)
Бо маргінали не розуміють реальних потреб, «отих міліонів мух які не помиляються».
Не розуміють про що Страуструп каже:
Design and programming are human activities; forget that and all is lost.

Варто глянути там Outwatch під Airstream / Colibri, доволі цікаво працює під fs2-grpc та Protobuf-es.

... на free monad’aх та Coyoneda Trick’и то вже давно не «академічні забаганки»,

В перший раз бачу ці назви. А функціональщина вже довела на практиці — що не стане мейнстрімом. Хоча про це було зрозуміло, принаймі мені років 10 вже, як не більше :)

Так що — не варто витрачати на них час, академіки з маргіналами завжди щось вигадують.
Як матиме практичні переваги — воно з’являється так що й не оминеш.

ЇЇ не потрібно обирати — або вже є типізація,

З використанням TS вона вибирається по кожній ситуації. Без усякого головняка. За рівнем команди.

Академ складність TS вже перевалила давно за функціонал тої ж скали

Що не має значення, коли немає заборони використовувати не все що він може.

Карго культ TypeScript’a давно всім відомий — його нема сенсу заперечувати.

Звичайний аргумент маргіналів про любу популярну річ.

З суто практичної точки зору ,зараз відсутній нормальний інструментарій для перевірок коректності ADT в Compile Time — є хіба що Scala з розпаковкою макросів, десь у Quill, й більше нічього толком не може підєднатись до БД, завантажити схему, та зробити всі необхідні перевірки типів, прямо під час компіляції. Ще невідомо як й шо буде з тим в Dotty...

Може, Rust + SqlX. Робить перевірки схеми під час компіляції на реальній базі.

ПС Ох щас набіжить хейтерів...

Так, знав що теоретично можна через макроси в расті так само як й в скалі, але раніш не бачив нічього готового, дякую. Загалом то раст не вміє повертати анонімні типи, то треба трохи з тими макросами погратись... та їх треба якось ще кешувати — зазвичай доволі повільні, але це буде працювати.

Ну я використовував — воно в принципі не набагато повільніше, ніж звичайна компіляція, якщо перевірки робити на локальній базі. Там же по суті лише перевірка синтаксиса SQL та отримання схеми, що дуже швидко, запиту самих даних немає.

Так, анонімні типи не вийде використовувати, треба усі резалти описувати. І воно ще перевіряє, чи співпадають типи та чи усі поля заповнюються.

У SqlX проблеми дещо іншого плану — так як там макрос, то є обмеження — SQL запит можна передавати лише як строковий літерал або як конкатенацію строкових літералів (це обмеження стосується лише запитів, які будуть перевірятися у компайл таймі). Тому якщо хочеш зробити щось типу бібліотеки для спрощення роботи з ним — то треба писати макроси, а не функції.

Але може вони вже почали використовувати const вирази, тоді це усе спростило б.

А що не так з типізацією у тайпскрипті? (Крім того, що вона буває доволі складна і «програмісти», які обирали Javascript за його простоту, не можуть її опанувати?)

1. Збільшує когнітивну складність — значно більше коду, навіть в порівнянні з іншими мовами.
2. Складність виведених типів (inferred types) вже давно стало мемом... та й Type Inference не усюди доступний (нема там для Arrow Functions, тощо).
3. По дизайну то все вже тяжіє до залежних типів з усіма наслідками — я теж вважаю що люде які обирали JS за його простоту мало чого здогадуються про всілякі Agda/Idris.
4. Функціональне програмування зараз більш-меньш працює в TS4 fp-ts, про якість тайпінгів та зворотню сумісність всяких там lodash-fp історія замовчує.
5. Із-за низької швидкості перевірок її доводиться повністю вимикати та часто застосовувати альтернативні тулчейни (babel-preset-typescript swc).

Погоджуся з усім, крім 1. — навпаки, добре описані типи зменшують когнитивну складність. Чи ви про написання тайпінгів?

Я про кількість коду — вона значно більша ніж в scala.js / kotlin.js
Когнітивна складність визначаєтсья не тільки цикломатичною складністю, а й кількістю Типів в поточному файлі / пакунку, й кастомным обвісом — алгебрами / операторами тощо.

Загалом то лише питання продуктивності Type Inference — чим більше типів виводиться автоматом, й меньше доводиться писати вручну, тим меньше результючого джерельного коду ... й меньше когнітивна складність — «мізковий стек у хлібців не переповнюється».

Я про кількість коду — вона значно більша ніж в scala.js / kotlin.js

Ну хз, тайскрипт це джаваскрипт + типи (грубо кажучи), тому кількість коду можна порівнювати с джаваскриптом, а не з якимось більш виразними мовами.

Кількість типів буде плюс-мінус такою самою, як і у котліні, бо ці ж типи не беруться нізвідки.

Припускаю (бо котлін.джс не знаю), що кількість тексту може бути меншою за рахунок виведення типів. Але когнитивне навантаження менше не буде, бо типи ж нікуди не ділися, тіко зараз їх треба памʼятати, а не читати.

бо ці ж типи не беруться нізвідки

Ну от в тому то й справа що «беруться».

Type Inference кращий — котлін більше дописує... особливо коли мова йде про якийсь Arrow.kt (пародія на котів) та відповідні плагіни до компіляхтора.

Мені незрозуміло, яке відношення проблеми SQL мають до проблем Go? Звідки на етапі компіляції нам має бути відомо, що відбувається у паралельному світі? Чи є поле у DB, чи його немає, чи хтось його видалив?

Мені незрозуміло, яке відношення проблеми SQL мають до проблем Go?

Вже пояснено у dou.ua/...​rums/topic/41933/#2566220

Звідки на етапі компіляції нам має бути відомо

Тип першого арументу відомий, чи не так? (до речі, а буде помилка, якщо
прибрати gorm.Model з type Product struct { gorm.Model
Тому відомий його інтерфейс (проперті у прикладі) для другого аргументу
і тип проперті — для третього аргументу.

в jOOQ викрутились іншим способом(не простим), бо от так — нема можливостей:
class DBrecord {     toSql() : string {return "";} } class Product extends DBrecord{     Id: number = 0     Code: string = "" } function fooFunc<TObj extends DBrecord, TProp extends keyof TObj>(obj: TObj, prop: TProp, value: TObj[TProp]) : boolean {     return false } let p = new Product() fooFunc(p, "Id", 34)

Чи є поле у DB, чи його немає, чи хтось його видалив?

Поле БД — то штука поза кодом програми, тому не може бути перевірена на рівні статичного аналізу.

Тому відомий його інтерфейс (проперті у прикладі) для другого аргументу
і тип проперті — для третього аргументу.

Як я бачу, другий аргумент ("foobar = ?"), як я бачу, це шаблон умови WHERE. Тут мені важко сказати, чи є foobar полем у таблиці, чи його немає, а також якого він типу та що за звір взагалі.

як я бачу, це шаблон умови WHERE

ОРМи є мабуть на всіх мовах.
GORM — самий уродський що я бачив в свому программерському житті.
А з базами данних я давно працюю, на різних мовах писав :)

І я розумію, що то не його автори винні.
То така мова програмування — зробити пристойно таку штуку як ORM заборонено by design.

І Пайк багато пояснював — чому.
Але всі його пояснення пройшли повз вуха євангелізаторів Golang

То така мова програмування — зробити пристойно таку штуку як ORM заборонено by design.

Це як by design? Чим підхід якогось entgo не влаштовує? Впевнений що є купа інших ORM на go яке з генераторами кода, я не говіст.

Це як by design?

Це до Пайка.
Та до адептів який цей дизайн нахвалюють.

І до волання роками про дженеріки, які накінець завезли в Go. Кострубаті правда, але хоч такі :)

Чим підхід якогось entgo не влаштовує?

в пристойних мовах query builder зазвичай дозволяє писати без сніпетів SQL.
а далі вже — як мова дозволяє, то й перевірити можна.

А враховуючи фундаментально невирішну проблему відображення декларативного опису і маніпуляцій з імперативним — зручність ORM — дуже важлива штука для продуктивності програміста.
Або — тоді краще взагалі формувати запити просто як стрінгі. Принаймі буде простіше — треба буде знати тільки дві мови, а не ще й викручуватись з якимось gormом. API якого виглядає як якесь студенське доробло.

Впевнений що є купа інших ORM на go яке з генераторами кода, я не говіст.

ну то почекаю говістів.
поки ж, який рік вже — тільки отакє жахіття як GORM вони й спромоглися.

Колись, звісно, і PHP був примітивним темплейт генератором. Та й перші версії Java — якись забавки. А JS — невже можна було на ньому щось писати?

Тому не виключаю, що з роками, завезуть в Go не тільки дженеріки :)

От що я досі не можу зрозуміти, так це любов багатьох до ORM та query builder’ів: нашо вчити якусь криву пародію на SQL, яка у більшості випадків менш гнучка й потужна, за цей самий SQL?
Та й це взагалі абсурд та атавізм робити білдер, який в рантаймі побудує строку, яку потім БД буде парсити й виконувати, а відповідь також парсити з таблиць у типізовані структури. Вже б використовували щось типу RPC з бінарними даними, або хоч в json...

От що я досі не можу зрозуміти, так це любов багатьох до ORM та query
builder’ів

Коли не робили складного у складних кейсах, доменах, з врахуванням розміру та змін команд — і на зрозумієте.

Та й це взагалі абсурд та атавізм робити білдер, який в рантаймі побудує
строку

Завдання білдера у іншому.

Але так, якщо не зрозуміли і це — що програмний код пишеться для людини, а на машини, то «атавізм» :)

Коли не робили складного у складних кейсах, доменах

може навпаки? робити CRUD’и просто з ORM, але у разі важких SQL-запитів, всі ці ORM виявляються неефективними і все закінчується костилями з побудовою SQL у стрінгу й подальшого розбору результатів.

з врахуванням розміру та змін команд — і на зрозумієте.

тут можу зрозуміти — джуни і постійна їх ротація вимагають компромісів.

програмний код пишеться для людини, а на машини

ну тоб-то це нормально, що ми з одної human-readable мови (наприклад JS або C#), що конвертується у машинну, перекладаємо на іншу human-readable (SQL), що в рантаймі потім перекладається знов у машинну для SQL-сервера?
В принципі, мій головний консьорн саме в наявності досі SQL замість нормального типізованого «машинного» протоколу без зайвих конвертацій та костилів.

костилями з побудовою SQL у стрінгу й подальшого розбору результатів.

Тож на гоу ми одразу будуємо стрінгу?

І до волання роками про дженеріки, які накінець завезли в Go. Кострубаті правда, але хоч такі :)

Ну так можна в кожній мові. Завжди є у всьому trade offs. Всі мови переглядають минулі рішення і розвиваються.

в пристойних мовах query builder зазвичай дозволяє писати без сніпетів SQL.

Так до чого тут мова? Го оптимізовується щоб було швидко написати якийсь мінімальний сервіс, з цим воно справляється. Для якоїсь джави треба підключати ліби, для того щоб була повноцінна ORM в go теж треба ліби. Чим entgo ліба не катить?
entgo.io/...​docs/crud#field-selection

Ще якась ORM є яка з першого погляду виглядає не гірше github.com/...​er/en-US/mvc/model/orm.md

Я навіть більше скажу. Є ще null типи для нулових полів у базі — часта помилка
А ще дуже часта runtime суто Go помилка це nil pointer dereference
І що? Звісно жодна у світі статична типізація не гарантує що усе буде гаразд.
Я перейшов на Golang (а до цього трохи на .net) із Python. Статична типізація суттєво мені економить час,

Ну... як раз nil pointer dereference легко фікситься, якщо використовувати алгебраїчну теорію типів. Взагалі, типи як раз існують для того, щоб зменшувати кількість помилок runtime.

Чи економиться час? Як на мене залежить від задачі.

якщо використовувати алгебраїчну теорію типів.

А можна конкретніше.
Якщо у тебе така наприклад структура
type SomeStruct struct {
....
log *zap.Logger
}
Якщо ти забув передати log при створенні об`єкту цього типу. Як алгебраїна теорія типів тут допоможе?
Звісно це все виловлюється юніт тестами, але все ж таки цікаво.

Чи економиться час? Як на мене залежить від задачі.

Звісно від задачі. У деяких випадках треба писати багато зайвого коду (особливо якщо ти працюєш із якимісь дикими API які можуть видати у одному і тому ж полі то string, то int то цілу структуру і ти городиш костиляру із type assertions). Але все ж таки для мене простіше так працювати.

og *zap.Logger
}
Якщо ти забув передати log при створенні об`єкту цього типу. Як алгебраїна теорія типів тут допоможе

Для того, щоб спрацювала теорія, потрібні засоби мови програмування, які дозволять помітити log *zap.Logger як значення, яке ніколи не може бути nil.

Тоді будь яка спроба присвоїти цьому полю щось, що потенційно може бути nil, буде відловлена ще на етапі компіляції.

Монада Maybe
Рішення досить просте, на рівні синтаксису ти не маєш можливості звернутися до o без перевірки на Nothing. Тобі завжди треба писати

case obj of Nothing -> error "Log is not set"
            Just o  -> callSomething o 

А якщо ти впевнений, що об’єкт не Nothing, тоді можна викликати напряму.

В принципі, це потрохи додають у мови, вводячи різні optional, але не 100% захист.

Ну і... логування також краще реалізовувати через монаду Writer...

А якщо додати обмеження, що кожен випадок має оброблятися, то ми можемо гарантувати, що при виконанні коду не буде жодних несподіванок, усі варіанти будуть обчислені, звісно, що можуть бути обчислені невірно, то таке.

А якщо додати обмеження на структурну рекурсію, то можна гарантувати, що код виконається за кінцевий час. Звісно, що мова зі структурною рекурсією не буде Turing complete, але при цьому буде достатньо багатою для практичного використання.

Тому... моя порада вивчити Haskell :-)

Тому... моя порада вивчити Haskell :-)

Дякую. Спробую

Двоякое от него впечатление.

Рантайм без шуток великолепен, и если надо малыми силами соорудить нечто сетевое, что будет крутиться 24×7х365 не распухая по памяти и по CPU — я мало что видел лучше. На минуточку, даже iOS—клиент Wireguard крутится на Го, весьма при этом шустро и не насилуя батарейку, к тому же в iOS существует жесткий лимит по памяти для NEPacketTunnetProvider.

Сам же язык ... ну, скажем так, чтобы никого не обидеть — минималистичен :)

Хотя, может это и к лучшему. Те, кто этой идеологией прониклись творят отличные штуки. Над Сашей Валялкиным тут смеялись, а его VictoriaMetrics теперь ого-го!

Надо понимать что у golang’a только вот в 1.20 появился Arena Allocator.
До этого байтики надо было уметь вручную считать... и даже либы Саши Валялкина сортируют пул буферов по частоте доступов, что бы в кешлайны проца влазить...

Гошка как язык очень капризный, и для его правильной и шустрой работы надо стремиться к 0alloc, уметь писать бенчмарки и фаззинг. Чаще всего проблемы стандартной библиотеки либо решаются своими 6-15 конкурирующими велосипедами, либо у людей/компаний для этого просто нет денег. Потому история «что это для тупых» что бы «фичи деливерить» тоже не более чем отмазка... Уже и тот же GRPC переписывали раза 3, вместе с buf.build connect.build и прочим, а 0alloc’a как не было так и нет — люди пытались, но на одном лишь энтузиазме далеко не поедешь.

Потому Rust экосистема в целом хоть и менее проработана в плане конвенций и подходов к разработке, но самые распространённые вещи типа http/2 http/3 GRPC реализованы на порядок более зрело, без потребности в лишних 10-15 велосипедах.

Чаще всего проблемы стандартной библиотеки либо решаются своими 6-15 конкурирующими велосипедами

...а адепты Go говорят что ничего кроме стандартной либы Go не нужно...

Когда сервер может умереть от регулярки — одинаково что на Go, что на Node.js, вера в магию очень быстро испаряеется.

На практике даже тот же кубер кусками давно на Rust переписывали... потому golang — это больше про портабельные СLI’ки и non-mission critical сервисы «второго дня».

не нужно, когда вам не нужно 0alloc code :)

Якось я намагався пройти на ЛітКоді таску з го, яка вимагала роботу з Квері... І тут було два варіанти, або качати депенденсі, або копіювати 100+ строк коду з чужою імплеметаціює

Сам же язык ... ну, скажем так, чтобы никого не обидеть — минималистичен :)

Як цим можна образити :-) Якщо ти зрозумів принципи програмування то найскладніщі мови можна вчити за день. Хоча дехто вихваляє вивчення мов як щось таке прям ...
Я навпаки обожнюю мінімалізм і ідеальною мовою програмування для мене є, будете дико ржати, LUA! Саме завдяки мінімалізму LUA я зрозумів як насправді працює то ООП. От спробуйте заради приколу розібратися в LUAвських метатаблицях.

У меня тоже есть опыт разработки на Lua, причём немалый, лет 6 это у меня был можно сказать основной язык, а C++ второстепенный. ООП из Lua можно конечно вписать золотыми буквами в учебники по прототипному ООП. Также ещё там лучшая реализация коротинов.

Lua прекрасна, коли треба написати щось складніше, ніж може Bash, але простіше, ніж С++.

Але щодо елеґантності реалізації корутин, Forth поза конкуренцією
: yield 2r> swap 2>r ; 

А я думав на Луа можна тільки неовім тюнити! ;) no offence.

О а я від тебе про neovim тільки но почув :-) Треба спробувати якщо воно не руське, а то активно якийсь чувак з Avito його просуває.
Взагалі із LUA познайомився коли на NodeMCU програмував ESP8266 для домашніх саморобок.
Потім ще у якості Pet проекту запилив гру на CoronaSDK і на Roblox гру запилив малому.
Взагалі у геймдеві вона дуже популярна.
Щодо хмар ще якийсь форк Nginx можна тюнити на ній.
Взагалі дуже крутий «клей» для C/C++

Ну NeoVim опенсорсний. Хз скільки там русні і не русні github.com/...​eovim/graphs/contributors

Щодо хмар ще якийсь форк Nginx можна тюнити на ній.

OpenResty

Go це Rust для тупих тих, хто хоче зосередитися на делівері фіч, замість вивчення мови

Судячи по ринку, Го це для тих, хто вивчив Раст, але зрозумів що на ньому неможливо знайти роботу, і пішов пробувати Го

Перша проблема полягає в тому, що в Go не імплементований класичний підхід ООП... Це може бути незрозуміло, якщо ви вже маєте досвід, або навчити вас «неправильному» підходу, якщо ви початківець.

Ага, «класичний». Алан Кей з цього приводу писав багато років тому: «I’m sorry that I long ago coined the term „objects“ for this topic because it gets many people to focus on the lesser idea. The big idea is messaging...».

Перелік коментаторів на dou в топіках про Go:

1. нікому окрім гугла не потрібен — ✅
2. хайпова технологія — ✅
3. для тупих — ✅
4. не вистачає generics — (deprecated, їх вже завезли)
5. нафіга вони зробили generics? стало тільки гірше! — [вільне місце для хейтерів]

Я досі не користуюсь дженеріками бо якось звик без них. Шах і мат — хейтери.

Працював на кількох проектах з golang й можу сказати, що цей допис вводить в оману, бо багато чого — просто маніпуляція.

Може якщо порівнювати з асемблером, то так — більш лаконічна, або якщо порівнювати з плюсам — то більш проста. Але майже усе, що є на ринку Java/Kotlin/Scala/C++/C#/Swift/Python/Ruby/JS/TS виграють у порівнянні з golang, може хіба Rust у дечому схожий (особиста думка, бо на расті комерційний софт не розробляв). Основна фіча golang-у — це легкі потоки. Але в одних мовах вирішили цю проблему через корутини, а у інші вже їх підвезли, тому навряд чи golang популярність буде збільшуватись. Так, є купа вже легасі проектів де потрібні голенгери, або компаній де є купа голенгерів, й тому стартують на ній нові проекти. Але об’єктивно, поза Гуглом, перспективи голенга не дуже.

Але об’єктивно, поза Гуглом, перспективи голенга не дуже

Bingo!
Суб’єктивна об’єктивність вона така, не дозволяє мислити більш ширше. Вакансії кажуть про інше, gladly

Але об’єктивно, поза Гуглом, перспективи голенга не дуже.

В кубер пробували ?

Ні, але код дивився. Плагіни для куберу на голенгу — це правильне рішення, але знову ж таки, кубер виліз з Гугла. Якби він розроблявся в іншій компанії, то, досить ймовірно, був на іншому тех.стеці.

Дякую за топік.
Як рекомендація — в таких статтях було б класно додавати якісь приклади, а то про яку мову не почитаєш так вона швидка, лаконічна, з великим коммюніті і взагалі найкраща в світі)

Gо реально уникальный язык, если сравнивать с «Java/Kotlin/Scala/C++/C#/Swift/Python/Ruby/JS/TS». Но уникальность его не в том, что у него есть какой-то набор супер-выражений или ключевых слов. Хотя, и тут есть немного (go, chan, select, etc). Но это не главное. Уникальность его в философии и его понимании простоты (а так то Python тоже пытается казаться простым). Тут лучше посмотреть выступы Пайка за 09-10 годы, чтобы это понять суть. А то можно начитаться вот такого, что Go, оказывается, чуть ли не функциональный язык.
Если принять, что Go это современный, безопасный, улучшенный С (или С++, как заявляли авторы) с GC то все становится на свои места и достигается гармония. Go наследует философию UNIX.

Go є досить потужною та дозволяє писати менше коду

хахахахах
Я дуже полюбляю «хайпові технології», бо незважаючи на зловживання ними, все ж там часто є цікаві ідеї, та й просто подобається мені щось нове колупати. Kubernetes, NodeJS, TypeScript, Rust, Kotlin (backend), Scala (давно було вже) й так далі — й це те, що я вивчив мінімум на рівні middle девелопера.
Але Go? Серьозно? Таке відчуття що це мова спеціально для людей які нічого іншого не осилили. Ось реально, багато мов хейтять, але відчуття що Go як раз заслуговує на це.

мова програмування Go дуже перспективна та займатиме надалі суттєву долю ринку

Боже помилуй.
Пробачте за мій тон, але це вже як традиція Golang — цей коментар повинен бути тут.

відчуття що Go як раз заслуговує на це.

Ну так тримайте свої відчуття при собі інакше чим ви відрізняєтесь від хейтерів.На рівні мідла він вивчив усе. А Go на рівні мідла не осилив ось і біситься

Ну так тримайте свої відчуття при собі

А як тоді люди дізнаються, що Go погана мова щоб не витрачати час на це, особливо новачки в айті? )

Так напишіть статтю де детально опишіть усі ваші претензії до Golang (бажано щоб стаття була якісніша за цю де автор плутає конкурентність із багатопоточністю)
А ваші відчуття нікому не потрібні.
Не напишете за тиждень я напишу хвалебну оду Golang де опишу в деталях усі переваги цієї мови і її інфраструктури (ліби, комьюніті, тулзи і т/п) і тоді вашему хейтингу прийде кінець! Ха Ха

Не напишете за тиждень я напишу хвалебну оду Golang де опишу в деталях усі переваги цієї мови і її інфраструктури

Напишіть ) Якщо я своїм коментарем спонукаю когось на статтю, це ж круто )
Реально. Немає сенсу писати цілу статтю про те, який Go поганий — й так багато вже, зауваження достатньо. А ось прям гарно, переконливо про його плюси не дуже багато.

Я б сказав, що принаймні одна перевага у Go є — на ньому можна писати код, який компілюється у нативний для платформи бінарник, за яким не треба тягати ліби та фреймворки, й при цьому сама мова доволі проста порівняно з C++ або Rust.

Тобто, для системних утіліт або якихось lambda функцій, де дуже важливий час cold start — ідеально.

Інша справа, що Go почали тягти туди, де його використання автори не бачили навіть у жахливому сні (ті ж ентерпрайзні моноліти).

Інша справа, що Go почали тягти туди, де його використання автори не бачили навіть у жахливому сні (ті ж ентерпрайзні моноліти).

А чому це погано?
Чи можна для тих, хто не в темі, пояснити?

А чому це погано?

1 тому що моноліт писати легше на семантично виразній мові.
а Go — принципиво бідніша мова.

2 а для ентерпрайз монолітів важливіші можливості мови створювати код близький до бізнес логіки, аніж якісь там оптимізації тримати тисячі тредів.

А для цього — мова повинна мати можливості. C#, Java, TypeScript, Python, PHP — мають купу можливостей для пп 1 та 2.
А в Go — крепко порубані саме ці можливості.

Тобто, для системних утіліт або якихось lambda функцій, де дуже важливий час cold start — ідеально.

docs.aws.amazon.com/...​dg/dotnet-native-aot.html

З недоліків я б додав відсутність нормальної підтримки багатьох проектів. Оці $GOPATH $GOROOT це якийсь збоченець придумав.

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

Так ты уже сам определись, Golang или Go. А еще с рекрутеров смеются, что они Java от Javascript не отличают.

Ховраха

Валялкін у молодості?)

Вибачте, у російському плагіаті світових шедеврів не орієнтуюсь

Настільки, що аж зльоту зрозумів — про що мова.

Я и до сих пор не понял. Про что же?

Я теж не зрозумів. Треба Вільного Художника спитати

Ну я просто погуглив хто такий Валялкін
Чи ви про ховрахів

Тоді пробач

Тре було не гуглити, а пошукати його профайл на цьому форумі) Більш упоротого шофера не існує у природі)

шофера

Гофера
Автори т9 будуть горіти у окремому пеклі)

Варіанти Golang Developer чи Go Developer то вже краще, ніж Goland Developer.

Я за варіант Golang Developer бо тоді відсутня плутанина коли в описі вакансії є слово «go» з іншим контекстом.

The language is called Go. The “golang” moniker arose because the web site was originally golang.org. (There was no .dev domain then.) Many use the golang name, though, and it is handy as a label

go.dev/doc/faq#go_or_golang

Так, поки що це навряд буде великий ентерпрайз та проєкт на 150 осіб.

Давно уже пилят на энтерпрайзе с сотнями разработчиков, всё нормально.

Недоліки: Go не C# чи Java. Не назвав би це недоліками, скоріше трохи інший підход.
Я би ще порекомендував одну і найголовнішу книгу по Go: The Go Programming Language
by Alan A. A. Donovan and Brian Kernighan

Brian Kernighan

гарантує! :)))

в Go немає єдиного фреймворку для розробки

... і це прекрасно!

Друга проблема полягає в тому, що в Go немає єдиного фреймворку для розробки.

Як впізнати .net-івця за однією фразою :-)

Маячня. Під .NET їх точно не одна, навіть ще десять або більше років тому був такий двіж, як alt.net, який проповідував максимальне дистанціювання від «стандартних» фреймворків від Microsoft.

З іншого боку, те ж саме можна сказати й про Java, де теж є з чого вибрати, але дуже багато хто пише на Spring Boot.

І як? Допоміг двіж?
Тільки коли Microsoft це віддало на open source почало по троху змінюватися на краще.

А кому він мав саме допомогти?

Втім, дещо з того, що було популярним у alt.net ком’юніті, свого часу мало непоганий adoption rate — той же NHibernate.

З іншого боку, в тій самій ноді маємо різноманіття фреймворків (а про front-end краще й взагалі не згадувати, бо там вони з’являються як гриби після дощу) — але чи краще це для developer experience пересічного розробника?

Все-ж таки, коли екосистема стандартизується на невеликій множині рішень та компонентів — це й краща підтримка, й більш пологий learning curve (бо не треба перенавчатися при переході з одного проекту до іншого).

Інша справа, що дійсно дуже бажано, щоб ці стандартні рішення були open source, бо з MSFT проблема була не скільки в тому, що було мало альтернатив, скільки у тому, що вони роками забивали на баги, а ніхто інший виправити їх не міг, бо пропрієтарщина.

Як людина, шо все життя заробляє гроші розробкою на Symfony, як на фреймворку, шо став де-факто стандартом в php ентерпрайзі, не можу погодитись. Спробую пояснити на власному прикладі. Чомусь мені здається, шо це буде актуально і для .NET, але можу помилятися — поправте, будь ласка, в такому випадку.

Якшо ти працюєш з symfony, то у тебе нема особливих альтернатив, наприклад, в тому, як працювати з базою даних, бо у тебе є Doctrine. Ти не можеш отак просто взяти і замінити її на якусь Cycle ORM чи Eloquent. Частково ця проблема вирішується за допомогою PSR, який дозволяє замінити, умовно, один http client на інший, але це трохи не те.

Коли я почав своє знайомство з Golang мене вразило те, шо ніхто нікого ні до чого не зобовʼязує. Треба працювати з БД? Ок — бери ту ORM, яка тобі подобається, і працюй!

Щось подібне є в «мінімалістичних» фреймворках Python по типу Flask, але там на перший план виходять уже зовсім інші речі.

P.S. Про різноманіття JS фрейсворків — це теж спірно. Я отак сходу можу назвати React, Vue, Angular і, може, Svelte. Всякі backbone, meteor, ember ніколи не були в мейнстрімі і лишаються доволі нішевими продуктами, які тримаються за рахунок ентузіастів. Сподівась, не варто пояснювати, чому я не згадував Express, Next та їм подібні. Якшо брати до уваги лише тих, хто пройшов випробування часом, то їх кількість +/- така ж, як і в інших мовах програмування.

Коли я почав своє знайомство з Golang мене вразило те, шо ніхто нікого ні до чого не зобовʼязує. Треба працювати з БД? Ок — бери ту ORM, яка тобі подобається, і працюй!

і любий керівник скаже що — це недолік.
бо — якщо всюди «symfony» і в нас «symfony» — то потенційно ми маємо великий вибір програмістів на ринку праці.
а якщо наш проект написаний унікально — то де ми будемо швидко шукати програмістів (тимчасових контрактників, аутсорс підрядників)?

і відповідальний архітектор скаже — ми зможемо знайти купу прикладів рішень на «symfony», використати досвід — позитивний і негативний інших. ми маємо бест практикі, і навіть сертифікацію (гуглить «Symfony Certification»). А з «бери ту X яка тобі подобається, і працюй!» — ми будемо витрачати час на тестування як тулзів, так і підходів.

і любий керівник скаже що — це недолік.
бо — якщо всюди «symfony» і в нас «symfony» — то потенційно ми маємо великий вибір програмістів на ринку праці.

це не недолік. Го пропагую простоту у всьому, то і працювати із будь-якою лібою немає ніяких проблем. Тому це ліби, а не фреймворки.
Це стереотипне мислення у рамках фреймворків. Говісти можуть працювати будь з чим написаним на го і ніяких проблем у нового гофера на проекті з цим не буде
Це не джава або сімфоні, де потрібно досконально знати фреймворки (той же спрінг та гібернейт), щоб правильно з ними працювати і щось нове натюнити
(Кажу це як колишній джавіст)

це не недолік.

недолік для продуктив які розвиваються з часом різними командами.

так як Го пропагую простоту

простота мови програмування майже не впливає на простоту розробки ПЗ.
виключення — Brainfuck. Ця мова так, буде впливати.

складність — у самому функціоналу ПЗ, а не мові.

тримати десяткі тисяч конектів для відповіді на ping — pong — складно на пітоні, так.
але це не складне ПЗ.

то і працювати із будь-якою лібою немає ніяких проблем.

складність праці з лібою виникає не з того на якій мові вона написана, а з її можливостей.

Це стереотипне мислення у рамках фреймворків.

на взаєм — нерозуміння що такє розробка ПЗ і які головні в ній складнощі — типова риса у аргументах Гошників.

Говісти можуть працювати будь з чим написаним на го

а джавісти значить не можуть працювати будь з чим написаним на джава?
а пхпісти — на пхп?

це тільки говісти можуть працювати з чужим кодом го?

Тобто — на інших мовах те неможливо?

Це не джава або сімфоні, де потрібно досконально знати фреймворки

бо якщо їх писати з нуля — то вийде довше=дорожче і гірше.
і на Go — теж, причому ще довше з нуля писати те що пишуть на джаві або php-сімфоні.

щоб правильно з ними працювати

свій код — це не ознака що автор вміє правильно його писати.
а аргумент проти фреймворків — притаманий «веб-майстрам» з місцевих фріланс бірж. які не змогли вивчити ларку чи вордпрес. «важко, складно те вивчити»...

і давно має назву:
лісапєдописьменники.

ну, як в світі Go лісапєдописьменництво — це перевага, ну ок, обговорювати далі нема що :)

а джавісти значить не можуть працювати будь з чим написаним на джава?
а пхпісти — на пхп?

я ж кажу, Java + Framework != Go only

бо якщо їх писати з нуля — то вийде довше=дорожче і гірше.

а в го їх і не потрібно писати, все є у стд лібі

свій код — це не ознака що автор вміє правильно його писати.
а аргумент проти фреймворків — притаманий «веб-майстрам» з місцевих.
і давно має назву:
лісапєдописьменники.

ну, як в світі Go лісапєдописьменництво — це перевага, ну ок, обговорювати далі нема що

я забув додати, а ви, мабуть і не знали цього, але у Го все є у стд лібі і нічого не потрібно накручувати. Тому не, ще раз писати гібернейт або спрінг, просто щоб написати — такого ніхто не робить, бо не потрібно

складність праці з лібою виникає не з того на якій мові вона написана, а з її можливостей.

ліба — маленька штука. які можливості можуть виникати у цій маленькій опенсорсній лібі, де ти можеш все прочитати, щоб не знати як з ними працювати?

недолік для продуктив які розвиваються з часом різними командами.

не стикався з таким. були проблеми (у сенсі навіщо так писати і взагалі «больно») тільки з тим як пофіксити/додати щось у код, написаний індусами-джавістами бо перекручено джава підходом, коле це взагалі не потрібно адже го це про сімплісіті

це тільки говісти можуть працювати з чужим кодом го?

І це саме чудове! Всі SE дуже просто можуть щось пофіксити у Го, навідміну від Джави, де до дупи магії під капотом фреймворків/глобал стейтах неочевидних, коли малий чендж в одному місті викликає дуже дивні ченджи у другому
Саме зараз на проекті де є моноліт на джаві і всім, навіть джавістам, які там давно працюють, пофіксить/додати щось на го у 100 разів швидше, ніж інжектнути логіку у моноліт і не зламати там щось

я ж кажу, Java + Framework != Go only

ну то й що що ви кажете. («І ви кажіть» — класний анекдот)

Java+Framework — це десятки людино-років.
Go only — вийде ще більше, бо треба буде написати те що вже написано у фреймворці.

а в го їх і не потрібно писати, все є у стд лібі

обрахування знижкі покупцям які купили товарів з груп А та Б на сумму більше X але за виключенням товарів по яких були акції Х та З — теж?

Ото я не надивуюсь — звідки береться аргумент що в стд лібі Go все є, а от в стд лібах у інших мовах так бідно, що є купа ліб та фреймворків.

я забув додати, а ви, мабуть і не знали цього, але у Го все є у стд лібі і нічого не потрібно накручувати

що там є — швиденько зробити модальне вікно з пошуком по перших літерах?

Гошникі чи якись новачки виходить, чи просто тролять не дуже розумно :)

ліба — маленька штука

та ну, хто вам такє сказав :) Вони бувають і малєнькі, так.
А бувають і ой не малєнькі.

які можливості можуть виникати у цій маленькій опенсорсній лібі, де ти можеш все прочитати, щоб не знати як з ними працювати?

нещодавна мав справу з лібою для SOAP.
Як вона може бути малэнькою та простенькою, коли сама спека по SOAP — ніяк не малєнька і не простенька?
І чому це в світі Go складність ліби залежить не від спеки яку вона реалізує, а від того — якою мовою вона написана?

не стикався з таким.

Аутсорс — постійно з таким і працює.
Десятки як не сотні програмістів писало той код.

І що, парочка гошників може все викинути, і шавиденько та гарненько переписати на Go, бо «все э в стд лібі», а сам Go — проста мова, не те що якийсь C#?

тільки з тим як пофіксити/додати щось у код, написаний індусами-джавістами

а як це ви могли — то ж джава а не Go.
там же, в джаві, все так складно, що ніяк такого не зробити:
влізти в код від якихось індусів і щось там пофіксати/додати.
Дивина
ось аргумент

працювати будь з чим написаним на го і ніяких проблем у нового гофера на проекті з цим не буде

а ви пишете що й на джаві так можна?

а як це ви могли — то ж джава а не Go.
там же, в джаві, все так складно, що ніяк такого не зробити:
влізти в код від якихось індусів і щось там пофіксати/додати.
Дивина
ось аргумент

це було про написаний java-like code з купою абстракцій бо джавісти так звикли, але в го можна так і не робити. від того і погано, так шо нічого дивного

а ви пишете що й на джаві так можна?

java != Java + Hibernate + Spring. Потрібно знати фреймворки, коли в Го — не

та ну, хто вам такє сказав :) Вони бувають і малєнькі, так.
А бувають і ой не малєнькі.

у Го не бувають))

що там є — швиденько зробити модальне вікно з пошуком по перших літерах?
Гошникі чи якись новачки виходить, чи просто тролять не дуже розумно :)

я не тролю. Може ви просто не звикли до багатої стд ліби. Розумію :)

нещодавна мав справу з лібою для SOAP.
Як вона може бути малэнькою та простенькою, коли сама спека по SOAP — ніяк не малєнька і не простенька?

і шо? в чому аргумент? що ліба важка?
SOAP — це спека, сама по собі. Якщо не знати що таке СОАП і як з ним працювати, то буде важко працювати з будь-якою мовою
Ви ще скажіть, що важко працювати з OpenAPI лібою, бо це го

Go only — вийде ще більше, бо треба буде написати те що вже написано у фреймворці.

depends on what you need. для бейзік крудів з секьюріті мідлварами і бд вам просто потрібно все написати гошним кодом, замість конфігурації, вийде не так вже й багато коду, повірте.

джавісти так звикли

Ця зввічка ще називається експертизою та професіоналізмом.

Але то такє. Головне що проблеми не існує, достатньо «звикнути».

Потрібно знати фреймворки, коли в Го — не

Тому що на bash, тьху, на Go не пишуть такого складного софта як на «Джаві». От і весь секрет.

Може ви просто не звикли до багатої стд ліби.

Я думаю ви просто ніяких стд ліб більш на знаєте :)
В Go нічого дивного в стд лібі.

Звісно, ви можете навести, що там такє є, чого ніде в стд немає, і тому не треба ніяких ліб до Go ;)

вийде не так вже й багато коду, повірте

Чому я повинен вірити невігласам в розробці, які навіть після натяків не можуть подумати над відповіддю на питання: а чому фреймоворки є для більш потужних мов аніж Go, а для bash, тьху, Go їх нема?

А коду вийде точно більше. Бо в Go дуже погано з симантичною потужністю мови.
Так задумав Пайк, щоб і не лізли з bash, тьху, з Go туди, де давно вирішені проблеми.

Но то ж Пайк, а не типовий не дуже обізнаний в розробці гошник, який впевен що заміна

printf("Hello world!") на
puts("Hello world!")
революція і потрясіння всесвіту

шо ніхто нікого ні до чого не зобовʼязує

Ну там акцент на іншому. Автори мови акцентують увагу перш за все на мові, а сторонні тулзи то вже другорядне

Причому звертаю увагу — мова на 100% самодостатня без фреймворків. Ти спокійно без gorm/gin можеш написати мікросервіс і це не буде біллю (у мене не складні проекти так і написані бо нащо тягнути в проект непотрібні залежності і зайву ORM-мну рефлексію).

Для юніт тестування я використовую взагалі виключно стандартні тулзи і не бачу сенсу щось накручувати. godoc/pprof/gofmt — це шедеври (любов с першого погляду і т/д)

Причому звертаю увагу — мова на 100% самодостатня без фреймворків.

люба мова самодостотання.

а ліби і фреймворки потрібні для того щоби на любій мові — не писати в мілліоний раз те що вже написано.

Ти спокійно без gorm/gin можеш написати мікросервіс

на любій мові де в системній лібі є можливість роботи з TCP/IP — можна працювати без усяких ліб з сервісами які працюють по TCP/IP

питання тільки — навіщо писати той же парсинг відповіді сервера БД — самостійно, коли він давно вже написаний? яка в тому користь — писати свій парсинг?

Ти не зрозумів — працювати і щоб це не було біллю.
Для роботи з базами у go є стандартна ліба SQL і цього достатньо для комфортної роботи з базами.
http ліба стандартна теж гарна.
А фіг з ним — НІКОЛИ НЕ КОДЬТЕ у golang. А ще ніколи не йдіть у блокчейни, multy party computations і на Kubernetes SDK навіть не дивіться. І на хліб у мене завжди буде.

Ти не зрозумів — працювати і щоб це не було біллю.

як я кажу — та куди мені щось розуміти, за майже 30 років в програмуванні, «про біль» :)

http ліба стандартна теж гарна.

а ще — в Go використувуються літери англійського алфавіту!
Круто то як! Неперевершене досягнення!

А фіг з ним — НІКОЛИ НЕ КОДЬТЕ у golang

а що там кодити :)
мова спрощена, є деяка специфіка звісно, вона всюди є.
то чого б не кодити, коли треба буде :)
просто поки — не треба було.

А ще ніколи не йдіть у блокчейни

а що, «йти в блокчейн» є якась ознака крутого пацана, чи що?

І на хліб у мене завжди буде.

на хліб у тих хто на Go не пише — хватає.
навіть якщо ви кинете Go — та почнете писати на мейнстім мові — ніхто й не помітить по розміру своєї хлібини.

а на Go виходить так все погано, що парочка новеньких — вас без хліба залишать?

Для роботи з базами у go є стандартна ліба SQL і цього достатньо для комфортної роботи з базами.

Вочевидь, що у вас дещо особливе розуміння, що таке «комфортна робота з базами»

Мне лень опять гуглить, нормальная библиотека контролов под винду уже есть на го или еще 10 лет подождать?

github.com/sciter-sdk/go-sciter — вот такая подойдёт? Давно известная тема запилена под Go.

Людина мала на увазі

нормальная библиотека контролов под винду

А не черговий сраний electron))

Это даже не сраный электрон, а го-биндинги к сраному электрону.

На виході все одно маємо сраний електрон)

Бо вся королівська кінниця,. вся королівська рать тру програмістів і хейтерів, і навіть з допомогою гошників у яких все просто, і яким достатньо стд ліби для всього — не можуть зробити кросплатформений фреймворк яким будуть масово користуватись.

А презренні жабоскриптери змогли. От і вся ціна трушності і хейтерству.

А презренні жабоскриптери змогли.

і користуються ним тільки самі жабоскриптери, бо нікому іншому він не потрібен)

легко гуглиться, наприклад запитом famous applications by electron

не кажучи про всякі тулзи тіпа pgAdmin. Перши версії яких частенько були на Qt.

з js повторюєтся історія як з пхп — поки пиху хейтили — на ньому була написана більшість сайтів за 2000ни.
та й зараз можна подивитися на чому — trends.builtwith.com

То поки хейтят js, на ньому пишеться купа всього. ті ж лямбди на раз. більше мабуть тільки на пітоні їх пишеться.
Javу теж хейтили, коли вона пішла на сервер сайд.

Від того що лайно юзають, воно не припиняє бути лайном.
Усі оці спроби робити кросплатформений десктоп чи мобайл на жабоскрипті у сухому залишку мають два варіанти — або просто здохло, або переписали на натіву. Звісно є виключення, наприклад шлак чи тімз, але вони як раз краща ілюстрація, чому такий підхід хибний.

Це все просто емоції.
А от від нативного відмовляються частіше чим навпаки.
це — практика а не якісь там почуття лайно, не лайно

Це все просто емоції.

Це не емоції, а оцінка якості одним словом, без розписування на десять сторінок про ненажерливість, тормознутість та інші «бенефіти» такого підходу з власного досвіду.

А от від нативного відмовляються частіше чим навпаки.
це — практика а не якісь там почуття лайно, не лайно

_Моя_ практика свідчить про зворотнє.

Так а де тоді конкуренти? Швидкі, маленькі і усі такі класні?

А немає їх. Тому що кросс-платформенні нативні фреймворкі виглядають як безкоштовне лайно, що скачане з соурсфорджа у 2001 році.

Або потребують х5 ресурсів, щоб пиляти під дві платформи одразу (і х8, якщо ще треба під лінукси)

Так а де тоді конкуренти?

Xamarin, Avalonia, Qt — цього достатньо буде?

Так-то я вам багато можу назвати, наприклад, JavaFX, Rust IceD, і тп.

Qt — це, як на мене, єдиний більш-менш конкурент. При чому складність розробки на ньому набагато вища.

Xamarin — хіба він підтримується на лінуксі чи мак ос?
Avalonia — так, досить цікавий проект, давно дивився його в останнє, сподіваюся, він добре розвивається.

.NET десктопи, як на мене, не менш ресурсоємні, ніж Електрон. До того ж, досить складно без контролів, до речі, як з цим у Авалонії? В Електроні працюють усі бібліотеки компонентів.

Qt — це, як на мене, єдиний більш-менш конкурент. При чому складність розробки на ньому набагато вища.

Складність вища, але результат все окупає

Xamarin — хіба він підтримується на лінуксі чи мак ос?

Так, ще є підтримка різних smart-TV OS

Avalonia — так, досить цікавий проект, давно дивився його в останнє, сподіваюся, він добре розвивається.

він вже досить давно production-ready

До того ж, досить складно без контролів, до речі, як з цим у Авалонії?

нормально, доречі там система стилів схожа на CSS, мені вона подобається більше ніж wpf-на

Складність вища, але результат все окупає

якби отой великий список, початок котрого ви почали, окупав — то не було б ніякого Електрону.

Qt з’явився в таку сиву давнину, що якби його використання щось окупало — все GUI було б на ньому

Але, в нього є шанс. Пітон може дати йому життя, приклад Eric IDE вважаю вдалим прикладом потужності GUI рішень на ньому.

Але, в нього є шанс. Пітон може дати йому життя

у контексті розмови про кросплатформеність згадування python виглядає як мінімум дивно)

_Моя_ практика свідчить про зворотнє.

кого цікавить практика маргиналів?

мілліони мух — то практика успіху, а не вимерлі динозаври :)

і з тим же .NET — я постійно зтикаюся з обуренням дотнетчиків, бо їх заставляють писати й на ангулярах — бо такий попит на UI.
Так і з джавістами — частенько.
А от щоб навпаки вимагали — якось набагато рідше.

Його величність Замовник вимагає не інженерної досконалості.
Хоча є і будуть таки сфери — де вона буде головною.

Сам Golang так з’явився. Як PHP, та JS :)

кого цікавить практика маргиналів?

кращій вихід коли закінчуються аргументи — переходь на особистості
це очікувано було

мілліони мух

це мільйони мух

я постійно зтикаюся з обуренням дотнетчиків, бо їх заставляють писати й на ангулярах

так ніхто їх не заставляє працювати там де їм не подобається)

Його величність Замовник вимагає не інженерної досконалості.

коли ти не на галері, а у продукті, та маєш можливість впливати на рішення ця проблема відсутня)

коли ти не на галері, а у продукті

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

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

Місце ще й як має значення, бо в мене подібного за останні років 5 було аж два чи три рази, і все одно пізніше переробив усе чим був невдоволений)

а в мене інший досвід: від вдосталь часу та натхнення робити і перероблювати архітектуру й код в одному продукті, і до повного говнокоду в іншому продукті, де фіча робилась, тестувалась, потім реквайрменти змінювались до невпізнаності, а бажання та часу все заново детально продумавати і ідеально виписувати не залишалось зовсім.
І те саме в аутсорсі: десь немає часу навіть тести писати, а десь по третьому разу робочий код на інші патерни переписують, бо часу продали багато і треба щось робити :)

Різні люди, різний експіріенс, c’est la vie)

Не согласен. Пластмассовый мир победил. Электрон рулит, хоть и гавно.

Это даже не сраный электрон, а го-биндинги к сраному электрону.

Это не электрон, это его конкурент. Более высокопроизводительный, и с дополнительными возможностями. Например, html+css можно рендерить в текстуру, и дальше использовать в 3D-графике, в электроне такой возможности нет.

Это не электрон, это его конкурент.

Немає принципової різниці, важливе тільки те, що це не натіва.
Ну й він ще у додаток із закритими сорцами, що у нинішні часи виглядає якось дивно.

На кой конвертить html+css в 3D графику, когда есть более удобные и надежные подходы :)

Они же и используются в решениях на Электроне, точно так же, как они же используются в браузере.

github.com/golang-ui/nuklear

Сам не пробував, картинки бачив, красиві

Подивився у сампли, там жерсць жерсцяна, майже геймдев якийсь..
Але дивився неуважно))

Для професіоналів я б лише додав книгу Mihalis Tsoukalos — Mastering Go — Third Edition

Обережно, книга «Mastering Go» з помилками

Підписатись на коментарі