GolDDranks

Just having features associated with OOP isn't a bad thing. Object upcasting has its uses.

It's some of the other stuff that gets OOP its bad rap.

Garbage collection, common in many OOP languages, enables having arbitrary object graphs. The programmer doesn't need to think hard about who has a reference to who, and how long these references live. This leads to performance-defeating pointer chasing, and fuzzy, not-well-thought-of object lifetimes, which in turn lead to accidental memory leaks.

Additionally, references in major languages are unconditionally mutable. Having long-lived mutable references from arbitrary places makes it hard to track object states. It makes easier to end up in unexpected states, and accidentally violate invariants from subroutine code, which means bugs.

Also, class-like functionality conflates data-layout, privacy/encapsulation, API, namespacing and method dispatch into a single thing. Untangling that knot and having control over these features separately might make a better design.

Japanese is often described as "strictly head final". However, there are some exceptions such as head-initial phrases with modifiers like "dake", "bakari", "goro", "gurai" and "hodo".

Also, the morphology in verb inflection and case declination is often head-initial, if it makes sense to say that about morphology. Word formation seems to be kinda mixed.

But Japanese syntax is a lot more consistently head-final than with how many European languages have their parameter setting.

No, because what people mean when they say grammar checker, it doesn't suffice to check whether a sentence is (formally speaking) ungrammatical or not. You'd expect it also check word choice, ortography etc. Those aren't part of the syntax structure. This means that it would allow many very flawed sentences.

Besides, the grammar this project uses is not likely to reflect accurately the actual grammar of modern spoken or written Japanese, and it's likely not to be even nearly complete; that would mean it would also have a quite lot of false positive "ungrammaticals".

Something _like_ this can certainly be used as a part of a grammar checker. But in that case, you shouldn't implement it in TypesScript's type system in the first place.

Every human language works this way...? This is why we have systems called "grammars" in the first place: they capture regularity in the structure of a language.

Human languages are, in a sense, "infinitary", so that they aren't simply a set of fixed phrases. However there are, depenging on the language, also patterns they don't allow. (And some patterns _any_ human languages don't allow.)

This logically necessities language to have regularities. We capture these regularities as "generative grammars".

Your point on intersubjectivity is spot on.

I kinda agree. But she seems smart and knowledgeable. It's kinda disappointing, like... She should know better. I guess it's the Gell-Mann amnesia effect once again.

I guess that Sabine's beef with LLM's that they are hyped as a legit "human level assistant" -kind of thing by the business people, which they clearly aren't yet. Maybe I've just managed to... manage my expectations?

I am so confused too. I hold these beliefs at the same time, and I don't feel they don't contradict each other, but apparently for many people some of these do:

- LLMs are a miraculous technology that are capable of tasks far beyond what we believed would be achievable with AI/ML in the near future. Playing with them makes me constantly feel like "this is like sci-fi, this shouldn't be possible with 2025's technology".

- LLMs are fairly clueless for many tasks that are easy enough for humans, and they are nowhere near AGI. It's also unclear whether they scale up towards that goal. They are also worse programmers than people make them to be. (At least I'm not happy with their results.)

- Achieving AGI doesn't seem impossibly unlikely any more, and doing so is likely to be an existentially disastrous event for humanity, and the worst fodder of my nightmares. (Also in the sense of an existential doomsday scenario, but even just the tought of becoming... irrelevant is depressing.)

Having one of these beliefs makes me the "AI hyper" stereotype, another makes me the "AI naysayer" stereotype and yet another makes me the "AI doomer" stereotype. So I guess I'm all of those!

A package manager that is a quick and snappy binary that doesn't need a big runtime, unlike most of the Python tools.

My biggest annoyance with recent macOS versions that most QuickLook plugins stopped working. Apparently one could re-develop them with their new framework-of-the-day, but I have no doubt a lion's share of what I'm using will just become abandonware.

I think there had been an easier path for Go to solve those problems. What's making C++ and Rust complicated is that they strive for much more generality than Go does.

Requiring a value to be provided at usage/definition site would go a long way. Also, of course, having to provide a default value by hand when initializing an array. Go also has easy-to-use callbacks, so having also APIs that take a callback returning a sentinel/default value should be easy enough. The problem isn't having defaults, but having pervasive defaults that are set in stone by the language itself, even in places where it doesn't make sense.

