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.

This comparison is kind of sloppy, though. OpenGL on the desktop needs to be compared to a concrete WebGPU implementation. While it still lags behind state of the art, `wgpu` has many features on desktop that aren't in the standard. For example, they've started working on mesh shaders too: https://github.com/gfx-rs/wgpu/issues/7197. If you stick to only what's compatible with WebGL2 on the desktop you'd face similar limitations.

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.

The functional interface changes are huge. Clojure is always at its best when staying close to Java via judicious use of interop and this solves one of the major missing links.

Of course not.

This is solved in tools like Pulumi by having a declarative and auditable build artifact as an intermediate step that can be diffed. This seems to solve a lot of the security issues (and is generally a good idea anyway).

I think that declarative configuration languages scratch the itch of a lot of developer brains, but in practice it doesn’t really matter and using more familiar languages is a huge benefit to devex that shouldn’t be overlooked if the goal is to be mainstream. Yes, it requires more discipline on the reviewer front not to create abstractions that are too powerful/footgun-y, but it’s totally possible to write clear, declarative code in a “real” programming language without artificial constraints.

The syntax isn’t as clean but you can add property accessors to objects in JavaScript that accomplishes the same thing.

Very exciting. The ideas behind Nix are so good and everything else so bad. It seems like a lot of people are trying to solve this by building abstractions on top of Nix, but I'm really skeptical that is the solution. As crazy as a full rewrite is, I hope someone succeeds!

I'm constantly getting

Something went wrong, but don’t fret — let’s give it another shot.

Firefox’s Enhanced Tracking Protection (Strict Mode) is known to cause issues on x.com

Edit: kinda makes the whole "we didn't change our privacy policy" kinda sus lmao.

`no_std` with `alloc` isn't that different.

> There is definitely need for an OOP engine in Rust

Is there a need for an OOP engine in Rust?

I don't want to be too negative here — the developer of Fyrox seems like an incredibly talented and productive engineer and they can work on whatever they please, more options in the ecosystem is always a net good — but in my experience attempting to model OOP patterns in Rust is almost always the wrong decision.

What PR money has been behind Rust?

Your conspiratorial framing here strikes me as odd, as well as unnecessarily denigrating Bevy as a "research project." Isn't the answer quite obvious, which is that if someone wants to use an engine built off "proven old tech", they should probably just use one of the major players in the space, and that Bevy's uniqueness/commitment to the ECS model is precisely what causes it to generate more hype and energy? Is this really an issue of "fairness"?

Many people consider what you refer to as "the dirty work" as precisely the point of creative practices.

Yeah, these all made me feel incredibly nauseous. I was trying to figure out what aspect of the motion was triggering this (bad parallax?) but couldn't. The results are impressive but it's still amazing to me how little defects like this can trigger our sense of not just uncanniness but actual sickness.

Don't really get the criticism of Clojure for being hosted on the JVM, particularly relative to its status as a "productive" Lisp. Like oh, you get access to one of the biggest and most mature library ecosystems out there as well as best in class operational tooling? Obviously there are use cases where the JVM doesn't fit and all things being equal I prefer shipping statically linked binaries too, but the JVM still feels like an obvious "pro" here.

> and if it’s after the code I care about observing, it doesn’t matter

That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior you are no longer capable of observing the code you care about correctly.