31–40 of 110 posts
Otherwise, feel free. Not sure why this is such a huge point of contention.
Earlier quoted context omitted.
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.
I like coffee and long walks.
tl;dr: * Stratups don't have time to rewrite the prototype the right way, and then hit the performance wall. * A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node.
>Startups don't have time to rewrite the prototype the right way, and then hit the performance wall.
I would guess that for experienced C/C++ programmers (and probably C#/Java) Go isn't going to be slower to build in than Python/Node etc. I actually build things the fastest right off the bad in Go... I've ported node.js applications to Go, and let me tell you it was not fun. Even if the first throw away prototype was in Go, it would have made the rewrite much easier.
>A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node.
Considering Go was built to compete with Python/C/C++/Java at Google I would hope so. I think a key metric that often is left out is maintainability. I think Go's very straight forward code (which some people call boring) is an asset here.
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 would choose Go over Java (or Scala) for serious backend development. Java has more libraries, is faster, has generics (for the love of god), has better IDE support, and has a larger hiring pool. In summary, the ecosystem is more mature. Java's checked exceptions…
> Java is faster Do you have any evidence to back that up? I am not disagreeing, just curious.
... Thanks for the downvotes. Well worth the bad karma :)
Earlier quoted context omitted.
I've never really understood the "no easy way to handle errors" complaint. I'm not saying it is easy, nor that it isn't verbose (hell, it is super verbose!) but I'm seriously asking: what would be an easy way to handle errors? I'm not asking about how to do it in Go, just how to do it in any programming language. To me errors are very special constructs, is not a typical return value, as for example a method returnin…
It's the verbosity that I'm talking about. In go I end up with %70 of my code being error handling or error related... with Elixir it's close to %0.01. I'm giving estimates here, of course, but they aren't off by much. With elixir, using try catch is rare, because it should never crash, and when it does, you lose a process and debug it. With go, every line that calls a function needs to check to see if there was an e…
Those numbers you gave, even when you said they're estimates, still seems like made up numbers. I've never used Elixir, so if you could point me to an example so I can be more informed, I'll be grateful :) but also I've read some Go programs (not many, I'm not an expert) and it didn't seem to me that 70% of the code is dedicated to error handling.
Note that I'm not defending Go's position on error handling, I'm asking about error handling in general, what does people mean with "easy way to do it".
While go has some nice features-- standalone executables and fast execution are two. I don't really see a compelling reason to switch to it from Elixir/Erlang. Biggest downside seems there's no real easy way to handle errors being returned from function calls. Easier deployment would be good, but once you solve it for elixir it's not a big issue. On the other hand Erlang is very well tested and established and pretty…
Let be honest here, who really use Erlang? How do you find people that knows this language?
A few well know companies in the healthcare world.
Nice stories about how iron.io reduced 30 ruby servers to 2 go servers became relevant only after they proven good market fit and working growth engine.
So GO? maybe yes but probably only when the prototyping languages, can't carry weight.
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 would choose Go over Java (or Scala) for serious backend development. Java has more libraries, is faster, has generics (for the love of god), has better IDE support, and has a larger hiring pool. In summary, the ecosystem is more mature. Java's checked exceptions…
Like with any languages, there's lots of tradeoffs between systems. I would also suggest the "Java .. is faster" isn't always true.