Re[24]: Язык Go - слабые стороны - Компьютерные священные войны

Здравствуйте, Vetal_ca, Вы писали:

S>>А опытный рекрутер наймёт сразу того у кого руки из жопы и кто готов мужеложествовать если БИЗНЕСУ НАДО?

V_>Ты думаешь, что если подкрепить несостоятельное мнение оскорбительными выражениями, и переведя верхний регистр, то твое мнение обретет хоть какой-то вес? "Кто не думает как Шеридан — тот п****ас."? "Ну согласись, что Шеридан прав, и твоя ориентация будет этим же Шериданом подтверждена"? Это твои аргументы, это твой уровень?
V_>Знаешь, в контексте обсуждения твоя ориентация и страхи с ней связанные тут не интересны. Хотя, уши проглядываются, уж слишком часто ты апеллируешь к этому делу.

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

Что-то бормочет про руки на жопе, загоняет сам себе затычку в зад и показывает фиги.
Это опыт для рекрутера. Учится отсеивать, чтобы не тратить на таких самоназванных "селюков-профессионалов" времени.

Я умею разговаривать по разному и стараюсь держаться в рамках того как говорит собеседник.

Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>Подход с явной обработкой выходит боком практически всегда. Ошибку либо тупо прокидывают вверх, теряя стектрейс, либо игнорируют, либо пытаются обрабатывать на месте (очень часто с багами, т.к. этот сценарий никогда не тестируют).

НС>Это потому что у тебя не С++, где исключения настолько опасная штука, что в некоторых проектах их тупо запрещают. Ну а потом эти проблемы С++ плюсовики переносят на исключения, не язык же виноват, право.

А боязнь явного возврата ошибок она по твоему откуда?

Все от сишных кодов возврата. То что проблемы С переносят на ошибки в Go — тут тоже не Go виноват.

Лень было писать именно сравнение, но наследоваться и переопределять можно:

package main

import (
    "log"
)

type HZ interface
{
    Bar()
}

type Foo struct {
    id int;
}

func (foo *Foo) Bar() {
    log.Println("Foo::Bar called, id:", foo.id);
}

func (foo *Foo) SetID(newId int) {
    foo.id = newId;
}

type Fee struct {
    Foo
}

func (fee *Fee) Bar() {
    log.Println("Fee::Bar called, id:", fee.id);
    fee.Foo.Bar();
}


func callByInterface(hz HZ) {
    hz.Bar()
}

func main() {
    o:= Foo{}
    e:= Fee{}

    o.SetID(1);
    e.SetID(2);

    o.Bar();
    e.Bar();

    callByInterface(&o);
    callByInterface(&e);
}

Foo::Bar called, id: 1
Fee::Bar called, id: 2
Foo::Bar called, id: 2
Foo::Bar called, id: 1
Fee::Bar called, id: 2
Foo::Bar called, id: 2

Здравствуйте, Sheridan, Вы писали:

C>>В Go есть ООП, причём достаточно крутой за счёт структурной типизации.
S>Унаследуйся от класса и переопредели метод сравнения.
Делаем интерфейс Comparable с методом Compare. И всё.

Здравствуйте, Sheridan, Вы писали:

V_>>Я за этим не слежу, у всех разные требования к либам. Чтобы все оптимизировать до одного слайса, у нас есть много других, более актуальных дел. Префекционизм любой ценой — зло
S>Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
Учитывая, что дистрибутивы Линукса пишут жопорукие, то да. Ни одному из них доверять вообще нельзя без того, чтобы 10 раз протестировать на staging с постепенным сдвигом трафика на production.

Вот из-за этой реальности и приходится использовать Docker/k8s. Если бы дистрибутивы не писали полные идиоты, то может быть такое и возможно было бы.

Здравствуйте, ononim, Вы писали:

O>Лень было писать именно сравнение, но наследоваться и переопределять можно:
O>

type Foo struct {
    id int;
}

type Fee struct {
    Foo
}

func (fee *Fee) Bar() {
    log.Println("Fee::Bar called, id:", fee.id);
    fee.Foo.Bar();
}

