arendjr

joined 8 months ago
sorted by: new top controversial old
What are your favorite statically typed, compiled, memory safe programming languages? in c/programming
[–] arendjr 1 points 1 month ago

Modern C++ does use references, which can also reference memory that is no longer available. Avoiding raw pointers isn’t enough to be memory safe.

Zig vs Rust. Which one is going to be future? in c/programming
[–] arendjr 8 points 1 month ago

Try browsing the list of somewhat recent #CVE rated critical, as I just did to verify. A majority of them is not related to any memory errors. Will you tell all them “just use a different programming language”?

I'm sorry, but this has been repeatedly refuted:

And yes, they are telling their engineers to use a different programming language. In fact, even the NSA is saying exactly that: https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/

It doesn’t come out today, it’s been there for a long time, and it’s standardized, proven and stable.

This seems like an extremely short-sighted red herring. C has so many gaps in its specification, because it has no problem defining things as "undefined behavior" or "implementation defined", that the standard is essentially useless for kernel-level programming. The Linux kernel is written in C and used to only build with GCC. Now it builds with GCC and LLVM, and it relies on many non-standard compiler extensions for each. The effort to add support for LLVM took them 10 years. That's 10 years for a migration from C to C. Ask yourself: how is that possible if the language is so well standardized?

Zig vs Rust. Which one is going to be future? in c/programming
[–] arendjr 2 points 1 month ago

Great suggestions! One nitpick:

But in principle I find this quite workable, as you get to write your CI code in Rust.

Having used xtask in the past, I’d say this is a downside. CI code is tedious enough to debug as it is, and slowing down the cycle by adding Rust compilation into the mix was a horrible experience. To add, CI is a unique environment where Rust’s focus on correctness isn’t very valuable, since it’s an isolated, project-specific environment anyway.

I’d rather use Deno or indeed just for that.

Zig vs Rust. Which one is going to be future? in c/programming
[–] arendjr 10 points 1 month ago* (last edited 1 month ago) (1 children)

No, OP asked for a black and white winner. I was elaborating because I don’t think it’s that black and white, but if you want a singular answer I think it should be clear: Rust.

Zig vs Rust. Which one is going to be future? in c/programming
[–] arendjr 13 points 1 month ago* (last edited 1 month ago) (3 children)

I would say at this point in time it’s clearly decided that Rust will be part of the future. Maybe there’s a meaningful place for Zig too, but that’s the only part that’s too early to tell.

If you think Zig still has a chance at overtaking Rust though, that’s very much wishful thinking. Zig isn’t memory safe, so any areas where security is paramount are out of reach for it. The industry isn’t going back in that direction.

I actually think Zig might still have a chance in game development, and maybe in specialized areas where Rust’s borrow checker cannot really help anyway, such as JIT compilers.

“Truly Hygienic” Let Statements in Rust in c/rust
[–] arendjr 2 points 1 month ago

Ah yes, exactly.

“Truly Hygienic” Let Statements in Rust in c/rust
[–] arendjr 2 points 1 month ago (2 children)

Runtime performance is entirely unaffected by the use of macros. It can have a negative impact on compile-time performance though, if you overdo it.

Should I choose Ada, SPARK, or Rust over C/C++? in c/ada
[–] arendjr 1 points 1 month ago

Might be relevant to mention that Rust has formal verification methods available as well, similar to SPARK, but also optional. One that looks pretty appealing is this one: https://verus-lang.github.io/verus/guide/overview.html

Avoiding if-else Hell: The Functional Style in c/programming
[–] arendjr 20 points 1 month ago (1 children)

While I can get behind most of the advice here, I don’t actually like the conditions array. The reason being that each condition function now needs additional conditions to make sure it doesn’t overlap with the other condition functions. This was much more elegantly handled by the else clauses, since adding another condition to the array has now become a puzzle to verify the conditions remain non-overlapping.

When happy teams are an issue in c/programmer_humor
[–] arendjr 5 points 2 months ago (1 children)

I find Linear to be reasonably pleasant.

When happy teams are an issue in c/programmer_humor
[–] arendjr 45 points 2 months ago (1 children)

Issue resolved

B-Trees: More Than I Thought I'd Want to Know in c/data_structures
[–] arendjr 2 points 2 months ago

I mentioned it in the first comment:

the reason I tend to recommend B-Tree maps over hash maps for ordinary programming is consistent iteration order. It is simply too easy to run into a situation where you think iteration order doesn’t matter, but then it turns out it does in some subtle unforeseen way.

I’m not talking about bugs in the implementation of the map itself, I’m talking about unforeseen consequences in the user’s code since they may not anticipate properly for the randomness in iteration.

10
GritQL integration progress · Biome.js (github.com)
submitted 7 months ago by arendjr to c/programming
0 comments fedilink
 

Just a progress update on a fun open-source project I'm involved with. Biome.js is a web toolchain written in Rust, and it provides a great excuse to play around with parsing technologies and other fun challenges :)

247
Productivity of Rust teams at Google (programming.dev)
submitted 7 months ago* (last edited 7 months ago) by arendjr to c/rust
124 comments fedilink
 

Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”

In small print it says the data is collected over 2022 and 2023.

147
Auto-reviewing AI bots are fun! (programming.dev)
submitted 7 months ago by arendjr to c/programming
12 comments fedilink
 
11
Unused lifetime parameter -- except it isn't (self.rust)
submitted 8 months ago by arendjr to c/rust
5 comments fedilink
 

I have a fun one, where the compiler says I have an unused lifetime parameter, except it's clearly used. It feels almost like a compiler error, though I'm probably overlooking something? Who can see the mistake?

main.rs

trait Context<'a> {
    fn name(&'a self) -> &'a str;
}

type Func<'a, C: Context<'a>> = dyn Fn(C);

pub struct BuiltInFunction<'a, C: Context<'a>> {
    pub(crate) func: Box<Func<'a, C>>,
}

error[E0392]: parameter `'a` is never used
 --> src/main.rs:7:28
  |
7 | pub struct BuiltInFunction<'a, C: Context<'a>> {
  |                            ^^ unused parameter
  |
  = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData`

For more information about this error, try `rustc --explain E0392`.
error: could not compile `lifetime-test` (bin "lifetime-test") due to 1 previous error
13
Writing exhaustive switch statements in TypeScript (arendjr.nl)
submitted 8 months ago by arendjr to c/typescript
5 comments fedilink
 

Today I'm sharing a little trick that I like to use to make switch statements cleaner and more type-safe. Happy to hear other ideas!

21
In search of a better Bevy UI (arendjr.nl)
submitted 8 months ago by arendjr to c/rust
3 comments fedilink
 

As part of my Sudoku Pi project, I’ve been experimenting with improving the Bevy UI experience. I’ve collected most of my thoughts on this topic in this post.

6
A Deep Dive Into Fiberplane's Operational Transformation (fiberplane.com)
submitted 8 months ago by arendjr to c/programming
2 comments fedilink
 

I wrote a post about how our Operational Transfomation (OT) algorithm works at Fiberplane. OT is an algorithm that enables real-time collaboration, and I also built and designed our implementation. So if you have any questions, I'd be happy to answer them!

view more: ‹ prev next ›