7 ms·

I think at this point Go is more of a replacement for Java than C++.

kyllo 12y ago
Perhaps, but the problem is, with no generics or exceptions, it might just be too low-level and not expressive enough to really be a suitable Java replacement.
- agmcleod 12y ago
  Yeah i just see Go as an alternative for web technologies, where Rust is much more system level focused. I could be wrong, but that seems to be the direction I see with Rust.
  - naasking 12y ago
    > Yeah i just see Go as an alternative for web technologies I don't see any web technology Go could replace. Not even dynamically typed langauges.
    - vec 12y ago
      I'm starting to use Go as an arguably better Node. Very fast, easy (pseudo)concurrency, relatively nice HTTP capabilities in the stdlib. It wouldn't be my first choice for building a full library, but it works well as an internal component in a service oriented architecture or a background worker for a queuing system.
      - sagichmal 12y ago
        Go is very uncontroversially a better Node. It also predates Node.
        spion 12y ago
        Depends on what you mean by "better". Better language? Not really, if you want types TypeScript is a much better option. With node+typescript+react you can get end-to-end typechecked code with no FFI involved - thats really, really cool. Better concurrency? Oh yeah, definitely. Better core libraries? Yes, by far. Better package ecosystem and management? Definitely not.
        sagichmal 12y ago
        > Better language? Not really, There is no conceivable universe in which the expression "JavaScript is a better language than Go" evaluates to true.
        kyllo 12y ago
        ...except for in JavaScript itself: ~$ node > "JavaScript is a better language than Go" ? true : false true > "JavaScript" > "Go" true
        spion 12y ago
        Unless/until Go gets generics, I stand by my statement. A horrible type system that severely limits expressiveness is worse than no type system. Even TypeScript's type system is miles ahead compared to the one in Go.
        general_failure 12y ago
        I doubt it. The node ecosystem is second to none.
        deleted 12y ago
        [deleted]
      - aikah 12y ago
        All the things node is designed to do and it does it at least as fast as Go. We can argue that the Go concurrency model is better.I think nodejs's is good enough,easier to understand and to deploy. If your goal is to write lightweight webservers that do a specific task,nothing beats node in my opinion.
        e12e 12y ago
        > easier to ... deploy Ehm, really? Tree of javascript, possibly with some compiled libraries easier to deploy than a static binary? I'm not saying node is hard to deploy, but I think maybe I'm misunderstanding what you mean here?
    - cft 12y ago
      Prime candidate is any highly scalable TCP socket server. Currently, there's no better language for it
      - pjmlp 12y ago
        Erlang? That switch that is routing your phone calls?
        kasey_junk 12y ago
        Almost certainly not TCP socket based nor built on commodity hardware.
        coldtea 12y ago
        It hasn't rooted anybody's phone calls for a long time. Even Ericsson doesn't use Erlang based phone routing anymore...
      - rdtsc 12y ago
        Erlang is a better for it. WhatsApp runs their infrastructure on it. Can easily do millions of concurrent TCP connections on a single machine.
    - tptacek 12y ago
      We could not have handled the load at Microcorruption, emulating CPU state for thousands of concurrent users, using Ruby --- which remains the front-end language for the site. We could easily have done so in Java, but we'd be in Java's concurrency model, which is much more difficult to reason about.
      - kyllo 12y ago
        So, you did it in Go instead of Java, right? I think this is exactly what people mean when they say Go is more of a replacement for Java than it is a replacement for C++: In the sense that when Ruby and Python become too slow, people normally reach for Java, but now they have Go as an alternative option, with a better concurrency model than Java's.
        tptacek 12y ago
        We never even considered writing it in Java. We wanted something with the performance characteristics of C, which is what we would have used had we not had Golang.
        seunosewa 12y ago
        Golang does not have the "performance xteristics of C"!
        tptacek 12y ago
        I must just be crazy.
      - threeseed 12y ago
        There are alternatives to Java's concurrency model whilst still staying on the JVM: http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/
