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

11–20 of 105 posts

Re: D for the Win

#11

Post by jacques_chester »

Ironballs wrote: post #5
cjslep wrote: post #3

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

Go hasn't been intended for "systems programming" for quite a while. It is a general purpose language.

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.

Re: D for the Win

#12

Post by agumonkey »

tomwilde wrote: post #8
agumonkey wrote: post #6

Earlier quoted context omitted.

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

Re: D for the Win

#13

Post by bkeroack »

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?

Yeah, I read it as 500 rps per instance, which is not unreasonable for AWS.

Re: D for the Win

#14

Post by valarauca1 »

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?

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.

Re: D for the Win

#15

Post by seabee »

tomwilde wrote: post #7
Ironballs wrote: post #5

Earlier quoted context omitted.

Go hasn't been intended for "systems programming" for quite a while. It is a general purpose language.

Those properties are not mutually exclusive.

C++ is the counterexample in nearly all such cases, for better or worse!

Re: D for the Win

#16

Post by codygman »

agumonkey wrote: post #6
cjslep wrote: post #3

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

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.

Re: D for the Win

#17

Post by tachyonbeam »

valarauca1 wrote: post #14
tomwilde wrote: post #10

Earlier quoted context omitted.

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?

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…

The i7 can dispatch 4 instructions per cycle. In practice, I find it can realistically execute about 2 per cycle. So at 2GHz, that's closer to 4 billion instructions per second, or ~800M instructions per request as per your calculation.

The slowness of their system can probably be blamed on slow database access, or some kind of initialization cost they're paying for every request (i.e.: calling into a binary like in the old CGI days, initializing the Python VM every time).

Re: D for the Win

#18

Post by agumonkey »

codygman wrote: post #16
agumonkey wrote: post #6

Earlier quoted context omitted.

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)

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.

So Go 'system' is the cybernetics/communication one.

Re: D for the Win

#19

Post by valarauca1 »

tachyonbeam wrote: post #17
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…

The i7 can dispatch 4 instructions per cycle. In practice, I find it can realistically execute about 2 per cycle. So at 2GHz, that's closer to 4 billion instructions per second, or ~800M instructions per request as per your calculation. The slowness of their system can probably be blamed on slow database access, or some kind of initialization cost they're paying for every request (i.e.: calling into a binary like in…

Like I said something fundamentally wrong. With their approach.

Un-Indexed databases, databases far away from front end servers (in terms of network topography), or weird VM things with python.

Something is bad, and if changing languages solved their problems, they are just sweeping an issue under the rug. It'll hit them in the face later, and harder. Be it developer knowledge, or architectural choices. It'll surface again, they'll (hopefully) be large, and the problem will sting harder too.

Re: D for the Win

#20

Post by tomwilde »

valarauca1 wrote: post #14
tomwilde wrote: post #10

Earlier quoted context omitted.

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?

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.

Post reply on HN