It's all the stuff that people always mention; they are not wrong. You spend a decent amount of time... conversing with the compiler about lifetimes and, in my experience, even more so about the type system, which is _extremely_ complicated. But you also have to keep in mind that Rust got very popular, very fast, and the tail end of something like that is always a negative reaction. The language is the same, despite the hype roller coaster.

I'm not OP but here's my disadvantages. Rust is the way I earn my living, and also my open source tool of choice. And my background is 25 years of SWE career:

1. build / compile times can be atrocious

2. crates.io inherits the npm philosophy, which means fairly unmoderated space of third party deps and because the Rust stdlib doesn't have a lot in it, extensive third party crate (lib) usage is strong in Rust. As a result most Rust projects have rather sprawling dependency trees, often with duplicated functionality (multiple Base64, rand, sha256, etc crates). I personally have a problem with this (auditability, accountability, security, complexity etc). Others don't.

3. Despite being nominally runtime agnostic, Rust async basically is tokio and it's almost impossible to use another runtime once you factor in third party deps. In many ways Rust is the language that tokio ate. In fact even if you opt out of async entirely, you often end up with tokio as a dependency simply because the community just seems to expect it.

4. Despite advertising itself as a "systems" language, some basic systems programming facilities I expect from my C++ background are still fundamentally not there. In particular, per-container/struct pluggable allocators still isn't a thing and the feature to add it (allocator-api) has sat unmerged in nightly for almost ten years at this point and it doesn't look good for it landing any time soon.

5. If you're working in the embedded space, there's still plenty of devices that will not have a workable Rust toolchain option yet.

I still choose it for new projects instead of its competitors C++ or Zig. But I think it's important to recognize there are compromises like any other tool.

As much as people might insist otherwise, there will in fact come a day when there are "multiple Rusts" by which I mean multiple styles and ways of doing things -- just like C++. For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there. And I don't use tokio. Though my paying jobs do.

They've been stuck with swift adoption for a long time, abandoning that was the reasonable decision. That only leaves Rust as the second language to C++

Honestly I find writing Rust more fun than writing Python. Python just doesn't scale, any non-trivial quantity of it has a habit of turning into spaghetti however hard I try to be disciplined.

Rust, although annoying at a micro scale, does at least enforce some structure on your code, although like Kling I miss OO.

AI has made Rust approachable to a new audience of programmers who didn't want to dedicate their life to learning the ins and outs of the language. Especially for C++ developers who already learned the ins and outs of a hyper complex programming language and don't want to go through that a second time.

Before AI, writing Rust was frustrating experience that involved spending 90% of your time reading documentation and grumbling that "I could do this in 5 minutes in C++"

Now I can write Rust in a way that makes sense to my C++ addled brain and let the AI do the important job of turning it into an idiomatic Rust program that compiles.

Its for the time being is stuck with LLVM, so I can't currently LTO with GCC objects. Its got a lot higher complexity than I perfer in a language. A lot of features I find important seem perma-unstable. Pin is unnessesarily confusing. No easy way to define multiple compilation units for use with linker object selection and attribute constructor. The easy path is downloading binary toolchains with rustup and not using your disto package manager. You can't use unstable features without the bootstrap env var on distro rust toolchains. Cargo leads to dependency bloat. The std/core crates are prebuilt binaries and bloat binary sizes. Bindgen doesn't translate static inline code. The language has a ton of stuff it exposes just to std and not user code. Unsafe code is unergonomic. No easy way to model a cleanup function that needs more args. No support for returns_twice. No ability to use newer stuff like preserve_none. Can't go-to-definition from a bindgen binding to original header file. Macros pollute global namespace. Can't account for platforms where size_t and uintptr_t are different. Traits can only be relied on if marked unsafe. Can't implement something like defer since it holds a borrow. no_std code still can pull in core::fmt. Can't enforce dependencies are also no_std. Panics are considered safe. No way to add non-function fields to dyn vtables. No way to declare code separately from definition. No way to have duplicate type definitions that merge, making interop between different bindgen generated modules annoying.

To me, a project's "hype-ness" is the ratio of how much attention it gets over how useful it actually is to users.

As a browser, Ladybird usefulness is currently quite limited for obvious reasons. This is not meant to dismiss its achievements, nor to overlook the fact that building a truly useful browser for everyday users is something few open source teams can accomplish without the backing of a billion dollar company. Still, in its present state, its practical utility remains limited.

> What does Ladybird need to achieve in your opinion to shake the "hype" label?

A release (?)

they tried swift, it didn't work, and they figured rust was the best remaining option. that's not "flip-flopping" (by which I assume you mean random indecisiveness that leads to them changing their mind for no reason)

They made a very pragmatic and sensible decision after reviewing Swift that it wouldn't be suitable for their purposes, so they shifted to the next best alternative. I think they reasoned it very well and made a great decision.

I guess they bet on Swift being more than Apple's blessed way of writing UI software.

It's not that they are loving Rust, but they realized going all-in on Swift means becoming sharecroppers on massa Tim Apple's plantation.

Upside: he's learning?

Why would 200 contributors have to be okay with this migration? The project has a leader, the leader makes decisions.

Doesn’t sound like a bad thing to evaluate the most obvious alternative to build confidence before officially pulling the plug.

Swift adoption had been dead long before the actual announcement. It's likely Rust was being considered long before this two week experiment with LLMs.

in case it's not glaringly obvious from the comment, he has plenty of cpp experience and little rust experience, and that's according to his own comments

the relevant bit here is that he's porting from a language in which he has plenty of experience into another one in which he doesn't, in a large project

that in itself sounds like putting a lot of faith in LLMs but maybe there are factors not mentioned here, which is why i said "on the surface"

It's hard to articulate, but as someone who knows first hand, I just want to say that manic productivity is not the same as solid engineering.

I did, and the point stands because reading someone else's code is not the same as writing it, esp. when you're not able to do so to the same standard