Hacker News Reader

Comment by mhh__ | Hacker News Reader

The main issue with the nogc and nothrow flags is people taking a feature designed for careful consideration, and using them for building from-scratch code with often no philosophy other than a vague and usually completely unfounded mental model where GC == slow.

Write the code first then measure it.

View on HN

Agreed and I actually don't really care about the GC speed. I mostly use arenas / object pools and you can do that with or without GC.

Sort of undecided on the exceptions though. The Result / Option type in Rust is pretty nice to use (and !?*T in Zig, which is nicer if you ask me). It forces you to handle exceptions explicitly which is pretty nice and you can be sure there is no overhead introduced by the compiler for handling exception stuff.

I'd probably wrap all the exception throwing functions in my D codebases with Result type if we had language level support for sum types and match syntax. I know we have it in the standard library, I want it in the language with nicer syntax.

I also want the GC to be replaced with deterministic destruction using RC + ownership analysis and optimizations like Lobster does, but that's wishful thinking territory.

Even if it's small, the Option/Result style exceptions always have overhead in at least a limiting case whereas the unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.

> unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.

D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation?

I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?

If you don't throw there's no overhead, hence Exception-al cases only. The Optional style always has an overhead but the cost of actually throwing is much less.

Lots of people do statically allocate their errors now.

Implementing stack unwinding properly is not trivial.

It's crazier even when you consider how insanely fast the official D Forums render. I'm going to go out on a limb but I kind of doubt Vibe.d is plastered with @nogc everywhere. I am looking forward to the borrow checker being added to D on the other hand, that ought to be a little more interesting.

The official forums don't actually use vibe.d. vibe has the most marketing out of the D web frameworks, followed by hunt, but there's actually a few more too that just don't get as much attention, despite being older and possibly more widely used behind the scenes! The official forum uses the `ae` library. (And I have to mention my own `arsd` library which I'm pretty sure is the oldest web lib - mine dates back to 2008, but ae's pretty old too so he might beat me, and mine actually does better on some benchmarks despite me using GC and such with wild abandon.)

That said though, yeah, I don't think any of them use `@nogc`. I've actually tried to get the gc to interrupt audio code before and couldn't even hear it. I'm sure a bigger heap to scan might cause a problem in some situations, but these fears are really overblown in the popular commentariat.

Agreed. @nogc is useful if you have no a disabled or no-runtime, or in tight loops. Other than that, it's more fruitful to use pools, benchmark the GC, keep scannable heap small.

Reply on news.ycombinator.com