> For (1) and (2), the worst-case just doesn't occur. I mean, installing packages and type checking can surely be slow. But, at least in my career, I've never seen a galactic blow-up.
Hehe, clearly the author hasn't written any SwiftUI.
I think that Swift is the exception that proves the rule. The fact that it is notorious for giving up on certain type checks indicates that it isn't a problem for most languages.
It's the other way around, I think: it's not a problem for most languages because bidirectional type inference with overloading is NP-hard. It'd be nice to have, but it's impossible to implement in a way that's reliably fast, so it's not even considered as an option.
Why are they writing their own constraint solver? There are so many great off-the-shelf constraint solvers that are probably going to be way faster than whatever Swift engineers can cook up.
Rust certainly helps for certain classes of errors but doesn't help at all for logic errors or incompletely understood requirements or occasional need for hacks due to business needs.
Why is everyone always referring to logic errors when pushing back against Rust? No programming language ever invented (or to be invented) will fix logic errors made by developers.
Logic errors are "out of scope" for Rust or any other programming language.
No shallow dismissals please, tell me why you think I'm wrong.
> Rust is not a major advance over C/C++
Rust adds the borrow checker (and especially with non-linear lifetimes it's an implementation like the world has never seen before, not even in Cyclone). That alone raises it leaps above both C and C++.
But even without it, it still has a Hindley Milner type system (which most people considered superior to multiple inheritance), it has Sync/Send traits, the concept of UnwindSafe, proper destructive moves and affineish types, proper sum types and matching, sane iterators, lack of UB on uninit/overflow/etc, a sane module system, hygienic macros, and that's just the things I was able to pull of the top of my head right now.
Not to mention, the design of its stdlib is absolutely lovely compared to what C++'s stdlib has become, and it focuses on correctness much more than most other popular languages.
The more verification you do, the more likely it is for a program to be correct. Lean towards Assembly, and you get less correctness, but lean towards Ada/SPARK, and you get more.
Rust is a notoriously difficult language specifically because it adds some limited verification features, going further along that correctness continuum than C. I didn't think that could even be disputed.
The "if it compiles it probably works" feeling most Rust programmers experience is proof that those verification features work, too.
> In time you will learn about all of the faults and flaws in Rust
I've programmed enough safe Rust and unsafe Rust that I'm now very familiar with most of its flaws, and yes, it has many. I'm also familiar with C and C++'s flaws, and they're so, so much worse.
> after you've suffered the pain of trying to rewrite the entire universe in it
My goal has never been to rewrite the universe in Rust. Battle-tested software is fine to stay as-is, unless it needs constant updates and new features, where most memory bugs appear.
With that said, a couple years ago, at work, our team finished migrating a couple of performance-sensitive services from C++ to Rust, and not only were they both successful, but they became 5x and 10x faster respectively, because it's so much easier to do direct memory reference stunts that would've been possible, but crazy via C++'s std::span and lambdas.
> I know exactly what the successor to C/C++ looks like, and it's not Rust.
What does it look like?
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted
Everything I listed is compile-time complexity. I'm not sure how you can add any of it at runtime without extra runtime costs. Or are you talking about modifying the C language?
We might argue over whether that complexity is worth it, for sure, but once again: "if it compiles it probably works" is a very common sentiment with Rust.
But also, what you're saying sounds very much like the Blub Paradox [1]:
"As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub."
> Most of it is wankery, the sort of stuff that 20-somethings salivate over
I'm not sure how that is relevant to what I said? I have 30 years of experience with C, and have read the C specification cover to cover, plus more recently some 15 years of C++ experience in parallel at work. I still use all 3 languages today.
> Again, the actual successor to C/C++ looks nothing like Rust.
> In time you will learn about all of the faults and flaws in Rust, after you've suffered the pain of trying to rewrite the entire universe in it just to fix one single class of problem you are obsessed about--inevitably introducing many new bugs in the process, because that always comes with the territory.
Good thing Rust doesn't just fix that one class of problems, but also provides better tooling to fix other classes too. Classes of problems that could be fixed with the other features of Rust mentioned later like the Hind...
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted, but why would I?
...the vast majority of these features don't even run at compile time. Some of them can't even be implemented in C. For starters, show me an example of a Hindley Milner type system implemented for C (how can someone improve a strictly compile time feature, static typing, with a runtime implementation is beyond me). Or proper destructive moves in C or C++.
> Ada is the language to emulate, [...]
Good thing Rust also takes from Ada.
> Again, the actual successor to C/C++ looks nothing like Rust.
It is obvious that you are just trolling, but for other readers: our production app went from 50-100 unexplained sentry errors in typescript to 0 sentry errors in rust.
The language absolutely helps fix logic errors.
It's something that becomes immediately clear as soon as you start using the language in earnest.
> Wow, what a magical language! [ waves hands vigorously ] will fix all the problems which are inevitably introduced by auto-porting from one language to another, or by manually rewriting everything from scratch. Rust doesn't obey the same laws of the software universe as other languages, it seems. Or is this a "just use magic AI bro", type situation?
Nope, that's just your own prejudices speaking. We already cited features (seen in and inspired by other languages) and you handwaved them away with "I don't care". You are the one fixated on C and C++. You are a C evangelist, if I were to make a guess. And that's on you.
> In the latter case, why don't I just use the to auto-magically solve my C/C++ problems, rather than rewrite the entire universe from scratch? You know, like Google claims to have done for Chromium C++ sources in this very news article?
You certainly can. But to spin this the other way around: in lieu of the Bun case, why not use it to rewrite the project in Rust, Zig, D or any language of your choice (yes, even C)? Given the role harnesses have in keeping agents in check, it seems plausible that languages with stricter safety features help agents avoid common issues.
> This is the type of shit noobs are always wringing their hands about as they need maximum guardrails to cover for their ineptitude.
You seem to be forgetting that proper software engineering is just as much about managing developers and their skills as the actual code structure. If a tool helps noobs produce better quality code, specially ones without as many vulnerabilities, why not employ it? Also, it's not like experts are immune to mistakes either.
> It could compile and still have 10,000 logic errors.
It could. Switch that to C or C++ and the amount of logic bugs is likely going to triple.
> Rust is not a major advance over C/C++, only an incremental and quite limited one, [...]
"Nothing ever happens." I guess you could consider borrow checking, an actual module system, type classes, enum variants, compiler-integrated macros, async/await, etc. to be just small increments. (Theoretically, you can reimplement most of this in C++, like std::variant, but they don't integrate well into the language - having to declare a type just to use std::visit is certainly not as simple as using match).
> [...] which will require decades of rewriting perfectly good code to gain its dubious benefits, in the process introducing numerous other errors.
"Introducing numerous other errors"? Would be interesting to see an citation on that. From what I've seen, these "new errors" were already present in the original "perfectly good code", except the original also had instances of undefined behavior and logic errors from poor type modeling.
> But don't take my word for it [...]
Why would anyone other than your friends take your word? You could have substantiate your claims with actual evidence.
> [...] after the hype has worn off [...]
Which already did. Nowadays, I see more posts about Zig and Fil-C.
>[...] left with the sad mess that is Rust.
I went to read your comment history to see if you elaborated on this "sad mess" of Rust, but you didn't. How about you do it here?
It basically completely eliminates the most common class of errors which are bugs related to memory management. Hard numbers and statistics show that every application with enough complexity will be riddled with those.
It is simply impossible, even for the smartest human minds, to manage this kind of complexity. And this is a fact.
Basically all C programs I use, shells, editors, terminals, etc. But I do not claim that there "never has been a memory-related bug" but that it is not "riddled with" memory-related bugs, which I would expect would have manifested in at least one segfault over all these years, which I did not observe.
I just pushed another tool for that! It wasn't exposed in the Live API but the implementation just issues the same queries to the underlying sqlite db that the Live GUI queries for the "Find Similar Sounds" feature.
Added an "Agent Audio Tap" Max for Live device that lets the agent analyze any part of the signal chain and optimize your mix based on that (or just make cool visualizations!)
Nice, the audio analysis M4L device is something I wanted to add next, as that would close the feedback loop and let the agent actually analyze its setup. Kind of like how giving agents screenshots of its UI work helps improve the UI.
I agree! I made this mostly so I could stay in the flow more in Ableton without getting lost spinning knobs and pressing buttons. Although I do enjoy spinning knobs and pressing buttons.
With this I can keep my hands on my keyboard or guitar and direct Codex to make a quick backing track.
To be fair, the demo track was one of the first I had it make, and I didn't put much effort into it because I thought it was especially funny with the macos "say" command vocals.
It's a garbage-in, garbage-out situation. If you give it more musical direction you will get more out of it.
It's not just that the track is garbage (the "say" vocals are actually the least of its problems). Even if AI would make a good track: why use AI for creating your arrangements in the first place? Why this resistance to actually getting good at something? I can understand if your livelihood depends on it and you just need to be fast, but why for stuff you do for fun?
The book I mentioned has a good suggestion when struggling with arrangements: just copy. Take a track you really like, put it into your DAW, sync the speed and replicate its structure. You'll see that in many genres, structure is often exactly the same anyway. This can be an eye opener, and once you've realized this, you'll be able to experiment with structure in ways you couldn't do before. That's the fun part.
I agree that having an MCP Ableton can make total sense. After many years of use, I would say I know Ableton quite well, but nowadays, I regularly ask ChatGPT if certain things could be done differently/more efficiently, and it often surprises me with new ways of doing things. For instance, sometimes Ableton has gotten new features over the years I'm not aware of. It surely would be nice to have this integrated via MCP.
I think you would get much better feedback if you'd focus on these use cases: flattening the learning curve for newcomers, and new ideas for experienced users, rather than creating tracks completely by AI. Because in that case, why even go through a DAW and not use Suno directly?
Thank you for the feedback, I'll record some more co-creating examples! And yea, it's also fun to take stuff out of Ableton and run it through Suno, to get real vocals and such.
A cool thing about this MCP is you can ask Codex Ableton questions and it will go and read the state of your current Live Set and answer based on that. You don't have to have it change anything for you if you don't want.
Hehe, clearly the author hasn't written any SwiftUI.