Hacker News Reader

Comment by teleforce | Hacker News Reader

Personally I think D language got it right when it makes GC as a default but still allows for no GC whenever applicable thus keeping most of the language relatively safe, easier to grok and more Pythonic compared to Rust.

It will be very interesting to survey how many Rust implementations nowadays do away with memory safety [1].

Not sure if the author of the article referred to this seminal paper on Rust for GC for his GC implementation for Rust in Rust [2].

[1] What is a safe programming language?

https://cs.stackexchange.com/questions/93798/what-is-a-safe-...

[2] Rust as a Language for High Performance GC Implementation:

https://users.cecs.anu.edu.au/~steveb/pubs/papers/rust-ismm-...

View on HN

D made the right tradeoffs for whom? There are many safe languages with great ecosystems which have a GC. Realistically, before rust, there wasn't really any for languages without a GC. A major problem for folks who must not use a GC is that large parts of the D ecosystem rely on the GC which makes it not useful for the segments that cannot use said GC. I've not actually used D professionally, so I could be off base, but this is at least the perception.

Rust is facing a similar problem in terms of sync vs async, which seems to limit options primarily for folks who want to avoid async, but it doesn't seem like a major blocker for adoption comparatively.

I think one notable difference for Rust is that it's still perfectly possible to call async code from sync code. It might be slightly less efficient than if everything was participating in async, but often that's fine when it's just the one-off network request in your otherwise synchronous CPU-heavy workload. Meanwhile, for people who need to have no GC, you can't paper over an internal dependency that uses GC. The whole stack has to be no-GC period. A similar comparison in the Rust world is probably with the #![no_std] ecosystem. Kernels/kernel modules and super low power microcontrollers have the biggest restrictions on what libraries they can pull in, since they can't use any dependencies that use the normal standard library, only the core library. (Low power is relative though, eg the ESP32 chips have nearly full std lib support)

I think D failed because it doesn't take a stand one way or the other.

Overwhelming majority of mainstream programmers want important choices to be made for them.

- People want language designers to decide: Has GC or no GC. Choose one and be consistent with it. Then all the libraries will be written on top of it.

- People want language designers to decide: Has async green thread or not. Choose one and be consistent with it. Then all the libraries will be written on top of it.

- People want language designers to decide an auto format syntax style. Choose one and be consistent with it. Then all the libraries will be written on top of it.

etc. etc.

C# doesn’t do the latter two

they’re experimenting with green threads now though… we’ll see where that ends up :)

From BUILD 2023 Q&A session, nowhere, too expensive to retrofit, even though in hindsight would have been a better approach, given how hard still is to write correct async/await code.

Thanks, I didn’t hear that update!

D was doomed from the start. It was designed as an incremental improvement over C++. Initially it provided refuge to burnt out C++ programmers like myself. But once I discovered Rust there was no coming back.

Rust takes its fundamentals from more advanced and well thought out functional languages. As a result it outclasses D and its ilk.

The big reason why this library exists is so that downstream consumers can be entirely memory safe in their allocations - it's the same way that the Rust standard library works. Library writers can use unsafe code to provide safe abstractions and APIs, so you end up with an unsafe core with a safe framework on top of it. I'm just continuing that tradition.

I actually haven't read that paper! Thanks for sharing it. What I'm doing is slightly different - it looks like they're building a conservative GC with an unsafe API, much like one might for C. My intent was closer toward building a GC which can be used with any safe Rust code more or less unconditionally.

You would think that if D "got it right," it would have seen a tenth the excitement / engagement Rust does. The proof is kind of in the pudding?

> You would think that if D "got it right," it would have seen a tenth the excitement / engagement Rust does.

Why? Excitement doesn't always follow correctness or even "goodness" (whatever that means in context), even if we'd like it to. Fashion and marketing matter more when it comes to excitement.

I think they're very correlated!

counterpoint, PHP?

It's very naive to think that language popularity correlates with engineering merits...

I worked very little with D, and a lot more with Rust. I cannot really speak to the qualities of D because, by and large, I dealt with a very few instances of it, and only at the interface level (mostly writing in another language). But, in terms of fame and popularity -- Rust developers and backers put a ton of effort into promoting the language. There were times when every other week there would be an article in some popular tech. media source from all kinds of "big names" about how Rust is superior to something (usually C++). There were massive efforts made to create a self-sustained community of Rust-evangelists who'd go and spread the word to the heathens...

I haven't been around to witness the birth of D and don't remember if it had any kind of adoption campaign, but from what I can tell, even if it had a campaign, it didn't succeed.

Now, here's another example from the same category of languages: Ada (esp. with Spark). I'm not very knowledgeable about it, but from the little I know, there are a lot of good reasons to prefer Spark over Rust. At least, on engineering merits, they should be roughly equivalent. But, in terms of popularity, Rust beats Spark by a lot.

Popularity is itself an engineering merit.

Yeah, if you have $500M (half a billion of USD) to spend on marketing, like Sun Microsystems poured into Java, you must have some engineering merit behind you. Not necessarily in the thing you market.

Social Engineering

Merit? -- maybe. Engineering? -- definitely no. This is why I used this word in the first place.

I mean, I understand this is an attempt at being a snarky remark, but it gets really annoying as a joke that a lot of people repeat to the point they start believing it's true.

Beyond technical merit, D never had a "carrier" application like Rust had with Firefox (AFAIK).

Rust had servo, not Firefox, but it doesn't matter that much; Rust got legitimately popular for the 'safe non-GC language' badge that it shares with precious little peers.

Python is a very niche language in my country

Unless your country barely has any computers, I find it hard to believe.

First world country, middle of Europe, Java everywhere. And C#.

Saw Python last at university and just because I wanted to.

I know nobody that works with Python on a day by day basis and I know many nerds like me :)

That just seems to be the bias of your work. Python is absolutely huge in ML.

I know and it is.

Just wanted to put it into perspective, because people tend to think their bubble is the whole world. (Oh the irony;-))

I think it's more accurate to say the Python is a very niche language in your field. Python is everywhere in all aspects of computational and data science, ML and most engineering fields. Even in your country.

That being said I have observed that using Python as a web/backend language seems to be more common in North America than in Europe, but I have no evidence to back that up.

Reply on news.ycombinator.com