
D for the Win - ingve
http://tomerfiliba.com/blog/dlang/
======
ckaygusu
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.

[1] [http://gopy.qur.me/extensions/](http://gopy.qur.me/extensions/)

~~~
blt
"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.

~~~
thinkpad20
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"?

~~~
snth
Yes.

------
lclarkmichalek
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.

~~~
tomwilde
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?

~~~
valarauca1
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.

~~~
tomwilde
Unless you're a mathematician or theoretical physicist the gross of your CPU
time will be spent waiting for IO. Reading from disk, writing to the network,
synchronizing, etc.

They're probably just aggregating 2 or 3 APIs, maybe hitting a database and
then adding it all together.

That description can apply to almost any and all web applications and is
inherently IO-bound.

~~~
jerf
"the gross of your CPU time will be spent waiting for IO. Reading from disk,
writing to the network, synchronizing, etc."

People just sort of chant this, yet... if you upgrade from Python to something
on the faster end of the spectrum, like D, you are _very likely_ to still
experience significant speed up, in my experience, even if you don't touch IO
access patterns. You're even more likely to see a real latency decrease. And
that's before we start actually multithreading or anything.

For all the work done on them in the past few years, the dynamic languages
remain _slow, slow, slow_.

I think people often don't look at the math very carefully... if you do, say,
half a dozen DB queries each less than 1ms, but your entire web page is
clocking in at 50 or 100ms of rendering, all numbers that are very easy to see
in real life (such as my own personal Django blog, where I've carefully
counted each DB access and carefully indexed all of them), you are _not_
actually spending all your time in IO wait.

One of the worst cases for a dynamic language is crawling a large object
hierarchy, obtaining lots of tiny objects from them, and then merging them
together in the end. You pay and pay and pay for the constant new object
creation, reference count management, endless resolutions of methods, and all
the other things dynamic languages are doing over and over and over (even when
JITed).

Now, guess what "rendering a template" looks like internally.

Oh, and don't forget, if the DB returns in 1ms but your language reports the
query took 5ms, you can't count the time it took your dynamic language to
handle what came back from the DB as IO wait!

(I have to admit, I'm _really_ done with the dynamic languages. It was fun
when the megahertz went up every year, but now it's like wearing 20lb concrete
shoes and trying to pretend that's not a problem, it doesn't affect my
performance at all... and the 20lb is already after we cut it down from 40lb
with all the JITs and stuff, which rhetoric notwithstanding simply _do not_
produce anything like C-like performance in practice.)

~~~
srean
I agree with you. There is a structural problem with the view put forward by
the parent. If the validity of a view relies on I/O being the bottleneck, it
encourages coding practices among that keep the implementation I/O
bottlenecked. Once you already believe such a thing to be true you have little
motivation to challenge or overcome it.

It is not the case that I/O bottlenecks can always be overcome, but it can
often be, depending on circumstances, provided one tries of course.

------
beagle3
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.

[0] [http://nimrod-lang.org/](http://nimrod-lang.org/)

~~~
CyberShadow
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...](http://blog.thecybershadow.net/2014/03/21/functional-image-
processing-in-d/)

I'd be interested to know if the same expressiveness is possible in other
languages without sacrificing speed.

------
cjslep
> 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?

~~~
agumonkey
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)

~~~
tomwilde
Hail Wikipedia for it is the source of all truth.

[http://en.wikipedia.org/wiki/System_programming_language](http://en.wikipedia.org/wiki/System_programming_language)

~~~
agumonkey
C and Go both classified as high level system language, but I can't deny the
fact that C allows for finer control over machine usage so it's hard to put Go
in the same bag.

~~~
tomwilde
You are right yet Go is much closer to C than Erlang in syntax, type system
and memory-representation. Go is so close to C in fact, that its compiler is a
modified C compiler.

Therefore I'd bundle it with C and D rather than Erlang.

~~~
voidlogic
I think of Go as "C++", but as brought to you by the guys who made C, with
tasty sprinkles from CSP and Python.

~~~
coldtea
It's mostly Java from the people who made C, but didn't learn much from their
C design mistakes.

~~~
voidlogic
Ridiculous. Go's lack of verbose classes and lack of inheritance, pass
everything by value, the existence of pointers, first class concurrency
primitives, compile to binary / no interpretation/JIT, lack of a VM, built in
unit testing/benching, fast compile times, memory usage, easy C integration,
etc etc all make it very different from Java.

I've been writing Go full-time for over 2 years and used to write mostly
Java/C#, so I should know. When I started with Go and ported many of my
personal Java applications, they all were much more maintainable and straight
forward in Go.

Of course C had always been favorite language, and all I ever really wanted
was a "modern" C, so I am probably biased.

------
charlieflowers
"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."

~~~
simias
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.

~~~
quatrevingts
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.

------
saosebastiao
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.

~~~
eco
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!

------
kolev
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.

~~~
cnbuff410
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?

~~~
klibertp
> 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.

~~~
kolev
It is important - we're not just robots doing work to eat and have where to
live, we need to enjoy what we do and having pleasant syntax is what made many
fall in love with Ruby. Let's not pretend syntax doesn't matter - it does,
indeed, otherwise there wouldn't be Scala today either!

~~~
WalterBright
I agree, syntax does matter. A program should look good on the page. It's much
more satisfying to write code in a language that you can craft in an eye-
pleasing manner.

------
skizm
Python a D have totally different use cases. Just because you can do something
with Python doesn't mean you should.

~~~
pjmlp
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.

~~~
anon4
Please, it's really unfair to single out Linux GUI tools. Basic system
utilities are also written in python, like yum, which masks its slowness by
doing network access on each invocation and makes you think that's why it's so
slow.

~~~
danieldk
...and it it used to be far worse. In the old days it was spending most of its
time parsing metadata, until the C metadata parser introduced, and later
sqlite databases were added to repositories as an alternative for the XML
metadata.

I even backported the C metadata parser to CentOS 3 and 4, because it was a
whole different experience altogether:

[http://lists.centos.org/pipermail/centos-
devel/2007-May/0017...](http://lists.centos.org/pipermail/centos-
devel/2007-May/001732.html)

------
smegel
> The code must compile

If the code compiles, it must run without error?

~~~
Abscissa
If it compiles, it must run without several entire classes of errors.

