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

OpenD, a D language fork that is open to your contributions

dpldocs.info

Post reply on HN
Print view View original

261–270 of 322 posts

Re: OpenD, a D language fork that is open to your contributions

#261

Post by zozbot234 »

fl7305 wrote: post #242
zozbot234 wrote: post #220

Earlier quoted context omitted.

> I still don't need rust because I don't code like a crazy person. This is not a foolproof argument because safety problems can easily result from unforeseen interactions among parts of the code that all seem to be OK and not "crazy" locally. A significant benefit of something like the borrow checker is that it can suss out these problematic interactions in a comprehensive way, even at the cost of forbidding some co…

I'm new to Rust, but wouldn't it be possible for the "C++ boss" to start writing Rust code like below? Here I think we have a multi-threading race condition that can lead to a crash (?) use std::sync::Arc; use std::thread; use std::time::Duration; fn main() { let shared_data = Arc::new(42); // Create an Arc let weak_ref = Arc::downgrade(&shared_data); // Create a Weak reference let thread_handle = thread::spawn(move…

Rust does not protect against race conditions, since these are mere logic errors that don't impact memory safety. This program can panic when unwrap() fails, but that's also a safe operation.

Re: OpenD, a D language fork that is open to your contributions

#262

Post by [deleted] »

logicchains wrote: post #153
chromatin wrote: post #2

My research group left D for Rust several years ago due to nonresponsiveness and poor language development trajectory. While I wish Adam and the others success with OpenD, I hope they can take the opportunity to pick a more unique/memorable name.

They could go with TheD, to fill in the niche left by Coq now Coq's getting renamed.

[deleted]

Re: OpenD, a D language fork that is open to your contributions

#264

Post by ColonelPhantom »

fl7305 wrote: post #258
ColonelPhantom wrote: post #245

Earlier quoted context omitted.

Sure, that does seem to be a race condition that can crash. I'm not sure how valuable this example is though, because it's not very intricate at all: a Weak reference can be invalidated (duh!) The fix is trivial: just use an Arc instead of a Weak. In addition, `upgrade().unwrap()` should be a sizable red flag (like any unwrap, really) since fallibility is kind of the entire thing of Weak.

Thanks! But Weak can be needed in case you have self-referential structures, right? I was wondering about this in the context of the C++ programmer in post above who likes to use both new/delete and malloc/free in his code. Sure, Rust will give him far fewer ways to screw up. But if he can't be asked to at least not use malloc/free in C++, he probably won't be too careful about unwrap() either? My point here is mainl…

> But Weak can be needed in case you have self-referential structures, right?

Well, technically, no, you can just use Arc and leak memory all over the place :^) but that's not very useful either. Most self-referential structures need some kind of "owning" thing too though. For example, a graph could use Weak for the edges, but in order to keep vertices alive you need e.g. a Vec>. Then, if upgrading fails, you know that your edge leads to a deleted vertex (and as such should be considered nothing, hence Option).

> Sure, Rust will give him far fewer ways to screw up. But if he can't be asked to at least not use malloc/free in C++, he probably won't be too careful about unwrap() either?

There's one big advantage of messing up with unwrap vs malloc/free: unwrap 'only' crashes your program (and can even be caught in some scenarios), whereas use-after-free can do literally anything. Unwrap is also much easier to debug because you usually get a clear stack-trace, and the program semantics have been well-defined at all points.

> My point here is mainly that a good programming language won't make good programmers out of bad ones.

Very true! But I think the point of Rust advocates tends to be more along the lines of "a bad programming language makes a bad programmer out of a decent one". It is very easy to misuse C++, so mistakes are made with it way more often. 'Dangerous' constructs do exist in Rust, but are generally far less pervasive, making it easier for the programmer to understand what they are doing.

Saying Rust has no benefits over C++ because you can mess up in both is like saying that anti-lock brakes are useless because you can still understeer by pressing the accelerator too hard (sorry for the car analogy, I had to). Preventing entire classes of mistakes is valuable, even if other classes are still possible. (If it's worth the cost is of course another question. My personal opinion is yes, although that's especially for memory safety and a bit less for race safety.)

Re: OpenD, a D language fork that is open to your contributions

#265

Post by Conscat »

tialaramex wrote: post #256
Conscat wrote: post #227

Earlier quoted context omitted.

Given that Sean Baxter already has lifetimes in Circle that work very similarly to Rust's, I'm skeptical that the very similar D language wouldn't be able to express the same thing.

Generously, you've confused somebody saying they're interested in working on a problem with them having a working solution to the problem. Circle does not, in fact, have working Rust style lifetimes. Sean splits the Circle documentation into features which work and "Research" features Sean is working on and lots of interesting ideas, including lifetimes, are in the second category. Maybe Circle will implement them so…