pjmlp 12y ago
Given how the JVM ecosystem looks like and what is planned for Java 9+ in terms of mechanical sympathy, I have my doubts.
tptacek 12y ago
People love to say this, but the observation falls apart quickly under scrutiny. People working in Java are doing so to retain access to the JVM and to the zillion libraries built on it. The JVM with its ecosystem is a colossal asset for Java; one of the greatest in all of commercial software development. (I say this as someone who does not enjoy Java). Meanwhile: Golang neatly fills in a sweet spot just "below" Python and Ruby, where finer-grained control of memory and more predictable performance characteristics are required, but bare-metal performance isn't. That sweet spot actually describes a huge fraction of all the use cases for C/C++ in Internet software. So this is a meme I'd like to see die. It somehow manages to simultaneously get Golang, Java, and C++ wrong all at the same time. The only way to make it worse would be to work in some kind of Lisp comparison, based on Golang's parsimony with parenthesis.
- threeseed 12y ago
  Couldn't agree more. Anyone who thinks Go will ever be a replacement for Java is frankly clueless about enterprise software development. Go has almost non-existant integration with enterprise systems e.g. SAP, Hadoop. It lacks operational management capabilities e.g. JMX. And seriously the range of libraries on the JVM covers pretty much everything e.g. banking/finance use cases. And concerningly there is not a single reasonably sized Go project to get an understanding of how it works with 20, 50, 100 or 500+ developers working on the same codebase.
  - kasey_junk 12y ago
    I think when people claim that Go is a replacement for Java, what they really mean is "Go has similar performance characteristics as the JVM and also doesn't require manual memory management". Anyone who has ever worked in enterprise software can tell you, Go is (currently) exceptionally poorly suited for that style of development. I don't think that is an accident though. I think there is at least the implication that enterprise software development models and architectures are flawed at the core. Go seems to be designed from the start to prevent you from developing that way. I may be reading more into the Go culture than I should, and I certainly don't think that there is proof that enterprise software can't be successful, but Go clearly steers you into building small, self contained servers that do one thing well and can go without change for a long time.

kyllo 12y ago

Perhaps, but the problem is, with no generics or exceptions, it might just be too low-level and not expressive enough to really be a suitable Java replacement.

