Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why do you use Rust, when D is available?

news.ycombinator.com

Post reply on HN
Print view View original

241–250 of 262 posts

Re: Ask HN: Why do you use Rust, when D is available?

#241

Post by asdkhadsj »

tluyben2 wrote: post #118
dpc_pw wrote: post #28

Personally, at some point Rust was just clearly better and after a while - I lost interest in D. I don't have time to keep track of D catching up, when I'm so happy with Rust, and ecosystem is growing so fast. Maybe D got much better in last few years... but I kind of don't care anymore. It's hard enough to introduce a raising star like Rust to your coworkers and D just don't have traction anymore. I've been followin…

> It's a C++-killer: same strengths, none of the weaknesses Not used Rust yet, used a lot of C++; isn't a weakness that it also is extremely slow in compiling? Not sure about others but to me that's a big weakness (if it still applies, but as far as I can find on Google it does).

I'm not sure what fast or slow is. I think on average I spend 1-10s compiling. Eg when I run my tests, or run a server. However that is during my normal workflow. Ie the thing I do 500x a day.

If I was to nuke my target directory _(the compile cache)_, it would take minutes. Not sure how many honestly, because when I do it, I rarely wait for it.

So the compiles are definitely slow, but for me it's only bad when dependencies are needing to be compiled. Which is rare.

If you don't cache your dependencies well, like in a poorly written CI pipeline, things will suck though. 20 minute builds at work (slow build machines) are common for us due to some poorly done caching.

Re: Ask HN: Why do you use Rust, when D is available?

#242

Post by tastyminerals2 »

vvillena wrote: post #222
tastyminerals2 wrote: post #183

Earlier quoted context omitted.

Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name? double[] arr; bam! Simple and clear. What about functions? It has input, name and output and D nicely presents you with double[] createArray(int size) {...} This is as little typing as you ca…

> Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Usually, the reason is to make parsing easier. C++ is infamous for having undecidable grammar. Ruby is extremely pleasing to the eye, but its grammar is a clusterfuck. Newer languages have learned from that, so they try to have simpler grammars. Another reason for those small syntax markers is to avoid im…

Yes, "make an explicit choice regarding mutability" can be done even easier by actually writing "immutable double[] arr = [1, 2, 3];", "const double[] arr = [1, 2, 3];". See, no Scala val/var which to a person who doesn't know the language tell nothing. When the language grammar is unambiguous and coherent you have faster compiling times and occasionally better readability. D hits a nice spot in here by capitalizing on C++ mistakes.

"optional parentheses introduce ambiguity" -- true, they do. However, I am struggling to understand why it is necessarily a bad thing? For a user I see a clear convenience of being able to write "double[] zeroArr = arr.zeros;" or "double[] newArr = 6.iota.sliced(3, 2).array.reverse.dropOne.join;". And if that is not enough, you can also inject your custom method into this chain and it will just work. Don't know about Rust but Scala simply refuses to compile in such cases which for a functional language looks like a limitation.

These are the D features that I really enjoy.

Re: Ask HN: Why do you use Rust, when D is available?

#243

Post by tastyminerals2 »

claudiug wrote: post #240

- bad or missing tooling - no clear direction - no vision - no ide - no big company - bad or missing documentation

* bad or missing tooling - true, it's missing but I wouldn't say it is bad

* no clear direction - agree

* no vision - there is but not well maintained unfortunately https://wiki.dlang.org/Vision/2018H1

* no ide - VS Code with D plugin works pretty well these days. There is an IDE written fully in D too.

* no big company - true, but there are a bunch of successful smaller ones.

* bad or missing documentation - not true, std documentation is pretty good and is gradually improved.

And don't forget that notwithstanding the lack of people and corporate funding (D is crowd-funded), you get a language that attempts to rival the big guys and frequently outplay them. Now, imagine the results given the resources were equal.

Re: Ask HN: Why do you use Rust, when D is available?

#244

Post by ncmncm »

adamnemecek wrote: post #218
ncmncm wrote: post #174

Earlier quoted context omitted.

Rust macros know nothing about types, but types are what do all the work at compile time.

Do they have to know about types?

Only to build designs that today are possible only in C++.

Type-aware macros might not be the best way to implement the features needed to match C++.

Re: Ask HN: Why do you use Rust, when D is available?

#245

Post by AnimalMuppet »

yesenadam wrote: post #239
AnimalMuppet wrote: post #155

Earlier quoted context omitted.

Case study: awk. Brian Kernighan, who (co-)wrote the book on C, designed (with two others) another language, awk. Same organization (Bell Labs) pushing it as pushed C. C ate the world. awk... um... was available on all Unix installations, and got used for some things. Sure, there are people who rave about how great awk is. I've read them here on HN. When you've got the right kind of problem, it's a great tool. But th…

So you're saying Awk isn't "actually useful" which is why it's hardly used?! It's an entirely different kind of tool to C. Or rather, C is a programming language, Awk is a tool. To "get used for some things" is what it's for. Sounds like you're talking more about what purpose things are used for than how much they're actually used. And Awk seems a failure to you because it's used for Awk-problems rather than C-proble…

