(Edit: As this seems to trigger some people: I code in Rust. I’m just stating the facts.)
It sounds like maybe you're used to skipping part of the development process required for stable well-tested software. Maybe that works for UIs? Wouldn't want my runtime authors feeling that way.
Developers, on the other hand, seem to need some help running static checkers regularly. Most don't seem to have well exercised CI toolchains doing it for them. Or aren't aware that they should be doing so - like yourself.
Rust makes use of the tight integration between language, compiler, and checker to allow the language to be easier and more thoroughly checked than possible with checkers built for other languages. Many steps performed for compilation are reused. Which is what makes it so fast.
If you think "why can't I skip this?" you have missed the point and are exactly the target developer these checks are for.
I've written a lot of software. Never had a complaint about compile times in any language. The reality of developing with Rust is that after the first build, only changed files are rebuilt, which makes it just as fast to compile as any other language.
If compile times are what concerns you about a language, that tells me you're not very far along in your career. You have a lot more problems to discover which are very much more serious. If you ever encounter the problems Rust solves, you'll grow to appreciate it's solutions.
My largest rust project is still fairly small at around 8k lines across two dozen files. Still, it builds and links in 30 seconds on my workstation which is several years old and not particularly fancy.
I could see this beginning to become an issue around 100k lines of code, but I'd think most people would be looking to split into multiple crates before that just for readability.
This is objectively not true. “Go feels legacy to me and I wouldn’t use it in production in most cases” is reasonable, if you feel that way, but “legacy language” has a definition, and Go isn’t a legacy language.
On top of this, in its excessive caution about adding features while balancing incidental and essential complexity, it just hasn't evolved and kept up to meet the kinds of demands modern languages do like Zig, Rust, C3, Carbon and Odin, and while these languages were innovating, Go was still catching up to 10-20 years ago at any given moment. It was already kind of a weird middle ground, not quite as high level as Ruby, not quite as low level as C++, and this slow catch up game plus lack of keeping up was, for me at least, just the nail in the coffin. But all of this together makes me personally think that it's just not a great fit for most scenarios, but also that it seemed to have started off on the wrong foot with itself and the wider programming community.
That's my take at least.
For those who aren't familiar, Luau is a language based on Lua that is developed and maintained by Roblox. It's entirely open source (you can see the repo here: https://github.com/luau-lang/luau) and it's diverged a fair bit from Lua at this point. Most notably, it's quite a bit faster than the PUC-Rio distribution of Lua, has native vector support, and has a type checker. It's not as fast as LuaJIT, but it's about as fast as you can expect for a non-JITed language and it has support for AoT compiling to native instructions on x86 and aarch64, so it can be basically as fast as LuaJIT for some tasks.
It's worth reading the website: https://luau.org/
Lune itself is nice and I use it for basically all of the scripting needs I have. Some of the API is limited compared to what you'd get in other runtimes (the obvious example is hashing, where it's just "string in, string out" instead of a stream that you can feed into and then finalize) but the logic is essentially that APIs should be "good enough" for the average user, not perfect. I think that's fine, but I'm also the one that wrote the hashing API so take it with a grain of salt. :-)
The WASM build is actually what powers the demo on their website: https://luau.org/demo
90s_dev•5h ago
My main gripe with Lua (and thus Luau) is colons. It's so easy to forget them. Does the type checker catch this error? And if so, does it catch it every time, provided you always use types? If so, that could be good enough for me. Especially if it has strong LSP + VS Code support.
gsck•5h ago
LoganDark•5h ago
Moomoomoo309•5h ago
debugnik•4h ago
I'd check for myself but Luau's web demo seems to lack the most important feature of their dialect, type checking.
parenwielder•3h ago
debugnik•2h ago
Since you're here: Is it reasonably feasible for users to add declaration files for code exported from the host application? The lack of documentation got me stuck the last time I tried to embed Luau. Aside from that, I'm very excited about it!
deviaze•1h ago
This is just because definition files don't support doc comments yet (for hovers w/ luau-lsp)
SkiFire13•4h ago
Lua has a type checker?
parenwielder•3h ago