Live data from Hacker News

Why Tech Startups Should Look at Go

startupedmonton.tumblr.com

11–20 of 110 posts

Re: Why Tech Startups Should Look at Go

#11
post #3
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…

Can you be more specific in how handling errors is difficult? I've found it to be generally forced and explicit, which, while sometimes unpleasant, is quite comforting. The alternative seems to be exceptions flying unhinged.

Let it fail, let it fail, let it fail! (to the tune of "let it snow, let it snow, let it snow!) Supervisor Trees!

Exceptions are not much better, but checking the return every time is no fun. And if you crash the whole thing crashes.

In erlang you can have a once in 1x10^9 error and not even catch it, but only that process crashes (and your system keeps running) and that process gets relaunched. With go, it's the whole program that will crash, necessitating checking every return value.

I say this, though I might be missing some error handling system in go that I'm simply not aware of.

Re: Why Tech Startups Should Look at Go

#12
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

#14
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 don't really see a compelling reason to switch to it from Elixir/Erlang. What about ease of growing your team and finding 3rd party libraries so you don't have to re-invent the wheel?

I think it's funny, but not surprising, that you assume it will be easier to grow the team with Go. It's not a more popular or established language, yet.

But also, I've recently built a team using Elixir before Elixir was even 1.0. About the hardest possible example of that argument and we found great people, grew a great team in Austin Texas.

Having a really good language as part of your stack works as a filter-- you get the best programmers that way. Not saying go is bad, but it's popular, and so you're going to get a lot of people who chose it because it was popular.

As for re-inventing the wheel, erlang has a lot of 3rd party libraries, and is ahead of go in that regard, for the time being.

Most interesting to me is your perception of the situation, which I'm guessing is driven by the fact that go is very popularly being evangelized right now.

Re: Why Tech Startups Should Look at Go

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

One upside is that learning Go is easy for a an experienced developer.

Re: Why Tech Startups Should Look at Go

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

Re: Why Tech Startups Should Look at Go

#17
post #12
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?

Who? Guys who know about high load and distributed systems, mostly the telecom industry.

Re: Why Tech Startups Should Look at Go

#18
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 am not going to argue about "which one does it better", because I have no experience with Elixir.

But regarding Go's verbosity when dealing with errors in particular, this article helped me a lot:

http://blog.golang.org/errors-are-values

Re: Why Tech Startups Should Look at Go

#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 are less painful then Go's C-style error handling. They could have gone with something sane like Rust/Haskell style error handling (using the type system), but they instead regressed to return value checking.

The complaints about Java's overwhelming verbosity are mostly dated both on the language-level and the ecosystem-level. Java 8 has lambdas, streams, and more. Spring Boot and Dropwizard are 2 modern, lightweight frameworks that do away with the XML configuration nonsense.

I'm actually genuinely asking why anyone would choose Go over Java and not trying to start a flame war. An API I'm working on is due for a rewrite and it's currently written in PHP. I'd like to give Go a chance but it just seems like a poor choice compared to Java.

Re: Why Tech Startups Should Look at Go

#20
Here's my take on this as someone who loves both Go and PHP (yeah, I know!). I agree that startups can get entrenched in their legacy code, but I also think there is a false choice here:

1. Write with a system language from the start. Yikes!

2. Do a total rewrite of your application later when you hit scale issues. Yikes!

In my opinion, though, Go is not well-suited (today) for rapid prototyping or web application development, even with some of the frameworks. This shouldn't be a surprise. Go is a systems language.

I think languages like PHP, Ruby, and the lot are much better suited early stage startups. When you hit problems of scale, it's very straight-forward to isolate parts of your application that do not scale well and translate those components to Go.

Introducing Go for only the components that require high availability and guarantee a level of performance / memory safety as an iteration to your original application code is probably a much saner choice.

Post reply on HN