тут задвайте

ну а зачем там middleware придуманы тогда?

фрейворки у нас не жалуют

фрейворки у нас не жалуют

то есть по сути Go по типу микрофреймворка? В стандартном пакете есть все для веба -> дальше сам крафтишь свой апп? Почти как Flask в питоне, так?

то есть по сути Go по типу микрофреймворка? В стандартном пакете есть все для веба -> дальше сам крафтишь свой апп? Почти как Flask в питоне, так?

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

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

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

для руста подобное видел

хотелось бы видить что-то подобное для Go, поскольку Go это рай для статик-анализа)

нененене, ясное дело что можно поломать совместимость поломав поведение функции. Но я скорее говорю про облегчение стандартного workflow разработчика Go а не про охоту на баги. Если уж ты назвал функцию CreateFile то она конечно должна создать файл, если она этого не сделает то мы получим баг. Данный анализ не сможет защитить от багов! Он сможет лишь значительно облегчить CI/CD, тебе не нужно мануально выкатывать версии с CHANGELOG'ом и всё ручками писать.. сервис с каждым комитом track'ит версию и по нажатию кнопочки можно получить release + semver версию + changelog

> Go > рай для статик-анализа Оо. Ты о том, что это го это рай для компаний производящих проприетарные решения для статик-анализа? Ну всё же цпп ему ен переплюнуть.

Если не ошибаюсь, в своем цикле статей, перед выкаткой vgo, как раз об этом писал

https://forum.golangbridge.org/t/go-1-2-immutability-proposal/10613

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

раньше было лучше (с) во времена ассамблера не говнокодили (с)

Ребят, я как понял в Go горутины - самые обычные корутины, только с implicit event loop'ом?

Ребят, я как понял в Go горутины - самые обычные корутины, только с implicit event loop'ом?

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

То есть корутина сама фактически должна отдать управление другим корутинам, что собственно и есть кооперативная многозадачность

Но к примеру в ноде, корутина не прерывается пока не встретилось слово await.

node это event loop go это как потоки, только легковесные и кооперативные. у них user space scheduler который работает на пуле системных потоков

node это event loop go это как потоки, только легковесные и кооперативные. у них user space scheduler который работает на пуле системных потоков

А разве в го нет event loop какого-нибудь?

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

user space scheduler

И в чем его принципиальное отличие от event loop поверх тред пулла?

А разве в го нет event loop какого-нибудь?

какие еще варианты есть? огласите весь список, пожалуйста

какие еще варианты есть? огласите весь список, пожалуйста

Проще всего делать json-rpc поверх gorilla websocket

Ребят, посоветуйте ORM (нужно чтобы firebird поддерживало, или какое либо универсальное решение)

нормальная ОРМ только одна - reform. Но в огнептицу она не умеет к сожалению

gorm? а про него что скажите

Sql boiler?

gorm? а про него что скажите

это на сколько я понял универсальное решение?

Ну впринципе

Sql boiler?

похоже придется пользоваться gorm

а без ОРМ ни как нельзя? я вон для огнептицы юзаю sqlx. в принципе проблем нет

а без ОРМ ни как нельзя? я вон для огнептицы юзаю sqlx. в принципе проблем нет

Он хорош

концептуально sqlx не позволяет разве что запросы с динамической структурой билдить. Для этого есть squirrel