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

151–160 of 193 posts

Re: D as a Better C

#151

Post by steveklabnik »

WalterBright wrote: post #150
steveklabnik wrote: post #144

Earlier quoted context omitted.

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

No problem!

This isn't my super strong area of expertise, but don't you have to specify how the unwinding works? I believe this is part of the reason why Rust punted; you'd have to specify exactly what kind is supported. (Rust uses libunwind for panics, incidentally.)

Re: D as a Better C

#152

Post by norswap »

camus2 wrote: post #22
norswap wrote: post #4

Earlier quoted context omitted.

D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. From what I can gather, it succeeded pretty well at that, lacking maybe some hype. The recent open-sourcing of the toolchain might help though.

> D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. I don't believe that one second, every language strives to be popular and reach large adoption, since more developers == more maintainers == bigger ecosystem == more reach into enterprise.

Of course, but while still being itself.

Just like you would like to be personally successful, but won't sell your soul or betray your principles for it.

Re: D as a Better C

#153

Post by WalterBright »

steveklabnik wrote: post #151
WalterBright wrote: post #150

Earlier quoted context omitted.

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.

No problem! This isn't my super strong area of expertise, but don't you have to specify how the unwinding works? I believe this is part of the reason why Rust punted; you'd have to specify exactly what kind is supported. (Rust uses libunwind for panics, incidentally.)

The how is handled by providing a language-specific "personality" function in the generated exception tables. The D runtime library has one for D. But with D as Better C, I'd have to find a way to make the C personality function work for D.

Re: D as a Better C

#154

Post by bloaf »

camus2 wrote: post #22
norswap wrote: post #4

Earlier quoted context omitted.

D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. From what I can gather, it succeeded pretty well at that, lacking maybe some hype. The recent open-sourcing of the toolchain might help though.

> D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. I don't believe that one second, every language strives to be popular and reach large adoption, since more developers == more maintainers == bigger ecosystem == more reach into enterprise.

The HolyC language was mandated by God and therefore needs none of those things.

Re: D as a Better C

#155

Post by steveklabnik »

WalterBright wrote: post #153
steveklabnik wrote: post #151

Earlier quoted context omitted.

No problem! This isn't my super strong area of expertise, but don't you have to specify how the unwinding works? I believe this is part of the reason why Rust punted; you'd have to specify exactly what kind is supported. (Rust uses libunwind for panics, incidentally.)

The how is handled by providing a language-specific "personality" function in the generated exception tables. The D runtime library has one for D. But with D as Better C, I'd have to find a way to make the C personality function work for D.

Ah right, makes sense. Thanks :)

Re: D as a Better C

#156

Post by ben-schaaf »

christophilus wrote: post #72
mhh__ wrote: post #27

Earlier quoted context omitted.

The D standard library is generally designed to generic code: you often aren't supposed to see the type returned by a function. Also, you can use auto too + Template constraints would help you here.

I understand. That's why I mention it as one of the downsides of D. It's probably subjective, but I like to see the types of function signatures. It serves as documentation, and makes it easier for me to say, "What does this function return, and what can I do with it?"

The problem is, with a lot of the range code in D you can't actually specify the return type since it's an internal struct or similar.

Seeing MapResult!R map(R, alias fn)(R range) makes it seem like MapResult is a thing you can reference/use. But it's an internal struct, so it's neither accessible not documented. That's a whole lot more confusing than having auto and documenting that the result is an input range.

Re: D as a Better C

#157

Post by anonfunction »

jmh530 wrote: post #113
srcmap wrote: post #81

I love to see someone prove D as a Better C by porting the "small" sqlite 124K line of C code to D and run some benchmark/test code against it. I used to work on OO database engine that handles billions of records. I end up rewriting/overloading my own new/delete and redesign everything how data is load/store around it. Shorten the open/close document time from hours to seconds for large documents. Basically, one can…

Could you recommend some resources on these techniques?

https://stackoverflow.com/questions/45972/mmap-vs-reading-bl...

Re: D as a Better C

#158

Post by kevin_thibedeau »

e12e wrote: post #102
dom96 wrote: post #52

Earlier quoted context omitted.

(Disclaimer: one of the Nim core devs here) Happy to see you paint Nim in a (sort of) positive light, I hope I can help with this one negative. > I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes. Can you give some examples and elaborate on what you mean by "fail silently"? Did you at least get a segfault?

Since it's already brought up in this thread, I recently had (another) look at nim and was a little disappointed too. It's been a while, but as I recall, on Windows - it was difficult to find a supported way to output Unicode on the console in a sane, portable way (write utf8 nim source code, get wide strings in Windows console and utf8 under eg Linux) - and I think I also had some problems getting off the ground wit…

It's not really Nim's fault that cmd.exe has crap Unicode support.

Re: D as a Better C

#159

Post by e12e »

kevin_thibedeau wrote: post #158
e12e wrote: post #102

Earlier quoted context omitted.

Since it's already brought up in this thread, I recently had (another) look at nim and was a little disappointed too. It's been a while, but as I recall, on Windows - it was difficult to find a supported way to output Unicode on the console in a sane, portable way (write utf8 nim source code, get wide strings in Windows console and utf8 under eg Linux) - and I think I also had some problems getting off the ground wit…

It's not really Nim's fault that cmd.exe has crap Unicode support.

If you have an "echo" primitive/function, and "out of the box unicode support", then respecting the host OS codepage/output encoding by default is the sane thing to do (as indicated in the bug linked by the sibling comment ("just use the win32 api").

It's not that nim can't output wide characters from a utf8 source, it's just that it's not obvious how to do it in a standard way - one might thing that utf8 unicode "hello world" should "just work" on windows, and it doesn't.

It doesn't really make much sense to only do the right thing on systems that happen to have a utf8 locale (it's not that windows doesn't handle wide strings, it just doesn't have a utf8 locale by default).

It's not my impression that the nim community doesn't want to be cross-platform and beginner friendly - it's just that they're going through a phase of modernizing the win(32) sub-system.

Correct text handling isn't "just use utf8", as fun as that would be - correct handling is figuring out "what encoding is the source text", "what encoding is the destination file/device" and "how do I put the source into the destination".

I'd expect a latin1, a utf16 and a utf8 string to all be output correctly with "echo" - on all supported platforms. It's kind of why you would want to use a higher level language with "batteries included" in the first place.

Re: D as a Better C

#160

Post by codyguy »

I have tried D, loved the language but I feel the ecosystem and environment issues need to be addressed asap. Here are a few inputs (1) setting up env different operating systems eg GNU/linux variants. Compilers ldc, etc are not really easy to setup on all systems.

(2) Memory usage during compile can get out of control resulting in mid-build crashes if sufficient memory is not available.

(3) Setting up of a simple http server should be made simple. (ideally the way Go allows to convert any regular Go program to a http server)

Post reply on HN