OpenD, a D language fork that is open to your contributions • Hacker News Board

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

#271

Post by pjmlp » Sun, Jan 14, 2024, 9:28 PM UTC

jug wrote: post #185

Kranar wrote: post #7

D is such a sad case of how a good technical product can fail due to poor leadership and decision making. A language is more than just a compiler, it's also an ecosystem and a community. D's community is actually very welcoming but man, watch some of the DConf videos and Q&As on Youtube and it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves l…

Or Go... Or among the new kids on the block - Mojo. Heck, even .NET is pushing NativeAOT (their brand name for native code compilation) hard these days. Still with sizable gaps but closing for every new release, and you can now develop full fledged desktop apps or a web service and have it be self-contained with native code. I think .NET in particular is a harbinger for D. When even a "managed language" platform at i…

.NET has always had native support, although in various forms.

NGEN, only usable for fast startup, using dynamic linking.

Singularity and Midori respective C# dialects.

MDIL in Windows 8.x based on Singularity Bartok compiler toolchain.

.NET Native on UWP, taken from Project N, inspired by Midori's System C#.

Mono AOT used by Xamarin for iOS and Android.

Homebrew OS like CosmOS.

Unity's IL2CPP toolchain.

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

#272

Post by kristianp » Sun, Jan 14, 2024, 9:39 PM UTC

keyle wrote: post #152

nwallin wrote: post #77

Earlier quoted context omitted.

Rust is a frustrating language for me too. I never saw the need for it, really. I just stuck with the language constructs in C++ that makes it basically impossible for memory leaks/use after free/use outside of bounds to occur or if they do occur, explode loudly in debug environments. I haven't used new/delete in a personal project in like a decade; longer than Rust has been around. Now I'm working on a project where…

Please write a book about this. I'd want to read it!

I'm not a C++ programmer, but aren't there plenty of "Modern C++" books out there already?

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

#273

Post by foresto » Sun, Jan 14, 2024, 9:40 PM UTC

auxym wrote: post #195

foresto wrote: post #90

Earlier quoted context omitted.

If you're put off by key leaders talking down to people, I think you'll want to spend some time in Nim's forum and issue tracker before considering it as an alternative. (YMMV, of course, but I was put off by what I found.)

FYI, some members of the Nim community are working on a fork, for apparently similar reasons as OpenD (community-led development). https://github.com/nim-works/nimskull under active development and not ready for general consumption though, from my understanding.

Thanks for calling my attention to that. I'll have to keep an eye on it.

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

#274

Post by ColonelPhantom » Sun, Jan 14, 2024, 9:44 PM UTC

zozbot234 wrote: post #261

fl7305 wrote: post #242

Earlier quoted context omitted.

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.

Most race conditions are prevented by Rust thanks to its "alias XOR mutable" paradigm that prevents having multiple mutable references and enforces the presence of locking or atomics. Not all, but the words "fearless concurrency" aren't meaningless either.

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

#275

Post by Const-me » Sun, Jan 14, 2024, 9:48 PM UTC

dequan wrote: post #244

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.

C# is not more safe than Rust is and falls to prevent null pointer exceptions and modified collection exceptions.

> C# is not more safe than Rust

By design, Rust requires unsafe code to implement any non-trivial data structures (except trivial POD types). This applies to both Rust standard library, and third-party crates.

The issue is not a theory, security bugs actually happened in reality. Here’s an example about the Rust standard library: https://shnatsel.medium.com/how-rusts-standard-library-was-v...

By contrast, thanks to the VM and the GC, C# allows to implement very complicated data structures without any unsafe code or unmanaged interop. The standard library is also implemented in idiomatic memory-safe subset of the language. For example, here’s the hash map: https://source.dot.net/#System.Private.CoreLib/src/libraries...

> falls to prevent null pointer exceptions and modified collection exceptions

Yes indeed, but these exceptions are very unlikely to cause security bugs in the software.

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

#276

Post by neilv » Sun, Jan 14, 2024, 9:52 PM UTC

neilv wrote: post #51

lifthrasiir wrote: post #40

Earlier quoted context omitted.

While I agree this is an important problem, I don't think there is a satisfactory answer. Programming language evolution is more or less a complexity management, while you also have to balance requirements from various stakeholders. Almost all governance drama came from one group of stakeholders complaining about requirements essential for other group of stakeholders, and you can't always satisfy both. (Rust `async`…

We might be able say that a given assessment of governance will work out well for our needs. But it's a lot easier to identify showstoppers early on. For example, if a language designer and implementor says upfront that they want to run it as Benevolent Dictator For Life, and also that they don't want to see feature PRs from people, because they prefer to work through all the details themself... That's their right, a…

> We might be able say

Correction: "We might not be able to say".

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

#277

Post by fl7305 » Sun, Jan 14, 2024, 9:55 PM UTC

ColonelPhantom wrote: post #264

fl7305 wrote: post #258

Earlier quoted context omitted.

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 t…

> Saying Rust has no benefits over C++

Sorry, that wasn't my intent. It was more to point out that bad programmers are surprisingly inventive when it comes to write bad code. New languages are an improvement, but not a panacea.

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

#278

Post by Const-me » Sun, Jan 14, 2024, 9:56 PM UTC

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#?

Don’t create new objects, instead use stack and/or unmanaged heap.

This reduces the expressive power of the language, for example LINQ from the standard library is probably out because based on the delegates which require memory allocations.

Still, the language is very usable even without GC allocations. For example, that library re-implements a subset of ffmpeg for Raspberry Pi4 running 32-bit Linux, with no memory allocations in runtime: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo

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

#279

Post by JonChesterfield » Sun, Jan 14, 2024, 10:01 PM UTC

As a contrary perspective, a language which enthusiastically welcomes patches from anyone is likely to degenerate into an incoherent mess very quickly.

Language design is difficult. Features interact in complicated ways. Fixing mistakes is tricky - you break existing code.

Forking D sounds fine. It's easier to start with an implementation than to go from scratch. Ideas which work out well get to have a existence proof when proposing them to the original. Ideas that crash and fail don't add to the debt of the original language.

I hope the fork goes well and this proves a net gain for the original ecosystem.

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

#280

Post by datadeft » Sun, Jan 14, 2024, 10:12 PM UTC

lolinder wrote: post #209

datadeft wrote: post #116

Earlier quoted context omitted.

Rust is for people who stick around, can come over hurdles, can take in new concepts and see the overall benefits. It has a steep learning curve that pays off. For me there are three reasons why Rust is suitable for many usecases: - performance - safety - static binary compilation with targeting different cpu architecture After spending majority of my time with Python and Java in the last 10 years these are things i…

> Rust is for people who stick around, can come over hurdles, can take in new concepts and see the overall benefits Speaking as someone who is learning Rust and really liking it, I just want to note that this comment is sort of emblematic of what is wrong with the Rust community. It comes off as pretty condescending—"Rust is for the people who are smart and don't give up easily, if you're less smart or give up easily…

Sorry i do not want to sound condescending. I was just explaining my own experience. The first time I wanted to learn Rust I failed because I gave up.