Except for C

Yeah, same. The fact I can chill the fuck out and basically not have to worry about an enormous class of serious, hard-to-spot bugs makes it a lot more fun for lower-level programming.

Like, yeah, I still need to worry about obstacles like other drivers, animals, etc., but it's a lot more fun driving on a road that isn't completely teeming with potholes and black ice.

Different strokes I guess. Personally, I do have a good time writing Rust and fun feels like the right word

Look, undeniably some coding languages are miles better than others, but I don't think any of them would fall under my personal classification of what the word "fun" means...

There are probably other private parts of the crates website, like the pages for developers who are uploading crates. It makes sense to just give the same error for everything, from the same logic all in one easily auditable spot.

And of course, just because all crates on the site are public now, doesn't preclude the possibility of private crates im the future.

Generally agree with the takes here and similarly befuddled that an unofficial site like lib.rs seems to be entirely better in almost every way than the official site. It's a bit disappointing.

I've unfortunately seen first hand the stubbornness of some developers on the Rust project when I tried to contribute a minor thing myself. I perhaps just had a bad unlucky experience, but it turned me off from ever contributing again.

it becomes possible to discover parts of the website that exist but you can’t access.

This doesn't really apply as a concept to crates.io though, as all crates on the site are public. It seems kinda like security theater to be doing these 403s when all the data is public anyway. GitHub doing this makes sense as there are private repos.

Only possible to authenticate with Github

They seem to be working on it

If you go to a page which doesn't exist, one would expect to get the 404 HTTP code (not found). So let's try when we query a crate which doesn't exist:

This is the only one I somewhat disagree with. If you give a 403 error whenever you don't have permissions to access a page, and a 404 whenever you access a page, it becomes possible to discover parts of the website that exist but you can't access.

It's because of this, that both Github and Forgejo just return 404 errors when you access a repo that doens't exist OR it's a private repo. A quick test with Codeberg against a repo that probably doesn't exist gives me an error 404 and the message:

The page you are trying to reach either does not exist, has been removed or you are not authorized to view it.

(emphasis mine)

Now, I would rather see 404 errors everywhere instead of 403's. It's way more likely that you are encountering a repo or website path that doesn't exist, than you lacking privileges/auth. But, 403's everywhere is an approach I've seen done before and it makes sense when you understand why.

Code viewing was always a part of rustdoc, and thus available via docs.rs. I actually don't like this violation of abstraction separation.

And doing this before doing the most obvious sensible trivial addition, a download link, is doubly ironic in my view.

A code viewer for the actual uploaded code is much appreciated. The upcoming diff view sounds really useful too.

Why the double-post? Same link was posted here ~45 minutes earlier

Thanks!

It sounds promising if you chose it for a similar reason.

I'll plan something and see if I can get all the core parts working.

And I agree with that core reason, it's why I chose dioxus too.

I've not bothered with component libraries, as my UI is ironically very simple, but the ecosystem is slowly growing.

For simpler stuff you can use tailwind out of the box with it's various libs.

I heard dioxus is react-like which tells me barely anything, as I've avoided writing any JavaScript in my 15 years of programming, but the rsx components seem intuitive enough for me.

You get a signal framework too, the usual rust examples/ dir is there to show how to do some things.

One thing I struggled with was auth, especially any SSO auth. There's barely any rust crates for it (and none high level ones), and dioxus docs aren't straightforward with how to integrate axum middleware. Gotta dig deeper.

For frontend only, it seems great. Other than wasm being a bit of a chunk to download it's quick, usually well hydrated and the UI seemingly being on one page with no page loads is cool.

Thanks. I'm a JavaScript developer. To create a webapp is relatively easy for me because I'm familiar with the tooling.

I see there are things like UI component libraries like dioxus-material... I suspect there will be things I might have to create myself. Are there nuances that might stand out?

What are your thoughts on the ecosystem with dioxus?

My core reason to consider dioxus over JavaScript is the ability to use more mature tooling for formal verification.

I've used dioxus a couple of times but I don't know if I have any general useful insights.

I've mostly used it for mobile, which does require a bunch of manual patching.

Fullstack/web seems ok. I like the auto-reload, and obviously rust tooling is relevant.

Any specific questions?

This should definitely be required follow-up reading, as it puts many of the Bun article's "too good to be true" claims into context.

The fact that the Bun author didn't know that Zig also has LTO really puts the rest of their claims into question.

https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html

Commentary/blog post by Andrew Kelley (Zig creator) for perspective!

Very interesting achievement, and of course requires domain knowledge to implement (which you can’t get without experience!)

Zig's features don't map 1:1 to Rust's features, so translating line-by-line (or file-by-file) doesn't even make much sense. What are you supposed to do with a crazy comptime function full of reflection when translating that? What about custom pointer types (which Bun had to create for Rust), lifetimes, differences in ecosystem library APIs, etc?

The author actually mentions the challenges they ran into due to breaking the code up across multiple crates. They needed to break cyclic dependencies for it all to compile.

I agree. 1 year is an underestimate.

Honestly, if this is tge future for software engineers,, I'll leave the fields when I ma forced to do it.

Rust-based JS engine that isn’t just AI generated unsafe everywhere

Tbf only 4% of the code was unsafe after the rewrite, which is much better than the 100% of the Zig code being unsafe. Honestly it's not surprising you'd have such a large amount of unsafe when you translate Zig to Rust. But as I understand it, it's since been refactored to much less than 4%.

I mean it was 600,000 lines of Zig prior to the rewrite yea? If we say that a team is ~6 people, that's 100,000 lines each to read through and translate. Assuming 250 working days in a year, that's 400 lines of code you just need to read every day, let alone the Rust you need to be writing (approximately another 400 lines).

Add to that overhead for planning and coordination... I actually think a year for a team might be an underestimate.

Eh if they're going to use C, they might as well give Zig a shot.

unsafe everywhere

Might as well use C at that point.

This Rust rewrite would've taken a team of engineers with full-context on the codebase a year of work

Doubt.

There are a lot of ways to do a terrible job of this. For example, prompting Claude "Rewrite Bun in Rust. Don't make any mistakes." and then praying it would work is not [sic] what I did.

Adversarial workflows seems like an awesome strategy for burning tokens if your workplace uses a token leaderboard. I'm glad to see that someone discovered a way to game the system!

I'm really hoping that Boa can compete soon. I'd love an embeddable, Rust-based JS engine that isn't just AI generated unsafe everywhere. I don't think they plan to really fit into the same space as node/deno/bun, but we already have node for that, and an easier to use JS runtime from within Rust would be awesome.