This is the 3rd copy of a flagged comment within a single minute.
Readit Newswhytevuhuni commented on The Tor Project is switching to Rust itsfoss.com/news/tor-rust... · Posted by u/giuliomagnifico
whytevuhuni commented on Rust in the kernel is no longer experimental lwn.net/Articles/1049831/... · Posted by u/rascul
> The damage from the correction that comes later will do so much harm.
Which part here is misinformation? Do you know something we, or the author, does not? I'm quite curious what that might be.
whytevuhuni commented on Thoughts on Go vs. Rust vs. Zig sinclairtarget.com/blog/2... · Posted by u/yurivish
I think a better example might be logging. How is this typically solved in Rust? Do you have to pass a Logger reference to every function that potentially wants to log something? (In C++ you would typically have functions/macros that operate on a global logger instance.)
In Rust you typically use the "log" crate, which also has a global logger instance [0]. There is also "tracing" which uses thread local storage.
As another comment said, global state is allowed. It just has to be proven thread-safe via Rust's Send and Sync traits, and 'static lifetime. I've used things like LazyLock and ArcSwap to achieve this in the past.
whytevuhuni commented on Why we built Lightpanda in Zig lightpanda.io/blog/posts/... · Posted by u/ashvardanian
The mentality around lifetimes is different in Zig if you are using it for the correct types of problems.
For example, a command line utility. In a CLI tool you typically don't free memory. You just allocate and exit and let the OS clean up memory.
Historically compilers were all like this, they didn't free memory, they just compiled a single file and then exited! This ended up being a problem when compilers moved more into a service model (constant compilation in the background, needing to do whole program optimization, loading into memory and being called on demand to compile snippets, etc), but for certain problem classes, not worrying about memory safety is just fine.
Zig makes it easy to create an allocator, use it, then just free up all the memory in that region.
Right tool for the job and all that.
I've been having an absolutely great time with Rust's bumpalo crate, which works very similarly. The lifetime protection still works great, and it's actually a lot more permissive than normal Rust, since it's the same lifetime everywhere.
The sad exception is obviously that Rust's std collections are not built on top of it, and neither is almost anything else.
But nevertheless, I think this means it's not a Zig vs Rust thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's stdlib can be replaced via #[no_std]. In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.
whytevuhuni commented on Zig's new plan for asynchronous programs lwn.net/SubscriberLink/10... · Posted by u/messe
> But that's the thing, idiomatic Rust sync code almost never passes around handles, even when they need to do I/O.
Because they don't use async inside.
Zig code is passing around handles in code without io?
> Because they don't use async inside.
But they use I/O inside, and we arrive at this issue:
I'm writing async, and I need to call std::fs::read. I can't, because it blocks the thread; I could use spawn_blocking but that defeats the purpose of async. So instead I have to go look for a similar function but of the other color, probably from tokio.
In Zig, if you're writing sync, you call the standard library function for reading files. If you're writing async, you call the same library function for reading files. Then, the creator of the `io` object decides whether the whole thing will be sync or async.
whytevuhuni commented on Zig's new plan for asynchronous programs lwn.net/SubscriberLink/10... · Posted by u/messe
just pass around handles like you do in zig, alright?
also: spawn_blocking for blocking code
But that's the thing, idiomatic Rust sync code almost never passes around handles, even when they need to do I/O.
You might be different, and you might start doing that in your code, but almost none of either std or 3rd party libraries will cooperate with you.
The difference with Zig is not in its capabilities, but rather in how the ecosystem around its stdlib is built.
The equivalent in Rust would be if almost all I/O functions in std would be async; granted that would be far too expensive and disruptive given how async works.
whytevuhuni commented on Zig's new plan for asynchronous programs lwn.net/SubscriberLink/10... · Posted by u/messe
yes, you can:
runtime.block_on(async { })
Here's a problem with that:
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
whytevuhuni commented on Several core problems with Rust bykozy.me/blog/rust-is-a-... · Posted by u/byko3y
I don’t think i’ll ever understand the compile time argument https://xkcd.com/303/
One thing that this blog doesn’t address though, is the cult-like following of Rust. It’s like the “AI” of oss — a main selling point by itself despite not being a feature. Seemingly, there is an assumption that software written in Rust is inherently better than any other, or that if something is written in Rust, it cannot have any errors.
Sure, new software should be written in it instead of C. But why fix programs that are already memory safe?
> Seemingly, there is an assumption that software written in Rust is inherently better
Yes. Both Rust and its standard library have features that make programs be less likely to have problems.
> than any other
No. It's just better than the languages that are very popular right now.
> or that if something is written in Rust, it cannot have any errors.
No. How people keep jumping from "better" to "absolutely 100% infallible" is beyond me. Nobody is claiming this.
> But why fix programs that are already memory safe?
Because:
1. Programs that are already memory safe still need to be improved, and those improvements are really dangerous in a dangerous language
2. Things like https://news.ycombinator.com/item?id=46013579
whytevuhuni commented on The worst programming language of all time [video] youtube.com/watch?v=7fGB-... · Posted by u/todsacerdoti
> it's the obvious comparison to make
Why do you think that? I think these two languages have pretty little in common besides a few (remote) syntactical similarities. Both languages have their merrits and weaknesses, but I don't think that one is able to fully replace the other. I would rather compare C++ to Ada or D.
That's a very unusual take. Rust (in its 1.0 form) was precisely made to replace C++, since the goal was to replace as much of Firefox's code as possible with it.
Also, if you cannot afford a GC, then languages like Ada and D are indeed decent alternatives... but D without a GC is very limited, Ada without SPARK is not as safe nor as ergonomic, and Ada with SPARK is very difficult to scale to larger projects.
Ada is very scalable, suitable for everything from blinking LEDs on an AVR microcontroller board to controlling interplanetary spacecraft. Similarly, SPARK can be used incrementally, proving lower level or critical parts first.
How does this SPARK/non-SPARK mix compare to Rust's safe/unsafe mix though, in terms of both safety and pragmatism for larger non-interplanetary software? Like, for creating a CLI tool, a GUI application, a game, a web server?