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

71–80 of 322 posts

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

#71

Post by kstrauser »

fiddlerwoaroof wrote: post #53
kstrauser wrote: post #33

Earlier quoted context omitted.

Rust pissed me off until I stopped fighting it. When I finally gave up and started doing things its way, it became a lot more fun. And `cargo clippy` is flat-out helpful for learning Rust’s idioms. While I’m not yet out to rewrite all the things in Rust, I understand the appeal of rebooting archaeological projects with a modern approach.

The thing is, I just don’t want to write programs the way Rust wants me to. Among statically typed languages, Java is the closest to what I want to use but my true love is Common Lisp. With the arrival of Coalton, I can get the best of both worlds: a type system with nice properties for the rare program that would benefit from them and CL for the majority of programs.

Alright, so when I’m appointed Lord Emperor, we’ll all be writing CL. Until then, I’m digging Rust. It’s like garbage collection, but where you can always tell exactly when a thing is going to be collected.

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

#72

Post by carterschonwald »

fiddlerwoaroof wrote: post #53
kstrauser wrote: post #33

Earlier quoted context omitted.

Rust pissed me off until I stopped fighting it. When I finally gave up and started doing things its way, it became a lot more fun. And `cargo clippy` is flat-out helpful for learning Rust’s idioms. While I’m not yet out to rewrite all the things in Rust, I understand the appeal of rebooting archaeological projects with a modern approach.

The thing is, I just don’t want to write programs the way Rust wants me to. Among statically typed languages, Java is the closest to what I want to use but my true love is Common Lisp. With the arrival of Coalton, I can get the best of both worlds: a type system with nice properties for the rare program that would benefit from them and CL for the majority of programs.

Yeah, there’s enough ways that rust makes really tedious choices in generics, type system stuff, and its particular flavors of affine memory as a resource logic that I’m considering building my own wee language.

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

#73

Post by verall »

bsdpufferfish wrote: post #52
lifthrasiir wrote: post #46

Earlier quoted context omitted.

Don't we consider a C/C++ replacement "successful" when it was able to capture enough share of prior C/C++ uses, not the entire share? I never thought C or C++ could be completely gone out of sight, even COBOL is technically alive today (on life support). To be clear, I meant that D could have been in the position of Rust today if done right.

Yes, by that criteria C++ was successful over C. And C was successful over fortran. There are small communities that prefer the older stuff, but they were better enough to move the entire industry. D isn't, and neither is Rust. > I meant that D could have been in the position of Rust today if done right. My point was Rust is just a completely different audience. I suppose D could have sold itself as a better JavaScri…

