Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Is Best (2025)

sqlite.org

Post reply on HN
Print view View original

101–110 of 574 posts

Re: C Is Best (2025)

#101

Post by giancarlostoro »

alexpadula wrote: post #64
nu11ptr wrote: post #51

I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old tha…

I agree. We will see how Limbo turns out :)

I forgot what Limbo was, Rust rewrite of SQLite, now called Turso.

https://github.com/tursodatabase/turso

I could see it being useful for pure Rust projects once its completed. I mean in Java / Kotlin land, I prefer to use H2 in some cases over SQLite since its native to the platform and H2 is kind of nice altogether. I could see myself only using this in Rust in place of SQLite if its easy to integrate and use on the fly.

Re: C Is Best (2025)

#102

Post by kstrauser »

assimpleaspossi wrote: post #70
publicdebates wrote: post #37

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language. But I don't see Rust ever goin…

Calling C "strange" for being conservative and not wanting to break things is rather odd. It's one of the "great" things in that sense. "Stable" could be another description.

Depends on what it’s unwilling to break. “The compiler generates code that segfaults when you multiply 13 * 37, but someone found a way way to trap it and used that as a faster way to make syscalls on Prime minicomputer, so we had to add -ffix-four-eight-won, which the original implementor misspelled in 1993 so we can’t fix that, either, for backward compatibility.”

Some of its actual weirdnesses seem no less odd than that to people who aren’t C experts, I assure you.

Re: C Is Best (2025)

#105

Post by hmry »

MeetingsBrowser wrote: post #80
Ragnarork wrote: post #63

> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language. Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++…

> It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics? I've only seen it done for C++ that is more C than C++, or for libraries that were designed to "bail out" to a C interface.

That's definitely true. Can't have generics / compile time evaluation across languages. Need to design your code around that restriction ahead of time. SQLite being dynamically typed luckily doesn't have any problems with that.

I've actually run into a similar problem with a C library before, because it heavily used macros as part of its API. Glad most developers don't do that.

Re: C Is Best (2025)

#106

Post by nicoburns »

przmk wrote: post #85
nicoburns wrote: post #49

Earlier quoted context omitted.

> SQLite is never gonna be rewritten by its creators in another language. Almost certainly correct. It is however being rewritten in Rust by other people https://github.com/tursodatabase/turso . This is probably best thought of as a seperate, compatible project rather than a true rewrite.

I'm biased but when I see Discord as the only way of communication, it doesn't make for a serious project. I wish more projects would rely on IRC/Matrix + forums.

For better or worse, plenty of serious projects are using Discord for communication. It's not great, but IRC and Matrix have their own problems (IMO Zulip is the best of the bunch, but doesn't seem to be particularly widely adopted).

Re: C Is Best (2025)

#108

Post by baq »

baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

I mostly agree, but the OOP is most definitely not in vogue on HN for the past decade at least, arguably far longer than that (think Rust pre-1.0, Go 1.0 times).

Re: C Is Best (2025)

#109

Post by Drew_ »

> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM.

As someone who runs into this problem a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite?

Re: C Is Best (2025)

#110

Post by gwbas1c »

nu11ptr wrote: post #51

I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old tha…

Honestly, instead of porting SQLite to Rust, IMO, it makes more sense to make an easier-to-use embedded database (in Rust) first.
Post reply on HN