Our great sponsors
-
llvm-project
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Through value tracking. It's actually LLVM that does this, GCC probably does it as well, so in theory explicit bounds checks in regular C code would also be removed by the compiler.
How it works exactly I don't know, and apparently it's so complex that it requires over 9000 lines of C++ to express:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Anal...
The compiler can actually get pretty fancy with its analysis. See "https://github.com/Shnatsel/bounds-check-cookbook" for details. In your case though, I don't think its necessary to get that fancy?
Whatever routine that checks if the number of fields is correct can return a slice of fields. Then you can iterate over that slice, which doesn't require any more bounds checking than the equivalent for loop in C would. If you need to access the slice in a more complicated manner than simply looping forward over it field by field, then the bounds check cookbook could be useful.
Not sure if this is helpful because I don't know the details of your case.
As already mentioned, bounds checks won't necessarily cause that much overhead. When I rewrote my small image processing library from C to Rust ([1]), I only had to use unchecked array access in one hot loop to get overall performance equivalent to C code.
[1] https://github.com/GreatAttractor/libskry_r
> C/C++ can be made memory safe
.. but it's much harder to prove your work is memory safe. sel4 is memory safe C, for example. The safety is achieved by a large external theorem prover and a synced copy written in Haskell. https://github.com/seL4/l4v
Typechecks are form of proof. It's easier to write provably safe Rust than provably safe C because the proofs and checker are integrated.
> your arguments against Rust come off as biased.
Yes, I'm pretty aware of this, and I keep this bias voluntarily, because Rust is generally touted (hyped?) as a Silver Bullet, and I'm wary of Silver Bullets. So, I want to highlight that fact.
> Sorry if I came across as rude.
No hard feelings. As I said, I'm not under delusion of a perfect life. I just said it.
> I just find it slightly puzzling how your stance on it is kind of going up and down. :)
I have a habit of mirroring the tone of the person I'm talking with. Combine it with the fact that English is not my native language, it's possible that "tone adjustment" is far from perfect.
> it's been quite a while since I've seen Rust zealotry on HN...
Yes, there's no zealotry here, and it's great, but I'm exposed to a wider community than HN people. Unfortunately, HN represents very small percent of the programmers around. A great talk I like about this issue is Robert Martin's "What Killed Smalltalk Could Kill Ruby, Too" [0]. Let's say, I'm marred and bitter from tons of zealotry and flamewars over the years (yes, I'm not young folk).
> While that likely does wonders for your mental health... [Snipped for brevity]
First of all, thanks. I pray that you work in a place you love and never work again. I'm very aware that how being solo makes me different and biased, and I think I highlighted at a couple of places.
On the other hand, I understand what teams and team-related activities are important for code quality. Let's say that I work as a team of two people. Current me knows everything about code, and my future me which inherits that code. So, I always code and comment for my future self, who doesn't know anything about the code. I always sharpen my axe, and try to improve myself as a "team of one". My personal state of the art of this practice is at [1]. I'll reflect what I have learnt from this project to the next one. The fact is while I do extensive C++ testing, I yet to pick up Go's testing abilities. That'll be the next step probably.
> Tinkering is nice and all but I'd probably make your life living hell if I had to review your PRs. :D
Give it a look at [1], and maybe [2], and let's have a chat again. I'm not perfect, for sure, but I think I'm no basement dweller when it comes to code and docs quality. :D
> OK, that's valid but I'd still urge you to reassess your opinion of the Rust community.
As a recovering grumpy, I'll do. I don't like to be bitter grampa (to be). I'm fine with the grampa part, but not with the bitter part.
> No harm done IMO, and I don't think that I disagree strongly with anything you said.
Same, no hard feelings here. I can say that you're good sport even, and I don't use this lightly. I enjoyed what you wrote and writing this comment.
> I am mostly saying that you working what you love and working solo is keeping you quite disconnected from what are good team practices.
Of course, but I'm trying to incorporate the good practices I can use as a team of two (as aforementioned). Also, I'm mingling with more Free Software teams than I might show.
> Maybe you have a compiler in your brain as you have alluded to but I will trust a good test suite over a human brain every day.
I'll trust my brain first, then evaluate that with the compiler, then evaluate the end product with a good test suite. Then feed what I learnt to myself, so I don't repeat the same mistakes as much as I can. My intuition gives me perspective, but I always operate on the assumption that I'm the worst programmer in the universe (no kidding).
[0]: https://www.youtube.com/watch?v=YX3iRjKj7C0
[1]: https://git.sr.ht/~bayindirh/nudge
[2]: https://github.com/TRUBA-HPC/lssrv