Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Tech Startups Should Look at Go

startupedmonton.tumblr.com

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Why Tech Startups Should Look at Go

#71

Post by copsarebastards »

It's not at all surprising that those startups solved their problems with Go: if you switch from a language that doesn't address your problems to one that does, you're going to see a big benefit. But there are lots of languages that address the problems mentioned by those startups, and I think that Go is possibly the worst of the options.

It's telling that none of the startups in question switched out of a language which provides good compile-time type and thread-safety guarantees:

1. iron.io: ruby -> go 2. SendGrid: perl -> python -> go 3. TJ Holowaychuck: node.js -> go

Go would have a reasonable compile-time type system, except that without generics you end up having to cast a lot, which renders your compile-time type system almost irrelevant.

It's also telling that none of the authors mentioned experience with functional programming. Go supports some functional programming, but it doesn't seem to be a very big part of the language. The only one who mentions that they even considered any functional languages is the iron.io guy, and it seems like a big part of his choice was not technical: he mentions that he had to sell the idea of Go to his team by mentioning that Google supports it. A language that was a more serious paradigm shift (OO -> functional) would have been an even harder sell.

(EDIT: Okay, the SendGrid guy did mention considering Scala.)

The fact is, there are a bunch of languages that would have solved their problems, in addition to a few they didn't know they had. Julia has coroutines similar to Go, but is much more expressive, Rust has a more traditional threading model but a type system and focus on immutability that provides better safety guarantees. There are other choices, but those two stand out as the major ones that could have solved their problems better than go.

Re: Why Tech Startups Should Look at Go

#72

Post by bad_user »

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…

> 1. Less verbose code

Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages.

> 2. Platform Ind. + native binaries, no runtime dependency

In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work. On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency. It's true that it doesn't get distributed as byte-code that needs a VM, but at the very least you're still dependent on a garbage collector and that makes it unsuitable for all those things one would naturally do in C/C++.

Also, Java being the standard that it is, has multiple implementations and it doesn't necessarily need a VM. The purpose of RoboVM (http://www.robovm.com/) for example being to build apps for iOS in Java meant compiling Java to native and RoboVM does just that. But there are advantages to distributing apps as bytecode - Android ART (the successor to Dalvik) is doing AOT compilation to native upon installing an app on your phone and the cool thing is that you don't have to worry about what processor your app will end up running on.

> 3. Built in unit testing/benching

I don't see how that is an advantage. Does Go have something like YourKit Profiler? Can you easily connect to a remote application for debugging or profiling?

> 4. Fast compile time

One can argue that fast compile times are a direct consequence of the compiler not doing pretty much of anything you'd expect a compiler to do - like optimizations or type-safety. For example the C++ compiler is slow, but the C++ compiler can optimize the shit out of anything. Scala's compiler is slow, but it can catch a lot of errors for which you'd normally have to run expensive third-party tools.

> 5. Better tooling, no Ant etc needed

Nobody is using Ant anymore. Go doesn't have Maven or anything like it (i.e. Gradle, SBT, Leiningen). As a personal opinion, whenever I have to work with other platforms, feels like going back to the nineties.

> 6. Better core language support for multithreading/concurrency

This is a common misconception, when the opposite is factually true.

On the JVM you'll find support for the Erlang-style actor model, Hoare's CSP, Futures/Promises, reactive streams (Rx), STM, parallel collections and the best concurrent data-structures that open-source can provide. See Akka, Quasar, Scala's and Clojure's standard libraries, LMAX Disruptor, etc...

> 8. Related to 7, better stack vs heap allocation control

This has always been a problem for the JVM, however stack-allocated values are coming in the next version. On the other hand the control on memory layout in Go is still weak and the JVM does have much better garbage collectors.

Re: Why Tech Startups Should Look at Go

#73

Post by codygman »

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…

I wonder how long it will be until Rob Pike decides that "Handling error values should be enforced by the type system".

Re: Why Tech Startups Should Look at Go

#75

Post by masklinn »

inkel wrote: post #60
waffle_ss wrote: post #44

Earlier quoted context omitted.

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

> 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

It is a different way to see things, but makes sense when you consider that Erlang comes from the world of distributed high-availability telecoms where "one machine" is the same as no machine (because when — not if — the machine crashes, the system is dead).

