AK
хм... а как тогда go могёт собирать so?
Size: a a a
2021 April 06
AK
Собственно, беда долгой компиляции больше даже не в производительности компилятора, вряд ли ведь кто-то ждёт, что Crystal сравнится в этом плане с Go. Проблема как раз в том, что нельзя использовать сторонние crystal-библиотеки в скомпиленном виде. Это влияет и на размер бинарника, и на время компиляции
G
можно, но это пока чисто PoC
DV
А, ну это понятно
AK
Понятия не имею, но подозреваю, что код на входе и должен быть не GC-зависимым, т.е. в можно добавить явные malloc/free
DV
Тоже сразу о go подумал
AK
Концепт и предполагает отказ от GC вроде?
AK
Ну вот я лично не видел россыпи .so-шек, скомпилированных в Go. Что-то с этим явно не так :)
G
нет, просто подменяют main и инициализируют гц там (надо перед использованием эту функцию вызвать)
DV
Просто не очень популярно, хотя даже статья на хабре есть
DV
AK
Наверное возможен несложный какой-то подход, когда Crystal-приклад цепляет бинарник, скомпиленный тем же crystal-компилятором. В конце-концов julia так умеет ведь. Но именно традиционный .so... Там же ещё файберы, шедуллинг, тогда уж надо таким .so заменять что-нибудь типа libuv/libev
G
да и куча ограничений будет
AK
Обычный-то so просто предоставляет некий API, а не подменяет собой ключевые функции основного приложения
G
вроде частичной невозможности использовать дженерики
G
в го проще c этим было на момент написания статьи
G
> Обратите внимание, что размер файла .so около 2 Мб. Довольно много для такой маленькой библиотеки. Дело в том, что в этот файл запихивается вся runtime-механика Go и зависимые пакеты.
AK
Ну вот да. Не проще ли как говорится из Go использовать функции, написанные на Си, нежели делать всё в точности до наоборот :)
VF
Хочу поделиться. Сейчас запилил колоссальный рефакторинг. Теперь сижу и одну за другой ошибки компиляции правлю, благо они удобно тыкают туда, где я не прав. Нормас 👍