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

261–270 of 574 posts

Re: C Is Best (2025)

#261

Post by samiv »

TZubiri wrote: post #244
samiv wrote: post #203

Earlier quoted context omitted.

Talking as a long time C++ programmer. I really don't get this mind set. First off allocation failure (typically indicated by bad_alloc exception in C++ code, or nullptr in C style code) does not mean that the system (or even the process) as a whole is out of memory. It just means that this particular allocator could not satisfy the allocation request. The allocator could have "ulimit" or such limit that is completel…

>does not mean that the system is out of memory. >"The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations." Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that'…

"Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean."

As I just explained an allocator can have its own limits.

A process can have multiple allocators. There's no direct logical step that says that because some allocator some failed some allocation, the process itself cannot allocate more ever.

"Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development."

The parent comment is talking about over commitment and OOM as if these are situations that are completely out of the programs control. They aren't.

Re: C Is Best (2025)

#262

Post by lelanthran »

zabzonk wrote: post #229
lelanthran wrote: post #162

Earlier quoted context omitted.

> As someone who runs into this problem [OOM] a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite? How are you running into it? If you're writing in C, idiomatic code works (check the return values of functions that allocate!) If you're in C++, Rust or similar, you have to write pretty non-idiomatically to recover from an allocation failure.

how exactly do you think C and C++ differ here?

> how exactly do you think C and C++ differ here?

`new` throws, `malloc` returns. That's a pretty big difference!

Idiomatic C++ code never puts a `try` around `new`, while idiomatic C code always checks the return from an allocation.

Re: C Is Best (2025)

#263

Post by senfiaj »

C is fast and maybe has predictable performance, but, for example, strcmp(), strlen(), strncmp() are not as fast (and also secure) as C++ std::string analogs, unless you don't help a bit by storing the string lengths.

Re: C Is Best (2025)

#264

Post by knowitnone3 »

yomismoaqui wrote: post #176

As an outsider when I read about Rust it seems like it is positioning itself as the language to rewrite things that already work. It's just the simplistic first feeling of a language, in the same way I feel like Go is the language for Kubernetes/cloud/net servers, Ruby is for Rails, JS is the browser/bootcamp language, Python is Data Science and AI... Sure, you get that safety but you are also throwing the stability…

who is this that you are claiming is "positioning" itself??? the Rust maintainers? No. Programmers are choosing to write something in Rust and it just so happens they are interested in rewriting something that already exists because they can. You write as if Rust is an entity that chose to position itself. What is your argument here? Rust should just go do something else? You wouldn't dare say that about Python. Also, how dare you put these languages in a corner. I've use ruby for many things other than Rails. JS is much more than a browser language now, and python is much more than data science and AI. Go is much more than Kubernetes/cloud/net servers.

Re: C Is Best (2025)

#265

Post by vlovich123 »

TZubiri wrote: post #250
pie_flavor wrote: post #44

Earlier quoted context omitted.

The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not e…

Sounds like textbook bc break. I'm curious as to what you think a bc break would look like? Consider python2 and python3, you don't need to update your python2 code really, you can just use the python2 interpreter.

No you’re misunderstanding the ecosystem. Rust 2024 code can call 2021 code without issue (and vice versa I think although could be wrong on the vice versa). So you can progressively update code of individual components as you want or not at all and still continue using it just fine in new code using later editions. Thats the very definition of back compat, something you really really shouldn’t do with C++ (every file should be compiled with the same language version target although practically that may be less of an issue depending on the specific stdlib implementation and if they break ABI)

There’s also automated migration tools to convert 2021 code to 2024. It might fail on some translations but generally it’s pretty automatic.

So huge difference both in the migration mechanism and the bc story.

Re: C Is Best (2025)

#266

Post by alexpadula »

kibwen wrote: post #182
andrepd wrote: post #112

Earlier quoted context omitted.

I'm very much into Rust but this article is precisely about the fact that Rust is not "better in every way"...

This article was written nine years ago, when Rust 1.0 was two years old, by an author who spent a small (but nonzero) amount of time evaluating Rust.

Not true, the page is updated every now and again.

Re: C Is Best (2025)

#267

Post by craftkiller »

dnautics wrote: post #259
kibwen wrote: post #17

Earlier quoted context omitted.

None of Rust's language features allocate; not arrays, not closures, not iterators. Everything is stack-allocated by default. Rust code doesn't malloc unless you use a library that calls malloc; in other words, exactly like C. Rust fully supports turning off the parts of the standard library that perform allocation, and this is precisely what embedded code and the Linux kernel does. So Rust already gives you full con…

you understand that stack allocation can OOM too?

Can C gracefully recover from running out of stack space?

Re: C Is Best (2025)

#268

Post by guywithahat »

ashtonshears wrote: post #166
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…

Rust is pushed on the internet

I definitely wouldn't say internet, I think it's popular on HN and a few other online forums. There are a lot of X/twitter circles which make are critical of rust, as well as other sites.

In my mind at least there's a decent risk Rust is going to end up like the next Haskell, its benefits other than safety are not that clear and many of those features can and have been replicated in other languages.

Re: C Is Best (2025)

#269

Post by smj-edison »

ViewTrick1002 wrote: post #167
koakuma-chan wrote: post #122

Earlier quoted context omitted.

I think this is bullshit. If you are running out of memory, you can, for example, choose to stop accepting more work ("backpressure"). I am always advocating for Rust, but this is one thing I really disagree on. I think Zig gets this right.

Now you need to ensure that your entire error path does not allocate or you have to deal with allocation errors in the error path as well. Trying to apply backpressure from memory allocation failures which can appear anywhere completely disconnected from their source rather than capping the current in memory set seems like an incredibly hard path to make work reliably.

In Zig's case, the entire stdlib never allocates on failure, and most libraries follow the same pattern. The philosophy of Zig is allocation/creation can fail, but freeing/destroying must never fail. It's caused me to be really thoughtful with how I design my data structures, and often made me use better ways of representing metadata.

Re: C Is Best (2025)

#270

Post by vlovich123 »

alexpadula wrote: post #114
publicdebates wrote: post #93

Earlier quoted context omitted.

Sure, Rust can compile old code. But you can't upgrade that old Rust code to new Rust code very easily. The fact that C was effectively "born old" means you can take a C89 program and compile it as C23 and it should simply work, with extremely minimal changes, if any. That's a killer feature when you're thinking in decades. Which SQLite is.

True that!

No not true. cargo fix —edition automatically does most translation to the new edition (most people never see it fail, I’ve seen it fail only on some obscure constructs that it couldn’t do automatically because the meaning of some trait stuff changed subtly but took 2 minutes or less to fix). cargo clippy —-fix will automatically apply linter fixes or warning fixes when it can.

Claiming that editions are an example of rust failing back compat shows a complete ignorance of the ecosystem or what coding in the language is actually like. People in this thread think you can’t mix n match editions or that migrating is some huge unavoidable obstacle. Indeed I have less fear upgrading editions than I do bumping the version of the c or c++ language or even using a newer compiler that exploits accidental UB that had been lurking.

Post reply on HN