Hacker Newsnew | past | comments | ask | show | jobs | submit | mickallen's commentslogin

I personally have no issue with it. Because Rust's type inference is so good, you don't generally even have to specify generic type parameters for method calls. It is more verbose and perhaps you could say less elegant, but I think it better expresses the concept.


This looks really cool! What's the tech stack?


> About half my money is intended to help problems on Earth & half to help establish a self-sustaining city on Mars to ensure continuation of life (of all species) in case Earth gets hit by a meteor like the dinosaurs or WW3 happens & we destroy ourselves


Classic musk :)


Are there any performance benefits over MRI?


I don't think it runs Optcarrot (the current most prominent Ruby benchmark) otherwise it'd be listed here https://github.com/mame/optcarrot. It doesn't have a lot of compatibility with standard Ruby yet according to https://eregon.me/blog/2020/06/27/ruby-spec-compatibility-re... which could be why it doesn't run it. But it's a really exciting project!


The talk at rubyconf mentioned that `string.scan` was 100% faster due to specialized string implementations in the Rust backend. I wonder if there are any performance gains from the actual runtime rather than from std optimizations?


100% faster? Does that mean twice as fast or is string.scan now take 0 time?


100% faster means speed is increased by 100%, i.e. double the speed or half the time.

MRI took 89ms/iter to scan for a regex pattern over 6.8MB of text, while Artichoke took 48ms/iter [0]

0: https://youtu.be/QMni48MBqFw?t=1378


That is misleading, in my opinion. "100% faster" implies that runtime for a given workload is reduced by 100%, taking zero time. I think what you mean to say is either that it's 50% faster or that throughput is increased by 100%.


Surely faster means higher speed, and speed is something per time unit, e.g. miles per hour, or number of scans per second.

At least for me 100% faster does not mean the same as 100% less time was needed.


Not sure how far off this is, practically speaking, but "true parallelism with no GIL" would be a pretty damn significant perf achievement.


You make a good point.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: