Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

They are both weak contenders, for the reasons laid out in the article. Go and Rust have large runtimes with lots of dependencies, and Go is not as performant as C.

Literally every system has a C compiler, except maybe for a very small number of very old and niche systems. Assuming it cound fit on the ROM, sqlite could probably be ported to my z80 calculator, which has an 8 bit processor and 128 kiolobytes of RAM - trivially! C runs literally everywhere, which is something no other programming language can lay claim to. For a tool like sqlite there is no other choice, period.

View on HN

Rust has an equivalent amount of runtime to C.

Our platform support is limited by LLVM though, this is a good reason for sure.

Fair, I forgot that Rust has good freestanding support. I still don't think it'd be a good candidate for sqlite, though, for one reason in particular: Rust is not competitive with C on portability.

Which is why Nim would be a good candidate. Compiles to C so has the benefits of its portability, interoperability and speed.

Oh please please no! Nim is almost impossible to debug at a low level and you have no fine-grained control over its performance or behavior. It's also far less well understood than C, which is more boring and the subject of decades of conservative development. I'm also not sure what kind of support nim has for freestanding programs.

Can you elaborate? I've never had problems debugging it, you can use lldb or gdb to do it.

You have a hell of a lot of control over its performance and behaviour. Are there instances where you found that wasn't the case?

As far as the understanding of C goes, I can agree with that. But we are discussing rewriting sqlite in something else after all.

Maybe you can reach out via email, it's in my profile. I'd rather not tear into Nim in this thread, we're getting pretty off-topic.

Done.

Doesn't it come with GC? That would limit embedding.

That's true. You do have the option to disable it though.

Seeing as Go was suggested above (which is also garbage collected), I figured I would mention Nim too.

Interesting. I love programming in Nim but I'm not sure if I would consider developing something like SQLite in Nim. It still has a few rough edges IMHO.

> It still has a few rough edges

Love to hear what those are and what language you would consider developing SQLite in.

I'm nowhere near technically competent to develop something like SQLite in any language. Richard Hipp is a legend unto himself.

But, I tried working in Nim without GC and out turned out to be a bigger hassle than I expected it to be. GC was supposed to be ref counted and now they're doing memory regions? There is also a -gc:stack which I'm not sure if it works the way like in C++. Then there is the pointer free paradigm. Don't get me wrong, I'm very optimistic about Nim and would be great if it really replaces C. But I feel like it's doing too many things at once.

I personally feel like Nim dev team should stop adding new features every release and work on releasing a solid 1.0.

Yes, agreed. It's not a real answer yet, but mrustc can compile Rust to C, so if this becomes a really huge blocker, we could put in some elbow grease and make it a real answer. The question is mostly "is that worth the time or not?"

I was under the impression that the support for unrecoverable errors via panic! creates a runtime structure (allowing for the explicit release of resources) which is not typically present in C programs (unless manually included).

Honestly, "runtime" is just a complex word in general, like, most people refer to C as having "no runtime" even though it does.

Regardless, those are called "landing pads", and you can compile with an option to turn them off. Many do.

Reply on news.ycombinator.com