5 ms·

Essentially all of the quoted usecases switched from a slow dynamically typed language to Go. Of course that's an improvement. But I still don't see why you wo

• MCRed 12y ago
  I'm much more productive (in terms of bug-free-functionality-per-hour) in Go than I am in Java (and even more so in Elixir than go). It seems the value of those 3rd party libraries are not as much for me as for you and others. I guess cause the essential stuff is covered for Elixir and most other languages.
  • tljr 12y ago
    I like coffee and long walks.
    • deleted 12y ago
      [deleted]
    • rdtsc 12y ago
      Great point. If you switched to those language you might have more time to go for coffee and take long walks, because your system have a higher chance to manage errors and crashes and you don't have to rush to the office right away or at night to fix issue.
• otikik 12y ago
  > Java is faster Do you have any evidence to back that up? I am not disagreeing, just curious.
  • pjmlp 12y ago
    For example, https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
    • Gurkenmaster 12y ago
      I love the fact that lua is at the top, directly after java.
    • voidlogic 12y ago
      Go still beats Java sometimes: https://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=update&l=cqp https://www.techempower.com/benchmarks/#section=data-r9&hw=i... I'm not saying Go wins more, but they are very close compared to other languages.
      • nazka 12y ago
        I want to point that in fact Go is extremely performant on EC2 for every tests and average on Peak. So with that and all its features, it seems that Go is an awesome solution for startups. And then Java when you start to be quite big.
• ironchef 12y ago
  The couple of things I've found (which are perhaps more niche) are the GC behavior of golang seems to be "nicer" / "easier" than that of java and I've found the concurrency of the channels to be easier to use and more predictable than the N different concurrency constructs within Java proper (that isn't to say using something more akin to Quasar isn't a nice alternative). Like with any languages, there's lots of tradeoffs between systems. I would also suggest the "Java .. is faster" isn't always true.
• muraiki 12y ago
  An experienced programmer friend of mine uses Go professionally. I was surprised to hear that he much prefers Java: he said that many concurrency libraries are available for Java and that Go's features are quite limited in comparison. He dislikes the fact that you have to break Go's poor type system to get many things (such as tests) to work. He has a pretty strong background in FP, so I think that perhaps Go's interfaces are the straw that broke the camel's back. This made me realize that I'm still holding onto some biases about Java, and that it's worth a look. I did start to dabble in Scala (and I have experience with Clojure), but it seemed like I'd want to know some Java before doing Scala, whereas that didn't seem as necessary with Clojure.
  • muraiki 12y ago
    An explanation for downvotes would be appreciated... perhaps "poor type system" was too strong wording, and for that I apologize. But it was surprising to hear his opinion re: concurrency, as from what I understand that's one of the biggest features of Go.
    • TheHydroImpulse 12y ago
      "poor type system" isn't too strong, it's just what it is.