For low-level code that fiddles with uninitialized memory buffers and allocators, things might get complicated, if zero values are not allowed. (Rust's struggles around `MaybeUninit` is a poster child example of the ensuing complexity.) However, I think that a very Go-style solution would have been that the type system allows for zero-initialized types, but everything around the provided APIs and language semantics makes creating them hard. It's a similar solution with "our strings are UTF-8, but we don't check and world doesn't explode if they are not". I generally dislike this kind of "worse is better" design, but it certainly fits Go very well.

The main problem with Go, arguably, would be what to do with null pointers. They could have gone with separate reference types for "definitely not null" and "may be null", with a specialized if-like check-and-coerce-operation, without having full generics and sum types like Rust does.

Because Go has a GC and thus is capable of having arbitrary object graphs, there shouldn't be a problem of initializing multiple values with a reference to the same object, so user providing a default value and the API cloning it to fill the array should work. And in case of a "may be null" ref, having it to be null is not a problem.

Yeah "They terminated him for lack of transparency and honesty", which is ridiculous since the opposite was the case. (He was being transparent and honest towards his employer that he is being investigated.)

I own a home router (TP-Link Archer C7) and I have been running OpenWRT for many years on it, having full control over it via SSH. A few years back, I had an idea for an daemon process/service to improve a certain thing in its functionality. I was delighted to find out that the MIPS chip that powers the thing was supported by Rust, and I coded a "script", cross-compiled it to a binary and SCP't that to the router. It ran beautifully. After that (and running Rust on a few other embedded systems, including an ARM Cortex-R chip) I became convinced that Rust is the next C for the embedded.

It was a huge hit, and those tend to turn into classics with age. Gotta admit that it's making me feel old.

The maintainer of the DMA subsystem, Christoph Hellwig seems to vehemently oppose having an mixed-language codebase, and is using the confusion whether he as a maintainer has a say against the consumers of his APIs, to further his cause.

There was indeed some confusion about this, because the normal rule of kernel development is that if you change an API, you also fix the downstream users. (A standard-ish monorepo rule.)

However, because R4L is an experiment, the rule seems to be different: it's up to the R4L team to fix the Rust side if things break, so the upstream C devs don't need to care about Rust if they don't want to. (And conversely, they can't then weaponize their reluctance against Rust. That blade cuts both ways!)

However, apparently there wasn't sufficient clarity about this rule. Well, now there is.

This is the hugest release of Rust this far.

I think the article is wrong in that std::io::stdout would be panicking, or that "the panic is reachable somehow". It's just the optimizer doesn't see it doesn't panic.

https://doc.rust-lang.org/beta/src/std/io/stdio.rs.html#674-...

The implementation calls indeed a panicking API, OnceLock::get_or_init:

https://doc.rust-lang.org/beta/std/sync/struct.OnceLock.html...

But it only panicks if it is being used in a wrong way, which it isn't. The usage is contained within the implementation of std::io::stdout, so it's an implementation detail.

It's a shame that there are no better ways to eliminate panics in case they are impossible to trigger. The article shows some tricks, but I think the language is missing still some expressability around this, and the stdlib should also thrive harder to actually get rid of hard-to-optimize links to panic runtime in case of APIs that don't actually panic.

Based on my experience of just listening convos around me, danshari is the more popular method in Japan. At least, people talk about it more.

> making her basically German anyway.

Huh?

I've been living in Japan for more than 9 years. I think that the author is right in the sense that people in Japan seem to care more. Of course, the stress is on the word "seem". Some people truly care, but there is also the cultural expectation that you should care. I don't know if realising that counts as the "shine that will wear off", but it seems to not a bad default.

What are POSIX timestamps that don't correspond to any real time? Or do you mean in the future if there is a negative leap second?

But because of the UNIX time stamp "re-synchronization" to the current calendar dates, you can't use UNIX time stamps to do those "delta seconds" calculations if you care about _actual_ amount of seconds since something happened.

How do you define having real values? I'd imagine that a token-predicting base model might not have real values, but RLHF'd models might have them, depending on how you define the word?

How would passing on the left would risk a collision with a car coming from an opposite direction? The opposite lane is on the right hand side (in Japan)?

Yeah, I know, but I mean that it's normal to link together crates compiled with the same compiler, unlike with C, where ABIs are stabler and binary dependencies are more common.

By linking both and not allowing mixing types, i.e. it considers types from a totally unrelated with types from b.

Also, Rust compiles the whole world at once, so any ABI breakage from mixing code from different compiler versions doesn't happen. (Editions are different thing from compiler versions, a single version of the compiler supports multiple editions.)

What if one's name is not in alphabetic script? Let's say, "鈴木涼太".

Just use a recent nightly and you should be fine. Rust project doesn't offically provide support even for old stable versions, so "using nightly" with no specifics generally means using any nightly build, around or newer than, the current stable release.

There was an idea floated for another lint `#[diagnostics::lint_as_temporary(reason = "...")]`, which is supposed to be added by implementors of such locks. https://github.com/rust-lang/rust/issues/131154#issuecomment...

https://github.com/rust-lang/rust/issues/131154#issuecomment... Especially this matrix was helpful! The behaviour that's going to be adopted in Rust 2024 is the Rust2024.1 one. They were having doubts about the rules becoming too complex/non-uniform, but at least dropping early means compiler errors rather than deadlocks.