7 ms·
Well all of those solve concurrency and scale problems in the VM and build a language on the top. I think you're quite mistaken here. These languages solve con
by gngeal 13y ago
Well all of those solve concurrency and scale problems in the VM and build a language on the top.
I think you're quite mistaken here. These languages solve concurrency at the language semantics level, and then, some of them implement the semantics in a VM, but the VM (in case of Erlang, no Go implementation in use has one) is a tangential issue. To say that these language "solve concurrency problem in the VM" simply doesn't make sense. Languages are languages, they are not implementations.
C++ is just a language in which you are free to build those abstractions into in any form you choose.
Well, there's Turing completeness, and then, there's actual usability. Consider transactional extensions, for example. Haskell gives you a type system for that. In Lisp, you could achieve the same using a code-walking macro library. C++ gives you...what, pattern-matching based template metaprogramming? Ugh! The "language" for that, while Turing-complete, isn't even identical to the one used for run-time code. I've seen a factorial written that way. I don't want to imagine how more complex code like that must look like in C++. Even D is better at that!
If that wasn't possible, then our SQL server installation (all c++) wouldn't quite happily run a single process on each of our 48-core nodes with 128Gb of RAM, nor would it cluster and replicate amongst all 8 of them and deliver 10,000 queries a second whilst yawning.
I didn't say it's impossible in C++. It's just that it's masochistic, that's all. You could easily argue along the same lines that COBOL is a well-designed language because millions of applications have been written in it that power the reliable day-to-day operation of banks you've invested your money into. Yes, they have been written, but at what human cost?
Rob Pike is pretty cool but has blinkers on as he's a captive research executive rather than someone with dirty hands on the ground in some enterprise outfit.
"Captive research executive?" What does that even mean? He certainly has more than enough of his share of dirty hand, while continuing doing so even today, and I won't even comment on that "enterprise outfit" nonsense.
- csmuk 13y agoWell erlang and go do have a virtual machine concept because they are basically flip off great big coroutine schedulers at the end of the day (or are they OS's?). Go and erlang give nifty coroutine initialisation and communication stuff - that is all with language constructs on top. c++ has none so you're free to choose depending on what you need to do. It's a good general purpose language. Usability is perfectly fine when you consider C++11 and boost for example. They both can the useful abstractions. Transactional code is pretty easy. You can do it fine with closures you know, elegantly without resorting to metaprogramming monstrosities. Metaprogramming is a PITA in large systems from a maintenance perspective. Its not as masochistic as finding erlang developers. Nor is it all that masochistic actually if you consider the good old CSP paper and apply that to your code. The "enterprise outfit" nonsense is us large businesses who have a vacuum of quality staff because people would rather work at google (for a lesser salary I'll add) where they can take on menial duties and be kept away from the competition. We build really big, complicated systems like you've never seen with "inferior" tools, low quality staff, very little CPU time and not a mention of erlang or Go. In fact some of our shit is handling 1000 requests a second on VB6+DCOM. Go figure...