7 ms·

> > On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go. > Depending on what you mean by "do" ... Oh, I do

> > On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go. > Depending on what you mean by "do" ... Oh, I don't know, maybe dynamic code loading or secure sandboxing of code? For instance you can compile a custom Google Go without disk IO, but you can't have an app that loads plugins much less one where the app can do IO but the plugin can't. These may not be the wisest or most useful of features for "systems" programming, but you have to admit that there are real things Java can do that Google Go cannot. I think Google Go advocates put blinders on like agentS because if they actually objectively looked at the situation they would have the same thing to say as others do about Google Go: "meh".

agentS 14y ago
> Oh, I don't know, maybe dynamic code loading or secure sandboxing of code? For instance you can compile a custom Google Go without disk IO, but you can't have an app that loads plugins much less one where the app can do IO but the plugin can't. Sure you can. Spawn a child process with lower security privileges, and communicate over a pipe. It might require you to restructure to reduce chattiness, but on the other hand, you will be much less likely to expose yourself to security vulnerabilities than the Java "sandbox". If the child process is written in Go, you can even use the -u compiler flag to only allow safe packages (i.e. no assembly, C, only packages explicitly marked as safe and pure Go). You can go even further, and mark package os unsafe, disallowing file system access altogether. Or do what (I suspect) Appengine does, and provide your own neutered implementation of package os/time/net/etc, and mark those as safe. The Go playground is an example of this, btw. It merely streams stdout and stderr, but you could imagine doing other things with the sandboxed program. > I think Google Go advocates put blinders on like agentS because if they actually objectively looked at the situation they would have the same thing to say as others do about Google Go: "meh". I think you are falling prey to the same fallacy of false cause as your GP. "agentS likes Go, so he must not be objectively looking at the language". It is possible to objectively look at the language, and think it useful.
- 0xABADC0DA 14y ago
  > 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 14y ago
    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 14y ago
      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-type-golang 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/instrument/package-summary.html 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 14y ago

> Oh, I don't know, maybe dynamic code loading or secure sandboxing of code? For instance you can compile a custom Google Go without disk IO, but you can't have an app that loads plugins much less one where the app can do IO but the plugin can't. Sure you can. Spawn a child process with lower security privileges, and communicate over a pipe. It might require you to restructure to reduce chattiness, but on the other hand, you will be much less likely to expose yourself to security vulnerabilities than the Java "sandbox". If the child process is written in Go, you can even use the -u compiler flag to only allow safe packages (i.e. no assembly, C, only packages explicitly marked as safe and pure Go). You can go even further, and mark package os unsafe, disallowing file system access altogether. Or do what (I suspect) Appengine does, and provide your own neutered implementation of package os/time/net/etc, and mark those as safe. The Go playground is an example of this, btw. It merely streams stdout and stderr, but you could imagine doing other things with the sandboxed program. > I think Google Go advocates put blinders on like agentS because if they actually objectively looked at the situation they would have the same thing to say as others do about Google Go: "meh". I think you are falling prey to the same fallacy of false cause as your GP. "agentS likes Go, so he must not be objectively looking at the language". It is possible to objectively look at the language, and think it useful.

0xABADC0DA 14y ago
> 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 14y ago
  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 14y ago
    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-type-golang 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/instrument/package-summary.html 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 ...