Live data from Hacker News

Azul3D – A 3D game engine written in Go

azul3d.org

1–10 of 46 posts

Re: Azul3D – A 3D game engine written in Go

#5

What's with the package versioning? http://azul3d.org/doc/versioning.html#development-versions v1 (latest version) import "azul3d.org/audio.v1" v0 (in development) import "azul3d.org/audio.v0" Is this normal for go packages?

It's not normal, but package versioning in go is broken, so people invent their own workarounds

Re: Azul3D – A 3D game engine written in Go

#6

What's with the package versioning? http://azul3d.org/doc/versioning.html#development-versions v1 (latest version) import "azul3d.org/audio.v1" v0 (in development) import "azul3d.org/audio.v0" Is this normal for go packages?

That's one way of doing it. Another is to just use their github path and use vendoring tools like godep.

I prefer vendoring since it doesn't rely on a 3rd party being online or existing in a year. Also it's simpler when you want to have repeatable builds, since the vendored code is usually in your repo. It's also convenient for CI/CD things, since your repo ships as a unique component.

Also using versioned path like that means that a version bump means editing all your files. Across a large project, it becomes harder to manage.

However, versioned path aren't incompatible with vendoring tools. So one doesn't prevent the other.

FWIW, I think versioned path is also not very popular in the pseudo-contest of vendoring code/versioning path.

Re: Azul3D – A 3D game engine written in Go

#7
post #3

Garbage collector FAQ isn't necessarily reassuring, since it seems to say "go through the same hoops other GC gaming platforms push you through". Obligatory Rust gaming comment goes here.

I never read it like that at all.

To me it says be mindful when allocating memory. This is no more effort than having to manually allocate and free memory, but also has the convenience and safety of a GC to fall back on.

Post reply on HN