2 ms·
Fun article and interesting analysis. That said, why limit yourself to Rust specifically? There are plenty of other languages with "fast enough" implementation
by nerdponx 4y ago
Fun article and interesting analysis.
That said, why limit yourself to Rust specifically? There are plenty of other languages with "fast enough" implementations/runtimes, which also promote "higher quality software by default" but also don't require manual memory management.
Maybe the limiting factor is availability of good GUI toolkits? Or do text editors need particularly low level control over memory in order to avoid performance issues?
- fuzzygroup 4y agoI fundamentally believe that: * The language you use defines how you attack the problem. If you use Snobol then you can only think of the world as strings. If you use an APL derived language then you think in terms of arrays. * If the language's core attributes really suit the problem then you get something fundamentally different. We see this with Erlang which achieves safety but (finally) acknowledging that stuff crashes so build support for recovery into the language. As someone who used to commercially sell a text editor derived product, memory management is just plain hard.
- wongarsu 4y agoUnless we are talking about embedded, "availability of GUI toolkits" is not something that speaks in Rust's favor, as evidenced by only one of these editors being graphical. Maybe in 2-3 years when the current toolkits had time to mature.