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

91–100 of 105 posts

Re: D for the Win

#91

Post by Abscissa »

ckaygusu wrote: post #27

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

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.

Re: D for the Win

#92

Post by CyberShadow »

beagle3 wrote: post #89

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, t…

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.

Re: D for the Win

#93

Post by eps »

falcolas wrote: post #9
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.

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.

Re: D for the Win

#94

Post by eco »

4ad wrote: post #83
eco wrote: post #81

Earlier quoted context omitted.

So subtyping automatically happens for all members of a struct? I'm not sure I like that but I guess I'd have to see how well it works in practice.

No, it only happens if you embed the type, a.i. the member is anonymous. http://golang.org/doc/effective_go.html#embedding http://golang.org/ref/spec#Struct_types Note that there's also interface embedding which is a different thing.

Ah, that makes a lot more sense. Thank you for explaining.

Re: D for the Win

#95

Post by coldtea »

voidlogic wrote: post #59
tomwilde wrote: post #21

Earlier quoted context omitted.

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.

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

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

Re: D for the Win

#97

Post by gldsmth »

anon4 wrote: post #88
pjmlp wrote: post #66

Earlier quoted context omitted.

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.

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.

And yum has always been much slower than apt-get.

Re: D for the Win

#98

Post by Roboprog »

valarauca1 wrote: post #50
waps wrote: post #36

Earlier quoted context omitted.

That's not true. Well it's true in a very narrow technical sense, but it's not really true. For example, the amount of housekeeping python does in order to execute a function call is staggering. It leads to all sorts of nice functionality, but nevertheless (plus C++/D does it almost entirely without housekeeping. Either no housekeeping, or 1 level of indirection). Python has so many indirections for a function call i…

Slightly unrelated, but this confused me. >1139 (each of which causes a program reschedule) I thought system calls were packaged into the binary itself and didn't necessarily cause a job to re-schedule. But just caused a context switch to take place, then execution continues. I thought re-scheduling only happened on interrupt, or a thread reaching a blocked stated. Could you clarify this for me, I'm interested.

About 10 years ago I remember prototyping some code on Linux with a perl script running a java program as a "coroutine" (er, service) via request/response pairs over a socket (not http). Then we moved it to AIX, where it was essentially unusable due to the lost time slice each time an IO sys call was made. On Linux, the remaining time slices were recovered and immediately used. On AIX, the time slice was simply lost until the next process scheduler tick. Ouch.

Re: D for the Win

#99

Post by buster »

pjmlp wrote: post #66
skizm wrote: post #38

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.

Are you sure it's not Java you mean? Everytimg i see a slow desktop app it's Java. What python apps do you mean? Sublime Text starts and runs very fast for me, for example. No complaints here and no difference to some other light weight editor like gedit.

Re: D for the Win

#100

Post by platform »

ckaygusu wrote: post #27

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

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.

Post reply on HN