This appears to be a april fools joke... judging by the Repo Lily was always written in C [0].<p>[0] <a href="https://github.com/FascinatedBox/lily/tree/9ed9a706e0a1f99ff271cde132b73664e9bf3ff8" rel="nofollow">https://github.com/FascinatedBox/lily/tree/9ed9a706e0a1f99ff...</a> (Tree at a random commit a while back)
I checked out the Lily tutorial (<a href="https://fascinatedbox.github.io/lily-site/tutorial.html" rel="nofollow">https://fascinatedbox.github.io/lily-site/tutorial.html</a>) and the syntax is unusually clean. Really cool!
I can't tell if this is an April Fool's joke or not. If it is, congratulations, troll successful. But I'm going to go ahead and reply anyway...<p>There are exactly two valid* points in this post:<p><pre><code> - rustc is slow
- "the circlejerk"
</code></pre>
* i.e. not completely without merit<p>I'll just go through these really quick:<p>1. rustc is slow<p>Rust just shipped (in beta) incremental compilation, a technique commonly used by compilers to speed up recompiles:<p><a href="https://internals.rust-lang.org/t/incremental-compilation-beta/4721" rel="nofollow">https://internals.rust-lang.org/t/incremental-compilation-be...</a><p>This doesn't change the fact rustc is slow, but it certainly makes the developer experience much better. Try it out!<p>That said, rustc is still slow. A valid complaint.<p>2. rust needs unions<p>Rust has two types of unions:<p><pre><code> - tagged unions a.k.a. sum types. These are preferred
- #[feature(untagged_unions)]: actual C-style unions, unsafe, useful for C interop
</code></pre>
You probably want the first kind. Rust does have them!<p>3. linked lists are great<p>Linked lists are great! I use them in one of the main Rust programs I'm working on. The thing about Rust linked lists is how you write one will depend entirely on your memory model.<p>One of the best tutorials on Rust explains the language's memory model in terms of linked lists. It's a great read, a harrowing tale of "fighting rustc" until you achieve victory:<p><a href="http://cglab.ca/~abeinges/blah/too-many-lists/book/" rel="nofollow">http://cglab.ca/~abeinges/blah/too-many-lists/book/</a><p>I'm using immutable arena-allocated linked lists, which is a great pattern. This is in conjunction with tagged unions, and together I have an immutable sum type + list memory model for a sort of Lisp-alike VM.<p>I did have to implement my own linked lists. The code is not terribly complicated. It'd be nice if there were standard one-size-fits-all linked lists in e.g. the "collections" module, but the type system needs a bit more work before it will be generic enough for that to be a good idea. Until then, you'll have to write your own or use a library given your unique constraints. But that's not really different from C...<p>4. "the circlejerk" a.k.a. the community<p>If you dislike the community there's not a lot to say. It's probably a bad idea to use a language whose community you dislike.<p>I personally think Rust has a great community.<p>5. rust's safety is overrated<p>C programmers routinely make memory safety mistakes, even if they're experts, even if they're using static analysis tools. You don't have to use Rust to have a safe memory model... any JVM language or most other managed language runtimes will do.<p>If you're writing a trivial C program it's possible it's safe. But it only takes one mistake for things to go from safe to catastrophic in C.
> "Every time there is a post on Hacker News or Reddit about a vulnerability in C, the strike team comes out to mention a rewrite in Rust"<p>I thought it was only happening with Go posts, but I can see it's happening with C and C++ too, which other programming language do you know is suffering Rust attacks ??