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

491–500 of 574 posts

Re: C Is Best (2025)

#491

Post by smj-edison »

kibwen wrote: post #290
pjdesno wrote: post #238

Earlier quoted context omitted.

> was in unsafe code, and related to interop with C 1) "interop with C" is part of the fundamental requirements specification for any code running in the Linux kernel. If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job. 2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code. This is a fundamental limitation, and again…

> If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job. Rust is no less safe at C interop than using C directly.

As long as you keep C pointers as pointers. The mutable aliasing rules can bite you though.

Re: C Is Best (2025)

#492

Post by jason_oster »

atherton94027 wrote: post #375
erk__ wrote: post #366

Earlier quoted context omitted.

Then it would not be unscientific.

Yeah I mean I could also say "there are no CVEs written in PERL in the kernel ergo PERL is safer to write than Rust". Given there's close to zero .pl files in the kernel, I think we can all agree my assertion holds

That claim relies on an absurd "in the kernel" qualifier, making it difficult to agree with. Furthermore, your hypothesis is that "we all" agree with claims that rely on absurd conditions as a matter of course.

Re: C Is Best (2025)

#493

Post by zbentley »

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…

Limbo and Turso's other tools seem interesting, but the listed limitation of “no multi process database access” is pretty huge.

If you don’t need that, then great—Turso/Limbo might be for you! But there are a ton of use cases out there that rely on SQLite for simultaneous multiprocess access. And I’m not even talking about things that use it from forking servers or for coordination (though those are surprisingly common as well)—instead, lots of processes that use SQLite 99.9% of the time from one process still need it to be multiprocess-authoritative for e.g. data exports, “can I open two copies of an app far enough to get a ‘one is already running’ error?”-type use cases, extensions/plugins, maintenance scripts, etc. not having to worry about cross-process lock files thanks to SQLite is a significant benefit for those.

Re: C Is Best (2025)

#494

Post by cozzyd »

ninkendo wrote: post #468
cozzyd wrote: post #389

Earlier quoted context omitted.

C++ has reasonable dynamic linking (there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11), obviously excluding a lot of metaprogramming features, but a lot of C++ dynamic libraries exist that are widely used. Supposedly Swift does a better job, though I'm not familiar. Yes, Rust can dynamically link with a C ABI (as can any language) but it loses a lot of the expressivene…

> there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11 ABI breaks are everywhere in C++... consider a class class foo { public: foo(); void do_something(); private: int x; } and an impl in the dynamic library: #include "foo.h" foo::foo() { this->x = 0; } void foo::do_something() { std::cout x You build a libfoo.so and clients use it, calling `foo f; f.do_something();`, it…

Sure, you can break ABI in a library, but the compiler doesn't force you to, is what I mean. Same as breaking ABI in C when you change a struct...

Re: C Is Best (2025)

#495

Post by smj-edison »

ruszki wrote: post #170
Supernaut wrote: post #137

Earlier quoted context omitted.

Absolutely. Our thought leaders have been pushing functional programming for a long time now.

Is it possible to have an OOP language which is also functional? Or is it impossible without imperative paradigms?

Gilad Bracha talks about how they're not mutually exclusive concepts, and I mostly agree (OOP can have tailcall recursion and first order functions for example). But, the philosophy seems very different: functional programming is "standing above" the data, where you have visibility at all times, and do transformations on the data. OOP is much more about encapsulation, where you "send a message" to an object, and it does its own thing. So you could totally write OOP code where you provide some core data structures that you run operations on, but in practice encapsulation encourages hiding internal data.

Though on further thought, may be this isn't FP vs OOP, because C has a similar approach of "standing above", and C is the hallmark imperative language.

Re: C Is Best (2025)

#496

Post by smj-edison »

senko wrote: post #410
lelanthran wrote: post #152

Earlier quoted context omitted.

> most code is not in a position to do anything other than crash in an OOM scenario. That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way. You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.

Zig puts OOM handling much more front and center than C. In C, you can handle OOM but it's easy to ignore NULL checks on mallocs &co because they almost never happen. In Zig you must handle it. Even if handling means "don't care, panic", you have to spell that out.

It's also really ergonomic with `errdefer` and `try`.

Re: C Is Best (2025)

#497

Post by arghwhat »

vips7L wrote: post #436
arghwhat wrote: post #359

Earlier quoted context omitted.

I don't agree. First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade". The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Ko…

I think you're widely mistaken if you don't think Java is a platform. The VM and language are intertwined. The VM explicitly knows about things like records, language constructs, and idioms from Java. Java sets the direction of the VM, not Kotlin.

JVM does not know about Java, it knows about an IR that Java, Kotlin, Scala, Closure, Groovy, etc. all target. Java as a language also doesn't know about JVM, as it commonly targets things that are not the JVM, whether that is Dalvik, Graal or something else entirely.

That the JVM and IR has features to help the Java compiler generate better output is obvious but not really relevant. Modern CPUs also have instructions to help C compiles generate better code, but that doesn't make them C platforms. It's just that implementation details.

So no, Java is not a platform. It is a language that sometimes runs on the JVM together with many other large and quite influential languages.

Re: C Is Best (2025)

#498

Post by arghwhat »

locknitpicker wrote: post #450
arghwhat wrote: post #359

Earlier quoted context omitted.

I don't agree. First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade". The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Ko…

> First of all, Java isn't a platform. You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for? > The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable (...) Yes, in the sense that Java exists and Kotlin by design piggybacks on the JVM. > The C → Rust migrations that happen a lot…

> You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?

Java runs on several things that are not the JVM. Android does not use JVM to run Java, and even Oracle is pushing something that is not the JVM.

At the same time, JVM runs many things that are not Java.

If you are somehow implying along the lines of JVM only got initially authored because Java, then that is nothing but a historical fact of little relevance from the early days of the language. If not even Oracle considers Java and JVM one thing - and by virtue of Graal they don't - then it simply isn't as such.

> This analysis is very superficial and fails to identify any of the real world arguments to switch from C

You misread - what you quoted was not an analysis of why the migrations happen. It was a parallel, underlining that migrations do happen in spite of obvious feature differences (and sometimes, because of such differences).

Re: C Is Best (2025)

#499

Post by dkdcio »

alexpadula wrote: post #352
EricRiese wrote: post #285

Earlier quoted context omitted.

SQLite's test suite is proprietary. A Rust implementation exists. It's called turso https://github.com/tursodatabase/turso There's a whole company around it.

Did they rename from Limbo to Torso?

yes, mentioned in https://turso.tech/blog/upcoming-changes-to-the-turso-platfo...

Re: C Is Best (2025)

#500

Post by LexiMax »

donkeybeer wrote: post #159
misnome wrote: post #59

Earlier quoted context omitted.

> strangely and disproportionately pushed on Hacker News There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages. > then those from outside the project shouldn't really have any say on it. It…

I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pushing of say Kotlin or Scala or Go or, etc from their fans.

> I think it's more than just the normal amount for advocacy of a new language.

More than C++? More than Java? More than Python?

Post reply on HN