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

D as a Better C

dlang.org

Post reply on HN
Print view View original

131–140 of 193 posts

Re: D as a Better C

#131

Post by dbaupp »

WalterBright wrote: post #85
millstone wrote: post #66

Earlier quoted context omitted.

Why does RAII require exceptions? RAII is routinely used in C++ with -fno-exceptions.

Because D code may sit in between code that throws and exception and code that handles it. Without EH support, the RAII destructor won't get called when the stack is unwound.

Isn't it generally undefined behaviour to have exceptions pass through code that isn't compiled with support for them? I.e. not running some destructors is the least of your worries if an exception hits C/-fno-exceptions/-betterC code.

Re: D as a Better C

#132

Post by omaranto »

logicallee wrote: post #124
TylerE wrote: post #98

Earlier quoted context omitted.

I sometimes feel Go went to far, as in the classic quote "Make it as simple as possible, but no simpler".

I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more. Toy example, a language that is simpler than possible: - If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible". The only example I know from Go: - Many people feel that the lack…

I'll repeat my usual comment about what I found annoying in Go:

It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago).

I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings.

I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings.

It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.

Re: D as a Better C

#133

Post by logicallee »

cstrahan wrote: post #86
logicallee wrote: post #62

Earlier quoted context omitted.

EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious. --- Thanks for your answers! So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I c…

I'll let the parent answer you (though I have similar sentiments as someone with language implementation experience, and FWIW, I have professional experience with Go, Ruby, JavaScript, Clojure, C#, and I've used Haskell, F#, and much more in my free time). I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty. ") than is often used i…

Thank you, this was excellent and very informative.

You weren't kidding about the lambda calculus definition!

https://en.wikipedia.org/wiki/Lambda_calculus#Formal_definit...

With that said, your comment seems quite technical, about the single point of simplicity. You don't talk much about Go at all, and although the other poster has also answered, I'd be curious in your answer as well (if you've worked with Go):

You've given a definition of simplicity (correcting mine). Did you find Go simple? What other thoughts did you have?

Re: D as a Better C

#134

Post by logicallee »

christophilus wrote: post #94
logicallee wrote: post #62

Earlier quoted context omitted.

EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious. --- Thanks for your answers! So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I c…

I feel a little bad writing up a full list of what I don't like about Go since I haven't used it enough to be as informed as I should be to write such a list. But... since you asked. No generics, error-handling obscuring flow of logic, dependency-management, the compiler complains about not-used vars and imports (which is great, except when you're prototyping) it should be togglable, it felt like I was producing a lo…

Hey, thanks! This is exactly what I was asking from you and the fact that these points remain in your mind despite being distant memories makes your reply particularly interesting.

(What I mean is if if you worked with Go every day you likely would not have the same perspective anymore.)

so thank you, perfect reply.

Re: D as a Better C

#135

Post by no_wizard »

innocenat wrote: post #68
no_wizard wrote: post #60

Earlier quoted context omitted.

This seems like it would be great for a list comprehension. I believe the main appeal to using comprehensions is that it speeds up the iteration process at run time so wouldn't a list comprehension be just as useful here if not more so then?. You could also use the functools and itertools library for really fast iterations, possibly, depending on what it is you are trying to achieve. If you are specifically talking l…

But would that be faster than numpy? numpy in typical setup would use SIMD or other math kernel (mkl, blas, etc).

Oh no of course not. Sorry I must have missed something here. I was speaking specifically of iterating over/with values. Numpy is optimized for this kind of thing. Though you can help yourself out and make sure you python code is also optimized by using comprehensions and itertools I would suppose

Re: D as a Better C

#136

Post by OoooooooO »

steveklabnik wrote: post #84
christophilus wrote: post #76

Earlier quoted context omitted.

I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change.…

Rust's major goals this year are around learnability and productivity; maybe come check it out again someday :)

Inferred lifetimes? A man can hope :).

Re: D as a Better C

#137

Post by steveklabnik »

OoooooooO wrote: post #136
steveklabnik wrote: post #84

Earlier quoted context omitted.

Rust's major goals this year are around learnability and productivity; maybe come check it out again someday :)

Inferred lifetimes? A man can hope :).

If it were always possible to infer all lifetimes, we'd do it. Unfortunately that's not the case.

There are a number of RFCs in the pipeline to help with lifetimes, including more elision. In no particular order:

https://github.com/rust-lang/rfcs/pull/2115

https://github.com/rust-lang/rfcs/pull/2094

https://github.com/rust-lang/rfcs/pull/2093

Re: D as a Better C

#138

Post by WalterBright »

dbaupp wrote: post #131
WalterBright wrote: post #85

Earlier quoted context omitted.

Because D code may sit in between code that throws and exception and code that handles it. Without EH support, the RAII destructor won't get called when the stack is unwound.

Isn't it generally undefined behaviour to have exceptions pass through code that isn't compiled with support for them? I.e. not running some destructors is the least of your worries if an exception hits C/-fno-exceptions/-betterC code.

Undefined behavior or not, implementations of languages in gcc and Windows tend to support it, even if the language itself does not. I consider it my job to make this work if at all practical, because users do not like ugly surprises.

I don't know how Rust's RAII deals with exceptions thrown by lower level code. If someone better acquainted with Rust could chime in here, it would be interesting.

Re: D as a Better C

#139

Post by flavio81 »

sythe2o0 wrote: post #51
pjmlp wrote: post #24

Earlier quoted context omitted.

You can easily get best of both worlds with Lisp derived languages.

It's been my understanding that Lisp and its relatives aren't designed to compete against C for speed either. Is this wrong?

"How to make Lisp go faster than C" (2006) http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pd...

And these figures aren't using the SBCL Lisp compiler which should currently be faster than the one cited.

You are correct, it wasn't designed to compete against C. And it has a garbage collector. But make the right choices and a compiler like SBCL can produce surprisingly "clean" (optimized) machine language code.

Re: D as a Better C

#140

Post by flavio81 »

rifung wrote: post #99
steinuil wrote: post #80

Earlier quoted context omitted.

Common Lisp has some very fast implementations (I think SBCL is the fastest) and it was designed to be a systems language. It can be optimized to be as fast as C.

> It can be optimized to be as fast as C Sorry if dumb question but how is this possible when it's garbage collected? Now I really feel like I need to learn a Lisp though.. Is there a certain Lisp you would recommend that's practical enough I'd use it for projects? Racket?

> Sorry if dumb question but how is this possible when it's garbage collected?

On a big or complex system you end up at least doing one or both or two things:

a. Having to manage many temporal (transient) objects in memory. Thus you end up doing some sort of garbage collector, either doing it yourself, or using the facilities provided by the languages, or a library.

b. Allocating fixed big blocks of memory (such as arrays, or doing a "malloc") and then using this block of memory as your storage area, which then you manage.

Usually on C programming you do (b), although you can also do (a), it is not so easy.

Usually on Common Lisp programming you do (a) very easily, but you can also do (b) by allocating an array and a bit more stuff. It is not difficult, really.

Post reply on HN