News for hackers. Stuff that matters.
Re:Proposals for Go 1.15 by pjmlp on Wednesday January 29, 2020 @08:52AM (#22180406)
Actually I find it a disadvantage, I don't want to deal with source code from other teams/companies, rather binary artifacts totally separated from their toolchains.
Re:Proposals for Go 1.15 by kortex on Wednesday January 29, 2020 @10:06AM (#22181272)
I find it a huge advantage, in fact the lack of blobs may be my favorite go feature. I'm sure stodgy old companies that want to preserve "IP" through security through obscurity, dislike this model.

But as a dev? I can drill down to the core (C-b in Goland, jump to definition) of ANY import. Even the entire go toolchain is in go.

ABI/version management of artifacts is a nightmare, every single time.

Re:Proposals for Go 1.15 by pjmlp on Wednesday January 29, 2020 @10:12AM (#22181333)
That is what debugging symbols are for.

Using binary dependencies doesn't preclude having access to source code if desired.

Re:Proposals for Go 1.15 by jayd16 on Wednesday January 29, 2020 @12:15PM (#22183045)
Same with Java unless they stripped symbols. Libs wouldn't be stripped though.
Re:Proposals for Go 1.15 by jwalgenbach on Wednesday January 29, 2020 @10:09AM (#22181310)
One of the reasons I use go is the production of static, self contained binaries. Wouldn't binary artifacts make that much more difficult?
Re:Proposals for Go 1.15 by pjmlp on Wednesday January 29, 2020 @10:16AM (#22181383)
Why should it? Static compiling has been a thing since compilers exist.

Dynamic linking only became mainstream in the mid-90s.

Re:Proposals for Go 1.15 by apta on Wednesday January 29, 2020 @04:58PM (#22186309)
You can build self-contained Java JAR files for a while now.