 |
lua-l archive |
|
|
||
|
On Fri, Apr 21, 2017 at 11:58 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 12:24 PM, Nagaev Boris <bnagaev@gmail.com> 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
>> language.
>
> 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
> dynamically.
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.
--
Best regards,
Boris Nagaev