С чего начать:
- В обязательном порядке проходим 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://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
- Обновляемый список с пакетами: https://github.com/avelino/awesome-go
Небольшая конфа треда: https://t.me/golang2ch более чем живая!
предыдущий утонул тут https://2ch.hk/pr/arch/2023-07-12/res/2665435.html
> В обязательном порядке проходим Go Tour
А есть на русском?
В вс коде же можно спокойно поставить временный комментарий и на импорт, всё работает по принципу максимального сохранения кода, который ввёл программист.
Тебя чем комплексное число не устроило? Это буквально SSE, что мастхев в вычислениях
>они
А может это оне, а не они
https://ru.wiktionary.org/wiki/оне
Скорее вопрос почему они не сделали перегрузку операторов чтобы я сам мог навасянить себе тип для денег
Так это стандартный гоимпортс так работает, так шо претензии в первую очередь к ним. Да, говно.
Сори за мат, но у меня жопа просто полыхает.
Ты че, самый умный что-ли? Пиши как все и не выебывайся
За мат извини
Указатель внутри структуры лежит, при копировании структуры он копируется, вот и всё.
Про сравнение с nil - судя по сорсам, работа со слайсами, как и работа с мапами, переписывается рантаймом на работу с ансейф поинтерами (или я даун, ресерчил 15 минут с телефона) .
https://go.dev/src/runtime/slice.go
Потому что долбоёбы. Но вообще тип деньги как минимум требует валюту, чтобы 10 баксов не сложить с 10 песо, требует точность на основании валюты, ну и конечно конвертация. Понятно что такая масштабная библиотека выходит за пределы возможностей аутистов из Го-тем.
ну представь, что слайс это структура которая может быть равна nil, потому что в компиляторе реализовали сравнение слайса с nil.
https://github.com/golang/go/discussions/54245#discussioncomment-3800568
Как читаю этот коммент каждый раз смеюсь и плачу
Здарова, погроммисты.
Как в го можно сделать следующую штуку?
Условно есть последовательность значений в файле, допустим
x = 1
y = 2
z = 3
...
И тд, они могут повторяться в рандомном порядке, нужно сложить все значения x, все значения y и тд.
Итак вопрос - как это обработать через каналы, чтобы без явного указания
if val == "a" {
chanA <- val
}
if val == "и" {
chanB <- val
}
и прочее
СПАСИБО!
Нихуя не понял, что ты хочешь сделать.
Ну можешь завести массив из 26 (или какая у тебя там мощность множества) каналов и по val - 'a' искать индекс канала, в который пишешь.
Но вообще я не понял, нахуй тебе там каналы, сложение элементов это явно не боттлнек программы ботлнек в сисколле, который ты не распараллелмшь, от конкарренси ты скорее лососнешь, чем выйграешь. Ебани просто мапу [byte]int, или рун-инт в особо запущенном случае, че как не родной.
c awk это просто echo 'x = 1
y = 2
z = 3
x = 11
y = 22
z = 33' | awk 'BEGIN{FS="="}{a[$1]+=$2}END{for (k in a) print k "=" a[k]}'
> Итак вопрос - как это обработать через каналы, чтобы без явного указания
> if val == "a" {
> chanA <- val
> }
> if val == "и" {
> chanB <- val
> }
это очень широкоизвестная проблема в программировании, многие люди бьются над её решением
>ботлнек в сисколле, который ты не распараллелмшь
ссд уже везде, дед https://chrispenner.ca/posts/wc
Коллега, удалось её решить за полином, или все еще np полная?
Емнип у го отдельный P под чтение/запись, я с этой точки зрения срал.
>Емнип у го отдельный P под чтение/запись
у го есть отдельный тред с нетполлером, но он только для неблокирующих сисколлов (ну и по сути в нём чтение/запись не происходят, он просто говорит, что файловый дескриптор готов и можно шедулить горутину, которая хочет читать/писать в этот фд).
обычные файлы не поллятся, поэтому сисколл будет сразу в треде, который крутил горутину. если чтение надолго блочится, то его P/очередь горутин отойдут другому треду, а он останется висеть пока сисколл не вернется и потом пойдет чиллить с тредиками в пул тредов.
> var _ Bar = &Foo{...}
Unterprogrammiersprache
перейти на дебиан анстейбл или рач.
или можешь из васянского PPA установить себе гошку https://github.com/golang/go/wiki/Ubuntu
>васянского PPA
Придумали же менеджеры версий для этого, зачем систему засирать какими-то васянскими пакетами, чтобы они тебе потом кровь пили при обновлении?
>менеджеры версий
зачем засирать систему менеджерами версий, если есть менеджер пакетов из коробки?
Чтобы в системе не пересекались разные версии среды, когда у тебя много проектов - для каждого можно хранить свою версию языка и свой изолированный набор модулей, чтобы обновляться и откатываться одной кнопкой без васянских репозитариев, которые наставят непонятно что непонятно куда, и обнаружить в один прекрасный день что какая-то зависимость сломалась после очередного обновления системы и начинаются детективные истории и головняк, когда всего этого можно избежать одним простым инструментом в виде менеджера версий, который отделит мух от котлет (операционную систему от рабочего инструментария).
в отношении гошки это литералли решение несуществующих проблем. мб иностранные специалисты из ноды/петона привыкли иметь тысячу окружений под каждый из проектов, в гошке в 99% (100%, если ты круды для бекенда пишешь) случаев достаточно иметь последнюю версию конпелятора.
да и конкретно гошка из ppa вряд ли сломается, она не линкуется динамически с какими-то либами, которые могут с системой обновиться и стать несовместимыми.
ну и плюс менеджеры версий никак не защищают от того, что у тебя система обновится, а твой софт будет слинкован с неактуальной версией какой-то либы вроде glibc. просто у тебя все говно внутри юзерской папки будет храниться и не будет конфликтов с системными пакетами на уровне файлов
чево? слайс именно хранит значения своего типа. слайс интов хранит инты, слайс поинтеров хранит поинтеры, а слайс интерфейсов хранит интерфейсы
>>2919190
анонимные функции же уже есть
Он косноязычный просто, хочет чтобы слайс был объектом, внутри которого лежит массив, а не просто указатель на массив.
В чем проблема возвращать чаннел в роли иттератора? табу? Буквально ничем отличаться не может
А в чём, простите, разница? Как ты собираешься выделять память в куче без указателя на неё?
map[int8]chan, ну или строку вместо инта, если у тебя больше, чем одна буква, зачем мозг ебать себе...
В какой статье, какого кока? Ты хотя бы ответ разворачивай что ты именно хочешь сказать, а не намеками
Надеюсь аннотации никогда не добавят в го. Именно из-за них джава превратилась в какашку.
Аннотация это просто интерфейс для запуска жирной цепочки действий,не понимаю батхерта
Ну ,что поделать,в джаве нет геттеров сеттеров по умолчанию,не считая рекордов. Мне кажется @Getter @Setter над классом это намного лучше чем в коде по два метода на каждое поле
Го делали хохлы русофобы?
В чём проблема сделать поля публичными? Сами же создали проблему и придумали кривой костыль для её решения.
Нарушает инкапсуляцию. Нельзя встроить логику в получение и установку значения
А ломбок у тебя дофига логики встраивает? Там тупая заглушка, как и в 99% случаев ручного написания. И ничего это не нарушает, просто все привыкли писать эти какашки, даже не задумываются зачем это нужно.
Логику может встраивать не конкретно не лично пользователь,а например ioc контейнер,считай спринг. Поэтому для сериализации и десереализации ему нужны геттеры сеттеры
Сколько лет до этого работал? Какие ощущения были от перехода на новый стек?
вы каждый тред этот вопрос будете задавать долбоебы?
когда appspot задепрекейтил го 1.9, все туры на древней гошке начали пятисотить, включая русский. васян, который делал русский тур, забил на свою хуйню, так что её убрали
>Надеюсь аннотации никогда не добавят в го.
Уже есть, пока ограничено, но это вопрос времени.
Даже простейший круд на джаве можно написать в 2-3 раза быстрее, чем на го.
Если не брать какой-нибудь gin, а взять обычный роутер вроде chi, то даже примитивная задача вроде достать из урла "/<uid>/update", передать его в сервис, а оттуда сходить в базу, становится какой-то чрезчур сложной. Банально в if err != nil очень легко становится запутаться, если их становится очень много. И из-за этого контроллер, который должен был быть написан в 3-4 строчки, разбухает как скотина, потому что на любой пук приходится городить if err != nil. Даже если закрыть http.Body не щмогли или джейсон неправильный пришел к нам. В общем хуйня/10, если нужно много бизнес-логики накидывать.
Для инфра проектов, вроде кубернетиса или докера наверное хороший инструмент, но не для крудов ебучих.
Нарушает инкапсуляцию и всё законы вселенной встраивание логики в дата обджекты. Кстати, забавно, что главный архитектор джавы Brian Goetz прямо называет свидетелей секты геттеров-сеттеров дебилами и the "learn java in 21 days" crowd.
Тем временем шёл 2024 год...
Это кстати отличная иллюстрация подхода го: вместо простого, общепринятого, универсального решения (макросы/метаданные) сделать сложное, нетипичное и узкоспециализированное, а потом героически это преодолевать на протяжении следующих эн лет.
У вас же там питухон и c++ со своим фреймворком.
Зачем тебе gouleng?
>сделать сложное, нетипичное и узкоспециализированное, а потом героически это преодолевать на протяжении следующих эн лет
Основная и единственная проблема - уже есть куча хуйни которая ожидает через рефлексию найти геттер или сеттер, а не публичное поле.
Так публичное поле это синтаксический сахар для геттера.
Не вкатун, работаю псевдодевопсом-сисадмином. Писал только на баше и на C давно. По работе программировать не нужно, и так все отлично. Но из каждого утюга верещат, что TRVE devops инженер должен знать go.
Я открыл учебник по go, пытаюсь что-то делать и мне физически плохо, как будто мне в мозг через ухо хуй вкручивают. Скажите, это нормально или у меня просто синдром утенка? Стоит дальше бороться или лучше за другой язык взяться?
Вообще, поясните, зачем девопсу Go, на нем же даже скрипт не написать.
Если ты в кубере метрическими контейнерами не жонглируешь, то нахуй не нужон.
Достаточно посмотреть на фото создателей языка, чтобы все стало ясно
Ну серьезно, в чем причина такого подхода?
В крудах и калопроводах практически всегда, если возникла ошибка, то ее нужно просто протолкнуть до респонса, завернуть в джейсон и отдать пользователю.
При этом ты не можешь просто использовать net/http или chi какой-нибудь, потому что количество действий, которые приводят к ошибке в контроллере попросту велико и нужно городить дополнительные абстракции, чтобы это хоть как-то читалось.
Например взять тот же пример, когда в калопроводе нужно достать /<uid>/update, причем сам метод - POST
Итого:
1) readAll из request.Body -> requestJson
2) json -> requestStruct
3) requestStruct -> service
4) service -> responseStruct
5) responseStruct -> json
6) json -> httpWrite(response)
А, ну и еще когда uid достаешь, тоже может ошибка возникнуть.
Вопрос, как правильно в этом вашем гоуленге писать контроллеры? Так, чтобы не ебаться с фреймворками, а просто взять gin и эти самые ручки писать быстро, просто и не захламляя код тяжелыми проверками ошибок?
>Банально в if err != nil очень легко становится запутаться, если их становится очень много. И из-за этого контроллер, который должен был быть написан в 3-4 строчки, разбухает как скотина, потому что на любой пук приходится городить if err != nil. Даже если закрыть http.Body не щмогли или джейсон неправильный пришел к нам.
А ты делай как я:
if err !- nil { panic(err) }
а наверху
defer func() {
if r := recover(); r != nil {
return InternalServerError
}
}()
>Ну серьезно, в чем причина такого подхода?
Говнорутины. Предполагается, что ты будешь запускать десятки горутин и пролучать ответ через каналы. И в таком сценарии эксепшены не работают.
Ну ок, допустим мы из реквеста будем Body читать в массив байт.
Случилась ошибка. Мы ее хотим в джейсон положить и вернуть фронтам.
Когда возвращаем ошибку (то есть http.Write делали), то может возникнуть еще одна, новая ошибка. Что тогда?
Я просто не знаю какие ошибки как и в каком виде нужно обрабатывать.
Код с паниками не пройдет код-ревью, тимлид попустит и пригрозит увольнением за такое.
Вкатун спок! Тебе просто надо подсунуть эту идею тимлиду, так чтобы он думал что это его идея. И вы даже можете написать микрофреймворк - Autumn.
С целью трудоустройства попробуй освоить востребованную профессию, а не программирование. И вообще съеби в прикреп.
Я программист-любитель, а теперь хочу стать профессионалом
Отказывают ли в трудоустройстве тем, кто задает тупые вопросы.
>>2931518
Лично я заметил, что все, кто работают, сидят в голэнде, а безработные как раз и сидят на всяких вскодах и вимах.
Есть у тебя функция рекурсивного поиска определенных файлов по пути и надо что-то сделать для найденных файлов. Вот ты и передаешь функцию.
Понял, дурында?
Хуй знает как в го,но файловый поток у меня в языке можно читать так:
while(bytes = stream.readBytes() != null{
Че то делаем
}
Нахуя городить рекурсию?
Какой поток?
Ты обходишь дерево фс вглубь и для каждого совпадения надо применить какой-то код.
Files[] list = folder.listOfFiles()
И дальше форичем по этому с вызовом FileUtils.readInTypeYourWant
А там ещё вложенные диры и ты соснул.
Суть не в рекурсии, а что ты передаешь свою логику в универсальную функцию. Это и есть функции первого класса.
Учить и учить, кароч.
И как тут поможет вложенная функция? Проверишь если тип это файл а не директория и применишь только к файлу?
Это не связано, ебать тебя в сраку. Просто это типичная задача, понятная почти любому, а тебе нет, что симптоматично.
Ты можешь передать функцию чтобы принтить, можешь передать функцию чтобы удалять и т.д.
Сука,если мне нужно принтитить или удалять я передам объект в функцию принт или делит. Нахуя нужен это фасад-метод,это же лютый говнокод,абстракция над поведением
Ты передаешь функцию, что и требовалось!
Но если вместо просто функции тебе нужна логика сложнее, то ты передаешь своб функцию со своей сложной логикой.
>Нахуя ее принимать в качестве параметра?
Например, чтобы обработать некоторые данные которые связаны с какими-то другими данными которые ты не хочешь отдавать наружу.
Например https://go.dev/src/io/fs/walk.go тут прячется как именно идет обход директорий, просто вызывается твоя функция которая должна обработать данные. Другой пример из ФП это всякие map/reduce.
>Нахуя возвращать функцию из функции?
Это чаще всего применяется в интерфейсах типа:
>type Iterater interface {
>Iter() func() (any, bool)
>}
С помощью полученной функции можно итерироваться по любой коллекции или вообще чему угодно.
Для адепта ООП выглядит как наркомания, но по факту здесь решается проблема параллельного выполнения кода и изоляции ресурсов, в распределенных системах нельзя просто взять и вызвать какой-то метод откуда захочется.
Ну вот у Котлина есть эксепшены, но обработка ошибок из корутин это еще больший пиздец чем в Го. https://www.linkedin.com/pulse/exception-handling-coroutine-amit-nadiger/ - 100500 разных неочевидных способов обрабатывать ошибки. Экспшены хороши если у тебя линейный код в одном потоке, а если потоков становится много и они запускаются паралельно, то простой советский код возврата - проще и понятнее.
Почему исключения не работают при многопотоке? Любое исключение,выброшенное из таски убивает таску вот и все, соответственно их просто нужно обработать
>Любое исключение,выброшенное из таски убивает таску вот и все, соответственно их просто нужно обработать
Об этом то и речь, что.у тебя десяток тасок работает и одна сфейлилась. И дальше начинается мотня, эти таски можно проигнорировать, эти ретрайнуть, эти фатальные - и надо кансельнуть все живые таски и выбросить эксепшн выше.
Просто напиши на котлине пример который запустит 3 задачи:
- ошибки первой - игнорировать
- вторую ретраить 3 раза
- третью - канселить все и бросать эксепшн выше
и увидишь как там все """легко и элегантно""" получается.
Не уверен,что можно их ретраить кстати. А обработка пишется внутри метода run или call в зависимости от типа. То есть у тебя не разбросана эта логика в классе экзекьюторе,все находится прям на месте
>Любое исключение,выброшенное из таски убивает таску вот и все, соответственно их просто нужно обработать
Убивает, а дальше то что? Вверх по стеку - а там ничего нет, для родительского процесса что там внутри таски происходит - тёмный ящик, то есть родительскому процессу надо какое-то сообщение слать, а как его послать? Обработать ошибку в таске и засунуть в return вторым аргументом, вот так вот, без всякой магии и сахара.
Я увидел только 2 способа: блок try catch и хэндлер. Просто примеры на разных вариантах использования корутин.
>Не уверен,что можно их ретраить кстати
А хули нельзя, то? Просто ещё раз запускаешь го/ко рутину и всё.
>А обработка пишется внутри метода run или call в зависимости от типа. То есть у тебя не разбросана эта логика в классе экзекьюторе,все находится прям на месте
У тебя есть метод прочитать настройки пользователя, он не может знать критично это вызывающе у или нет. Если функция показывает пользователю текущие настройки, то критично. А если там нужно прочитать предпочитаем часовой пояс чтобы отобразить дату, то не критично, можно пояс браузера использовать. Критичность определяет вызывающий, а не функция. Это как если бы функция чтения файла решала критична ошибка или можно проигнорировать.
Ты видимо не понял,таска умирает если из нее наружу выбрасывается исключение,само собой в этом случае класс где происходит запуск может это обработать. А если ты,например,получил исключение внутри таски и залогировал его не выбросив наружу то таска продолжит свое выполнение
общие модельки, которые в бизнес-логике широко используются (вроде Coords и более доменные штуки) в models.
модельки реквестов/респонсов к внешним сервисам - в пакетах с клиентами в clients/somemicroservice123.
если у метода с бизнес-логикой много аргументов и хочется их тупо запихнуть в структ, то структ можно рядом с функцией объявить. если это метод для интерфейса с несколькими реализациями и нужно чтобы на вход они принимали одну и ту же структуру, то в models.
>если это метод для интерфейса с несколькими реализациями
и тут я имею в виду не реализация + мок, а несколько реальных реализаций
>Такой кейс как ты описал не загоняется в экзекьютор
Наркоман что ли? Мы ту про горитуны говорим, при чем тут твой экзекутор?
Я не ебу что такое горутины,я влез в спор исключительно из-за ошибок и исключений
Да всё понятно, семантическая часть языка дизайнится на отъебись, без оглядки на прогресс в области, ощущения как будто на турбо паскаль возвращаешься.
Под макросами очевидно имеются в виду лисп-макросы (метафункции). Это the one true way.
Аннотации конечно костылёчек, но всё же более общее решение, чем кривотеги в го, которые вообще просто от баллы на отъебись сбоку прилеплены по принципу "и так сойдёт, потом разберёмся".
>аннотации\макросы еще больший костыль чем теги гошки
Сколько слышал наездов на аннотации, ни разу не видел внятной аргументации почему это плохо и как надо вместо этого делать.
Аннотации прикольны, пока не начинаются проблемы из-за них, потому что решить их очень сложно. Фактически тебе придётся изучить все кишочки своего фреймворка и понять где возникает конфликт, а потом придумать костыль, который эту проблему решает.
Когда идёшь по го-вей, то просто пишешь свой бойлерплейт и не паришься. Любая проблема решается в твоём коде, а не где-то на стороне.
>Аннотации прикольны, пока не начинаются проблемы из-за них, потому что решить их очень сложно. Фактически тебе придётся изучить все кишочки своего фреймворка и понять где возникает конфликт, а потом придумать костыль, который эту проблему решает.
Это всё общие слова которые ничего не стоят. Так можно про всё что угодно сказать, про фреймворки, про либу, даже про какие-то фичи языка.
>Когда идёшь по го-вей, то просто пишешь свой бойлерплейт и не паришься. Любая проблема решается в твоём коде, а не где-то на стороне.
Т.е. ты неилюзорно предлагаешь мне самому писать сериализацию в джсон? Потому что у тебя детская травма, в бытность джуном не смог разобраться с аннотациями и накричал тимлид?
>Стоит продолжать или идти сразу в раст вкатываться?
Смотря для чего ты вкатываешься. Если для души катись к хуям в Раст. Если тебе работу работать - Го.
ну честности ради даже если ты не пишешь свой личный бойлерплейт на каждую хуйню вроде сериализации жсонов, то по крайней мере ты собираешь свой стек из кубиков и можешь перейти на другой кубик, а не порабощен анальным эндоскелетом фреймворка
Да в принципе 50/50, только вот смотрю на го и вакансий не густо. И в целом душа больше лежит к вебчику, к бэку, а go для этого более подходит, нежели раст. Вообще, что больше с питоном в связке встречается, раст или го?
Вместо того, чтобы нести порожняк предложи решение конкретной проблемы. Есть библиотека сериализации JSON. Как кастомизировать формат сериализации?
>только вот смотрю на го и вакансий не густо
Ты ролфишь? На Го полно вакансий. Это на Расте из 3,5 штуки.
Ты смотрел свежий индекс вката? Там падение на четверть.
>Ты смотрел свежий индекс вката? Там падение на четверть.
Нахуй мне всякое говно смотреть, я же не вкатун.
>прочитать доку к либе
Где будет написано что:
1. Ты пиздабол.
2. Чтобы управлять сериализацией используйте аннотации.
*input.Field здесь сначала будет получена вся структура и потом у нее возьмётся значение поля или будет получено только значения поля?
А как ты представляешь, как она "достаётся из памяти"? Она ведь не на диске лежит, а в RAM - Random Access Memory, то есть доступ к элементам в памяти осуществляется произвольно.
В указателе хранится адрес объекта. Когда ты его разыменовываешь ты обращаешься к участку памяти, на который указывает этот адрес. То есть даже в этом случае никаких затрат памяти не производится дополнительно. Когда ты обращаешься к полю этой структуры, адрес этого поля высчитывается неким образом и так ты можешь достать значение этого поля.
Для полной ясности я бы посоветовал ещё дизасемблированный код посмотреть.
Ну меня больше интересует при коде:
input.Field
input.Field2
(Х повторений)
Будет каждый раз обращение к памяти или го умный и закеширует структуру чтобы потом к ней обращаться
>Будет каждый раз обращение к памяти или го умный и закеширует структуру чтобы потом к ней обращаться
В общем случае будет 2 обращения к памяти, в лучшем случае компилятор оптимизирует. Детали как всегда зависят от конкретного кода.
Короче если планируется обращаться к большому количеству полей по указателю лучше разыменованное значение сохранить в переменной и обращаться уже через нее
>Короче если планируется обращаться к большому количеству полей по указателю лучше разыменованное значение сохранить в переменной и обращаться уже через нее
Нет.
Если есть проблема с перформансом - надо бенчмаркать, а потом уже на основе этого оптимизировать и снова бенчмаркать. А эту ебалу с оптимизацией на уровне интуиции оставить.
А в чём этот анон не прав? Как минимум это хорошее начало - уже не будет тратиться ресурсов на разыменование
Преждевременная эякуляция оптимизация - корень многих зол. Кстати, кто это сказал?
И с удивлением узнал, что в стандартной библиотеке нет способа сделать reverse sort для слайса чисел, например. И в книжке рекомендуется отсортировать прямо, а потом в цикле переставить в обратном порядке.
Но, а как же "... имеет богатую и универсальную стандартную библиотеку"? Это типа дохуя богато и универсально?
Вообще, при более-менее близком знакомстве c Go складывается впечатление, что Го-программисты люди не ленивые, и дублирование кода для них обычная практика, например. И сто километров для них вообще не крюк.
не могу подсказать добавили или нет, но насчёт умерший - уже не особо актуально
https://www.reddit.com/r/golang/comments/14xyido/the_gorilla_web_toolkit_project_is_being_revived/?rdt=43258
первым языком за который получал бабки был голанг, так что не согласен со всеми этими выражениями "на го не берут джунов" и всё в этом духе
в мск огромный набор постоянно в гиганты, типа вб, озон
Сколько лет назад это было? Сейчас рыночек поменялся и почти на всех языках берут от мидла и выше только.
Подобные вещи проверяются один раз и не меняются в зависимости от кода. На уровне бест практисов нужно это закреплять
Охуительные истории. А до мидла как? Или то что раньше называли джуном теперь считается мидлом?
Только не надо пздеть про перенасыщенность отрасли, вакансии есть, просто в отрасль проникли туророгие русские кабанчики, которые хотят 20 летнего сеньора с личным ютубом, твиттером гуглом и с опытом работы 25 лет.
Все рисуют фейковый опыт и рассказывают как они уже 2-3 года где-то поработали. Порожек входа в айти теперь выше.
Многие, кто давно вкатились, до сих пор этого не понимают и советуют молодым то, что уже не актуально. По их советам новичок будет получать отказы на уровне кадровой службы, даже до собеса не дойдёт. Причём для го эта ситуация наиболее острая. На других языках с этим полегче и порог входа не такой крутой.
Чет меня не взяли недавно в озон, авито и ещё один стриминговый сервис, коммерческого опыта на го нет, хотя базовый синтаксис изучил и курс на работе прошел. Коммерческий опыт: последние 4 года на пистоне (автоматизация всякой хуйни -> джанга -> фласк, грпц, фастапи), и до этого ещё 5 лет пердолился с бд. С ноября ищу новую работу и уже потихоньку начинаю обмякать, без коммерческого опыта на го никто не хочет брать.
Я много лет писал на джава и до твоего поста даже не задумывался про такое ограничение. У меня реально ни разу не возникала задача отсортировать числа по убыванию. В 99.999% приходится сортировать объекты, а там всегда есть компаратор.
>>2943347
>Вообще, при более-менее близком знакомстве c Go складывается впечатление, что Го-программисты люди не ленивые, и дублирование кода для них обычная практика, например. И сто километров для них вообще не крюк.
Это правда.
Смотрю этого дядечку последнее время. Он уже 2 года учит го и не может вкатиться. Сплошные отказы. Хотя опыта в других языках у него десятки лет.
https://www.youtube.com/watch?v=aPu46ozF-JQ
Так что я тоже не верю в эти сказки, что типа выучил го и тебя на работу взяли. Наверно сейчас реально вкатиться только если внутри фирмы переходите с питона или РНР на го.
>На уровне бест практисов нужно это закреплять
Ну да, ну да, удачи тебе поработать с кодом, где разраб до тебя накостылил своих бестолковых оптимизаций с указателями, а после обновления рантайма в системе плавают непонятные баги в многопотоке, которые возникают в зависимости от фазы луны и отладка больше напоминает гадание на кофейной гуще. Не просто так вся эта залупа абстрагируется от работы с памятью, не можешь удержаться от байтоёбства - пиши на сишке.
Речь не о каком-то метапрограммировании,поведение не изменится от того будешь ли ты делать разыменование на каждый гет переменной либо же сохранишь в переменную разыменованный объект. Здесь нет никаких сложных оптимизаций,байтовых сдвигов и тд и тп
Что там под капотом происходит одному богу известно, и представь себе гипотетическую ситуацию: чел прихоидт на собес, его спрашивают, какие оптимизации применял и как лечил ботлнеки, а он такой отвечает - ну я пердолился с указателями на структуры. Никто в здравом уме не возьмет на работу человека, у которого появляются мысли заниматься такой хуйней.
Нет братан,это обычный вопрос от человека который посмотрел пару лекций по го. На уровне чем линкед лист от эррей листа отличается. И эта информация известна не только богу. Вопрос элементарный для человека,работающего с го больше чем две лекции,так что если ты не в курсе такого то это исключительно твоя проблема. Я подожду ответа более опытных и компетентных анонов
>Это правда.
Я очень много лет пишу на джаве. И ещё много на чём.
И среди всего этого, Go кажется мне наименее выразительным языком. Несколько раз пытался начать писать на нём что-то посложнее, чем просто учебный код, и каждый раз реально начинает тошнить.
Т.е., в нём практически отсутствуют эффективные средства выражения мыслей и построения абстракций. Интерфейсы - да, но, блядь, как же убого это сделано. Для большого проекта - это просто пиздец. И, параллельно, куча подводных камней просто на ровном месте. Здесь играем, здесь не играем, здесь опять играем, а здесь вообще рыбу заворачивали.
Именно поэтому дублирование кода повсеместное. Потому, что нету эффективных средств не дублировать.
Как сказал Дейкстра - инструменты, которыми мы пользуемся, оказывают глубокое и тонкое влияние на наше мышление, и на саму нашу способность мыслить. И в этом плане Go на меня оказывает примерно то же действие, что и встроенный язык 1С.
Здесь нужно понять, тратится ли при этом больше памяти.
Далее - по результатам - понять, что тебе важнее - память или производительность (и там и там разница будет копеечная).
Ещё лучше - сделай бенчмарк производительности (как советовали выше). Цикл на миллион повторений и сравни время. Всё полезнее, чем хуиту на дваче писать, лол.
>Как минимум это хорошее начало - уже не будет тратиться ресурсов на разыменование
При написании кода думать про производительность нужно, спору нет. Но тут речь идёт о том, что нужно думать про глобальные вещи: как сократить число чтений из базы, как уменьшить число вызовов сторонних сервисов, не повторять одну и ту же операцию дважды и т.п. А микрооптимизации на уровне доступа по указателю это херня которую не заметишь на уровне лишнего чтения из базы.
Конечно если у тебя какой то инфраструктурный проект типа базы данных или кэша тут такие оптимизации будут уместны. Но тогда тоже следует начинать с профилирования, бенчмарков и анализа сгенерированого кода.
Тут полностью согласен. Но зато код очень прямолинейный и простой для понимания. Тут нет такого как в Спринге: повесил аннотацию и класс начал валидировать реквесты и по стектрейсу вообще не видно твоего кода. Единственная головная боль, это то что интерфейс не реализуется явно и найти имплементации не работает. Разбираться в существующем коде долго из-за того что его много, но очень просто.
>код очень прямолинейный и простой для понимания
Да, всё так. И это хорошо.
Плюс - охуенная concurrency из коробки и много чего ещё интересного.
Поэтому я и продолжаю пытаться постичь этот дзен. В смысле - наработать интуицию, принять такие подходы.
Иначе давно бы нахуй бросил.
Даже попытка взять энвы превращается с функцию с лукапами, который разработчик каждый копирует из проекта в проект.
Сделай сам.
Какие-нибудь функции типа GetOrDefault(environment, paramName, defaultValue)
Думаю, дело в том, что довольно многие Го-девелоперы просто не очень умеют в настоящее программирование. Поэтому, дублируют код даже там, где можно не дублировать.
Печально что при изучении новой и современной технологии для решения конкретных проблем приходится сталкиваться с такими детскими болезнями, вроде 2к24 на носу, искусственный интеллект уже код пишет, а тут приходится откровенно ерундой бестолковой заниматься, это как надевать портянки с лаптями вместо нормальной обуви.
У нас есть сервисы на питоне и го.
Чсх, сервисы на питоне быстрее.
РНР сейчас тоже с каждой версией всё быстрее и многопоточку сам оптимизирует. Так что может го и не нужен будет в будущем.
Go - очень сложный язык.
Синтаксис простой, да. Вот только язык - это не синтаксис.
Да и простота бывает такая, которая хуже воровства. Вот как в Go.
Так что максима "Го не для вкатунов, а для свитчеров" - вполне себе справедлива. В смысле, что человек, не умеющий программировать, ничего путного на Го не сделает, если это его первый язык. Разве что под постоянным руководством ментора.
Не совсем понятно, зачем тебе Го после Питона.
Но, если таки нужен - не лезь в крупные компании, и не ищи сразу много денег.
>что в стандартной библиотеке нет способа сделать reverse sort для слайса чисел, например. И в книжке рекомендуется отсортировать прямо, а потом в цикле переставить в обратном порядке.
>Но, а как же "... имеет богатую и универсальную стандартную библиотеку"? Это типа дохуя богато и универсально?
ну проблема тут в том что автор не знает про slices.SortFunc и sort.Slice
И правда не знает, лол.
Автор - рубист в прошлом. Хули с него взять.
При этом резюме у него внушающее.
Он сингапурец, работает в госконторе, что-то типа наших Госуслуг, и занимается там вот этим вот самым. В послужном списке - 3 изданных книги по Руби, и эта, четвёртая, по Го (сент. 2023).
Sau Sheong has been in the software development industry for more than 28 years and has been involved in building software products in many industries and using various technologies. He is an active member of various software development com‐ munities, previously Java and Ruby, but now focuses mostly on the Go community. He runs meetups and gives talks at conferences all around the world on Go and also on topics related to his work, especially on sustainability, smart cities, government, and AI. He also runs GopherCon Singapore, one of the largest community-led devel‐ oper conferences in Southeast Asia, and has been doing so since 2017. Sau Sheong has written four programming books, three in Ruby and the last one in Go.
У меня кореш джуном заскочил по счастливой случайности, даже собеседования не было. В резюме напиздел про опыт, на собеседовании тимлид дохуя занят был, поэтому поздоровался, бросил пару коротких фраз и сразу нанял. Хотя кореш не то что особо умный и к тому моменту он только синтаксис знал, программистом не работал никогда. Я, посмотрев на него, тоже пытаюсь повторить, но пока ем говно. Я еще и человек склонный сдаваться, на нервяке постоянном, типа без работы сижу, а лет уже дохуя. Но всегда хотел в погромисты, понимаю, что если не сейчас, то никогда в жизни, поэтому всякую хуйню учу и стараюсь не охуеть от количества информации, которой не знаю.
>и стараюсь не охуеть от количества информации, которой не знаю.
Я тут выше писал про то, что преждевременная оптимизация - корень многих зол (это сказал Дейскстра).
Так вот, когда ты вкатываешься, и думаешь, что нихуя не знаешь, и вместо поиска работы пытаешься доучивать то или другое - это и есть так самая преждевременная оптимизация.
Чем больше мы узнаём - тем лучше понимаем, как много мы ещё не знаем. Это порочный круг.
Поэтому - если есть база - морду кирпичом, и вперёд.
Проверено многократно.
Мне до сих пор бывает немножко стыдно, когда я вспоминаю, сколько я напиздел о своих навыках в резюме, когда устраивался на первую работу в IT много-много лет назад. Это была просто чудовищная хуцпа. И это сработало.
Тут правда, есть один нюанс - я был хорошо мотивирован, был готов отвечать за базар и впахивал как конь. И реально охуевал от количества информации, которую приходилось учить. Только это была реально нужная информация, а не мои домыслы и предположения о том, что нужно.
ну например можно добавить в глобальный .config/git/ignore или в .git/info/exclude у отдельной репы
https://git-scm.com/docs/gitignore#_synopsis
Существует ли на самом деле проект, который использует только стандартную библиотеку и драйвер базы данных?
Если нет, возможно, сусликам следует перестать говорить, что стандартной библиотеки достаточно, или хотя бы перефразировать ее.
Все до единой библиотеки маршрутизации для го это обертки для дефолтного http разной степени говености, так что тейк не засчитан
В идее есть же плагин для .gitignore
И там есть даже пресеты для типичных задач, и можно одной кнопкой настроить игнор всей этих идеевских штук, это не только папка .idea, там ещё много чего.
Ты немножко неправильно понимаешь, что такое "стандартная библиотека". Высокоуровневые веб-серверные штуки и не должны там быть.
>без гитигнора
Они игнорят гитигнор же.
Есть разные мнения о том, стоит ли это делать.
Можешь просветиться в интернетах.
А вообще - это на твоё усмотрение, особенно, если речь идёт об учебных проектах. А в не-учебных тебе скажут, как надо.
Стандартная либа - это чтобы _не_ копировать. И не изобретать велосипед.
Потому что тащить говяху туда, где не нужен мнопоточный перфоманс будет только ебанутый
Такое ощущение что ты вбираешь между пыхом и голенгом, только вот выбор этот такой же бредовый, как выбор между трамваем и карьерным самосвалом, главный вопрос в том, какие технические проблемы ты собрался решать?
У меня на го спросили мапу, слайсы, стринги и стрингбилдер, ебучий sync пакет и тд.
В то же время на пыхе спрашивали в основном про постргрю и прочую ебку базы
Мне надо устроится на работу, чтобы жить на что-то, а водить трамвай или самослав - второстепенный вопрос.
Не понял, это что, троллинг тупостью?
Стандартная библиотека - это то, что входит в дистрибутив языка.
Все эти пакеты, типа fmt или sync.
Тогда учи PHP, тут даже думать нечего.
Го вообще не очень годится на роль первого языка, и, тем более, первой работы. А пыха - вполне себе да.
Я, кажется, понял, что ты имел в виду.
Если ты хотел сказать, что неправы те, кто дрочит на то, что надо использовать только стандартную библиотеку, а остальное хуярить самому, то я полностью согласен, это идиотизм.
Просто я тут выше писал про бедность стандартной библиотеки Го, и продолжил на той же волне, лол.
Можешь привести конкретный пример того, что тебе хотелось бы посахарить?
Нет, голаг изначально должен быть необоснованно неудобным и сложным, в этом суть языка. Главное занять программиста чем нибудь, чтоб разработка была маскимально долгой, заставлять его писать одни и те же паттерны снова и снова, повторять одни и те же конструкции.
Тогда кодревьюеру будет приятней читать код, а qa делать тесты. Голанг это не язык для программистов, а язык для менеджеров этого самого программиста, чтоб всесторонне контроллировать его и сделать мозг максимально шаблонным.
>Оно же само пишется
Да.
Но, к сожалению, оно само не читается.
А на чтение кода программист тратит в несколько раз больше времени, чем на написание.
Зато авторевьюится. Это важно. Важнее читаемости. Ведь го это язык для менеджеров.
бля анон, суть в том, что в Go тебя не спрашивают про знание фреймворков. точнее спрашивают, но на уровне "что-то видел, с чем-то работал". они от стандартной либы далеко не ушли - ну там будут какие-то QoL вещи ну и хуй с ними. я лучше на собесе посмотрю как челик вейтгруппами/мютексами умеет пользоватся и поспрашиваю про глубины шедулера/гц. но мы всякими файберами/фастхттп не пользуемся, у нас свои велосипеды. ну и если ты юзаешь исключительно горм и не можешь sql запрос написать, то вероятно пройдешь нахуй.
я был на одном собесе, где меня о фреймворках спросили, и это была какая-то залупа в совковом офисе. ну я ответил "горилламукс для роутинга и стандартная либа в основном, без фреймворков" хз точно почему, но мне отказали в итоге. ну я потом оферы от озона/авито получил, так что вспоминаю для рофла
>>2944834
ну для простых сервисов её достаточно. роутер не поддерживает параметры в путях, но для внутренних сервисов можно тупо post для всего использовать и передавать значения в теле. рестуху для внешних апих конечно хуево делать на стандартной либе, пока там параметры не поддержали, но ищью у них на гитхабе такая открыта.
ну и бля там в стандартной либе нет драйверов, только интерфейс для драйвера и либа чтобы его использовать более-менее удобно. так что хуй знает как ты хочешь с нереализованным интерфейсом БД пользоваться. sqlx если што от sql не особо далеко ушел и переписать на ручной сканнинг Rows тривиально
Ты рисовал фейковый опыт в резюме, чтобы приглашали на собесы?
нет, я на хх нашел стажерскую вакуху без опыта/откликнулся/прошел, потом рекрутеры сами писали
Опять "только стандартные либы"...
Вы олимпиаду делаете или рабочие сервисы? Либо ты пздишь, либо тебе очень сильно насрали в голову на работе.
хз о чем ты говоришь. я нигде не сказал, что мы используем только стандартные либы. я сказал, что нормальным конторам знание ваших фреймворков нахуй не нужны. нужно знание языка.
и да даже если бы мне насрали в голову на работе, то в чем проблема, когда мне платят, а тебе нет? )))
Что то не пойму какие ты задачи макросами решаешь и метафункциями(даже лень читать что такое, по названию понятно что говно)_
Это все похоже на один большой костыль на уровне архитектуры, т.е. теги гошки это самое безобидное что есть.
>Лучше никак, чем так.
Мне кажется, ты не понимаешь сути Го.
Копирование кода, велосипеды, ехал-цикл-через-цикл и т.п. - это _официальные_ бест практисиз в Го. Если ты такое не любишь - тебе надо что-то другое.
Ты джавист? Я - да.
Это не те интерфейсы, не надо вестись на "знакомые слова".
Го - это совсем другой язык, и пишут на нём по-другому.
А зачем го такое? Почему синтаксис сделали таким? То что оно там внутри быстрее это ок, но почему сам язык сделан так, это как-то помогает разработке?
Физически плохо - это нормально, это мозг потрескивает просто. Можно и поехать, да, если слабый духом, бьёт по самооценке. Но если мотивирован, то обычный проходной этап.
Сам также вкатывался в течение нескольких лет: берешься за что-то, и бьешься головой о стену, очень плохо, не выдерживаешь, бросаешь, восстанавливаешь психику и силы, через какое-то время повторный цикл, но уже продвигаешься чуть дальше, и так раз за разом постепенно выходишь на плато, где тебе в целом комфортно, а новые испытания уже не так больно даются, и пусть не просты, но вполне решаемы.
Просто вся эта хуйня контринтуитивна, в природе ее нет, в нас это не заложено природой, поэтому сначала нужно сломать мозг, а это больно и неприятно, выдерживают единицы, самые стойкие и мотивированные, остальные на каком-то из промежуточных этапов бросают, не выдерживают, прям как в меме про js и проститутку.
Потому что хороший инструмент стоит денег, и отбивает их с лихвой
Житбрейнсы не зря хлеб жуют, их анализатор синтаксического дерева с индексацией, инспекциями, рефакторингами и исправлениями - это реально полезная хрень, которой больше нигде нет
Да, оно жрет много ресурсов. Но оно того стоит, когда распробуешь. А ресурсы сейчас - вопрос небольших денег, даже днищепрогер с одной ЗП себе позволит nvme + 64gb ddr5 + 7950x, и будет в хуй не дуть, кайфуя в умной ide. На современном железе оно работает так же быстро и легко, как любой блокнот.
А сейчас к ide они еще и прикрутили ии-сопрограммиста, который всю рутину берет на себя, и с которым можно обсудить наилучшее решение, в котором он тебе подскажет наиболее подходящий функции, о которых ты даже не слышал, забыл, или не подозревал/не думал что их можно использовать в таком контексте
В общем после их ide уйти на что-то более тупое уже нереально, к хорошему быстро привыкаешь
А зачем вообще нужны интерфейсы? Какую пользу они приносят? И в джавовском и в го понимании
Сложно объяснить.
Это другой язык, другой подход к разработке. Более низкоуровневый. Проще в одном, сложнее в другом.
Ты пытаешься понять это, не выходя из (например) джавы.
А надо выйти.
Вообще, если на низкоуровневых языках не писал никогда ничего, и нет никакого представления о том, как оно вообще всё внутри работает, то это будет сложно.
Другой вопрос - зачем?
Чтобы понять - попробуй читни какую-нибудь годную книжку по Го - Cloud Native Go, например.
Охуенный вопрос.
Интерфейсы нужны чтобы абстрагироваться от реализации.
Ты говоришь: Мне нужна хуйня, которая делает Икс, и мне вообще похуй, как она это делает. Например, в джаве один и тот же код может читать данные из файла, из порта, из строки и т.п., в зависимости от того, какая реализация интерфейса Reader в него была передана. В го - примерно так же, только сделано по-другому.
>Cloud Native Go
Уточню - имеется в виду книжка "Cloud Native Go: Building Reliable Services in Unreliable Environments" O'Reilly, 2021 год, см. scanlibs.com.
Есть ещё другая, с таким же названием (но, с другим подзаголовком), более старая и немножко не о том.
Я работал раньше с контроллерами сименса для нефтегазовых шкафов управления. Мне байты и вот это всё как вода для рыбы. Сейчас же работаю на питоне.
Меня больше смущает излишний синтаксис и в целом неудобство самого языка.
К примеру, чтоб на питоне запустить две асинхронные таски, достаточно сделать
await asyncio.gather(task1(), task2())
или другими способами. Можно их создать через циклы и передать какую-нибудь очередь для воркеров к примеру, которая заполняется в другом месте
q = asyncio.Queue()
workers = [worker(q, i) for i in range(10)]
await asyncio.gather(*workers)
То же самое на го делается более громоздко.
когда илон маск изобретал го он хотел сделать так чтобы в языке было минимум синтаксиса чтобы все было просто для того чтобы в код было просто читать
Какой-то очень неудачный пример "неудобства" Го.
Как раз именно асинхронщина и конкурентность там сделано просто охуенно.
В отличие от питона, в котором ещё и настоящей многопоточности нет, одна видимость.
И ты загляни в исходники этого asyncio. Посмотри, что там.
Это вообще довольно высокоуровневая вещь, с event loop etc.
А в Го - немножечно другое, более низкоуровневое. Есть какие-то либы с event loop, но, я не разбирался.
Но, Го - язык действительно неудобный. Корявый просто пиздец.
Такое ощущение, что специально делали максимально непохоже на Си и си-образные языки. Чтобы на каждом шагу программист спотыкался, и вспоминал, что это не Си, не Джава, а Го, ебать его в сраку.
Алсо, тут стоило бы ещё вспомнить о том, что всё, что делает Гугол, является совершенно неюзабельным говном, лол.
>Это вообще довольно высокоуровневая вещь, с event loop etc.
Почему в го не сделали удобные интерфейсы для работы со всем этим? У меня основной бугурт от этого в говяхе. Ты сначала изобретаешь их заново, а потом только пользуешься, хотя реализация, в целом достаточно общая и могла быть сделана заранее уже в языке.
мимо
>Почему в го не сделали удобные
Потому, что как в том армейском анекдоте:
- Солдаты, мне не надо "быстрее и удобнее", мне надо, чтобы вы заебались.
На самом деле, этому Говну многое можно было бы простить.
Да вообще всё можно было бы простить.
Кроме одного - глядя в исходник невозможно понять, из какого именно файла того или иного пакета взят тот или иной символ.
Это делает язык вообще непригодным ни для изучения, ни для программирования.
Читать исходники стандартной библиотеки - просто невозможно. В пакете 30 файлов, с хуй пойми какими названиями, и все друг на друга _неявно_ ссылаются. Т.е. в этом файле используется функция MakeZalupa, угадай, в каком из оставшихся 29 файлов она определена? Как эту срань можно использовать для промышленного программирования - для меня загадка.
И это, блядь, новый язык, _специально_ разработанный для того, чтобы код, блядь, в исходниках, было _просто_ читать, понимаете, да?
Воистину, го-девелоперы люди не ленивые, и грузить го-вно в самосвал чайными ложками им совершенно не трудно.
>Кроме одного - глядя в исходник невозможно понять, из какого именно файла того или иного пакета взят тот или иной символ.
нахуя тебе файл знать? на ревью либо файл будет в диффе, либо его не будет в диффе и тебе все равно придется его открывать в редакторе. в 2к23 все редакторы умеют к имплементации переходить.
так ты объяснить можешь зачем тебе файл видеть, когда в пакете не может быть дублирующихся идентификаторов?
То что там костыльная асинхронность это и так известно, главное что она работает и работает как надо.
Я чисто про сам синтакс, как вот это вот всё писать.Я работаю с кодом, с буковками скобочками и вот этим всем, а что внутри мне не интересно, хоть сингулярность.
Это разные вещи, понимаешь?
Система на базе event loop (т.е. постоянно выполняющаяся в отдельном потоке программа) и просто языковые примитивы для конкурентности.
Я знаю как она работает. Про многопоточность тоже знаю, про многопроцессорность. Чем отличаются. Я асинхронность использую чаще, тк только в основном запросы делаю.
Твой вопрос скорее про то, почему какую-то штуку типа питоновского asyncio не сделали частью стандартной библиотеки.
Ну, так в джаве тоже нет такого. И в перле нет. И вообще нигде, я думаю. Потому, что это не уровень стандартной библиотеки. А вот в питоне есть.
Ну так питону уже очень много лет. И всё это там успело, так сказать, кристаллизоваться. И это был довольно непростой процесс. И только потом это стало частью языка.
Кстати, не секрет, для какого рода задач ты это используешь? Какие запросы?
Обычная сортированная mq с тасками по 2-10 запросов. Очереди появляются динамически, кажду должен обслуживать только один воркер.
Сделана кастомно через редис zset, т.к раббиты и прочие не устраивают по скорости, настройкам и излишним фичам. Заранее не известно сколько таких очередей может быть и как они называются, кроме префикса.
Если кратко - обычные чаты со сторонними апи, с дополнительными запросами кроме самих сообщений.
А какая предметная область?
Коммерция, финтех, что-то ещё?
Кафку не пробовали? Мощная вещь.
Кафку хз. Я с тех пор вообще критично отношусь к сторонним сервисам, да и зачем, если 100 строк кода делают то же самое, только без дополнительных штук. Редис у меня и так есть, а разворачивать ещё один сервис немного сомнительно.
Необходимости в кафке пока нету. Я пробовал яндекс очереди использовать, там задержки пздц, у меня же мессенджер, а не запланированные задачи. Очередь нужна только чтоб сортировать список по времени и не отправлять все сообщения разом.
Она занимается тем что перессылает сообщения из одних мест в другие. Самого чата как такогового нету.
Для того чтобы узнать в каком именно файле лежит условная MakeZalupa(кому вообще не похуй в каком) тебе нужно зажимая ctrl кликнуть по MakeZalupa. Плюс мне очень интересно что же это за другие яп которые тебя в этом плане устраивают
Сегодня читал исходники net/http на pkg.go.dev
Зажимал ctrl, как ты советуешь - никакого результата.
>что же это за другие яп которые тебя в этом плане устраивают
Python, Perl, Java.
Не, я понимаю, что в IDE оно удобнее.
На джаве я только в IDE и пишу, разумеется.
Но, речь была не об этом, а о дизайне языка.
В котором как-то дохуя implicit вещей, с учётом того, что он задуман как читаемый, понятный и т.п. А по факту - корявая хуита (просто визуально тяжело воспринимается) и концов хуй найдёшь (см., например, неявную имплементацию интерфейсов там, где она должна быть явной).
сегодня читал https://docs.oracle.com/en/java/javase/12/docs/api/java.net.http/java/net/http/HttpClient.html и чет вообще не понял как сорсам перейти
В вскод же есть го ту дефинишон. Не работает? Когда последний раз на го писал вроде работало.
В питоне с метапрограммирование это пздц как бесит, до какого-то времени вообще непонятно было как и где инициализируется это говно, особенно motor, ладно сейчас показывает норм с новым pylance
Так если тебе, дружок, не нравится неявная имплементация интерфейсов (утиная), ты об этом и пиши, а не вкидывай невнятную хуйню о том как тебе дико мешает что при читании сорцов в браузере видите ли не показывают файл где лежит искомое
>утиная
Хуиная.
Как правило, в большинстве случаев имплементация явная.
И надо было просто добавить соответствующий синтаксис.
А там где утиная - тоже добавить, только другой.
Потому, что explicit is better than implicit.
И всегда приятно, когда концы сходятся с концами.
Это снижает cognitive load.
Код на нормальном языке читается на уровне подсознания.
То же и про файлы.
Почему, блядь, в JS/TS/Java всегда понятно, откуда что берётся, а в Го - нет? Просто похуй? Кому надо - тот найдёт? Понимаю.
Говно и палки, как и было сказано.
Про более тонкие вещи даже говорить не хочу.
С другой стороны, у такой реализации интерфейсов есть один большой плюс.
Можно делать интерфейсы пост-фактум, для уже написанного кода, чужого или своего. А потом добавлять новый код, использующий и реализующий их.
https://youtu.be/PF8d1r-jTN8
Будет смешно если в уже написанном коде метод иначе называется. Мне кажется проще явный клссс адаптор шмякнуть как в Java8
>Можно делать интерфейсы пост-фактум, для уже написанного кода, чужого или своего.
В нормальных языках: создают интерфейс, описывают контракт функций.
В говно языке: пишут код, а потом под него подгоняют интерфейс.
Game 1: 3 blue, 4 red; 1 red, 2 green, 6 blue; 2 green
Game 2: 1 blue, 2 green; 3 green, 4 blue, 1 red; 1 green, 1 blue
Game 3: 8 green, 6 blue, 20 red; 5 blue, 4 red, 13 green; 5 green, 1 red
Game 4: 1 green, 3 red, 6 blue; 3 green, 6 red; 3 green, 15 blue, 14 red
Game 5: 6 red, 1 blue, 3 green; 2 blue, 1 red, 2 green
В какую сторону вообще копать, чтобы забить данные из подобного текста по шаблону в виде каких-то переменных?
>пишут код, а потом под него подгоняют интерфейс.
Это называется "итеративная разработка".
Я думаю, что копать надо в сторону strings.Fields() и fmt.Sscanf()
Sscanf - из строки, Scanf - из stdin.
https://www.geeksforgeeks.org/strings-fields-function-in-golang-with-examples/
https://www.geeksforgeeks.org/fmt-sscanf-function-in-golang-with-examples/
(ссылки первые попавшиеся)
Т.е. у тебя запор, говно осталось в жопе, а в унитаз ты передал указатель на него? Хитро.
Нет,говно я складировал в монго дб тк там высокая скорость доступа
Я хуею, разрабам языка что, букв жалко на нормальные названия? фмт, сс скан ф, и еще такой же метод, только с одной с, как будто кто-то в пьяном угаре копировал из сишки самые ебанутые названия и смешивал их между собой.
Таков говей
>In Go, names tend to be somewhat shorter than in many other languages
>https://google.github.io/styleguide/go/guide
>Это называется "итеративная разработка".
Это называется неспособность к системному мышлению. Этим страдает не только Го, но и значительная часть динамодристни. ИЧСХ в Го линковка типа и интерфейса осуществляется в рантайме при первом использовании, прамо как вся это утиная типизация из динамодристни.
> копировал из сишки
Ну, в данном случае таки именно копировал, и именно оттуда.
Чтобы люди с опытом видели знакомые буквы. А ньюфаги - привыкнут.
Ну, и говей тоже, как заметили выше.
> То же и про файлы.
> Почему, блядь, в JS/TS/Java всегда понятно, откуда что берётся, а в Го - нет? Просто похуй? Кому надо - тот найдёт? Понимаю.
Ну зачем блять, зачем ты продолжаешь это приводить в пример и жидко серить под себя, бестолочь
>осуществляется в рантайме при первом использовании
Ты явно чего-то недопонял, если считаешь это каким-то (пусть даже теоретическим) недостатком.
Например, то, что переменным значения присваиваются в рантайме тебя не беспокоит? Это не как в "динамикодристне"?
Так реализованы интерфейсы в Го.
Это не бесплотные абстракции или контракты, как в Java или Typescript. Это _значения_ (пара указателей). Эти значения надо инициализировать. И это, естественно, делается в рантайме.
Потому, что считаю это досадной недоработкой.
Впрочем, спишем это на приверженность создателей языка к минимализму. Недостатки как продолжение достоинств.
>Ты явно чего-то недопонял, если считаешь это каким-то (пусть даже теоретическим) недостатком.
>Например, то, что переменным значения присваиваются в рантайме тебя не беспокоит? Это не как в "динамикодристне"?
Совсем того? Присваивание переменной значения это именно то, для чего программа и нужна. А система типов, в статически типизированном языке подразумевает, что типизация будет делаться статически, а не крякать в рантайме.
А в го этого не сделали потому, что интерфейсы так через жопу реализованы, что порождают слишком много возможных комбинаций. И приходится переносить это в рантайм, чтобы создавались только те пары которые реально используются.
Чувак, интерфейсы в Го - это не про статическую типизацию (в привычном понимании). И в этом весь секс.
Именно интерфейсы - это самая замечательная часть Го, а не конкурентность (которая тоже охуенна).
Тебе надо расширять сознание, я думаю.
Так может объяснишь в чем пиздатость интерфейсов? В JS и питоне вот нет никаких интерфейсов и нормально вроде живут.
В пихоне есть абстрактные квассы и протоколы для этого, правда в большинстве случаёв они нахуй не нужоны.
Так и в джаве статическая типизация нихуя не работает во время рантайма. Сейчас я беру класс, реализую интерфейс. Потом в рантайме обновляю джарник с интерфейсом, джарник с использованием этого интерфейса, а джарник с классом оставляю старым. И дальше у тебя работает не типизация, а правила бинарной совместимости, изучай - https://docs.oracle.com/javase/specs/jls/se21/html/jls-13.html#jls-13.5.4
Если тебе прям надо, в го проверка сводимости типа к интерфейсу во время компиляции делается одной строчкой в любом месте (обычно рядом с описанием структуры):
`var _ Iface = (*IfaceImpl)(nil)`
Вот такой тебе implements, если надо. А если не надо, то и не пиши его.
Такие интерфейсы тебе приносят нишевые варианты использования, как например комбинирование интерфейсов, или имплементация интерфейсов для любого локального типа, хоть функции - https://cs.opensource.google/go/go/+/refs/tags/go1.21.4:src/net/http/server.go;l=2132
PS. Cамые охуенные системы типов работают максимально прозрачно и максимально близко к динамикодрисне - ты трейтами описываешь что тебе нужно от типа принимаемого объекта, а дальше компилятор сам всё проверяет. Хуле ты к го доебался, да еще с джавой, которую без ломбоковой кодогенерации и DI уже никто и не использует, лол.
>Он уже 2 года учит го и не может вкатиться. Сплошные отказы. Хотя опыта в других языках у него десятки лет.
Ну, как-бы это показатель. Если у него опыта десятки лет, то ему где-то под полтинник. Кому нужен кодер-скуфидон, который вот-вот выйдет на пенсию?
Тебя заставляют что ли писать на го?
Он тут на днях признался, что устроился на РНР. Будет пилить какую-то CMS на Ларе. Вот и думайте!
>под полтинник
>вот-вот выйдет на пенсию
Юноша, вы вообще в курсе про пенсионный возраст?
А потом, если сейчас детей рожают в 35+, то "полтинник" это типа сильно дохуя?
Это называется "в самом расцвете сил", лол.
Алсо, это чисто россиянская тема, что программист должен быть в памперсах и сисю сосать. А на западе хуева туча кодеров 60+, и всё прекрасно.
>в чем пиздатость интерфейсов?
Вообще или в Го?
Если вообще - то долго. Если в Го - то тоже долго.
Есть очень много вещей, которые нельзя понять, просто прочитав чьё-то объяснение. Для понимания необходимо пройти путь. Это занимает время и требует сил.
Если спросишь более конкретный вопрос - попробую ответить.
Тут дело не только в программистах. В россии принято в 20 лет уже иметь тугосерю, тян, квартиру и ипотеку, а в 30 можно и на упокой. В западных странах многие люди в 30 только вышку получать начинают, да и то особо не делают акцент на нём.
Это чтоб кодер запаривался, уставал, было чем заняться и чтоб у него в принципе не было возможности проявить самодеятельность.
Я ж говорю, го для менеджеров, а не программистов.
>Так и в джаве статическая типизация нихуя не работает во время рантайма.
Сейчас я беру GraalVM, сертифицированную JVM на минутгчку, компилирую всё в нативный образ и шлю тебя нахуй с левыми примерами.
>делается одной строчкой
Спасибо за очередной элегантный костыль.
>>2950558
>Cамые охуенные системы типов работают максимально прозрачно
Ты только что поделил на ноль твой любимый говноланг. В этом говне как раз максимально непонятно нахуй strings Builder.WriteString() возвращает nil error.
>Хуле ты к го доебался, да еще с джавой, которую без ломбоковой кодогенерации и DI уже никто и не использует, лол.
Я джаву не упоминал вообще, это твои личные заскоки что она тебе везде мерещится. Таблетки прими.
Не совсем правда про западные страны. В целом от 25 летнего человека уже много чего ожидается.
>В россии принято
Кем принято? Шизам, которые покупают курсы от инфоцыган? Знакомые, которые не в ойти только еботеки начинают брать к 28-30 годам, и то, с помощью родителей
Посмотри лучше на функции в своём РНР. Там ни стиль наименования, ни позиции параметров не выдержаны. Каждая функция действительно уникальна и будешь всю жизнь их учить и никогда не запомнишь.
Что ожидается? Что он в 25 девопсом должен быть? А в 40 че, в могилку?
Куда вы жить торопитесь, я не понимаю
Так и здесь та же самая ерунда, только пыху уже 30 лет, когда его рожали еще на коболе писали, а Голенг позиционируется как свеже-модно-молодёжная технология от продвинутой конторы гугол, и это при том что уже существуют языки с прекрасным дизайном, казалось бы, даже рисёрч не нужен, бери и копируй 1 в 1, но нет, возьмем самые убогие практики из самых устаревших решений, пенсионеры оценят, а на остальных похуй.
>Я джаву не упоминал вообще
Так ты шарпоблядок, что ли? Что жы ты раньше не сказал?
Хотя, можно было бы и догадаться, по характеру аргументации.
А что нужно уметь? Пока голангу учу, немного SQL знаю.
>>2951110
Удалёнка, но готов работать за еду
>А что нужно уметь?
Ты хочешь работать по найму. Решать чьи-то проблемы и брать за это деньги.
Естественный вопрос - какие проблемы ты можешь решать?
Это необязательно должны быть какие-то сложные вещи, могут быть и совсем простые. Но, это должно быть именно умение решать проблемы.
В идеале - проанализировать ситуацию, увидеть проблему, предложить решение и/или решить.
Если у тебя есть английский на уровне, позволяющем тебе как-то читать книги - это большое дело.
Берёшь книжку по Го, читаешь, делаешь примеры, умнеешь etc.
Что-нибудь типа "Hands-On RESTful Web Services with Go (Second Edition)" или "Powerful Command-Line Applications in Go" или что-то подобное. Где рассматриваются конкретные проблемы и их решения.
>Так ты шарпоблядок, что ли? Что жы ты раньше не сказал?
Пиздец ты дегенерат, я на говноланге пишу, потому и бомбит.
Чем хуйней страдать, лучше бы по сути ответил, а еще лучше просто заткнулся.
Удаленки есть, мелкие конторы, ищи на хх, всё время ищи, месяц, два. Будет с десяток отказов, но найдёшь. Заодно на тестовых поделаешь, посмотришь кто чем занимается.
Никто натаскивать тебя не будет нигде и никогда, ни сейчас, ни во время работы, ни через десять лет.
Бл, что такого в этом ресте? Чё все носятся с этим рест апи, лучше б полезным вещам учили, например, архитектура проекта, да даже банальное расположение исходников в папке и то полезней будет. Это гораздо важнее и сильно поможет сделать код поддерживаемым.
Этот рест апи уже кринж какой-то честно говоря.
>исходников в папке
Это всё в гайдлайнах прописано - стайл и бест практис, потом надо начинать что-то писать, рест-сервис это простое и в то же время самое базированное из всего, так как встречается в вебе повсеместно, набив руку на простых рест-крудах можно уже переходить к архитектуре, и нормальных книг по архитектуре на самом деле почти нет, есть паттерны проектирования, из которых строится программа, но это всё довольно абстрактно и в отрыве от практики не очевидно где какие инструменты применяются, так что этот этап требует создания большого количества кода и может затянуться на годы.
По архитектуре вообще ничего нет. Каждый делает как хочет. После сотни рефакторингов и тысяч коммитов я так и не пришёл к чему-то одному чтоб было заебись. Но по крайней мере уже начал приходить к чему-то правильному.
Расположение исходников в папке на самом деле тоже часть архитектуры, позже это поможет разбивать проекты на микросервисы.
Изучай Clean Architecture и DDD. Там вся база написана, единственно годная на текущий момент
Про ddd пишут что это очень нужно, очень важно, полезно и дохуя круто, как какой-то философский камень. Просто мешанина из умных слов: единый язык - что за язык, причём тут это? Это и так очевидно что надо сделать какой-то стандарт. Какие-то суперабстрактные слова, даже не сущности, слабо отссылающиеся на реальный проект.
На примерах же видно что это блин то же самое что мы и делаем всегда. Модели данных, валидация, разделение классов, работа. Приходит запрос, происходит валидация на какую-то модель, передача другой системе из матрёшки других моделей по такой же схеме, прямо здесь или на другом сервисе и даётся ответ. Это подаётся так будто это технологическая сингулярность.
Не знаю, может я что-то не понимаю.
>На примерах же видно что это блин то же самое что мы и делаем всегда. Модели данных, валидация, разделение классов, работа. Приходит запрос, происходит валидация на какую-то модель, передача другой системе из матрёшки других моделей по такой же схеме, прямо здесь или на другом сервисе и даётся ответ.
Ты только что описал типичную анемичную модель данных где у тебя контроллеры, которые мапят дэтэохи в твою модель, которая мапится на таблицы в базе данных, которые ты потом передаешь в сервисы, где насрано бизнес логикой.
Это типичная архитектура долбаебов, которые могут несколько месяцев катить примитивную фитчу и в конце обосраться не только со сроками но еще и высрать тонну багов, которые будут фиксить на протяжении нескольких лет, т.к. писать тесты на подобный понос просто невозможно, т.к. тесты будут хрупкими и по-сути повторять логику твоего сервисного слоя
>позже это поможет разбивать проекты на микросервисы
Ты так говоришь, как будто микросервисы это что-то хорошее, и, более того, обязательное к использованию. А это немножечко не так.
Это серьёзный оверхед, и нужны серьёзные причины, чтобы он стал приемлемым.
>единый язык - что за язык, причём тут это?
Не "единый", а "ubiquitous".
Не надо читать русские говнопереводы.
Все участники проекта (включая экспертов в предметной области) должны говорить на одном языке. Если ты не понимаешь этого, значит просто не участвовал в больших сложных проектах, или участвовал, но, на низовых ролях.
Язык (человеческий) - это вообще важнейшая вещь в программировании. Так работает мозг. Ты не можешь писать программу, если не вполне понимаешь проблему. Именно поэтому вокруг столько плохих программ.
Тот же Дейкстра говорил, что исключительно хорошее владение _родным_ языком является важнейшим качеством для программиста. Очень рекомендую читнуть вот это (на русском):
https://informatika-21.ru/pdf/dijkstra.pdf
См. стр. 38, например.
По необходимости. Чтоб это было легко сделать, плюс это сбособствует разделению независимых участков кода.
Разбивать когда это не надо конечно не нужно, это идиотизм.
Нет, я не про разбиение вообще (сервисы, функциональные модули etc), а именно про микросервисы.
Это просто дичайший оверхед, и то, что сейчас это считается чуть ли не обязательным паттерном - это просто ужасно. Вообще, вся эта облачная хуйня - это реальная деградация. Возврат в каменный век, буквально.
Он хорош в том плане что передача данных между сервисами идёт через grpc, это быстрее и удобней в плане разработки. Микро это или нет уже другой вопрос.
Вот, это тот самый случай, когда отсутствует ubiquitous language.
Я тебе про Фому, а ты мне - про Ерёму.
Я имел в виду микросервисы как паттерн. В том числе, обмен по grpc или чему-то подобному. Проблема в том, что программа строится из слабо связанных распределенных кусков. Нет единой базы данных, нет нормальных транзакций. И т.п.
Хорошо ли это? Это плохо. Почему же так делают? Потому, что надо, чтобы это работало в облаке. И чтобы держать миллион реквестов в секунду. А если миллион не надо - микросервисы тоже не надо. Как то так.
Когда я сказал, что облака - это деградация, я имел в виду, что куча отработанных паттернов сливается в унитаз, и всё начинается с нуля, на днищевом уровне. Про БД и транзакции я уже сказал. Другой пример - пользовательский интерфейс. Интерфейс в браузере - это днище. Но, сейчас уже выросло целое поколение, которое этого не понимает, и нормальных бизнес-UI не видело никогда. И т.д.
>Вообще, вся эта облачная хуйня - это реальная деградация. Возврат в каменный век, буквально.
Это не хуйня, когда тебе действительно нужны облака
>Интерфейс в браузере - это днище
Потому что либы для нативных интерфейсов говно ебаное
Ничего страшного,гоферу необходимо время от времени писать на нормальном языке чтобы не заработать птср
Любая программа проходит через этап "сервер в подвале", так как это тупо дешевле и проще, 99 из 100 на этом этапе остановится, из них одна выстреливает - переезжает в цод, прменяется простое масштабирование по количеству инстансов и cdn, и только потом, когда программа уже приносит хорошую прибыль и продолжает расти - нанимают опытных разрабов, максимально формализуют все требования на бумаге, проводят рефакторинг и монолит распиливают на микросервисы. Пилить программу сразу в микросервисной архитектуре - это бред, постоянное изменение требований и подгон под реалии просто задушат разраба, так как микросервисы - это очень сложная и мудовая в работе штука, а когда внятных требований нет - нет возможности продумать изоляцию данных и логики, релиз затянется до второго пришествия.
Сам работаю на PHP, есть пара проектов на Go. Пытаюсь перекатиться в Go но блять сотыги сложно найти РАБоту куда меня возьмут без просадки по ЗП, учитывая годы опыта ковыряния PHP и гомофреймворков под него
>Любая программа проходит через этап "сервер в подвале"
Из какого года капчуешь? Щас этот этап заменен на облако. Облако для прототипов куда лучше сервера в подвале
У тебя хотя бы работа есть, а мне грозит голод и накопление долгов
Да, да, главное кредитку привяжи пожирнее, чтобы счета выставлять, когда забагованный код случайно утилизирует месячную квоту за пару часов.
Аренда своих датацентров это уже следующий уровень, когда проект приносит профит, нагрузка предсказуемая без резких скачков и есть время на оптимизировацию затрат.
>когда забагованный код случайно утилизирует месячную квоту за пару часов
Выставляешь алерты/делаешь квоту и говняка не будет
Код на проде в принципе не может месячную квоту утилизировать. Если у тебя есть способность кидать на прод забагованную сборку, то земля бетоном, что уж сказать.
>Да, да, главное кредитку привяжи пожирнее, чтобы счета выставлять, когда забагованный код случайно утилизирует месячную квоту за пару часов.
Возьми тогда vps-ку где по месяцу. Если у тебя нормальная посещалка то того интернет соединения что ты покупаешь себе в хату тебе будет мало. А хороший тариф дают только юрлицам.
Лучше виртуальный сервер на железяке, которая стоит в серверной комнате.
А серверная комната в нашем случае - таки в подвале, лол.
Я занимаюсь внутри-корпоративными штуками. На джаве, в основном. И интерес к Го вызван (помимо прочего) интересом к облачному деплойменту. Я когда-то начинал совсем не с джавы, предубеждений у меня нет, и я прекрасно понимаю, что Го для облачных вещей подходит лучше.
Другой вопрос, что облачный деплоймент - это совсем не обязательно микросервисы. Это может быть и монолит.
Вообще, "монолит vs микросервисы" - это классическая ложная дихотомия.
Это просто разные вещи, под разные случаи использования, со своими плюсами и минусами.
Если у тебя нет опыта, но тебе нужна работа, чтобы было на что жить - то PHP - это один из лучших вариантов.
А Го никуда не денется. Будешь не вкатуном, а свитчером, лол.
Это не говоря о том, что приличный девелопер должен более-менее свободно знать несколько языков. Причём, один из основных - английский.
>виртуальный сервер на железяке, которая стоит в серверной комнате.
>А серверная комната в нашем случае - таки в подвале, лол.
Чего стыдиться, нормальный вариант абсолютно - когда эти чипы китайские продают на развес, собрал стойку, накидал этого барахла на полтерабайта оперативы, пачку процессоров, даже на галимый китай хуйнанжи встаёт xen-виртаулизация, ssd, а там уже крутится всё что нужно, мощности там лошадиные абсолютно, и стоит буквально хуйню.
Сколько готовились?
Так вот, а что можно интересного и небольшого с этим го сделать то? Просто с жсом я могу нахуярить по-быстрому spa, которое что-то будет делать и выглядеть заебись, а тут только в консоли ковыряться, если в сложные вещи не лезть, я даже как-то хз.
Да много чего. Какие-нибудь сервисы по перевариванию одного говна в другое. Короткие ссылки или ещё какую залупу
>что можно интересного и небольшого с этим го сделать то?
В Го - встроенная поддержка JSON.
Простейший REST API сервис для твоей SPA делается в несколько строк кода, буквально. Без базы данных, аутентификации и т.п. естественно.
Го - не обычный ОО язык. Если в обычном методы рулят вообще всем, то в тут - не так.
Насколько я сейчас понимаю, методы нужны только в 2-х случаях:
1. Имплементация интерфейсов, это очевидно.
2. Инкапсуляция полей - только геттер, только сеттер, сложная логика вычисления значения поля и т.п.
Во втором случае поле является не-экспортируемым, и для него определяются сеттер и/или геттер. В этом случае можно использовать и функцию, но, с методом лучше. И можно и интерфейс прикрутить - сразу или позже.
Методы нужны для работы с конкретным объектом. Функции общие.
Всё.
>Всё.
Не понял, а чо ты такой дерзкий, сынок?
И типа функции не подходят для работы с конкретным объектом, или что?
>>2954359
Функции не имеют целого ряда ограничений, присущих методам.
Поэтому, в общем случае удобнее применять их.
Но, есть случаи, когда методы использовать просто необходимо.
Два очевидных случая я перечислил.
Есть ли другие?
Это вопрос к тем, у кого есть реальный опыт работы
Вопрос про методы, процедуры и функции это вопрос чисто теоретического характера из учебника по общей информатике, им валят ленивых студентов первокурсников на зачетах, практического смысла не имеет.
Какой ещё блядь "общей информатики"?
Что за хуйню ты несёшь?
И, главное - зачем?
Той самой, первый семестр первого курса, лабораторная работа №4, такие недоступные, такие непонятные, будоражащие умы методы, процедуры и функции.
>лабораторная работа №4
Вот эта, что ли?
Мальчик, будь так добр, сделай дедушке одолжение - залезь обратно в ту дыру, из которой ты вылез.
>А серверная комната в нашем случае - таки в подвале, лол.
>Чего стыдиться, нормальный вариант абсолютно
Пиздец днище. Почему в шаро/джава/питоно-треде нет таких днище идей? Почему такие обсоски только тут?
А в чём, собственно, днище?
В идее о том, что свои данные надо хранить у себя, а не у дяди?
Скока тебе годиков, сыночка?
Ты снова написал какую-то дичь.
Кем ты работаешь, если не секрет?
И сколько тебе платят за вот такую вот экспертизу?
>А в чём, собственно, днище?
>В идее о том, что свои данные надо хранить у себя, а не у дяди?
Никакому хостеру не уперлись данные твоих "Рога и Копыта". Кого стоит боятьcя, так это ментов, вот эти придут технику опечатают и заберут и сиди и без техники и данных.
Это еще не поднимая вопрос, как обеспечить бесперебойную работу хотя бы на уровне 99.9%.
Да.
И камеру заклеивать на ноуте тоже не надо.
Бизнес-ноутбуки, правда, делают со шторками на камерах, но, это просто так, чисто для лулзов.
Почему такие хуепуталы занимают нормальные позиции, а я новую работу на го не могу найти?
мимо синька на петухоне
Потому что го рекламируется как очень быстрый и производительный язык. Идеальное сборище для байтоебов и вечных вкатунов, которые считают микросекунды для своего невелосипеда.
Вместо того чтоб наконец закончить проект, они думают что лучше использовать - методы или функции.
Если "хуепуталы" занимают нормальные позиции, а ты нет, может ты хуепутало, не?
Ну так он на то и хуепутало, что успел за счёт языка (не программирования) вовремя пролезть, а остальных теперь ебут по алгосикам и архитектуре, чтоб на место рядом с ним претендовать.
>они думают что лучше использовать - методы или функции
А вот ты думаешь всегда об одном и том же - где бы покушать писюнов.
И снова и снова голод приводит тебя сюда, ты привычно пишешь то, о чём тебя не спрашивали, и получаешь очередную порцию.
>И снова и снова голод приводит тебя сюда
Жалко, что не кадровый.
мимо
ну кстати сейчас хожу по собесам на мидла (3 года опыта) и алгосов почти нигде нет. Ну я бы их в любом случае не нарешал, так что кайф
Алгосов нет, ок.
А что есть?
И на какую зп ты претендуешь, имея 3 года опыта?
Алсо, на скольких собесах уже был? Ты в ДС?
>Бизнес-ноутбуки, правда, делают со шторками на камерах, но, это просто так, чисто для лулзов.
В голос с этого скуфидона параноика. Иди галоперидолу наверни. А как пропустит пойди посмотри актуальные бизнес модели HP, Dell, Lenovo, Apple и найди там шторку.
>скуфидона параноика
Может быть просто человек, увлеченный информационной безопасностью? Я вот после знакомства с метасплоитом все камеры на девайсах заклеил.
В наше время хочешь-не хочешь, а увлечёшься, лол.
Вообще, речь шла про серверы для внутри-корпоративных решений - виртуальный сервер on-premises vs виртуальный же сервер в облаке. Я сказал, что собственный - лучше, чем у дяди (>>2953058). Если можешь себе позволить.
Почему? Потому, что дядя проебёт твои данные, и ему вообще ничего за это не будет. Потому, что это прописано мелким шрифтом в пользовательском соглашении. Это во первых.
Во вторых - если облако за границей, то в наше время это немножечко неудобно. Если в РФ - то, твои данные не только проебут (вероятность x10), но и продадут или просто предоставят по запросу из органов. И ты узнаешь об этом позже всех.
Насчёт того, что в облаке надёжней (если не проебут, конечно) - это не всегда так. В моём случае - точно не так. Я умею делать такие штуки, о которых в средне-васянской конторе даже и не мечтают. И аптайм у нас лучше, чем в облаке, или, как минимум, не хуже.
Если бы ты хотел перейти с си - просто перешел бы, и всё.
Ну вот тебе пример - у тебя есть интерфейс Doer.
И есть структура его реализующая - SomeDoer.
Есть 2 функции: одна принимает переменную - doer Doer, другая - слайс - doers []Doer.
И у тебя есть 2 переменные типа SomeDoer - someDoer (один объект) и someDoers (слайс).
Можешь ты передать их в соотв. функции? Да-нет-почему?
(квадратные скобочки пропадут, скорее всего, но и так понятно)
Ты блядь свой телефон посмотри и открой разрешения российских приложений. Охуеешь сколько их там, геолокация, блютуз, вайфай когда она вообще не работает с ними напрямую.
Вообще какие материалы НЕ про Go посмотреть, чтобы потом было понятнее, почему этот язык устроен именно так, и пользоваться им более грамотно.
А может потом еще вот это полезно почитать, если базовый C освоить?
https://beej.us/guide/bgnet/
https://beej.us/guide/bgnet/translations/bgnet_A4_rus.pdf
>>2956083
Это лишнее, мне кажется. И концепции там другие.
В Си будет куча низкоуровневого говна, которое тебе не нужно в принципе, и которое будет только мешать пониманию сути.
Хотя, конечно, минимальное знание Си - вообще полезная для программиста вещь.
По сетям - есть книги для Го. По системному программированию - тоже. Зайди на scanlibs.com и сделай поиск типа go network programming, go system programming.
https://scanlibs.com/network-programming-go-language-2nd/
https://scanlibs.com/network-programming-go-secure-reliable/
https://scanlibs.com/hands-systems-programming-go/
По языку советую читать документацию. Про компьютеры в целом это другая литература совсем. Книжки по конкретным языкам на 90% состоят из воды, лучше не забивать ими голову.
>Может быть просто человек, увлеченный информационной безопасностью?
Увлечени инфобезом надо начинать с анализа угроз, а не пустопрожней болтовни про выдуманные шторки. AWS нет резона красть данные мелких говноконтор, профит минимален, а репутационные риски велики. А защищать данные AWS умеет лучше всяких энтузиастов увлеченных информационной безопасностью.
>>2955355
Скуфидон первый начал про возраст
>Скока тебе годиков, сыночка?
>>2955740
Ты вначале список ноутов дай, потом про разрешения приложений поговорим.
>Потому, что дядя проебёт твои данные, и ему вообще ничего за это не будет.
Да ты сам проебешь в 100 раз быстрее дяди. У тебя никогда в жизни не будет столько денег, чтобы обсепечить отказоустойчивость на уровне облачных провайдеров.
>И аптайм у нас лучше, чем в облаке, или, как минимум, не хуже.
Ну давай расскажи: какой у вас в рогах и копытал SLA на реакцию в случае атеджа? А сколько магистральных линий интернета идут в ваш подвал? А каков запас топлива для дизельгенератора?
Почему тогда в школе русский язык изучают не по энциклопедиям, а по учебникам? Может эта вода как раз позволяет усвоить материал лучше?
>чтобы потом было понятнее, почему этот язык устроен именно так
Я как-то перечитывал книгу Кернигана про Си, и там прямо видно где авторам Го было больно настолько, что они начали делать новый язык точнее, им было больно от плюсов, и они хотели нормальный си для прикладных задач.
Но я не уверен, что это прямо очень полезно для профессионального роста.
Лучше почитать "100 ошибок Go" для углубления в язык, книгу с кометой про операционные системы (как раз недавно перевели на русский), и книгу с кабанчиком, чтобы понять, что в клиент-серверных приложениях ничего никогда не было просто и никогда не будет.
Авторам Го было больно? С трудом верится что авторам этого чуда вообще знакомо чувство боли связанное с языками, иначе они действительно сделали бы нормально, а не так, как этот язык по факту устроен и выглядит.
Ты говоришь так, как будто го делали какие-то хипстеры для хипстеров.
Го делали гигачады, которые придумывали ютф-8 и писали за один день программы для древних пекарен с нестандартной архитектурой.
Им не нравились сишные строки, массивы, адресная арифметика, управление зависимостями, они их переписали и добавили асинхронность прямо в синтаксис языка и им норм, у них теперь какой-то кусочек гуглового бэкенда быстро компилируется.
А страдают те, кто вкатился в го, потому что думал, что это модно молодежно и много денег плотят.
кому война, а кому мать родна. создатели го не хотят повторения с++, которое такие как вы делаете с каждым языком
Ты ведь трогал себя в разных местах, пока это писал?
Не стесняйся, здесь все свои.
На двачах вкатунам говорят не вкатываться. Чтоб конкуренцию не создавать
Нет, если ты хочешь найти высоконагруженный опенсорс, то у тебя не получится. В опенсорсе в целом только инструменты для создания продуктов.
Как тогда научиться писать высоконагруженные приложения, если их никто не показывает?
Через работку, очевидно же. Ну и в целом, хуйлоад это в первую очередь про архитектуру и сустем дезигн.
Но ведь на работу не берут, если не умеешь писать высоконагруженные приложения
>на го пишут высоконагруженные приложения
Я вообще никогда не слышал за рубежом фразу "высоконагруженный". Это устаревшее понятие. Никто так не говорит, это чисто внутрироссийская тема. Примерно как "импортозамещение". Я и гуглил "high load websites", и книги смотрел, и статьи. Нихуя нет нигде. Скажи любому американцу "I make highload websites", он ахуеет и переспросит: в смысле высоконагруженные? Что ты имеешь ввиду?
Тема на самом деле высосана из пальца. Смысл короче в том, что люди просто пытаются выжать максимум ресурсов из нихуя. За рубежом это не актуально, так как там работают другие принципы. Там говорят "облачные технологии". То есть, я предоставляю код, а облака обслуживают всю аппаратную часть. И если завтра на сайт прибежит миллион хомяков, меня не ебёт как именно облака всю эту ораву обслужат. Я плачу только за количество вызовов. Оно десять миллионов раз по 1 секунде отработало, я оплатил эти 10 миллионов. А насколько оно нагружено, чего и как меня не касается.
>Там говорят "облачные технологии".
Там уже маятник качнулся и упоминается новая методология "on-premise hosting". Скоро начнут писать сайты на перле.
"On-premise" - это как раз то, что любят в России. У нас свой путь. Мы не ищем простых решений, лучше закупим сервера, наймём сисадминов, построим дата центр и будем всем этим самостоятельно рулить. Зачем нам готовые решения? Понятное дело, что "высоконагруженность" это компенсация. Люди экономят за счёт того что язык go компилируемый, он работает раз в 10-20 быстрее интерпретируемых языков. Соответственно, кабану легче купить условно говоря 5 серверов вместо 20 серверов.
Найс готовое решение, которое отказывает тебе в сервисе потому что паспорт не тот и страна не та, ясное дело никто не хочет ничего приземлять, ебаться с железом, потому что это гемор, но жизнь повернулась так что всё приходится резервировать локально.
Ахах
Многие пользуются хостингом, где надо платить за ядра, память, диски и тд. Вот там и нужен хайлоад.
А облака, где платят только за количество запросов редко кто пользуется
>отказывает тебе в сервисе
Что ты мне говоришь, кто мне чо отказывает? Я до сих пользуюсь и амазоном и gcp. К тому же яндекс облако никто не отменял.
>>2958096
Это обычная экономия. Не обязательно для этого выдумывать новые слова. Есть прекрасные другие слова - resilience (устойчивость), scalability (масштабируемость), performance (быстродействие). Обычно говорят просто - решение масштабируемое или нет. Имеется ввиду способность выдерживать растущий поток трафика. А дальше уже разделяют вертикальное масштабирование или горизонтальное. Здесь хотя бы понятно о чём идёт речь. А "высоконагруженное" ни говорит ни о чём.
>Что ты мне говоришь, кто мне чо отказывает? Я до сих пользуюсь и амазоном и gcp. К тому же яндекс облако никто не отменял.
Интересно как ты их оплачиваешь и как всё это вообще через бухгалтерию проходит, а так же как относишься к тому, что РКН банит пачками подсети облачных провайдеров, я вот лично так недавно с cloudflare впёрся.
Два чая этому просветлённому.
Здесь мерилом работы считают усталость
На родине программирования это называется high performance.
Причины, скорее всего, примерно те же, по которым "screwdriver" по-русски называется "отвёртка". А не "завёртка" например.
>Го - это не язык общего назначения
Это кто такое говорит? Твой дядя?
Те, кого я слышал, говорят, что Го - это Си 21-го века.
>Скоро начнут писать сайты на перле.
Перл - охуенный язык. Но, сайты на нём писать сейчас не надо, конечно.
Я пару лет назад на нём написал интересную систему, которая в числе прочего, занимается многопоточной обработкой сообщений, приходящих по сети (через AnyEvent).
Система такого рода, что просто просится, чтобы её переписали на Го. Но, делать этого я не буду, т.к. производительность там не важна вообще (хотя Перл очень быстрый для скриптового языка, быстрее Питона). И используется сторонняя перловая либа, которую тоже тогда надо переписывать, а лень.
Я поясняю дебилам, что они дебилы. Не нравиться natribu.org к твоим услугам.
Это из-за шаблона:
fmt.Errorf("zalupa vo vremya drochka happens: %v", err)
т.е. у тебя один err оборачивается в другой, ну и тут как бы заглавные не уместны.
Можешь всплакнуть о стектрейсах Java/C#/Python/C++
Ну, ты же понимаешь, какой ценой даются те стек-трейсы, правда?
Ахуеть открытие, ЛИНТЕР к чему-то анально принуждает, а мы и не думали
Тебе бы русский подучмть для начала.
Ибо ты очевидно его не понимаешь.
А потом уже здесь менторствовать, если желание ещё останется после этого.
>Ну, ты же понимаешь, какой ценой даются те стек-трейсы, правда?
Единственная реальная цена: немного больше расход памяти на стекле. Затраты на сбор стектрейса вообще похуй, если у меня произошла ошибка - я хочу видеть стектрейс. Это важнее чем сэкономить немного CPU.
Им-то откуда знать полезность стектрейсов, в петпроектах он не нужен
Они как бы актуально, но всё равно устарели, потому что язык развивается. Старый код выполняется, но так уже не пишут.
>но так уже не пишут
А что именно существенно поменялось? Вот много любопытных книг по Go 2019 года. Тогда язык был совсем другим?
Кое-что в стандартной библиотеке устарело, добавили обёртывание ошибок, сам интерфейс error теперь требует метода Error(), а не String() как раньше, система пакетов поменялась, добавили дженерики. Ну и ещё помелочи.
Ещё забыл, что они меняли семантику всяких неочевидных вещей, но там каждый случай надо отдельно расписывать.
Зачем ты мне рассказываешь про полезность стектрейсов?
Я на джаве пишу ещё с тех пор, когда ты пешком под стол ходил.
Речь шла про то, что при агрессивном минимализме Го стектрейсы даже идеологически неприемлемы. Хотя, не удивлюсь, если сделают в дебаггере, например. Дженерики же сделали, пускай и через жопу. Хотя незадолго до того писали, что дженериков в Го не будет никогда, а если и будут, то в 2.0.
Вроде всё ОК, но постоянно ловлю себя на мысли, что делаю всё через силу. Что мне очень трудно выражать свои мысли на этом языке. При этом на джаве, перле, питоне, джаваскрипте, тайпскрипте, и даже на си - такой проблемы нет.
Я знаю, тут есть джависты-свитчеры. Скажите - это нормально?
Насколько я понимаю, и с работой тоже не очень на Го?
Стоит ли продолжать?
Испытали ли вы в итоге сатори? Или просто тянете лямку?
Если коротко - make programming fun again.
И джава стала слишком большой. А я, надо сказать, приверженец минимализма. И просто устал тянуть огромные проекты.
Ну, и я не молодею. Место энрерпрайзного консультанта мне не светит (наверное). Поэтому, просто хочется чего-то, что сложное не в ширину, а в глубину. Чтобы жизненный опыт был к месту.
Для души пишу на Руби, более приятного и удобного языка не придумали пока что.
Если есть опыт, то на собес позовут, но всё будет зависеть от того как пройдёшь.
Да никто не бежит, инфоцыгане форсят эту тему чтобы продавать курсы, любой разраб с опытом знакомится с Го, понимает что его место - висеть хттп-воркером на бэкенде и перемалывать жсоны, и на этом интерес угасает, просто еще один ситуативный инструмент в копилку, естественно никакой технологией будущего даже не пахнет.
Если на том же петухоне каким-нибудь образом запилят нормальный быстрый интерпретатор, то го можно будет выбрасывать на помойку. Куча библиотек, удобный синтаксис.
И нет, это не потому что го молодой, это сам язык такой. Каждый раз шлепать одни и те же шаблонные строки кода да ну нахер, на большие проекты сомнительно годится. За десять с лишним лет-то можно было уже б набрать аудиторию
>го молодой
Это заблуждение. Его придумали в 80-е для Plan9, но тогда не взлетело и Роб Пайк решил подсунуть его гуглу в конце нулевых.
Бессвязное кукареканье про удобство, большие проекты.
Чел у кубера больше миллиона строк кода на года. Пацаны и не знали видимо что можно.
Я собираюсь написать фреймворк типа Лары на голанге и вытеснить РНР с рынка. 80% сайтов в интернете будут переписаны на голанге.
Как осуществляется локальная разработка на Golang? Есть какой-то мануал, как сделать локальное окружение? Докер-хуёкер?
>Чел у кубера больше миллиона строк кода на года. Пацаны и не знали видимо что можно.
Мокрописька студентоты.
Это многое объясняет.
Загуглил (лол) эту тему.
Нашёл вот это:
https://www.reddit.com/r/golang/comments/b8dgr/curious_what_the_relationship_among_go_plan_9/
14 лет назад на полном серьёзе писали про го, как про замену джаве. И как это было бы хорошо. Пиздец.
Вообще, не устаю охуевать с могильщиков джавы, люди в принципе не понимают, что такое джава, почему на ней пишут энтерпрайз и прочий фарш, и т.п.
Ты сделай сначала что-то сложнее микросервисов и байтоебства. И хотя бы год поддерживай реальный средний проект на го.
Мне кажется поэтому на го так мало библиотек. Люди тупо не хотят работать с большим количеством кода. Когда у тебя в проекте четыре-пять го файлов это ещё ладно, но когда их больше 50 уже становится неприятней во всём этом разбираться. Поэтому видимо его и позиционируют как язык для микросервисов и всяких узких мест.
О чём собственно речь? Допустим, я хочу набрать какое-то внешнее имя в формате пакет.Функция или пакет.Тип. В вс коде мне достаточно набрать: "па" (или больше символов), затем Tab и он дополнит до полного имени: пакет. Дальше могу также выбрать функцию или пакет набрав первые буквы.
В голэнде так невозможно сделать, он конечно сразу догадается о пакете, но если нажать Tab то добавится ещё функция, но скорей всего не та, которая нужна, а другая. Поэтому надо полностью набирать "пакет." и только после этого можно через Tab выбрать функцию или тип.
>люди в принципе не понимают, что такое джава, почему на ней пишут энтерпрайз и прочий фарш, и т.п.
А ты понимаешь?
Один язык испоганили, теперь и наш хотят испоганить
А какие-то требования по железу есть? Я просто понятия не имею, что бэкендерам требуется для этих докеров и т.д. Вот в машин лернинге люди себе берут помощнее ноуты.
Докеры легковесны. У тебя больше памяти иде и браузер сожрут. Вообще вполне можно работать на ноуте 2 ядра 2 гига. Для комфортной работы конечно озу можно побольше, иначе свопится будет часто. Также лучше не выделять раздел под своп, а сделать через файл (ну порой инстраллер так не позволяет делать). Дело в том, что своп файл можно легко увеличить, а раздел переформатировать сложнее.
Из легковесных дистрибутивов могу посоветовать Linux Lite, Mint XFCE, Q4OS.
Ебланоид нажимай не таб а энтер. Если тебе так критично жать именно на таб то перебинди
Спасибо. Я как раз Mint на старенький ноут накатывал.
Пока тогда буду на старом всякие докеры ставить, а то на основном ноуте по учебе нужен Windows.
А если мне надо перейти на новую строчку? Какой вообще дебил из жидбрейнс придумал использовать для этого ентер?
Перебиндить хваленная идея не позволяет. И да, я уже пробовал до этого и просто отключил автодополнение по ентер, поэтому работает только по табу, но там вариант с заменой, а не вставкой.
В жидее есть в плагинах мапинги от других иде-попробуй их.
К чему ты это спросил? Типа выебнулся?
Если да, то выебнулся ты глупо.
Я на джаве пишу уже очень много лет.
И, при этом, я ещё пять-шесть языков знаю на таком уровне, чтобы писать идиоматический код коммерческого качества.
Так что да, я понимаю. В отличие от тебя.
хватит смеяться.......... по виду ей лет и питаеться она так себе, винтовку дай бог удержит, не говоря уже об акробатике. И на твоей картинке пацаны + с винтовками, тоже мне сравнил.
>К чему ты это спросил? Типа выебнулся?
Что у мани на уме, то у него и на языке. Нет, я спросил, чтобы узнать в чем минусы джавы с твоей точки зрения.
1. Пишеш go mod init, чтобы начать проект
1. Чтобы добавить зависимость пишеш go get
2. Перед коммитом пишеш go mod tidy
???
Локальная разработка
>в чем минусы джавы с твоей точки зрения.
в чем минусы и плюсы*
быстрофкс
P.S. Хахахах, дочитал твой пост, пиздец тебя задел обыкновенный вопрос, так порваться.
> А если мне надо перейти на новую строчку?
В какой ситуации тебе нужно после того как написал "пакет." перейти на новую строку?
>>2960652
Двачую, но вообще если очень нравится вскод то сиди пердоль его дальше, или смирись с особенностями жидбрейнса
> идиоматический код
идиотический
> идиоматические посты
идиотические
быстрофикс
Я скачал пиратку голэнда, чтобы стать профессионалом, а на вс коде не пишут профессионалы.
Профессионалам просто надо таски делать потому что тимлид ебет, а не ныть что кнопка делает не то что тебе хочется
>>2960941
>в чем минусы и плюсы
Надо было так и сформулировать.
А то получился наезд с выебоном, а я немножко уставший.
Плюсы:
Промышленный стандарт.
Охуеннейшая инструментальная поддержка.
Которая вытекает из того, что язык однозначный, простой, двусмысленности отсутствуют. Никакой другой язык не имеет такого уровня инструментальной поддержки.
По этой же причине (простота и недвусмысленность) код читается на уровне подсознания (при наличии опыта). Мозг - тоже инструмент.
И всё это позволяет писать сложные, огромные проекты, и не бояться, что потеряешься в них.
При этом - достаточно богатые средства построения абстракций.
Но, не слишком богатые, это важно. Например - в Scala - богаче. Но, код люто двусмысленный, и нормальная инструментальная поддержка просто невозможна.
Возможности метапрограммирования (развитый механизм аннотаций).
Удобный, очень практичный скриптовой язык-компаньон - Groovy.
Есть jRuby и jPython, но, это не то. Groovy лучше (для джавы).
Kotlin не предлагать!
Огромная куча библиотек, фреймворков, разнообразных инструментов, информации и т.п.
Продвинутая виртуальная машина, в которую вложен уже, наверное, не один миллиард долларов.
Минусы:
Многословность.
Некоторая, скажем так, ригидность. Исправляется рефлекшном и байткод-инжинирингом.
Это, всё-таки, Го-тред.
Как написал один чувак на реддите - Го не тот язык который нравится с первого взгляда.
Несмотря на весь скептицизм, высказанный ранее, думаю, что однозначно буду продолжать вкат.
Оно того стоит.
Да, это не замена джаве. И это хорошо, потому, что джаве не нужна замена.
Плюсы Го, с моей точки зрения:
Быстрая компиляция в нативный код.
Встроенная поддержка конкурентности, CSP.
Минимализм.
Ани-энтерпрайз, простые вещи можно (и принято) делать просто, а не наворачивать фабрики абстрактных фабрик.
Интерфейсы (дак-тайпинг) - когда-то я был лютым фанатом таких вещей. Потом энтерпрайз отучил. Но, всё-равно, тянет иногда на такое.
Простота (если привыкнуть к ряду необычных и фриковатых вещей).
Цели - мини проекты, автоматизация, девопс.
Саморазвитие - в смысле принятия альтернативных, анти-энтерпрайзных подходов.
Хотел бы я писать на Го фулл тайм? Пока не знаю.
>код читается на уровне подсознания (при наличии опыта)
это скорее что-то из МКБ-11
Спринг - это не джава.
Это анти-джава, если угодно.
Алсо, даже одна ложка говна может испортить целую бочку мёда.
Но, мёд как таковой от этого говном не становится.
В своё время я прочитал книжку "Better Faster Lighter Java" (автор Брюс Тейт). И она произвела на меня неизгладимое впечатление. Брюс, правда, потом свитчнулся в Ruby, к сожалению. Но, в те годы это было модно.
Так вот - бессмысленные фабрики абстрактны фабрик пишут те, кто кроме джавы нихера не видел, и (по сути) не умеет программировать.
А те кто умеют программировать как решают проблему выбора какую имплементацию создавать во время исполнения?
Спасибо.
А что ты думаешь по поводу зоопарка из систем сборок? Меня это немного пугает после cmake/make.
И ещё вопрос по поводу всей это структуры проекта org/example и тд, отчего это вообще пошло и как мириться с этим?
Я просто сам с си и хочу перекатиться либо в джаву, либо в го.
Зоопарк - это сильно сказано.
Есть Gradle и есть Maven. Стандарт - Maven.
Но, если проводить параллели с Си и make, то это будет, скорее, просто билд в IDE, без каких-либо систем сборок. А без IDE на джаве не пишут.
Выражение "структура проекта" не очень подходит. Это пакеты (неймспейсы). Т.е. у тебы не просто класс Hello, а com.example.Hello. И в том же проекте может быть и bar.foo.Hello, совсем другой.
И называй их как хочешь, никто не неволит.
Хелло ворлд - можно вообще без пакета, но лучше не надо, сделай хотя-бы package hello;
Имена доменов - это гарантия, что не будет конфликтов, и всё.
Если же тебя смущает сама иерархическая структура, то напрасно, это очень удобно. А вот в Го, как раз, что с пакетами, что с зависимостями - так себе.
Пара слов про классы. Джава-класс - это 2 в 1, и класс (шаблон для создания объектов) и модуль (просто набор переменных и функций, тот же неймспейс). Static методы и поля - это модуль. Обычные поля/методы + конструкторы - это класс. Никакой связи между этими двумя частями нет вообще, не считая того, что из статик-функций тебе доступны private поля класса (после создании экземпляра этого класса и при последующей работе с ним).
В принципе, можно писать код только на уровне модулей (только статик методами в классах), а классы делать только с public полями (как структуры), и это будет почти как в Си.
И, сразу хочу сказать, что вообще порог вхождения в джаву несколько высоковат. Почему - не так просто объяснить в двух словах. Просто в силу специфики вещей, которые принято писать на этом языке. Это сложные вещи, как правило. А если писать простые, то получается сложновато (многословно), и новичков это отталкивает. Т.е. могут быть проблемы с мотивацией. В этом смысле питон - гораздо более rewarding. Я когда-то с него начинал (ну не считая машинных кодов и перла, который я тогда не понимал, лол). Алсо - питон - прекрасный клей для сишных либ.
Лучше присмотрись к профессии экономиста с такими охуительными расчетами.
Это не мои рассчёты, а Влада с канала ДимСаула, его там забанили.
А можно пояснительную бригаду?
Я как-то не увидел связи между циферками и цветом клеточек.
И что в этом списке делает C# ???
Кто и зачем будет в него вкатываться в здравом уме?
Могу предположить, что в стране есть изрядное к-во пожилых экс-дельфистов, ибо дельфи был популярнее 1С в своё время. Теперь, они, естественно, перекатились в шарп, и преподают это на курсах. И надо эти курсы кому-то продавать.
Красный - если индекс вката падает, зеленый - если повышается.
Судя по расчетам курс вката = 19.095, так что всё в твоих руках.
Ты правда веришь, что в платных тебе расскажут больше чем в видосах на ютюбе?
Там хотя бы материал выстроен методически, а в видосах на ютубе абы как рассказывает какой-нибудь студент. У него у самого ещё каша в голове, собственно в видосы получаются такие же.
Если чел не может изучить что-то без курсов, то как он потом будет работать?
По документации к языку, либам, рабочим проектам на гитхабе. Статейкам на разных сайтах, если натыкаюсь на них. Иногда просто смотрю сорсы
А вдруг ты упустишь какую-нибудь важную вещь, а потом на собесе окажется, что у тебя огромный провал в знаниях?
А по курсам "какую-нибудь важную вещь" упустить не могут? Че за бред, как раз-таки ровно наоборот, если человек сам изучает по либам и докам, то у него куда выше уровень знаний будет.
Го - идеоматический язык, а сам ты никогда не додумаешься до этих идиом и будешь писать непонятный код. А на курсах показывают лучшие практики и сразу разбирают типичные ошибки новичков.
Перед собесом, очевидно, надо смотреть какие требования и какой стек. Да, и что значит "провал в знаниях"? Если каких-то навыков не хватает то так и говоришь, что не приходилось этим заниматься, никто не требует от тебя знать всё подряд в 21 веке, это идиотизм.
Я уже работаю несколько лет. Когда первый раз на собес пришёл так и говорил, что нет опыта и тд, давали тестовые, гуглил, читал и делал то что нужно. Мой гит вообще пустой был на тот момент. Когда взяли через пару месяцев поисков - работал и изучал то чем занимаюсь, рефакторил, смотрел какие технологии есть, что можно улучшить, предлагал решения которые находил и так далее. Так и рос и продолжаю расти.
Почему-то все судорожно изучают всё подряд: граф деревья, алогритмы, пытаются написать свою ос, десятки петпроектов и всё ради того чтоб делать рест-прокладки. Зачем?
На курсах показывают устаревшие практики. Хочешь что-то актуальное - смотришь сорсы популярных библиотек. Хотя даже там кринж можно словить местами.
>работаю несколько лет
Чел, требования за эти годы изменились. Это раньше брали всех без разбору. Теперь если чего-то не знаешь, то сидишь без работы. Там народ опыт накручивает и собесы заучивает наизусть, а ты предлагаешь ничего не смотреть и с пустой головой вкатываться.
Если идти на первую работу в известные конторы и за 300к со старта то конечно там требования ебанические. Я первое время за 40к работал в мелкой фирме.
Дак никто не берёт даже на минималку, такой программист убыточный, потому что ему зп (хоть и маленькую) надо платить, а ничего полезного он не сделает, хуже того ещё будет отвлекать опытных работников тупыми вопросами.
Читай книги (англоязычные).
Гугли интернеты (на английском).
Нет английского - значит нечего делать в этой профессии.
Ну, не знаю.
Если ты знаешь базу языка, можешь по англоязычной книге сделать проект с веб-сервисами и т.п. - это уже не ноль, и свои условные 50 тыр ты отработаешь гарантированно.
Скорее всего, дело в том, что у нас большинство вакансий и коммерческих проектов на Го довольно специфические, и там надо сразу впахивать. Т.е., как обычно, кабан хочет потратить 3 копейки, а заработать миллион.
Сам факт того что нет такого понятия как класс и статические методы (тут видимо это просто функции) вызывает непонимание как организовывать код.
Вот я хочу к примеру макс кучу написать, в каком-нибудь петухоне я бы создал класс MaxHeap, в конструктор поместил листик, создал бы классметод heapify и обработал бы им листик, метод бы вернул мне уже упорядоченый по правилам макс кучи листик и я присвоил бы его приватному атрибуту класса _heap какому-нибудь. Переопределил бы __str__ чтобы элементы кучи выводились в принте, возможно переопределил бы методы индексации. Навесил бы методов типо append, pop.
А как в Го? Придётся видимо создавать отдельную папку-пакет structures (иначе если в main оставить то ИДЕшка будет срать этим хипом постоянно, нарушается инкапсуляция хуяция, сокрытие и прочий кал), создавать там maxheap.go, в нём делать type Heap []int на который мы будет навешивать уже приколы. И тут начинаются вопросы, как сделать конструктор? Писать просто фабричку Heapify ([]int) Heap? Или сделать это методом моего типа: (heap Heap) Heapify?
Второй вариант такой себе, он будет принимать уже инициализированные данные при вызове и мы по сути не будем их использовал, какой-то кринж. Тем более понадобится сначала создать инстанс моего типа чтобы хипифайнуть слайс.
Первый вариант хуёв тем что в ИДЕшку при доступе к structures будет показывать Heap и Heapify одновременно. Хотя может так и надо.
Высрал кал какой-то, соболезную прочитавшим.
В общем чтобы сократить этот поток кала: я тупа без понятия как организовывать код. Не вливаюсь в концепт. Не выкупаю философию. Не чувствую архитектуру. Надо будет посмотреть что-то где-то как другие люди делают.
Хотя я буквально меньше недели гошку трогаю руками по вечерам после сработки, наверное зря хотеть всё и сразу.
Плохо искал, мы недавно двоих взяли спокойно и без больших требований, лишь бы работали и работали хорошо
Окей, я взглянул мимолётно первый пикрил и мне пришла гениальная идея конструктор назвать тупо New. Вроде норм.
Для прототипов есть быстрый python
Для мидовых крудов есть хорошо зарекоммендовавшие себя яп с готовой инфраструктурой Java, PHP
Для йоба хайлоадов с байтодрочением есть C++/Rust
Реально нужно было создавать целый язык только для того, чтобы там была встроенная либа с легковесными потоками/их синхронизацией для concurrency? Это сработало бы, если бы рыночек в почти 2024 году не требовал от вкатунов понимания осей и вышки тех вуза. Так зачем всё это? Для чего?
Тем не менее на go написали k8s, docker, ngrok и много всего другого.
Нахуя? Единственную причину для себя вижу в том, что в компаниях работает большое количество студентов/самоучек, которым можно платить 2 камня, а они и рады будут
Для узких мест где планируется заложить масштабируемость и быстродействие. На началбном этапе го кажется бессмысленным и ненужным, но когда вот прямо будет надо, переписывать сервис никто не будет
Го - это не тот язык, где ты за неделю получишь всё и сразу.
Или даже за месяц. Или даже за три.
Так что лучше настройся на неспешный вояж.
Организация кода - да, своеобразная.
Очень не хватает чего-то типа модулей - внутри пакетов. Ибо пакет (в моём понимании) несколько крупноват.
Но, надо пользоваться тем что есть, поэтому - да, всё распихивать по мелким пакетам.
Вместо конструкторов - функции, типа:
func NewMyZalupa(...) *MyZalupa {...}
Читай исходники стандартной библиотеки - очень познавательно.
И книги - их много.
Вообще - конструктор - это и есть функция, просто в ООП языках это присыпано сахарком.
Делать конструкторы методами типа - не надо, да это и невозможно сделать.
Вообще, не надо пытаться писать на Го как на питоне или жс или ...
Только зря устанешь.
Быстрый = на нём можно быстро разрабатывать прототип, в принципе можно питон на жс заменить, так даже лучше будет
>Делать конструкторы методами типа - не надо, да это и невозможно сделать.
Ну можно сделать чото типа:
(&MyZalupa{}).MyZalupa(args...)
Если тяжко без ооп синтаксиса конструкторов. Честно говоря не понимаю, в чем проблема.
Имхо можно без проблем писать код, отдаленно напоминающий жабий (на жабе удобнее будет намного засчет статических классов, крутой рефлексии)
Если тяжко без ООП, то не надо писать на Го.
Надо вначале очистить сознание, избавиться от ООП-зависимости, и мир заиграет новыми красками, безотносительно Го.
Ящитаю, что ЯП это просто инструмент, если человек использует его не по назначению, то это только его дело. Я вот на го пытаюсь игры писать, мои страдания - исключительно моё дело
А я вот не понимаю как в ООП писать, мне куда привычнее ещё с си просто написать функциями, разделить их по файлам и всё.
Как можно для прототипирования питон заменить на говно-жс?
А тонны библиотек? А нормальное ООП? А пакеты? А интеграция с сишными либами? А потоки? А всё остальное?
>игры писать
В смысле - десктопный GUI?
Месье знает толк, лол.
На питоне оно сильно приятнее будет
>А тонны библиотек
Есть
>А нормальное ООП?
TypeScript
>А пакеты
Есть
>А интеграция с сишными либами
Нахуя что-то прототипировать с сишными лабами, ебан?
>А потоки
Не шарю, там чето евент лупы, хуюпы, вроде да, с этим хуево, но это нинужно для прототипов
>А всё остальное
Прилагается
>Нахуя что-то прототипировать с сишными лабами, ебан?
Туда ли ты зашёл, пацанчик?
Вернись в жс-обезьянник.
Да, я уже заметил что здесь придётся долго разбираться, хех. Вообще по идее много чего в ООПшных языках это просто какие-то примитивные вещи, как те же самые методы как функци (куда передаётся self/this... собственно аргументом), только это скрыто за такой пеленой сахара, что если у тебя за плечом опыт исключительно ООП языков, это начинает бить по голове и вызывать неудобство, мышление настроено на питоны с жсами.
Книжечку наверное стоит прочитать если не собьюсь с пути, когда доки прошерстю. Как раз какую-нибудь где приложение разрабатывается, чтобы взглянуть на организацию и архитектуру кода в типичном го-проекте. Читать же исходники будет вызовом, наверное. Хотя там есть в принципе комментарии.
>>2963805
Можно, но это семантически бьёт по голове, в том плане что ты так сказать от "инстанса" пытаешься вызвать конструктор. Да и выглядит не очень. Лучше уж действительно использовать функции для создания инстансов. В принципе как я выяснил есть вариант каждый около-объект выносить в отдельный пакет и делать в нём свою функцию-конструктор.
>>2963808
Да, в этом есть проблема. Буквально другой мир открывается и не понимаешь как принято писать не по ООП, ломается шаблон. Либо же я сверхдраматизирую.
>>2963812
Видимо ты и начинал с Си/подобных. Я, не считая первой неудачной попытки на шарпе ещё в школе, с питона начал и прилип к нему. Хочется попробовать новое.
Это потому что ты курсы не проходил и у тебя провалы знаний по го
В книге Донована и Кернигана есть куча идеоматичных примеров. Если прочитаешь, то все вопросы отпадут как и что именовать.
>Для йоба хайлоадов с байтодрочением есть C++/Rust
Ты вначале попробуй напиши и потом говори. Го для того и создавался, чтобы можно было легче писать, чем на С++. Сейчас работодателям проще найти гофера, который уже шарит за бэк, чем плюсовика, который поди писал на каком-нибудь Qt формочки и за бэк не шарит, или тем более растовика, который явно вкатун и вообще программировать не умеет.
Неа. Да и смысл крутить опыт, за тебя ж работать не будет никто, это не школа.
https://www.youtube.com/watch?v=oQ9LkPuZK1Q
Что бы там ни говорили инфоцыгане с курсов.
https://go.dev/play/p/OVWzVzSHBfO
Кто из вас может объяснить, что происходит в этом примере, и почему оно нихуя не работает как надо?
Го не может в абстракции. Всегда надо держать в голове, что там у него под капотом происходит.
Это тянется ещё со времен си, когда программисты компилировали код, а потом прогоняли его через дизассемблер, чтобы понять где и что идёт не так.
Нет, это не про абстракции. Это про контракты. И про их соблюдение. Точнее - про не-соблюдение.
я подумал и не понял зачем тебе месяц чтобы понять как слайс работает
То есть, ты можешь объяснить, что там происходит, и почему тот же пример, если из него убрать вторую строку, где append(sa, 4), и дописать это 4 в первой строке, будет работать правильно?
А после этого сможешь объяснить, что это называется не "хуйня", а "хороший дизайн"? Можешь?
Ушёл из тайпскрипта или из калфы? Не очень понял, может ты про другого говоришь. Ну я постил как-то в js треде когда расширением баловался, но вряд ли ты про меня. Вряд ли вообще это кому-то в память влезло, лол.
первое тебя на собесе могу спросить
второе хз. дизайн не дизайн, но работает
Оно работает ровно так как и должно, просто дурачки типо тебя не могут понять что это не массив а что-то другое хоть и выглядит похоже. Классические массивы в го бтв тоже есть
Анон, на самом деле это можно понять. Буквально за 1 день и запомнить. Буквально просто нужно посмотреть всего лишь одно видео.
Вот что происходит к примеру (пик1). Ну или текстом ниже, накидал.
// `sa` является слайсом: len: 3; cap: 3
// SliceHeader содержит указатель на низлежащий массив `A`
sa := []int{1, 2, 3}
// `sa` передаётся по значению (SliceHeader) в append.
// Прибавляем к слайсу число. Низлежащий массив (`A`) пересобирается (создаётся новый (`B`), с 6 ячейками), адрес памяти на начальную ячейку массива в SliceHeader меняется.
// append ретёрнит новый SliceHeader с указателем на новый низлежащий массив (`B`).
// Значение sa заменяется новым SliceHeader'ом, в котором len: 4, cap: 6 и в котором указатель на массив указывает на совершенно другое место в памяти.
// SliceHeader содержит указатель на низлежащий массив `B`
sa = append(sa, 4) // [1, 2, 3, 4]
// `sa` передаётся по значению (SliceHeader) в append.
// Низлежащий массив в `sa` (`B`) не пересобиратеся, поскольку, по итогу прошлой операции, его размер равен 6.
// `append` спокойно прибавляет к этому слайсу пятёрочку и возвращает новый SliceHeader с len: 5 и cap: 6
// `sc` присваивается слайс с len: 5, cap: 6
// `sa` до сих пор содержит SliceHeader, указывающий на `B`, ! НО У НЕГО len: 4 и cap: 6 !
// SliceHeader содержит указатель на низлежащий массив `B`
sc := append(sa, 5) // [1, 2, 3, 4, 5]
// `sa` передаётся по значению (SliceHeader) в append (передаёт слайс len: 4 cap: 6)
// Низлежащий массив `B` не пересобирается, поскольку его cap: 6 и в момент вставки он содержит 5 элементов
// ОДНАКО МЫ ПЕРЕДАЛИ СЛАЙС ИЗ `sa`, А НЕ `sc`, СООТВЕТСТВЕННО АППЕНД БУДЕТ ПРОИЗВОДИТЬСЯ НАД СЛАЙСОМ len: 4 cap: 6
// Происходит вставка в низлежащий массив `B`. Однако, поскольку len: 4, вставка происходит на пятый элемент.
// Соотвественно `5` заменяется на `6`
// Возвращается новый SliceHeader с указателем на низлежащий массив `B`, len: 5 и cap: 6. Массив `B` содержит 5 элементов
sd := append(sa, 6) // [1, 2, 3, 4, 5]
// sa: ARRAY `B`; LEN 4; CAP 6. Видит 4 элемента: [1,2,3,4]
// sc: ARRAY `B`; LEN 5; CAP 6. Видит 5 элементов: [1,2,3,4,6]
// sd: ARRAY `B`; LEN 5; CAP 6. Видит 5 элементов: [1,2,3,4,6]
Кстати, если ты отрастишь слайс `sa` до его кэпа (максимального размера), а именно до 6, то ты увидешь эту самую шестёрку. А также нолик в придачу (пик-2):
// ОТРАСТИМ `SA`
sa = sa[:cap(sa)]
fmt.Println(sa)
К слову, я тот самый аноний-долбоёб который не больше недели в целом го трогает (не считая редких эпизодических чтений исходников простеньких программок ради любопытства ранее). После того как хеллоуворлд написал, мне стало интересно как что-то сложнее делать. Я знал что в го есть слайсы, но не знал что это такое, нагуглил видео. И оно мне пиздец открыло глаза резко, автору почёт и слава. Я даже не задумывался о таких вещах вообще на петухончике, мозг вынесло неплохо так.
Видос: https://www.youtube.com/watch?v=1vAIvqDo5LE&list=LL&index=1&t=350s&pp=gAQBiAQB
Если я где-то ошибся, поправьте меня, пожалуйста.
Поправлюсь, слайс содержит не указатель на ячейку на первый элемент массива, а просто на ячейку массива, с которой начинается слайс. Вроде как.
>Оно работает ровно так как и должно
Но не так как этого от него ожидают, очевидно слайс sc - багует, в коде из трёх строчек, где вообще никакого криминала визуально нет, но значение в слайс не попало. А если там не цифры, а операции с баблом, будешь искать, где и почему у тебя транзакция на миллион пролетела мимо слайса? И это считается надёжным языком, я ебал.
Здесь будет шестёрка, опечатка.
Очень много букв, потом прочитаю, и, если что - прокомментирую.
Но, дело тут вообще в другом.
Функция append() ведёт себя _не_очевидно_.
Т.е., _ничего_ в коде не указывает на то, что она поведёт себя так или иначе. Понимаешь? Вообще _ничего_. И "запоминать" тут нечего, кроме самой возможности такого поведения.
У взрослых людей, пишущих серьёзные программы, это называется "очень хуёвый дизайн". За такое в приличном обществе пиздят канделябрами по морде.
>>2964858
Мальчик, зачем ты лезешь во взрослый разговор?
Тебе одиноко? Так поди в /b - там все твои друзья.
Ну в принципе наверное можно с этим согласиться, хотя наверное у гоферов что на нём посидели есть свои причины и они найдут чем возразить. Просто из-за того что в Go, как я понял, всё принципиально передаётся по значению, а слайс в свою очередь является структурой в которой есть указатель на массив, то можно встретить вот такие приколы. По идее если по ссылке передать то всё будет работать 'as-inteded', но что-то я не понял как это сделать. `append` кажется возвращает по значению в любом случае.
Я сам люто охуел когда первый раз увидел, не понял прикола когда слайс не начал изменяться или вообще по другому, не очевидному, работал, по сравнению с другими языками.
дебсофикс
> Функция append() ведёт себя _не_очевидно_.
> Т.е., _ничего_ в коде не указывает на то, что она поведёт себя так или иначе. Понимаешь? Вообще _ничего_. И "запоминать" тут нечего, кроме самой возможности такого поведения.
> У взрослых людей, пишущих серьёзные программы, это называется "очень хуёвый дизайн". За такое в приличном обществе пиздят канделябрами по морде.
это уровень "почему я не могу скопировать словарь оператором присваивания а с числами работает??"
чел, тебе тот момент, что аппенд возвращает новый слайс ни о чем не говорит? то, что это x=append(x,y), а не append(x,y) на что-то намекать должно.
Мальчик, проблема в том, что append() _иногда_ возвращает новый слайс. А иногда - старый. Причём, когда и какой - решает она сама.
Надеюсь, что ты работаешь кассиром или курьером, потому, что такие программисты стране не нужны.
а прикинь, аппенд всегда новый возвращает. ну ты почитай как там слайс устроен
На самом деле он всегда возвращает новый слайс, как я мог понять. Просто есть ключевые приколы которые вызывают антиприкол, а именно:
1. У слайса есть низлежащий массив
2. Разные слайсы от одного слайса имеют общий низлежащий массив
3. При превышении cap(acity) создаётся новый низлежащий массив и если были слайсы, которые шерили (share хз как сказать) один низлежащий массив, то у них разъезжаются "хранилища"
4. Слайс передается по значению в append, т.е. передается копия слайса соответственно если ты передашь какой-нибудь старый слайс в аппенд то у него может быть странная длина и тогда аппенд к примеру перезапишет какое-то значение в массиве, а не создаст.
>странная длина
Не странная, а старая. Хуй пойми как я постоянно опечатки такие делаю. Заебало.
Собственно поскольку у слайса есть указатель на исходный массив и новые слайсы шерят его то сборщик мусора не убьет массив пока есть хотя бы 1 ссылка на него. Поэтому могут возникать приколы по типу пикрила, когда ты прочитал файл, вернул небольшой слайс с данными которые тебе нужны, а из-за этого слайса у тебя в памяти по прежнему весь файл наху валяется, лмао.
Поэтому как я понял в гошке важно следить за своими слайсами и насильно пересоздавать новый низлежащий массив чтобы избавиться от ссылки на источник.
Хотя мне кажется в других языках похожее бывает, просто я особо не вдавался в подробности.
https://go.dev/blog/slices-intro
Ты как-то сложно всё это пишешь.
Слайс - указатель. Передавать его _не_ по значению - это надо иметь очень особенную причину.
Проблема не в том, как он передаётся.
А в том, что append иногда создаёт новый массив (len >= cap), а иногда - оставляет старый (len < cap). И ты на это влиять не можешь. Т.е. нет параметра, который говорил бы "хочу всегда новый слайс". А вот какая у слайса capacity - из кода не всегда понятно. Потому, что append приращивает её, опять же, по своему разумению - см. исходники.
Этот пример - это известный подводный камень Го. Я поэтому его и запостил.
И стало понятно, что никто из вас об этом раньше не слышал, хотя это очень известный прикол.
Об этом много написано, и это одна из тех вещей, которые сразу отталкивают новичков от Го. Типа "ребята, если у вас такое считается нормальным, то ну его нахуй такой язык".
И таких подводных камней в Го есть в количествах.
На самом деле, как раз таки append - это не такая большая проблема. Собственная реализация, которая делает именно то, что тебе нужно - пишется за 5 минут. И это очень даже Го-стайл - писать заново самые базовые вещи, просто чтобы жизнь мёдом не казалась.
>Хотя мне кажется в других языках похожее бывает, просто я особо не вдавался в подробности.
Люди просто хотят векторов как в плюсах
Люди хотят того, что описывается словом "explicit".
Не находят и пишут сами, в итоге.
А почему все не вносят с стандартную либу? Это же никак не повлияет ни на скорость компиляции ни на что-то еще. Просто удобства добавит и избавит от бойлерплейта. Пайк говорил об этом?
>Слайс - указатель
уровень людей спорящих о том как аппенд непонятно работает
Подожди, но это же вроде не так. Слайс не указатель. Слайс это структура, которая содержит указатель. Т.е. ты передаешь её по значению и у тебя каждый раз всегда получается новый слайс. Из-за этого и могут возникают расхождения при работе с аппендом.
Насчёт недостатка QoL фичей согласен. Если честно, я не очень понимаю как писать что-то не низкоуровневое/крупное на нём. Видимо поэтому он в основном в микросервисах используется, это его стезя.
И как раз, возможно, факт того что ты из коробки не можешь контролировать создание нового массива это и есть пример нехватки QoL. Хотя всегда можно написать newSlice := append(oldSlice[0:0:0], oldSlice...) или append([]int{}, oldSlice...)
https://go.dev/src/runtime/slice.go
Хорошая стандартная библиотека - это многие годы труда.
И нужно ещё весьма нетривиальное коммюнити.
Причём очень _ленивых_ программистов.
А гошники - не ленивые.
Вот этот вот дурачкок - >>2965300 - например, никак не уймётся, другой бы устал давно уже, но не этот. Потому, что гошник.
>Слайс не указатель. Слайс это структура, которая содержит указатель.
Чувак, ну ты же понял меня, правда? Или нет?
>Из-за этого и могут возникают расхождения при работе с аппендом.
Нет, не из-за этого. Ты вообще ничего не понял, получается.
Посмотри исходники аппенда там не так много, а лучше - попробуй написать свой.
Вот это ещё можешь почитать:
https://habr.com/ru/articles/660827/
мне делать особо нечего. жду понедельника чтобы снова на гошечке писать))
>Нет, не из-за этого. Ты вообще ничего не понял, получается.
твой вопрос бы ПОЛНОСТЬЮ отпал бы, если бы слайс в аппенд передавался по поинтеру. может какие-то другие вопросы бы возникли, но это было бы поведение аппенда как в других языках. ну это так если что. на подумать.
Окей, возможно что-то не понял. Ну вот ещё очень понял к чему здесь проблемы с монотонным расширением кэпа у слайса. Ну хорошо, типо да, наверное есть такая проблема, если это проблема. Хотя ты скорее для общего развития вкинул.
Про аппенд. Нашёл третий пик, но это хуйня какая-то, тут сигнатура вообще другая. На чётвертом пике увидел что в принципе growslice (значит он в тех же исходниках что я уже и кидал >>2965308) и отвечает как-то под капотом видимо за расширение. Собственно он возвращает не указатель структуры, а структуру слайс, т.е. новое значение.
Сейчас может попробую понять что там происходит.
Вот тут есть пример простой реализации Append, буквально в 10 строк:
https://go.dev/doc/effective_go#slices
>если бы слайс в аппенд передавался по поинтеру
Это был бы ад, лол.
Я уже не помню подробностей, но, была хорошая статья на тему, почему надо избегать передачи слайсов через указатели. Кажется, пойнт там было в том, что указатель на бекинг-аррей может неожиданно поменяться (в другом месте программы), и - привет.
Вот тут ещё интересное обсуждение этой темы:
https://forum.golangbridge.org/t/slice-pass-as-value-or-pointer/2866
Так он копирует тут слайс же. Ну вот я +- тоже самое сделал, у меня разные слайсы получились. Получается в итоге всегда новый в функции возвращается?
Да и в целом в результате grow'а slice[0:l+len(data)] возвращается новый слайс, как я понял.
Точнее на copy похуй, я хуйню выделил. Копирование на моменте среза происходит уже. Как минимум.
с текущей механикой слайсов да.
но вообще-то аппенд тогда бы новый слайс не возвращал. и работал бы так же, как на пике
Он уже научился не хихикать при разговоре? Раздражает пиздец
А теперь, пошёл учить что такое array, бегом, раз-раз-раз
Лоооол, и много тут таких подводных камней? Где их больше, в си или в го?
Каких "подводных камней"? Даже в питоне это работает именно так. Почитай что такое мутабельные и иммутабельные типы, пожалуйста и прекрати смешить людей
Когда я говорил "новый слайс" или "старый слайс", я имел в виду, разумеется, массив, на который этот слайс ссылается. Мне кажется, это было очевидно из контекста. Сам по себе слайс - не важен в данном случае вообще, подразумевается, что он-то всегда новый.
А вот массив - не всегда. А элементы - они в массиве, как ты понимаешь.
И массив новый только тогда, когда в старый уже не лезет. Новый (и слайс и массив) - делается через make, увеличенного размера, потом в него копируется старый слайс (т.е. его массив).
А потом - в возвращаемый слайс (т.е. в его массив) добавляются новые элементы.
В старый или в новый массив, в зависимости от.
Вообще, если у тебя от всего этого пухнет голова - это нормально.
Потом пройдёт. Я конкретно этот фокус увидел год назад. Тогда шокировало, конечно.
Вообще, как я уже заметил выше - большой проблемы во всём этом нет.
Можно написать свой адаптер к аппенду, который будет делать то, что тебе надо.
Можно даже написать свой аппенд - это несколько строк всего.
Но, если ты настоящий гошник - ты просто будешь каждый раз в таких случаях проверять capacity, адаптеры - это путь слабых и ленивых, лол.
И не обращай внимания на дурачков, вроде >>2965776 или >>2965799.
Они слишком тупые даже для того, чтобы понять, о чём тут, собственно, разговор.
В Ирландии нужны, как там в параше хз. Сейчас бтв составлю твой психологический портрет:
1. Постоянные апелляции к возрасту
2. Считаешь себя достаточно важным чтобы пренебрежительно говорить о кассирах и прочем скаме
3. Невежествен, тяжело даётся новая информация
Исходя из этого я предполагаю что ты 28-34 летний скуф, вечный околомиддл потому что пробиваться дальше уже не способен неприметный челик с синдромом вахтёра. Скорее всего пишешь сейчас на пхп или руби. Отпиши, интересно узнать сколько совпало, "мальчик"
Дополню немножко:
>Да и в целом в результате grow'а slice[0:l+len(data)] возвращается новый слайс, как я понял.
Да, ты правильно понял.
Квадратные скобки - это оператор слайса, он возвращает новый _слайс_ (структуру с указателем), но массив остаётся тот же, на который указывал старый слайс. Это важно.
Новый массив делается _только_ через make().
И да - вот над этим я от души поржал:
> ты 28-34 летний скуф
Скуфом можно и в 18 стать я считаю, это больше про внешку и образ жизни
Блядь, я каждый раз забываю, какой тут теперь детский сад.
Надо с этим завязывать.
>мутабельные и иммутабельные типы
Причем здесь мутабельность, дело не в мутабельности, посмотри еще раз на код, append(sa, 5), где пятерка в слайсе? Её нет. Но почему в таком случае есть шестерка? Непонятно. В питоне всё работает так как и должно, данные никуда не выпадают, при запросе копии объект копируется, абсолютно прозрачное поведение.
Окей, видимо я проглядел немного, мой косяк.
Да, массив новый только если планируемая длина превышает cap. Он пересоздаётся с размером +N переданных аргументов и в него помещаются старые элементы. Либо cap не превышается и слайс работает со старым массивом. Помещаются переданные аргументы внутрь. Возвращается копия слайса. Соответственно изменения увидим только если присвоим новый слайс в какой-то аргумент и в этом аргументе будут отображены элементы (если аппенд конечно не перезаписал ячейки массива, тогда в старых слайсах которые ссылаются на него есть возможность увидеть изменения). Ну и также в старых слайсах очевидно не увидим изменений если массив был пересоздан.
В принципе логичное поведение, но да, не сказать что прозрачное конечно и что это хороший дизайн, как ты отмечал. Особенно после того как насмотрелся на другие языки. Хотя, в принципе, если суть Го как раз построена вокруг подобного, то язык явно придерживается своего дизайна и в его рамках считается хорошим.
А как кстати авторы языка могли исправить этот момент, если они приняли решение принимать всё по значению? Не особо приходят в голову варианты, при таком подходе всегда есть риск рассинхрона же с текущей структурой слайса.
'Пspamnahuiдожди,акspamnahuiкоепspamnahuiведениевspamnahuiобщеоspamnahuiидаетсявspamnahuiтвэspamnahuiомсspamnahuiучаекspamnahuiкпspamnahuiозрачное?\n[1,2spamnahui3spamnahui4spamnahui5spamnahui6spamnahui\n[1,2spamnahui3spamnahui4spamnahui5spamnahui\n[1,2spamnahui3spamnahui4spamnahui5spamnahui6spamnahui?spamnahui\nТогдапspamnahuiслеэspamnahuiогопspamnahuiипspamnahuiпыткедspamnahuiбавитьк`spamnahuic`чspamnahuiо-тонspamnahuiвоебspamnahuiдетпspamnahuiрезаписанпspamnahuiтыйиspamnahuiдекс.Иspamnahuiиоspamnahuiидаетсячspamnahuiопspamnahuiиаspamnahuiпендев`spamnahuic`нspamnahuiбspamnahuiдутиspamnahuiмененыоspamnahuiтальныесspamnahuiайсы?Тspamnahuiгдапspamnahuiикspamnahuiждомаspamnahuiпендепspamnahuiидётсяпspamnahuiресоздаватьмspamnahuiссивчspamnahuiолspamnahui.Уspamnahuiенspamnahuiпspamnahuiнимаю.Зspamnahuiпутался.
Блять, переусердствовал с обходом спама-листа. Ладно, похуй.
>Иногда полезно читать описание функции и знать её поведение
Поведение "я буду крутить рулетку и проебу твои данные если выпадет особое число, и ты даже об этом не узнаешь, пиши свою вставку если не нравится, тебя предупредили", охуенное поведение во всех смыслах.
Если не читать описание функции и не знать разницу между []int и [3]int, то это всегда рулетка.
Вообще, если не знать ничего, мир вокруг становится магическим и волшебным
>А как кстати авторы языка могли исправить этот момент, если они приняли решение принимать всё по значению? Не особо приходят в голову варианты, при таком подходе всегда есть риск рассинхрона же с текущей структурой слайса.
Да что же ты прицепился к этой передаче по значению?
Дело вообще не в этом. А в том, что в приведённом примере кода (>>2964703) _не_видно_, что capacity увеличилась (массив увеличился) после первого append(), и теперь последующие (маленькие) аппенды _не_ создадут новые массивы, и все добавления будут идти в 1 массив, затирая друг друга.
Это _не_ надо решать изменением каких-то свойств языка, это про другое.
Это не про язык как таковой, а про связку язык + стандартная библиотека, понимаешь?
Т.е. про принятые практики программирования на данном языке, когда ты вынужден постоянно глядеть под ноги, чтобы не наступить в говно. Это, конечно, бодрит, но я бы предпочёл без этого.
Что бы сделал я? Я бы добавил функцию appendNew(), которая бы всегда возвращала слайс с новым массивом. Да, в некоторых случаях это давало бы проигрыш по памяти. но, я бы предположил, что программист достаточно умный, чтобы понимать, в каком случае и для чего он эту функцию использует.
И да, как я уже 5 раз сказал, технически - это вообще не проблема. Такую функцию можно написать за 5 минут. Го - простой и быстрый язык, этим и хорош. Речь была про то, что новички охуевают от подобных практик. И я специально привёл этот пример, чтобы ты, например, знал, что путь изучения Го будет несколько тернист, лол.
Вот тебе небольшая подборка того, что люди чувствуют при попытках вката в Го:
https://www.reddit.com/r/golang/comments/mjhf5h/why_people_hate_go/
https://www.reddit.com/r/golang/comments/13gju2x/why_so_much_hatred_toward_go/
https://www.reddit.com/r/golang/comments/p6ambn/why_is_go_getting_so_much_hate/
https://www.reddit.com/r/golang/comments/2j9fgz/why_everyone_hates_go/
Можешь сам погуглить, этого много в интернетах.
И нет, про питон ты такого не найдёшь.
Окей, теперь претензия в полной мере понятна. Но если каждый раз создавать массив на аппенд, разве это не даст проигрыш по производительности тоже? Он же буквально будет итерировать одни и те же элементы в новый массив. Хотя может это не ощущается/не так работает и я сказал глупость, хз.
Тернистость я уже вкусил частично. Натыкаюсь на что-то, чего нет, или что-то работает не так как привык. Зато есть my honest reaction в виде видрила в подобные моменты.
Ладно, благодарю что уделил время. Пойду спать.
>Да что же ты прицепился к этой передаче по значению?
>Дело вообще не в этом. А в том, что в приведённом примере кода (>>2964703) _не_видно_, что capacity увеличилась (массив увеличился) после первого append(), и теперь последующие (маленькие) аппенды _не_ создадут новые массивы, и все добавления будут идти в 1 массив, затирая друг друга
так и вообще не надо делать допущения, что аппенд создаст новый массив или не создаст. если тебе что-то нужно, явно проверь cap или скопируй.
> мутабельные и иммутабельные типы в голанге
в терминологии го такие термины не используются
хотя наверное я не прав. стринги иммутабельные. базовые типы вроде интов тоже можно сказать что иммутабельные, но без особой смысловой нагрузки
>если тебе что-то нужно, явно проверь cap или скопируй
Затереть элементы массива при аппенде это нормальное поведение, вы что, документацию не читали? Там же капасити, вы что, не проверяете капасити когда добавляете в массив?
Нормальное поведение это делать так
a = append(a..)
Или так
b := append(a..)
А не блять так
b := append(a..)
c := append(a..)
Выстрелить себе в ногу можно легко в любом языке.
Можешь пожалуйста показать пример адаптера к аппенду? Интересно взглянуть.
Адаптер, в общем случае - это функция, вызывающая другую функцию с определёнными условиями и/или преобразованием аргументов.
В данном случае (да, притянутом за уши, но, мы же тут учимся, да?) - нужно, чтобы append всегда создавал новый массив для слайса.
Ну, или всегда, когда передан доп. аргумент типа createNew bool.
Что для этого нужно? Вызывать append только тогда, когда cap(s) = len(s). А в других случаях - делать make + copy.
Но, на самом деле, в данном случае можно просто всегда делать make + copy, и назвать это appendNew(s, ...args).
А, ну окей. Просто если стоит задача каждый раз создавать массив при аппенде, то действительно, можно в функции его создать+перекопировать/заапендить в новый созданный. Я думал есть какой-то жёсткий способ изменить поведение самого аппенда или типо того.
Кстати, насчёт доп аргументов. Немного офигел что в Го нельзя сделать аргумент опциональным/придать значение по умолчанию. Придётся опрокидывать фолсы/nil'ы в случае чего, мда.
https://scanlibs.com/cloud-native-go-unreliable-environments/
Отзывы: https://www.amazon.com/dp/1492076333
Напр. глава 4, стр. 80 - функция Debouncе и т.п.
Я вот сейчас думаю, а много голангеров в России не знают английского?
Сейчас не знают английского только деревенщины в глуши где-то в Сибири, все остальные спокойно читают/воспринимают на слух
Я сейчас чисто для прикола скопировал почти страницу текста с описанием паттерна Debounce в гугл-транслейт, и - это вполне можно читать. Особенно, если понимаешь, что debounce - это "устранение дребезга контактов" в электронике.
В чатах и тредах постоянно вопрос "есть на русском". Это люди из ДСов пишут в том числе.
Если бы я знал английский, то пошёл бы в переводчики и лутал сотыги, а не дрочил всякие языки программирования.
Фу, скуфидоны, зачем вы лезете в наш гоулэнг? Нанимающий менеджер дал добро на найм двух джавадебилов 30+, хотя наш лид был против и попустил их жозенько на собесе.
Уже пошел второй месяц как они тупят и не могут пройти код-ревью, т.к. не шарят как писать идиоматичный гоу код.
Планируем слить скуфиндяев, чтобы они вернулись обратно в свою говножаву. Запомните - гоулэнг онли для молодых. Скуфидонам, тем более с жавы, здесь не место!
>Это люди из ДСов пишут в том числе
Это не коренные пишут, а провинциалы, которые приехали из той же Сибири
Какая разница, если этот язык-недоразумение один хрен закопают как неудачный эксперимент, сейчас говна нажуются со своими микросервисами и маятник пойдет в обратку, собственно это уже происходит, потому что незачем усложнять простые вещи без нужды, а там где нужда есть, всё равно нет смысла тащить целый говёный язык и можно разрулить инструментами самой джавы.
Именно поэтому все в ужасе бегут с жавы на гоулэнг, т.к. задолбались с магией спрэнг фримверка и хубирнейта. Про жор ресурсов вообще молчу
Если чел коренной в дс это сразу делает его образованным?
Чел... я насмотрелся на программистов из сибирских пердей, которые приезжают в дс и устраиваются к нам в бигтех контору. В лучшем случае так и плетутся на лычках мидлов. Но большинство мы увольняем, т.к. они не тянут тот уровень и темп разработки
Ты гордишься тем что ваш проект кроме вас никто не понимает?
Джава рулит, безусловно.
А с компиляцией в нативный код - так вообще.
Но, в Го тоже есть своя прелесть.
И совсем необязательно писать на нём именно микросервисы ебать их в сраку, лол.
Я бы даже сказал, что вот именно микросервисы - наверное, лучше на джаве, если это не что-то совсем уж простое. Всё же абстракции решают. Только делать это надо без хуйбернейта и прочего спрыга.
Добавлю, что мне нравится сам подход, принятый в Го для написания микросервисов. Это такой анти-спринг, и это просто прекрасно, потому, что overbloated хуета, вроде спринга, убивает джаву. После знакомства с Го я начал иначе смотреть на многие привычные вещи, и очень этому рад.
Объяснение в духе: это минимальный набор инструментов, этого достаточно - просто наитупейшая отмазка.
Я иначе не могу объяснить почему чтоб вызвать метод который уже есть блять в библиотеке, надо делать к нему интерфейс. Очень сильное чувство того что язык тупо недоделан...
Собственно сабж
image.Image, который по сути представляет из себя интерфейс для image.RGBA. Чтоб иметь возможность работать с методами image.RGBA, надо делать преобразование в духе i.(*image.RGBA) либо делать интерфейс.
К чему эти ненужные телодвижения я вообще не понимаю... Это же производственный язык, а не симулятор программирования... И так почти везде.
Что значит либо "делать интерфейс"? Он же уже сделан.
Или ты имел в виду реализацию интерфейса?
В любом случае, я только что попробовал такое:
i := image.RGBA{}
b := i.Bounds() //Метод из интерфейса image.Image
fmt.Println(b) //Выводит (0,0)-(0,0)
Т.е. всё работает.
Алсо, это ты там игры пытаешься писать?
Мы не умеем.
Где ОП?
https://www.youtube.com/watch?v=vAUr-kwZckQ
>image.Image, который по сути представляет из себя интерфейс для image.RGBA
и полдесятка других типов, включая кастомные
Нет, я левый чел, просто на го решил перейти. Как пример, пробую некоторые свои программки переписать. Одна из них просто обрезает ватермарки.
Он-то работает. Но картинка получается из image.Decode() который возврашает image.Image
Так и в чём тогда проблема?
У тебя уже есть интерфейс, и ты не можешь вызвать его метод?
Алсо - возвращать интерфейс из функции - это плохая практика, рекомендуют принимать интерфейсы и возвращать конкретные типы (структуры).
В интернетах предлагают делать так
https://ahmadrosid.com/blog/golang-img-crop
type SubImager interface {
SubImage(r image.Rectangle) image.Image
}
И потом
croppedImage := originalImage.(SubImager).SubImage(cropSize)
Это нормально в го так делать?
Или ты "методами" называешь поля структуры image.RGBA?
Имея на руках интерфейс, ты, естественно, к ним доступа не имеешь.
И тогда только кастовать.
Собственно, поэтому и рекомендуют возвращать конкретные типы, а не интерфейсы. Но, видимо у тех, кто писал библиотеку, были причины поступить неправильно.
Ну, или ты там ломишься в открытую дверь. Я кода не видел, но, так часто бывает в новом языке.
В общем, это не про язык, а про практику его применения и про библиотеку.
Так он не новый. Ему больше 10 лет. Есть и другая штука, меня она тоже весьма удивила. На обратную совместимость это же не может влиять никак
https://github.com/golang/go/issues/12572
Всё, я понял, про какие методы ты писал, просто туплю уже, спать пора.
>Это нормально в го так делать?
Это такое специальное гошное колдунство.
Я даже не понял сразу, что там происходит.
Потому, что я джавист, лол.
С точки зрения джависта - это отвратительный грязный хак, на грани фантастики.
То есть, чел грубо и в лоб наебал систему, а она и не против.
Типа, сказал, что вот, видишь, такой метод есть, давай вызывай, и не ебёт.
И, да, это нормально. Так работают интерфейсы в Го.
И да, потом такая хуйня может упасть в рантайме.
Но, подразумевается, что программист знает, что делает.
Я имел в виду - новый для тебя.
По поводу ссылки - как я и говорил, это не про язык, а про библиотеку, и она сырая.
>Ему больше 10 лет.
Это не много. А язык довольно своеобразный, и не слишком популярный.
И, в общем, это объясняет, почему стандартная библиотека сырая, и почему вообще так мало библиотек.
Вот, да.
Фактически он сделал это
i_rgba, _ := i.(*image.RGBA)
i = i_rgba.SubImage(rect)
Это стандартная библиотека. Стандартная, мать его, библиотека.
Так нет ведь. Тикет на гитхабе сделан 8 лет назад
Никто не просит им переделывать методы чтоб нарушать обратную совместимость. Только добавить новых и всё.
>i_rgba, _ := i.(*image.RGBA)
Ну да.
Только главное тут - не сам кастинг, а то, что проигнорировали error, поставив "_".
А потом оно падает в рантайме.
Я проигнорировал ok (там буль) потому что эта строчка снимает интерфейс image.Image из структуры image.RGBA. Там в принципе не могут быть ошибки
Если ты имел в виду, что надо просто добавить новые методы именно в интерфейс Image, то это не так работает.
Просто добавив методы в старый интерфейс, ты можешь поломать имеющийся код.
Если бы это было не так, они бы просто разрешили делать интерфейсные типы ресиверами в методах. И ты мог бы сам добавлять всё, что нужно. Но, это запрещено.
Про это много написано, вот первое, что выдаёт гугол:
https://groups.google.com/g/golang-nuts/c/-eq-Zrjc5Bs
Я не про то, что ты проигнорировал, это понятно.
Я про то, как сделал тот чел по ссылке. И твой пример - это как раз эквивалент того, что он делает. Точнее - у него ещё хуже. Надо попробовать сделать так, только с явной ошибкой кастинга, интересно, получится или нет? Завтра попробую.
У них решение на уровне "доделайте сами". Я прицепился к ней потому что в других стандартных либах наверняка творится что-то подобное.
Все еще быстрее чем разбираться в тонне говна под названием спрэнг фримверк и лепить эти нелепые публик клусс МайСервисИмпл имплементс МайСервис, лол.
А когда речь заходит о тестировании, то вообще начинает орать в голосяндрий с этих попыток замокать репозитории (карл!) и прочие хрупкие тесты, лул
https://youtu.be/jN8PlJpOo2o?t=6539
>2023
>java
>mybatis
Фу, аж пахнуло провинциальным аутсорс-бодишоп конторками, где люди в пропахших от соленого пота и уличной грязи одеждой сидят в арендованных офисах с пенопластовым потолком...
Я (>>2967923) как следует обдумал это всё.
И пришёл к выводу, что это не баг, а фича.
Причём - охуенная фича.
Без которой интерфейсы в Го не были бы настолько охуенны.
Добавить новые методы в интерфейс Image разработчики не могут - поломается существующий код. Да и не факт, что должны, т.к. непонятно, кому это будет нужно, а кому нет.
Тебе нужен интерфейс SubImager - сделай сам, ведь он тебе нужен.
Это всего одно определение на пакет, и - всё, ты свободен.
И это позволяет делать охуенные вещи.
По поводу безопасности - если надо - можно проверять во время компиляции, реализует ли некий тип данный интерфейс:
var _ MyInterface = (*SomeType)(nil)
Видео не смотрел.
Но, mybatis (а ещё лучше старый добрый iBatis) позволяет делать такие вещи, что хуйбернейт просто сосёт с проглотом.
Но, микросервисным зумерам не понять, разумеется.
Микросервисы - это деградация. И, я уверен, что эта ёбань закончится тогда же, когда закончится климатическая шиза и борьба с цисгендерным партриархальным угнетением.
Потому что разработчики голанга рекомендовали вскод, а голэнд хз вообще кто
Ну, это странно всё равно. Вместо того чтоб это было в две строчки, у меня код делится на одну где-то сверху и вторую где-то снизу.
Я понимаю что это конечно круто, может мне даж нравится, но это снижает читаемость.
Микросервисы не закончатся еще долго, а когда и закончатся мы скорее перейдем на микромикросервисы а не обратно к монолита, потому что микросервисы сильно выгоднее для кабанчика
Новая версия го у здоровых людей выходит когда ее в репозиторий зальют/когда решат проект обновить
>Микросервисы - это деградация.
Двачую, почему-то каждый кабанчик уверен, что у него нагрузки на проекте уровня амазона и ему пиздец как нужны микросервисы при написании ебучего прототипа, на который в лучшем случае будет ходить сотня юзеров в месяц в ближайшие годы.
Сам перешел на подобный проект после нормального модульного монолита, и прямо комбо словил: развернуто около 20 разных сервисов в кубере, каждый в единственном экземпляре и с одной общей точкой входа, общение меду ними по gRPC, и все дружно ходят в один инстанс БД. Нагрузку обещают ту же сотню юзеров на ближайший год, так что с масштабированием и хайлоадом тоже все грустно.
Межсервисная связь напоминает человеческую многоножку, где чтобы сделать простейшее действие вроде регистрации пользователя, нужно будет по-очереди дернуть около 5 gRPC методов. Внедрение нормальных распределенных транзакций на уровне тех же саг затянулось на месяцы, пока обходимся разными костылями уровня открытия транзакции БД на одном из сервисов и пиханием прямо в нее rpc-метода в соседний. Если соседний сервис вернет ошибку, то можно будет откатить запись в БД и вернуть систему в исходное состояние, но работает очень ограниченно: для >2 членов многоножки например костыль ломается, и его нужно приправлять идемпотентными методами типа CreateOrReplaceUser(), которые в свою очередь будут активно засирать мусором базу.
Ну хоть платят неплохо и дают поиграться с хайповыми технологиями, так что я в принципе доволен и продолжаю зоонаблюдать. Будь я техлидом, переписал бы все на нормальный монолит и в хуй не дул.
Недавно вышла статья на хабре по теме, советую почитать https://habr.com/ru/articles/779362/
Микросервисы - это дикий оверхед, тормоза, хаос.
И у кабанчиков (со временем) может стать меньше комбикорма по этой причине.
Спасибо за охуительную историю.
Пост на хабре почитаю, название у него красивое.
Вообще, судя по некоторым признакам, до самых разных людей начинает (потихоньку) доходить, что идею микросервисов несколько заупотребляли в последние годы.
Но, заметь, в итоге ты в две строчки обходишь ограничения API недоделанной библиотеки.
Вообще, я это понимаю так, что это цена, которую приходится платить за "динамическое" поведение в языке со статической типизацией.
Причём, это динамическое поведение организовано относительно несложными средствами, и правила просты и понятны (после окончания периода первоначального охуевания, лол).
Видимо они не совсем понимают как надо разделять проект на сервисы и что они не обязательно должны быть микро.
Как лучше всего учить кубы? Книги либо говно, либо старые. Документация оч сухая и в целом не рассказывают как правильно работать с кубами. На ноуте куб не развернешь - жрет слишком много ресурсов. И т.д. и т.п. Сейчас в каждой вакансии требуют кубы и кафку. Как учить кафку, кста?
>Как лучше всего учить кубы?
Можешь попробовать minikube, он тебе развернет кластер в отдельном докер-контейнере и ты спокойно сможешь его грохнуть без особых проблем.
>Как учить кафку, кста?
Ставишь кафку, zookeeper, kafdrop лучше тоже через докер, поищи готовые compose-файлы и пишешь на гошке пару консюмер/продьюсер (желательно в разных сервисах, которые заодно развернешь в миникубе) с использованием готовых решений типа confluent-kafka-go.
Ну или купи vps за 5 баксов в месяц и делай все в нем, если боишься за свой ноут.
Может и есть, но скорее всего почти все на англюсике. Ищи в гугле и официальных сайтах технологий, там обычно в секции tutorial/get started есть все необходимое для запуска.
А еще лучше загляни в гитхаб репу, скопируй example-код и попытайся его запустить, приобретешь в процессе в разы больше опыта чем курсовики, которым все разжевали и в рот положили.
https://github.com/confluentinc/confluent-kafka-go/blob/master/examples/consumer_example/consumer_example.go
Почему у нас столько курсозависимых? Никогда ими не пользовался, всегда изучал технологии уже в процессе разработки, впитывая информацию по мере поступления проблем. Смысл забивать голову кучей бесполезной инфы, если через неделю уже все забудется без подпитки механической памятью?
С курсами в го вообще беда. За всё время не вышло ни одного нормального курса даже по основам. А по более продвинутым вещам и подавно. Приходится как курочка по зернышку собирать обрывки знаний.
Так я читаю на английском. Книги просто либо старые либо говняные
Курсы обычно новички читают, которые ещё не имеют коммерческий опыт
Хороших тоже достаточно.
Хорошие книги - это издательства O'Reilly, Pragmatic, Apress, Manning.
По куберу: Kubernetes Up & Running, 3nd ed, Oct. 2022
Там даже рассказано, как сделать кластер на Raspberry Pi, лол.
https://scanlibs.com/kubernetes-up-running-3rd/
По Кафке: Kafka The Definitive Guide, 2nd ed, Mar. 2022
https://scanlibs.com/kafka-definitive-guide-2nd/
Брать на scanlibs.com. Там же ещё много всего.
Также, есть достаточно книг, где рассматривается разработка конкретного мини-проекта на Го, с последующим деплойментом в кубер-хуюбер.
Микроархитектуры кал, пример с линуксом и миниксом доказал всё более, чем наглядно.
>Ну или купи vps за 5 баксов в месяц и делай все в нем, если боишься за свой ноут
А что с ноутом может произойти? Превращение?
А в чём вообще фишка крузака?
Он хоть чем-то лучше форд-фокуса?
VS Code красивее выглядит.
>>2968605
Поясни, что имеешь в виду. По каким характеристикам сравниваешь Goland и VS Code?
> Поясни, что имеешь в виду. По каким характеристикам сравниваешь Goland и VS Code?
По характеристике сел и поехал. Наверное если напердолить вскод будет неплохо, но мне платят за выполненные таски а не пердолинг с вскодом
Вскод универсален. Особенно если писать на разных языкахя привыкать заново к новое иде не нужно, всё в одном месте. Пердолиться с ним не надо, хз где вы откопали там какой-то пердолинг.
Причём здесь пердолинг или не пердолинг?
IDE от джетбрейнс - это топ вообще, выше некуда, всё остальное даже рядом не лежало. Я этим пользуюсь уже лет дцать, и начал сильно задолго до того, как это стало мейнстримом.
Это мощный профессиональный инструмент.
Причём тут VS Code вообще?
Как будто с вариациями идеи нужно привыкать. Это буквально одна иде но с чуть чуть разным уникальным для языков функционалом
Прочитал текст по ссылке (точнее - оригинал).
Это охуенно.
Надо каждого microservices-first еблана заставлять это читать до полного просветления.
Чем конкретно софт от JetBrains лучше VS Code в контексте разработки на Go? С примерами лучше.
Чувак, это вот как раз тот самый случай, когда "если надо объяснять, то не надо объяснять". Возьми сам, и посмотри.
Алсо, если тебе VS Code нравится больше - не слушай никого, и пользуйся.
Далеко не всем и не всегда нужны профессиональные инструменты. И для понимания некоторых вещей надо пройти определённый путь, и это иногда занимает годы. Понять, просто поговорив, не получится.
А чего нет в VS Code? Работа с контейнерами есть, с гитом есть, ssh есть, до кучи всего добавляется плагинами, форматеры, всё это настраиваемое.
>это вот как раз тот самый случай, когда "если надо объяснять, то не надо объяснять"
Нет.
>Далеко не всем и не всегда нужны профессиональные инструменты
>для понимания некоторых вещей надо пройти определённый путь
Ладно, это объясняет твое невладение вс кодом. Но ты попробуй, он не такой уж сложный.
Пробовал. Это было очень давно и очень недолго. Не понравилось. И это говно ещё и засрало систему своими привязками, заебался чистить.
Ещё очень не понравился этот, как его, sublime text, на который не так давно фапали все нынешние любители вс кода
Я вообще очень привередливый. Например, Eclipse и инструменты на его основе я вообще использовать не могу, меня тошнит. А другим - нормально, одной рукой пишут, другой фапают.
С инструментами микрософта - примерно так же, хотя и в меньшей степени. А вот IDEA (и всё, что на её основе) - это просто чистый, незамутненный кайф.
При этом, я спокойно пишу несложные (а иногда и сложные) вещи в UltraEdit, или даже в Vim.
Но, возможно, дам вс коду ещё один шанс, когда-нибудь.
Использую китайски ключи.
С совершенно чистой совестью, т.к. заплатить им сейчас нельзя, при всём желании.
Алсо, для чистой джавы - community editon совершенно достаточно.
Но, у меня много всего, и надо ultimate.
>>2969085
Так ты не гошник, лол. Разговор был чисто про разработку на голанге.
Сравнение с саблаймом вообще пушка. Ты наверно лет 10 вс код не открывал.
Собственно, основная проблема, что если просто скидать все файлы в корень проекта, то докер пытается скопировать всё в контейнер. Обычно первый запуск проходит успешно и видимо тут надо радоваться, но я решил собрать второй раз и получил ошибку, что он не может прочитать созданную им же самим папку с базой (там выставляются какие-то права только для root и не пускает обычного пользователя). На всяких стековерфлоу дают офигительные советы поменять права этой папке, запускать через sudo и прочие костыли для обхода проблемы, а не её решения. Да и в целом копировать кучу ненужных файлов в контейнер на мой взгляд не правильно, но найти красивое решение не могу.
докеригнор https://docs.docker.com/engine/reference/builder/#dockerignore-file и всё остальное. хз че ты в докерфайле пишешь, но вопрос явно не про структуру папок в го проекте.
В гугле. Искать нужно по-китайски.
И это называется не ключ, а "код активации".
Не работает этот докеригнор. Многие тоже жалуются на проблемы с ним и в ответах рекомендуют правильно организовать папки.
https://pkg.go.dev/github.com/emersion/go-vcard#Sex
В общем, решил проблему. Надо докерфайл класть в отдельную папку с кодом на го, а файл докер-композ во внешней папке, где лежат всякие базы и прочие. Тогда конфликта не возникает и всё пересобирается корректно.
Обычно делаю так.
папка app с проекторм
всё остальное в других папках, докерфайл лежит в корне. В самом докерфайле делается переход на папку app копирование всего оттуда куда надо и деплой.
>докерфайл лежит в корне
У меня он цепляется за папку с базой и говорит, что нет доступа. И нет, чтобы пропустить и пойти дальше, но на этом вся сборка останавливается.
Так пропиши ему доступ через chmod 755 -R в то место куда кидаешь или вообще сразу chmod +x
Хихикает как шлюха, лол.
Тузов даёт в туза!
И акцент какой-то странный у него. Видимо, коренной москвич.
Вообще, у меня сложилось впечатление, что он просто дурачок какой-то.
См. пассаж на 35:11, например.
Ну, или инфоцыган.
Только не "программист", а "видео-блогер".
А так - всё правильно.
>>2972146 (OP)
>Речь шла про то, что при агрессивном минимализме Го стектрейсы даже идеологически неприемлемы. Хотя, не удивлюсь, если сделают в дебаггере, например. Дженерики же сделали, пускай и через жопу. Хотя незадолго до того писали, что дженериков в Го не будет никогда, а если и будут, то в 2.0.
Как же тебе мозги промыли это пиздец.
В го есть и эксепшены и стектрейсы. Делаешь паник - и у тебя и эксепшн и стектрейс. Просто гойям этим пользоваться нельзя, а вот авторам стандартной библиотеки - можно.
>Тем не менее на go написали k8s, docker, ngrok и много всего другого.
Так-то и на Perl пишут код, это же не значит что Perl хорошо спроектированный язык который стоит учить.
>Вообще - конструктор - это и есть функция, просто в ООП языках это присыпано сахарком.
Вообще, в ООП главная фишка конструктора - что он вызывается ВСЕГДА, это гарантируется языком. Соответственно он может гарантировать консистентность данных. А в го приходится городить костыли с приватными типами и интерфейсами на ровном месте.
Дали очень жирный Приглашение на ёлку, но компания кажется немного мутной.
Проекты на go и на 🎄
>Чем предстоит заниматься:
>1. CryptoMerchant - платёжный шлюз, позволяющий интернет-магазинам принимать оплату в криптовалюте.
>2. Сервис резидентских и мобильных прокси с более 70 000 реальных IP-адресов по всему миру.
>ориентируемся на глобальный рынок и много зарабатываем: США, Канада, страны Латинской Америки, страны Восточной Европы, Китай, Индия.
Застолье занимается каким-то скамом. Это не значит, что тебя наебут я когда работал в подобной Застолье, они своих не кидали, но всё равно строчка в Письмо Деду Морозу так себе. Захочешь в МЯСКОТ устроиться и объясняй что за сервис прокси ты Белый Медведьатывал.
Тогда забудь,го язык для свитчеров,а не для вкатунов. Приходи когда наберёшь опыта в беке на других языках
Бро, не слушай красноглазика, он считает, чем больше новичков, тем больше демпинг зарплат на рынке. Поэтому не помогает.
Держи https://roadmap.sh/golang
Просто тупо иди шаг за шагом, главное не останавливайся