How to become an author
Search
Write a publication
Pull to refresh

Comments 35

Простите, а почему бы не сделать один бинарник на Golang, и вызывать нужную вам функцию через параметр?
Например:
<binary-name> config args.json res.json

Тогда как минимум вам не нужно будет дублировать весь рантайм и библиотеки в каждом бинарнике.
Total votes 5: ↑5 and ↓0+5

Хороший вопрос. Так не сделали, потому что подход выработался не заранее перед началом работы, а уже во время переписывания.


Во время переписывания было удобно распределить работу параллельно по людям и каждому дать задачу типа: вот тебе компонент, ожидается бинарник с таким-то интерфейсом. При этом каких-то договоренностей о том, как устроен бинарь не было, главное чтобы делал то что надо и соответствовал интерфейсу. Так было удобнее делать работу именно параллельно с точки зрения редактирования кода. В случае когда один бинарь и над ним работает несколько человек — надо сразу определиться с "правильной" организацией кода, чтобы несколько человек не редактировало один файл. Нам же был больше нужен быстрый результат, чем экономия места.


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

Total votes 4: ↑4 and ↓0+4

Я конечно только за прогресс, но не нашел в вашей статье доводов для переписывания именно на Го.


Во-вторых, простота установки

С использованием контейнеризации этот аргумент выглядит сомнительно


В-третьих, скорость работы

Ну если уж на то пошло то скорость работы Rust или Kotlin Native заметно выше(не на порядок конечно) да и комфорта больше ибо оба языка гораздо богаче в плане фитч, да и инфраструктура тоже если не лучше то эквивалентна голанговской.

Total votes 3: ↑2 and ↓1+1
«Во первых» тоже отпадает. У k8s есть api, который может работать на любом языке, хоть на php.
Total votes 4: ↑2 and ↓20
Сложно согласиться. Когда проект для широкого сообщества, которое поголовно пишет на Go, и взаимодействует с другими проектами этой экосистемы, вопрос вовсе не в одном конкретном API.
Total votes 2: ↑2 and ↓0+2

Это только в теории. Есть проблемы с аутентификацией в api например. Ниже ответил развернуто.


В k8s еще есть куча оберток над этим api. Например, shared-informer-ы для слежения за состоянием ресурсов. Эта обертка решает низкоуровневые проблемы и является стандартной для написания kubernetes-операторов. В других языках такого нет, пока сам не напишешь.

Total votes 2: ↑2 and ↓0+2
Не вникая в проблему, так действительно может показаться, однако реальность чуть сложнее.
Последние две недели я активно работаю с Python Client. Ничем, помимо сгенерированных классов/методов из OpenAPI, он похвастаться не может. Сильно не хватает более высокоуровневых концептов из client-go, а потому велик соблазн забить на Watch совсем и пользоваться только List'ом, несмотря на performance impact. Таких, как Informer, например. Работать напрямую с List/Watch сильно неудобно.
Total votes 3: ↑3 and ↓0+3

Похожее впечатление было от pyqt. Как бы молодцы, биндинги с классами нагенерили, а за решением проблем всё равно лезешь в C++-ную доку и потом как-то транслируешь примеры кода из C++ в python. В итоге два языка используешь, а не 1. Плюс автодополнение не всё автодополняет, потому что часть свойств в бинаре — удобной разработки! ;)

Total votes 1: ↑1 and ↓0+1

Инфраструктура — главный аргумент. На Rust не может быть богаче инфраструктура именно для Docker и Kubernetes.


Например, по опыту с Ruby: отсуствие нормальных клиентов для Kubernetes. У нас был самописный, чтобы достучатся до некоторых фич API типа слежения за ресурсами. Самописный клиент привел к тому, что наш dapp не мог коннектится к Google Kubernetes Engine, из-за использования там кастомной схемы аутентфикации. А времени реализовать эту схему в нашем клиенте не было. Вот такого рода проблемы.


Когда перешли на Golang — мы просто включили стандартный клиент kubernetes и все, коннект к GKE из коробки. Если появится что-то новое — сразу будет из коробки.

Total votes 3: ↑3 and ↓0+3
Вы так уверенно рассуждаете про kotlin-native. Не подскажите, где бы можно посмотреть результаты тестирования KN? А то у меня пока ровно обратная информация.
Total votes 1: ↑1 and ↓0+1

Если говорить про сравнение с Rust то KN проигрывает, так же как и Го. А вот если сравнивать Го с jvm то тут быстродействие на одном уровне. KN по определению работает быстрее без jvm, темным пятном остается его оптимальная работа с памятью, тут нужно детальное сравнение, которым пока никто не занимался.

Total votes 1: ↑1 and ↓0+1
KN по определению работает быстрее без jvm

вы это проверяли? или какую-нибудь ссылку дайте.
Total votes 1: ↑1 and ↓0+1

