5 ms·

It seems (to me) like if statically typed, compiled languages are your bag, and you want to create web applications, Go is the right choice. I recently finishe

It seems (to me) like if statically typed, compiled languages are your bag, and you want to create web applications, Go is the right choice. I recently finished the MVP for a weekend side project in Go, and I had a lot of fun (coming from a Node.js/Ruby background). I finally understood the draw of static typing (the compiler saved me a ton of time), but I didn't feel limited by the type system, nor encumbered by the syntax. The performance boost was also quite nice (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison). It's hard to imagine needing even more performance, since the Node version still would have been "good enough", and needing it so badly that it'd be worth muddling through C++ to get it (especially given the stark contrast of managing concurrency in Go vs C++).

copperx 12y ago
Why Go and not Haskell?
- notduncansmith 12y ago
  I don't know much about Haskell but I suppose it would work as well. I just took an example of a statically typed, compiled language with which I'm familiar and which seems to have a decent amount of momentum.
waps 12y ago
> (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison) You're probably not doing it right. You should see a factor 10 or more difference, without optimization. Why ? Because any variable lookup in a dynamic language is always at least O(log N), and the mere fact that it needs looking up at all costs you a lot. So every single statement and expression of a compiled language is going to blow the socks off any interpreted language.
- flohofwoe 12y ago
  I'm not a fan of dynamic typing, nor am I a compiler expert, but I'm pretty sure this is wrong for (at least) JS engines, which are JIT-compiled down to static machine code and which use automatic type deduction. Only when types on existing variables change all the time it would be a performance problem. If JS code is 10x slower then it's native equivalent it's probably because some slow-path is hit (too many objects created and destroyed, burdening the garbage collector, or too "dynamic code" which causes many recompiles at runtime, or code not to be compiled at all but running through the interpreter..).
- notduncansmith 12y ago
  Are you saying I should have seen more of a difference than I actually did? Maybe I was doing it wrong, but I said it makes Node's performance look "mediocre" rather than "bad" because Node is still pretty damn fast compared to the rest of the field (also, I like Node.js a lot and use it daily). Also, this was by no means a scientific benchmark - it wasn't a comparison of raw ops/sec, or anything like that: just the requests/sec on a few different routes (pretty close as far as implementation logic). I'm sure the chosen frameworks played into the results as well, but I'd consider that a more pragmatic benchmark anyways.
  - waps 12y ago
    This is the sort of improvement you'd see if your program was fully IO bound.

copperx 12y ago

Why Go and not Haskell?

notduncansmith 12y ago
I don't know much about Haskell but I suppose it would work as well. I just took an example of a statically typed, compiled language with which I'm familiar and which seems to have a decent amount of momentum.

waps 12y ago

> (not even optimized, and it still made the equivalent Node implementation's performance look mediocre by comparison) You're probably not doing it right. You should see a factor 10 or more difference, without optimization. Why ? Because any variable lookup in a dynamic language is always at least O(log N), and the mere fact that it needs looking up at all costs you a lot. So every single statement and expression of a compiled language is going to blow the socks off any interpreted language.

flohofwoe 12y ago
I'm not a fan of dynamic typing, nor am I a compiler expert, but I'm pretty sure this is wrong for (at least) JS engines, which are JIT-compiled down to static machine code and which use automatic type deduction. Only when types on existing variables change all the time it would be a performance problem. If JS code is 10x slower then it's native equivalent it's probably because some slow-path is hit (too many objects created and destroyed, burdening the garbage collector, or too "dynamic code" which causes many recompiles at runtime, or code not to be compiled at all but running through the interpreter..).
notduncansmith 12y ago
Are you saying I should have seen more of a difference than I actually did? Maybe I was doing it wrong, but I said it makes Node's performance look "mediocre" rather than "bad" because Node is still pretty damn fast compared to the rest of the field (also, I like Node.js a lot and use it daily). Also, this was by no means a scientific benchmark - it wasn't a comparison of raw ops/sec, or anything like that: just the requests/sec on a few different routes (pretty close as far as implementation logic). I'm sure the chosen frameworks played into the results as well, but I'd consider that a more pragmatic benchmark anyways.
- waps 12y ago
  This is the sort of improvement you'd see if your program was fully IO bound.