Why I moved from Rust to simpler, cleaner C(fascinatedbox.blogspot.com)
fascinatedbox.blogspot.com
Why I moved from Rust to simpler, cleaner C
http://fascinatedbox.blogspot.com/2017/04/why-im-moving-from-rust-to-c.html
13 comments
Yep.
First commit: https://github.com/FascinatedBox/lily/commit/1e509cbdd56ef36...
Commit list at oldest page: https://github.com/FascinatedBox/lily/commits/master?after=9...
(GH doesn't seem to have an easy way to jump around time and directly find commits. I jumped to the oldest tag, went to the commit list, clicked "older", edited the tag out of the URL then followed "older" to the start. Took around 15 clicks.)
First commit: https://github.com/FascinatedBox/lily/commit/1e509cbdd56ef36...
Commit list at oldest page: https://github.com/FascinatedBox/lily/commits/master?after=9...
(GH doesn't seem to have an easy way to jump around time and directly find commits. I jumped to the oldest tag, went to the commit list, clicked "older", edited the tag out of the URL then followed "older" to the start. Took around 15 clicks.)
Also, an issue created today "Rewrite Lily in Rust" [1]. Not sure if it's just the other half of the joke or not.
[1] https://github.com/FascinatedBox/lily/issues/294
[1] https://github.com/FascinatedBox/lily/issues/294
Yeah, it's a joke. I added an issue (https://github.com/FascinatedBox/lily/issues/294) for extra fun.
I liked the part about the parser not benefitting from memory safety(parsers are a classic source of CVEs).
I checked out the Lily tutorial (https://fascinatedbox.github.io/lily-site/tutorial.html) and the syntax is unusually clean. Really cool!
I mean, this is great, obviously. True spirit of the holiday.
That being said, rustc _is_ slow.
That being said, rustc _is_ slow.
Happily, incremental compilation[1] is set to be included in the next release[2] at the end of April!
[1] https://github.com/rust-lang/rust/issues/2369
[2] https://internals.rust-lang.org/t/rust-release-milestone-pre...
[1] https://github.com/rust-lang/rust/issues/2369
[2] https://internals.rust-lang.org/t/rust-release-milestone-pre...
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...
There are exactly two valid* points in this post:
I'll just go through these really quick:
1. rustc is slow
Rust just shipped (in beta) incremental compilation, a technique commonly used by compilers to speed up recompiles:
https://internals.rust-lang.org/t/incremental-compilation-be...
This doesn't change the fact rustc is slow, but it certainly makes the developer experience much better. Try it out!
That said, rustc is still slow. A valid complaint.
2. rust needs unions
Rust has two types of unions:
3. linked lists are great
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.
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:
http://cglab.ca/~abeinges/blah/too-many-lists/book/
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.
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...
4. "the circlejerk" a.k.a. the community
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.
I personally think Rust has a great community.
5. rust's safety is overrated
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.
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.
There are exactly two valid* points in this post:
- rustc is slow
- "the circlejerk"
I'll just go through these really quick:
1. rustc is slow
Rust just shipped (in beta) incremental compilation, a technique commonly used by compilers to speed up recompiles:
https://internals.rust-lang.org/t/incremental-compilation-be...
This doesn't change the fact rustc is slow, but it certainly makes the developer experience much better. Try it out!
That said, rustc is still slow. A valid complaint.
2. rust needs unions
Rust has two types of unions:
- tagged unions a.k.a. sum types. These are preferred
- #[feature(untagged_unions)]: actual C-style unions, unsafe, useful for C interop
3. linked lists are great
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.
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:
http://cglab.ca/~abeinges/blah/too-many-lists/book/
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.
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...
4. "the circlejerk" a.k.a. the community
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.
I personally think Rust has a great community.
5. rust's safety is overrated
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.
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.
>> "together I have an immutable sum type + list memory model for a sort of Lisp-alike VM"
So are you saying that you're using Rust as if it were a higher level language? Almost as if you had garbage collection? (If so, that's very interesting. I've been wondering about ways to do that when it's appropriate for the task at hand).
So are you saying that you're using Rust as if it were a higher level language? Almost as if you had garbage collection? (If so, that's very interesting. I've been wondering about ways to do that when it's appropriate for the task at hand).
No, I am using Rust to implement an interpreter for a Lisp-like language
> "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"
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 ??
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 ??
[0] https://github.com/FascinatedBox/lily/tree/9ed9a706e0a1f99ff... (Tree at a random commit a while back)