а мемы где? лучше не перекатить чем так перекатить. пацаны так не перекатывают
Стоит ли вначале учить РНР, а потом перекатываться на го?
У меня завалялось несколько старых мемесов, кекай на здоровье.
Есть перевод этих мемасов, а то не понятно?
Первая пикча охуенна, конечно.
Самый, так сказать, дзен.
На самом деле - в этом нет ничего плохого. Совершенно нормальный функциональный паттерн. Я подобное в перле делаю постоянно, хотя там есть и эксепшны, и стактрейсы, и прочий фарш.
А почему ты вообще хочешь писать на го?
Язык минималистичный, можно строить веб-приложения начиная с самых основ. Есть строгая типизация, а значит тип не будет перетекать из строки в число, всегда знаешь что у тебя в переменной. Не нужно учить всякие ОРМ, а сразу писать всё на SQL.
Но вот требования в вакансиях пугают. Ещё собесы на ютубе посмотрел и вообще теперь боюсь соваться в го.
>Язык минималистичный, можно строить веб-приложения начиная с самых основ.
Закон сохранения никто не отменял. Если язык минималистичный, и делать с самых основ - значит писать придётся много. И по ходу дела решать задачи, которые где-то в других средах уже решили.
Плохого в этом ничего нет, но, новичок может быстро устать.
Так что, мне кажется, для начала лучше что-то другое.
Пыха - это если надо быстро найти работу и чтобы было на что жить (хотя, высоких зарплат не жди). Но, и сам язык и практики программирования на нём - далеки от идеала. И быдло-коммьюнити тоже не добавляет оптимизма.
Так что лучше - питон.
Те же веб-сервисы на Flask делаются ну очень минималистично. Ну и питон - один из лучших на сегодня вариантов чтобы просто научиться программировать. Насчёт работы - это второй вопрос. Но, вроде есть, и больше чем на Го, и без опыта тоже.
Также, на питоне можно писать разные небольшие практически полезные вещи, для чего угодно, буквально. Включая несколько вариантов десктопных GUI (рекомендую wxPython). Количество библиотек - огромно. И если чего-то нет, но, есть на Си(++) - то можно и самому подключить. Ни на одном другом языке такого разнообразия возможностей не будет.
И перекат с питона на го - это довольно распространенное явление, насколько я понимаю. Точнее, наверное, не перекат, а расширение зоны комфорта, лол.
А Java?
Добавлю ещё, что огромный плюс Го - это то, что в результате компиляции получается 1 бинарник, большой, но без зависимостей.
А с версии 1.16 в него можно также встраивать все нужные статические ресурсы - html, css, js, картинки и т.п.
Т.е. получается 1 файл, который можно ставить на голую систему (в голый контейнер), который быстро стартует и жрёт относительно мало памяти. Это очень хорошо для облачного деплоймента. И ради этого люди мучаются и терпят, лол. Т.е. мотивации не новичковые, а чисто взрослые и энтерпрайзные.
Нет, это не то. Это сейчас чистый сервер-сайд.
С довольно высоким порогом вхождения.
Т.е. чистый энтерпрайз.
Нельзя писать скрипты, мелкие утилиты и т.п.
Т.е., если ты учишься на джаве - вознаграждений по ходу дела ты почти не получаешь. На питоне же - постоянно положительная обратная связь.
Чем го лучше ноде.жс?
И в итоге всё равно во время деплоймента идёт сборка из репозитория :/
Ноде в 30 раз медленнее.
Ничем, продолжай работать на ноджс
Всё так. Пишу на питоне и некоторые части делаю на го.
Почему не перекатишься на Go?
На го долго писать
1. Так удобнее
2. Дженерики есть
3. У него в метаданных есть оригинальный тип, который ты не можешь поменять, но спокойной конвертировать в него получится
4. Дженерики опять же есть
3. Да, вот только когда тебе приходит hui_mocha: interface{}, то как ты поймешь какой набор возможных типов там спрятано?
Любой статический язык без вменяемого ADT жрёт говно.
Ну в пыхе, жс и питоне как-то же понимают вот уже лет 30?
Это же программа, у неё есть какая-то логика, оно же всё не из воздуха берётся?
Если бы сразу (без дженериков) додумались как-то реализовать comparable и прочее подобное, то и дженерики делать бы не пришлось. Ибо полезность их в таком языке довольно сомнительна, тут я согласен с Робом Пайком. В Си вот нет дженериков, и как-то похуй.
>В Си вот нет дженериков, и как-то похуй
На самом деле не похуй, знаю кучу сишников которые таскают с собой самописные либы что бы большую часть говняка заново не реализовывать из проекта в проект. Но сишка древний язык со своим ограниченным скоупом применения и не пытается казаться средством для создания джесономешалок игнорирующие достижения других языков созданные за это время.
> джесономешалок
Ну, в этом деле хороший рефлекшн решает, а не дженерики.
А с этим в Го всё в порядке, насколько я понял.
Вообще, им бы вот эту вот конструкцию - "interface{}" - назвать бы как-то по-другому, например "any", и всё бы сразу стало выглядеть гораздо приличнее. Слова имеют значение.
Если что - у меня в ежедневной работе ехал дженерик через дженерик, т.к. джава и тс. И рефлексия через рефлексию, т.к. генераторы кода и сериализация. Так что предмет разговора мне понятен.
В го есть any. any - это алиас interface{}
В 1.17 - нету.
Видимо, добавили вместе с дженериками.
Видимо, добавили вместе с дженериками.
А, нет, таки есть.
У меня просто сейчас старый Го-плагин стоит в Идее, и он не понимает any, но, код компилируется и работает.
>в Идее
Чому не Goland?
Даун
> goland
> ide
Не ругайся, няша.
>Любой статический язык без вменяемого ADT жрёт говно.
Ну, что сделать, тогда все жрет говно.
Нормальные АДТ только в хаскеле и других языках с типовой системой Хиндли-Милнера, если еще всякие попытки типа std::variant в плюсах но это треш с отсутствием строгих гарантий и запредельная дрочка SFINAE, поэтому гошный any это не самое худшее что может быть.
Зачем кстати все эти голанды пайчармы пхпштормы и прочее если для идею буквальное любой плагин кроме с++ есть?
Потому, что я, в основном, пишу на java, ts, js.
И идея с плагином go == goland.
Я даже специально смотрел ответ на этот вопрос на сайте JB.
И там официально написано, что разницы нет вообще никакой.
Кроме того, что некоторым нравится меньше клаттера в интерфейсе ide, и им удобнее специализированный интерфейс под конкретный язык. Но, я старый полиглот, мне похуй абсолютно. И даже лучше, когда всё сразу под рукой.
Ой, блять, не начинай, клоун.
Вскод - ненужная хуйня.
А почему ты 1.17? В дебиане 1.19, в убунте лтс вроде 1.18, как можно умудрится встрять именно на 1.17?
>Вскод - ненужная хуйня
Ну ты же не пробовал в нем работать.
мимо
чтоб у ИДЕхочушпанов больше иконок на рабочем столе было. нахуя еще?
Потому, что плагин старый, и не поддерживает дженерики.
Которые мне прямо сейчас не нужны совершенно для текущего проекта.
А плагин старый, потому, что идея сейчас старая стоит. А почему идея старая - это долго рассказывать.
Как-то двусмысленно получилось.
Дженерики сейчас не нужны, да. Но, если использовать сдк с дженериками (1.18+) то плагин показывает ложные ошибки в некоторых местах кода. И при просмотре исходников стд либы тоже.
Как-то двусмысленно получилось.
Дженерики сейчас не нужны, да. Но, если использовать сдк с дженериками (1.18+) то плагин показывает ложные ошибки в некоторых местах кода. И при просмотре исходников стд либы тоже.
Он пробовал - не осилил.
Забавно видеть как кто-то в го готов тратить 60% времени на написание шаблонного кода, но не готов потратить минут 10 на настройку вскода.
А как мне проводить рефакторинг в вскоде? Он просто не умеет в него, ну в плане… совсем
А в голенде одну кнопочку нажму, и у меня сразу сигнатура функции поменяется, все само и все автоматизировано, оно мне даже строчки поменяет при моем хотении, или рефакторинг переоценен и его вообще не существует?
После голенда вообще не могу пользоваться вскодом, слишком мало функционала, который не расширяется ни одним плагином
VS Code - это текстовый редактор с плагинами.
Goland - это IDE. С большой буквы. Точнее - с трёх.
Что тут обсуждать вообще?
Хотя, кому-то и Vim - IDE.
Начинайте форсить, а то вскод - это как-то мелко.
Уверен, у кого-то возникнет вопрос: «Зачем в 2021-ом пользоваться -vim- neovim, когда есть замечательный Goland?». Я до какого-то времени сам пользовался только продуктами от JetBrains, но вот уже более 1.5 лет пишу исключительно в vim.
Основной причиной для моего перехода с Goland стала его прожорливость. Отдавать по 3-4 Гб программе, которая просто подсказывает мне названия методов, запускает тесты и реализует «Go to definition», очень расточительно. Вкупе с непонятной политикой индексации проекта, когда у тебя в момент взывают куллеры, а батарейка на глазах тает, привело меня к vim.
https://nikgalushko.com/post/vim_as_golang_ide/
Мастер-класс от Никиты Галушко
https://nikgalushko.com/about
Так бы и сказал что не осилил. Вскод это всё умеет.
Кроме бэкенда, что еще хорошо делать на Go?
Говно
Утилиты командной строки, например.
А что бы тебе хотелось?
Реально раздражает то, что это ваше Го создавалось безо всяких мыслей о больших проектах.
С инкапсуляцией - полная жопа.
Если у меня есть енум, то это, блять, не енум, а просто набор констант в неймспейсе пакета. Т.е., глобальных, по сути. Ну что это за хуйня, блять? Как такое можно было родить в 21 веке, это уму непостижимо.
Причём, сделать константу структурой (литералом) - нельзя, пиздец идиоты.
Это-то почему нельзя, с хуя ли это "не константа"?
И вот у меня есть три константы состояния записи - EntryAdded, EntryChanged, EntryDeleted, в пакете zalupa. И пиздец - создать в этом пакете функцию с таким именем я уже не могу. Это просто какой-то позор.
С инкапсуляцией - полная жопа.
Если у меня есть енум, то это, блять, не енум, а просто набор констант в неймспейсе пакета. Т.е., глобальных, по сути. Ну что это за хуйня, блять? Как такое можно было родить в 21 веке, это уму непостижимо.
Причём, сделать константу структурой (литералом) - нельзя, пиздец идиоты.
Это-то почему нельзя, с хуя ли это "не константа"?
И вот у меня есть три константы состояния записи - EntryAdded, EntryChanged, EntryDeleted, в пакете zalupa. И пиздец - создать в этом пакете функцию с таким именем я уже не могу. Это просто какой-то позор.
Ты что, это же го его использует гугол, как ты смеешь так говорить про него
>создавалось безо всяких мыслей о больших проектах.
Для них и не создавалось.
Ну, конкретно, про константы я немножко подумал, и понял, почему так сделано. Всё в угоду скорости компиляции и минимальному потреблению ресурсов в рантайме.
Вообще, большинство сомнительных решений в Го имеют вполне разумные объяснения.
Но, большие проекты делать на таком языке действительно не очень удобно. И самый правильный путь - инкапсуляция в мелкие вложенные пакеты. И да, это будет не совсем идеоматический Го.
Тут, опять же, есть 2 стула стиля - либо пишем без ide, либо - с хорошей ide, джава-стайл. Идеоматический Го (см. стандартную библиотеку) очевидно рассчитан на вариант без ide.
Но, писать большие проекты без ide - это мазохизм. А если с ide - то надо таки писать немножко в стиле джавы, в смысле разбиения кода на части. Нету классов - значит делать кучу мелких пакетов, и играться с public-private (экспорт-не экспорт). И с ide так будет гораздо удобнее и писать, и читать.
Сделать вещь и потом придумать для него объяснение - это и есть тот самый говей
Ну, я это понимаю так, что сначала сделали простой, но эффективный (!= удобный) язык из говна и палок. А потом начали улучшать.
И это было ошибкой. Говно и палки-то никуда не денешь. Не надо было модули-шмодули, дженерики-хуерики и прочее добавлять. Не масштабируется - ну так и нехуй масштабировать.
Алсо, вот тут чел выдал такой длинный конкретный прогон про Го:
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
И, среди прочего, пишет какой ценой делается разработка больших проектов в крупных компаниях:
Go lets you whip something up quickly, but making the result "production-ready" is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all.
И, несмотря на это, всё равно делают хуйню.
Так что - простой бекенд и утилитки - это самое то.
Для всего остального есть джава.
С другой стороны - вот сейчас надо одну утилиту сделать.
Которая тянет данные по одному протоколу из одного места, и потом заливает по другому протоколу в другое. Преобразуя и фильтруя по ходу дела.
У меня есть версия на перле, которой года 3, но, она не соответствует новым реалиям.
И можно или доработать перловую версию, или переписать на питоне, или написать с нуля на Го.
На Го я до сих пор ничего кроме разных хелловорлдов не писал. А на питоне и перле - написал много разного полезного. Поэтому, казалось бы, ответ очевиден.
Но, делов в том, перл немножечко утомил своей необычностью. Вспоминать его каждый раз просто надоело. А большая любовь к питону осталась в далёком прошлом, и нехуй его ворошить.
В итоге - посмотрев либы, сделав несколько примеров, и т.п. - решил делать на Го. И уже сделал изрядный кусок. Сам не ожидал.
И могу сказать, что несмотря на все обозначенные недостатки - язык довольно приятный. Особенно, при наличии хорошей ide, которая сильно ускоряет эксперименты.
Нет не так. Го придумали буквально на коленке в попытках улучшить и оптимизировать гугол. В нём очень много странных и недоделанных решений.
Я вообще хз почему его начали распространять куда-то за пределы. Его максимум - микросервисы для систем наподобие гугла. Всё.
Десктопные гуи и прочие нейронки можно сделать и на го. Можно вообще это всё сделать на чистом ассемблере, так будет ещё быстрей работать. Это очень неудобный язык для разработки больших проектов, а уж сколько историй про то как в кубике вертятся стопитсот микросервисов, когда один наебнется - наебнутся и все остальные - просто не счесть. Почему микросервисы? Потому что их гугол использует, их нельзя обижать и вообще добейся.
>историй про то как в кубике вертятся стопитсот микросервисов, когда один наебнется - наебнутся и все остальные - просто не счесть
Го - сложный язык, он для тех кто умеет программировать. И когда на нём начинает писать какая-нибудь вчерашняя пыхоблядь с физфака да, это Тузов, то получается то, что получается.
А микросервисы - пиздецки сложная тема. И когда их начинают пихать куда надо и куда не надо под предлогом "упрощения разработки" - это пиздец.
Короче - время дураков. Впереди нас ждёт ещё много интересного.
Писать шаблонный код из раза в раз это не "уметь программировать", го не оправдать этим. На но может пимать даже джун, просто он тратит кучу времени на написание этих шаблонов, а мидл уже копипастит его из существующих проектов.
>Пыха - это если надо быстро найти работу и чтобы было на что жить (хотя, высоких зарплат не жди). Но, и сам язык и практики программирования на нём - далеки от идеала. И быдло-коммьюнити тоже не добавляет оптимизма.
Чиво блять... на пыхе зарплат высоких тоже дохуя
Я не про оправдания, а про то, что язык с кучей подводных камней.
Я в курсе.
Но, речь шла про конкретного вкатуна.
Вряд-ли он мог бы рассчитывать сразу на высокую зарплату.
А ну бля, это да. Вкатунам платят 20к, базару нет.
Считай на РНР хотя бы 20к будешь получать, а на го вообще без денег сидеть в надежде, что кто-то сжалится и возьмёт на работу.
В общем, пообщался с нужными людьми и понял, что вкатиться в го можно, но либо ты москвич и идёшь работать в офис, а если не москвич, то должен накручивать опыт. Сейчас оптимальной накруткой считается 2 года. Вопросы к собесам давно уже слиты и можно тупо вызубрить. Не получится ответить на первых собесах, к дцатому уже будет как от зубов отскакивать. Так что вкатиться в го возможно, не слушайте местных нытиков.
>а уж сколько историй про то как в кубике вертятся стопитсот микросервисов, когда один наебнется - наебнутся и все остальные
это просто неправильный коммунизм
func (h *Hui) Ololo [T ~string | ~int] Pizda(zalupa T){}
Почему в методах нельзя использовать дженерики блять?
Почему в методах нельзя использовать дженерики блять?
Ахах, ебать
Правильный вопрос - почему нельзя объявить новые переменные типа на уровне метода.
Ну, вообще "методы" в Го не такие, как в джаве. Дактайпинг и всё такое.
Скорее всего, это как-то связано с тем, как делается поиск метода. Говорят, что дженерики и так немножко тормозят. А с таким сильным колдунством тормозили бы не немножко.
Короче, не еби мозги, делай функции в таких случаях.
Оно и более осмыленно будет, т.к. тут появляется тип, не связанный с базовым типом (метода), и это, как бы, намекает нам, что эта операция - что-то отдельное.
Опять пользователи сами додумывают объяснение почему го такой.
Вот в данном случае, как раз, нет.
В Го _нет_ ООП.
Методы - это _не_те_ методы. Оно местами похоже, но не то.
И это не какое-то "недоделанное ООП", это вообще не ООП.
И есть куча постов в интернетах, где люди пытаются (в силу инерции мышления) делать какие-то вещи методами, и не могут, по причине "ограничений языка". При этом функциями это решается легко и просто.
Не перестаёт удивлять, как гошники записывают отсутствие чего бы то ни было в достоинства языка, а нежелание строчить бессмысленные бойлерплейты в инерцию мышления.
Ты, похоже, пишешь на каком-то чудесном языке, совершенно лишённом недостатков.
Не секрет на каком?
В ассемблере вон вообще ничего лишнего нет, а работает быстрее чем го.
Кто нибудь перекатывался из жабы на го? СтОит того, нет? Есть работа на голанге? Заебала она знатно, но как то сыкотно.
Чем именно заебала?
А то может получиться так, что го заебёт тебя по-настоящему.
А куда обычно перекатываются из Go?
На завод
В 🍊 или 🥗 что ли? Почему именно туда?
В джаву и си🥗 имелось в виду
Мда. Кто эту автозамену придумал.
Я не знаю.
Некоторые, особо утомлённые - в 🎁.
🎁 - это такой анти-го. Причём, в плохом смысле.
Кто-то, блять, поел несвежих мандаринок.
Имелся в виду r'u's't.
Вот вам ребус
💩'''
💩'''
дж(ава)?
Да просто не нравится и никогда не нравилась. Ооп это ебанутое, какие то аннотации блять, скрытое поведение, аспекты, нихуя не понятно. Спринг этот вонючий повсюду.
В голанге пусть и многословно, но всё понятно, как книжку читаешь.
Мне ещё нравится питон, они с голангом как будто из одного мира) Но страшно уйти на миску риса и похлопывание по плечу.
Тут ещё такой момент - я всех наебал и вкатился в ит, почти три года делаю вид что умею кодить. А по факту просто макака быдлоБелый Медведь с курсов. Возможно мне просто кажется что в другой тарелке хрючево вкуснее.
Где можно почитать про структуру проектов в плане папочек? Типа там всякие Entity, Repository, Service и т.п.
Что вообще делают интересного на Новогодняя ночье кроме перекладывания данных из запроса в бд и из бд в ответ?
Я понимаю что что-то делают, но ничего в голову не идёт.
Я понимаю что что-то делают, но ничего в голову не идёт.
Что-то для чего мне был бы акшули нужен Новогодняя ночь сложнее серверных функций некста.
Переписывают сайты с РНР на го, чтобы РНР быстрей умер
А могли бы на некстжс.
Некстжс такой же кал как и РНР
Да, но я его уже знаю. Хочу в го вкатиться с чем-нибудь чего некст не делает.
>Ооп это ебанутое, какие то аннотации блять, скрытое поведение, аспекты, нихуя не понятно. Спринг этот вонючий повсюду.
То, что ты перечислил - не имеет никакого отношения к ООП.
Спринг, АОП, DI - это рак, который убивает д'жаву.
Когда-то всё это было прогрессивно. Но, затем дураки (как всегда) не смогли вовремя остановиться. Чудовищные нагромождения аннотаций, за которыми не видно мысли - это пиздец.
Пи'тон - да, хорош. Но, в нём сейчас происходят примерно те же процессы. И по тем же причинам - дураки оЗаяц-белякевают.
Голанг - тоже хорош, и да, чувствуется идеологическая общность с пи'тоном, но, язык своеобразный, мягко говоря.
>почти три года делаю вид что умею кодить.
Погугли "синдром самозванца".
Вообще, если ты хочешь стать более лучшим Белый Медведьом - не надо учить голанг. Посмотри в сторону Scala и FP. Это тебе поможет подняться над собой.
Есть прекрасная книга Functional Programming in Scala. Это не столько про скалу, сколько про фп вообще.
Можно первое издание, второе - под новую скалу, не факт, что это нужно. Есть также Functional Programming in Ja'va - тоже весьма духоподъёмно. Но, на скале код короче и выразительнее, плюс - есть специальные фп-конструкции.
Что за долбоёб уродует посты?
Это зачем? Чтобы тут в новый год народу было поменьше или что?
Это зачем? Чтобы тут в новый год народу было поменьше или что?
https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/
Там же ссылка на Новогодний Выпуск и плейграунд.
Основные идеи:
- экзешники в /cmd
- то, что не должно импортироваться снаружи - в /internal
Ещё могу добавить, что то, что _должно_ импортироваться снаружи - принято помещать в /pkg
Внутри папок cmd, internal, pkg - папки пакетов. Или просто файлы, если не хочешь выделять доп. пакеты. Тогда имя пакета в этих файлах будет именем основного пакета (модуля). Или main - для экзешников в cmd.
Если у тебя свой проект, и им никто со стороны пользоваться не будет - internal и pkg не нужны.
Вообще - можешь делать такую структуру, как хочешь.
Главное - другой пакет = другая папка. При этом родительская папка значения не имеет.
Т.е. package zalupa может быть в папке myproect/foobar/zalupa.
Ещё можешь посмотреть вот это:
https://go.dev/doc/modules/layout
А то, что тебе посоветовали выше () - это немножко перебор.
>чувствуется идеологическая общность с пи'тоном
Где ты эту общность усмотрел, если не секрет? У меня пока прямо противоположное ощущение, что Го забивает большого толстого хуя на какую-либо общность с современными технологиями и вообще на весь немалый прогресс в области языков за последние 20 лет.
>Добавлю ещё, что огромный плюс Го - это то, что в результате компиляции получается 1 бинарник, большой, но без зависимостей.
>А с версии 1.16 в него можно также встраивать все нужные статические ресурсы - 🕛, 🕛, 🥂, картинки и т.п.
>Т.е. получается 1 файл, который можно ставить на голую систему (в голый контейнер), который быстро стартует и жрёт относительно мало памяти.
Да всем ПОХУЙ на количество файлов. Ты во время сборки все упаковал в образ и все. Время старта тоже такой себе параметр, если у тебя не амазон лямбды, где тебя ебут долларом за каждую секунду старта - то тоже похуй. А все сэкономленные центы ты отдашь в виде зарплаты Белый Медведьам, которые будут по много раз переписывать один и тот же шаблонный код.
Требования к специалисту в Go-Белый Медведьотке:
junior
- умение писать скрипты;
- Белый Медведьотка приложений на основе шаблонов проектирования;
- знание 🍊, 🕛, 🕛, Linux;
- опыт работы с веб-сервисами REST, микросервисами;
- знание Git;
- опыт в DevOps.
middle
- Go (желательно с различными фреймворками);
- 🥂 (со знанием одного из Хоровод-фреймворков: Vue, Angular или React);
- 🕛5 и 🕛;
- Опыт работы с базами данных SQL и NoSQL, такими как PostgreSQL, Redis, MongoDB, RabbitMQ, Kafka;
- Понимание принципов контейнеризации, опыт работы с Docker и Kubernetes;
- Опыт интеграции с API сторонних Web-сервисов;
- Умение писать тесты;
- Знание REST, HTTP, 🥂ON;
- Опыт участия в highload-проектах, создания масштабируемых решений;
- Знание микросервисных архитектур;
- Опыт Белый Медведьотки с использованием таких языков, как 🍾, 🎄, Perl, Typescript, Node.🥂 и т. д
senior
- 5+ лет профессионального опыта работы со сложными серверными веб-сервисами;
- 5+ лет опыта Белый Медведьотки программного обеспечения;
- 2+ года опыта в Белый Медведьотке программного обеспечения на Golang;
- Опыт Белый Медведьотки API (GraphQL / gRPC / REST);
- Опыт Белый Медведьотки сервисно-ориентированных решений;
- Опыт построения высоконагруженных систем.
junior
- умение писать скрипты;
- Белый Медведьотка приложений на основе шаблонов проектирования;
- знание 🍊, 🕛, 🕛, Linux;
- опыт работы с веб-сервисами REST, микросервисами;
- знание Git;
- опыт в DevOps.
middle
- Go (желательно с различными фреймворками);
- 🥂 (со знанием одного из Хоровод-фреймворков: Vue, Angular или React);
- 🕛5 и 🕛;
- Опыт работы с базами данных SQL и NoSQL, такими как PostgreSQL, Redis, MongoDB, RabbitMQ, Kafka;
- Понимание принципов контейнеризации, опыт работы с Docker и Kubernetes;
- Опыт интеграции с API сторонних Web-сервисов;
- Умение писать тесты;
- Знание REST, HTTP, 🥂ON;
- Опыт участия в highload-проектах, создания масштабируемых решений;
- Знание микросервисных архитектур;
- Опыт Белый Медведьотки с использованием таких языков, как 🍾, 🎄, Perl, Typescript, Node.🥂 и т. д
senior
- 5+ лет профессионального опыта работы со сложными серверными веб-сервисами;
- 5+ лет опыта Белый Медведьотки программного обеспечения;
- 2+ года опыта в Белый Медведьотке программного обеспечения на Golang;
- Опыт Белый Медведьотки API (GraphQL / gRPC / REST);
- Опыт Белый Медведьотки сервисно-ориентированных решений;
- Опыт построения высоконагруженных систем.
Да много чего, навскидку: компилятор языка для описания множеств с лексером, парсером и AST-деревом, разные число/лого-дробилки и большие ин-мемори хранилища для одновременного отслеживания состояний 10kk+ сущностей. И все написано на go, и по сути является такой же прослойкой меду базой и http-реквестами, только в боди POST-запроса будет лежать код твоего языка или параметры для конфигурирования файла лицензии.
По опыту скажу, го в плане написания сложных велосипедов не сильно отличается от других языков, все инструменты для этого есть.
>junior/middle
>умение, знание, кучи технологий
>senior
>ОПЫТ 2+ года, ОПЫТ 5 лет, стаж 10 лет ОПЫТ ПОПЫТ ААААА
Ну как бы все понятно, с сеньки требуют только трудовую книжку, на остальные знания всем насрать. А Зайчишку/Эльфа прогонят по всем паттернам, так еще знания ноды и реакта в добавок спросят. ЗАЧЕМ?
>забивает большого толстого хуя на какую-либо общность с современными технологиями и вообще на весь немалый прогресс в области языков за последние 20 лет.
Так ведь и п'итон...
>все инструменты для этого есть.
Интересен один инструмент, каким образом происходит отладка коммуникации между микросервисами, что есть для мониторинга коммуникации? И вообще микросервисная Белый Медведьотка, в деталях? Вот пишу я сервис, которому надо дёрнуть данные из других сервисов, нужно убедиться что код работает, мне на локальной машине поднимать в дев-среде контейнеры с кучей сервисов? А если там что-то не то, как посмотреть что внутри другого сервиса, лезть в запущенный контейнер, ставить там точку останова?
Спасибо анончик, буду изучать.
Я вообще подозреваю что мои пиздострадания от недостаточного погружения в тему. Все языки говно и просто перекладывают биты, а я ищу какой то чудо-инструмент который позволит быдлокодить не изучая матчасть(
Каждый новый год такая хуйня, Новогоднее Настроение.
хуй, пизда, двач, тред, кун, тян
>Все языки говно и просто перекладывают биты
Чем более производительный и низкоуровневый язык тем в нём больше бестолковой хуйни, просто снизь планку и откроешь целый пласт скриптовых языков, которые по своей сути приближены к обычному человеческому и сфокусированы на решении бизнес-проблем, а не на конфигурации вычислительной машины ради дрочки наносекунд.
Если не получится с го, то пойду на РНР
Возьми хорошую книжку по микросервисам (и вообще, и на го) - и почитай. Их есть.
Отладка коммуникаций - через хттп дебаг прокси.
Ошибки и прочее - в лог - в файлы или в лог-сервис.
Можно и в контейнер залезть, и точку останова поставить.
И это всё не специфично именно для микросервисов.
Какой каркас вы используете для го?
Ёпта у тебя микросервисы работают по какому принципу? Событийно-ориентированные с event bus'ом в роли кафки? Если так, то можно просто повесить слушателя на все события. А внутри там просто будет логгер. Это самый простейший способ.
Либо можно у кафки просто включить трейсер, режим дебага
деревянный
Вот сейчас мне кусок кода из 5 совершенно невинных строк стабильно выдаёт "panic while printing panic value". На ровном месте вообще. Причём, код (сетевой запрос по протоколу X) работает, и делает, что должен. Это какая-то ложная паника.
В трейсе - только вызовы рантайма.
Это не говоря о том, что я уже за эти несколько дней успел уже немножко устать от отсутствия нормальной инкапсуляции в этом чудесном языке и прочих концептуальных проблем. При том, что в целом пишется нормально. Но, есть нюансы. Этакий запашок, если вы понимаете, о чём я.
Думаю, что я эту утилиту, всё таки, на пи'тоне напишу.
Да и по отношению к работодателю так будет честнее, лол.
В трейсе - только вызовы рантайма.
Это не говоря о том, что я уже за эти несколько дней успел уже немножко устать от отсутствия нормальной инкапсуляции в этом чудесном языке и прочих концептуальных проблем. При том, что в целом пишется нормально. Но, есть нюансы. Этакий запашок, если вы понимаете, о чём я.
Думаю, что я эту утилиту, всё таки, на пи'тоне напишу.
Да и по отношению к работодателю так будет честнее, лол.
>Всё в угоду скорости компиляции и минимальному потреблению ресурсов в рантайме.
Если бы их так заботила скорость компиляции, то не делали бы forward declarations и разбивки пэкеджа на файлы. Про рантайм вообще смешно, в том же ❄️ енумы спокойно компилируются в инты и никакого оверхеда. Да что там ❄️, в древнейшем Паскале уже освоили такую технику.
Держу в курсе - нашёл причину.
"panic while printing panic value" - это было просто.
А вот самую мякотку увидел только в дебаггере.
В смысле - печать в консоль не помогала понять, что именно происходило.
Код после if err != nil печатал <nil>. Охуенно, да?
В общем, типичная г'ошная хуйня.
Пытливый читатель может сам посмотреть вот здесь изолированный пример:
https://go.dev/play/p/oFxSY952-YB
Там без паники, правда, просто проверка на nil не работает так, как ждёт наивный чукотский юноша.
И без рефлексии это никак не обойти.
Потому, что пидарасы, вот почему.
А сколько такой красоты в реальном продакшн-коде ждёт своего часа?
Страшно подумать.
Упёрся я в это, пытаясь достать реальную ошибку из-под интерфейса error, который возвращает функция одной либы (а внутри - красота с кодом ошибки и прочим).
Г'ошникам это похуй, потому, что они не обрабатывают ошибки.
В смысле - не делают с ними ничего, кроме обнаружения факта ошибки и получения строки с сообщением. Т.е. не выходят за пределы интерфейса error.
А у меня - наоборот, принято ошибки обрабатывать.
Поэтому - нахуй такое счастье, извините.
Пишите на нём сами, лол.
Добавлю ещё, что это не просто кака-то "особенность" языка, которую надо просто "знать", и всё. Это фундаментальный просчёт в дизайне. Который ведёт к порочным кругам, и к тому, что люди вынуждены нарушать их же собственные best practices. Например, возвращать интерфейс error вместо структуры CustomError, хотя явно рекомендовано принимать интерфейсы, а возвращать структуры. Да и насчёт "принимать интерфейсы" - тоже, как видим, немножко не складывается, лол.
И этот косяк, на мой взгляд, делает невозможным сколь-нибудь серьёзное программирование на этом языке.
И да, теперь я начал гораздо лучше понимать всю ту критику г'о, которую я читал раньше.
Да похуй, на самом деле. Всё серьёзные программы уже написаны.
Пеши исчо
это просто просчёт в дизайне. надо просто "знать", и всё. хз че ты "свою борьбу" высасываешь
Да ладно, это моя первая попытка написать что-то полезное на Г'о.
И я реально охуеваю, как в первый раз.
В принципе, цель make programming fun again достигнута, лол.
Алсо, я тут просветился на эту тему.
Про это много написано весьма противоречивого.
И пришёл к выводу, что это опять не баг, а фича.
Вот только могли бы проверку интерфейса на nil сделать попроще, просто какой-то builtin функцией, чтобы рефлект не подтягивать.
Я имею ввиду фреймвёрк
Использование фреймворков - это не говей.
Как тогда маршрутизировать что-нибудь типа /foo/bar/{id}?
> скриптовых языков
> сфокусированы на решении бизнес-проблем
Что забавно, жабу я использую исключительно потому, что её использует работодатель.
Все околорабочие задачи (распарсить, прочитать и проанализировать, побегать по директориям и т.д.) я решаю на питоне, потому что реальные задачи в нём сделать проще: три высокоуровневых строчки -> запустить -> глянуть результат.
Задачи по фану тоже решаю на нём. Отсюда же интерес к сабжу.
Пиши свой микрофреймворк. Во всех гоуленговых компаниях сделан индивидуальный велосипед. Таков путь.
Мне на ум пока приходит только портянка из кучи if ... else или switch. Потому что тут надо сразу и URL проверять и по какому методу прилетело (GET, POST и т.п.), а может и ещё какую-нибудь фигню проверить в загловке.
Мапу сделай с кейсами. Подними контексты, нет, маршрутизацию. Обычно берут фреймворк спринг и начинают переписывать на гоу. Как настоится, переходим к бизнес логике.
А бины в xml конфигурировать? В го аннотаций же нет
Использование аннотаций - это не говей
>А бины в xml конфигурировать?
Говнокодом разумеется. Говей это писать много кода, на каждый чих.
func init() {
_, _ = di.RegisterBean("weatherService", reflect.TypeOf((services.WeatherService)(nil)))
_, _ = di.RegisterBean("weatherController", reflect.TypeOf((controllers.WeatherController)(nil)))
_ = di.InitializeContainer()
}
Энвоем перекладываешь в нормальный протобуф и работаешь только с протобуфами.
Вообще для быстрого вката есть echo, а вопросы типа такого принято сначала смотреть на awesome-go
Жду когда питон заменит баш скрипты и будет в убунте изкаробки со всеми скоростными либами по типу aiohttp
Да го норм язык если делать на нём небольшие микросервисы. Я хз почему некоторые пишут на нём большие проекты, а потом страдают от количества шаблонного кода.
Он даже для сервисов не подходит, только микро. И при этом не весь проект, а отдельные части связанные через grpc.
inb4 зато быстрей, ну пиши тогда на ассемблере, он ещё быстрей
Он даже для сервисов не подходит, только микро. И при этом не весь проект, а отдельные части связанные через grpc.
inb4 зато быстрей, ну пиши тогда на ассемблере, он ещё быстрей
>пиши тогда на ассемблере
Мало кто может писать на ассемблере быстрые программы. Современные оптимизирующие компиляторы уделывают кожанных мешков в этом плане. Сейчас уже скриптовые языки вроде РНР обзавелись JIT-компиляторами и работают на уровне компилируемых языков, там буквально накладные расходы только на чтение и разбор скрипта, а выполнение уже в машинном коде идёт.
Лично мне в гошке не хватает поддержки десктопных приложений. Было бы прикольно писать один раз код, а потом просто компилировать под все платформы программки.
> init
Почему в мэйн не пихаешь это?
Питон не заменит баш. Даже перл не не заменил, куда уж там питону. Я все три знаю и использую, если что.
Если можно делать большие программы на си, то на го - можно аж с разбегу. Вообще не сравнимые вещи.
Я ещё почитал про это. Как говорят знающие люди - это единственный настоящий косяк в языке.
И абсолютно все на это натыкаются, поначалу.
Один дед даже багрепорт им по этому поводу им заебенил, и устроил срач, лол.
Но, я, по зрелому размышлению, даже косяком это не считаю.
Го - это другой язык. И null в нём понимается совершенно иначе, чем в си или джаве.
Но, книги и руководства не акцентируют на этом внимание.
Также, и тема интерфейсов разъясняется недостаточно, т.е. акцент обычно делают не на том. А надо подчёркивать, что интерфейс - это не "тип", не "контракт" (как все привыкли), а просто значение. Которое, иногда, инициализируется довольно необычным способом.
И да, им надо было сделать встроенную функцию для проверки интерфейсов на nil.
У Донована и Кернигана это подробно разбирается. Даже таблица нарисована, что в интерфейсе хранится 2 значения, а сравнивается только одно.
>перекладываешь в нормальный протобуф и работаешь только с протобуфами.
Язык протобаф, язык ерр не нил.
С чего ты Прочитал что ассемблер быстрее? какой-нить gcc/g++ намного лучше тебя оптимизирует асм
Так в примере было.
>И да, им надо было сделать встроенную функцию для проверки интерфейсов на nil.
Во первых им надо было слать нахер Пайка. А во вторых нормально реализовывать интерфейсы.
Нигде больше такой хуйни нет, а тут есть. Вначале НИНУЖНО, а потом БЛЯЯЯЯ, А КАК ТЕПЕРЬ СДЕЛАТЬ?. И вот такой факап дривен девелопмент от версии к версии. Вначале пустой error в котором кроме текста нихера нет, а потом давай наворачивать Unwrap и прочий is/as.
Напомню, что go - это c для plan9 и в C обработка ошибок выглядит примерно так:
if res < 0 {
fprintf(stderr, "%s: %s\n", s, strerror(errno));
exit(1);
}
И не говори.
А ещё есть контекст, который на самом деле не контекст, и использовать его именно как контекст - не рекомендуется, разве что в крайнем случае, и осторожно, лол.
Говно и палки, как и было сказано.
Я уже на питоне начал эту свою утилиту писать.
Не то, чтобы не осилил, там, скорее, задача ближе к скрипту, чем к самодостаточной утилите. Надо, чтобы и админ мог поковырять, в случае чего. На го пришлось бы толстый слой конфига намазывать, а нету ни времени, ни сил, ни желания.
>и в C обработка ошибок выглядит примерно так
Вот только С это язык для написание низкоуровнего кода под все платформы включая эмбед вообще без ОС и 64к памяти.
А с другой стороны Говноланг с жирнючим рантаймом, бинарниками в десятки мегабайт, сборщиком мусора, ебанной политикой аллокации данных. ВНЕЗАПНО стал переживать, что эксепшены это оказывается накладно с т.з. перформанса.
>А во вторых нормально реализовывать интерфейсы
Зачем нам ещё один 🎁?
А ты сравни количество проектов на си и го с питоновскими. Писать большие программы можно на чём угодно, тут вопрос - как быстро и удобно
Потому что иначе 🎁 превратится в 💩
да эксепшны просто хуета по сравнению с ошибками-значениями. а с учетом перформанса так вообще нахуй
>range-over-func
Как думаете, взлетит?
Эксперемент запилили, в 1.22rc уже можно попробовать
Как думаете, взлетит?
Эксперемент запилили, в 1.22rc уже можно попробовать
Им бы то, что есть, до ума довести сначала.
А то вот люди пишут:
Over and over, Go is a victim of its own mantra - "simplicity".
It constantly takes power away from its users, reserving it for itself.
It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness.
It is a minefield of subtle gotchas that have very real implications - everything looks simple on the surface, but nothing is.
https://fasterthanli.me/articles/i-want-off-mr-🍾🍾🍾s-wild-ride
Это примерно то же, что я сам почувствовал буквально сразу же после первого знакомства с го.
И вот будет ещё одна (весьма непростая) фишка, реализованная с таким вот подходом.
Бля, надо сваливать отсюда.
Пидоры уже и ссылки портить начали, пиздец, дегенераты.
Там слово g'o'l'a'n'g замазано говном, если что.
Пидоры уже и ссылки портить начали, пиздец, дегенераты.
Там слово g'o'l'a'n'g замазано говном, если что.
>Как думаете, взлетит?
Как обычно высрут недоделанную хуету.
Почему range только от 0 до n-1? Нельзя сделать как в нормальных языках для произвольного диапазона? Нахуя высирать yield с непонятной семантикой? Вам всего-то нужен простой интерфейс с двумя функциями HasNext() Next() или даже вообще с одной.
> Нахуя высирать yield с непонятной семантикой?
Как в 🐍е и 🥂 же, только там это ключевое слово, а тут явный вызов колДети в костюмах снежинока. Единственное что непонятно как с ошибками быть, разве что в структуру сохранять, а итератор методом делать
> Вам всего-то нужен простой интерфейс с двумя функциями HasNext() Next() или даже вообще с одной.
Так логику итератора сложнее писать/читать
пи то не и жыесе
Там тупо str_replace() стоит и заменяет символы
>Вот пишу я сервис, которому надо дёрнуть данные из других сервисов, нужно убедиться что код работает, мне на локальной машине поднимать в дев-среде контейнеры с кучей сервисов
У нас для этого развернуто тестовое окружение. И есть интеграционные тесты, которые в тего стучатся. Вроде никаких секретов нет. Локально все сервисы не разворачиваем, так как это охуеть как сколько телодвижений нужно сделать, да и к тому же много сервисов, куда ходим мы, или откуда ходят к нам, написаны не нашей командой и не нашим отделом вообще. Поэтому тут только интеграционные тесты спасают.
В яндексе свой S3 написан практически полностью на го.
Ну и вообще всякие инфра инструменты вроде самописной графаны у них тоже на го/❄️ написаны.
А бизнес-логика на питухоне, у них весь код недавно утёк, можно скачать с торрента, посмотреть.
Ну бизнес логику на питухоне самое то писать
>Так логику итератора сложнее писать/читать
Вот эта нечитаемая eбaла: func на func, через func понятнее? Это г0вн0 нечитаемое! Понятнее в пит0не, где компилятор делает всю магию, но сам код и правда очень простой и читаемый.
То что они предлагают, это засунуть forEach() внутрь цикла. Нахуя - решительно непонятно, его можно использовать и так. Более того это требует корректно обрабатывать все варианты управления циклом, о проблемах с чем они и сами пишут.
>Today, range makes the decision of how to iterate based only on the underlying type of the range variable, not its methods. In fact, no syntax in Go ever makes use of specific methods. The closest exception is the predefined error interface, but even that never has its Error method called by any Go syntax. People often ask for operator methods, and we have avoided doing that for the same reason: we don't want to privilege specific methods. It is of course possible to create a language structured around such methods (🐍 is one example), but Go is not designed that way. Nothing in the Go language invokes specific method names.
В результате вместо
for i, x := range myTree {
придется писать
for i, x := range myTree.DFS() {
Оxуеть какое удобство.
А еще функция итератора может проигнорировать то, что возвращает yield и тогда, у тебя перестанут работать break и прочее. Но это пока конечно, а потом-то они обязательно
>we will make sure the check happens, with a panic on misuse, without noticeably hurting performance.
with a panic и without noticeably hurting performance звучит очень многообещающе.
В общем как обычно замутят какое-то половинчатое решение, которое будет работать через Тулуп. Таков путь.
Как выучить гошку, чтобы пройти через круги ада Стишок на табуреткеов с душными Волшебниками, которые будут гонять по кишочкам с усмешками, а потом на лайв-кодинге и вовсе унижать ебанутыми задачками с нечёткой постановкой? https://youtu.be/GD0iHLucYdU
Вот взять видрил, чел уже реально работает сенькой много лет, постоянно пишет на го, а его по сути опустили на Стишок на табуреткее, как Зайчишку. А как тогда "с улицы" туда попадать?
Мне кажется, единственный вариант — это как-то перескочить с 🎄и внутри компании.
Вот взять видрил, чел уже реально работает сенькой много лет, постоянно пишет на го, а его по сути опустили на Стишок на табуреткее, как Зайчишку. А как тогда "с улицы" туда попадать?
Мне кажется, единственный вариант — это как-то перескочить с 🎄и внутри компании.
Обьясните плз что такое бизнес логика и чем он отличается от кода. Тип просто сценарий обработки? Получить данные, сделать 1, потом 2 потом 3 и закончить, это бизнес логика?
> Вот эта нечитаемая eбaла: func на func, через func понятнее? Это г0вн0 нечитаемое!
Если введут, то будет встроенный/в стандартной либе типы, можно будет их использовать и не вникать каждый раз
type Seq[V any] func(yield func(V) bool)
type Seq2[K, V any] func(yield func(K, V) bool)
Главное саму суть понимать - yield-нуть значение - значит вызвать тело цикла с этим значением.
>То что они предлагают, это засунуть forEach() внутрь цикла.
Не всё что коллДети в костюмах снежинок принимает это форич. Оно мощнее, можно генерировать любую последовательность, не только обходить коллекции. Можно генерировать последовательности из других последовательностей, можно писать потоковый код на много проще теперь.
Вон в том же 🐍е на генераторах делают ленивые вычисления и можно результат запроса в дб вычитывать только при рендеренге шаблона и отправке его в соединение, т.е. обрабатывая только одну строку за раз
Это как "бизнес-процесс", в отличие от системного процесса.
Т.е. какая-то логика, имеющая дело не с системными или инфраструктурными объектами, а с объектами предметной области.
И это обычный программный код, как правило.
О, обратно Тузов даёт в туза!
Чувак, не смотри это. Это просто инфоцыганская хуйня.
Эти люди шлюхи, а не Белый Медведьы.
Иначе бы они писали программы, а не торговали еблом в ютупе.
Одно с другим довольно плохо сочетается.
А в чем цыганство? Типа чел раскручивает свои платные курсы? Вроде бы нет. Да и челы, представленные в Голубой Огонёк РАБотают на реальных РАБотах и пишут коды.
Этот "Главэльф много лет" не знает что такое тип-сумма.
Речь шла о том, что yield в Г0вн0 реализции, это нечитаемое г0вн0. Обычный итератор проще, там семантика каждой функции ясна тупо из названия функции. И даже использование его в foreach не вызывает особых вопросов, тупо переписаный for
for iter := collection.Iter(); iter.HasNext(); {
value := iter.Next()
}
Всё! Никакой магии, предельно ясно что будет если: break, continue, break label, panic, return, goto. А то что предлагают авторы г0вна это магия которую будет генерировать компилятор. Для примера расскажи как будет работать возврат значения из функции, учитывая что ты уже внутри двух вложенных функций.
>Не всё что коллДети в костюмах снежинок принимает это форич.
У тебя память как у рыбки, не помнишь вообще о чем идет речь просто триггеришься на слова без контекста. Мы тут обсуждаем охуенную иннициативу улучшения foreach. К0лДети в костюмах снежиноки пока, слава богу, никто не предлагает улучшать.
Ты не видел их на работе.
И не видел, что они пишут. И в каких объёмах.
А чел раскручивает себя и свой к'анал.
Торгует еблом, в самом буквальном смысле.
Видимо, это приносит больше денег, чем то про'граммирование, которое он умеет.
Я тоже не знаю.
Это ты union так обозвал, или что?
>мне на локальной машине поднимать в дев-среде контейнеры с кучей сервисов
У нас для этого развернуто тестовое окружение. При локальном запуске твой сервис роутится автоматом на зависимости в тестовом окружении. Все урлыпорты автоматом прописываются утилитой в генерируемый конфиг. Той же утилитой разворачиваются локальный миникуб и личные зависимости сервиса - очереди/БД. Запускать сервис можно хоть go run/IDE и соответственно дебажить стандартно, всё подтягивается из конфига. Конечно не всегда это катит и мб придется дебажить на проде через логи/метрики, но это редкие случаи.
А если у вас что-то в тестинге упадёт/сломается? Во всех зависимых сервисах пайплайны перестанут проходить и вы не сможете катить правки?
Таков говей
Гове́ть — значит предписать своему телу воздержаться, очиститься и ограничиться в пище.
В чем проблема параллельно работать и раскручивать свой канал? Так многие делают, называется самопиар, может помочь потом с поиском работы или сотрудников.
В данном конкретном Голубой Огонёк () "Стишок на табуреткеедуемый" очень профессионально тычется лицом в микрофон. И вообще, ведёт себя как шоумен. Человек, просто пришедший на Стишок на табуреткеедование, будет вести себя совершенно иначе. Я думаю, это постановка.
Такое же ощущение у меня было и от предыдущего Голубой Огонёк, ссылку постили в предыдущем треде.
Это просто шоу на тему около-программирования.
Вопросы - детские, ответы - детские.
Чтобы неискушенному зрителю (уровня стажёра максимум) было понятно.
Иначе массовая аудитория не будет смотреть.
Пиздец, чтоб просто устроиться на работу Белый Медведьом надо стать известным ютубером и с петпроектами на пару сотен тысяч пользователей.
Не надо в такие места соваться.
Это живо напомнило мне, как в 90-е уборщиц нанимали с высшим образованием. Совчиной всё это попахивает, просто поверх ещё одеколоном побрызгали.
> Вопросы - детские, ответы - детские.
> Чтобы неискушенному зрителю (уровня стажёра максимум) было понятно.
Так мне нихуя не понятно было, ЗАВСТАВИЛО ЗАДУМАТЬСЯ, как говорится, а я уже далеко не стажёр, поэтому и спрашиваю, что надо делать/читать, чтобы это детским казалось.
Извиняюсь, опять вставлю линк с канала Тузова, смотреть не агитирую, сам не смотрел, но кекнул с комментов.
https://www.youtube.com/watch?v=aWP6JIime8w
А вы бы хотели РАБотать с ублюдочным зумером с зелёными волосами?
https://www.youtube.com/watch?v=aWP6JIime8w
А вы бы хотели РАБотать с ублюдочным зумером с зелёными волосами?
>А если у вас что-то в тестинге упадёт/сломается
У нас такое регулярно происходит. А еще регулярно падает тестинг сервисов, куда мы ходим. В итоге большая часть интеграционных тестов просто помечены как необязательные в CI. На них нужно смотреть только если вносишь изменения в код, которые в теории проверяются интеграционными тестами.
>что надо делать/читать, чтобы это детским казалось.
Надо больше читать. По-английски.
А движущиеся картинки смотреть, в основном, с голыми тётками.
Зумер похож на жырную девочку. И дёрганый какой-то. Наверное, от недоёба. У девочек такое бывает. А может месячные, хз.
Комменты - да. А потом поебалися.
Добавлю, что у меня от такого кина совершенно пропадает стояк желание писать на Го. Видимо, подсознательное нежелание становиться таким же, как эти актёры.
В какой слое лучше размещать логику валидации: entity или repository?
./pkg/validator
Валидацию надо делать в том месте, где ты получаешь данные.
И слать их на хуй, если не валидируются. Чтобы тот кто их послал, сразу понял, что его послали.
В репозитории, например, это делать уже как-то поздновато.
Там можно просто делать проверку каких-то инвариантов. Но, это, скорее, про гарантии целостности данных, а не про валидацию.
Ентити конечно.
Смотря что ты валидируешь. Что валидируешь - там и должен лежать вплидатор а не где-то в жопе проекта в отдельной папочке validators
У меня вообще даже изначального желания нет писать на го, я на него смотрю уже лет семь-восемь, всё никак не могу начать, но сейчас уже такое чувство, что если с пыхи не соскочить в ближайшее время то ВСЁ. Но мотивируют только большие зепки гошников, а на сам язык как-то похуй, наоборот, гуглозависимость отвращает.
Почему бы тебе не соскочить с пыхи на джаву, например?
Или на питон (хз как там с работой).
Го - весьма специфический нишевый язык. И он сложный, с кучей подводных камней на каждом шагу (как написал один умный чел - fake simplicity). После пыхи будет Весело на утреннике.
А гугол - да, та ещё хуйня. Они не умеют в юзабилити, о чём бы ни шла речь - системы, программы, библиотеки, языки. Хуй знает, как вообще можно быть настолько последовательными в этом деле.
Го сейчас идёт как бы приложением к пыхе, если ты не в курсе. На него переписываются всякие критичные к производительности сервисы. Джава - хз, в принципе, я думаю что смогу осилить, но хуй знает, с чего начинать. Да и уныло это, опять будет кровавый энтерпрайз с дрочерами на абстракции абстракций и дядюшку Боба. Про фейк симплисити в курсе. Петон - хз, думаю что осилю в два счёта, но там с работой похоже туго, либо надо какую-то нишу искать.
Пыха никуда не денется ещё лет 50, а вот как раз судьба го под вопросом
> Го сейчас идёт как бы приложением к пыхе, если ты не в курсе.
У тебя сложилось такое мнение потому что ты сам пыхер
Ну да, и что? В чём ошибка?
В том, что есть кубы и блокчейн :) сиди дальше синки и круды дрочи.
Экспертно мнение птушника:) очень вкусно, продолжай! Смеемся всей галерой.
И тут ты сейчас взял, и написал в чем он не прав
>кубы
Это девопсы, и там непосредственно с го работы не очень много, на питоне и то больше придется писать скорее всего
>блокчейн
Мерзкая хайпожорская сфера, где базворды меняют друг друга каждый год, недавно там все на Раст усиленно переписывали потому что БеЗоПаСнОсЬ
>>кубы
https://github.com/search?q=operator&type=repositories уже бегу переписывать на питон. Есть конторы (биг Техи), которые делают собственные дистры кубов. Там дохуя работа для прогеров. офк нужно знать девопс и кубы.
>>блокчейн
Нахрюк крепкий! Делай дальше круды на пхп, унтерменш
Можно добавить еще задачи - логи, метрики и етц.
Какой смысл менять язык и делать то же самое.
Так я ж не спорю что они есть, я вообще изначально толкую про перекат в го из пыхи в рамках той же компании. Это и хорошо, что гошка востребована в хайповых отраслях типа блокчейна, можно будет наконец заработать ДЕНЕГ, а не выживать на ссаные 2.5 сотыги. Но сначала надо перекатиться, везде требуют каммерческий опыт. Хотя я и писал один простенький микросервис на гошке, всё равно сквозит НЕУВЕРЕННОСТЬ и тянет по низам ДАННИНГОМ-КРГЮГЕРОМ.
Расслабься и иди на собес в ноунейм контору. Тренировка и раскрепощение. Толку на дачах сидеть и разговаривать с вкатунами, если ты прошел пhп гойду.
>писал один простенький микросервис на гошке
А что делал твой микросервис?
И почему он был только один?
Я уже в "нейм" конторе, КОТВАСЯ. Да, надо сходить, но типа чтоб совсем не опозориться надо же что-то знать/уметь, да?
Клал данные в базу из джейсончика, потом отдавал + сваггер. Практически обычный круд, по сути. Один потому что это было как бы экспериментом, там основная часть людея на сисярпе писала, я на пыхе поддерживал сервис авторизации и еще один сервис с данными. Для эксперимента в рамках "перехода на го" написал вот ето.
С конца октября сходил на 20+ собесов (синьор питухон, хотел на го мидла), законно за щеку взял, нужны только С КАМЕРЧЕСКИМ ПАПЫТОМ.
Я же говорю - это _нишевый_ язык.
В РФ - это только крупные компании, типа авито-хуяндекс и банков, и они могут себе позволить повыёбываться.
Асло, им проще взять ждуном школьника, который дрочит на кино с Тузовым, и отформовать его, чем бодаться с опытным (но не в го) человеком, который привык прогибать ситуацию под себя. Собственно, для этого такое кино и снимают, как я понял.
Думаю, если поискать как следует, то найдётся есть некоторое к-во вариантов, но, зарплата там будет попроще. Что делает эту затею бессмыссленной, если ты не маньяк.
Поэтому, я на это дело пока смотрю как на хобби.
Я думаю, что если этим даунам объяснить, что ты законтрибутил в попенсорс проект, которым пользуются десятки тысяч или сделал свой работающий сервис с закрытым кодом, то они охуеют.
> проще взять ждуном школьника, который дрочит и отформовать его, чем бодаться с опытным человеком, который привык прогибать ситуацию под себя
Так это везде так. Кабанчик хочет быстро, качественно и бесплатно.
Вон, один клоун-бизнесмен хочет рабов на цепи держать, чтоб к восьми утра все в офисе были! https://t.me/bezsmuzi/4972
Если у тебя динамические стенды в кубе это плюс, жрет мало ресов, не надо тратится на доп ноды, также регистри не забивает быстро(да можно настроить чистку) ибо образ весит мало. Также старт сервиса быстрый по сравнению с той же джавой, которая по минуте поднимается...
"Русский IT бизнес", никак не меньше, сука. Не васин, не петин, а прямо вот национальный. Мамкин бизнесмен, офис он снял, ололо.
А в VSC можно как то гошные проги запускать по кнопке, как тот же петухон или жабу, а то заколебало постоянно в терминал мотаться
Всегда через терминал запускаю. Ну либо настрой кнопку на баш
можно.
но с нюансами (или я не разобрался как). смотри, у нас во всех сервисах главный бинарник компилируется из cmd/service/main.go. Я добавил глобальный конфиг для запуска в общий settings.json. Этого хватает в 90% случаев. Бинарники по другим путям запускаю через консольку. Если нужно подебажить, то добавляю конфиг для конкретного бинарника в локальный конфиг для проекта - для этого буквально нужно конфиг скопировать и поменять пути.
// settings.json
{
"launch": {
"version": "0.2.0",
"configurations": [
{
"name": "cmd/service",
"type": "go",
"request": "launch",
"mode": "debug",
"program": "${workspaceFolder}/cmd/service",
"cwd": "${workspaceFolder}",
}
],
},
// ...
}
То есть, в этой чудесной супер-ide для Го нельзя запускать гошные файлы по кнопке? Охуеть.
Goland поставь, там можно.
Хотя, в голанде я сам тоже обычно из терминала запускаю.
Кроме тех случаев, когда делаю отладку.
Дебаггера в чудесном вскоде тоже нет, как я понимаю?
У тебя N бинарей в проекте. Как ты поймешь какой бинарник запускать когда ты нажмешь кнопку в пакете, который во всех из них используется?
Очевидно, нужен какой-то отдельный дропдаун для выбора конкретной main.go. В вскоде его нет, там можно вручную указать путь. В этом и различие - указываешь путь вручную.
Дебаггер есть.
Крч как то через launch.json я разобрался как по F5 и ctrl+F5 делать debug/run, твой способ выглядит как то что похожее, но чет я не вкурил
Дебаг там имеется, насколько он пиздатый пока не проверял. Голанд есть, но я глянул сколько он ресурсов жрет ради программки вычисляющей условно 2+2 и чет грустно стало, пробовал VSC как что то легковесное и маложрущее, но чет подсказывает, что я останусь на жибрейне
> Крч как то через launch.json я разобрался как по F5 и ctrl+F5 делать debug/run, твой способ выглядит как то что похожее, но чет я не вкурил
ровно то же самое, просто глобальное для проектов https://code.visualstudio.com/docs/editor/debugging#_global-launch-configuration
>нужен какой-то отдельный дропдаун для выбора конкретной main.go.
В голенде так и есть. И даже более того, это можно группировать в папки. И выполнять можно что угодно, не только го (скрипты и прочее), и всё это будет в одном дропдауне.
>сколько он ресурсов жрет
Он их совсем не просто так жрёт, всё по делу.
И при увеличении размера программки ресурсов он будет жрать столько же.
Алсо, там какие-то вещи можно отключать, оптимизировать производительность, я никогда не заморачивался (за ненадобностью), но можешь погуглить. В том числе, можно оперативно отключать подсказки и т.п., это экономит.
ну технически в вскоде просто все пунктики дропдауна нужно написать самому в жсоне сначала
Ну, если так, то это не такая большая проблема.
Как вам идея писать код на Go не в Golang и не VS Code, а в Vim?
В нем кто-нибудь работает из известных Go-разрабов?
В нем кто-нибудь работает из известных Go-разрабов?
Как раз книжка недавно вышла
https://nikgalushko.com/post/vim_as_golang_ide/
Уверен, у кого-то возникнет вопрос: «Зачем в 2021-ом пользоваться -vim- neovim, когда есть замечательный Goland?». Я до какого-то времени сам пользовался только продуктами от JetBrains, но вот уже более 1.5 лет пишу исключительно в vim.
Основной причиной для моего перехода с Goland стала его прожорливость. Отдавать по 3-4 Гб программе, которая просто подсказывает мне названия методов, запускает тесты и реализует «Go to definition», очень расточительно. Вкупе с непонятной политикой индексации проекта, когда у тебя в момент взывают куллеры, а батарейка на глазах тает, привело меня к vim.
Уверен, у кого-то возникнет вопрос: «Зачем в 2021-ом пользоваться -vim- neovim, когда есть замечательный Goland?». Я до какого-то времени сам пользовался только продуктами от JetBrains, но вот уже более 1.5 лет пишу исключительно в vim.
Основной причиной для моего перехода с Goland стала его прожорливость. Отдавать по 3-4 Гб программе, которая просто подсказывает мне названия методов, запускает тесты и реализует «Go to definition», очень расточительно. Вкупе с непонятной политикой индексации проекта, когда у тебя в момент взывают куллеры, а батарейка на глазах тает, привело меня к vim.
Ты сказал perl? Я думал он умер лет 15 назад.
Жаль, что он не умер. Он такой забавный - на нём очень просто писать, но через недеелю уже не понимаешь что твой код делает. А если код чужой, то всё, пиздец, приехали.
> Отдавать по 3-4 Гб программе, которая просто подсказывает мне названия методов, запускает тесты и реализует «Go to definition», очень расточительно
Я уж думал, что не осталось программистов-бомжей, которые не могут себе позволить иметь 32/64 Гб RAM на своей рабочей машине.
>Основной причиной для моего перехода с Goland стала его прожорливость. Отдавать по 3-4 Гб программе, которая просто подсказывает мне названия методов, запускает тесты и реализует «Go to definition», очень расточительно.
У него платное использование памяти что ли? Типа ГБ×час тариф?
Ну я понимаю, оно бы 10 ГБ жрало и на всё остальное бы не хватало, но 3-4 то почему жалко?
>Вкупе с непонятной политикой индексации проекта, когда у тебя в момент взывают куллеры, а батарейка на глазах тает, привело меня к vim.
Он не пробовал ноут к сети подключать? Ноут без сети это просто бесполезная хуйня.
На некоторых компах всего 2 гига ОЗУ может быть и там хваленый голэнд от жидбрейнс просто не работает
У меня на первом компе 32МБ было и винт на 1.66ГБ, я же не ною, что на нём вижуал студия не работает, поэтому я на кубейсике программы пишу.
2ГБ памяти это год 2006, наверное. Это просто гроб какой-то, а не ПК.
В 2006 у меня было 512Мбайт, а в 2010 я купил новый комп 2 ядра 2 гига.
Значит ты, дружище, нищееб. Два ядра два гига это как раз стандарт для 2006-2007
У меня 32 гига на топовом ThinkPad. Но увы - железо принадлежит компании. А своего компа уже давно нет - хуй угонишься за современным железом.
Серьёзно?
У меня валяется штук шесть старых ноутов и я тоже думал что без сети они бесполезны. Да они и были бесполезны, а затем на работе выдали божественный ThinkPad и мир перевернулся.
Впрочем, на нёи нет ни одной игры (нахуя, если плойка для игр лучше), весь софт исключительно лицензионный и, если надо загрузить чем-то действительно тяжёлым, то всегда под рукой putty и rdesktop - пусть сервера греются, а не прерасный "ящичек Пандоры".
> А своего компа уже давно нет - хуй угонишься за современным железом.
Да ладно, а зачем за ним гнаться? Я как собрался на райзенах года 3-4 назад, так до сих пор всё актуально.
Посоветуйте фреймвёрк для написания веб-приложений
В го нет фреймворков, язык ближе всех к unix way, каждый раз клепаешь себе франкенштейна из разных либ которые заточены под одну задачу. Иногда можешь обойтись только стандартной библиотекой, иногда кастомный велосипед пишешь.
А что у нас по зепкам?
С учётом годовой премии, у меня российской компании по текущему курсу вышло около 100к баксов за год заработка.
Это норм или не норм?
Прост сомнения, потому что гоферы как-то сложно нанимаются - многие просят непропорциональнр много относительно своего опыта. И тут всплывает в голове, а не недоплачивают ли мне.
С учётом годовой премии, у меня российской компании по текущему курсу вышло около 100к баксов за год заработка.
Это норм или не норм?
Прост сомнения, потому что гоферы как-то сложно нанимаются - многие просят непропорциональнр много относительно своего опыта. И тут всплывает в голове, а не недоплачивают ли мне.
Что-то как-то маловато у тебя.
Вот 500 - уже более-менее нормально было бы.
Половина миллиона долларов в год?
А десятка в месяц в РФ тебя не смущает?
Где размещать контроллеры? Рядом с main.go в cmd/app или тащить в internal/controllers?
Это здорово конечно, но как писать веб-приложения? Все говорят про это, но никто реальных примеров не скидывает.
Какие именно веб-приложения? Они бывают очень разные.
Есть куча книг (англоязычных) с примерами.
А фреймворков действительно нет, они не нужны.
Потому, что то, что делает какой-нибудь flask уже есть в стандартной библиотеке и в gorilla mux. Т.е. сам язык создавался уже заточенным под это применение.
Ахах. Тогда уж проще на бумажке код писать, прогонять в голове и уже потом переносить на пк. Зачем тратить заряд ноута лишний раз, правильно?
Ваще насрать где, если твой проект кроме тебя никто смотреть не будет
Я его буду размещать на гитхабе, а ссылку в резюме, чтобы при устройстве на работу все видели, что я крутой программист и сам написал веб-приложение.
Мне надо веб-приложение, которое может отвечать жсонами и хтмл-страничками, чтобы там была авторизация и аутентификация с миддлварями, чтобы была защита от CSRF-атак и т.п.
Есть список этих книг? Почему их никто не переводит? Неужели только я один задумался о написании веб-приложений?
В самом языке ничего нет. Он пустой. В том же РНР всё заточено для работы с вебом, а тут буквально ничего нет.
В /cmd размещают то, что будет компилироваться в исполняемый файл (команду).
В /internal - то, что _не_ должно импортироваться при импорте твоего модуля (библиотеки).
Т.е., в твоём случае - ни то, ни другое.
Или в /pkg или, лучше, просто в /controllers, если ты хочешь именно так структурировть код. Это не единственный способ. Можно группировать по функционалу, а не по типу кода. Какого-то одного правильного способа нет.
Или просто скопировал готовую структуру проекта хз где, а вместе с ним и код. Все эти контроллеры и прочее - это с пхп пришло.
Лучше делай по своему. Потому что тебя в любом случае заставят делать так как у них принято.
Спросят почему так а не эдак - говоришь так мне удобно, а в го нет жестких правил касательно структуры проекта. Начинают доебываться - шлёшь нахуй этих душнил ебаных.
Почему они не делятся кодом на этапе обучения, а ждут когда к ним придут челики, разработавшие свои методики?
Почему язык пкстой и на нём нихера нет? Потому что это язык для микросервисов через grpc блядт, он даже на рест не тянет.
Гуглу до зарезу нужен был язык для кучи пхп макак, желательно чтоб они не зависели друг от друга. Вот и появился го. Для микросервисов там сделано моё почтение. А на всё остальное просто положили болт, потому что они им не пользуются.
Лучше сделай морду на реакте, рест на питоне, а какую-нибудь прокладку по типу чятиков на го.
Все охуеют и поймут что ты нормальный разработчик, а не дрочер на один язык и выясняющий в интернете кто из них круче.
В ДС реально устроиться джуном на Го?
Да, но только в офис
Потому что некоторые конторы так и разрабатывают свои проекты. Заставляют делать тестовые, опрокидывают, а сами втихую пиздят код под свои нужды. Если код непонятен - нанимают на работу чтоб ты сам с ним разбирался.
Вот же гады!
Веб-приложения, отдающие html, не слишком популярны в го.
Потому, что в этом нет большого смысла, этот язык для другого.
Хотя, есть встроенные шаблоны, и их можно использовать.
Но, основная масса литературы - про rest api и микросервисы.
>Есть список этих книг?
Вот это посмотри:
https://scanlibs.com/full-stack-web-development-go/
https://scanlibs.com/pro-go-programming-efficient/
Потом попробую ещё чего-нибудь подобрать.
>Почему их никто не переводит?
Потому, что те, кому это интересно, умеют читать по-английски, как правило.
Алсо, ты такое вообще на чём-нибудь делал?
На питоне, например?
А то на го с нуля может быть сложновато.
Ну а ты как думал, на хх вон сколько вакансий по сотни и тысячи откликов. Представь себе, тысячи бесплатных одноразовых программистов каждый день. Делишь проект на элементарные части, каждую раздаешь по 10-20 соискателями. Выбираешь из них лучшую и собираешь готовый рабочий код.
Это хорошо. Почему-то кажется, что джуну так полезнее будет.
>Почему их никто не переводит
Ты что английский не учишь, Снегур?
А ещё можно заставить их обернуть всё это тестами. Это ж за неделю можно сделать проект который занимает полгода.
На PHP Laravel писал свои проекты, а на работе только на Вордпрессе писал, но там нужны только плагины, само приложение уже готово.
Тогда, стоило бы начать с питона - flask или fast api.
https://scanlibs.com/fastapi-modern-python-web-development/
Идеи все те же самые, только начинать проще, чтобы понять, что к чему.
Мне ещё питон учить что ли?
Чому не Django? Меньше похож на Go?
Сначала английский
Ну, если ты не знаешь го и не знаешь питон, то какая разница?
В итоге, по затратам времени сделать работающий проект на питоне - будет в разы быстрее, чем на го.
Да. Философия другая.
А может у него цель пет проект для резюме для вката голангером. Выучить питон, понаписать проектов по книгам и курсам, потом выучить го и переписать все на нем, но уже самостоятельно - норм идея?
Я РНР неплохо знаю
А то сейчас FastAPI хайпует. Вакансий нет, но интересно.
>full-stack-web-development-go
Автор тянет на каждый чих библиотеку с гитхаба. У него реально кривосшитый франкенштейн. Стандартную библиотеку он не использует.
>pro-go-programming-efficient
Дотнетчик Адам Фриман написал мини ASP.NET на голанге с рефлексией и инверсией зависимостей. Так явно никто не пишет на го.
Посоветуй другие книги тогда
Что сретесь?
В гошке стандарт - чистая архитектура дяди боба. Так что с его книжки и можно начать. Если читали, но лень самому делать структуру, можно утащить от three dots или evrone.
В гошке стандарт - чистая архитектура дяди боба. Так что с его книжки и можно начать. Если читали, но лень самому делать структуру, можно утащить от three dots или evrone.
Ну, это то, что быстро нашлось на тему "классических" веб-приложений на го.
Вот это посмотри:
https://habr.com/ru/articles/501722/
Там наоборот, чел мигрирует с пыхи на го.
Будет полезно для понимания, что к чему.
>чистая архитектура дяди боба
Там на каком ЯП примеры? Ньюфагу не сложно будет читать?
Алсо "Чистая архитектура" и "Чистый код" подразумевают какой-то порядок чтения или они о разном?
И как в го развешивать атрибуты с маршрутизацией по контроллерам?
С го на пыху, конечно же, лол.
См. ServeMux, gorilla/mux
Как аргумент функции передаётся.
Тут есть примеры:
https://github.com/gorilla/mux
Походу и мне придётся идти с го на пыху. А жаль, язык хороший, но что-то конкретное написать сложно. Нет, был бы у меня вагон времени, то с удовольствием бы разработал свой фреймворк, но когда готовишься для работы, то времени столько нет.
Не нужен никакой фреймворк, берёшь и пишешь что угодно.
Язык от дядь, которые писали все с нуля и не привыкли тащить пол гитхаба зависимости.
Все что нужно уже есть в языке.
Если ты прям ньюфаг вообще в программировании, то бери туториал по grpc и пили свой сервис как написано в туториале.
Сходу ты вроде все тонкости архитектур не погрузиться.
А grpc + базки будут хорошим стартом для портфолио.
>берёшь и пишешь что угодно
И в итоге спустя 5 лет получаешь абсолютно устаревший и неподдерживаемый кал во многих местах. Видел я такое однажды: в команде заморочились и сделали целый свой набор общих компонент и тулзов, чтобы в разных микросервисах использовать. Писались эти тулзы и микролибы одним челиком. А как он уволился - всю его работу просто взяли и выбросили нахуй, решили дать другому челику переписывать с нуля все заново. Ебало имаджинировали?
Сказки джуна фрилансера, который "это невозможно поддерживать, давайте переписку, а? Позязя, у меня долг по комуналке".
Неподдерживаемый код на гошке бывает конечно, когда приходит пыхер/питонщик/джавмст/etc и пишет как привык, но получая по рукам он быстро становится нормальным.
Go на уровне языка подталкивает разработчика пользоваться стандартными кирпичиками, делать код максимально solid, бить его на микроскрвисы. Что делает ситуацию с переписать все невозможной, если, конечно, сильно не поменялись бизнес требования.
Сказки джуна фрилансера, который "это невозможно поддерживать, давайте переписку, а? Позязя, у меня долг по комуналке".
Неподдерживаемый код на гошке бывает конечно, когда приходит пыхер/питонщик/джавмст/etc и пишет как привык, но получая по рукам он быстро становится нормальным.
Go на уровне языка подталкивает разработчика пользоваться стандартными кирпичиками, делать код максимально solid, бить его на микроскрвисы. Что делает ситуацию с переписать все невозможной, если, конечно, сильно не поменялись бизнес требования.
Да причем тут сказки, просто в команде решили повыебываться и написать свой микрофреймворк. Автор микрофреймворка ушел, поэтому все его тулзы заново переписывать начали, а старые тулзы и микролибы выбросили. Сам код микросервисов особо не трогали, кроме как если нужно было сами тулзы по другому начать использовать, не более. Переписывал не я, меня лишь заставили переводить часть микросервисов на новые либы постепенно.
>бить его на микроскрвисы
Уже в другом проекте мы сознательно делали монолит. Ну, вернее, так лид захотел. Причина - не хочется ебаться с распределенными транзакциями и двухфазными коммитами. Поэтому сделал по старинке одну базу с гигантской центральной сущностью в 30 полей и монолит, который на 10 виртуалок в облаке деплоится.
Ну, что-то такое я и имел в виду.
Это выгляди сложным, но, учиться вообще сложно.
Конечно, не надо год учить питон, потом год фласк или фаст-апи.
Смысл в том, чтобы быстро получить что-то работающее, поковырять его, и потом делать подобное на го, уже понимая куда копать. Сам питон при этом можно глубоко не учить, просто базу. Оно вообще не лишне - скрипты писать, прототипы и т.п.
>с гигантской центральной сущностью в 30 полей
Вот чем вы там все занимаетесь, лол? Лайки считаете?
В бизнес-задачах 30 полей - это вообще ни о чём. Просто так, побаловаться. А тут - гигантская сучность, лол. Отсюда и микросервисы эти ваши дурацкие. В задачах реального сектора - склад, планирование, прозводство, crm - такая хуита просто не жизнеспособна. Да и не нужна.
Ващето бабки считаем, ну да и похуй. Ну там не 30, а чуть больше полей, вроде 40, не считал на самом деле. Просто есть центральная сущность, которая нужна в абсолютно всех бизнес-процессах. Поэтому и приходится ее везде тянуть. А если монолит делать, да так, чтобы у каждого сервиса своя база была, то придется постоянно изо всех сервисов обращаться к тому, который обладает базой с таблицей, где эти сущности лежат.
Вот и хуй знает как тут на микросервисы монолит грамотно распилить...
Кто сказал, что его надо обязательно пилить на микросервисы?
Вот тут эта тема неплохо рассмотрена:
https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html
И, если кто не читал:
https://habr.com/ru/articles/779362/
оригинал:
https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices
Эти статьи и комменты уровня яндекс дзена, к кому хабра и скатилась.
Ложная дизотомия, монолит vs микросервисы. Должна решать команда разработки, не поддаваться на желтые статьи, а исходя из требований и ограничений конкретного бизнеса.
Микросервисы почти никогда и нигде не нужны.
Делать рест на го очень плохая идея. Я вас предупреждал. Потом не жалуйтесь когда Тулуп начнёт гореть, но будет уже поздно
> жирный монолит vs микросервис на каждую строчку кода
Максималисты добрались до ит.
О, джун-двачер
Ты точно прочитал, что там написано? Оба текста?
На хабре - это перевод. И хабр не "скатился", а всегда был говном.
Микросервисы (в большинстве случаев) - это способ искусственно увеличить сложность и стоимость разработки проекта, прикрываясь благими целями и умными словами. Инфоцыганство в чистом виде.
Хотя, часто это делают просто по глупости - все побежали - и я побежал.
Аргументации, конечно же не будет?
Я не он, но соглашусь. Раз нет реализации openapi3 за все годы, значит она нахер никому не упала из крупных компаний. Значит ресты никому не нужны.
Чем не угодил grpc? Он будет для внутреннего взаимодейсвия и мобилок, для веса можно на уровне гейтвея конвернуть в рест.
Всем привет. Хочу написать API-GateWay сервер на го. Использовал генерацию echo-сервера по спеке. Подскажите пожалуйста в чем ошибка?
моя структура пакетов:
main:
- main.go
- server.go
В обоих файликах прописан package main
в server.go лежит
type GatewayServer struct {
}
в main.go лежит
server := &GatewayServer{}
В VSCode go-to-definition работает, ошибок нет, но если пытаюсь запустить то получаю
./main.go:22:18: main.GatewayServer is not a type (exit status 1)
Чат гпт и гугл уже задрочил, не понимаю в чем проблема. Если перенести server.go в отдельную папку и поменять пакет то все работает нормально, но если main.go и server.go лежат вместе - то все пизда
А вообще если брать бэкенд, то какие технологии ближе всего (аналогичны) Go по задачам и концепциям?
Вот например список языков. Что из этого близко к Go, а что совсем не близко?
Python + Flask + FastAPI
PHP + Laravel + Symfony
Node.js + Express + NestJS
Java
C#
Ruby + Ruby on Rails
Rust
C++
Питон (до определённой степени).
Всё остально - это, скорее, анти-го.
Сами создатели позиционируют Го как "Си 21 века".
Т.е., это си со сборкой мусора, слайсами вместо массивов, интерфейсами, асинхронностью из коробки.
А питон многие определяют как "си с отступами" (в смысле - синтаксис на отступах).
И питон - прекрасный клей для сишных либ, интеграция очень простая.
Как-то так.
Алсо, в питоне то же лютое дрочево на стандарты кода (PEP-ы), диктаторские подходы (Гвидо - "милостивый диктатор") и прочий лол. Как и в го.
>type GatewayServer struct {}
У тебя там, случайно, '=' не стоит?
type GatewayServer = struct {...}
Ну или ещё какая-то хуйня, которую вскод не распознаёт как ошибку. Внимательно посмотри.
>Если у тебя динамические стенды в кубе это плюс, жрет мало ресов, не надо тратится на доп ноды, также регистри не забивает быстро(да можно настроить чистку) ибо образ весит мало.
Мало жрет сервис на сях, а реальный сервис на говноланг жрет ± на уровне джавы.
>Также старт сервиса быстрый по сравнению с той же джавой, которая по минуте поднимается...
Если у тебя каждую минуту стартует сервис, то у тебя проблемы с архитектурой или окружением. И решать их надо не ускорением старта сервиса, а исправлением основных проблем.
То есть, го не нужен, так?
А мужики-то не знают.
Памяти он жрёт реально меньше. А цпу - больше. Время старта реально меньше. Об этом много написано.
Алсо, 1 самодостаточный бинарник ставится в голый
контейнер, в отличие от.
Кого вообще парит время старта приложухи? Всё давно уже бесшовно деплоится, старый контейнер не отключается пока новый не стартанёт, так что это вообще не фактор, пусть хоть 10 минут стартует.
>1 самодостаточный бинарник ставится в голый контейнер
Опять же, какая разница, голый контейнер или не голый, его придумали чтобы набивать туда всё что нужно и не забивать себе голову - команда для запуска будет одна и та же.
Аргументации? Ты потратишь кучу времени на изучение го, устроишься на работу, будешь делать какие-то костыльные рализации реста на языке который для этого в принципе не предназначен. Поймёшь что на других языках это делается в разы проще, гораздо легче разработка, поддержка. Но к тому времени осознаешь, что просто потратил время на узкоспециализированное говно и в итоге Тулуп будет в огне потому что надо будет переучиваться.
>на языке который для этого в принципе не предназначен
Что значит, блять, "не предназначен"?
Там json встроен в язык.
Декларативная сериализация/десериализация из коробки.
Как ещё это должно быть "предназначено", по-твоему?
А насчёт grpc и protobuf есть разные мнения.
В том числе и такие, что это ненужное гугло-говно.
короче пока последовал вот этому совету и держу main.go в отдельном пакете а весь остальной код в другом
https://stackoverflow.com/questions/70024480/go-golang-does-not-see-other-go-files-inside-the-same-dir
вопрос номер 2
Я генерирую код сервера из опенапи спеки с помощью https://github.com/deepmap/oapi-codegen
Я получил такой интерфейс, который, как я понял, мне нужно имплементировать
type ServerInterface interface {
RegisterUser(ctx echo.Context) error
LoginUser(ctx echo.Context, params LoginUserParams) error
// остальные методы такие же
}
почему тут нет типизации никакой? я думал эта штука за меня напишет сериализацию/десереализацию тел ответов/запросов. А мне получается самому нужно это делать?
и еще у меня генерируются модели запросов, типа AddWordJSONRequestBody, но не генрируются модели ответов. Почему так нахуй?
Ну, вообще, это правильно.
Пакет main - только для запускающего кода.
Сама программа должна быть в другом пакете или в нескольких пакетах.
ты запускаешь через go run main.go? оно компилирует только main.go из пакета. зависимости оно подтягивает, другие файлы пакета не будет. запускай через go run .
>Кого вообще парит время старта приложухи? Всё давно уже бесшовно деплоится, старый контейнер не отключается пока новый не стартанёт, так что это вообще не фактор, пусть хоть 10 минут стартует.
вот я качу свои охуенные правки на прод и мне нужно следить не сломалось ли что.
10 минут непродуктивного тупняка в пайплайн это хуйня. либо отвлекаешься на другую таску, но тогда можешь вообще забыть, что тебе надо следить за метриками вообще-то. у нас и так пайплайн деплоя минут по 5-10. было бы 20, то вообще пиздец.
>go run main.go?
да, так и запускал. понял, спасибо
да рест вообще переусложненная хуита. делаешь просто POST запросы /set /get /update и норм.
Голанг это и есть гуглоговно которое почему-то пытаются тянуть в массы. Они сделали язык под свои задачи, а некоторые тут хотят на нём игры ещё делать.
Он существует уже больше десяти лет, а адекватных устоявшихся фреймворков до сих пор нет. Я уж молчу про всё остальное.
Он банально недоделан в качестве главного языка для проектов, его максимум - затычки для узких мест. Косяки стандартных библиотек превращают в фичи, которые создатели не хотят фиксить прикрываясь обратной совместимостью, раз уж комьюнити превратило это в фичу.
>говно которое почему-то пытаются тянуть в массы. Они сделали язык под свои задачи, а некоторые тут хотят на нём игры ещё делать.
Кто сказал Kotlin?
GET если данные не меняются: GET /UsersInGroup
POST если меняются: POST /AssignUserToGroup
Шиза со всякими PUT LIST DELETE нахуй не нужна.
А как же UWU запрос?
>Да всем ПОХУЙ на количество файлов. Ты во время сборки все упаковал в образ и все.
Поебись с докером, поебись с регистри и может быть ты запустишь свою cli. Нет, спасибо, мне как-то проще сервис и клиент для него на одном языке разрабатывать.
А хули ты хотел от издательства "Apress".
> , у меня российской компании по текущему курсу
30к вышло примерно, вместо премии дали хуй. Но это на пыхе.
Рест это не про тип http запроса, а про организацию роутинга и апи, чтобы шаблонные вещи оставались простыми и одинаковыми везде, а не приходил очередной Вася и лепил костыли UsersInGroup, AssignUserToGroup, в ресте это было бы GET /groups/:id/users и PUT /groups/:id/users, таким образом рест даёт стандартный интерфейс для доступа к большинству данных и любой веб-фреймворк сейчас генерирует эти ресты одной командой, только Гошники в очередной раз изобретают колесо зачем-то, еще спорите какая форма лучше, круглая или квадратная.
>Памяти он жрёт реально меньше. А цпу - больше. Время старта реально меньше. Об этом много написано.
Если сравнивать хелопорлд на голом Го и на Спринге может быть. А если реальные приложения, то разница будет в пределах погрешности. Кривая архитектура, на любом языке, перебьет индивидуальные особенности языка.
>вот я качу свои охуенные правки на прод и мне нужно следить не сломалось ли что.
Потому что ваша говноконтора не умеет в девопс. А по нормальному - у тебя есть стейджинг и канари с мониторингом и пробами. А не так что Паджит сидит и мониторит глазками.
>Поебись с докером, поебись с регистри и может быть ты запустишь свою cli. Нет, спасибо, мне как-то проще сервис и клиент для него на одном языке разрабатывать.
У тебя каша вместо мозгов, как вообще связан докер и то на каком язык разаработки клиента?
Прошёл го тур и встал вопрос практики. Как думаете этот проект подойдёт для начинающего?
https://www.youtube.com/watch?v=k_V5VvYSlS4
Книги читать не хочу просто потому что зачем тратить время на чтение 500 страниц когда можно посмотреть видео за 2 часа. По видео как по мне обучаешься в разы быстрее.
https://www.youtube.com/watch?v=k_V5VvYSlS4
Книги читать не хочу просто потому что зачем тратить время на чтение 500 страниц когда можно посмотреть видео за 2 часа. По видео как по мне обучаешься в разы быстрее.
>Мало жрет сервис на сях, а реальный сервис на говноланг жрет ± на уровне джавы.
Сразу видно человека не в теме... У меня в проде джава(спринг) была, жрало как не в себя, потом переписывали на гошку, сами образы меньше стали, сборка моментальная, и по ресам ест фигню...
Они привыкли просто переписывать всё на го. Зачем? Потому что так делает гугл, а гугл это цель жизни для зумеров-кодеров
Нет, просто микросервисы это го. Пихать туда джаву, си шарп это полный бред.
>Нет, просто микросервисы это nodejs + typescript. Пихать туда джаву, си шарп или го это полный бред.
>Книги читать не хочу просто потому что зачем тратить время на чтение 500 страниц когда можно посмотреть видео за 2 часа
Заблуждение. По книгам учиться гораздо эффективнее.
Я правильно понял, что мьютекс блочит вообще все корутины, кроме той, которая его лочит?
Для людей без образования.
Людям с образованием достаточно документации и пара статей
>людям с образованием
>достаточно пара статей
:)
Да, весь код который между lock и unlock может за раз пройти только одна горутина
Погугли, что такое tutorial hell
Дружок, это как в том анекдоте про еблю:
- Да долго ли умеючи!
- Вот умеючи как раз и долго.
Это то, на чём инфоцыгане делают деньги.
С образованием. А не тем кто учился ради корочки
>У меня в проде джава(спринг) была, жрало как не в себя, потом переписывали на гошку, сами образы меньше стали, сборка моментальная, и по ресам ест фигню...
Ты не отдупляешь суть. Главное это
>переписывали
а не
>на
Но ты не из таких, если собрался учиться по видосикам
Не знаю, не учусь по видосикам
Не надо грязи.
Сделать рабочий вариант, а потом, по результатам тестирования, оптимизировать - это нормально. Прототип на питоне был бы ещё проще, но, людям привыкшему писать на типизированном языке питон не катит (от тайп-хинтов там толку мало, это не то).
Алсо, Го таки быстрее джавы. Особенно в части работы с данными, вычислений и т.п. Например, я недавно узнал, что генерация случайных чисел на го в несколько раз быстрее, чем на джаве. И потребление памяти, опять же, не надо забывать.
А так-то, если по запросам в секунду смотреть, то оно всё примерно одинаково - что джава, что го, что питон.
Вот цитатка с реддита, про fastapi vs go:
https://www.reddit.com/r/golang/comments/u5squc/golang_vs_fastapi/
Generally, slower languages use Request Per Second to determine speed and show good numbers, which is super irrelevant for basically any real workload. Fast API is definitely fast in responding thanks to Uvloop and the underlying system calls, but in a real world application it will never be as fast a Go.
I've written a significant web API in both Go and Python using FastAPI and I consistently hit bottle necks inside python with the serialization and validation of data, which I've never had in Go.
Мы перепишем все на го
И будет бизнес огого!
Товары разом все уйдут
Как на страницу попадут.
Ведь важна скорость языка,
И польза тредов высока.
И будет бизнес огого!
Товары разом все уйдут
Как на страницу попадут.
Ведь важна скорость языка,
И польза тредов высока.
> адекватных устоявшихся фреймворков до сих пор нет
Детектор неосилятора-пхпшника, все знают что ИДНЫЙ ФРЕЙМВОРК это не говей. А пыхари/питонисты жрут симфони/джанго и просят ЕЩЁ.
*ЕДИНЫЙ
>Товары разом все уйдут
>Как на страницу попадут.
Ну точно пыхоблядок же.
Товары все уйдут на Озоне.
А ты пойдёшь торговать пирожками на вокзале.
Так вы даже не магазины на гохе пишите, а бизнес круды которые одна бабасрака в день будет ворочить?
Ты заебал уже, на го пишут
М И К Р О С Е Р В И С Ы
И
К
Р
О
С
Е
Р
В
И
С
Ы
Сервис рекомендаций, сервис рейтинга, сервис матрасчётов
Где много данных и нужно быстрое время обработки
Ваши магазины ссаные уже все давно написаны на пэхапэ
Миркосервисы и на пыхе пишут
И на брейнфаке
И еще половина постов о том, что оп сравнивает тёплое с мягким, и ты всё равно высрал это сюда, черрипикнув какую-то бессмысленную хуету.
Про тёплое с мягким там пишут твои братья по разуму.
Остальные прекрасно поняли, о чём речь.
Фастапи в питоне делает то, что в Го уже встроено из коробки.
А остальное - как сделаешь, что тут, что там.
Поэтому, такое сравнение "фреймворк vs язык" более чем правомерно.
Пока ты с горе пополам сделаешь один проект, остальные сделают три
Нахуя ты сравниваешь тормознутый фреймворк на тормознутом интерпретируемом языке с стандартной библиотекой на компилируемом языке? Да даже если так, для таких дуболомов, как ты, там внизу написано про blacksheep и litestar (а про granian не написали), которые под капотом используют не тормознутый pydantic, а msgspec. Ой, а ещё можно заменить uvicorn на nginx unit или написать свою реализацию asgi-сервера. Да, это всё ещё будет медленнее такой же дефолтной веб-дрисни даже на fiber или gin по бенчмаркам, но про ботлнек сервиса, которым пользуется даже 200 тёть срак из твоего бэк-офиса, смешно слышать.
> тормознутый
Я не думаю что на подтираче есть люди которые держат сервер на 100к запросов/с
Зато есть умники, которые рассуждают не исходя из своего практического опыта и собственных замеров, а на основе тредов на реддите. И вправду ботлнек головного мозга.
Какие такие задачи за тебя решает фреймворк, которые уже не решены стандартной библиотекой go и golang.org/x/...?
Посмотрел тут книжку Облачный Go и что-то офигел от сложности. Это реально всё надо знать что ли? Или можно написать простой сайт на го и устраиваться на работу?
А что там сложного? Ты хотя бы на английском смотрел? Может дело в переводе.
Ну всякие дроссельные заслонки надо учить и потом прям сложные примеры он даёт. Я практически ничего не понял. Это блин реально надо быть на уровне сеньора, чтобы вкатиться в го. Новичку тут просто не освоить.
Так по Го десятки, если не сотни книг. Почему ты взял именно эту?
Проблема не в том что го решает или не решает.
Проблема в том как быстрее и удобнее вести разработку
Я хотел сразу оценить, что нужно знать по го в плане микросерсивом и офигел от сложности. Толку читать ещё одну книгу го для чайников, она не приблизит к трудоустройству.
Сколько месяцев пишешь на Го?
Разница в том что если твой софт запускать будешь не ты у себя локально, то чем проще запуск и чем меньше требований к окружению - тем лучше.
Статическая сборка бинарей из коробки - это очень мощный бонус go, наравне с электроном для js.
Контейнеры - это хороший способ доставить приложение из дева в прод, и очень хуёвый способ дистрибуции софта клиентам.
Судя по содержанию, это книга для техлида/архитектора - такие почти нет смысла читать без наглядного примера решаемой задачи под боком.
Если не стрессуешь с провалов, на собеседования можно ходить в любое время - только не ходи на вакансии мидла когда ты не уверен что даже джуна потянешь.
Где-то в сентябре начал учить
>не ходи на вакансии мидла
Я не в Москве живу, а за тысячу км от неё. Так что только удаленка, а туда требуют мидлов. На джуна 0 вакансий.
По каким материалам учил? Если по ютубу, то для начала реально простые книжки стоит почитать.
Я учил по книжке Адама Фримана. Первая часть вполне годная в плане изучения языка, до проекта реального веб-приложения. Я пытался разобраться в его веб-приложении, но там всё на рефлексии и она нужна просто для красоты, чтобы было похоже на ASP.NET.
Потом ещё нашёл в интернете статьи чувака по разработке более идеоматичные: https://golangify.com/go/web-app-go
Но он не до конца написал.
Пробовал читать Цукалоса, но он слишком коряво пишет. Одновременно пытается объяснить основы языка и какие-то сложные моменты. В итоге - каша.
У книжек от O'Reilly обычно в начале написано для кого они предназначены.
>This book is directed at intermediate-to-advanced developers, particularly web application engineers and DevOps specialists/site reliability engineers
Хороших книг по Go навалом, но они на английском. Хороши издательства O'Reilly, Manning, No Starch, иногда Packt и Apress, с этими двумя надо внимательнее быть.
И что мне теперь ещё английский учить? Я планировал в марте уже искать работу. Считай 2 месяца осталось на подготовку, а у меня - не у шубы рукав как говорится.
Ну что за абстрактный вопрос? Быстрее всего вести разработку в copilot в привычном для себя стеке.
У нас веб-приложения даже на плюсах пилят, потому что все инструменты для этого готовы и рядом в монорепе куча примеров (https://userver.tech), но если ты дома с нуля попробуешь, то сольёшь кучу времени в хэлло-ворлд.
Вы выбираете не жену, а инструмент на ближайшие полгода-год. Куда правильнее выбирать язык по вакансии на которую метишь и задачам которые ты хочешь решать, а не по абстрактному кол-ву фреймворков - на работе всё равно придётся использовать локальный стэк.
Тогда могу только порекомендовать стажировку с проживанием и последующую релокацию, но это вариант для молодых и шутливых. На удалёнку все опасаются брать ждунов.
Английский в любом случае учить.
Его очень полезно знать. Тем более, для чтения не так уж сложно выучить. А так на русском тоже что-то есть, хотя и негусто. Head First Go, Донован и Керниган, Боднер, Харшани. Еще можешь какие-то курсы на рутрекере и nnmclub поискать.
Но вообще учи английский, если есть свободное время. Ты же как-то помимо работы/учебы/вката чиллишь, сериалы, игры, ютуб. Перейди на чисто англоязычный контент и за месяц уже будешь понимать более-менее. Алсо пройди A Tour of Go с гугл переводчиком хотя бы.
>Облачный Go
Лол, они перевели Cloud Native Go. Да ещё так быстро.
Оригинал - отличная книга, но, это ни разу не учебник по Го.
Перевод я не видел, но, хороших переводов комп. литературы вообще мало. а этот сделали очень быстро - оригинал издан в апреле 2021, а перевод - уже в сентябре. Хотя, ДМК, вроде, раньше делал норм. переводы, когда я ещё читал такие вещи на русском (лет 20 назад).
Но, вот эти вот "дроссельные заслонки" немного настораживают.
В оригинале, конечно же, было throttle. Кстати, как они там debounce перевели? Короче - не читайте до обеда советских газет, лол.
Но, если ты "ничего не понял" в книге, где рассказывают, что такое микросервисы, то что ты собрался делать на работе?
Я бы тебе посоветовал просто учить Го, и делать что-то по книжкам с пошаговыми примерами. Их есть на scanlibs.com (на английском). Причём, упор не на "микро" а прост на REST API. Переводить можно гуглом. А потом честно пытаться устроиться стажёром за еду. Это единственный реальный вариант.
А ещё лучше - то же самое, но на питоне. Ибо го - сложный язык + сама тема микросервсов/облаков тебе совершенно не знакома, как видим.
https://scanlibs.com/building-rest-apis-flask-services-mysql/
https://scanlibs.com/fastapi-modern-python-web-development/
https://scanlibs.com/building-python-microservices-fastapi/
https://scanlibs.com/python-microservices-development-2nd/
https://scanlibs.com/architecture-patterns-python-domain-driven-microservices/
https://www.youtube.com/watch?v=yE5Tpp2BSGw
https://news.ycombinator.com/item?id=38872362
Выступление великого Пайка и еще более интересный тред с обсуждением на хакерньюс.
https://news.ycombinator.com/item?id=38872362
Выступление великого Пайка и еще более интересный тред с обсуждением на хакерньюс.
Короче, посмотрел перевод - на сайте ДМК есть оглавление и несколько отрывков. Хуета. Переводчик - Киселёв, известный персонаж. Из тех, кто переводит паттерн как "шаблон". И изобретает свои термины, вместо устоявшихся англоязычных. С терминологией, в итоге - пиздос. Учите английский, дети.
О, спасибо за подгон!
это всё есть. на стейдже все проблемы не отловишь. и проберы в канари на всё не настроишь. простой пример - накосячил в логике с условием и запросы в новую зависимость не идут. или наоборот задублировались. по графикам легко будет заметить, а проберы на такую хуиту никто не настраивает. или если другой сервис может начать стрелять (а он может), то ты будешь проберы на соседние сервисы тоже себе завозить? да или еще проще пример - порог на пробере может не заметить проблему, даже если с EWMA/производными/бейзлайнами наизвращаешься. так что вообще-то да, поглядывать на метрики при деплое помогает.
>debounce
Антидребезг
Проблема тут очевидно в завышенных требованиях в вакансиях. Как человек вообще может этому обучиться, если он в глаза не видел этих ваших хайлоадов!? У меня вот на учебном проекте ни каких хайлоадов нет, там один пользователь - я.
Мне кажется го сам себя загоняет в тупик такими завышенными требованиями к программистам и быстро схлопнется. Уже сейчас наблюдается снижение его уровня популярности.
>завышенных требованиях
Да не завышены требования, они как раз такие, какие требуются, го это инструмент для хайлоада и ты идёшь работать на хайлоад с микросервисной арихтектурой, которая хуёво отлаживается, хуёво мониторится, хуёво деплоится и мутная со всех сторон, зато быстрая и хорошо масштабируется, возьмешь новичка на такую работу - он тебе заминирует весь проект так, что на этих минах будут подрываться другие разрабы, плохой код и плохие архитектурные решения придётся переписывать, а издержки на переписывание кода в такой системе просто колоссальные. Го это не язык для вката, это не язык для обучения программированию, это язык который решает узкую техническую проблему для уже развившихся и устоявшихся систем, требования к которой известны и жестко зафиксированы, не надо себе иллюзий строить что вот сейчас прочтешь книгу по микросервисам и начнешь писать распределенные системы не имея опыта работы с другими архитектурами и подходами, это так не работает. Откуда у вас вообще возникла идея в голове, что можно вот так с нихуя посмотрев видосики на ютубе вкатиться в хайлоад? Далеко не все программисты с опытом-то дорастают до таких вещей.
Хозяйке на заметку:
Чтобы ваш микросервис не дребезжал, и не искрил, надо поджать контакты реле.
Всё так, конечно.
Но, хайлоады можно и симулировать:
https://github.com/grafana/k6
https://justin.palpant.us/simulating-user-traffic-with-chrome-and-golang/
https://blog.postman.com/postman-api-performance-testing/
Конкретно на рынке рф большинство вакансий го это обычные круды.
>хайлоад
Чисто российский термин, нигде вне снг не используется
И что теперь делать? Учить пхп что ли?
>Откуда у вас вообще возникла идея в голове, что можно вот так с нихуя посмотрев видосики на ютубе вкатиться в хайлоад?
Мне на ютубе сказали: https://www.youtube.com/live/mzULEOFgc98?si=zvPl-GKhNvKqgLLm&t=6705
Обычные круды делаются обычным инструментом, предназначенным для клепания крудов, десятки их, очень простых и удобных, в популярных веб-фреймворках уже встроен генератор крудов.
>Чисто российский термин
Термин может и местный, но проблема, которую он характеризует, понятна любому специалисту.
У белых людей это называется high performance.
Потому, что не важно, насколько ты устал, важно, что ты в итоге сделал. А у нас - "здесь мерилом работы считают усталость".
Я правильно понимаю, что если проекты с пхп переводят на го, то пыха уже не нужна и нет смысла её учить?
Ты еблан? Хайлоад == high performance, это литералли одно и тоже. Плюс термин не российский а постсоветский
Сынок, еблан - это твой папа.
И посмотри в словаре, что значит слово literally.
Потом подумай.
Термин "high load" не отражает вообще ничего.
Большая нагрузка - и что?
Вот если тебе дать штангу 200 кг - это будет "хайлоад".
И под этим хайлоадом ты просто обосрёшься, и всё.
А вот хай перфоманс - это когда серьёзный перец подошёл, и эту штангу поднял.
Понимаешь разницу?
Пока что на го нет ничего уровня Ларавеля
Забавно, что бывшие пхпешники сильнее всего засирают пхп
>хуёво отлаживается, хуёво мониторится
Так бывает у дебилов, которые вместо саги срут ивентами в кафку, а потом с горящей жопой бегают по 100500 логам и пытаются понять, куда пропала транзакция ебаная. Микросервисы - это литерали про "наймем кучу дешевых мартышек и пусть они пердолятся".
Менторы из яндекса, лол.
Слушай больше, они тебе расскажут.
Клоун справа даже не понимает, что при разговоре демонстрирует полный набор маркеров лжеца, раз за разом. Зато, наверное, не прочь порассуждать про "софт-скилы". Ебаный стыд, короче.
А зачем?
Го - это анти-ларавель. И анти-пхп, если угодно.
И да, пыха никуда не денется в ближайшие лет триста. Го тут вообще не при делах.
Ой да иди нахуй душнила ебаный.
На хуй твоя Тулуп хороша мальчик.
Если ты тупой - сиди тихо и не отсвечивай.
Сойдёшь за умного.
>сервис рейтинга
Зачем для рейтинга делать отдельный сервис?
Какая разница как называть это говно вообще. Хайлоад, хуйлоад хай перформанс. Ваще насрать, это одна и та же проблема, а вместо того чтоб сосредоточиться над проблемой люди спорят как её правильно называть.
Филологи комнатные блядь
>на рынке рф большинство вакансий го это обычные круды
Двачую.
Голанг тащат в те места, где более чем достаточно связки python+flask+pydantic
>на работе всё равно придётся использовать локальный стэк
Ну это только в Я по большей части. Помню как работал там, такого говна поел, особенно по части деплоя в няню.
Это было сказано мимоходом, для лулзов, неужели не понятно?
Алсо, разница в названиях прекрасно иллюстрирует разницу менталитетов - понты и пафос против реальных результатов. Это как подросток vs взрослый.
Ну, ты бы просветился сначала, зачем их вообще отдельными делают. Т.е. зачем вообще микросервисы.
Сферическая идея в вакууме такова, что можно масштабироваться под нагрузкой, автоматически запуская параллельно нужное число контейнеров с отдельными инстансами сервиса. Каждый сервис делает свой маленький кусочек, но делает очень быстро и т.д. и т.п.
На самом деле, в 90% случаев это всё нахуй не нужно, и нормальный монолит будет в разы быстрее и дешевле.
Весело на утреннике тебе жить :) Сколько девушек за ручку держал?(кроме мамы, если она есть)
Мало того, что ты говоришь с людьми из снг, где все понимают под хайлодом - высокие нагрузки (хотя само определение не дает понимание о каких нагрузках идет речь), так еще и пытаешься маневрировать, как последний малолетний кретин. Саги тебе свинья.
мимо - другой анон.
>Контейнеры - это хороший способ доставить приложение из дева в прод, и очень хуёвый способ дистрибуции софта клиентам.
У клиента должен быть браузер или аппка на мобилке, никакого другого софта ему дистрибутить не надо.
>Например, я недавно узнал, что генерация случайных чисел на го в несколько раз быстрее, чем на джаве
Ну ахует теперь!
>на стейдже все проблемы не отловишь. и проберы в канари на всё не настроишь
И что ты предлагаешь? После каждого релиза каждый разраб должен пыриться на прод метрики, логи, вручную тестировать свою фичу? Ты понимаешь, что такой подход абсолютно не продуктивен и подвержен ошибкам?
Хайлоад это состояние системы.
Хай перформанс - качество.
Причём тут менталитет вообще...
Мальчик, сосни-ка хуйца.
А когда проглотишь - попытайся научиться понимать прочитанное.
Можно несколько раз читать, если с первого не доходит.
Чувак, видишь ли, в чём проблема - термин high load - англоязычный. Но, англоязычная аудитория таким термином не пользуется в принципе. Вообще никогда, понимаешь? Там думают по-другому. Вопрос - зачем этот карго-культ? Почему не использовать русскоязычный термин? Если это не понты и пафос, то что это?
Скуфик - спок. на вопрос ответь сначала, а потом рыгай из себя желочь. Ты обязательно сможешь! Я в в тебя, обруганная тупая блядь.
Этот битард порвался, несите другого, лол.
Среди англоязычной аудитории программиостов 80% это китайцы с индусами.
Почему они пользуются английским?
>термин high load - англоязычный
>Если это не понты и пафос, то что это?
Не понты и не пафос, просто калька с конференции HighLoad++, на которой уже 20 лет ежегодно обсуждают проблемы высоких нагрузок, так что твои наезды к устоявшимся терминам в глазах опытных анонов выглядят как тупость залётного вкатунишки и никак иначе.
Книга с кабанчиком это про тот самый хайлоуд?
> вы не имеете права пользоваться английским
> в глазах опытных анонов выглядят
Дружок, я здесь не для того, чтобы соответствовать твоим ожиданиям.
По итогу вчерашних или позавчерашних обсуждений спрошу.
Если я в универе немного учил Питон и сейчас повторю основы, а потом возьмусь за бэкенд на Flask или FastAPI, то через пару месяцев практики норм будет взяться уже за Golang? Или лучше не ходить окольными путями?
Если я в универе немного учил Питон и сейчас повторю основы, а потом возьмусь за бэкенд на Flask или FastAPI, то через пару месяцев практики норм будет взяться уже за Golang? Или лучше не ходить окольными путями?
Мне кажется - лучше ходить.
Можешь смотреть на это не как на "окольный путь", а как на создание прототипа.
Ты Го вообще знаешь? Можешь что-то написать?
>Ты Го вообще знаешь?
Нет, я сейчас прохожу A Tour of Go, потом хотел какие-то книги с упором на практику почитать. Не переписывать код, а так: пару часов читаю, потом пару часов делаю сам.
Из языков программирования знаю JS и Python. В универе изучал Python для работы с данными, еще на нем же немного изучал алгоритмы. JS когда-то знал неплохо, на React кое-что делал, но потом понял, что фронтенд не вариант для вката. Не только из-за конкуренции, но и в целом перспектив развития как разработчика.
Хочу какой-то оптимальный путь обучения выбрать, чтобы летом можно было по собесам начать ходить. Мне в целом импонирует идея знания многих языков программирования, если они применяются для схожих задач. Встречал, что многие себя так и идентифицируют "Python/Go разработчик" или вакансии так называются. Но вроде в Go повыше вероятность вката, чем в Python, так что вопрос в конвертации знаний, полученных на примере Flask/FastAPI, в Go.
Ну, если ты никогда не делал веб-сервисы, то питон - самый простой способ это начать.
Насчёт "конвертации" знаний - я думаю, так не совсем правильно говорить. Ты получишь знания о том, как вообще делаются веб-сервисы. Независимо от языка.
Насчёт книжек по Го - выше упоминалась Cloud Native Go (и её перевод).
Там всё не так сложно. Первая часть - просто введение в тему, совсем короткая. Во второй части дано введение в Го и рассмотрен пример простейшего сервиса, который пишет transaction log. В третьей - разговор про паттерны и про то, почему и зачем делают так или иначе. Третья часть может быть сложновата, т.к. без опыта может быть непонятно, зачем это всё.
Могу также посоветовать Distributed Services with Go: Your Guide to Reliable, Scalable, and Maintainable Systems (очень годная книга с хорошими отзывами на амазоне).
Там в течение всей книги делается несложный сервис распределённого лога, который по ходу дела обрастает разными фишками. Но, всё с самого начала делается на gRPC, а на на REST.
https://scanlibs.com/distributed-services-go-reliable/
Ещё могу сказать, что книги микросервисам и т.п. на Го содержат массу интересных подробностей, которых нет в книгах по этим же темам на джаве, например. Потому, что в Го принято делать всё без фреймворков (и делается это, в целом, несложно).
не, предлагаю обмазать весь проект проберами на каждый чих и обтекать с отваливающимися от колебаний воздуха деплоями. а чатик с алертами замютить чтобы постоянные флапы не мозолили глаза. или еще лучше идея - хуяк хуяк и в продакшн.
от разраба нужно не кода больше высрать, а фичи сделать и деньги не потерять. то, что деплой мониторит 1 (один) человек это не непродуктивно. и лучший человек для этого это сам разраб, который знает, что он релизит.
>После каждого релиза каждый разраб должен пыриться на прод метрики, логи, вручную тестировать свою фичу
тестить до релиза надо. после релиза - по ситуации. в зависимости от сложности/рисков выбирается как фичу тестить и мониторить.
юнит-тесты нужно писать однозначно.
малорисковые штуки уровня цвет кнопки/либу обновить - можно не следить и не тестить вручную.
что-то посложнее хорошо бы хеппи патх на стейдже протестить и деплой проконтролировать. это значит в идеале пару раз в графану заглянуть как канари себя ведет, даже если проберы не стреляют.
более рисковое уже в зависимости от масштабов - qa подключать/делать внутренний тест на компанию/пыриться в метрики и логи/добавлять проберы/дохуя всего
>подвержен ошибкам
нихуя не понял. мониторишь/не мониторишь, ошибки все равно будут. если мониторить, то есть шанс про них раньше узнать и меньше разбирать потом.
это тупо развитие кругозора. есть шанс, что поможет, но когда - тут не угадаешь.
предвижу, что в петоне будет много сахара, который скрывает то, что в го надо будет научиться писать самому. из фласка ты в итоге перенесешь тупа общие знания как писать бэкенд, а всё остальное будешь учить заново. да и даже общие знания о бэке это нихуя без работы с реальными системами. imo на петоне надо уметь писать, но учить лучше сразу гошку.
> пара месяцев практики
Этого даже на проект не хватит, нужен опыт.
Потому что на го очень неприятно делать рефакторинг. Чтоб за него браться, надо набить руку сразу делать проект на хорошем уровне. Для этого нужен опыт.
Поэтому на го не берут джунов. Они сами перегорают от сроков одного и того же проекта, так ещё и потом за него гавно чистить надо когда он свалит и поймёт что это не его.
Микросервисы это не архитектура, это стиль управления. Они нужны, чтобы нанимать хохлов из епама за тарелку мивины. Когда у тебя мусорный стартап и ты не можешь год искать синьоров, а хохлы вот они, за забором хрюкают. Опыта у них ноль, мозгов еще меньше, но их много, они дешевые и могут начать работать прям завтра. Разделение на микропенисы придумали, чтобы эти долбоебы не утонули в бесконечных мерджах пул реквестов и хоть как-то работали. К масштабируемости микропенисы никакого отношения не имеют, ведь тормозит не говнокод, а база, которую хуй отмасштабируешь. Можно до усрачки поднимать контейнеры, но когда они все ходят в одну базу, будет пиздец с блокировками, это классика, это знать надо.
Это паста или что?
>Сферическая идея в вакууме такова, что можно масштабироваться под нагрузкой
Микросервисы решают задачу менеджмента а не масштабирования. Чтобы компанию можно было поделить на группки и дать каждой группе по одному микросервису. И они могли независимо от других разрабатывать, тестировать, деплоить.
Это удобно, если у тебя 100 программистов, ты можешь сделать 10-20 микросервисов. Микросервис приёма заказов например. Над ним может работать менеджер по продажам, два программиста и дизайнер.
Монолиты прекрасно масштабируются. С помощью кеширования + лоад балансинга.
Микросервисы можно более ТОНКО отмасштабировать. То есть дать какому-то сервису чуть больше ресурсов, другому чуть меньше.
Но общей сути это не меняет.
мимо
>Это удобно, если у тебя 100 программистов, ты можешь сделать 10-20 микросервисов. Микросервис приёма заказов например. Над ним может работать менеджер по продажам, два программиста и дизайнер.
И кто мешает делать то же самое с модульным монолитом?
Возможно, несколько усложнится деплоймент, и то не факт.
При том факте, что на микросервисных проектах модно делать монорепы. Это сильно "помогает" разгрузить мержи реквестов...
А потом версионный ад начинается, когда всё по репам разбито.
Ничего! Но монолит как ты его не модуляризируй как не выноси в плагины, остаётся монолитом. Какая хуй разница, ну окей, у тебя есть интернет-магазин. Ты его написал на java/c#/go/rust. Вынес checkout, cart, заказы в отдельную библиотеку. Этот проект всё равно будет компилироваться полдня, от того что ты вынес в библиотеки, это особой погоды не сделало. Посмотри сколько условный файрфокс компилируется. Потом ещё полдня будет тестироваться. Ну и плюс, это всё сидит в монорепе.
Я не привязан к одному языку программирования в микросервисах. Захотел в одном месте питон использую, в другом go, в третьем rust. У меня только один сервис на которым я работаю. Он быстро компилится, быстро тестируется и быстро деплоится.
Чаще всего под модульным монолитом имеют ввиду 3-х слойную архитектуру. Ну типа фронтэнд, бекенд, данные. Но это не совсем то. Что скажем маленькая команда программист + дизайнер + менеджер по продажам, работающая над микросервисом.
Из твоих 100 программистов 95 - это вкатунцы после курсов, синьоры уровня епам и мастера софт-скиллов 80 уровня. То есть, стадо долбоебов. Когда они все начинают комитить в одну репу, наступает хаос. Уволить этих мартышек тоже нельзя, ведь когда ты начальник 5 человек - ты тимлид Вася, а когда 100 - ты руководитель направления разработки Василий Петрович, понимаешь ли. Поэтому мартышек делят на команды по 5-10 голов и там они кидаются джейсоном в кафку, а толковых ребят выделяют в отдельную команду инфраструктуры и кластер крутится, код мутится. Потом падает какой-то из 500 микросервисов и вся система встает раком. Архитектура жи есть.
>Чаще всего под модульным монолитом имеют ввиду 3-х слойную архитектуру. Ну типа фронтэнд, бекенд, данные.
Нет.
Ты описал горизонтальные слои.
А модули - вертикальные блоки.
В каждом модуле - свои три слоя.
То же самое, что микросервисы, но, связь не по сети, а средствами языка - просто вызовами функций или очередь сообщений и т.п.
>Что скажем маленькая команда программист + дизайнер + менеджер по продажам, работающая над микросервисом.
И я тебе даже больше скажу - вот это вот, что ты описал - это модуль, а не микросервис. Возможно - реализованный через Тулуп, но модуль. Потому, что в микросервисе дизайнер не нужен.
Вообще, завязывай учить, и начинай учиться.
https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html
>читать высеры от инфоциган
Ты лучше посмотри на ютубе выступления с конференций хайлоад, где люди делятся реальными кейсами, а не влажными фантазиями. Сначала микросервисы, теперь модули, завтра очередной джон хуй высрет очередной фанфик про разработку и все будут обсуждать какие-нибудь юниты, блять.
Ищу работу на Гошке.
Связался с компанией, они пилят мобильные игори на айос, при этом у них бек на го.
Никогда не имел дело с такой специфической штукой как мультиплеер игори. Расскажите вообще че это. Как я понял, это дохуя сокетов, которые получают какие-то изменения мира и возвращают актуальное состояние карты/персонажа/мира/прочей фигни.
>Выступление великого Пайка
Хуета. Все got wrong ограничивается в документации было мало примеров, с комьюнити неправильно работали, int надо было сделать безразмерным, syslog плохо написан. На критику Го как языка он никак не ответил.
Ого какой там в треде жесткий блэкпилл и дизмораль в сторону гошки
ну представим что все микросервисы стали модулями. каждый модуль может общаться с другими модулями только по API, который валидируется и всегда валиден, как сейчас. и все модули в отдельных репах, как сейчас. и каждый модуль может ходить только в личную БД, как сейчас. и, конечно, вся сборка монолита абстрагирована от разработчиков - пайплайн пуллит модули и собирает монолит.
что ты получил? усложнение сборки монолита, невозможность поскейлить отдельные модули - можно скейлить только монолит целиком.
и непонятные деплои - у тебя очередь из деплоев на каждый апдейт одного модуля или можно катить правки в N модулях одновременно?
как делать канари деплои? роутинг на уровне кода разруливать и держать старый код рядом? хотя ладно, окей, теоретически можно роутить на разные версии модулей одновременно из кода монолита и в пайплайне пуллить пару последних тегов. это конечно еще доп. сложность для сборки.
но вот ещё некоторые модули делают довольно долгие запросы к своей БД, им норм 5 секунд ждать инфу, бизнес-требования расслабленные. уверен, что у тебя ФД не кончатся?
а если пролезла паника/сегфолт (а некоторые фичи могут быть завязаны на CGO)? у тебя падает сразу абсолютно всё, ок?
>тебя падает сразу абсолютно всё, ок?
Система останавливается целиком, абсолютно благоприятный сценарий в отличии от микросервсиов, где всё пошло в разнос и при этом продолжает функционировать непредсказуемым образом.
Почему-то люди думают, раз кому-то микросервисы помогли, значит они и всем помогут. При этом не вдаваясь в подробности и кейс проблемы.
Почему все забыли про сервисную архитектуру? Либо монолит, либо микро. Будто ничего другого нетю
Почему все забыли про сервисную архитектуру? Либо монолит, либо микро. Будто ничего другого нетю
Идея микросервисов хорошо ложится на кубер хуюбер+ если большая компания и много команд, каждая может на своем текущем стеке пилить, а не переучиваться.
Я тебя понял. Го очень подходит для говнокодеров, потому что они не могут в тестирование, а деплоймент происходит быстро и можно быстро сломать проверить на проде.
Я имел в виду джаву. Надо было уточнить.
На Го такого опыта у меня нет, я написал всего пару cli-утилит, хотя и достаточно сложных.
И, я думаю, что в случае Го такой подход не очень подходит, просто потому, что это нативный код в одном толстом бинарнике. И делать .so тоже не вариант, как мне кажется.
Более того - при таком подходе Го становится просто не нужен, скорее всего.
Без микросервисов кубер просто не нужен.
Вообще, очень надеюсь, что когда-нибудь все уже поумнеют, и сольют всё это раздутое говно в унитаз.
Потому, что заменить один bloat другим - это так себе прогресс.
Микросервисы это, что называется: рыночек порешал. Для кабана топ тема.
>Система останавливается целиком, абсолютно благоприятный сценарий
нихуя не благоприятный, когда у тебя весь сайт тупо сдох. это сразу потери в деньгах и новости в СМИ.
вот у нас есть несколько источников дохода. если один отваливается, то продолжает работать.
с большой вероятностью отваливается сценарий, который пока меньше дохода приносит - он новый и не такой стабильный ещё. но если он будет класть весь сайт, то это хуевая архитектура. непредсказуемое поведение это тоже хуевая архитектура, но его легко избежать тупо правильными практиками и грейсфул деградейшном.
Платить клиентам компенсации на потерянную транзакцию типа ок?
Я уже писал тут - это инфоцыганский развод заказчика на бабки.
Реально пилят на микросервисах то, что в других местах прекрасно работало и работает на java EE. Работает в разы лучше, чем весь этот ёбаный хаос. Дебилы, блять. Воистину - время дураков.
Ты правда не понимаешь, что то, что ты описываешь (и вот здесь тоже) - это просто хаос? Нерабочая хуйня? Процесс ради процесса?
если прошла оплата, то деньги для начала просто захолдированы и их можно бесплатно вернуть.
чтобы они не списались, если нихуя в реальности не произошло, то надо просто нормально делать и нормально будет. пусть даже падает весь биллинг, но не сам сайт.
есть редкие кейсы когда всё пиздец неудачно - в них платить компенсацию норм.
а падение отдельных сервисов не должно к этим кейсам приводить.
я готов послушать. объясни
>Система останавливается целиком, абсолютно благоприятный сценарий
И не поднимается назад пока не починят модуль. Абсолютно хуёвый сценарий для бизнеса с задекларованным SLA. И теперь девопс должен уметь не только разбираться как что-то поднять и замониторить, но и как правильно отключать модули приложения руками в проде чтобы приложение не крешилось сразу после старта.
Полная остановка допустима только для некоторого коробочного софта.
Если биллить клиентов за незафиксированный заказ или неоказанную услугу для тебя ок, то компенсировать, откатывать транзакции и проводить сверку транзакций ты тоже должен уметь. А для крупного бизнеса это даже не право, а обязанность.
Охуеть как усложнится CI твоего монолита. Задача решаемая, но обычно ты не в гугле и разрабатываешь не хром, обычно вся история заканчивается тем что перед очередными празниками из-за изменений в куче сервисов сборка ломается в нескольких местах, и её не могут починить неделю.
>компенсировать, откатывать транзакции и проводить сверку транзакций ты тоже должен уметь
У нас сделали биллинг монолитом, чтобы не ебаться с транзакциями.
>И не поднимается назад пока не починят модуль.
Поднимается в последнее стабильное состояние, еще 10 лет назад деплой автоматом всё это делал, программа падает и всё встаёт на уши сразу же, а разбор полётов и ремонт уже в дев-среде, за чашечкой кофе, другое дело когда ты задеплоил, потом у тебя через час выстрелил алерт, за этот час система гоняла транзакии по сломанному пайплайну и тебе приходится подключать бухгалтерию чтобы всё это разгрести.
Я обычно объясняю такие вещи за $100 в час, для друзей - за 50.
Микросервисы - охуенная технология.
Правда, транзакций нет. И работает через Тулуп. Зато прогрессивно.
И люди постоянно заняты.
Ебанаты слили в унитаз все наработки последних лет 50 примерно.
И теперь делают велосипеды с квадратными колёсами из говна и палок.
Из каких-то маргинальных кейсов сделали систему. С которой кормятся тысячи паразитов. Пидарасы, просто слов нет.
Правда, транзакций нет. И работает через Тулуп. Зато прогрессивно.
И люди постоянно заняты.
Ебанаты слили в унитаз все наработки последних лет 50 примерно.
И теперь делают велосипеды с квадратными колёсами из говна и палок.
Из каких-то маргинальных кейсов сделали систему. С которой кормятся тысячи паразитов. Пидарасы, просто слов нет.
разбор полетов за чашечкой кофе когда заблочены деплои для всей компании ))
вы там сбербанк и тиньк в монолит поглотили? уважаю если так
Ещё один долбаёб порвался. Отношение к монолита/микросервисам отлично даёт представление о человеке. Яростно против микросервисов топят или вкатуны после курсов где их такому не научили, или сорокалетние сисядмины с атрофированным мозгом. Столь же яростно против монолитов топят уже-не-вкатуны которые успешно вкатились на работку, и сидят пердят над микросервисами, никогда грамотных монолитов не нюхали. А разгадка как всегда где-то посередине, здоровый человек понимает что это просто инструменты со своими применениями
Ну вот как быть с транзакциями, расскажешь мне, джуну?
У нас на работе именно из-за них не хотят монолит распиливать. Распределенные транзакции с сагами или двухфазным коммитом очень Весело на утреннике в рабочем состоянии поддерживать.
А без транзакций нам никак - нужно чтобы бд всегда консистентной была.
не может у вас БД быть консистентной с банком блять, ну принципиально
>Ну, если ты никогда не делал веб-сервисы, то питон - самый простой способ это начать.
Нет, не делал. Поэтому подумываю попробовать в уже знакомом Python.
>Ты получишь знания о том, как вообще делаются веб-сервисы. Независимо от языка.
Вот это звучит интересно. Вообще кто-нибудь итт перекатывался в Go из бэкенд-разработки на Python? Пришлось долго перенастраиваться на новый язык или просто освоили синтаксис, прочитали пару книг и уже могли идти на собесы? А может кто-то на работе переносил проекты с Python на Go?
За книги спасибо, я сейчас скачал довольно много литературы по Go, почти все из изданного в 2020-2023 на английском. По содержанию надо посмотреть и выстроить оптимальный порядок чтения.
В network programming бэкендеру стоит вкатываться или только первые главы с теорией посмотреть? Нашел книжку Network Programmability and Automation, что-то она мне понравилась по содержанию, там и Python, и Go, и Linux, и много чего еще затрагивается.
Он бы рассказал тебе, если бы знал.
Судя по тому, что он тут выдаёт - ему такими вещами лучше вообще не заниматься. И без него хватает специалистов в тулупах, ололо.
Мышление надо менять. Вам не база нужна, а данные из нее. И не все, а если хорошо подумать, милипиздрическая часть, которая к бизнесу относится. Если заменить подход с тотального контпроля над целосностью на ивент дривен, то окажется что транзакции и нахуй не нужны не распределенные, ни какие другие. Если нужна статистика, то она точно также собирается в процесс обработки ивентов, а не анализом портянок скл выхлопа.
это типа троллинг
>из фласка ты в итоге перенесешь тупа общие знания как писать бэкенд
У меня нет опыта в бэкенде. Так что общие знания не помешали бы.
>imo на петоне надо уметь писать, но учить лучше сразу гошку
Просто Python уже немного знаю. Читал еще такое мнение, что Go обманчиво простой язык, легко разобраться в синтаксисе и запускать какие-то программы, но язык предназначен для решения сложных задач, а для этого нужно много знаний не самого Go, а вообще про разработку и особенно бэкенд-разработку.
Вот тут () ссылка на обсуждение выступления Роба Пайка.
И в этом обсуждении, помимо прочего, разные люди пишут, что Го - это как раз таки замена Питону в бэкенде. Оттуда, типа, в основном и перекатываются, когда нужна производительность и типизация.
Да, Го - обманчиво простой язык.
>нужно много знаний не самого Go
Нет. нет, именно самого Го.
Там подводный камень на камне, буквально. Особенно после пыхи, питона или жс. Да и вообще.
Поздравляю, но вам в любом случае надо уметь проводить платежи и ты вряд ли лезешь напрямую в АБС банка, а значит тебе надо уметь отслеживать статусы платежей до их полного проведения и уметь перепрогнать платёжку с некоторых состояний.
Проверь, не пиздят ли там случаем?
> Поднимается в последнее стабильное состояние
Ага, ну раз ты любишь биллинг, давай на примере биллинга, он как раз охуенно подходит.
Смотри - у нас законодательство корректируется примерно 1-2 раза в год, в том числе с измнением форматов передачи данных и сроков их передачи.
Поэтому в своём биллинге вы должны были заранее заложить что откат на последнее стабильное состояние тупо невозможен, т.к. это состояние уже нахуй никому не сдалось. А также что на исправление проблемы у вас обычно есть около 4 рабочих дней.
И чем больше у тебя монолит, так больше модулей которые нет смысла откатывать, потому что внешняя система с которыми модуль работает же не сможет работать со старым модулем.
А что лучше - 4 дня лежать и нихуя не проводить, или 4 дня работать в контролируемо-сдеградировавшем состоянии и как писать сервис так чтобы состояние деградировалось контролируемо - вопрос для ваших архитекторов с бизнесами, но не для тебя, т.к. ты тупо даже не понимаешь границы применимости архитектур.
Во первых, примерно 30 из этих 50 лет индустрия решала задачи под мейнфреймы и на языках которые ты не слышал. Плавали, знаем. Во вторых, не слили, а проанализировали и поняли что эти наработки решали задачи 50/20/10-летней давности, а современные задачи они или решали плохо, или меняли их на груз своих проблем. А вот последние 10 лет индустрия как раз изобретает микросы и учится управлять получившимся флотом, что тоже нетривиальная задача.
> Правда, транзакций нет
Также как в монолитах - или у тебя используются двуфазные коммиты, или в любом случае решаешь проблемы на стыке трёх разных систем различными статус-сообщениями.
Я правильно тебя понял, что надо делать Python-проект на хорошем уровне с рефакторингом и всем остальным, как полагается, тогда в Go будет легче? А сколько после такого займет перейти на Go, если, допустим, полгода на Python что-то делал?
Тут анон пикрил советовал, например. Опыт проработки таких книг облегчит разработку на Go?
Сейчас смотрел книги и не понял, почему актуальное издание Refactoring от Мартина Фаулера с примерами на JS... JS норм язык, но почему именно он.
Причем тут вообще банк?
У нас свой собственный биллинг. Грубо говоря - пользователь пополняет счет на нашем сайте (типо кошелек), а оттуда уже бабки сами списываются. Если в кошельке бабок недостаточно, то автооплата должна сработать. И вот тут много всякой бизнес-логики еще накручено, с банком тут мы только на этапе выполнения самих платежей взаимодействуем, да и то, не лично мы - а через цепочку сторонних сервисов написанных другими командами и отделами.
Нужно сделать так, чтобы у юзера ни одной лишней копейки не исчезло, да и чтобы мы ни одной копейки не проебали по глупости. И вот сеньки наши говорят, что с микросервисами мы жидко пукнем с транзакциями в базе. У нас на целостность данных дрочат очень сильно, вплоть до того, что даже асинхронные действия (которые у нас через task queue сделаны) выполняются в той же транзакции, в которой мы условную фьючу этого действия создали. Для большей простоты - вот хотим мы обновить бабло на счету у юзера (предположим, что это тяжелая операция, которую нужно в асинхроне делать) - каждый раз для этого стартует асинхронная операция, которая ставится в очередь, и которую когда-нибудь воркер подхватит и выполнит. И вот когда мы эту операцию начинаем выполнять, то сразу же создаем транзакцию, в которой через хуй пойми сколько времени начнет сама бизнес-логика работать. Так мы в целом гаранитируем, что ничего не должно разъебаться между началом транзакции и ее окончанием после того, как таска в очереди отработает. Как такое с микросервисами и разными БД сделать я пока не очень понимаю.
ну я как раз к тому, что эти самые знания про разработку и бэкенд-разработку для сложных задач из круда на петоне ты не подцепишь, максимум основы. от круда на го ты хотя бы можешь в гошке поразбираться помимо основ.
не то, чтобы петон знать бесполезно, просто гарантированной ценности от дальнейшего изучения я бы не ждал.
Спасибо, посмотрю, почитаю. Если так пишут, то логично выглядит идея поделать бэкенд на Python и перейти на Go.
>Поздравляю, но вам в любом случае надо уметь проводить платежи и ты вряд ли лезешь напрямую в АБС банка, а значит тебе надо уметь отслеживать статусы платежей до их полного проведения и уметь перепрогнать платёжку с некоторых состояний
Статусы мы отслеживаем, но вот перепрогнать с определенного чекпоинта у нас уже вряд ли возможно. У нас просто ретраи идут какое-то количество раз, если платеж зафейлился, и все.
Вообще было бы интересно почитать статьи на тему того, как платежи должны быть сделаны, какие стейты должны быть, должна ли это вообще стейтмашина быть или что-то другое, итд... У нас они на похуй+отъебись делались несколько лет назад каким-то джуном, который уже уволился давно.
>Там подводный камень на камне
Это же в книгах нормально освещается? В Learning Go или Learn Concurrent Programming with Go, например.
Мне еще кажется полезной насмотренность в плане технологий, например, на собесах спрашивают, с какими технологиями работал и ты можешь рассказать про опыт работы с питоновскими фреймворками и пояснить, чем в конкретных случаях Go лучше и оптимальнее.
В целом опыт написания одного и того же с нуля на двух разных языках кажется не лишним.
>работать в контролируемо-сдеградировавшем состоянии и как писать сервис так чтобы состояние деградировалось контролируемо - вопрос для ваших архитекторов с бизнесами
В то время как монолит просто делает роллбек в стабильное состояние, у вас консилиум архитекторов разруливает деградацию системы, вот это го-вей, создать себе проблем и потом героически их решать.
>И вот когда мы эту операцию начинаем выполнять, то сразу же создаем транзакцию, в которой через хуй пойми сколько времени начнет сама бизнес-логика работать. Так мы в целом гаранитируем, что ничего не должно разъебаться между началом транзакции и ее окончанием после того, как таска в очереди отработает. Как такое с микросервисами и разными БД сделать я пока не очень понимаю.
да примерно так и работает. создаете в БД запись со статусом pending или вроде того. если банк ответил ОК, ставите джобу на обновление баланса кошелька и переводите в статус успеха. если не отработало/прошло больше N времени, то пишете что фейл. всё с ретраями. если ретраев не хватит, то по обращениям в саппорт фиксите отдельные кейсы.
Про такое лучше интернеты читать.
Гуглишь что-то типа go gotchas
Есть такой сайт "50 оттенков Go", лол.
Про садо и про мазо: http://golang50shad.es/
Есть ещё книжка 100 Go Mistakes:
http://golang50shad.es/
Я смотрю, к нам какой-то известный архитектор на гастроли приехал.
Вспомнился анекдот: теоретически у нас 3 миллиона доллларов, а фактически - две шлюхи и старый педик.
Вспомнился анекдот: теоретически у нас 3 миллиона доллларов, а фактически - две шлюхи и старый педик.
100 Go Mistakes:
https://scanlibs.com/go-mistakes-how-avoid-them/
50 оттенков на русском (старое, не обновлялось):
https://habr.com/en/companies/vk/articles/314804/
>Как такое с микросервисами и разными БД сделать я пока не очень понимаю.
Никак.
Такие вопросы обычно стыдливо обходятся микросервисными пропагандистами. Или идёт словоблудие и подмена понятий.
Или - есть ещё и такой вариант - всё будет, но очень-очень-очень медленно. И тогда становится непонятно - а нахуя вообще такое счастье?
Добавлю ещё, что для этого полезно почитать книжку с кабанчиком.
Она вот как раз именно про это.
Но, это совсем не лёгкое чтение.
Как делать распределенные транзакции придумали еще в Древнем Шумере за хуй знает сколько лет до нашей эры. Суть такова: резервирование. Когда тебе надо перекинуть деньги от Васи к Пете, которые находятся на разных серверах в разных базах, ты сначала делаешь Зарезервировать - уменьшить сумму в основной таблице и записать ее во вспомогательную таблицу, все в одной асид транзакции. У Пети делаешь так же - приход денег пишешь не в основную таблицу, а во вспомогательную. Потом, если все ок, делаешь Подтвердить и данные переносятся из вспомогательной таблицы в главную для Пети, а у Васи данные удаляются. Если ошибка - делаешь Отменить, реализация очевидна.
Так а зачем микросервисы вам если все так критично? Ты ножом есть пытаешься
Это предположительно сорокалетний сисядмин пожаловал
Нет, дурачок, в это время падающие микросервисы роллбекаются в стабильное состояние а не весь проект
>сорокалетний сисядмин
Оба раза мимо, лол.
>придумали еще в Древнем Шумере
Вот на этих ваших микросервисах оно примерно как в древнем Шумере и работает. Так же быстро и так же надёжно.
Это называется сага.
>Вот на этих ваших микросервисах оно примерно как в древнем Шумере и работает. Так же быстро и так же надёжно.
CAP теорема жи есть. Или быстро, или надежно, или работает только на локалхосте.
Да никто не говорит что микросервисы плохо.
Просто есть моменты когда их целесообразно использовать, а когда нет. Если у клиента сельский интернет магазин, то нет смысла ему такое делать. А проектировать типа " с заделом на будущее" это плохая затея потому что хер знает когда это будущее наступит и наступит ли вообще.
Просто есть моменты когда их целесообразно использовать, а когда нет. Если у клиента сельский интернет магазин, то нет смысла ему такое делать. А проектировать типа " с заделом на будущее" это плохая затея потому что хер знает когда это будущее наступит и наступит ли вообще.
>А проектировать типа " с заделом на будущее"
Это сразу два мема - преждевременная оптимизация (корень всех зол) и YAGNI.
Вообще, здравая рекомендация в таких случаях - пилить модульный монолит, который потом безболезненно делится на микросервисы, если это когда-то понадобится.
Но, это таки тоже преждевременная оптимизация. Т.к. модульный монолит сильно дороже обычного. Поэтому самая здравая рекомендация - minimum viable product. А там видно будет.
Микропенисы - это очень плохо, и в жизни, и в архитектуре. Для создания масштабируемой надежной архитектуры достаточно монолита с шардированием (call-based architecture) и не надо поднимать кластер кафки. Но тогда не получится разводить заказчика на бабло и чарджить деньги за облака, поэтому проплаченые хуесосы кукарекают за микросервисы снова и снова. Вкатунцы без опыта и без образования думают, что раз у дядьки борода и раскрученый канал, то дядька дохуя эксперт, а он всего лишь виртуальная шлюха и работает ртом в интернетах за деньги.
Я хоть и не люблю кубер, но масштабируемость и устойчивость это говно может обеспечить. Ценой ебических накладных расходов.
Ну и как говорится - миллионы леммингов ошибаться не могут. Или, иными словами, раз миллиарды мух любят говно, значит в говне есть что-то хорошее.
Только нихуя не пойму, с каких пор Go и "микро" употребляются вместе? Это когда ваша Goвнопрограмма статически линкуется с миллиардом библиотек и весит больше, чем весь объём жесткооо диска в 1993 году - это "микро"? Да идитн нахуй с такими "микро".
И самое смешное что эта многлмегабайтная програама АКА "микросервис" при ппреносе с одного линукса на другой не сттартует по причине разнвх версий либы для системных вызовов.
ПИ-ДА-РА-СЫ, нахуя вы налепили стольао говна в исполняемом файле, если он непереносим между разными версиями линуксов? Такой хуйни не помню со статически сл нкованными Си программами, которые весят в десятки раз меньше.
Бля, системные вызовы ядра Линукс не менялись со времён до появления Go. Какую хуя гниды не сумели встроить в Гошные либы прямые вызовы к ядру?
А ответ прост - они хуесосы. Вот и весь сказ.
Оэуенная задумка, кривейшая реализацию.
>call-based architecture
Может быть cell-based?
Но, это же такой же облачный микросервисный понос, насколько я понял после беглого гуглинга? Баззворды заебали уже
Лол, только сегодня проверил - набор скриптов на питоне + сам питон, упакованные в 1 экзешник, весят меньше, чем программа на го, которая делает примерно то же самое.
Был такой случай — нашел типа подработку через телегу, чел русский, заказчик из Израиля. Платит в крипте. Делает типа свойстартап: SaaS букинг сервис. Этот русский чел ему делал год или больше сервис, причем работал один, и заказчик тоже один, то есть сам себе и менеджер и хуенеджер, причём с коммуникациями у него не очень было, только письменный ынглиш среднего уровня.
Говорят, осталось только платёжный шлюз сделать отдельным микросервисом. Захожу на проект — а он ему там нахуярил микросервисов ДЕСЯТЬ (пикрил), типа на каждый пук отдельный сервис, отдельный контейнер с ларкой, лол. Ну у меня на тот момент заказов было много, я не стал сильно погружаться, залутал немного бабок с него и на хуй послал.
Наверное, до сих пор доделывает свой стартап, лул.
На картинке не 10, а почти 20.
Некоторые названия выглядят довольно смешно для микросервисов.
Заказчик - дурак.
Исполнитель - жулик (либо тоже дурак, не знаю).
А ты что там делал?
Да, cell-based. По русски соты, но по словам "сотовая архитектура" выдает всякое про gsm сеть.
Это не микросервисы, это классический монолит, но с ограниченным количеством юзеров. Логика простая: если наш сервер держит лям юзеров, а два ляма нет, то поставим два монолита и все будет ок. На входе, еще на уровне ngnix, вытаскиваем из jwt токена userid и сразу роутим на нужный сервер. Если один сервер отвалится, приложение будет недоступно только части юзеров, а не как в микросервисах хуяк и все лежит. Деплоймент простой. Долгая сборка, да, но тебе один хуй надо прогнать 100500 тестов перед выкаткой на прод, лишние пару часов роли не сыграют. Дорогая и сложная кафка не нужна, все транзакции крутятся в одной бд, репликации быстрее. Сплошной профит, но не получится раздуть команду на порядок, как с микросервисами.
Я же написал, залутал пару тыщ долларов за парочку крудов и съебал.
Да, все дураки кроме тебя, зато у них деньги есть. Исполнитель заряжает сейчас $40-50/hour, типа не ебаться архитектор и фуллстек разраб. Тот еврей я думаю тоже не бедствует, разжился где-то криптой и мутит свой стартап.
На картинке скрин из постмана, там не всё сервисы. По факту их было одиннадцать:
account
slot
activity
role
employee
customer
company
book
dispatcher
sms
И я должен был ещё один впилить - billing, который должен был включать тарифные планы и их оплату. ТЗ чёткого не было, всё на коленке и "по ходу дела".
>С чего ты Прочитал что ассемблер быстрее? какой-нить gcc/g++ намного лучше тебя оптимизирует асм
Твоё утверждение справедливо для больших проектов. Но если нужно написать библиотечную функцию, то компилятор отсосёт у меня. Впрочем, скорее всего, тот анон, которому ты отвечал, не сможет захуячить оптимальнее компилятора - по стилю его поста видно, что он никогда не заглядывает в код, который ему генерит компилятор.
Оптимизировать маленькую функцию лучше компилятора я смогу в виду того, что компилятор ограничен ABI, а я нет.
Но при этом, надо отдать должное, в современных компиляторах мегаохуенные оптимизаторы. Намедни мне надо было реализовать "очень быструю подпрограмму" и я смотрел что генерирует компилятор с разными ключами оптимизации и игрался с исходным кодом, пытаясь исходным кодом и ключами выжать каждый такт по быстродействию. Охуительнейше оптимизируют современные компиляторы, моё почтение.
Собственно сочетание хорошего компилятора и ручной оптимизации исходного кода и есть способ выжать из железа максимум возможностей. Но я к чему - если не говорить о всём проекте, а лишь о некоторых функциях, то опытный программист всё же умнее компилятора и способен захуячить код лучше. Потратив при этом кучу времени, сил и энергии.
А я наоборот жду безпитонный линукс, чтобы от этого тормозного говна избавиться в реальных системах.
Но, зачем же делать это отдельными микросервисами?
Какова цель? Разработчик - один. Нагрузок каких-либо в принципе не предполагалось, это очевидно. Обычный небольшой монолит на чём угодно решил бы проблему легко. Зачем вся эта ёбань? Год (как минимум) труда? Зачем?
>сочетание хорошего компилятора и ручной оптимизации исходного кода и есть способ выжать из железа максимум возможностей
Осталось ещё понять зачем - и всё будет заебись.
Не мог бы ты привести конкретный пример того, чем тебе мешает питон в дистрибутиве линукса? Он каким-то образом мешает тебе писать скоростное говно на си7
Ну у того чела в резюме появилась строчка "Full MicroService Architect (MSA) with separated DB and API logic on the backend (aggregation, MSA-transaction)" , кек. И денег он выжал немало. А на остальное - насрать. Ну видимо он налечил спонсору проекта что проект будет держать миллиарды запросов от юзеров со всего мира. Вот открытие для него будет, когда он поймёт что надо было делать MVP, а все бабки вливать в рекламу.
Мне просто он идеологически неприятен и не нужен в системе, как, например, джаваскрипт или руби. Вот перепишут портаж на го и тогда...
Дегенеративный хуесос, ну почему ты решил, что "микро" это про то чтобы занимать мало мегабайт? И вообще бинари на го должны крутится в докере, и вот тебе совместимость между всем подряд
Это вообще-то 2 разных человека написали.
И я () не "дегенаративный хуесос", я это просто для смеха написал. Потому, что в обоих случаях у меня получилось ~7.5 мегабайта. И мне это показалось забавным.
Но, при этом, размер бинарников в Го я вообще проблемой не считаю, хотя, знаю, что многим не нравится. И вообще, сборку в толстый независимый бинарник я считаю одной из главных фишек го.
>надо было делать MVP, а все бабки вливать в рекламу.
Золотые слова.
Сдохни в муках, быдло. Чем медленнее, тем лучше.
>независимый
С хуя ли он независимый? Он между линуксами не совместимый.
Я поебался и собрал себе k9s из исходников, правда давненько. И при копировании с одного дистрибутива другой он оказался нерабочим. Уносите своё говно.
а если у тя какая-то чатсь монолита не будет вывозить нагрузку, допустим по авторизации полдьзователей, ты будешь этот жирный монолит скалировать? а если потом еще-что притупится? получаеся тебе придется поднимать реплики тех же монолитов, токо теперь это будет жирно делать. По поводу микросервисов, типа если отпадет то все попало.. Это ни так, тупо делаешь несколько реплик и все. Также плюс у микросервисов это скорость релизов и прогонка тестов. Т.е. ты меняешь условно какую то фичу в блоке авторизации и тебе не надо прогонять весь монолит... Ну минусы на счет кафки это да, есть точка отказа, но тут нужны хорошие девопсы чтобы поддерживать инфру.
Там проблемы с системными вызовами из-за сборки мусора, как я понял. Вот тут эту тему затрагивают:
https://news.ycombinator.com/item?id=38872362
В смысле - является ли Го языком для системного программирования (скорее нет, чем да) и почему.
Вообще там охуенный тред, я прямо с удовольствием почитал.
Авторизация делается просто: ты отправляешь реквест всем своим серверам и ждешь, пока кто-то ответит ок или отвалится по таймауту. Таймауты настраиваются в одном месте, тебе не надо бегвть по всем микросервисам и настраивать каскадные таймауты в каждой микропиське. Для скаллирования используются виртуальные шарды. Скорость релиза одного микросервиса - это хуйня, релиз делается по бизнес фичам, которые затрагивают несколько сервисов и для которых надо прогнать все тесты. Про тайм ту маркет придумали инфоцыгане, пользователю лучше получить стабильную версию раз в неделю, чем каждый день видеть, как сайт сломался то тут, то там.
>разные люди пишут, что Го - это как раз таки замена Питону в бэкенде.
Надо только уточнить, что замена в Гугле. Раньше стандартным языком SRE был Питон, теперь Го.
А есть кто в крипте работает?
Ещё не поздно выкатываться?
Поделитесь хорошими курсами/книжками.
- по крипте в целом, что такое и как работает биток я понимаю, а вот что за новомодные стейкинги/свопы/лайтнинги, как несколько крипт живут на одном блокчейне, как исполняется код, и прочее - вообще хз. Биток был прост.
- что обычно разрабатывают под блокчейн на горшке? Вот курсы об этом
- по разработке на солидите или что там можно
- если знаете, то бизнесовым материалам тоже буду благодарен, в смысле назера все это
Ещё не поздно выкатываться?
Поделитесь хорошими курсами/книжками.
- по крипте в целом, что такое и как работает биток я понимаю, а вот что за новомодные стейкинги/свопы/лайтнинги, как несколько крипт живут на одном блокчейне, как исполняется код, и прочее - вообще хз. Биток был прост.
- что обычно разрабатывают под блокчейн на горшке? Вот курсы об этом
- по разработке на солидите или что там можно
- если знаете, то бизнесовым материалам тоже буду благодарен, в смысле назера все это
ага. только теперь если ломается сайт, то он или ломается полностью или аналогично кусками, если вы правильно пишете код. но зато фиксы в прод теперь за 10 минут не раскатить.
монолит тебя от багов не избавит, равно как и релиз раз в неделю автоматом стабильность не даст. можно и микросервисы разрешить только в определенное окно (пятницу вечер) деплоить. получишь собственно нихуя.
Скоро появятся нано сервес аркичектур. И это будет трендом.
Каждый файл в отдельном сервисе, потом каждая строчка кода отдельно... Это же aws lambda и прочая serverless залупа, не? Кстати, почему она не стрельнула?
>почему она не стрельнула?
Я думаю, потому, что это была чисто маркетинговая залупа.
Попытались впарить народу что-то типа налога на воздух - сколько раз вдохнул - столько и заплатил. Ещё и воздух не слишком свежий. Народ не оценил.
И вот ты сделал Подтвердить, а потом у Васи данные перенеслись, а у Пети - нет. И что?
Я вообще не понимаю, зачем ты это написал. Потому, что по сути дела ты ничего не сказал вообще.
Зато асид транзакции приплёл для красного словца, лол.
В чем суть?
>Кстати, почему она не стрельнула?
На больших нагрузках это становится пиздец как дорого. Но есть юзкейсы когда она вполне оправдана и я знаю компании которые используют.
Можно выставить в продажу любую совершенно нелепую хуйню, по совершенно несуразной цене, и всегда найдутся те, кто это купит.
Пацаны, чо сча со вкатом? Тостер 7 с хуем лет, пишу тосты на бэк уже несколько лет на петухевене, всякие кафки, постгри, grpc, графкл. Надоело автоматить и не хочу в менеджмент. Думаю покатиться в суровый бэк, ибо в принципе и так большинство всего умею из современной разработки. Думаю над языком. Рассматриваю гоху. Миддлы нужны сейчас, что с рыночком вообще?
Перекочуйте
Нет
>Я вообще не понимаю
Фронтенд разработку обсуждают в соседнем треде, тебе туда.
Пишешь книжку, продаешь, лутаешь бабло, ездишь по семинарам, торгуешь ебалом. За кодинг платят мало и это бабло ненадежно и немасштабируемо.
> Сдохни в муках, быдло. Чем медленнее, тем лучше.
Иди нахуй
> С хуя ли он независимый? Он между линуксами не совместимый.
> Я поебался и собрал себе k9s из исходников, правда давненько. И при копировании с одного дистрибутива другой он оказался нерабочим. Уносите своё говно.
Ну и схуяли это вообще проблема? Ты собрал бинарник для роботы в одном рантайме, ожидаемо что в другом он может не заработать. Парирую наперед твой ожидаемый тупорылый тейк о том что "ну бинари же больше по размеру, значит там очевидно собран весь рантайм мира", а ты почитай 10 минут о процессе компиляции в го и что вообще находится в бинарнике, может перестанешь выставлять себя дебилом на анонимном интернет форуме
Анонсы, сложно на вас перекатываться после питона? Работаю с ним относительно плотно, знаю несколько паттернов из ооп, ну и всякие там солиды, киссы и драи.
Будет стойкое ощущение что возвращаешься обратно в каменный век
Перекатиться несложно, сложно найти работу. Где-то в треде писал анон синьор питон, он пытался устроиться на го мидла. Везде отказали, потому что нужен прувен экспириенс именно на говяшке и похуй, что ты уже десять лет пишешь под клауды на другом языке.
Лол да. Я после сишарпа знатно прихуел. Го более 10 лет, а в стандартной библиотеке нет нихуя. Зато я понял, зачем на собесах спрашивают алгоритмы, тебе реально придется на го самому все писать. Бонусом идет ебанутая система модулей и ебанутый ооп, которого нет, но он есть.
Вернули 2007
>Можно выставить в продажу любую совершенно нелепую хуйню, по совершенно несуразной цене, и всегда найдутся те, кто это купит.
Несуразная хуйня получилась у твоей мамки. Лямбды полезны для обработки редких сообщений, это выходит дешевле, чем постоянно держать включенный инстанс. А если их ещё и пачкой присылать, то экономия будет ещё больше.
Какой фронтенд, вася? Ты читать умеешь?
Речь о транзакциях в микросервисах.
Откуда вы, блядь, лезете?
Ты просто не умеешь программировать.
Как и большинство шарпоёбов или питоно-блядей.
>микросервисы на сообщениях
А ты особенный.
> не написал ос на ассемблере - не программист
Такие как ты скоро станут не нужны, их заменит чат-гопота.
А такие как ты стали не нужны ещё лет 30 назад
Да ты совсем дурачок.
Поди лучше bubble sort научись делать.
Зачем мне делать бабл сорт? Я лучше проект сделаю которые будет приносить деньги.
>Я лучше проект сделаю которые будет приносить деньги.
Приходи когда сделаешь. Пиздеть - не мешки ворочать.
Так уже, и не один
Ну с этим у меня в принципе нет проблем, у меня начальству похуй, на каком стеке я пишу, т.к. босс не технарь команда разработки внутри не-разработческого отдела, техдиру вообще поебать, главное, чтобы не сломали ничего.
Я думал взять го в качестве запасного аэродрома, если вдруг с питоном что-то пойдет по пизде.
>А ты особенный.
Да! В отличии от среднестатистического Го-разраба - у меня есть мозги.
Скиньте реальный проект на го, чтобы не пустая болванка, а прям с реальным содержимым.
Докер, кубернетс
Это штучные приложения, а надо что-то более типовое, связанное с реальными задачами на работе
Где ознакомиться с лучшими практиками, сформированными сообществом разработчиков?
https://github.com/golang/pkgsite
оно конечно отличается от реальных микросервисов в компаниях, но пример хороший.
>Докер
И эта поебень тоже на Go нвписана? Ну охуеть теперь!
А пацаны-то думали что только Kuber-мать-его-netes.
Сначала Майкрософть двигала электронную промышленность, выпуская overblow систему и софт, а нынче эстафету перехватил Гугол.
А по сути, во всём виновать Линус-мать-его-Торвальдся, введя неймспейсы в ядро. И понеслось-поехало. Затем подключилась Красная Шляпа, наплевав на Unix way и пересадив полмира линуксоидов на systemd. Только Патрик Фолькердинг стойко держался, послав ну могучие хуи systemd. Затем какие-то арабы и еврей, все французского гражданства, придумали Docker на основе всей этой беды в ядре. Шоб им пусто было.
Тем временем Гугол пилил свою систему оркестрации Borg. И тут им подвернулся Docker. И начался пиздетс. Появились новые профессии, новые языки и возможность любому Васяну из подвортни, прочтив пару статей и HowTo развернуть собственный кластер. И потекло говно по трубам по проводАм. И настал новый безумный безумный безумный мир.
>а нынче эстафету перехватил Гугол.
Ты недавно из анабиоза вышел, что ли?
Этому всему уже сто лет в обед.
Меня удивляет, с какой скоростью тупое мудачьё бросилось делать свои маленкие гуголы. С микросервисами и кубернетисами. Нахуй не нужные при их реальных нагрузках.
Дружно слили в унитаз годами наработанные технологии, и начали городить огород с нуля. Просто потому, что им сказали, что так надо. Умиляет смотреть на всю эту петушню на ютубе, как они с умными рожами несут тупую хуйню, отсасывая друг другу в прямом эфире.
В индустрии чувствуется острая нехватка людей с мозгами. Которые могли бы находить новые пути, а не громоздить тонны говна для решения простейших проблем. Отрасли нужны герои, а пизда рожает айтишников.
>во всём виновать Линус-мать-его-Торвальдс
Нет, виноваты пидары, огородившие BSD анальными лицензиями. И в результате мы теперь имеем вот это вот говно вместо юникса.
>Тем временем Гугол пилил свою систему оркестрации Borg.
И до сих пор пилит. Но это сугубо внутренний продукт, его опенсорсить смысла нет.
Го тоже был внутренним продуктом. Но программисты в гугле же получают много, а значит надо изучать их инструменты чтоб в конце попасть туда.
Вот и нехитрая причина почему го пихают везде.
так всё и было. нищие пыхеры с завода проникли в штаб-квартиру гугла и шантажом заставили пайка его открыть го публике
Borg не функционален без инфраструктуры. Докер он изолирован, в нем можно запустить любое приложение. А в Borg можно запустить только приложение которое для него собрано. Borg-у нужен логгер, балансер, мониторинг, архитектура датацентров, система прод конфигов.
Докер - это надстройка над стандартным функционалом ядра, всего навсего.
Перекат
Почему на го так мало вакансий?
С чего начать:
- В обязательном порядке проходим Go Tour:
https://go.dev/tour/welcome/1
- Читаем документацию прямо по порядку (пункт "Learning Go"): https://go.dev/doc/
- Ознакамливаемся с общим roadmap по изучению языка и сопутствующих инструментов: https://github.com/Alikhll/golang-developer-roadmap (постоянно обновляется сообществом)
Литература:
- Донован, Керниган "Язык программирования Go"
- Также хорошие книги для начала: https://www.golang-book.com/ и https://www.practical-go-lessons.com/ (веб-версия - бесплатная и хорошо подходит для новичков в программировании)
- Книги из списка https://github.com/dariubs/GoBooks
Полезные ресурсы:
- Сборник паттернов и инфы по микросервисам: https://microservices.io/
- Обновляемый список с пакетами: https://github.com/avelino/awesome-go
Прошлый тред: