Average Amazon experience these days (stop buying from them, enshitification is strongly progressed there)

.

deleted by creator

because the massive ecosystem of JS components makes you more productive.

Slightly less ironic: I question even this right now (as I have to suffer from endless “hot”-reloading and browser-crashes because of Next.js bloat).

I think the massive ecosystem has fewer high quality libraries than Rust at this point. I use both JS/TS in frontend and Rust (either frontend more as a hobby and backend) extensively, and I very often check the dependencies-source, and even more often rewrite it (unfortunately not in Rust), because of low-quality. And it’s sooo slow… the tooling and the frontend (albeit I think that has a very lot to do with next.js… and with how easy it is to make it slow for someone not that experienced or someone not being extremely careful).

Frontend is not yet as matured as JS/TS (whatever matured is, but the count of frontend frameworks is at least a magnitude higher in JS/TS), but I think when I would start a new company I would default to Rust now as frontend indeed, the language itself is for me reason. And I think vanilla-js (or Rust?) is not that much worse (time/effort-wise, sanity etc.) for more complex applications than what the Next.js ecosystem has produced so far.

Actually, my (not that small) Rust projects now take officially less time to cold compile than the “hot” reloading of our next.js monster in my job. Incremental compilation is at least an order of magnitude faster. And cherry on top, dumb code is often 100x faster than js.

You can’t imagine how often I just sweared today about js. What did go through the mind of their designers, when they created this growing disease, and why did web browsers accept this as the lingua franca for the web. So… much… pain…

Definitely not your average Rust code, more like a very ugly example of it.

Also, as the syntax first put me off as well, I gave it a chance years afterwards, and have now (or rather years ago) officially joined the church of Rust evangelism.

A lot of the syntax you define as ugly makes sense when you learn it, it’s just so much more explicit than a more dynamic language, but that exactly saves your ass a lot (it did for me at the very least) (I don’t mean macros, macros are ugly and should be avoided if possible)

Right… And the best tool for every job is of course Rust.

The problem though (with AI compared to humans): The human team learns, i.e. at some point they probably know what the mistake was and avoids doing it again. AI instead of humans: well maybe the next or different model will fix it maybe…

And what is very clear to me after trying to use these models, the larger the code-base the worse the AI gets, to the point of not helping at all or even being destructive. Apart from dissecting small isolatable pieces of independent code (i.e. keep the context small for the AI).

Humans likely get slower with a larger code-base, but they (usually) don’t arrive at a point where they can’t progress any further.

Not really, but similar.

I guess good for us left leaning men?

On the other hand kinda sad, it further drives the fertility-rate downwards (see south-korea, which has a bad future because of this…)

That’s btw. also a good argument for Rust. Due to the strictness of the language the compiler os able to do optimizations that just aren’t possible (safely) in C or C++

From Scratch (as much as I like Rust, it’s very likely more verbose from scratch). Haskell is perfect for these kinds of things.

Have you thought about just wanting to preserve privacy?

Don’t get me wrong, I’m the first promoting an Android free mobile Linux, free of big company influences.

Though, what I meant is that there’s very few mobile optimised apps on Linux, and I doubt that changes soon. The Android SDK is very matured (like Compose for UI). It’s fairly easy to create a good native app experience in Android. Less so for non-Android Linux. (I’ve developed apps for either) Think about that alone, which further complicates adoption, which TBH is just necessary to get to an ecosystem that us usable for daily usage.

I hope that changes sooner than later, but the current alternatives are just not there yet.

You wouldn’t need it on Linux mobile because…it’s not Android

But then you need apps that work on Linux (optimised for mobile/touch). You can also easily create Apps for Android without play integrity API necessity.

Realistically an Android fork makes more sense.

Though in my ideal dream world a Rust based mobile wayland compositor (etc.) will be the future of open mobile OS. I hope there’s enough (financial) interest to at some point reach that future.

I’d still call it extrapolation, it creates new stuff, based on previous data. Is it novel (like science) and creative? Nah, but it’s new. Otherwise I couldn’t give it simple stuff and let it extend it.

Sounds like pain in the ass, I really like the auto-fill feature of Bitwarden… (or in my case vaultwarden as backend)

Arghh, why is every company thinking, that AI will make them valuable…

“Let AI retrieve, generate and manage all your credentials”

Yeah a definite nope, for what reason do I use bitwarden? So that exactly this doesn’t happen…

Anyway vaultwarden is what I’m using, much more performant and self-contained, compatible to bitwarden (but you need to host it, obviously)…

Independently of what your position to vibe-coding or LLMs are: Vibe coding just isn’t any programming paradigm. A programming paradigm describes the structure of the program, often on a grammatical (programming language) level (e.g. declarative vs imperative). While “Vibe Coding” can lead to using one or the other paradigm, but is not a paradigm itself, it’s a tool to achieve that, similar as using an IDE with code-completion to generate code.