Thanks for sharing this experience - implementing a VM with GC is a core example of where a systems programming should shine.
The result shows that a direct solution (in less time than the C solution might have taken?) was not achieved, which can be attributed to inexperience. Then he got the safe version running, but with a big performance penalty. In a third stage, the code got more and more "unsafe" and performance rose close to the C implementation - without ever reaching it.
Some results from this - very well described - experiment is:
- Rust is a good language, but in development: the Rust developers still have a lot of work to do.
- IMHO, the safe version here is at the sweet spot; stop optimizing there with all the unsafe tricks (playing with the hash map is still fair game) and leave the rest to the compiler writers. Once they have put the amount of effort in that has gone into compiling Java, the graphs will look different. Safety is priceless, and who knows what buffer weaknesses clox has that can be exploited.
The post's writing is very clear, and I'm particularly grateful for the explanation of the problem the borrow checker has with GC in the main loop, and I can see how a lot of re-factoring solves one type issue in one corner only for it to crop up in another - thanks!
I know nothing about rust but if you are struggling against the borrow checker because you want to implement something like linked lists or anything it doesn't want you the obvious solution is to allocate all your memory upfront and create your own allocator where you pass around indexes and thus bypass the borrow checker completely. I think this is what the author does? not really clear as he seemed to be constantly struggling with the language even after that.
I gotta say its not selling me on rust if bypassing the borrow checker with my own allocations still results in having to jump through so many hoops and struggle against the language.
6 comments
[ 2.3 ms ] story [ 20.4 ms ] threadhttps://news.ycombinator.com/item?id=35308246 - 52 comments
https://news.ycombinator.com/item?id=28026562 - 2 comments
My experience crafting an interpreter with Rust (2021) - https://news.ycombinator.com/item?id=35308246 - March 2023 (52 comments)
My experience crafting an interpreter with Rust - https://news.ycombinator.com/item?id=28026562 - Aug 2021 (2 comments)
My experience crafting an interpreter with Rust - https://news.ycombinator.com/item?id=27926705 - July 2021 (1 comment)
The result shows that a direct solution (in less time than the C solution might have taken?) was not achieved, which can be attributed to inexperience. Then he got the safe version running, but with a big performance penalty. In a third stage, the code got more and more "unsafe" and performance rose close to the C implementation - without ever reaching it.
Some results from this - very well described - experiment is:
- Rust is a good language, but in development: the Rust developers still have a lot of work to do.
- IMHO, the safe version here is at the sweet spot; stop optimizing there with all the unsafe tricks (playing with the hash map is still fair game) and leave the rest to the compiler writers. Once they have put the amount of effort in that has gone into compiling Java, the graphs will look different. Safety is priceless, and who knows what buffer weaknesses clox has that can be exploited.
The post's writing is very clear, and I'm particularly grateful for the explanation of the problem the borrow checker has with GC in the main loop, and I can see how a lot of re-factoring solves one type issue in one corner only for it to crop up in another - thanks!
I gotta say its not selling me on rust if bypassing the borrow checker with my own allocations still results in having to jump through so many hoops and struggle against the language.