xscott

Of course I can't be certain, but I think the "mixture of experts" design plays into it too. Metaphorically, there's a mid-level manager who looks at your prompt and tries to decide which experts it should be sent to. If he thinks you won't notice, he saves money by sending it to the undergraduate intern.

Just a theory.

Language changes over time, and I remember recent memes where a cute girl says something like "claiming you're moderate means you know conservatives don't get laid" (presumably because of abortion politics). It makes me wonder if the moderates actually became liberal or if they just don't want to use that word any more.

After all the polarism in "reality show politics", my diehard liberal friends seem less liberal to me, but they'll state which team they're on more fervently than ever.

Very simple code is UB:

    int handle_untrusted_numbers(int a, int b) {
        if (a < 0) return ERROR_EXPECTED_NON_NEGATIVE;
        if (b < 0) return ERROR_EXPECTED_NON_NEGATIVE;
        int sum = a + b;
        if (sum < 0) {
            return ERROR_INTEGER_OVERFLOW;
        }
        return do_something_important_with(sum);
    }

Every computer you will ever use has two's complement for signed integers, and the standard recently recognized and codified this fact. However, the UB fanatics (heretics) insisted that not allowing signed overflow is an important opportunity for optimizations, so that last if-statement can be deleted by the compiler and your code quietly doesn't check for overflow any more.

There are plenty more examples, but I think this is one of the simplest.

For or against, I don't know why the "just predicting" or "stochastic parrots" criticism was ever insightful. People make one word after another and frequently repeat phrases they heard elsewhere. It's kind of like criticizing a calculator for making one digit after another.

No, but in this case it indicates some hypocrisy.

> It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode.

They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood.

Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.

I'm not a web dev. Are people really that opposed to writing a function which would solve problems in their project? It's two lines long...

> Assuming assert existed

It's a function you could write for yourself and give it whatever semantics you feel is best. No changes to the language required for this one.

The Rust example I showed changes behavior when you declare the types. It's not just a readability or bug catching thing.

> Why would you say that? I feel this pushes people away.

It's not my obligation to evangelize for your pet language. I've spent enough time and written enough code in Rust to have a defensible viewpoint. This is public forum - I'll share my opinion if I want to.

Writing servers? Sure, go grab the crate that solves your problem and get on with it. Basically what I said above.

If I thought you would bother to do them, I could give you a list of concrete problems which ought to be super easy but are in fact really hard or ugly to do in Rust.

Phrases like "systems programming" have become so diluted that I'm not even sure what you mean. Once upon a time, that was something like writing a device driver. Now people use the phrase for things like parsing a log file or providing a web server.

I wanted to use Rust for numerical methods and data visualization. I didn't like the existing solutions, so I was willing to write my own Rust libraries from scratch. It was pretty painful, and the learning curve was steep.

> Why say that? It's not even remotely true

I didn't write the thing you quoted. Using a straw man argument like this is a lame tactic.

It also comes up when you want compile time expressions as parameters to your generics:

    // nice and clean
    let a = Generic[T, A > B]::new(); 

    // gross curlies needed because of poor choices
    let a = Generic::<T, {A > B}>::new();

> Rust isn't as hard or as bad as you think.

I think this depends a LOT on what you're trying to do and what you need to learn to do it. If you can get by with the std/core types and are happy with various third party crates, then you don't really need to learn the language very deeply.

However, if you want to implement new data structures or generic algorithms, it gets very deep very quickly.

> For this specific issue, if square brackets were used for generics, then something else would have to change for array indexing

The compiler knows when the `A` in `A[B]` is a type vs a variable.

I see your point, and it's a nice example, but not completely parallel to the Rust/StandardML thing. Here, your RHS is an initializer, not a value.

    // I don't think this flies in C or C++,
    // even with "designated initializers":
    f({ .flag = true, .value = 123, .stuff=0.456});

    // Both of these "probably" do work:
    f((some_struct){ .flag = true, ... });
    f(some_struct{ .flag = true, ... });

    // So this should work too:
    auto a = (some_struct){ .flag = true, ... };

Take all that with a grain of salt. I didn't try to compile any of it for this reply.

Anyways, I only touched SML briefly 30 some years ago, and my reaction to this level of type inference sophistication in Rust went through phases of initial astonishment, quickly embracing it, and eventually being annoyed at it. Just like data flows from expressions calculating values, I like it when the type inference flows in similarly obvious ways.

Lol, yes they would. However, I wouldn't. :-)

> This is like complaining that in C [...]

It's really not. Only one of my examples has the equivalent of superfluous parens, and none are dereferencing anything. And I'm not defending C or C++ anyways.

When I was trying to learn Rust (the second time), I wanted to know how to make my own types. As such, the macro `vec!` mentioned elsewhere isn't really relevant. I was using `Vec` to figure things out so I could make a `FingerTree`:

    let v: Vec<u32> = Vec::new();  // Awfully Java-like in repeating myself

    let v = Vec::new(); // Crap, I want to specify the type of Vec

    let v = Vec<u32>::new();  // Crap, that doesn't compile.

