It does take some getting used to, but the amount of tutorial content on YouTube is another reason I'm happy I made the switch. A lot of really good stuff on there. (Search on 'DaVinci Resolve Fusion' to see some examples of it in action if you want to get a feel).

(Can confirm - I just opened it on my laptop (I had the latest beta installed) and it prompted me to download the release version)

I do think 'self driving' is still their 'moat' when it comes to EVs. I use it every day, and nothing else comes close. But other than that, building EVs is becoming a cut-throat slim-margin business. I don't think that's where Elon, or Tesla employees, want to spend their energy.

Does he also deliver on some mind-boggling timelines? Well Tesla went from delivering its first cars in 2008 to having the best selling car in the world in 2023, and SpaceX went from not having successfully launched a rocket to delivering about 80% of the world's space payload in roughly the same timeframe. So I'd say that's clearly a 'yes', too.

https://siboehm.com/articles/22/CUDA-MMM

I'm not a Tesla fanboy, last year was the first time I bought one (new Model Y), but it is by far the best car I've ever owned, and the FSD blew my mind with how much better it was than I expected.

My wife hates Elon, and has a new hybrid Mitsubishi, but she still drives my Model Y all the time because it's just so much better to drive.

What are you basing the 'mediocre' opinion on?

At first I had the usual revulsion to the syntax, but after a few days getting used to it, I actually don't mind it at all now. (I still wouldn't say it's "elegant", but I can live with it).

Being Metal shader code is basically C++ anyway, and C++ is a language I'm familiar with, having a couple of .mm files to hold the Objective-C++ for API bridging and working in regular .cpp (and .h) files for the rest is pretty straight forward compared to having to learn Swift. (Especially with all the complaints I've heard about its complexity, including from Chris Lattner himself lately, which aligns with some of the other comments here).

Though to be fair, "Swift seems overly complex so use C++ instead" seems like a tough argument to make with a straight face ;-p

Excuse my naive physics, but is there a point at which if you take enough mass off of earth and launch it into space, it would have a measurable effect on earth's orbit? (Or if the mass is still tethered to earth via gravity, is there no net effect?)

That said, even though it's not to my taste, I do admire that they dared to do something different and took a big gamble on it. So many vehicles, especially in the truck space, are almost indistinguishable and lack any kind of imagination. Kudos to Tesla for trying to break the mold and push the category somewhere new.

I working in software and "build features" for a living, and over the years I've come to prioritize reliability, performance, and an intuitive experience over all else. No matter how good the feature set is, if it crashes, is painfully slow, or I can't figure out how to use it, then I don't want it.

Apple used to have that focus, but seems to have lost it of late.

That's a bold claim on Jan 12th!

Me: "Hey Siri, play Siri: "OK, here's "

Being these things are at their core probability machines, ... How? Why?

The project I'm mostly working on uses the wgpu crate, https://github.com/gfx-rs/wgpu, which may be of interest if writing cross-platform GPU code. (Though obviously if using Rust, not Zig). With it my project easily runs on Windows (via DX12), Linux (via Vulkan), macOS (via Metal), and directly on the web via Wasm/WebGPU. It is a "lowest common denominator", but good enough for most use-cases.

That said, ever with simple shaders I had to implement some workarounds for Xcode issues (e.g. https://github.com/gfx-rs/wgpu/issues/8111). But still vastly preferable to other debugging approaches and has been indispensable in tracking down a few bugs.

I am writing compute shaders though, where one command buffer can run for seconds repeatedly processing over a 1GB buffer, and it seems the tools are heavily geared towards graphics work where the workload per frame is much lighter. (Will all the AI focus, hopefully they'll start addressing this use-case more).

https://www.vice.com/en/article/open-source-devs-reverse-dec...

That aside, even if something like this was “legally enforceable”, it adds enough friction, risk, and uncertainty to downstream consumers compared to a “vanilla” open source license that I expect most folks would choose an alternative to the “bespoke” license project where they could. Fine if you don’t care about getting usage, but that defeats much of the value that open source brings.

This is the part I find confusing, especially as NVIDIA doesn't make it easy to find and download the old toolkits. Is this effectively saying that just choosing the right --arch and --code flags isn't enough to support older versions? But that as it statically links in the runtime library (by default) that newer toolkits may produce code that just won't run on older drivers? In other words, is it true that to support old hardware you need to download and use old CUDA Toolkits, regardless of nvcc flags? (And to support newer hardware you may need to compile with newer toolkits).

That's how I read it, which seems unfortunate.

https://quantum.microsoft.com/en-us/tools/quantum-coding

https://quantum.microsoft.com/en-us/tools/quantum-katas