Comment by kobzol
1 day ago
I don't think we hit a bedrock. As I wrote, we have a lot of ideas for massive improvements. But we need more people to work on them.
1 day ago
I don't think we hit a bedrock. As I wrote, we have a lot of ideas for massive improvements. But we need more people to work on them.
>But we need more people to work on them.
That's my point: I don't see how there could be people dedicated to work on an issue as grand as this in Rust's current organizational form. Especially considering all the gotchas, and continuous development of 'more fun' things (why work on open source if it's no fun?). That's why it's 'the bedrock'.
To do something like that, Rust would need to be forked and later on rewritten with optimizations. But by then it wouldn't be "Rust" anymore, it would be a sibling language with rusty syntax. Rust++, perhaps.
> I don't see how there could be people dedicated to work on an issue as grand as this in Rust's current organizational form
You're getting half ways there of giving actionable feedback, what exactly is the problem with the current organization structure that would prevent any "grand" issues like these? Is there a specific point in time when you felt like Rust stopped being able to work on these grand issues, or it has always been like this according to you?
> why work on open source if it's no fun
It's always fun to someone out there, I'm sure :) There are loads of thankless tasks that seemingly get done even without having a sexy name like "AI for X". With a language as large as Rust, I'm sure there might even be two whole people who are salivating at the ideas of speeding up the current compiler.
>what exactly is the problem with the current organization structure that would prevent any "grand" issues like these?
Well, it's summarized quite well here:
>"Performing large cross-cutting changes is also tricky because it will necessarily conflict with a lot of other changes being done to the compiler in the meantime. You can try to perform the modifications outside the main compiler tree, but that is almost doomed to fail, given how fast the compiler changes8. Alternatively, you try to land the changes in a single massive PR, which might lead to endless rebases (and might make it harder to find a reviewer). Or, you will need to do the migration incrementally, which might require maintaining two separate implementations of the same thing for a long time, which can be exhausting." - OP
A rigid organizational form (such as a company) can say: "Okay, we'll make an investment here and feature freeze until the refactors are done". I have a hard time seeing how the open source rust community who are doing this out of passion would get on board on such a journey. But maybe, who knows! The 'compilation people' would need to not only refactor to speed up the compilation times, they'd also need to encourage and/or perform refactors on all features being developed 'on main'. That, to me, sounds tedious and boring. Sort of like a job. Maybe something for the rust foundation to figure out.
2 replies →