charlotte-fyi

Curious what your thoughts on Jank are? I’ve been waiting for it to mature for ever because I see really strong benefits here in being able to use Clojure as an actual everything language by being able to bind to native libs without going through Panama.

I feel in a really weird position where I both really dislike what AI is doing to the experience and practice of writing code, to the point where I want a job doing literally anything else besides using the computer, but also think that these tools are extremely powerful and only getting better.

I think Mitchell's point is well taken -- it's possible for these tools to introduce rotten foundations that will only be found out later when the whole structure collapsed. I don't want to be in the position of being on the hook when that happens and not having the deep understanding of the code base that I used to.

But humans have introduced subtle yet catastrophic bugs into code forever too... A lot of this feels like an open empirical question. Will we see many systems collapse in horrifying ways that they uniquely didn't before? Maybe some, but will we also not learn that we need to shift more to specification and validation? Idk, it just seems to me like this style of building systems is inevitable even as there may be some bumps along the way.

I feel like many in the anti camp have their own kind of reactionary psychosis. I want nothing to do with AI but I also can't deny my experience of using these tools. I wish there were more venues for this kind of realist but negative discussion of AI. Mitchell is a great dev for this reason.

I agree with you in that I think there's a better programming model out there. But using a buffer in a CUDA kernel is the simple case. Descriptors exist to bind general purpose work to fixed function hardware. It's much more complicated when we start talking about texture sampling. CUDA isn't exactly great here either. Kernel launches are more heavyweight than calling draw precisely because they're deferring some things like validation to the call site. Making descriptors explicit is verbose and annoying but it makes resource switching more front of mind, which for workloads primarily using those fixed function resources is a big concern. The ultimate solution here is bindless, but that obviously presents it's own problems for having a nice general purpose API since you need to know all your resources up front. I do think CUDA is probably ideal for many users but there are trade-offs here still.

The last supported version they ship doesn't support compute, which is a pretty big limitation.

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.

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

"our compensation is not merely transparent, but uniform"

second paragraph

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.

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.

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.

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.

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.

> without risk factors like obesity

40% of Americans are obese.

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