> So you're saying Awk isn't "actually useful" which is why it's hardly used?!

I deny you the right to put words in my mouth. That is not remotely what I am saying.

Re: Ask HN: Why do you use Rust, when D is available?

#246

Post by WorldMaker »

Recurecur wrote: post #215
WorldMaker wrote: post #198

Earlier quoted context omitted.

Garbage-collected languages can have (and some have had) latency-predictable GCs. It's not entirely an either/or, it's something of a false dichotomy. "Non-garbage collecting" languages blur the line anyway because even basic things like reference-counting are still a garbage collection technique. The trade-offs are in how many control knobs and where those knobs are/how you turn them, and a lot of developers still s…

Something of a false dichotomy - perhaps. The fact is that allocating at all during realtime operation is frowned upon. Given that the best approach is pre-allocation and then turning off the GC, why carry the overhead of the GC at all? For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach. The important thing is avoiding languag…

> Given that the best approach is pre-allocation

GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not everything has moved to Span that can move to Span and family.)

But also, not everything needs to be pre-allocated for the "best approach". There's some work to get used to the feel of any specific GC, but most modern "VM" GCs (.NET and today's Java, not yesterday's) are multi-generational and there's a lot you can do in strategies such as "focus on the nursery and the LOH" (using only [potentially many] small short-lived objects and a few, mostly stable "very large" objects, avoiding the intermediate generations).

> why carry the overhead of the GC at all?

Safety. (Why wear seatbelts?) Rust's borrow checker is great but it still requires a lot of manual adjustment and it's still possible to miss something (it's not easy, certainly, but it is possible); a GC gives you safety by default, with no manual intervention required to guarantee safety, and requires manual effort to write unsafe code.

> The important thing is avoiding language patterns that encourage needless allocation.

That's where we agree and why I'm very adamant that though some of the tools ("knobs") look scarily different in performance optimization for GC versus non-GC languages, the vast majority of the tools are the same: know the O(memory) of your algorithms, and make smart trade-offs regarding that O(memory), avoid allocating what you don't need, know your trade-offs between pre-allocation and allocation only when necessary, etc.

Re: Ask HN: Why do you use Rust, when D is available?

#247

Post by Rochus »

Aeolun wrote: post #111
Rochus wrote: post #83

Earlier quoted context omitted.

Thank you for putting it so aptly. Unfortunately for many people technology is still an emotional rather than a professional topic.

I think the two go hand in hand. I get emotional over many a professional topic.

That's why we do tradeoff studies in systems engineering, to avoid that we take important decisions based on emotions or assumptions. Participants can still get emotional, but at least they have the facts and a process which converges to the optimum solution when followed.

Re: Ask HN: Why do you use Rust, when D is available?

#248

Post by danielscrubs »

WorldMaker wrote: post #246
Recurecur wrote: post #215

Earlier quoted context omitted.

Something of a false dichotomy - perhaps. The fact is that allocating at all during realtime operation is frowned upon. Given that the best approach is pre-allocation and then turning off the GC, why carry the overhead of the GC at all? For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach. The important thing is avoiding languag…

> Given that the best approach is pre-allocation GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not ev…

> it's still possible to miss something

Could you elaborate?

Re: Ask HN: Why do you use Rust, when D is available?

#249

Post by WorldMaker »

danielscrubs wrote: post #248
WorldMaker wrote: post #246

Earlier quoted context omitted.

> Given that the best approach is pre-allocation GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not ev…

> it's still possible to miss something Could you elaborate?

Tbf, I've not directly worked in Rust so my understanding is mostly academic of a sort. The issues I'm directly aware of are primarily in boundary conditions between unsafe and borrow-checked code, which isn't entirely fair to Rust as GC-languages of course have the same boundary conditions. My impression however is that because the borrow checker is a lot of work, there's a lot more Rust libraries in the wild with unsafe code sections than strictly need to be (as compared to similar libraries in GC-languages, and especially with modern tools like Span in .NET nearly shrinking GC-unsafe blocks to non-existent in modern code).

Re: Ask HN: Why do you use Rust, when D is available?

#250

Post by MacSystem »

Recurecur wrote: post #121
blub wrote: post #71

Earlier quoted context omitted.

Because the real world doesn't really match the expectations and statements of the HN community. It's really rare that I see here anything pragmatic regarding what programming languages to learn/use. The community lives in a bubble and is out of touch with mainstream software development.

I'm a very senior engineer. I've had a strong desire to find a better alternative to C++ since the 90s when I was first exposed to it (I worked with it for about a decade, after a few years with C). Now, decades later, enough bandaids have been applied that it's somewhat tolerable. Congratulations...? The industry has needed good alternatives for a long time. Finally, they're coming, and not nearly soon enough to sui…

What are thoughts on D?
Post reply on HN