33 ms·

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.

by MCRed 12y ago

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

ihsw 12y ago
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.
- masklinn 12y ago
  > 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.
  - ihsw 12y ago
    Yeah, that's why I said seems. I'm not going to lie, I know next to nothing about Erlang and Elixir.
- MCRed 12y ago
  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.
  - falcolas 12y ago
    You can set a `defer recover()` which will stop the panic from crashing the entire program, letting you recover & take whatever action you deem appropriate.
voidlogic 12y ago
> 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?
- MCRed 12y ago
  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.
  - eropple 12y ago
    > 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.
  - voidlogic 12y ago
    >It's not a more popular or established language, yet. Github would disagree as one data point. I don't have my own numbers to back this up but I firmly believe based on my communication that there are more people in the world that have written Go right now than Erlang. >Having a really good language as part of your stack works as a filter-- I think this is good for Go and Erlang... So I don't think it helps distinguish. Not to mention anyone that smart knows C/C++/C#/Java can very quickly become a gopher if needed; quicker I would contend than you will ramp them up on Erlang. >Most interesting to me is your perception of the situation I've been writing Go full-time since before Go 1.0 RC-- I think you don't have an accurate perception of where Go is at.
inkel 12y ago
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.
- waffle_ss 12y ago
  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/docs/Control-Monad-Either.html http://hackage.haskell.org/package/category-extras-0.53.4/do...
  - inkel 12y ago
    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 something else about it.
Thaxll 12y ago
Let be honest here, who really use Erlang? How do you find people that knows this language?
- bonesinger 12y ago
  http://stackoverflow.com/questions/1636455/where-is-erlang-used-and-why http://stackoverflow.com/questions/1636455/where-is-erlang-u...
- nine_k 12y ago
  Who? Guys who know about high load and distributed systems, mostly the telecom industry.
- radioact1ve 12y ago
  Whatsapp
- muraiki 12y ago
  WhatsApp is one of the more well known examples: http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...
- MCRed 12y ago
  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.
  - kyrra 12y ago
    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.
otikik 12y ago
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 http://blog.golang.org/errors-are-values
- MCRed 12y ago
  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.

by MCRed 12y ago

ihsw 12y ago

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.

masklinn 12y ago
> 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.
- ihsw 12y ago
  Yeah, that's why I said seems. I'm not going to lie, I know next to nothing about Erlang and Elixir.
MCRed 12y ago
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.
- falcolas 12y ago
  You can set a `defer recover()` which will stop the panic from crashing the entire program, letting you recover & take whatever action you deem appropriate.

voidlogic 12y ago

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

MCRed 12y ago
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.
- eropple 12y ago
  > 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.
- voidlogic 12y ago
  >It's not a more popular or established language, yet. Github would disagree as one data point. I don't have my own numbers to back this up but I firmly believe based on my communication that there are more people in the world that have written Go right now than Erlang. >Having a really good language as part of your stack works as a filter-- I think this is good for Go and Erlang... So I don't think it helps distinguish. Not to mention anyone that smart knows C/C++/C#/Java can very quickly become a gopher if needed; quicker I would contend than you will ramp them up on Erlang. >Most interesting to me is your perception of the situation I've been writing Go full-time since before Go 1.0 RC-- I think you don't have an accurate perception of where Go is at.

inkel 12y ago

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.

waffle_ss 12y ago
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/docs/Control-Monad-Either.html http://hackage.haskell.org/package/category-extras-0.53.4/do...
- inkel 12y ago
  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 something else about it.

Thaxll 12y ago

Let be honest here, who really use Erlang? How do you find people that knows this language?

bonesinger 12y ago
http://stackoverflow.com/questions/1636455/where-is-erlang-used-and-why http://stackoverflow.com/questions/1636455/where-is-erlang-u...
nine_k 12y ago
Who? Guys who know about high load and distributed systems, mostly the telecom industry.
radioact1ve 12y ago
Whatsapp
muraiki 12y ago
WhatsApp is one of the more well known examples: http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...
MCRed 12y ago
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.
- kyrra 12y ago
  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.

otikik 12y ago

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 http://blog.golang.org/errors-are-values

MCRed 12y ago
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.