its hard enough to hire decent developers never mind decent go developers
Why Tech Startups Should Look at Go
41–50 of 110 posts
Re: Why Tech Startups Should Look at Go
#42Re: Why Tech Startups Should Look at Go
#43AWS 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 rebuild with technologies that scale better than what you started out with, but I doubt all that many startups ever actually get to that point.
Re: Why Tech Startups Should Look at Go
#44While 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…
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 error or something. But generally it's considered defensive programming and an antipattern to try and handle every error condition in an Erlang program like you have to do with e.g. Java exceptions.
In languages with powerful type systems like Haskell, errors can be handled by using (for example) the Either[1] type. That way, you are forced to pattern match on the type (it will be a Right if successful or a Left if unsuccessful/errored), so it's not possible to "forget" to check for a null reference like you do in Go (i.e. checking err != nil all over the place).
[1]: http://hackage.haskell.org/package/category-extras-0.53.4/do...
Re: Why Tech Startups Should Look at Go
#45While 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
#46While 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
Nope, that's what I'm talking about. That article shows how to optimize this constant checking of errors.
What I'm trying to say is that in elixir you handle this at the level of the process. In go the whole thing is one process so you can't do that. In elixir you let it crash, and if the process crashes you report the error and conditions of the crash in the log.
In a real system you would only have a couple things where you do a try/catch or "is error not null" type checks-- for the whole program.
Re: Why Tech Startups Should Look at Go
#47Earlier quoted context omitted.
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 yea…
I would argue that you can pick any new'ish (last 5 years) language that is suitable for development and find the same results. Anyone who knows the language well taught themselves how to use it without the guarantee of being able to use it at a job.
This will be a fairly small subset of developers, the ones that have motivation and time to put into growing themselves. So this probably means that the devs that know new language X are just more interested in software development (compared to devs that just know the language(s) they learned in school, and whatever they were taught on their jobs). So they have a much higher chance of being good developers.
Re: Why Tech Startups Should Look at Go
#48Essentially 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…
An experienced programmer friend of mine uses Go professionally. I was surprised to hear that he much prefers Java: he said that many concurrency libraries are available for Java and that Go's features are quite limited in comparison. He dislikes the fact that you have to break Go's poor type system to get many things (such as tests) to work. He has a pretty strong background in FP, so I think that perhaps Go's interfaces are the straw that broke the camel's back.
This made me realize that I'm still holding onto some biases about Java, and that it's worth a look. I did start to dabble in Scala (and I have experience with Clojure), but it seemed like I'd want to know some Java before doing Scala, whereas that didn't seem as necessary with Clojure.
Re: Why Tech Startups Should Look at Go
#49Earlier quoted context omitted.
> 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-- yo…
> Having a really good language as part of your stack works as a filter-- you get the best programmers that way.
Agreed. At one point I felt this way about Scala, but it's starting to change as the boulder rolls downhill.
I still use Scala, because it's fantastic, but it's no longer a safe assumption that a Scala programmer can be trusted with sharp objects from the jump.
Re: Why Tech Startups Should Look at Go
#50Essentially 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 think one reason to choose Go is simplicity. You can run, say, a JSON REST service and build it with TDD out of the box with only the standard libaries. It's also such a small language that you can pick it up quickly.
I haven't done an serious Java development recently but my impression is that if I wanted to get up and running with it quickly there would be a ton of choices to make around frameworks, tooling, which conventions to stick to, etc. and it would all be difficult to navigate. (And maybe that's not even true, but if that's my impression I'm just gonna choose choose Go).