Ask HN: Rewriting our back end. Which language? An opinated selection
Now we are doing the same for all our internal backend processes (old good java, written in 2004-2006). They are basically a bunch of standard daemons ingesting traffic from either plain TCP sockets (custom text-based protocol) or beanstalkd tubes. The logic is fairly standard: Some parsing, Mysql access, Memcached/Redis access, StatsD publishing, HTTP requests to external services, etc.
We could do this with OpenResty (using the timer API), but we are more inclined to implement stand-alone daemons.
We have narrowed our list to 2 languages: Dart(DartVM) and Swift(Kitura). We have written a couple of daemons in each language and in both cases it just feels right: Language concepts are easy to grasp, coding is easy enough, IDE support (visual studio code/atom) is good enough, available libraries fit our needs and performance is great in both cases.
Other than the language itself, we are more worried about language adoption, support and evolution.
Which one would you choose ?
For the record, we have discarded some other languages. As you can see, the arguments to discard them are highly opinionated. We are a bunch of old guys (45+) and I guess we are starting to be maniac. You have been warned.
- elixir. We really wanted to like it, but erlang feels alien to us.
- java. We have had enough of java already.
- lua (with luv or luvi). We don't like - as in we hate - nodejs :)
- golang: We have written some workers in the past and for some strange reason the language does not feel right to us.
- rust: too complex for us. Our workers are simple enough and we feel rust would not give us any additional benefit.
- dlang: Nice, but it seems more oriented towards numerical computing, low level system programming (OS, compilers) and embedded applications
Thanks.
[1] http://www.openresty.org
1 comment
[ 0.30 ms ] story [ 10.4 ms ] threadBecause Elixir was alien to me too (other than looking superfically Ruby-like)... at first... but after a while working with it, I started to see the advantage of the functional approach over OO, pattern matching was AWESOME (!!!), new processes in 1ms was AWESOME (as is process management in general), and the OTP semantics made sense after sitting on it for a while. And also, after learning some OTP, talking to Erlang wasn't weird either, and then reading Erlang code made a lot more sense (if still much uglier).
> Language concepts are easy to grasp
Sure, because everyone knows how to read procedural OO code. But, line for line, you'll get a lot further (and have fewer bugs) with a functional approach IMHO, even if you have to master concepts like triggering TCO (tail-call optimization).