I think you're correct for D, but for Rust, we'll see. It's a very slow moving industry. I do C++ work all day (embedded) and while there's no current plans to move to Rust (which means it won't happen within the next 3-5 years), I could see it occurring someday.

We're finally (usually) allowed to use C++17. I had to use C++03 at times circa 2019 - we're finally done with that. It's _really_ slow moving.

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

#74

Post by nwallin »

emrah wrote: post #20

Are there any examples of forks going in a different direction than the original and being (more) successful?

X.Org. (if you know what X is, you are familiar with X.Org, which is a fork of XFree86)

Chromium is a fork of Webkit which is a fork of KHTML. If you use a web browser, that browser is either Firefox or a fork (of a fork) of KHTML. I don't know what percentage of Chromium/Webkit users have heard of KHTML, but I'd recon it's on the order of 1%.

mplayer used to be a very popular, very good media player, mostly for linux but it was cross platform. Development sort of died. These days its fork mpv is much more common.

There used to be many different forks of GCC. In 1997, all of these developers merged their forks together into the EGCS project. This project proved to be very active and very...good. It was so good that the FSF halted development on mainline GCC, forked EGCS into the new mainline GCC, and restructured the community built around the ideas of the EGCS community. If you use GCC, this is the version you use; forked from GCC into EGCS, forked from EGCS back into GCC.

MacOS' kernel is a fork of FreeBSD. Much of its userspace is a fork from ... somewhere. If you use MacOS it's forks all the way down.

Kindle is forked from Android and/or linux and/or... well it's complicated. Amazon forked a lot of stuff.

Much of the Android ecosystem has been forked. OpenSSL was forked into Tink, for instance. Again, complicated, lots of forks.

yt-dlp was forked from youtube-dl when ... the lawyers came.

Ubuntu is a fork of Debian.

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

#75

Post by Narishma »

lifthrasiir wrote: post #54
nordsieck wrote: post #45

Earlier quoted context omitted.

> It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. Do you have an opinion on how the GC schism within D affected it competitively with regards to C/C++?

While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer th…

What about the situations where you don't want the memory overhead of the GC?

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

#76

Post by notyoutube »

nwallin wrote: post #74
emrah wrote: post #20

Are there any examples of forks going in a different direction than the original and being (more) successful?

X.Org. (if you know what X is, you are familiar with X.Org, which is a fork of XFree86) Chromium is a fork of Webkit which is a fork of KHTML. If you use a web browser, that browser is either Firefox or a fork (of a fork) of KHTML. I don't know what percentage of Chromium/Webkit users have heard of KHTML, but I'd recon it's on the order of 1%. mplayer used to be a very popular, very good media player, mostly for linu…

I'm not sure the distinction is that clean, but isn't ubuntu still based off debian. As in, not a fork that went its own way, but a (big) collection of modifications on top of current debian?

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

#77

Post by nwallin »

fiddlerwoaroof wrote: post #27
TillE wrote: post #9

Earlier quoted context omitted.

I think the fundamental problem with D is much simpler than that, it's the technical context. D is a better C++, but it's not better enough to escape the gravitational pull of C++. Rust is sufficiently compelling, with its focus on memory safety.

Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting

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 the main developer is...a cowboy. Everything is insane. Not only is new/delete everywhere, but so is malloc/free. In C++ code. You have to navigate to where the thing is allocated to figure out whether to use free or delete. Everything leaks, everything crashes, everything races, everything deadlocks.

Oh and the guy is my boss.

So on the one hand, rust might fix these problems, on the other hand, rust is a non-starter.

So now what. I still don't need rust because I don't code like a crazy person. And the people who do code like crazy people will never use it anyway because it doesn't let them...express themselves.

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

#78

Post by nwallin »

notyoutube wrote: post #76
nwallin wrote: post #74

Earlier quoted context omitted.

X.Org. (if you know what X is, you are familiar with X.Org, which is a fork of XFree86) Chromium is a fork of Webkit which is a fork of KHTML. If you use a web browser, that browser is either Firefox or a fork (of a fork) of KHTML. I don't know what percentage of Chromium/Webkit users have heard of KHTML, but I'd recon it's on the order of 1%. mplayer used to be a very popular, very good media player, mostly for linu…

I'm not sure the distinction is that clean, but isn't ubuntu still based off debian. As in, not a fork that went its own way, but a (big) collection of modifications on top of current debian?

Sounds like a fork with extra steps.

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

#79

Post by lifthrasiir »

Narishma wrote: post #75
lifthrasiir wrote: post #54

Earlier quoted context omitted.

While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer th…

What about the situations where you don't want the memory overhead of the GC?

Again, the answer depends on whether you absolutely don't want that or just want to minimize that. I believe something like `@explicitgc` is enough annoyance to make sure that you are conscious about GC and memory allocation. If you need even more guarantee, you have to make sure that everything you transitively call is i) marked as `@explicitgc` and ii) has no GC call inside. Given enough demand you may have both `@nogc` and `@explicitgc` as well, but I think the hard guarantee is not something usually want.

Maybe you wanted me to answer about some magical sauce that can conveniently avoid such issues, but I want to make a point that there is no such thing. In fact, Rust is praised for its strictness about memory safety, but that owes much to the existence of `panic`, and you know what? What I've described earlier equally applies to the `panic` behavior in Rust. You can not avoid panicking in Rust, though you can avoid panicking as much as possible and make `panic` immediately fail to avoid any further overhead, so you are liable for any panicking in your code. In the same way, if you really don't want to touch GC you are in the minority and should be served well with a placeholder GC that always fails. Anything beyond that is not something you can't expect from mainstream programming in the near future.

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

#80

Post by satvikpendem »

fiddlerwoaroof wrote: post #68
satvikpendem wrote: post #61

Earlier quoted context omitted.

Then I guess you don't have to write Rust? It seems like it doesn't solve any new problems for you so don't feel forced or pressured to use it (for any technology, really), and I say this as someone who really likes and uses Rust.

Yeah, what’s frustrating is (a) I wanted to like it; (b) it’s taking up a lot of the job market relative to other alternative languages I’d rather use; and (c) I like the language Graydon describes as “the language I wanted” https://graydon2.dreamwidth.org/307291.html

Seems like you want something like OCaml then.
Post reply on HN