The rumours are that this is coming later this year with the M6 generation (along with OLED touch screens).

I don’t think we’re getting those this year, now that M5 MBP just launched

Maybe not, but the rumours have been exactly that (6 month refresh cycle).

If you need the CPU power in the Mac Mini then it is a pretty good price-to-performance ratio.

I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system, explicit lifetime for objects, much more expressive (and therefore complex) macro support...

I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.

> I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system

Swift already does have those things but unlike Rust, they are opt-in.

Not going to argue which language is simpler, but sorry, you don't seem like someone who knows Swift very well.

While Swift now has the `borrowing` and `consuming` keywords, support for storing references is nonexistent, and the only way to return/store `Span`s, etc, is only possible through using experimental `@lifetime` annotations.

Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.

Rust is still more complicated than Swift, but you needn't worry - the Swift team is flexing their muscles hard to ensure that Swift becomes the biggest, most complicated language on Earth and wins the complexity, cognitive burden and snail performance once and for all eternity. Their compiler already times out on the language, soon even an M7 will also give up.

One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.

C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.

It has been there for me since 1993, in every single scenario as alternative to C, when the choice boils down to either of them.

Since 1993, I only have used C when required to do for various reasons out of my control, or catching up with WG14 standards.

how would you write something like

    #include <print>
    #include <map>
    #include <string>

    int main(int argc, char** argv) 
    {
      using namespace std::literals;

      std::string foo = "foo:";
      foo += argv[0];

      std::map<std::string, int> m{
        {foo, 123}
      , {"count: "s + std::to_string(argc), 456}
      };

      std::println("{}", m);
    }

in C

Even better example,

    import std;

    int main(int argc, char** argv)
    {
        using namespace std::literals;

        auto foo = "foo:"s;
        foo += argv[0];

        std::map<std::string, int> m{
          {foo, 123}
        , {"count: "s + std::to_string(argc), 456}
        };

        std::println("{}", m);
    }

Sure, there are nice parts of C++. And there are also brain-dead parts that add needless complexity such as:

* rvalue references

* the difference between auto, decltype, typeof

* unreadable template monstrosities

* various different flavors of "smart" pointer

* the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc

* total absence of a build system or package management

* legacy APIs that still take raw pointers

* concepts, a half-assed attempt at generic constraints

No worries, you get some of those in C23, and C2y.

Where is C's build system and package management?

Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.

You misunderstood. Perpetuating C's weaknesses, and then adding additional complexity, is not a defense.

It kind of is, when the goal was to be TypeScript for C, before this was even a concept.

Now ideally we would all be using Modula-2, Ada, Delphi, VB, C#,.... and co, but given that even C compilers are nowadays written in C++, we make do with what we have, while avoiding C flaws as much as possible.

C++ if any made C user friendly.

C++ is trying to make something EASIER to use?

Examples?

Except the entire design of swift is meant to make everything more automated.

* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>)

* automated interop with C/C++/Obj-C through the clang ast importer

Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?

Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.

> Maybe they could have started with rust and added on what they needed

Unlikely, I think, because of timelines. Swift’s first public release was in June 2014. Rust is a few years older (first public release in January 2012), but that wasn’t the rust we have today. It still had garbage collection, for example (https://en.wikipedia.org/wiki/Rust_(programming_language)#20...)

How does it compare to the original in terms of source code size (number of lines of code?)

It's significantly smaller. Because Rust doesn't require header files or memory management, xmloxide is ~40k lines while libxml2 is ~150k lines.

> Small codebases were always a good thing. With coding agents, there's now a huge advantage to having a codebase small enough that an agent can hold the full thing in context.

It is somewhat ironic that coding agents are notorious for generating much more code than necesary!

> the "money you have" is just an int32

If only it was a uint32

My money is a boolean at this point.

    money_in_account=false;

Still better than half of uint32 possibilities.

Wanna take another stab at that? :)

Lol, I just wrote a bug.

I find that these kind of optimizations are usually more about technical architecture than leetcode. Last time I got speedups this crazy the biggest win was reducing the number of network/database calls. There were also optimisations around reducing allocations and pulling expensive work out of hot loops. But leetcode interview questions don't tend to cover any of that.

They tend to be about the implementation details of specific algorithms and data structures. Whereas the important skill in most real-world scenarios would be to understand the trade-offs between different algorithms and data structures so that you pick an appropriate off-the-shelf implementation to use.

I agree. The "advanced" leetcode is about those last % of optimization. But when network latency is involved in a flow, it is usually the most obvious low hanging fruit.

There's a long-term economic problem looming around the loss of jobs: which is that most people's ability to command a share of our economic output (i.e. earn money) is tied to their value as a labourer. If that labour is no longer needed by those who control capital and thus allocation of labour resources (which is increasingly the case across many segments of our economy), then we end up with an economy where people increasingly struggle to earn a decent living.

Of course there are areas where that labour would be useful: healthcase, teaching, childcare, elderly care all come to mind (and there are many other examples). But our economy is not set up to enable this. The problem isn't supply side (difficulty retraining people to do the jobs), it's demand side: the people who need these services often don't have the money to pay for them. So the jobs are badly paid.

And it's a downward spiral: as wealth becomes more concentrated, demand for labour drops because those controlling the wealth already have their needs met and often don't care about the needs of others.

If history is anyhing to go by, then this will eventually lead to war and/or revolution.

Damn, that's bad. You can compile C++ faster than that!

> Is there any front end framework that doesn't do this?

React, if you are judicious about what additional packages you use on top of it.

> I dropped out of the front end years ago, and it seems to just get worse every year with a profusion of confusion.

This has actually gotten somewhat better in recent years starting with esbuild which made it possible to use a simple single-binary tool for bundling.