I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.
Program your next server in Go
31–40 of 384 posts
Re: Program your next server in Go
#32I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.
Absolutely. It's unfortunate that Nim is relatively unknown - here's hoping it gets a large backer sometime soon to boost its popularity!
I'd also add D (above C++, level with Java) and Rust (above C++, close to Go).
Re: Program your next server in Go
#33What are some cases where I would choose to write a server in Go instead of in Erlang?
When your server has to do some computations to return results.
Erlang is bad at that.
Re: Program your next server in Go
#34What are some cases where I would choose to write a server in Go instead of in Erlang?
As an Erlang fan, my guess is that Go is a bit faster for many things, whereas Erlang's concurrency, fault tolerance, and distributed stories are "better". Not everyone needs all those though. Go is probably a bit more 'generic' - you can do anything with it. Erlang has always felt like it's a tool designed to do a few things really, really well.
Re: Program your next server in Go
#35What are some cases where I would choose to write a server in Go instead of in Erlang?
First thing on duckduckgo when you search for how to write a server in erlang: http://20bits.com/article/erlang-a-generic-server-tutorial That's just ridiculous. Erlang looks like php and python had an unholy child.
What is ridiculous exactly? You just dislike the superficial look of the syntax?
Re: Program your next server in Go
#36What are some cases where I would choose to write a server in Go instead of in Erlang?
When you want to hire developers.
Hiring good developers for Erlang is easy: just look for functional programmers.
It is indeed hard to hire mediocre developers for Erlang: they stay away from FP.
Re: Program your next server in Go
#37I will have to try Go again. It seemed really awesome at first then quickly seemed like a regression in a lot of PL design things (which is good in some cases). I personally like rust but maybe I am a glutton for type based punishment.
Solution: design the language for large code bases
This seems crazy but whatever works. I would assume that would only buy you some wiggle room inside whatever order of magnitude of committers you have. It seems like eventually you would need to split up the code base if you are having contention issues.
Re: Program your next server in Go
#38What about debugging? This is the major pain point for me. I've tried using GDB, but... > GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable deb…
It is strange you ask this, cause it was one of my major issues with diving into golang.
The reality is that I don't miss it any more, for two reasons.
1. I have been forced to write solid comprehensive testing. Its a pain, but the pay off has made it worth while.
2. Because you never find all the bugs anyway, instrumentation and logging has become part of everything I do. A framework like go kit can do this out of the box for you or function as a guide for you.
Re: Program your next server in Go
#39What are some cases where I would choose to write a server in Go instead of in Erlang?
First thing on duckduckgo when you search for how to write a server in erlang: http://20bits.com/article/erlang-a-generic-server-tutorial That's just ridiculous. Erlang looks like php and python had an unholy child.
Different stokes for different folks. Looks fine to me. But I'd prefer you don't try to offer advice if you don't actually know Erlang in the slightest.
Re: Program your next server in Go
#40What are some cases where I would choose to write a server in Go instead of in Erlang?
First thing on duckduckgo when you search for how to write a server in erlang: http://20bits.com/article/erlang-a-generic-server-tutorial That's just ridiculous. Erlang looks like php and python had an unholy child.
I won't downvote you because you are certainly entitled to your opinion, and there is no way I'm going to get into an Erlang vs Go For Writing Servers argument, but if you immediately write off Erlang/OTP because of how it looks, you are going to miss out on some pretty amazing server writing functionality.