▲ 119 points
back
102 comments
This article is full of D hype and so so so far away from reality.
Alright, some basics; Everything that has to access persistent information frequently is bound by disk/network/whatever IO, and web programming is no different. The reason why languages such as Python and Ruby are very viable options for this task is they are quite a lot abstracted away from bare metal to hasten the development process. The wait for IO is quite long compared to logic execution, so even though we are executing more instructions to get the same job done, the resulting overhead isn't very significant.
CPU-Bound computations are most definitely will execute faster in statically compiled languages such as C/C++, D, golang relative to interpreted languages but in the context of web programming this is not the case. Even though; if rendering HTML is such a big pain in the ass that it is slowing you down a lot you can always use a library that is implemented in a language that's fast, say C, and use its wrappings in your scripting language of choice. I am not sure about to what extent this is supported in other languages but I know you can do this in Python, heck you can do this in golang, even though it is a relatively new language [1]. I wonder how the author will move to C10M world by optimizing the wrong thing.
"Write in Python/Ruby/whatever and optimize the slow parts in C" echoes around the programming community endlessly, but I wonder how many people have actually done it. It's kind of hard.
- Automated tools like SWIG have weird limitations and are complex.
- Binding to a C library manually means you have to wrangle the data from a heapy, pointery dynamic language world into whatever format the C libary wants.
- Writing the C code to operate on the dynamic language's objects directly means you have to learn how the language works under the hood, and your C code will never be useful in any other language.
- Python and Ruby both have a GIL that prevents you from using multithreading to its full potential.
- The way dynamic languages lay out objects in memory causes an inherent slowness everywhere. Your app's slowness may well be a death of a thousand cuts, with no easily optimized hot spot.
I think anyone who has actually worked on a project built this way will appreciate the idea of a compiled language that is closer to the expressiveness of Python.
This isn't an assertion, just a question: isn't that exactly the reason why Cython exists, both to more easily facilitate the connection between Python and C, and to create essentially "a compiled language that is closer to the expressiveness of Python"?
I have done it a lot. However, I optimized the slow parts in C++ with Boost Python, not C. It is not hard and it works great and is well documented.
Writing your application in Python/Ruby/Whatever and optimize the slow parts in C sounds like a good way to have the worst of both worlds: the lack of efficiency of the interpreted language combined with long development time, difficulty porting, buffer overruns and segfaults of C programming.
V8 + C++ has served me pretty well; C and Lua likewise.
So you're arguing that it's "hype" because while it's all true, it doesn't matter if something is I/O-bound. Even if you're right, a server farm that uses 5x fewer CPU cycles is saving a lot of electrical power. 5x is of course a very conservative estimate.
I remember this argument being made in favor of Java (over native compiled code) and there it at least had some credibility. Python and Ruby are far, far slower.
Certainly, the only credible/really important argument in favor of Python (or whatever alternative language you want to suggest) is programmer productivity. Get the feature out the door, and then when it's making money figure out how to optimize it. If I were going to pick on anything in the article, it's the long line of "}"s in the HTML generation example. One of the best arguments in favor of Python's indentation I've ever seen.
All this theoretical bottleneck debate, but it really boils down to this:
If you're writing frequently-run code in Python/Ruby/JS, or any such highly-dynamic-at-runtime language, then chances are very good that your CPU, memory access, CPU cache, etc are going to be part of your bottleneck.
Write in something that doesn't effectively turn an i7 into a Pentium 4 (and be sure to use efficient memory management techniques), and your chances of main bottlenecks being IO-only are much better.
The belief that IO is the only bottleneck is a self-defeating prophecy. It leads to code and techniques that cause CPU to become a bottleneck once again. Don't forget Wirth's Law.
Alright, some basics:
having data "on disk/network/whatever IO" does not mean that you application will be bound by I/O.
If you care for your application performance you will quickly learn how to cache data (and that means figuring out algorithmic space and execution complexity). You will then, quickly care about how well your chosen programming language, libs and OS deal with memory allocations, instruction parallelization, on-die cache optimization, and so on.
And finally after all that, you will still care about I/O so you will figure out how to optmize your I/O access to benefit from hardware assumptions of a particular set of storage/network devices
Then you will look back at your solution and realize that your "use its wrappings in your scripting language of choice" is nothing more than a wrapper around another language. And then you will be wondering if it was worth starting with a different tool.
would you write Bitcoin in python?
People endlessly parroting the "IO bound" line never post numbers. As far as I've seen it's just not true. Things like web apps are routinely bottle-necked by execution speed, not disk or network.
Well, my experience is that web apps are most often bottlenecked by the database speed, because almost any other problem can be solved with money (and not even much of it).
I've seen databases bottleneck on lots of different resources, even some virtual ones (unexpected serializing). But I'm very suspicious of people claiming that one must write webapps in low level languages "because speed". (And yes, I know there exist problems out there where this is true, the same way that there exist people out there that've won the lottery.)
I know this is an inevitable comment on any article that calls any software slow, but: "~500 requests/sec" using ten servers? Python may be slow, but I would be very suprised if it can't do 50req/second.
This doesn't pass the smell test for me either. I'm running a Python Django server with a primarily write load on an EC2 small instance, and easily exceeding 50 requests per second, with very low load on the box.
It all depends on what a request is. The req/sec metric alone makes no sense.
As I read it that's one AWS server of unknown size serving ~500rps of an application of unknown complexity. Tripled when using PyPy (whatever that is).
Maybe a very small instance serving something fairly complex?
Yep, I could readily point to my Erlang application that can serve thousands of requests per second, doing real work. While simultaneously handling 10k+ websocket connections. All that on a single machine (16G RAM, 8 cores).
Does that mean that Erlang is the best? Of course not! It only means that Erlang was specifically designed for this sole use case, which only happens to encompass the whole "web" thingie.
It would be an overkill to use Erlang for single-threaded software that requires number crunching speed or for any kind of system scripting. Comparing Erlang to D or Python is stupid. As is (IMHO) using any of the latter for massively parallel servers.
How complex? In one second a modern processor can do ~1 billion operations (ish, some are faster, some are slower, sometimes multiple are done in the same clock tick). Even if its slow, core2 architecture.
This means they have the time for about ~200 million instructions per request (Ignoring internal disk I/O, or network I/O).
That amount of work is insane!
:.:.:
I want to say their doing something fundamentally wrong. And it has nothing to do with their language.
Yeah, I read it as 500 rps per instance, which is not unreasonable for AWS.
I have a lot of respect for Walter and for D. But having not enough time to try everything, I'm leaning towards doing a project in Nimrod[0] when I have the time.
D people who have some knowledge of Nimrod (or Nimrod people who have good knowledge of D) - where do you think D outdoes Nimrod? D is more mature, with a larger community, and a recognized brand - granted, and these are NOT trivial things -- in practice, they usually matter more than any specific feature. Yet, my question in this case IS about language/environment features.
As far as I can tell, all the examples in the article can be done at least as easily/tersely/nicely, if not more so, in Nimrod.
I don't know much Nimrod, but here's an article I wrote about a D package I also wrote, in which a number of D features have come together in an especially pleasing way:
http://blog.thecybershadow.net/2014/03/21/functional-image-p...
I'd be interested to know if the same expressiveness is possible in other languages without sacrificing speed.
> go (Google must be joking if they actually consider it for system programming)
I am curious what led the author to be dismissive of Go in such a strongly negative manner. Lack of generics? Disagree with certain language design choices? Too many cuddly caricatures of gophers?
I need some clarifications. I think there are two definitions of systems being used here :
- low-level hardware control (c,D,...) implicitely concurrent
- explicitely concurrent higher level components (go, erlang maybe)Hail Wikipedia for it is the source of all truth.
I think "erlang definitely" is more accurate. That's is erlang's domain and it does it better than any other solutions right now AFAIK.
Go hasn't been intended for "systems programming" for quite a while. It is a general purpose language.
Those properties are not mutually exclusive.
Nevertheless, many of the design decisions make sense in that context.
For example: the difference in initialisation of simple data types vs slices and maps. For an application programmer these are weird inconsistencies. But they make sense in the domain.
Or the way error handling works. Very tedious to have to do-check, do-check, and not be able to have automatic upwards delegation. But in system programming it's about robustness, not ease of development. A database server can't just restart if it has a file or memory problem. There needs to be a solution and it needs to be immediately next to the problem.
"The strange alias _curr this is a lovely feature of D known as subtyping. It basically means that any property that doesn't exist at the struct's scope will we forwarded to _curr, e.g., when I write myCtx.foo and myCtx has no member named foo, the code is rewritten as myCtx._curr.foo."
That's a great feature. I don't see many languages investing enough focus into this kind of "delegation wiring."
Yes. It makes it easy to do things like, for example, create your own "int" type without having to duplicate all the behaviors of int. Just override the behaviors you'd like to change, then forward the rest to the wrapped int field.
I love this feature! It's also recursive, you can have the following:
struct A { int a; alias a this; } struct B { A a; alias a this; } struct C { B b; alias b this; }
static assert(C(42) == 42);
Combined with D's support for compile-time protocols, this allows for some very expressive, powerful and lighting fast code.
If I understand correctly you can achieve something similar in many other languages by implementing a dereference operator. You'll have to be explicit when you use the object though (o.foo vs. o->foo for instance). I tend to prefer these kinds of explicit constructs over compiler magic, but it's a matter of taste really.
The built-in version has the big advantage that it integrates well with tools: you can statically determine the target of the reference and jump to it.
Go has something similar, but it's implicit with type embedding, you don't have to explicitly alias anything; also the Plan 9 C dialect has it too (and was used extensively in the Go runtime until recently). One nice idiom in Plan 9 is to be able to call Lock on various structures that embed a lock.
Can you give a code example in Go?
Lua metatables do that.
Why did Walter choose to not open source the compiler from the beginning? I would be willing to bet that it would hold the position that Ruby/Python currently hold if he had made that choice. The ability to apt-get/yum to install a language on a cheap linux server would have done wonders for its adoption, especially in the middle of the rise of linux and the web.
Perhaps that would have helped with adoption. I'm not all that convinced that would have really tipped the scales. It's been 5 years since it was open sourced and there have been over a hundred contributors but it's still only fairly recently gotten to the point where development is more about mundane bug fixes instead of implementing huge, unfinished parts of the language and blocker bugs that make the language hard to use. Open sourcing sooner would have given it a head start but even then, I don't think D would have been ready for heavy use in the middle of the rise of linux and the web.
Here's what Walter said at the time when asked why it took so long:
I've been intending to for a while, it took a while for me
to clean it up, check all the licenses, and get it into a
presentable form.
Essentially, it's pretty obvious that the world has changed,
and closed source is no longer acceptable for a mainstream
product that people will be relying on. Open source is the
future, and it's past time for dmd to join the party!The D front end is not only open sourced now, it is Boost licensed, which is the most open of the open source licenses.
Over in the D community we're very proud of our use of the Boost license.
I feel like D's lack of adoption was mostly due to issues around the way things transpired, specifically the closed-source compiler and of course the big mess with the standard library. Otherwise it was well-placed and well-timed, just ill-executed.
I think it's a good point. I can't speak for Walter, but I can say I've fostered openness ever since joining D development and we're both glad things are now in the right place.
I definitely agree that D is better from many and all the hype of the day gos to Go, not D. I really have issues with the Go syntax though - it's really not intuitive, some things are just made different just for the sake of being different, syntax is all over the place. I think Rust is way more elegant, unfortunately, it doesn't get as much hype as it deserves compared to Go.
What makes Go's syntax that unintuitive to you?
Go's syntax is really easy to most programmers who is willing to learn. It's probably just 1 days work to pick it up. It's very similar to Swift's syntax in many aspects, and I don't hear anyone complaining Swift's syntax is not intuitive and just for the sake of being different.
Perhaps instead of just claiming you can give us some examples on "syntax is all over the place" part?
> syntax is really easy to most programmers who is willing to learn
This is exactly how this sentence should look like, no need for any language at the beginning. While syntax does matter (and I only recently arrived at this conclusion) its "intuitiveness" or "similarity" is utterly unimportant. You either are a "real programmer" and have no problem picking up different syntaxes and semantics, or you're not. That's all there is to it.
Python a D have totally different use cases. Just because you can do something with Python doesn't mean you should.
Tell that to all those guys writing desktop utilities in Python slow as molasses.
Every time I get some GNU/Linux GUI utility running very very slow and check the code, it is Python under the hood.
> The code must compile
If the code compiles, it must run without error?
If it compiles, it must run without several entire classes of errors.