[0xABADC0DA]

> Sure you can. Spawn a child process ...

This is exactly what I was talking about. You can't even admit facts like that Java has dynamic loading and a security model and that Google Go does not. You're simply delusional in this respect.

[agentS]

It seems I wasn't clear enough; I apologize for the confusion. I fully admit that Java has dynamic loading and a security model and the Go does not.

I was responding to "you can't have an app that loads plugins much less one where the app can do IO but the plugin can't."; that is, I was merely providing a way to implement what you wanted (plugins that cannot do IO, in a host that can).

Like I said in my original post, "If you mean things that you can syntactically write down, like a Giraffe is-a Animal, or an Apple is-a Fruit, then yes, that is impossible to write down in Go." Similarly, it is impossible to dynamically load code, or enforce permissions at the runtime level (although implementations of this enforcement has historically been... buggy, to be charitable). I was attempting to show that the problem of having sandboxed plugins is solvable in Go.

[eternalban]

The child process approach is viable, but in fairness you should note that shared address space provides efficiencies that the RPC approach does not. This approach is IMO quite interesting in context multi-core and certain problem domains, but as a general mechanism it is a 'hack'.

And then:

- A full featured runtime reflection mechanism that does not drop "static info" on the floor: http://stackoverflow.com/questions/10210188/instance-new-typ... (Yes, there is a workaround but it is in 'hack' category of system engineering.)

- Class.forName(cname).

- @MetaInfo() ... Arguably not easy on the eye but necessary and enabling.

- Bytecode injest (beyond dynamic linking) -- the JVM is your oyster.

- and related Instrumentation and AgentS (pi) : http://docs.oracle.com/javase/6/docs/api/java/lang/instrumen...) -- this is a very powerful feature.

It is borderline fanaticism to insist on comparing Go to Java, and unfair to Go. Effective advocacy of Go should focus on its strengths (syntax) and not attempt to gloss over its inherent limitations. It is a capable and viable language within well defined limits. Java and JVM are in another league. Accept it and move on.

If a new 'headius' feels up to it, Go on JVM would be a very interesting new language for the JVM ...

[agentS]

> The child process approach is viable, but in fairness you should note that shared address space provides efficiencies that the RPC approach does not. This approach is IMO quite interesting in context multi-core and certain problem domains, but as a general mechanism it is a 'hack'.

As to the lack of a shared address space, I thought I had communicated that when I said "It might require you to restructure to reduce chattiness", but yes, there are performance advantages to having a shared address space.

You should note that there are security disadvantages to having a shared address space with a sandboxed plugin written in a relatively low-level language (bytecode). I won't post several links to exploits of the Java sandbox in the last year alone, but I am sure you can google for them.

This mechanism is most certainly not a hack. This is the approach that Chromium and the other multi-process browsers (all the modern ones?) use for sandboxing. It seems far more effective to me to push responsibility for security to the OS, rather than the language runtime.

> A full featured runtime reflection mechanism that does not drop "static info" on the floor

Package reflect is fully featured. It just requires you to have a value, or type to actually reflect upon. The tradeoff being that Go can do dead-code elimination and Java cannot. Same thing for Class.forName.

> @MetaInfo() ... Arguably not easy on the eye but necessary and enabling.

I think you are referring to annotations. Yes, Go doesn't have these on methods, functions, or types. But it has these for struct fields (tags); this gives you 90% of the functionality, without muddying up the syntax.

> Bytecode injest (beyond dynamic linking) -- the JVM is your oyster.

Sure. See my note about all of these points below.

> and related Instrumentation

Go has a CPU profiler, a memory allocation profiler. In tip, it has a data race detector. It can expose this data over an HTTP interface so you can profile a running server http://golang.org/pkg/net/http/pprof/.

> It is borderline fanaticism to insist on comparing Go to Java, and unfair to Go. Effective advocacy of Go should focus on its strengths (syntax) and not attempt to gloss over its inherent limitations. It is a capable and viable language within well defined limits. Java and JVM are in another league. Accept it and move on.

You continually give me solutions that are impossible to implement in Go, but not the corresponding problems. Like I said, there are things that are syntactically impossible to write down in Go. If you want me to give you a list of things that are impossible to do in Java, I can do that (structural typing, value types, methods on values, multiple top level definitions in a single file, first class functions, efficient array slicing come to mind). I have not done that because it is a nonsensical thing to do. That would be like me saying Javascript is superior to Java because Java does not have prototypical inheritance.

The only useful example I've heard is sandboxed plugins. That is a problem, not a solution. All the things you've listed are solutions. If you actually want to have a conversation about how to solve problems in Go, then list problems, not a laundry list of features that Java has that Go does not.

> If a new 'headius' feels up to it, Go on JVM would be a very interesting new language for the JVM ...

Why? If I want more performance than gc gives me, then I use gccgo. What would Go on the JVM give me?

Also, on an unrelated note, I find it a little sad and pathetic how both you and 0xABADC0DA have to resort to insults to get your point across.

[eternalban]

>> and related Instrumentation > Go has a CPU profiler, a memory allocation profiler. In tip, it has a data race detector. It can expose this data over an HTTP interface so you can profile a running server http://golang.org/pkg/net/http/pprof/.

It is canonically called "instrumentation" but that is not all that it is capable of doing. Have you actually ever used this feature of Java?

> Also, on an unrelated note, I find it a little sad and pathetic how both you and 0xABADC0DA have to resort to insults to get your point across.

?? When and where did I insult you? Pathetic, on the other hand, is an insult. I strongly take exception to that.