Live data from Hacker News

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

dpldocs.info

281–290 of 322 posts

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

#281

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…

Performance isn’t a problem for Java for just about any business application most programmers will work on and, if it is, you can usually figure out how to optimize Java to hit your performance target. Safety is also not a problem in Java. And fat jars remain the single best way to deploy an application I’ve seen in just about any ecosystem (and nix is working out pretty well to bring their benefits to the rest of th…

I have the exact opposite experience. In fact for a while I lived on optimizing Java projects to meet with performance numbers even my junior Rust code can beat easily. Most Java devs have no idea how to write performant software.

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

#282

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

> 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++

Yeah, for a long time the language was marketed as a better C++. That was wrong for two reasons. First, it's a C++ replacement, but it's not C++, as many C++ developers learned in frustration. Second, it's a lot more than a C++ replacement. It works for scripts, as a general programming language, and especially for C interop (ImportC, BetterC, etc.)

One of the goals of the fork is to stop apologizing for the GC. You still have reference counting, unique pointers, and whatever in the standard library. I'm sure if someone wants to contribute functions that avoid the GC, they'll be accepted. What you're not likely to see with the fork is Adam writing new functions for the standard library that go to great lengths to avoid the GC. He believes fear of the GC is overblown.

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

#283

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

> 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++ Yeah, for a long time the language was marketed as a better C++. That was wrong for two reasons. First, it's a C++ replacement, but it's not C++, as many C++ developers learned in frustration. Second, it's a lot more than a…

Right, but even if this was always the most consistent/accurate direction for D, so it isn't actually a change in direction technically speaking, that still leaves the main point of what I wrote unanswered — how can its new direction find it a niche when it has to compete in the "GC'd but very fast C++ successor language" space with C# and Java?

Also, this idea that fear of the GC is overblown — I buy that for servers and applications and the like for the most part (although I think our obsession with using heavier and heavier runtimes and frameworks to ease development at the cost of efficiency is unsustainable in the long term and has contributed significantly to the bloat of modern systems), but for real-time work, or embedded systems, or low level programming that needs to implement the sort of things a GC or runtime relies on, which are the only things I think most people claim GCs aren't good for, I really don't buy the argument that GCs don't matter. Yes you can do such things with languages that have them, especially if you have cutting edge GCs like Java's ZGC or turn your runtime into bare metal hardware drivers like Miranda did with OCaml, but oftentimes that's just harder to reason about and control, more work, and has costs (like ZGC needing 2x the memory and roping all pointer accesses into doing GC work to amortize processing costs), so it's like that article about using C# to do a <2KB game — why not just use things more well suited for that. This is a common sentiment I've seen in the D community though, so let me ask directly: is this argument a response to people who are claiming not to want a GC for low level / systems programming, in which case I don't think it's very reasonable, or is this a response to people who balk at GC for server and application stuff, in which case I'm not sure anyone disagrees? Or is there a third option I'm missing?

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

#284
post #244

Earlier quoted context omitted.

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

The entire JIT, garbage collector and most of the C#'s VM are all implemented in C++. This has caused various issues in the past which are exploitable from managed code. The amount of unsafe code used to implement C# vastly outweighs the amount in Rust's standard library.

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

#285
post #97
post #94

Earlier quoted context omitted.

> A would be an excellent choice were it not completely un-googleable. APL is named after the book A Programming Language

The ultimate language will be TPL (the programming language)

til chatGPT renames itself "I, programming language"

which is extra clever because the "boot" button on early IBM mainframes was labelled IPL "initial program load".

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

#286
post #284

Earlier quoted context omitted.

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

The entire JIT, garbage collector and most of the C#'s VM are all implemented in C++. This has caused various issues in the past which are exploitable from managed code. The amount of unsafe code used to implement C# vastly outweighs the amount in Rust's standard library.

> The amount of unsafe code used to implement C# vastly outweighs the amount in Rust's standard library.

According to bing.com chat, https://github.com/dotnet/runtime has 3.5M LOC, and https://github.com/rust-lang/rust has 6M LOC. The right panel of https://github.com/dotnet/runtime says 80% of the .NET runtime is written in C#.

This makes me wonder, do you happen to have a link for your “vastly outweighs” statement?

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

#287

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.

Why do that with the preprocessor rather than the `--wrap` flag? That's what most malloc libraries do.

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

#289
post #244

Earlier quoted context omitted.

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

> Rust requires unsafe code to implement any non-trivial data structures

That seems like a gross overstatement.

https://github.com/rust-lang/rust/blob/master/library/std/sr...

CTRL-F: unsafe

Only one result, an optional utility function: "pub unsafe fn get_many_unchecked_mut"

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

#290

Earlier quoted context omitted.

Your suggestions are moving backward, and GC by default and no macro made D intuitive and Pythonic that are big plus in any modern programming language construct. The non GC is not really needed unless you're working on OS control primitives but again D give you alternative unlike Go. Every modern languages should avoid macro like a plaque otherwise you will sooner or later create a ghetto inside your community not u…

> intuitive and Pythonic "Pythonic" hasn't been "intuitive" for 15 years now. Even old-school Perl is more cohesive and coherent than modern Python.

Yeah that is why Python popularity is on the downward trend and Perl is the opposite /s
Post reply on HN