Why Tech Startups Should Look at Go • Hacker News Board

Re: Why Tech Startups Should Look at Go

#21

Post by MCRed » Thu, Jan 15, 2015, 3:09 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…

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 error. And handling that error takes at least another line or two.

Unless there's a better way that I'm missing.

Re: Why Tech Startups Should Look at Go

#22

Post by radioact1ve » Thu, Jan 15, 2015, 3:09 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?

Re: Why Tech Startups Should Look at Go

#23

Post by muraiki » Thu, Jan 15, 2015, 3:10 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?

WhatsApp is one of the more well known examples: http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...

Re: Why Tech Startups Should Look at Go

#24

Post by MCRed » Thu, Jan 15, 2015, 3:11 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…

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.

Re: Why Tech Startups Should Look at Go

#25

Post by nkozyra » Thu, Jan 15, 2015, 3:11 PM UTC

voidlogic wrote: post #16

nkozyra wrote: post #7

Tech startups who hit this phase (or "wall," as it's described here), should look at all options. Even if Go is the best technical option, it may not be the best business decision. That's an unfortunate reality for startups - if you can't bring in the staff you want / need, the best tool for the job might not be the right one. This ends up being another pro for the distributed microservice model, allowing some experi…

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

I thought I hinted that it was more a matter of available resources. The Go community is growing but if you're a lean startup looking for developers to get moving quickly, the pool for Python, PHP, Node & Ruby/Rails dwarfs that of Golang.

And to the other comment, yes, it's easy (and generally surprisingly pleasant) for experienced developers to pick up, but that's an investment.

Re: Why Tech Startups Should Look at Go

#26

Post by otikik » Thu, Jan 15, 2015, 3:11 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 is faster

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

Re: Why Tech Startups Should Look at Go

#27

Post by 0xCMP » Thu, Jan 15, 2015, 3:11 PM UTC

voidlogic wrote: post #16

nkozyra wrote: post #7

Tech startups who hit this phase (or "wall," as it's described here), should look at all options. Even if Go is the best technical option, it may not be the best business decision. That's an unfortunate reality for startups - if you can't bring in the staff you want / need, the best tool for the job might not be the right one. This ends up being another pro for the distributed microservice model, allowing some experi…

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

Re: Why Tech Startups Should Look at Go

#28

Post by tljr » Thu, Jan 15, 2015, 3:12 PM UTC

MCRed wrote: post #24

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…

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.

Re: Why Tech Startups Should Look at Go

#29

Post by perturbation » Thu, Jan 15, 2015, 3:13 PM UTC

jonpress wrote: post #6

Gophers love to quote TJ Holowaychuk to justify choosing Go over Node.js. In my eyes, TJ is a traitor - If he preferred Go, that's fine - He could just go ahead and use it as he likes, but he wrote a post completely debasing Node.js without pointing to any real, concrete issue. I bet he is still using Node.js from time to time - The 'Goodbye' article is obviously just a stunt. He probably cashed out! I read somewhere…

Speaking only for myself, I've found the following to be broadly true with Node.js and Go:

If I'm building a strictly server-side app using Express, it's a joy to use Node.js (especially for a prototype) - everything more or less works, and the NPM ecosystem is rich and broad. Very easy way of getting a RESTful JSON API up-and-running from FooDB.

If I'm building a client (web scraper, getting stuff out of an API to load into R, etc.) then I really quickly run into "Too Much Concurrency" TM with Node. I quickly find myself building something with Go (or Ruby) to do the following:

- Limited Number of workers

- Automatically re-try request N number of times if fails, depending on response code

- Log all successes/failures

- Throttle total # of requests/second based on site-specific rate limiting

To make the above work in Node, I have to use caolan's async + Q promises + other libraries (or write in Icedcoffeescript, which I like but is very weakly typed and has inferior tooling) and find myself refactoring most of the small script just to fit into the async libraries. With Go, I can use mutexes or simple channels to control throttling, and do whatever I want with errors. There's a lot of boilerplate to get the above up-and-running robustly for Node, or at least that's been my impression the last few times that I've used it. Node has solutions for advanced concurrency (Generators, promises, CSP libraries), but why reinvent the wheel when Go has that out of the box?

Re: Why Tech Startups Should Look at Go

#30

Post by MCRed » Thu, Jan 15, 2015, 3:14 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?

I've recruited and built a team which was writing code in Elixir, even more obscure than Erlang. It wasn't really a problem finding people who knew it or were strong programmers who were interested in it.

Good languages attract good programmers.

The idea that we need to stick to popular languages is, I think, driven by business guys who want commodity programmers.

If you want 100 engineers added to your team in a year, then sure, use Java. But you will still be less effective, I bet, than 10 engineers doing erlang in that same year.