Applied to the development environment, that means of course erlang developers try to avoid errors, but its designers know it's not possible to have 0 errors so they've built support for independent error recovery into the system: when an error occurs, the whole agent may be corrupted (in an invalid state or whatever) so the erlang way is to throw it out and have an independent "auditor" (the supervisor) decide what should be done.

At scale, that's essentially what Netflix builds (and exercises with their Chaos Monkeys)

Re: Why Tech Startups Should Look at Go

#76

Post by voidlogic »

bad_user wrote: post #72
voidlogic wrote: post #51

Earlier quoted context omitted.

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

> 1. Less verbose code Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages. > 2. Platform Ind. + native binaries, no runtime dependency In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work. On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency. It's true that it…

>Go is much more verbose than Scala or Clojure. Go is just a language, whereas the JVM is a platform with multiple languages.

There is a trade-off being verbosity and maintainability, IMGO Go hits that.

>In my opinion Java has a greater degree of platform independence. Wherever it runs, things just work.

LOL. Said no person who has actually distributed a multiplatofrm Java application ever- I should know. Both Java and Go are "write once, test everywhere", but in my XP Go has been smoother.

>On runtime dependency, you're wrong, as Golang does have a pretty heavy runtime dependency.

The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it.

>Does Go have something like YourKit Profiler? Can you easily connect to a remote application for debugging or profiling?

Yes. It comes baked into the stdlib, its "http/pprof"

>Go doesn't have Maven or anything like it

Biggest plus ever, goes native simple tooling doesn't need an external life support system.

>This is a common misconception, when the opposite is factually true.

You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries.

>On the other hand the control on memory layout in Go is still weak

IMHO This is not the case, if you think it is, explain.

Re: Why Tech Startups Should Look at Go

#77

Post by bad_user »

onion2k wrote: post #43

AWS is cheap enough that "throw more hardware at the problem" is a viable option for most startups. So long as you're not being completely stupid with the way you've coded the first version, pretty much any language is going to work, and the cost of people who can code well in more esoteric languages that might be better suited to the problem domain are going to be increasingly expensive. Obviously there is a time to…

I don't think you've ever calculated just how much that cost is.

Lets say that you have a web service that is serving 30,000 requests per second, with a 1 Kb request size and a 4 Kb response size and you're setting up an elastic load-balancer setup that on average keeps 300 c3.xlarge instances open.

Do the math and you'll find that the cost on AWS, considering the instances used and the bandwidth, is over $80,000 per month. And that's a conservative example, since by my calculations that's about $1,000,000 per year and I know companies paying much more than that.

Don't know what startups you're thinking about, but from where I'm standing, for startups that's a recipe for burning cash.

Re: Why Tech Startups Should Look at Go

#78

Post by pjmlp »

voidlogic wrote: post #61
pjmlp wrote: post #55

Earlier quoted context omitted.

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

GCJ is dead. Are you referring to proprietary implementations?

Yes, who still bothers with GCJ? I really don't understand why GCC still ships it.

However there are also open source implementations like RoboVM and JikesRVM, among a few others.

Re: Why Tech Startups Should Look at Go

#79

Post by muraiki »

inkel wrote: post #60
waffle_ss wrote: post #44

Earlier quoted context omitted.

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

Something to think about: this is similar what people are building (outside of Erlang/Elixir) using Docker and CoreOS. Deploy a bunch of instances of your app both to scale and to handle failures. Need to update the OS on a box? Restart it, there's other app instances to cover it. A container crashed? Restart it -- it's not sharing state with other instances so things will be fine.

Another way to handle error propagation transparently is using monads. Even if you haven't used monads in Haskell, you've probably used them in Javascript: promises are monads. Consider how both errors and exceptions propagate through .then chains in promises. There might not be as much syntactic sugar in JS as there is in Haskell, but the idea is pretty much the same.

Re: Why Tech Startups Should Look at Go

#80

Post by voidlogic »

pjmlp wrote: post #34
otikik wrote: post #26

Earlier quoted context omitted.

> Java is faster Do you have any evidence to back that up? I am not disagreeing, just curious.

For example, https://www.techempower.com/benchmarks/

Go still beats Java sometimes: 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.

Post reply on HN