ISV_Damocles

Most of the big OSS AI codebases (LLM and Diffusion, at least) have code to work on any GPU, not just nVidia GPUs, now. There's a slight performance benefit to sticking with nVidia, but once you need to split work across multiple GPUs, you can do a cost-benefit analysis and decide that, say, 12 AMD GPUs is faster than 8 nVidia GPUs and cheaper, as well.

Then nVidia's moat begins to shrink because they need to offer their GPUs at a somewhat reduced price to try to keep their majority share.

UTF-16 is also just as complicated as UTF-8 requiring multibyte characters to cover the entirety of Unicode, so it doesn't avoid the issue you're complaining about for the newest languages added, and it has the added complexity of a BOM being required to be sure you have the pairs of bytes in the right order, so you are more vulnerable to truncated data being unrecoverable versus UTF-8.

UTF-32 would be a fair comparison, but it is 4 bytes per character and I don't know what, if anything, uses it.

Replying to this one since you apparently can't reply to a comment that has been flagged. Why was the grandparent flagged? Google's S2 library has been around for more than a decade and is the first thing I think of when I see "S2" in a tech stack.

And the flippant response from the parent here that they don't really care that they're muddying the waters and just want the crate name is irksome.

This article touched on a point that I feel is very relevant: unexpected show cancellations, apparently now happening for Apple TV+, as well.

Netflix and Disney+ trained me to not even watch a show until it's concluded because it could get cancelled and I don't want to invest my small amount of free time on entertainment that might not even finish. It does produce a self-fulfilling prophecy where people with the same mindset as me on this do the same, and then the rating for something I (and probably they) are interested in aren't high enough and it gets cancelled.

What should worry them, though, is that it also led to the final step for them; I cancelled my Netflix and Disney+ subscriptions with no intention of renewing them around a year ago. The end result is that "TV series"-style shows are effectively dead to me; I've shifted my time on them mostly to novels (that are basically behind-the-curve on this trend, hopefully forever), followed by single-player video games, and finally movies. (Why didn't movies take the first slot? Because I'm only willing/able to give 30-60 minutes of continuous time to entertainment most of the time, and it's very unsatisfying to pause a movie to resume later.)

The continuous, immediate feedback on series performance coupled with a reputation of acting on that feedback immediately is killing the traditional television medium.

On top of all of that, Apple TV+ has the added albatross of requiring their hardware for the shows, as if they were somehow a siren song to get people more tightly nestled into their ecosystem, and therefore dooming their shows to failure, at least amongst people who don't want to pay for overpriced hardware running software of degrading quality over the years (I switched to Linux in 2016 because it was more reliable than my MacBook Air; being better than Windows isn't good enough anymore, especially when Linux has a greater catalog of software these days).

The needs of Apple, Inc weigh on their Apple TV division, they don't help it, and the sins of the streaming services against actually finishing a story further increase the trust deficit with Apple TV+. No amount of marketing is going to turn that around.

`drop` is an optimization. You never have to call it if you don't want to, Rust will automatically free memory for you when the variable goes out of scope.

Rust won't let you do the wrong thing here (except if you explicitly opt-in to with `unsafe` as you note is also possible in other languages). The Rust compiler, when writing normal Rust code will prevent you from compiling code that uses memory incorrectly.

You can then solve the problem by figuring out how you're using the memory incorrectly, or you could just skip out on it by calling `.clone()` all over the place or wrapping your value in `Rc<T>` if it's for single-threaded code, or `Arc<Mutex<T>>` for multi-threaded code, and have it effectively garbage-collected for you.

In any case, this is orthogonal to safety. Rust gives you better safety than Python and Java, but at the cost of a more complex language in order to also give you the option of high performance. If you just want safety and easy memory management, you could use one of the ML variants for that.

Agreed. My personal experience is Rust is more safe than Python as you get runtime errors when your interpreted Python code has a type error in it, but that's a compiler error in Rust so you don't have an "oopsie" in production.

Much harder to write Rust than Python, but definitely safer.

(Rust vs Java is much closer, but Java's nullable types by default and errors that are `throw`n not needing to be part of the signature of the function lead to runtime errors that Rust doesn't have, as well.)

The suggestion to use AR glasses with this keyboard computer feels very Ghost-in-the-Shell cyberpunk to me. Stepping onto a train and you find some guy with glasses sitting near the train door staring blankly at other passengers while typing furiously on the keyboard. Looks a bit creepy. After a moment it's revealed he has an AR display and he's writing an email or whatever.

...why do I feel nostalgic for a cyberpunk dystopia?

That would also be true with analog film when you start reaching the film grain size.

I am just clarifying why I consider it impossible.

Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for.

If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.

It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it brings a huge value to you.

Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.