And so on...

Do these print statements print the same thing?

    let i = 1;
    let j = 1;
    print!("i: {:?}\n", !i);
    print!("j: {:?}\n", !j);

    let v = vec![1, 2, 3];
    v[i];

There are definitely times you want to specify a type.

Only `b` has the equivalent of "superfluous parens".

It's practically your job to defend Rust, so I don't expect you to budge even one inch. However, I hate the idea of letting you mislead the casual reader that this is somehow equivalent and "just how languages work".

The grammar could've used `Generic[Specific]` with square brackets and avoided the need for the turbo fish.

Fwiw, I didn't go looking for obscure examples to make HN posts. I've had three rounds of sincerely trying to really learn and understand Rust. The first was back when pointer types had sigils, but this exact declaration was my first stumbling block on my second time around.

The first version I got working was `d`, and my first thought was, "you're kidding me - the right hand side is inferring it's type from the left?!?" I didn't learn about "turbo fish" until some time later.

This is some True Scotsman style counter argument, and it's hard for me to make a polite reply to it.

There are people who program with a "fake it till you make it" approach, cutting and pasting from Stack Overflow, and hoping the compiler errors are enough to fix their mess. Historically, these are the ones your pages/books cater to, and the ones who think the borrow checker is the hard part. It doesn't surprise me that you only see code from that kind of beginner and experts on some rust-dev forum and nothing in between.

I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes:

    let mut a = Vec::<u32>::new();
    let mut b = <Vec::<u32>>::new();
    let mut c = <Vec<u32>>::new();
    let mut d: Vec<u32> = Vec::new();

Which one will your coworker choose? What will your other corworkers choose?

This is day one stuff for declaring a dynamic array. What you really want is something like:

    let mut z = Vec<u32>::new();

However, the grammar is problematic here because of using less-than and greater-than as brackets in a type "context". You can explain that as either not learning from C++'s mistakes or trying to appeal to a C++ audience I guess.

Yes, I know there is a `vec!` macro. Will you require your coworkers to declare a similar macro when they start to implement their own generic types?

There are lots of other examples when you get to what traits are required to satisfy generics ("where clauses" vs "bounds"), or the lifetime signature stuff and so on...

You can argue that strong typing has some intrinsic complexity, but it's tougher to defend the multiple ways to do things, and that WAS one of Perl's mantras.

Hours aren't SI/metric. That factor of 3600 makes any conversion to acceleration more ugly than it should be (rounding a curve for instance). Nearly as bad as 5280 in my opinion. And really, 30 meters/second would be a nice human readable number.

Even in science though, the pros are happy to switch to electron volts or units where the speed of light and years are both 1.

I see, thank you. I'd have thought the memory size was (mostly) independent of the chip "level" (Ultra, Max, whatever), but my understanding of memory controllers is really limited.

The M3 Studio can have 512GB of RAM, the M4 Studio maxes out at 128GB, and the M5 laptop 32GB. I assume the eventual M5 Studio will allow more, but can anyone explain why newer generation chips are getting paired with lower max memory? There must be some marketing/sales reason I don't understand.

You're confused about whose rights are at stake. It's you, not the LLM, that is being restricted. Your argument is like saying, "Books don't have rights, so the state can censor books."

If you look at the LLMs as a new kind of fuzzy search engine instead of focusing on the fact that they're pretty good at producing human text, you can see it's not about whether the LLMs have a right to "speak", it's whether you have a right to see uncensored results.

Imagine going to the library and the card catalog had been purged of any references to books that weren't government approved.

I think you have to start lower than that, with the voting system itself. I've seen it argued in several places that "first past the post" leads to only two parties.

If you just want to see the colors in action, here's some some JavaScript you could run with Deno:

    const encoder = new TextEncoder();

    function csi(text, ... args) {
        const filt = args.filter(xx => xx !== null);
        const output = "\x1b[" + filt.join(";") + "m" + text;
        Deno.stdout.writeSync(encoder.encode(output));
    }

    csi("True Color RGB:\n");
    for (let ii = 0; ii<32; ++ii) {
        for (let jj = 0; jj<64; ++jj) {
            const fg_rr = jj*4;
            const fg_bb = ii*8;
            const fg_gg = (fg_rr + 3*fg_bb)>>2;

            const bg_rr = 255 - ii*8;
            const bg_gg = 127;
            const bg_bb = 255 - jj*4;
            csi("+",
                38, 2, fg_rr, fg_gg, fg_bb,
                48, 2, bg_rr, bg_gg, bg_bb,
            );
        }
        csi("\n");
    }

You don't know if those 9s repeat forever in this problem. It's output from a program, and the program could switch to 3s in 1000 more digits. The "adding" program is reading text digits from two other programs and can't see how they work. It can't assume a bunch of 9s mean there will be more 9s.

I did say we needed to be careful with the definitions. I'm sure you can look at Wikipedia to see that Minsky gave a definition like I used. You're not wrong to use a new definition though.