Yeah. I've been getting quite a few timeouts with compilation. I'd recommend they could just check to see if the code has been modified in the examples, and if it hasn't then just pipe the results out using JavaScript/cached results. There are a few things I'm interested in (such as seeing what printing a void function comes out as) which I can't currently run, and which don't really need anything to do with the server
Yes, I've noticed the Rust compiler does fancy stuff like check for similarly named constants, check constants have uppercase names, do static analysis to check that I've kept my immutable variables immutable, check that a semicolon is always at the end, and so on. I've never found those necessary in Go...
Most of these are written in such a way that they don't affect the happy path and if they do their pact is negligible. Are you saying that these checks are completely unnecessary, or are you saying that you'd prefer a faster compiler over one with more checks?
Edit: To expand on "don't affect the happy path": most of those extra lints, checks and suggestions will be performed only if the error condition has been met. If your code doesn't trigger a mutability error, or a missing identifier error (to take from the parent's examples) the searches for suggestions are never executed. For others like style lints, those add some time to processing, but they are linear in time, we tag things that miss a lint during parsing or other passes and then emit them later.
The bigger costs as I understand them, are that everything needs to get passed through LLVM, and that the widespread use of generics increases the amount of generated code that passes through LLVM.
Last I heard, the biggest source of compile time in rustc is emitting absolutely enormous amounts of LLVM IR and leaning on aggressive low-level LLVM optimisation passes to clean things up. There are efforts to make most of these optimisations earlier that have been landing in recent releases, but I'm not sure what the overall state of it is.
I they have started doing work on that? I can't recall what it was exactly, but there was one constant or number (I'm so good at being specific) related one that did the optimization on the rust side instead of on LLVM's side.
2. create a new project with "cargo new foo"
3. add the code to the SRC/too.rs file
4. run with "cargo run"