by personZ on 9/4/14, 11:30 AM
The dogma about preventing the sharing of pointers with C is a bit concerning. I've made use of that mechanism, to fantastic effect, albeit understanding the risks and consequences. The notion that it must be prevented because bad things can happen if you aren't careful isn't a starter, as there are essentially zero people doing that who've had problems. Instead a lot of people have enjoyed fantastic productivity because of the similarities of the implementations, and the synergy that allows.
But the team wants move to a compacting GC. Fine, add pin/unpin idioms. This ground has been well covered by other languages. Don't completely destroy a very productive mechanism because in some oddball cases it might not work.
by pauldix on 9/4/14, 11:21 AM
This would be awesome to have. +1!
With InfluxDB we want to give users the ability to define custom functions and it looks like this could be used to let people do that in Go or any language really. Whereas right now we're limited to doing something like using LuaJIT.
by axaxs on 9/4/14, 6:15 AM
I would love to see the gc compiler support building dynamically linked executables against a libgo runtime Ala gccgo. Unless I'm misreading, this case doesn't seem covered. I love the standalone binary deployment ease as of now, but on a machine with tens of go applications, the binary size redundancy gets old. Or did I miss something?
by Rapzid on 9/4/14, 5:54 AM
I think the more relevant news in there for most is the support for dynamic/runtime loading. The title here makes it sound like it's just for dynamic linking but I read the article to article to be sure and was pleasantly surprised :)
by lobster_johnson on 9/4/14, 3:06 PM
> Building Go packages as a shared library
Yes, please! We have a few potential Go projects which are blocked by the inability to separate Go code into plugins.
I have toyed with the idea of forking child processes and implementing plugins via pipe I/O, but that's a very unfriendly API interface, and I don't feel very inspired. (Go isn't that great at POSIX stuff like forking, either.)
by bkeroack on 9/4/14, 5:10 PM
I realize it's just an early draft, but it's interesting (alarming?) that the proposed plugin API has no facilities for plugin discovery or separate namespaces. Nor any apparent ability for the plugin consumer to introspect into plugins.
I suppose the namespace issue can be mitigated by a strict naming convention (something like "[application_name].[plugin_name]"), but the others are kind of a bummer.
I don't have a whole lot of positive things to say about the Python setuptools API (perhaps better called "lack-of-API internal interface"), but at least it's possible to dynamically load python plugins from arbitrary locations in the filesystem and programmatically discover their contents.
by easytiger on 9/4/14, 11:39 AM
Is there a mirror? For those of us in the corporate wasteland this is not accesible
by JuiceSSH on 9/4/14, 9:26 AM
Interesting that it will allow compilation of PIE executables.
This is a mandatory requirement for any binaries run on newer versions of Android (L+).
by frik on 9/4/14, 6:26 AM
The doc doesn't mention a timeline or Go version when we may see the new planned features.