> just use async everywhere. That’s not the solution in Rust. It simply won’t work for the same reason that Rust isn’t GC’d.
At this point, I have to say RC is a primitive form of GC and it would mostly work. Not high performance but it would work.
> To be clear, I hate programming language development driven by memes. I don’t think that was the case with Rust async
First, most programming is driven by fads. Second, my point was that if Rust waited more people would pan it for not having async.
Rust async was "rushed". It took years, but we still didn't get smooth experience out of it. Many pieces were missing.
It was rushed because many people wanted it, many developers were sick of having it in limbo, etc.
> Today, in safe rust, it is impossible to allocate a structure larger than the stack. Placement new is always just around the bend.
I don't follow Rust development too detailed nowadays, but if you are experiencing hardships, have you considered providing support to it? Either via money or time donations?
I understand complaining that some closed source company is prohibiting you from doing something, but this is an OSS project.
> But comments like these and others on this thread is exactly why I may not in the future.
Please take your C style memory bugs with you.
In case anyone reading the thread would like quality information about Rust and memory safety, a great place to start is: https://www.youtube.com/@NoBoilerplate
> But when I read stuff like this I remember why I love using Go every day.
Me too! I wrote a window manager in Go[1] that I've been using for years now. I love that it takes <30 seconds to download and compile the whole thing. No C dependencies (compile or runtime) at all.
With that said, doing it with Rust should be almost as easy. There's no `cargo install` command, but I think it's only a matter of time. :-)
Your ideas seem cool, by the way! Sharing CSV data would be especially nice.
>Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker.
> I wish Rust would switch to mimalloc or the latest tcmalloc (not the one in gperftools).
That's nonsensical. Rust uses the system allocators for reliability, compatibility, binary bloat, maintenance burden, ..., not because they're good (they were not when Rust switched away from jemalloc, and they aren't now).
If you want the rust compiler to link against mimilloc rather than jemalloc, feel free to test it out and open an issue, but maybe take a gander at the previous attempt: https://github.com/rust-lang/rust/pull/103944 which died for the exact same reason the the one before that (https://github.com/rust-lang/rust/pull/92249) did: unacceptable regression of max-rss.
Five years ago Rust still had green threads. Literally every standard library I/O function was async, and the awaits were always written for you with no effort.
Its literally taken five years to get back to an alpha thats not as good, and we'll still have to wait for a new ecosystem to built on top of it. I know not everyone writes socket servers and so forcing the old model on everyone probably doesn't make sense long-term, but I still have to shake my head at comments like this.
>There’s already an OS completely written in Rust called Redox. Nobody uses it.
I find it would be very difficult to convince anyone to use any other OS than the currently mainstream ones. You should instead see this as an accomplishment of what Rust can achieve.
I also think you are undermining Redox OS developers efforts, which is kinda sad.
>Rust code is guaranteed to be fast and guaranteed to be bug free
Nobody claimed this, what people claim is that it can be as fast as C, and it has some safety guarantees. You can still have bugs.
>Rust is for writing blog posts...
What's so wrong about people being excited about something? Personally I find it awesome that a programming language can bring so much enthusiasm to people. In my opinion, what you are seeing here is people being excited about progress being made.
>the compiler authors so wonderful and smart
I sense some envy here, people achieved a great thing through effort and collaboration, we should celebrate this.
This is what's been so off-putting about Rust, to be honest.
"I should never assume" is precisely what bothered me.
I loved Rust at first, but it required so much maintenance with its constant changes between versions, that I stated to dislike it. I didn't have much time (and I enjoy learning new languages), but when I had to virtually unlearn something just learned the previous day, it became frustrating after a few iterations.
A colleague at work once sneered at me when I suggested I could do my next [internal] project in Rust; I didn't end up using Rust, because I got self-conscious about the idea, and kinda got scared that I'll have to do much, much more work simply because completely valid code would not work in a few days. That feeling is kinda stuck with me to this very day, even though Rust wasn't a stable release back then, and now is.
Not to mention, there's people I've talked to about Rust who still feel like Rust isn't mature and never will be—simply because of it's "reputation."
[1]: They were referring to how dramatically and chaotically it changed before the first stable release.
> The amount of time our industry wastes on C++isms is ridiculous where rust just works.
This implies that Rust doesn't have any problems, which is...crazy.
In addition to the problematic community, just rearchitecting your code to fit around the borrow checker can be a massive amount of work, which already makes it infeasible for use in some places where the primary work is not on greenfield projects but on legacy code.
> Unfortunately theres an old guard that refuses to let up and invest in rust.
...and this is just emotionally manipulative, in addition to incredibly dishonest about the problems that Rust actually has.
> Unless you're expecting some sort of blind worship, I expect pointers to source code. I found libstd/gc.rs, so I'll assume that it's what you're talking about. Let's see what's "basically" done, shall we?
I don't really want to draw out this argument, but I called your reply FUD because you were claiming things that were not true, such as that we cannot implement tracing GC.
> They used a checkbox, blanket argument against GCs, where the discussion was specifically about Go. It is just something I've noticed about the Rust team -- they overwhelmingly hold Go as their foe, and most if not all advocacy seems to be targeted at Go.
No they didn't. You just perceive it this way because fans of Rust often post in threads adding 'What about Rust'.
Fans non withstanding, I haven't really seen pcwalton or others (top 10 Rust contributors) behaving as you said they do. They comment on GC and various Firefox related technologies. Once the talk comparing Rust/Go starts, but I don't think they are as dismissive as you paint them.
But hey, prove me wrong, cite some messages.
--------------------
> In many other domains it needs to be analyzed, and there are no hard and fast rules. As I mentioned, the overhead of GC in most real-world Go solutions is close to if not completely irrelevant. Simply pointing it out as a checkbox, especially compared to what is effectively vapour right now (meaning you can't coherently compare solutions because one player is entirely unequipped to do so), is vapid laziness.
I offered no checkbox, just an explanation why people are excited about Rust. To me the greatest power comes not so much lack of GC, but concurrency, safety (no nil, compiler errors on unassigned variables) and zero cost abstractions.
> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary.
Assuming you're not a kernel developer, I don't understand why you need the feel to be offended in their stead, as they don't really seem to mind at all.
> Zig, D, Ada
(i) not yet stable; (ii) torn apart between two runtimes, not really GC-free; (iii) has a... complicated toolchain story, and basically didn't exist in a free/libre aspect on PC until very recently – and didn't/doesn't compile on 90% of Linux targets.
> The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be".
No, the only reason there is a push for Rust in the kernel is because people are interested enough to write the code to get Rust in the kernel.
> it does rub me the wrong way and makes me stop and think a little bit when one particular language is held on such a gigantic pedestal.
Maybe you should stop and think a little bit on why kernel developers, arguably among the most competent ones on this subject, put Rust on what you perceive as a "gigantic pedestal".
Wait until you learn how Rust now has a crate that implements seamless concurrent tracing GC, just like Go... https://redvice.org/2023/samsara-garbage-collector/
reply