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

51–60 of 105 posts

Re: D for the Win

#51

Post by awakened »

blt wrote: post #45
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…

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

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.

Re: D for the Win

#52

Post by Gracana »

jacques_chester wrote: post #11
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.

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

I don't do anything quite so tedious in my Go-based webserver projects. For functions that can return errors that I don't have a way to recover from (db calls, for example), I use a simple rapper function that automatically logs errors and panics. That doesn't seem to me like much of a source of difficulty or complexity.

Re: D for the Win

#53

Post by p0nce »

4ad wrote: post #26
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.

Can you give a code example in Go?

Re: D for the Win

#54

Post by snth »

thinkpad20 wrote: post #48
blt wrote: post #45

Earlier quoted context omitted.

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

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

Yes.

Re: D for the Win

#55

Post by p0nce »

waps wrote: post #36
falcolas wrote: post #25

Earlier quoted context omitted.

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

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…

> The point here is that things that are io-bound (esp. memory bound) in python may be cpu-bound in C++ or D, simply because you avoid doing all the indirections that higher level languages do.

I think you mean the reverse: "things that are cpu-bound (esp. memory bound) in python may be io-bound in C++ or D".

Re: D for the Win

#56

Post by cjslep »

p0nce wrote: post #53
4ad wrote: post #26

Earlier quoted context omitted.

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?

Quick example on the playground, if this is what you were asking about: http://play.golang.org/p/zShJKp0t3n

Re: D for the Win

#57

Post by quatrevingts »

simias wrote: post #49
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."

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.

Re: D for the Win

#58

Post by srean »

jerf wrote: post #29
tomwilde wrote: post #20

Earlier quoted context omitted.

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

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.

Re: D for the Win

#59

Post by voidlogic »

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.

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

Re: D for the Win

#60

Post by angersock »

blt wrote: post #45
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…

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

V8 + C++ has served me pretty well; C and Lua likewise.
Post reply on HN