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

451–460 of 574 posts

Re: C Is Best (2025)

#451

Post by orf »

samiv wrote: post #315
thisislife2 wrote: post #300

Earlier quoted context omitted.

I am not well-versed in this area but have a doubt - when the OS sends a SIGKILL to a process because it has run of memory for it how can the program catch that before it is killed and deal with it "gracefully"? Does C provide any mechanism to deal with such scenario?

There are several levels here. In your C++ (or C) program you have one (or more) allocators. These are just pieces of code that juggle blocks of memory into smaller chunks for the program to use. Typically the allocators get their memory from the OS in pages using some OS system call such as sbrk or mmap. For the sake of argument, let's say I write an allocator that has a limit of 2MiB, while my system has 64Gib or R…

None of that matters: what is your application going to do if it tries to allocate 3mb of data from your 2mb allocator?

This is the far more meaningful part of the original comment:

> and furthermore most code is not in a position to do anything other than crash in an OOM scenario

Given that (unlike a language such as Zig) Rust doesn’t use a variety of different allocator types within a given system, choosing to reliably panic with a reasonable message and stack/trace is a very reasonable mindset to have.

Re: C Is Best (2025)

#452

Post by tialaramex »

kibwen wrote: post #441
usefulcat wrote: post #156

Earlier quoted context omitted.

And it remains to be seen how well this approach will work as time passes and the number of versions continues to increase.

That won't be any more of a problem than the support that every existing C or C++ compiler has for targeting different versions of the standard.

Right, it's not considered weird for a C++ compiler to offer C++ 98, C++ 11, C++ 14, C++ 17, C++ 20, C++ 23 and C++ 26 (seven versions) and support its own extra dialects.

It is also usual for the C++ compilers to support all seven standard library versions too. Rust doesn't have this problem, the editions can define their own stdlib "prelude" (the reason why you can just say Vec or println! in Rust rather than their full names, a prelude is a set of use statements offered by default) but they all share the same standard library.

core::mem::uninitialized() is a bad idea and we've known that for many years, but that doesn't mean you can't use it in brand new 2024 Edition Rust code, it just means doing so is still a bad idea. In contrast C++ removes things entirely from its standard library sometimes because they're now frowned on.

Re: C Is Best (2025)

#453

Post by locknitpicker »

bigfishrunning wrote: post #253
munksbeer wrote: post #230

Earlier quoted context omitted.

Out of interest > As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language. After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there w…

I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.

> I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods.

This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to get anyone at a proficient level.

This claim is so outlandish that I'm inclined to dismiss it entirely as completely made-up. There is no project manager in the world who would even entertain this thought.

Re: C Is Best (2025)

#454

Post by LexiMax »

jcranmer wrote: post #136
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.

When clang was first coming about, the number one cause of Debian packages failing to build with clang was that (at the time) clang defaulted to C99 whereas gcc defaulted to C89.

I'm going to guess that most of those issues were caused by implicit declarations no longer being valid.

    int main() {
        printf("Sans headers, this is valid C89.");
        return 0;
    }
Without an explicit declaration, C will consider this function to have the following signature based on the call site:

    int printf();
By the way, in C () doesn't mean "no parameters" it means "any parameters, which the compiler will infer from the call site and pass to the function."

Re: C Is Best (2025)

#455

Post by locknitpicker »

shevy-java wrote: post #212
bigfishrunning wrote: post #186

Earlier quoted context omitted.

I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like we…

Kotlin won't replace Java. They do not have the same niche.

> Kotlin won't replace Java. They do not have the same niche.

Claiming Java has a niche is very funny. I guess the niche is programmable computers? Well done.

Re: C Is Best (2025)

#456

Post by aw1621107 »

cladopa wrote: post #231
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…

The great thing about C is that is was not designed by a committee at all. It was designed by a person with strong opinions. This means it is really great for what it does well(what the author was interested in). To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee. If you look at the structure of C++ in Backus Naur form it is abs…

> To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee.

This comparison confuses me because C is... also controlled by a committee? The evolution of the C standard is under the control of ISO WG14 [0], much like how the C++ standard is under the control of ISO WG21 [1]. This was true for even the first versions of each language that was standardized.

[0]: https://www.open-std.org/jtc1/sc22/wg14/

[1]: https://www.open-std.org/jtc1/sc22/wg21/

Re: C Is Best (2025)

#457

Post by orf »

koakuma-chan wrote: post #445
smj-edison wrote: post #434

Earlier quoted context omitted.

Well if you've hit OOM, you're kinda screwed anyways. But, if you allocate a ring buffer at the beginning, you can always do a best attempt write.

Why screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?

You need to apply backpressure before you hit memory limits, not after.

If you’re OOM your application is in a pretty unrecoverable state. Theoretically possible, practically not.

Re: C Is Best (2025)

#458

Post by IshKebab »

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy.

I don't think they thought about this too much. In the C code are they testing the "branch" into Undefined Behaviour?

Re: C Is Best (2025)

#459

Post by IshKebab »

alexpadula wrote: post #43
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…

Uh oh! I think Rust may settle down eventually. Who knows, maybe one of the devs will chime in.

It's pretty settled now.

Re: C Is Best (2025)

#460

Post by IshKebab »

uecker wrote: post #218
MeetingsBrowser wrote: post #172

Earlier quoted context omitted.

The original comment was edited after I replied.

Yes, sorry, apparently not quick enough. I actually do not think it is horrible. It is a nice language, but I still do not like it and see many downsides. What I hate though is how aggressively it is marketed. See my other response for details.

Nobody is marketing it. It doesn't have a marketing budget. What you're seeing are lots of people that really like it because it's really good. Not flawless obviously but a significant improvement on C and C++.
Post reply on HN