4 ms·

I often rant about everything related to the Delphi project I inherited, especially the stupid single pass compiler. But on the other hand having a blazing fast

I often rant about everything related to the Delphi project I inherited, especially the stupid single pass compiler. But on the other hand having a blazing fast compiler that compiles even very large programs within seconds makes makes developing, debugging and testing so much easier. Even better is developing a new project with vue.js and Vite, where changes in the code just show up in the browser. Often even without visible reload. Fells like magic.

ReactiveJelly 3y ago
Yeah, slow compile loops are the worst part of Rust for me. (The 2nd-worst part is fighting the borrow checker) I know it'll get faster as hardware marches on, but I often wish I could draw a boundary and say, "Look compiler, this program is months from being done. Let's say everything outside this boundary can be optimized and it won't change. But everything inside the boundary is quick-changing business logic that I'm actively debugging. Don't link or optimize across that boundary. Use wasm to enforce that if you need it." In C++ I did that with Lua for a while, but the DevEx cost of FFI boundaries is pretty awful even when the performance cost is affordable. I dunno.
- feoren 3y ago
  > I know it'll get faster as hardware marches on What makes you think this? Nothing else has gotten faster as hardware marches on. Almost all software is significantly slower than the equivalent (if it existed, of course) 20 years ago.
- senkora 3y ago
  Can you not achieve this in the build system using incremental builds plus disabling LTO plus specifying that some translation units shouldn’t be optimized?
Our_Benefactors 3y ago
> where changes in the code just show up in the browser I still reflexively refresh the page after making changes after being burned by hot reloading systems one time too many. Hot reloading systems are great when you have only static content, but usually fall apart once front end state is introduced. It would be incredible for the JS ecosystem to get a hot reloading strategy that “just worked”.
- KTibow 3y ago
  The one Vite has is pretty damn good

ReactiveJelly 3y ago

Yeah, slow compile loops are the worst part of Rust for me. (The 2nd-worst part is fighting the borrow checker) I know it'll get faster as hardware marches on, but I often wish I could draw a boundary and say, "Look compiler, this program is months from being done. Let's say everything outside this boundary can be optimized and it won't change. But everything inside the boundary is quick-changing business logic that I'm actively debugging. Don't link or optimize across that boundary. Use wasm to enforce that if you need it." In C++ I did that with Lua for a while, but the DevEx cost of FFI boundaries is pretty awful even when the performance cost is affordable. I dunno.

feoren 3y ago
> I know it'll get faster as hardware marches on What makes you think this? Nothing else has gotten faster as hardware marches on. Almost all software is significantly slower than the equivalent (if it existed, of course) 20 years ago.
senkora 3y ago
Can you not achieve this in the build system using incremental builds plus disabling LTO plus specifying that some translation units shouldn’t be optimized?

Our_Benefactors 3y ago

> where changes in the code just show up in the browser I still reflexively refresh the page after making changes after being burned by hot reloading systems one time too many. Hot reloading systems are great when you have only static content, but usually fall apart once front end state is introduced. It would be incredible for the JS ecosystem to get a hot reloading strategy that “just worked”.

KTibow 3y ago
The one Vite has is pretty damn good