А вы обратное проверяли? Или какую-нибудь ссылку дайте. Или так и будете на всякие слухи опираться?

Total votes 2: ↑1 and ↓10
Я проверял. KN отставал чуть ли не в 20 раз. Было очевидно что о скорости там ещё даже не задумывались, так как ещё рано об этом думать.

добавлено:
сейчас поискал что-то посвежее: github.com/msink/kotlin-pi
получше, но далеко не так, как вы рассказываете.
Total votes 1: ↑1 and ↓0+1

Следуя вашей же ссылке:


- C 6.8 sec
- Kotlin/Native interop with C  6.8 sec

Как бы не в х20 раз медленнее
Замеры были сделаны до выхода стабильной версии в апреле прошлого года.


Может и в какой нибудь 0.6 версии и были отставания, я не знаю, но вот к выходу стабильной версии все было подправлено. Компилятор KN опирается на LLVM и это уже о многом говорит.

Total votes 1: ↑1 and ↓0+1

Рикну предположить, что команде потребовались считаные дни, максимум недели, чтобы уже начать писать рабочий код на go. На Rust эта цифра измерялась бы на порядок большим сроком. Тут как-то писали об опыте на rust, что через год работы с языком начало получаться писать простые программы сразу, чтобы они компилировались без ошибок...

Total votes 2: ↑2 and ↓0+2

Злые языки, не верьте :). В языке где нет обобщений и где всего одна конструкция для циклов можно писать быстро, дешево и сердито как на php4. Вот только в Го 2 собрались добавить обобщения, так что халяве пришел конец. Ну а если серьезно я как-то наблюдал мучения команды бывших рубистов при использовании указателей при вызове нативных функций на Го.

Total votes 2: ↑0 and ↓2-2

Представляюих вероятные мучения в rust...

This comment wasn’t rated yet0

По этому Kotlin Native в данном случае выглядит куда более привлекательнее. У меня есть другой пример, мой один товарищ по цеху Scala за месяц игры с Rust в перерывах на обед освоил язык и сейчас пишет особо нагруженные сервисы на Rust. Так что, что скалистому хорошо, то рубероиду смерть :) .

Total votes 1: ↑1 and ↓0+1

Да, товарищ уже из сложного языка переходил. Может сработать.

This comment wasn’t rated yet0
Ребята, это реально охуенно ;) отсутсвие golang это была единственная реальная причина по которой я в сторону dapp даже не смотрел ;) не хотелось тянуть ruby в экосистему
Total votes 10: ↑5 and ↓50
Если хотелось просто переписать работающий продукт на другой ЯП ради переписывания — то всё ок. Из трёх пунктов мотивации на переписывание, только первый выглядит адекватным для перехода именно на go. Если важна была скорость работы продукта с минимум затрат на переписывание, то можно было взглянуть на crystal (или elixir) которые имеют ruby синтаксис и семантику. А менять ООП язык на «процедурный» фишка которого concurrency, и не имея в требованиях эту concurrency — звучит странно.
Total votes 2: ↑2 and ↓0+2
только первый выглядит адекватным для перехода именно на go.

Выше автор уже так и написал:
Инфраструктура — главный аргумент.
Total votes 1: ↑1 and ↓0+1

Ещё одна фишка Go и аргумент за начало всей этой движухи с переписыванием — кросскомпиляция. Компилятор Go умеет кросскомпилировать статические бинарники без дополнительных телодвижений. Одним заданием в travis ci можно собрать бинарники под несколько платформ (linux+macos+windows).


У Crystal с этим туговато, похоже это не его основное предназначение:


  1. https://crystal-lang.org/reference/syntax_and_semantics/cross-compilation.html
  2. NOTE: Building statically-linked executables is currently only supported on Alpine Linux.


Статические бинарники только под alpine linux. Для сборки динамического бинарника нужно произвести линковку на той платформе, под которую кросс-компилируешь. Не звучит невыполнимо, но заметно сложнее, чем сборка для Go.

Total votes 2: ↑1 and ↓10

Эта фишка свойственна не только Го

This comment wasn’t rated yet0
Как минимум (и этого достаточно) — потому что «во-первых» (экосистема Kubernetes).
Total votes 1: ↑1 and ↓0+1
А зачем рантайм Erlang тянуть (BEAM)?
This comment wasn’t rated yet0
Почему назвали werf? Какой-то прикол на тему оборотней? Или просто неудачно транлитерировали слово «верфь» на английский? Логика есть в обоих версиях )
This comment wasn’t rated yet0
Это был долгий процесс… Скоро представим проект отдельной публикацией — там и расскажем! ;-)
Total votes 1: ↑1 and ↓0+1
Как будто тут много голландцев ;) хотя отсылка на первоисточник — +1 в карму )
This comment wasn’t rated yet0

Так "верфь" и есть транслитерация слова werf, а не наоборот ;)

This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr