On Fri, Apr 21, 2017 at 11:58 AM, steve donovan
> On Fri, Apr 21, 2017 at 12:24 PM, Nagaev Boris <firstname.lastname@example.org> wrote:
>> language itself is convenient enough to do that (e.g. it has GC and
>> rich reflection so I can for instance enumerate fields of a
>> structure). Finally the whole project can be written in a single
> I enjoy Go, but it's a curious fact that there are numerous projects
> to provide binding to Lua (i myself have done one (luar) which
> leverages Go reflection). So we have to ask, why Lua? It's not that Go
> programs are slow to compile (unlike the big C++ game with Lua
> situation) but it's because Lua scripts can modify running behaviour
Good to know about luar. Looks very interesting!
Why to modify running behaviour dynamically, if you can recompile it
from scratch in few seconds?
>> rockspecs, CMakeLists.txt etc. Other thing I really like is that the
>> package system is decentralized: import paths look like
>> "github.com/user/repo". There is no thing like a luarocks server for
>> publishing packages: you just push your code somewhere (e.g. Github or
>> your homepage) and other people can import it directly from there.
> Go build system is brilliant, yes, but it's a known problem that you
> are at the mercy of upstream every time you make a github reference in
> a project.
This is a well known feature and it is a reflection of the practice of
putting everything in one large repo you can find in some companies.
If a project is actively developed then somebody takes eye on changes
of its deps. If a project doesn't build it is likely to be abandoned.
To pin versions of deps, you can fork all of them to your github user
and reference forks. Or create a vendor dir and put Git modules there.