agmcleod 12y ago
Yeah i just see Go as an alternative for web technologies, where Rust is much more system level focused. I could be wrong, but that seems to be the direction I see with Rust.
- naasking 12y ago
  > Yeah i just see Go as an alternative for web technologies I don't see any web technology Go could replace. Not even dynamically typed langauges.
  - vec 12y ago
    I'm starting to use Go as an arguably better Node. Very fast, easy (pseudo)concurrency, relatively nice HTTP capabilities in the stdlib. It wouldn't be my first choice for building a full library, but it works well as an internal component in a service oriented architecture or a background worker for a queuing system.
    - sagichmal 12y ago
      Go is very uncontroversially a better Node. It also predates Node.
      - spion 12y ago
        Depends on what you mean by "better". Better language? Not really, if you want types TypeScript is a much better option. With node+typescript+react you can get end-to-end typechecked code with no FFI involved - thats really, really cool. Better concurrency? Oh yeah, definitely. Better core libraries? Yes, by far. Better package ecosystem and management? Definitely not.
        sagichmal 12y ago
        > Better language? Not really, There is no conceivable universe in which the expression "JavaScript is a better language than Go" evaluates to true.
        kyllo 12y ago
        ...except for in JavaScript itself: ~$ node > "JavaScript is a better language than Go" ? true : false true > "JavaScript" > "Go" true
        spion 12y ago
        Unless/until Go gets generics, I stand by my statement. A horrible type system that severely limits expressiveness is worse than no type system. Even TypeScript's type system is miles ahead compared to the one in Go.
      - general_failure 12y ago
        I doubt it. The node ecosystem is second to none.
      - deleted 12y ago
        [deleted]
    - aikah 12y ago
      All the things node is designed to do and it does it at least as fast as Go. We can argue that the Go concurrency model is better.I think nodejs's is good enough,easier to understand and to deploy. If your goal is to write lightweight webservers that do a specific task,nothing beats node in my opinion.
      - e12e 12y ago
        > easier to ... deploy Ehm, really? Tree of javascript, possibly with some compiled libraries easier to deploy than a static binary? I'm not saying node is hard to deploy, but I think maybe I'm misunderstanding what you mean here?
  - cft 12y ago
    Prime candidate is any highly scalable TCP socket server. Currently, there's no better language for it
    - pjmlp 12y ago
      Erlang? That switch that is routing your phone calls?
      - kasey_junk 12y ago
        Almost certainly not TCP socket based nor built on commodity hardware.
      - coldtea 12y ago
        It hasn't rooted anybody's phone calls for a long time. Even Ericsson doesn't use Erlang based phone routing anymore...
    - rdtsc 12y ago
      Erlang is a better for it. WhatsApp runs their infrastructure on it. Can easily do millions of concurrent TCP connections on a single machine.
  - tptacek 12y ago
    We could not have handled the load at Microcorruption, emulating CPU state for thousands of concurrent users, using Ruby --- which remains the front-end language for the site. We could easily have done so in Java, but we'd be in Java's concurrency model, which is much more difficult to reason about.
    - kyllo 12y ago
      So, you did it in Go instead of Java, right? I think this is exactly what people mean when they say Go is more of a replacement for Java than it is a replacement for C++: In the sense that when Ruby and Python become too slow, people normally reach for Java, but now they have Go as an alternative option, with a better concurrency model than Java's.
      - tptacek 12y ago
        We never even considered writing it in Java. We wanted something with the performance characteristics of C, which is what we would have used had we not had Golang.
        seunosewa 12y ago
        Golang does not have the "performance xteristics of C"!
        tptacek 12y ago
        I must just be crazy.
    - threeseed 12y ago
      There are alternatives to Java's concurrency model whilst still staying on the JVM: http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/

pjmlp 12y ago

Given how the JVM ecosystem looks like and what is planned for Java 9+ in terms of mechanical sympathy, I have my doubts.

tptacek 12y ago

People love to say this, but the observation falls apart quickly under scrutiny. People working in Java are doing so to retain access to the JVM and to the zillion libraries built on it. The JVM with its ecosystem is a colossal asset for Java; one of the greatest in all of commercial software development. (I say this as someone who does not enjoy Java). Meanwhile: Golang neatly fills in a sweet spot just "below" Python and Ruby, where finer-grained control of memory and more predictable performance characteristics are required, but bare-metal performance isn't. That sweet spot actually describes a huge fraction of all the use cases for C/C++ in Internet software. So this is a meme I'd like to see die. It somehow manages to simultaneously get Golang, Java, and C++ wrong all at the same time. The only way to make it worse would be to work in some kind of Lisp comparison, based on Golang's parsimony with parenthesis.

threeseed 12y ago
Couldn't agree more. Anyone who thinks Go will ever be a replacement for Java is frankly clueless about enterprise software development. Go has almost non-existant integration with enterprise systems e.g. SAP, Hadoop. It lacks operational management capabilities e.g. JMX. And seriously the range of libraries on the JVM covers pretty much everything e.g. banking/finance use cases. And concerningly there is not a single reasonably sized Go project to get an understanding of how it works with 20, 50, 100 or 500+ developers working on the same codebase.
- kasey_junk 12y ago
  I think when people claim that Go is a replacement for Java, what they really mean is "Go has similar performance characteristics as the JVM and also doesn't require manual memory management". Anyone who has ever worked in enterprise software can tell you, Go is (currently) exceptionally poorly suited for that style of development. I don't think that is an accident though. I think there is at least the implication that enterprise software development models and architectures are flawed at the core. Go seems to be designed from the start to prevent you from developing that way. I may be reading more into the Go culture than I should, and I certainly don't think that there is proof that enterprise software can't be successful, but Go clearly steers you into building small, self contained servers that do one thing well and can go without change for a long time.