Go 2 быть

Я вот в Go ноль, но как изобразить аналог:

struct Point<T> {
    x: T,
    y: T,
}

Лучше бы хоть одну GUI библиотеку сделали

Пустой интерфейс не имеет методов, соответственно его реализуют все типы. Т.е. то, что он показал приводит к полному отсутствию типобезопасности (как в си, да).

Лучше использовать непустые интерфейсы, но тут есть подвох: нельзя объявить метод на builtins. То есть нельзя корректно реализовать обобщенный, например, mapreduce (в нем нельзя будет использовать int, uint32 и т.д. и т.п.). Возможно, будет исправлено в go 1.9 с алиасами для типов.

Сегодня только с кодогенерацией. А если вспомнить про отсутствие параметрического полиморфизма, то будет что-то вроде

PointInt, PointUint ...

Ну или реализовать в компиляторе как Print & range.

То есть извращения уровня Vec<Point<i32>> не вариант вообще?

Ага. Го для конкретного программирования. Для обобщенного он не подходит совсем. Может, станет получше с введением type aliases, но не намного. Так что хороших библиотек для работы с коллекциями ждать не приходится.

А то, что есть работает через пустые интерфейсы и type assertions. Иногда еще reflection, но он тормозной.

PS. Правда, я видел, ЕМНИП как раз от Russ Cox обобщенные коллекции через unsafe и работу с сишными (почти) указателями.

TIL в Go есть unsafe

cx_Freeze?

Не, это решает другую задачу. Оно как и Nuitka просто для упаковки приложения в standalone приложение для удобства распространения, главным образом это для пользователей Windows нужно. А я имею в виду чтобы на выходе был чисто нативный код без питона внутри вообще и работало так же быстро, будто было написано изначально на C или плюсах. Фантазии, да.

нельзя объявить метод на builtins
Возможно, будет исправлено в go 1.9 с алиасами для типов.

Не, не будет скорее всего.
В каких-то древних версиях го можно было написать type MyInt int и объявлять методы на MyInt и передавать MyInt туда где требовался int. Теперь так нельзя, MyInt нужно явно приводить к int. И алиасы скорее всего оставят это так как оно есть, потому что алиас это будет просто подстановка(т.е. если ты захочешь объявить методы на алиас, который алиасит int, тебе скажут что нельзя объявлять методы на int). Во всяком случае я так понял.

Я понял по другому:

https://github.com/golang/proposal/blob/master/design/18130-type-alias.md

Since T1 is just another way to write T2, it does not have its own set of method declarations. Instead, T1’s method set is the same as T2’s. At least for the initial trial, there is no restriction against method declarations using T1 as a receiver type, provided using T2 in the same declaration would be valid.

И? По-моему цитата как раз говорит о том, что у обоих типов будет одно множество методов.
Следовательно у алиаса int будут методы int, т.е. никакие, и добавить нельзя иначе будет расширение методов int, а это не позволяется.

Возможно ты и прав.