201–210 of 313 posts
Good to hear the news, and congrats to all involved. Since I see some comments in this thread, asking what D can be used for, or why people should use D, I'm putting below, an Ask HN thread that I had started some months ago. It got some interesting replies: Ask HN: What are you using D (language) for? https://news.ycombinator.com/item?id=12193828
Too late to the party to add my answer to your AskHN, but here we go: I use D at Netflix for machine learning backend.
Earlier quoted context omitted.
> race-free concurrency Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.
Could you give an example of a kind of race conditions allowed in Rust? (Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)
Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).
Earlier quoted context omitted.
The GC is only relevant if you allocate using the GC, because that is the only time the GC can run. If you use @nogc on your functions, you are guaranteed not to have GC allocations. You can use D as a better C with no GC but other good features. You can even avoid the D runtime compeletely if you want.
Thanks for your helpful answer. ...and I don't understand why some people have downvoted my question. Anyway, I'll continue reading the docs :)
Please don't get me wrong, as I don't want to start a flame here, but why do they call D a "systems programming language" when it uses a GC? Or is it optional? I'm just reading through the docs. They do have a command line option to disable the GC but anyway...this GC thing is, imho, a no-go when it comes to systems programming. It reminds me of Go that started as a "systems programming language" too but later switch…
D's garbage collector is both written in D and entirely optional, that alone should qualify it as a systems language. The gc can be disabled with @nogc, the command line flags are only if you want to disable it for the whole program or if you want warnings as to where the allocations happen. https://godbolt.org/g/IQ0O06
Earlier quoted context omitted.
Go does allocate and free at runtime, it just isn't explicit because its a garbage collected language and the garbage collector handles most of the freeing for you. Different GC'd languages handle allocations differently, some have a keyword, some do it whenever creating an instance of a type over a certain size. With C, C++ and Rust allocating memory often boils down to calling something equivalent to malloc and fre…
Does modern C++ or rust allow you to say "deallocate this pointer here " (like free or delete)? I was under the impression that Rust (and safe_ptr) deallocate at scope end, which could also cause framerate issues (unless you do ugly scope hacks). I do agree that you're unlikely to bump into this issue, though.
Earlier quoted context omitted.
uniq_ptr in C++ and Box in Rust are both considered smart pointers, dealing with memory management, and don't do any reference counting, bounds checking, or anything else like that at runtime. They're a compile-time abstraction only.
This is not really accurate. A unique_ptr move assignment must check the target location to see if it's null, and if not, free the underlying object. It also has to clear the source location. This is more than just a compile-time abstraction compared to raw pointers, even if modern compilers can elide the code most of the time. Also, the lack of checking leads to unique_ptr dereferences potentially having undefined b…
That said, the null checks required for C++'s destructor semantics are definitely a little more interesting in this respect, given one is rarely going to do this with raw pointers (although the cases when you don't need to do it also seem like cases the optimiser can handle fairly easily), but an extra branch and/or write at least seems significantly qualitatively different to the full reference counting that people often think of when talking about "smart pointers", which is the point the parent is trying to make (smart pointers aren't just reference counting).
Earlier quoted context omitted.
I think a lot of languages that get popular have to have a thing. Like a thing they do well, and hopefully change the world a little... Python had math and has lots more maths now. R also has math and started to kill Python, but now Python has Tensorflow and PyTorch. Scala has Spark. Java has Tomcat, and everything that followed, which is probably 20% of the world's mass by volume. Go has Docker Ruby has/had a railro…
> Does D have a thing? Probably its most useful feature is rather subtle. It's very easy to express diverse ideas in code in D without having to resort to contortions. It's something people realize after having worked with D for a while. It is not the result of having feature X (you can always find feature X in other languages or a way to make X work), it's the combination of various X's. For example, some algorithms…
(Yes, I know Haskell can also fake for loops more cleanly with monads, but they still feel awkward and unnatural.)
Earlier quoted context omitted.
> (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 plat…
> every language other than assembly languages has some amount of runtime How are you defining "runtime" such that this statement is correct?
Earlier quoted context omitted.
uniq_ptr in C++ and Box in Rust are both considered smart pointers, dealing with memory management, and don't do any reference counting, bounds checking, or anything else like that at runtime. They're a compile-time abstraction only.
This is not really accurate. A unique_ptr move assignment must check the target location to see if it's null, and if not, free the underlying object. It also has to clear the source location. This is more than just a compile-time abstraction compared to raw pointers, even if modern compilers can elide the code most of the time. Also, the lack of checking leads to unique_ptr dereferences potentially having undefined b…
I think my original point still stands here though: smart pointers != refcounting, inherently.
Earlier quoted context omitted.
This is not really accurate. A unique_ptr move assignment must check the target location to see if it's null, and if not, free the underlying object. It also has to clear the source location. This is more than just a compile-time abstraction compared to raw pointers, even if modern compilers can elide the code most of the time. Also, the lack of checking leads to unique_ptr dereferences potentially having undefined b…
I think you're picking nits. The equivalent raw pointer code would also have to free a pointer it was overwriting, so I'm not sure that's so interesting (definitely not in terms of "zero cost abstractions"). That said, the null checks required for C++'s destructor semantics are definitely a little more interesting in this respect, given one is rarely going to do this with raw pointers (although the cases when you don…
Also, the cost of it not being memory-safe should not be ignored.