1/n Ok as promised a thread about Rust. What I like and what not.
The base lang/syntax is reasonably concise. if expressions, return expressions, and type inference let you write clutter-free, dense code to some extent. Typical Rust code I read doesn’t take advantage of that tho.
The base lang/syntax is reasonably concise. if expressions, return expressions, and type inference let you write clutter-free, dense code to some extent. Typical Rust code I read doesn’t take advantage of that tho.
2/n The linear memory model seems cool for basic cases. The borrow checker is a bundle of implementation details and limitations, if you stray off the beaten path you enter a world of *ugh*. The marketing line “the borrow checker makes you write better programs”, I don’t buy it.
3/n IME, if the borrow checker starts throwing its hands up, its Rust signalling you to stop relying on its smarts. High-level ends here: fall back to copy, opt into shared rc references (super verbose), or hack your own allocator. Mucking around with lifetime parameters...
4/n Not worth it! I expect as the borrow checker gets better, more of the basic ground will get covered, but I expect that the threshold to pull the break-line and escape linear managed memory will always stay low. Using the unsafe hatch to escape brings me to encapsulation...
5/n AFAIU, in Rust there will be a tension between simple but plenty kernels of unsafe, and trying to avoid unsafe as much as possible using complex language features. I consider the latter to be bad. Leads to complex code that mainly describes the current state of the rust impl.
6/n OTOH basic encapsulation of unsafe kernels seems to work well, giving you some cool run-time and compile time invariant checks. Cool because I dunno how big the safety gains are in practice, definitely gives some peace of mind tho. (Limited lines of possible mem. corruption.)
7/n Within the kernels of raw hackery, you face some resistance: pointer arithmetic, and casting between types (fat/raw pointers) are very verbose. Barely tenable?
But to get back to general language verbosity... it’s right on the edge.
But to get back to general language verbosity... it’s right on the edge.
8/n Rust wants you to be super explicit with everything. It can infer variable types, but it won’t convert a u16 to a u32 by itself. You have to type bar(&mut foo) even though there is no other way to call bar with foo.
9/n libc access is *almost* as painless as with ljsyscall, except lots of type casts (rust str <-> C str, rust ptr <-> C ptr).
Generally strings are a pain in rust. I.e., &str vs String dichotomy: again you need to handhold and convert manually.
Generally strings are a pain in rust. I.e., &str vs String dichotomy: again you need to handhold and convert manually.
10/n Fearless concurrency is another marketing line that I don’t buy into at all. Rust expects you to use threads, shared memory synchronization between threads, and that everything be thread safe. The cargo test runner will run your tests in parallel using threads by default...
11/n If you don’t want to write your program this way you have to fight Rust. For instance: having global mutable state requires a crate and some verbose convincing. Again we have this conflict between pervasive complex language features and conscious encapsulation by the hacker.
12/n Inline assembly works OK, obviously not intended to be used for extensive ASM hacking. Could be really good for some use cases if some warts are fixed. Slightly related: LLVM tries hard to break your code, not even "volatile" ASM is safe from being optimized out a loop...
13/n ...compared to LuaJIT I had a really tough time writing micro benchmarks that actually run. Seems to be really an LLVM issue, but that’s what you get when you pick Rust. This sort of f*ckery really messes with confidence in the compiler btw.
14/n To summarize rust: lots of goodies for low level hacking, falls short for high level hacking, mainly due to missing options (besides Rc<Refcell<T>>) to fall back to for managed memory. Complex features of rust that try to make it a high-level language are IMO best to avoid.
15/n Nim finds a middle ground here by giving you a succinct GCed ref type, but maybe its OK to just use rust for low level stuff and link Lua for high level? \o/
16/n On high-level features... Traits... can do a lot of things, get really mental really quickly. I don’t really enjoy them. Dynamic trait objects... again super explicit/verbose... work OK for some use cases (keeping in mind the limited managed memory support).
17/n Finally, I can imagine myself doing some pleasant nostd embedded hacking in Rust. Tooling generally works well. Might be that the generated code is small enough, and the limits of small devices nudge you to avoid complex language features anyhow? :-) THE END
