Why Tech Startups Should Look at Go • Hacker News Board

Re: Why Tech Startups Should Look at Go

#51

Post by voidlogic » Thu, Jan 15, 2015, 3:27 PM UTC

ryeguy wrote: post #19

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…

>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.

Re: Why Tech Startups Should Look at Go

#52

Post by ksherlock » Thu, Jan 15, 2015, 3:28 PM UTC

Thaxll wrote: post #12

MCRed wrote: post #2

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?

Do you want to hire people that are incapable of learning a new language?

Re: Why Tech Startups Should Look at Go

#53

Post by functional_test » Thu, Jan 15, 2015, 3:28 PM UTC

ryeguy wrote: post #19

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 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.

Re: Why Tech Startups Should Look at Go

#54

Post by muraiki » Thu, Jan 15, 2015, 3:29 PM UTC

inkel wrote: post #36

MCRed wrote: post #21

Earlier quoted context omitted.

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…

Ok, verbosity I agree. That doesn't have anything to do with being easy or not, I think. I might be wrong. Verbosity can be a pain. Even after reading Rob Pike's article on "Errors are values" [1], I agree with you that the solution is still verbose. 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 b…

The Erlang/Elixir way can be hard to appreciate because it's not just a very different way of handling errors, it's a completely different way to architect your application. The following tutorial only takes about 45 min to go through, but you'll get a taste for how error handling (across distributed process, at that) works in Elixir: https://howistart.org/posts/elixir/1

Re: Why Tech Startups Should Look at Go

#55

Post by pjmlp » Thu, Jan 15, 2015, 3:30 PM UTC

voidlogic wrote: post #51

ryeguy wrote: post #19

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…

>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 result…

> 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.

Re: Why Tech Startups Should Look at Go

#56

Post by pjmlp » Thu, Jan 15, 2015, 3:31 PM UTC

functional_test wrote: post #53

ryeguy wrote: post #19

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 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), the…

It won't be longer true in Java 9, latest Java 10.

Re: Why Tech Startups Should Look at Go

#57

Post by bad_user » Thu, Jan 15, 2015, 3:31 PM UTC

ryeguy wrote: post #19

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…

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.

Re: Why Tech Startups Should Look at Go

#58

Post by rdtsc » Thu, Jan 15, 2015, 3:34 PM UTC

inkel wrote: post #9

MCRed wrote: post #2

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…

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…

> "real easy way"™, but in a very conscious and deliberated way.

If your don't deal with errors in a "real easy way"™, your customers will deal with errors in "a harder way"™ and they'll call you at 4am about it too.

You can't avoid dealing with errors basically.

> deal with in a certain special manner,

Ok is this "manner" easy or hard to handle.

You can also look at it this ways, errors will happen. Some will be predictable (as in you expected a "connection refused" exception or error value. Some will be unpredictable ("this library I downloaded return -5 and just silently doesn't send the value" or throws some un-expected exception).

There are 2 good ways to deal with errors:

1) Use a stronger/better type system or other static checkers. Something like Haskell or Rust, hoping the type checker will prevent some class of errors. You hope to avoid errors ahead of time here. This approach is taken for some critical systems. Navigation, medical equipment, military hardware etc.

2) Isolate errors when they happen. Errors will happen at runtime, even in a typed-checked language. How do you want to deal with them? You can deal with them in an easy way -- isolate the component that fails and degrade the system slightly without completely stopping service. Or even better restart just that one sub-components. Or, have everything come crashing down with an exception or tracelog and get a call from a customer. Erlang and Elixir (and other BEAM VM) languages do this best. You can to a certain way replicate this with OS processes, but Erlang has that built-in. The reason for that is concurrency primitives (processes in Erlang, others have tasks/goroutines/threads) do not share a global heap. So that lets you both isolate the errors they happen to one component, and lets you separate main code from error handling code (you can have supervisors that watch other processes and if they crash they can deal with it better).

Re: Why Tech Startups Should Look at Go

#59

Post by voidlogic » Thu, Jan 15, 2015, 3:34 PM UTC

0xCMP wrote: post #27

voidlogic wrote: post #16

Earlier quoted context omitted.

> Even if Go is the best technical option, it may not be the best business decision Why might Go not be the best business option? I see technical case for or against Go as very much religious and shaped by personal preference. But what could be a business reason not to use Go for a new startup that is independent of the technical side?

You could assume that Go, although popular, isn't at the level of Python and Ruby in terms of available developers. The ones that would know Go are most likely very good and also expensive compared to just finding that one Ruby/Node/Python programmer of the many out there which will go low enough and suddenly Go doesn't make sense anymore for startups without the cash.

>You could assume that Go, although popular, isn't at the level of Python and Ruby in terms of available developers.

Not really, any smart C/C++/C#/Java developer can be highly productive in Go in weeks.

Side thought: If your startup isn't on the west coast, C/C++/C#/Java developers are far MORE common than Python/Ruby devs. Although C/C++/C#/Java developers are not rare anywhere.

Re: Why Tech Startups Should Look at Go

#60

Post by inkel » Thu, Jan 15, 2015, 3:35 PM UTC

waffle_ss wrote: post #44

inkel wrote: post #9

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…

There are better ways. The Erlang way would be to code for the happy path, and not try to anticipate most errors. If your process encounters an error, it will crash, the supervisor will restart it, and it will continue processing. Of course, you can choose to handle anticipated errors if you would like to be more user friendly (e.g. provide a user-friendly message if a file is missing), or if you want to log the erro…

Thank you for the explanation. I think it makes sense somehow, however, and high likely because I've never dealt with errors in that way, the _encounter error, crash, restart, continue_ workflow seems a bit awful to me :)

The Haskell solution seems really nice. I've only used Haskell for pet projects and it's one of my favorites languages (though I don't have any proficiency with it,) so thank you for teaching me something else about it.