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

141–150 of 193 posts

Re: D as a Better C

#141

Post by steinuil »

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?

> how is this possible when it's garbage collected?

Common Lisp lets you give "hints" to the garbage collector, so you end up with pretty much what you'd have in C but without the manual memory management.

> Is there a certain Lisp you would recommend that's practical enough I'd use it for projects?

Racket is very nice and comes with great documentation, a huge standard library and a very handy IDE. Clojure was hyped a lot so it has lots of libraries, which however might be of dubious quality or unmaintained by now, and it's on the JVM, which might or might not be a good thing for you. Common Lisp is very versatile and "pragmatic", but lacking in external libraries.

Re: D as a Better C

#142

Post by logicallee »

omaranto wrote: post #132
logicallee wrote: post #124

Earlier quoted context omitted.

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

thanks!

Re: D as a Better C

#143

Post by fasquoika »

WalterBright wrote: post #138
dbaupp wrote: post #131

Earlier quoted context omitted.

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.

If you mean lower level Rust code, there are no exceptions. Errors are just regular values encoded in the type system. If you're familiar with OCaml optionals and results, it's the same thing

Re: D as a Better C

#144

Post by steveklabnik »

WalterBright wrote: post #138
dbaupp wrote: post #131

Earlier quoted context omitted.

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.

> I don't know how Rust's RAII deals with exceptions thrown by lower level code.

Unwinding across an FFI boundary is considered undefined behavior.

https://doc.rust-lang.org/reference/behavior-considered-unde... last bullet point.

Re: D as a Better C

#145

Post by dbaupp »

fasquoika wrote: post #143
WalterBright wrote: post #138

Earlier quoted context omitted.

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.

If you mean lower level Rust code, there are no exceptions. Errors are just regular values encoded in the type system. If you're familiar with OCaml optionals and results, it's the same thing

There's a subtlety here: panics are exceptions, but they can be disabled without also disabling RAII.

Re: D as a Better C

#146

Post by dbaupp »

WalterBright wrote: post #138
dbaupp wrote: post #131

Earlier quoted context omitted.

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.

How does it work if an exception gets thrown through a C stack frame that has outstanding resources (for instance, pointers that are freed later in the frame)? Are you referring to manual SJLJ?

In any case, it seems like C manual destruction has exactly the same problems as with RAII, because fundamentally the issue is passing exceptions through something that doesn't understand it, rather than with RAII.

Re: D as a Better C

#147

Post by dbaupp »

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

Inferring lifetimes from the implementation of a function won't happen for the same reason that inferring types won't happen: it is really nice for the signature of a function to not automatically be changed if the body is changed, instead programmers should be told when they might be breaking their users.

However, the compiler could (and did, I believe) run inference and suggest a fix that the programmer can explicitly include.

Re: D as a Better C

#148

Post by burntsushi »

omaranto wrote: post #132
logicallee wrote: post #124

Earlier quoted context omitted.

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

You can actually dynamically generate struct types at runtime with the `reflect` package.[1] That might work for you. Not that I'm saying this is an ideal solution, I'm just giving you another option to evaluate. :-) (I suspect I'd sooner choose "serialize to a string" if I were in your shoes.)

[1] - https://golang.org/pkg/reflect/#StructOf

Re: D as a Better C

#149

Post by saghm »

flavio81 wrote: post #139
sythe2o0 wrote: post #51

Earlier quoted context omitted.

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

C compilers have presumably gotten faster since then as well, of course

Re: D as a Better C

#150

Post by WalterBright »

steveklabnik wrote: post #144
WalterBright wrote: post #138

Earlier quoted context omitted.

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.

> I don't know how Rust's RAII deals with exceptions thrown by lower level code. Unwinding across an FFI boundary is considered undefined behavior. https://doc.rust-lang.org/reference/behavior-considered-unde... last bullet point.

That's exactly what I wanted to know. Thanks!

Full D is compatible with foreign exceptions and unwinding. I'll see about making D as Better C also compatible, but I suppose Rust's precedent makes it acceptable to not handle it.

Post reply on HN