Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D for the Win

tomerfiliba.com

Post reply on HN
Print view View original

21–30 of 105 posts

Re: D for the Win

#21

Post by tomwilde »

agumonkey wrote: post #12
tomwilde wrote: post #8

Earlier quoted context omitted.

Hail Wikipedia for it is the source of all truth. http://en.wikipedia.org/wiki/System_programming_language

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.

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.

Re: D for the Win

#22

Post by loxs »

tomwilde wrote: post #10
lclarkmichalek wrote: post #2

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.

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.

Re: D for the Win

#23

Post by copx »

tomwilde wrote: post #20
valarauca1 wrote: post #14

Earlier quoted context omitted.

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 wro…

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.

>Unless you're a mathematician or theoretical physicist [...]

..or Dwarf Fortress player ;)

Re: D for the Win

#24

Post by 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."

Re: D for the Win

#25

Post by falcolas »

tomwilde wrote: post #20
valarauca1 wrote: post #14

Earlier quoted context omitted.

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 wro…

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.

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

If their system was truly just IO bound, then moving to D wouldn't help them.

Re: D for the Win

#26

Post by 4ad »

charlieflowers wrote: post #24

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

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.

Re: D for the Win

#27

Post by 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/

Re: D for the Win

#28

Post by jeremiep »

charlieflowers wrote: post #24

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

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.

Re: D for the Win

#29

Post by jerf »

tomwilde wrote: post #20
valarauca1 wrote: post #14

Earlier quoted context omitted.

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 wro…

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.

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

Re: D for the Win

#30

Post by agumonkey »

tomwilde wrote: post #21
agumonkey wrote: post #12

Earlier quoted context omitted.

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.

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.

Agreed, I meant Erlang for its use. It's hard to be more different than Erlang in implementation :)
Post reply on HN