• dcosson 12y ago
  I think one reason to choose Go is simplicity. You can run, say, a JSON REST service and build it with TDD out of the box with only the standard libaries. It's also such a small language that you can pick it up quickly. I haven't done an serious Java development recently but my impression is that if I wanted to get up and running with it quickly there would be a ton of choices to make around frameworks, tooling, which conventions to stick to, etc. and it would all be difficult to navigate. (And maybe that's not even true, but if that's my impression I'm just gonna choose choose Go).
• voidlogic 12y ago
  >But I still don't see why you would choose Go over Java (or Scala) for serious backend development. 1. Less verbose code 2. Platform Ind. + native binaries, no runtime dependency 3. Built in unit testing/benching 4. Fast compile time 5. Better tooling, no Ant etc needed 6. Better core language support for multithreading/concurrency 7. A memory model that makes it easier to read the code and understand how the resulting data will be layed out in memory 8. Related to 7, better stack vs heap allocation control >Java has more libraries Many of which are of low quality / filled with code-rot, I used to play in the Java ecosystem the Go stdlib is cleaner and the Go 3rd party libraries tend to be better, more single function. >is faster This is not always the case and is changing for Go's better fast. To paint Go as non-competitive would be unfair as its in the same league as Java and it usually faster than C# Mono. >has generics (for the love of god) I used to miss this, but I find I don't anymore... I wrote proxies, databases, systems applications. >has better IDE support True. This used to pain me until I found LiteIDE and I started writing unit tests more and using the debugger less. Go's profiler is awesome though... >and has a larger hiring pool. Not really, any smart C/C++/C#/Java developer can be highly productive in Go in weeks. >In summary, the ecosystem is more mature. A double edged sword mind you, not to mention Go is maturing at faster rate then Java did. >Java's checked exceptions are less painful then Go's C-style error handling. No. C++/Java got it wrong, ignoring error paths lead or letting random low level errors bubble up are some of the horrible results of the Java way to handle exceptions. Forcing programmers to consider which operations may fail- how to handle those failures is one of the best decisions Go made. Multiple returns make this much less painful than C.
  • pjmlp 12y ago
    > 2. Platform Ind. + native binaries, no runtime dependency Also available in Java. It is just a matter of choosing the right compiler. Java like many other languages, enjoys a standard, certification process and multiple implementations to choose from.
    • voidlogic 12y ago
      GCJ is dead. Are you referring to proprietary implementations?
• functional_test 12y ago
  Java actually doesn't have generics. It has syntactic sugar for generics, but they are so horribly broken they can't be fixed. For example, because the generics are just sugar for casts, you can't specialize them. Because you can't specialize them, you have to put behavior in the "wrong place". Take for example a hash map from Double -> T. Because IEEE floats don't actually form an equivalence class (NaN != NaN), they don't make great keys to a hash table (if you put NaN in, you can't get it out). But, rather than specializing the hash table for floats to give special NaN handling, Java had to make Double(NaN) == Double(NaN), so when they're boxed, they do form an equivalence class. And if that were the only inconsistent behavior in primitives versus their boxed counterparts, that would be great... EDIT: To those who downvote, would you discuss your objections? I understand that I may come off a bit caustic, but having been burned by the myriad correctness issues in Java, it's hard not to. These aren't abstract problems that don't come up in practice -- for a public example, look at what Paul Phillips has to say about the JVM and standard libraries.
  • pjmlp 12y ago
    It won't be longer true in Java 9, latest Java 10.
    • functional_test 12y ago
      Overall that's great to hear, but I can't help but feel that it's too little too late. Once they fix the generics, are they going to go back and fix the secondary issues too (like the issue with Doubles)? I know this isn't a popular opinion, but these correctness issues really matter. For example, you can see the impact these choices in the JVM and the standard library had on the Scala community, ultimately forcing Paul Phillips to fork the compiler.
• bad_user 12y ago
  When people focus on a language, they tend to think only about the language and not the ecosystem around it. Yes, Java 8 has closures, but then again it will be a very long time until the ecosystem will move to using them. And for example, even though Scala has baked-in features to make functional programming much more pleasant / practical, it's not those features that position it as a functional programming language, but rather the ecosystem around it. In other words, even though you can mostly use a language that has closures in an FP fashion (and people did so with languages like Java or Javascript), it's painful doing so not only because of the language and the standard library, but also because the other people and the supporting libraries are not doing that and then you're the weirdo that swims against the tide. On the other hand the JVM on the whole is an extremely good platform and given that one can use on top alternative languages that do make a difference, like Scala, Clojure, Ceylon or Groovy, well that's the comparison I'd like to see ... the JVM versus Go. On your arguments - Java's checked exceptions are deeply broken IMHO, but something that works much better in the context of a static language are types such as `Try[T]`, `Either[L,R]`, `Option[T]` or `Validation[E,A]` from Scala. They achieve their purpose of documenting the error in the function's signature and can do much more than exceptions can, they force you to either deal with it or escalate and their API is very comfortable. Unfortunately whenever you bring these into a discussion, people dismiss them because you know, monads and applicative functors are apparently too "academical". But we keep reinventing broken wheels, because we can't bother to learn anything else that isn't in the gang of four. On Go my personal opinion is that it is a very poor choice compared to the JVM, even when speaking about Go's strongest points, like performance and concurrency and yes, I believe that the JVM is a strong winner on all points. But then I wouldn't expect people that have chosen Node.js or Python/Gevent to start making good decisions.
• shanemhansen 12y ago
  I find java's ecosystem to be it's biggest drawback. Yes, there are libraries and frameworks available for everything. The drawback is that every simple task, from building to testing to servers is wrapped in so many useless layers of indirection and configuration I just want to tear my eyes out. If you could throw out all the nonsense that has infected java and just build simple things from scratch on the jvm that would be awesome. But it's too late. I find that creating go backend services is super easy and simple. The builtin web server is amazingly performant. I've found it super easy to integrate with other services (cassandra, postgres, mysql, mongo, nsq). The result is always high performance apps with a low memory footprint and high test coverage. When it comes to type systems, I find go's handling of errors to be closer to rust than c. Basically multiple return values encapsulate the same information Rusts's Result<T, E> does. You just deal with: if a, err := f(); err == nil { // do something with a } else { // do something with err } rather than: match f() { Ok(a) => { // do something with a } Err(err) => { // do something with err } } Rust certainly has the advantage in type safety, but I find the 2 forms mostly equivalent for the things I care about.
  • codygman 12y ago
    In the rust example error handling is enforced via the type system whereas with Go it depends on your (and others) discipline.
    • shanemhansen 12y ago
      You're correct. Go doesn't leave it entirely to discipline, since unused (or unhandled) variables are a compiler error. You can silence that error with _, but it sticks out to the eye as broken code. However I'm not trying to argue that go gives you the same type safety guarantees that rust does, it doesn't.
      • codygman 12y ago
        Thanks, I forgot about the warnings. It's been a while since I've used Go.
• deleted 12y ago
  [deleted]