They've been the primary focus of Circle for the better part of a year now. He's demo'd them working many times already.

Re: OpenD, a D language fork that is open to your contributions

#266

Post by tialaramex »

softirq wrote: post #230

D is a real anomaly to me because it should have had the same trajectory as Rust, it vastly improved upon other systems languages at conception, the authors evangelized it, including at FAANG, and yet, Rust seems to have gained traction everywhere D failed to do so. Even in places where C++ has historically been shunned, Rust has some traction (Linux Kernel). I now believe that language adoption is just a product of…

Culture matters. "Culture eats strategy for breakfast". Rust has a safety culture. Yes it has a bunch of safety technology but the technology doesn't decide how things are used. It would be legal using the Rust compiler to implement the IndexMut trait on slices such that it just YOLOs like a C++ index. Rust doesn't do that, not because somehow the technology forbids it - it does not - but because culturally it's anathema to them.

Re: OpenD, a D language fork that is open to your contributions

#267

Post by fsckboy »

tsimionescu wrote: post #145
fuzztester wrote: post #135

Earlier quoted context omitted.

Interesting suggestions. How do you "hook' a function, like you said about malloc,free, main and exit? I guess it means intercept calls to it and do something additional to what it already does, something like Python decorators, but how do you do it in C or C++? I used C a lot (but not C++), but much earlier, and don't remember any method of hooking. atexit(), or something like it?

Given that they mention ifdef, I guess they just mean something like `#define malloc(x) (tracing_malloc((x))) ` in every place except the one where the tracing version is defined.

hungarian standardizes procedure/function names anyway (typed and capitalized), so while you're changing the name, it gives you "a place to stand" to do the other things you want to do.

for normal/average operating environments, I prefer to just indirect through an extra procedure call, gives you a place to put a breakpoint, and then if you need streamlined performant code you can #define it all away. But, if you plan to #define it all away, make sure that is a regular part of your work flow beforehand. you can have a procedure version, a heavyweight define and a lightweight define (and use your defines inside your procedure to test them there). On a regular basis you need to make sure your infrastructure is all doing what you think it is.

Same is true for main(), use it for setting up infrastructure, have it call Main() which is "your main".

if you are on a large enough project you can budget time for tools, the actual "__main.asm" code that calls C main() is also accessible and you can hook away in there too. Have to do it for all compilers, and track compilers, but on the scale of a large project, that's not the end of the world.

Re: OpenD, a D language fork that is open to your contributions

#269

Post by logicprog »

Personally, it's confusing to me what D's niche would be if they go all in on the GC. I get that it didn't really have a solid niche before either, because it was basically just a 10% better C++, without any really distinguishing killer feature, so it was kind of a hard sell, because most people are either going to stick with C++ for the existing support and code bases and industry, or are going to use Rust for greenfield projects, or Zig if they want simplicity, especially since with C++ 20 a 10% better C++ already exists, but I don't think focusing on having a garbage collector really helps so much? All this means is that it's going to be competing with C# and Java, which are already the garbage collected, safe, streamlined C++ successors and have been intended to be such since their inception, and I don't see how you can really compete with either of those languages at this point. Especially C# with its actually pretty excellent low level and unsafe capabilities like raw pointers and control over whether things are reference or value types and control over the layout of things in memory and stuff like that, combined with its pretty okay (for an OOP first language of its age) type system and reflection and all of the ML family features it's been getting.

Honestly, I've always felt really confused about what D's vision is. I've tried reading some of the docs about certain language features like better see and safe mode and lifetimes and they've been grammatically just kind of hard to read and generally poorly explained, despite going into great detail on things, and I've never really been able to get a sense for a coherent design vision or purpose for the language. The author mentions that this has been a problem, but I don't feel their vision is really any clearer. Yes they have a few concrete midterm technical goals, which is great, but it isn't clear to me what those goals are in service of. Honestly, I'm a rust programmer, so you know what I do for Greenfield personal projects, but I'd rather just use OCaml, C++, or even C# if I had to pick something else.

Re: OpenD, a D language fork that is open to your contributions

#270

Post by pjmlp »

tuna74 wrote: post #224
Const-me wrote: post #136

Earlier quoted context omitted.

> What kind of solution would you propose to folks like your boss? Rewrite it in C#. It’s safer than Rust, because VM. Both standard and third party libraries are often way better. With modern versions of the language, GC allocations are avoidable if that’s what needed for performance reasons. C interop is equally simple.

Could you expand on how to avoid using GC in C#?

Value types (structs), stack allocated arrays, spans, native memory allocation, arenas.

You can also enable the warnings/errors that complain about missing using declarations for class and structs with the Dispose pattern.

Post reply on HN