Hacker News Reader

Comment by WalterBright | Hacker News Reader

I've been working on a method for adding ownership and borrowing to the D programming language, and people kept asking me to explain how it works, so I wrote this article about it. I had originally thought it would be impossible to add this to D, but the more I thought about it, the more tractable the problem became.

View on HN

Not to go too far off topic, but I just wanted to say how much I've been initially pleased with D.

For a long time I've wanted a language that I could use with just a text editor and the command prompt or terminal.

I've been able to get programs to easily compile on both my Linux home and windows work machine without any complex install magic as it should be in my opinion. The programs produced were binary executables and tiny to boot (especially Windows where HelloWorld was ~367 KB iirc and ~1.1 MB on Ubuntu).

It is nice to not need an in-depth understanding of the JVM or CLR. The hardest part for me (I usually favor languages like Python) is not having a REPL, but I'll live.

The one place where I could use some help (similar to most of the advanced languages... although Rust is good here) is in the documentation which is more meant for power users than onboarding new folks. Compare and contrast the Nim section on types with D's classes/structs/unions. The D documentation is more like a reference manual and Nim is more tutorial. I think I'll try Andrei's book and see if that gets me far enough to where the technical doc becomes straightforward.

On another note, I see D has some functional programming support. If possible, I'd like to avoid having to model my own domain logic with OO classes. Is the proper way to do this with structs and the stdlib's map!, fold!, & filter! constructs.

Sorry for rambling!

Hey Walter, I really admire your work. I'm curious though, do you think D is potentially in danger of trying to do too many things? No one wants another mess like C++.

I do not think it is in danger, it already does too many things that make it a complex language. Similar with Object/Free Pascal and to some extent C# and certainly others i cannot think of right now.

These languages are like horses running on a straight line towards maximum complexity. It is just that C++ is at the front right now, but no horse has any inclination of stopping.

The Oberon language is an exception, it goes the other direction.

https://www.miasap.se/obnc/oberon-report.html

Isn't Go inspired by Oberon? That would explain some things.

Yes, the method syntax comes from Oberon-2, unsafe package is similar to SYSTEM on Oberon.

The rest comes from Limbo (Inferno's userspace language).

Unfortunately it also left a couple of other nice things from those languages.

Not an exception really, there are many simple languages and Oberon-07 (the dialect linked) is indeed an extremely simple one. Go is another language that is simple. And of course C (that compiler developers abuse undefined behavior to win artificial benchmark games and making the life of everyone using C for practical purposes miserable is not a problem with the language itself but with the compilers that do such abuse).

EDIT: Scheme too, at least up to R5RS.

What sets Oberon apart is that it has become smaller and simpler over time, something which is not true for the languages you mention.

This depends on if you see Oberon-07 as a different "version" of Oberon or as a different dialect belonging to the same family. Personally i see it as a different dialect instead of being the same language exactly because it removes functionality and isn't compatible with it.

It may not seem like a big difference, but it becomes more apparent when you consider how different all the Pascal dialects that are out there - some even from Niklaus Wirth himself - are.

Also IMO languages should not break backwards compatibility.

For me the best version of it was Active Oberon, but I guess Wirth wouldn't agree given its pursuit for minimalism.

Also I doubt he would bother to any further updates to Oberon-07 (2016 rev). Most likely busy with other matters nowadays.

Wirth — at the age of 85, no less! — is actively working on Oberon stuff, like the compiler. Here's his "news" file, which is up to date as of May 31, 2019:

http://people.inf.ethz.ch/wirth/news.txt

Oh! Thanks for the heads up.

Are there shops that will take advantage of this stuff by limiting what features they use and following a certain style? For ex would a C++ team use some functional approach or a Rust style approach to ownership etc? Or it always just a mishmash?

That's an ever present danger. We've been a bit more willing than C and C++, however, to discard some bad decisions.

Nice article as always. I don't think I fully grok this stuff (in other languages I've read about too). Perhaps you can help me have some clarity of thought.

1. What should I do when I want to make a data structure like a doubly linked list or a graph - ie one where multiple pointers point to the same object?

2. Memory is only one kind of resource where ownership needs to be tracked. Others include file handles, network sockets etc. Can you comment on whether the OB mechanism solves the problem in general, or is mainly for memory tracking?

You could make the entire thing `const` and operate in a purely functional fashion - though this approach might be absurd in the context of systems programming (I can't claim to know as I've no background in the area whatsoever.

How do you make an immutable doubly linked list?

Build it, then cast it to immutable in @system annotated code.

From the article: use 'system' annotation (the equivalent of unsafe in Rust)

1. This is, of course, a well known problem with an O/B system. The usual resolution is to a) use another data structure or b) hide the double linked list in @system code and use a safe interface to it.

2. It's a general solution (not limited to memory).

There's an article that focuses on number one:

https://rust-unofficial.github.io/too-many-lists/

I propose doing anything super hard and rare outside the general model. Make the doubly-linked list in whatever tool supports easy verification. Things like Why3 and solvers for separation logic. Run that object code through lots of testing with runtime checks for the specified behavior. If it passes, it's probably earned the right to be wrapped for use in the memory-safe code.

This use case is also why I prefer more research funding to go to verified solvers than to manually-verified algorithms. They'll get more real-world use on hard problems. Well, that and test generators. They complement each other. The testing tools are more cost-effective, too.

I will forever remember D as the book that was on the main characters bookshelf in Office Space.

Reply on news.ycombinator.com