The latter argument is actually fairly reasonable. (Which doesn’t mean that we shouldn’t try to make Rust as suitable as possible for them now and in the future, of course.)
-
-
My spicy take would be that, even if you don’t like Rust, designing and implementing your own language to write your large program in would be cheaper than trying to write C++ at scale
3 replies 0 retweets 25 likes -
That might be true for an initial implementation but over time the cost of maintaining an in-house toolchain will really add up, and you’d be competing with Apple/Google/Microsoft/Intel for compiler developers
3 replies 0 retweets 6 likes -
OTOH I’m sure at least some compiler developers would appreciate having a wider job market than the big evil Bay Area cos
2 replies 1 retweet 13 likes -
Replying to @jckarter @slava_pestov and
LLVM has evolved into a giant pile of complexity of its own but it did greatly bring down the cost of making a native AOT compiler competitive with C compilers. VS Code and the LSP could have a similar effect on IDEs
3 replies 2 retweets 10 likes -
Replying to @jckarter @slava_pestov and
There is always the compile to C route you can take as well and take advantage of the existing C/C++ compiler infrastructure. It's a shame that so many disregard this approach.
1 reply 0 retweets 1 like -
Replying to @d0m96 @slava_pestov and
It's not a good approach. C is a terrible IR; standard C can't express a lot of things you might want, and it's tricky to specify precise semantics without UB. Furthermore, you're also stuck with a C toolchain as a dependency, and an expensive part of your compiler pipeline
4 replies 2 retweets 11 likes -
C is a terrible IR but it's 10x easier and faster to bootstrap with a C toolchain compared to LLVM. Nim bootstraps itself from nothing but gcc and make in about 6-7 minutes including the compiler, stdlib and package manager.
1 reply 0 retweets 2 likes -
No doubt; it'd be great to have an alternative to LLVM that was stabler, smaller, and less dependency-burdened. Targeting C definitely has advantages if you don't want to write your own assembler(s)
2 replies 0 retweets 2 likes -
psst. Cranelift ;)
1 reply 1 retweet 8 likes
Honestly, if I were y’all I’d seriously think about using Cranelift for a “fast turnaround” compilation mode for Swift, just as we’re doing for Rust.
-
-
We could conceivably have a "fast isel" mode that directly lowers SIL to assembly too. As we've built out the runtime and started investigating code size, a lot of our unspecialized generics codegen has been drifting toward more bytecodey things
1 reply 0 retweets 1 like -
Isn’t most of Swift’s compile time in the front-end though?
1 reply 0 retweets 0 likes - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.