Rust, Go, Swift, или Kotlin native — что удобнее для того, кто работает с Python?

Go

Там наследование, кстати, добавили?

Python.

Если тебе так горить скомпилировать Python, то у него есть компилируемые под- и даже над- множества. Выгоды по производительности от этого будет примерно столько же, сколько и от переписывания на другой ЯП (на твоих задачах — кот наплакал), так что другие ЯП можно и не приплетать.

Наследование это просто (спорный) синтаксический сахар. Нет никаких проблем писать без него, разницы 15 на 200 не будет. Куда принципиальнее в этой задаче наличие файберов и их шедулера в Go из коробки, менеджера зависимостей (godep), статический бинарь и GC.

Нет никаких проблем писать без него

Лично у меня — есть. Есть задачи, для которых наследование является наиболее естественным способом проектирования. Приплетать композицию туда только потому, что у роба пайка случилась жопная боль, и он выпилил наследование как класс — это натягивание совы на глобус.

Как мне иначе сделать две реализации интерфейса (назовем их «классами», один уд), отличающиеся от себя начинкой только в одном из методов? Дробить каждую на две части? Копипастить?

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

Вот пруфлинк с затачиванием ложек для нарезки колбасы: https://hackthology.com/object-oriented-inheritance-in-go.html
Спасибушки за такое светлое будущее.

оптимизирует компилятор

Вот с этим в Go не очень. С другой стороны, если бы не GC, то задача действительно как будто под него написана.

Справедливости ради, производительность там не сильно ниже, чем в C, а на фоне интерпретируемых языков Go выглядит и вовсе как болид.

JS

Ну на фоне интерпретируемых понятно. Но вот скорость компиляции в Go во многом достигается за счет отказа от многих возможностей соптимизировать код.

Cython

/thread

...а потом положить это в сборку на основе Buildroot на Raspberry Pi какое-нить мелкое.

Думаю, что малина это прожуёт и не подавится. А для тотальной эмбедщины есть кошерный micropython.

:) а потом получаются проекты, где 80% кода, это абстрации, и 3 функции бизнес логики.

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

Еще меня конкретно задрало читать опусы о том, как благословенно ООП без наследования, как от статической типизации волосы становятся мягкими и шелковистыми, и как то, что вместо 15 строчек на Python мне надо написать простыню строк на 200 на любимом языке автора, на самом деле лучшая в мире вещь.

Кому-то правда глаза колет, а кого-то ещё и... гхм... задирает.

Виртуальные ф-ции без наследования у вас как?

задрало читать опусы о том, как благословенно ООП без наследования

А чего у тебя тогда половина ЯП не умеющие в наследование?

как от статической типизации волосы становятся мягкими и шелковистыми

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

15 строчек на Python мне надо написать простыню строк на 200 на любимом языке автора

Тогда добавь в свой список джаву, чтобы завершить логическую цепочку. Я тогда может снизойду и объясню почему ты должен выбрать её, ну или другие снизойдут и расскажут про шарп (говорят он теперь тоже норм).

Как мне иначе сделать две реализации интерфейса (назовем их «классами», один уд), отличающиеся от себя начинкой только в одном из методов? Дробить каждую на две части? Копипастить?

Я так делаю :)

type parent struct{ name func() string }

func (p *parent) init() { p.name = p.getName }

func (p parent) print() { println(p.name()) }

func (parent) getName() string { return "parent" }

type subclass struct{ parent }

func (p *subclass) init() { p.parent.name = p.getName }

func (subclass) getName() string { return "subclass" }

func main() {
	one, two := parent{}, subclass{}
	one.init()
	two.init()
	one.print()
	two.print()
}

Хорошо. Теперь делаем полиморфизм.

Есть структура Parent. В ней есть метод CalculateExpensively(), который ссылается, допустим, на другой метод, назовем его Log(). Он что-то пишет на экран.

Как мне сделать структуру Child, в которой метод Log() будет передавать сообщения по сети так, чтобы мне также не пришлось переопределять метод CalculateExpensively()? В статье по моей ссылке написано, что с Go в этом швах.

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

Надо будет пробовать Kotlin/Native.

Можно попытаться наоборот, все в parent инкапсулировать. Хз насколько это гонично и наверное будет костыльно, но надо попробовать. А так да:

if p.userMethod != nil {
	return p.userMethod()
}
return defaultMethod()

PS: Горутины после asyncawait\thread\process просто ня! Пишу четвертый день на го, уже привык к его «фичам».

менеджера зависимостей (godep)

эта штука давно умерла. Есть dep, но его лучше не использовать. Предпочтительнее всего go modules

Один публичный метод сущности не должен звать другой. Это верный признак низкокачественного дизайна кода.

Разрешаю.

пиши на сишечке

type Logger interface {
    Log(data ...LoggingField) error
}

// CalculateExpensively у Child-а наследуется от Parent-а, поэтому в качестве метода у Parent-а он примерно вообще не нужен.
func CalculateExpensively(item *Parent, logger Logger) error {
    …
}

Вот такой подход гораздо читабельнее твоего позорного шлака с наследованием.

Конечно же Rust.