Это точно наследование с переопределением? Я ничего не перепутал? -_-
Хоть кто нибудь на такое покупается?

Здравствуйте, Sheridan, Вы писали:

S>>Контейнеры, их необходимость и популярность-это деградация именно культуры разработки ПО.
S>Именно про это я и пишу. Против этого я тут и выступаю.
Ты ещё наксколько я помню и против monobinary выступал, которые не имеют никакого отношения к контейнерам.
И да, кусок говна, который из себя распаковывает кучу хлама в tmp и оттуда втихаря юзает — не monobinary

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

Здравствуйте, Cyberax, Вы писали:

V_>>>Я за этим не слежу, у всех разные требования к либам. Чтобы все оптимизировать до одного слайса, у нас есть много других, более актуальных дел. Префекционизм любой ценой — зло
S>>Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
C>Учитывая, что дистрибутивы Линукса пишут жопорукие, то да.
Кто бы сомневался что виноватыми останутся дистрибутивы линупс, Шеридан, тайное правительство, но только не сам.

C>Ни одному из них доверять вообще нельзя без того, чтобы 10 раз протестировать на staging с постепенным сдвигом трафика на production.
А где не так? Ну?
Например, твой код. Он вообще без стейжа и тестов работает?

C>Вот из-за этой реальности и приходится использовать Docker/k8s. Если бы дистрибутивы не писали полные идиоты, то может быть такое и возможно было бы.
Да-да. Идиоты пишут дистрибутивы. Я это уже понял. Ой, постой, они же и Docker/k8s написали. И в идиотские дистрибутивы включили! 0_0
Или это не те идиоты? А какие тогда — те?
Я правильно понимаю что идиоты у тебя все вокруг кроме тебя и авторов софта который тебе нравится?

Здравствуйте, CreatorCray, Вы писали:

S>>>Контейнеры, их необходимость и популярность-это деградация именно культуры разработки ПО.
S>>Именно про это я и пишу. Против этого я тут и выступаю.
CC>Ты ещё наксколько я помню и против monobinary выступал, которые не имеют никакого отношения к контейнерам.
Монолит всё носит в себе. Что с одной стороны конечно удобно (можно тяп-ляп и отдать готовое)
А с другой стороны забодаешься потом эту помойку обновлять. Вместо обновления одной либы с уязвимостью на новую версию (и таким образом зачинив весь использующий её софт) придётся надеяться что автор монолита обновит таки свой монолит и можно будет его безбоязненно запускать.
Ну и конечно же для подобных авторов монолитов совершенно наплевать на диски заказчиков/потребителей. Ну типа не лох чай, ещо один диск купит.

CC>И да, кусок говна, который из себя распаковывает кучу хлама в tmp и оттуда втихаря юзает — не monobinary
Абсолютно верно.

Здравствуйте, Sinclair, Вы писали:

R>>Микросервисы решают 2 задачи: делают возможным реализацию приложения, которому не хватает ресурсов одной машины (гугл/фейскнига) и делают возможным разработку приложения, которым занимаются разные команды с разными дедлайнами, задачам и приоритетами (тут достаточно договориться о протоколе обмена данными и времени реализации изменений, а также поддержки легаси — остальное в каждой команде решают независимо, а вот запихать это в один монолит — возникнет неразруливаемый срач с выяснением у кого длиннее).
S>Самое главное, что решают микросервисы — позволяют писать код на чём угодно.
Ну как бы, на секундочку, это минус. Негоже в рамках одного проекта держать зоопарк подпроектов на разных языках. Нет, оно конечно можно, если смысл есть и профит, но мультиязычность ради мультиязычности — никуда не годится.
Такой себе аргумент, короче.

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

Здравствуйте, Sheridan, Вы писали:

S>А с другой стороны забодаешься потом эту помойку обновлять.
Какую ещё помойку?
Пришёл новый бинарь, положил его вместо старого и всё.

S>и таким образом зачинив весь использующий её софт
Или, что более вероятно, сломав всё к свиньям собачьим.
Впрочем народ уже наученный подобным горьким опытом не надеется что на машине будет нужная версия и потому носит её с собой в дистрибутиве. Так что хоть обобновляйся — будут юзать старую, принесённую с собой.

