charlotte-fyi (u/charlotte-fyi)

charlotte-fyi commented on Java at 30: Interview with James Gosling thenewstack.io/java-at-30... · Posted by u/chhum

bsaul · 3 months ago

i do feel much more comfortable with lifetimes than at the beginning. I get the general concept, and i barely have to explicitely set them (i did start by religiously reading the rust book, of course).

However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes.

The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.

charlotte-fyi · 3 months ago

In my experience, beginners often make the mistake of assuming just because you can do things with references and lifetimes that you should. Unless you’ve done profiling, just start with the easy thing and clone an `Arc` (or whatever other data structure helps you avoid lifetime problems)!

Also, it’s worth saying, you probably don’t need async.

charlotte-fyi commented on Initialization in C++ is bonkers (2017) blog.tartanllama.xyz/init... · Posted by u/todsacerdoti

waynecochran · 3 months ago

This idea that everything must be initialized (i.e. no undefined or non-deterministic behavior) should never be forced upon a language like C++ which rightly assumes the programmer should have the final say. I don't want training wheels put on C++ -- I want C++ do exactly and only what the programmer specifies and no more. If the programmer wants to have uninitialized memory -- that is her business.

charlotte-fyi · 3 months ago

The entire problem is that what the programmer wants to do and what the program actually does isn't always clear to the programmer.

charlotte-fyi commented on Oxide’s compensation model: how is it going? oxide.computer/blog/oxide... · Posted by u/steveklabnik

throwaway81523 · 4 months ago

Is there a 1 sentence description of the model? It wasn't apparent in a minute of scrolling down the long winded blog post.

charlotte-fyi · 4 months ago

"our compensation is not merely transparent, but uniform"

second paragraph

charlotte-fyi commented on Migrating away from Rust deadmoney.gg/news/article... · Posted by u/rc00

pcwalton · 4 months ago

I just don't, and even less often with game logic which tends to be rather simple in terms of the data structures needed. In my experience, the ownership and borrowing rules are in no way an impediment to game development. That doesn't invalidate your experience, of course, but it doesn't match mine.

charlotte-fyi · 4 months ago

The dependency injection framework provided by Bevy also particularly elides a lot of the problems with borrow checking that users might run into and encourages writing data oriented code that generally is favorable to borrow checking anyway.

charlotte-fyi commented on Things Zig comptime won't do matklad.github.io/2025/04... · Posted by u/JadedBlueEyes

rc00 · 4 months ago

> What in particular do you find cumbersome about the borrow system?

The refusal to accept code that the developer knows is correct, simply because it does not fit how the borrow checker wants to see it implemented. That kind of heavy-handed and opinionated supervision is overhead to productivity. (In recent times, others have taken to saying that Rust is less "fun.")

When the purpose of writing code is to solve a problem and not engage in some pedantic or academic exercise, there are much better tools for the job. There are also times when memory safety is not a paramount concern. That makes the overhead of Rust not only unnecessary but also unwelcome.

charlotte-fyi · 4 months ago

Isn't the persistent failure of developers to "know" that their code is correct the entire point? Unless you have mechanical proof, in the aggregate and working on any project of non-trivial size "knowing" is really just "assuming." This isn't academic or pedantic, it's a basic epistemological claim with regard to what writing software actually looks like in practice. You, in fact, do not know, and your insistence that you do is precisely the reason that you are at greater risk of creating memory safety vulnerabilities.

charlotte-fyi commented on Rewriting essential Linux packages in Rust lwn.net/Articles/1007907/... · Posted by u/worble

brian-armstrong · 6 months ago

left-pad is symbolic of dependency and supply chain issues generally. If all you took away from that incident is that there's risk only from someone unpublishing the module then you probably need to go back and think about it some more.

charlotte-fyi · 6 months ago

Why would I take anything away beyond the specific scope of the vulnerability to supply chain issues that NPM had? Cargo offers a variety of tools for auditing and managing dependencies that specifically mitigate supply chain issues. If your only suggestion is to not use dependencies at all, that's an extreme opinion.

charlotte-fyi commented on Rewriting essential Linux packages in Rust lwn.net/Articles/1007907/... · Posted by u/worble

brian-armstrong · 6 months ago

> " There are between 200 and 300 dependencies in the uutils project. He said that he understood there is always a supply-chain-attack risk, "but that's a risk we are willing to take". There is more and more tooling around to help mitigate the risk, he said.

left-pad II, coming soon to a Linux distro near you

charlotte-fyi · 6 months ago

A left pad incident isn't possible on crates.io. Yanking a package from the registry doesn't remove the code if you have an existing lockfile.

charlotte-fyi commented on Effective Rust (2024) lurklurk.org/effective-ru... · Posted by u/ibobev

musicnarcoman · 6 months ago

While I am only a Rust novice it seems to me like the "2.2 Item 11: Implement the Drop trait for RAII patterns" could use some kind of mention of Drop-leaks. I learned about it at https://doc.rust-lang.org/nightly/nomicon/leaking.html

charlotte-fyi · 6 months ago

The important note here is that you can't rely on Drop running in order to satisfy the SAFETY comment of an unsafe block. In practice, in safe Rust, this knowledge shouldn't really change how you write your code.

charlotte-fyi commented on H5N1: Much More Than You Wanted to Know astralcodexten.com/p/h5n1... · Posted by u/feross

kleton · 8 months ago

It was clear to people paying attention to the hard numbers by February 2020 that Covid was no threat to children and non-elderly adults without risk factors like obesity, which led to the rational decision to treat it as a non-risk. If something bad comes around that is actually killing healthy adults, they would stay home.

charlotte-fyi · 8 months ago

> without risk factors like obesity

40% of Americans are obese.

charlotte-fyi commented on How much memory do you need in 2024 to run 1M concurrent tasks? hez2010.github.io/async-r... · Posted by u/neonsunset

afavour · 9 months ago

Maybe I’m missing something here but surely Node isn’t doing anything concurrently? Promises don’t execute concurrently, they just tidy up async execution. The code as given will just sequentially resolve a million promises. No wonder it looks so good. You’d need to be using workers to actually do anything concurrently.

charlotte-fyi · 9 months ago

That's not entirely true. There's a thread pool of workers underneath libuv. Tasks that would block do indeed execute concurrently.