The release announcement on the forum at https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=2369... lists what is new. AI is obviously a lot of the focus when it comes to talking about the product, (and in the current environment that is no surprise), but is still only a small portion of what is new in this release.
I'm no expert (relatively new to the field myself), but I was trying to put together some simple videos with animations in Final Cut Pro and decided to try DaVinci Resolve, and I'm glad I did. The Fusion stuff bundled into it is incredibly powerful for animations.
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).
That's why I think the Optimus thing might make sense from a 'market cap' perspective. Tesla is great at innovation and ramping global manufacturing for new tech. Ten years ago, that was EVs. But now EVs are becoming a commodity and every other car company is catching up.
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 Elon over-hype nearly everything he gets involved with? Clearly yes.
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.
I keep this link in my favorites and refer to it every now and again. Still one of the best write-ups I've seen on just have vast the difference is between a naive and well tuned kernel
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.
I've been playing around with low-level Metal a bunch lately, any many of their docs and samples seem still be mostly in Objective-C/C++ and not Swift, so have been forcing myself to get into it.
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
> Starship will deliver millions of tons to orbit and beyond per year
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?)
I think the timing of the Cybertruck starting deliveries roughly aligning with when Elon got heavily involved in politics hurt it quite a bit. It is such a distinctive vehicle with a strong association with Elon, that there was an immediate brand association. It may have had poor sales anyway, but it certainly didn't help that many folks on the left, who are typically the most 'pro EV', had a large 'anti-Elon' shift around its launch.
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.
This is the most disappointing aspect of the slide in quality for me.
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.
I was hesitant buying my Tesla this year (first one) as I really liked having CarPlay in my prior car (Jeep). But after having it a while, it's really a non-issue. The Tesla Apple Music app is pretty good. Their maps and navigation is pretty good (and integrated with FSD). And I can easily just use the bluetooth connection for a couple other minor things I occasionally use.
I didn't even notice who I was replying to at first - so let me start by saying thank you for Ghostty. I spend a great deal of my day in it, and it's a beautifully put together piece of software. I appreciate the work you do and admire your attitude to software and life in general. Enjoy your windfall, ignore the haters, and my best wishes to you and your family with the upcoming addition.
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.
It's a full featured and beautifully designed experience, and when it works it's amazing. However it regularly freezes of hangs for me, and I've lost count of the number of times I've had to 'force quit' Xcode or it's just outright crashed. Also, for anything non-trivial it often refuses to profile and I have to try to write a minimal repro to get it to capture anything.
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).
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.
> Also, code that compiles with older CUDA toolkit versions may not compile with newer CUDA toolkit versions. Newer hardware may require a CUDA toolkit version that is newer than what the project maintainer intended.
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 one of the primary reasons we built the tooling for Q# to run in the browser (by writing in Rust and compiling to wasm). The “try with copilot” experience [1] and the “katas” for learning [2] all have a full language service and runtime in the browser.