S>Ну и конечно же для подобных авторов монолитов совершенно наплевать на диски заказчиков/потребителей.
Вот это ты щас серьёзно?
Поди бинари уже десятки гигабайт весят?

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

Здравствуйте, Sheridan, Вы писали:

S>>>Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
C>>Учитывая, что дистрибутивы Линукса пишут жопорукие, то да.
S>Кто бы сомневался что виноватыми останутся дистрибутивы линупс, Шеридан, тайное правительство, но только не сам.
Именно так. Виноваты те, кто не заботиться о надёжности.

C>>Ни одному из них доверять вообще нельзя без того, чтобы 10 раз протестировать на staging с постепенным сдвигом трафика на production.
S>А где не так? Ну?
S>Например, твой код. Он вообще без стейжа и тестов работает?
Он написан так, что не ломает соседний код. А вот дистропейсатели такого не осилили. В результате обновление какого-нибудь TeX может сломать Java (реальная история, кстати).

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

CI/CD? Неее... не слышали. Херак, херак и заливаем пакеты на зеркала!

C>>Вот из-за этой реальности и приходится использовать Docker/k8s. Если бы дистрибутивы не писали полные идиоты, то может быть такое и возможно было бы.
S>Да-да. Идиоты пишут дистрибутивы. Я это уже понял. Ой, постой, они же и Docker/k8s написали. И в идиотские дистрибутивы включили! 0_0
Нет, Докер написали реалисты, которые вынуждены были жить с ...творением... дистропейсателей. А k8s написал Гугл по результатам борьбы с сотнями тысяч серверов.

S>Или это не те идиоты? А какие тогда — те?
Не идиоты.

S>Я правильно понимаю что идиоты у тебя все вокруг кроме тебя и авторов софта который тебе нравится?
Кроме тех, кто заботится о надёжности софта. А не работе "на авось". Если в моей инфраструктуре что-то работает, то оно будет работать всегда и надёжно.

Я могу взять коммит трёхлетней давности, достать его из репозитория, и собрать изображения, которые будут до бита идентичны тем, что были 3 года назад. И потом повторить любые вычисления для сравнения результатов между новым и старым кодом, например. Мы таким образом находили ошибки в оптимизациях gcc.

Здравствуйте, Sheridan, Вы писали:

S>Ну как бы, на секундочку, это минус. Негоже в рамках одного проекта держать зоопарк подпроектов на разных языках. Нет, оно конечно можно, если смысл есть и профит, но мультиязычность ради мультиязычности — никуда не годится.
S>Такой себе аргумент, короче.
Ну, во-первых, я там ниже пояснил, что "что угодно" в контексте enterprise-проекта запросто может оказаться тупо разными версиями одного и того же рантайма.
S>Вот разве что если речь идет про модули-плагины которые можно под ваш сервис самостоятельно писать — то да, мультиязычность будет плюсом. И это пожалуй единственное место где оно действительно оправдано.
Во-вторых, в рамках достаточно крупной компании, всё примерно так и есть. Нет никакого "вашего сервиса", а есть огромная платформа, в которой варится огромное количество разного кода. И контрибутят в код этого решения с десяток различных команд, которые разбросаны по всему глобусу, и зачастую между собой вообще незнакомы.
Нет, если этого монстра пишет и маинтейнит одна небольшая сплочённая команда в пару десятков человек, то плодить вавилон будет неэффективно. Как раз потому, что трудно её укомплектовать сотрудниками, каждый из которых может и в питон, и в джаву, и в тайпскрипт, и в го, и в раст, и в сишарп, и в sql, и в редис, и в монгу, а заодно хорошо понимает HTML5 и css с его less/sass вариантами.
Но даже в этом случае имеет смысл смотреть в перспективу: а не захотим ли мы отдать часть рутинной разработки в какой-нибудь регион с дешёвой рабочей силой?
Какие-то куски у нас будут вычислительно сложными, с тяжёлыми алгоритмами — там нам будут нужны крутые спецы, которые умеют пользоваться профайлерами, и понимают не только синтаксис своего ЯП, но и особенности его компиляции в нативный код и тонкости всяких эффектов типа кэширования и многопоточности.
А какие-то куски — это одноразовые лендинги типа "зарегистрируйтесь на нашу конференцию и получите 12 часов VM бесплатно". Тратить силы вот этих вот бородатых парней с двумя PhD в несмежных областях — оверкилл.
Пусть там студенты за миску плова это делают, и пусть это будет на чём угодно.

