Why Tech Startups Should Look at Go
startupedmonton.tumblr.com
Why Tech Startups Should Look at Go
1–10 of 110 posts
Re: Why Tech Startups Should Look at Go
#2While 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 complete-- though go's libraries and open source support is growing by leaps and bounds.
So really, it's that error issue. Oh, and pipe. I really love elixir's pipe ( |> ) operator.
Re: Why Tech Startups Should Look at Go
#3While 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.
Re: Why Tech Startups Should Look at Go
#4tl;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.
Re: Why Tech Startups Should Look at Go
#5While 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.
> The alternative seems to be exceptions flying unhinged.
…
The commenter you replied to explicitly mentioned Erlang and Elixir, you may want to have an idea about where they're coming from before replying to their comment.
Re: Why Tech Startups Should Look at Go
#6Gophers 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 that he got a decent sum for his Express framework. I would be interested to know who else is behind this.
Re: Why Tech Startups Should Look at Go
#7Tech 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 experimentation and internal learning in new languages without impacting an entire product.
Re: Why Tech Startups Should Look at Go
#8While 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?
Re: Why Tech Startups Should Look at Go
#9While 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 returning true or false whether the arguments are valid or not, so I expect errors to be something similar (at least semantically) as exceptions in other languages, and in that case, that is, return values that should be deal with in a certain special manner, so I don't expect to deal with them in an "real easy way"™, but in a very conscious and deliberated way.
Re: Why Tech Startups Should Look at Go
#10Earlier quoted context omitted.
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.
> The alternative seems to be exceptions flying unhinged. … The commenter you replied to explicitly mentioned Erlang and Elixir, you may want to have an idea about where they're coming from before replying to their comment.
Yeah, that's why I said seems. I'm not going to lie, I know next to nothing about Erlang and Elixir.