Live data from Hacker News

The reference D compiler is now open source

forum.dlang.org

111–120 of 313 posts

Re: The reference D compiler is now open source

#111
post #101

Earlier quoted context omitted.

There are many parts of the std lib that assume GC usage. When you mark a function as @nogc, DMD does a compile-time check and will not compile your program if there's a GC call. Applying this to main means that your entire program will by necessity be GC free.

Right, I understand that it effectively eliminates GC usage, I'm just wondering how much of an impact that has on what tools you have. In the extreme, I can imagine it degenerating into basically writing C, for example.

You have access to all of std.range and std.algorithm, most of std.datetime, many functions in std.string and std.digest, and others scattered throughout the std lib. The main thing you'll want to look at is std.experimental.allocator, which has tons of tools for manual memory allocation.

Most of the community packages out there use the GC. Some though are transitioning to a std.experimental.allocator interface, like this containers library https://github.com/economicmodeling/containers

Re: The reference D compiler is now open source

#112
post #82
post #44

Earlier quoted context omitted.

Also, how does D compare to Rust? (If I'm going to learn a new system programming language, which one should I pick?)

D has been around longer, has powerful compile-time metaprogramming tools, and has a very fast compiler. However, it has a garbage collector, and is not entirely memory-safe by default (though is beginning to optionally incorporate some ideas from Rust [edit: or not], maybe making that easier once you put in the work). It seems to follow C or C++ in what sorts of things it makes language-level features. Rust is newer…

[deleted]

Re: The reference D compiler is now open source

#113
post #85

Earlier quoted context omitted.

Why does gc disqualify a language as a system's language? P.S. I think of a system's language as one that runs directly on the machine, e.g. Swift, C, go. They operate at the "system" level.

> Why does gc disqualify a language as a system's language? AFAIK a "system programming language" should have deterministic performances, obviously Go hasn't. But different people might define "systems" differently.

I think Go should be pretty deterministic, if you don't allocate or free at all at runtime.

Just like C. You lose determinism with malloc() and free(). As any embedded/kernel developer knows, malloc() takes often unacceptably long time. Or even free().

Re: The reference D compiler is now open source

#115
post #44

Whats special about D? why should i learn it?

Also, how does D compare to Rust? (If I'm going to learn a new system programming language, which one should I pick?)

If you plan to learn a systems language for systems reasons (embedded development, compilers, low-level interfaces, etc) then Rust is the pick. No GC and the option to have no runtime (or a very small one, by default).

In other words, if you're looking to replace/supplement your C use: go Rust. If you're looking to replace/supplement your C++ use: probably go D, with some caveats towards actual use.

Note: I like both languages, but do prefer Rust for my personal use cases.

Re: The reference D compiler is now open source

#117
post #44

Whats special about D? why should i learn it?

Also, how does D compare to Rust? (If I'm going to learn a new system programming language, which one should I pick?)

My early impression with Rust is that it's more ambitious than it is capable of delivering. Lifetime annotations in particular are incredibly ugly. It's the kind of thing that makes me think: "...ok, so this is why other languages don't simply do static lifetime checks" and I guess I expected Rust to be the solution for that problem; it is instead not a solution, but the deliberate decision: "let's do static borrow checking" and that was at odds with what I expected from it.

In short, I thought Rust was "we solved the pain of this difficult thing." However, it is not really a novel solution to the difficult thing, but simply a decision to undertake it.

I've now moved to evaluating Nim and D, and while I've barely dabbled in them (mostly going through the docs and writing some simple example-like code), I can at least say that Rust is likely to be much more controversial and polarizing than these languages. I recommend giving it a try - go through the official "book" which serves as the main documentation. If you survive lifetime annotations without finding them too obnoxious, then you'll probably like Rust.

Personally, I find Rust's extreme rigorousness (and the laboriousness that follows from that) makes it very niche, and I find myself rather unexcited about using it for anything.

Re: The reference D compiler is now open source

#118
post #11

Walter, thank you so much for finally doing this! I am so happy that Symantec finally listened. It must have been really frustrating to have to wait so long for this to happen. I have really been enjoying D and I love all the innovation in it. I'm really looking forward to seeing the reference compiler packaged for free operating systems. Thanks again, this news makes me very happy!

You're welcome! It makes me happy, too. I've wanted to do this for a very long time.

Just to pile on: Kudos for this!

Re: The reference D compiler is now open source

#119
post #44

Earlier quoted context omitted.

Also, how does D compare to Rust? (If I'm going to learn a new system programming language, which one should I pick?)

If you plan to learn a systems language for systems reasons (embedded development, compilers, low-level interfaces, etc) then Rust is the pick. No GC and the option to have no runtime (or a very small one, by default). In other words, if you're looking to replace/supplement your C use: go Rust. If you're looking to replace/supplement your C++ use: probably go D, with some caveats towards actual use. Note: I like both…

> (or a very small one, by default).

Some details here... every language other than assembly languages has some amount of runtime. This is Rust's: https://github.com/rust-lang/rust/blob/master/src/libstd/rt.... (as you allude to, many people refer to this amount of runtime as "no runtime" since it's very, very small.)

You could also consider some other things as part of a runtime; for example, by default on most platforms, Rust includes jemalloc. That can be removed, though not in stable Rust. Same with the standard library code, which can be removed for libraries, but not binaries just yet (due to a small technicality regarding the stability of some attributes.) Things that do this are likely to use some of Rust's other unstable features at the moment, so it's not generally a burden to do so, and those interfaces rarely change right now.

Re: The reference D compiler is now open source

#120

Earlier quoted context omitted.

Smart pointers are a form of garbage collection. (I'm assuming you mean reference counting).

Not all smart pointers are reference counted.

Sure, smart pointers can also refer to bounds checking, etc.

In this case, grandparent did mention a memory management technique, namely garbage collection.

Memory management + plus typically required thread safety usually means reference counting.

Post reply on HN