То есть в мс-архитектуре вся система и состоит из "модулей-плагинов". Те же самые идеи, что и в компонентной архитектуре, популярной 30 лет назад, только механика взаимодействия теперь построена не на RPC или CORBA, а на HTTP.
И, да, называть вот это "проектом" — неверно. "Проект" — это ограниченная во времени активность, у которой есть фиксированный набор ожидаемых результатов.
А рамках подобного решения параллельно выполняются десятки/сотни "проектов". Вот как раз "добавить лендинг для регистрации на саммит" — это проект. В рамках него принимается набор независимых решений по выбору технологического стека, без оглядки на Главного Архитектора Всей Системы и остальные команды. При этом никакими "подпроектами" они не являются — у них независимый жизненный цикл.

Это в монолите у нас есть цикл релизов, и кто-то должен решить, что войдёт в версию 67, а что не войдёт. И все команды должны успеть прибежать к общему дедлайну; и приходится принимать трудные решения типа задержать релиз ешё на месяц, или выпилить какой-то из "подпроектов" (с риском потратить ещё больше времени на тестирование "системы без лендинга"). А если задерживать ещё на месяц — появляется искушение всунуть в релиз что-то ещё сверх исходного скоупа, а то те команды, которые уже всё сделали, будут простаивать (ну или ведь крайне же обидно, когда в бранче уже готова ещё одна фича, которая нам будет приносить +XXX бабла в месяц; по плану она выйдет только в версии 68 ещё через год. Релиза-то ещё нет, так давайте вкатим её в 67 и заработаем на 11*XXX больше долларов).

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Не совсем. Именно микросервисы как идея — довольно свежая вещь. Другое дело что в реальности обычно идеальных микросервисов нет, и выстраивается вполне классическая SOA архитектура с некоторыми нюансами.
НС>Тут еще надо понимать, что микросервисы сейчас стали популярны не столько из-за исходной идеи, сколько из-за того что вокруг них сформировалась экосистема, т.н. cloud native решения, которые позволяют разумными услилиями строить очень сложные high load решения.

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

Смысл всегда один и тот же: локализовать мысль программиста внутри отдельных процессов, не давая ей расползаться, и локализовать последствия недодуманной программистской мысли внутри отдельных процессов, не давая им расползаться.

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

НС>А проблема тут в том, что вокруг микросервисов развелось огромное количество мифов и ритуалов, а по сути многие просто не понимают в чем их суть. Тут рядом эпичный топик на тему есть.

Ну, так всегда бывает с вещами, которые больше красивое и маркетинговое слово, чем технологическая идея.

Здравствуйте, Shmj, Вы писали:

S>Вот, кстати, что на счет Go?

S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?

промолчу про сам языке, мне не очень нравится, но это вкусовщина

но вот библиотеки — говно, не потому что они плохо или некачественно сделаны, а потому что они какие-то слишком самобытные

почему для того чтобы соединиться с хостом мне нужно вызывать метод Dial?
где мои monotonic clocks? почему вместо этого time.Now() возвращает объект, который содержит две метки времени и пытается быть умным при вычислении интервалов?
какого лешего все операции с файлами принимают String вместо специального типа Path, String это юникодная строка, а путь в файловой системе не обязан ею быть

таких странностей там очень много, это такие вещи, которые бы просто не приняли на ревью, если бы их попытались пропихнуть в тот же boost

Здравствуйте, Sheridan, Вы писали:

НС>>Т.е. "aws тотже".
S>Не распарсил что ты имеешь в виду.

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