Tyler Compton <xavi...@gmail.com>:
> It would have been nice to see performance measurements from a more recent
> Go version. That said, it makes sense to me that Rust would be a better
> choice for this kind of application, where the main performance bottleneck
> is the sheer number of objects in memory. A language where you get to
> express more about the life-cycle of these objects should perform better. I
> say this as someone that knows very little about Rust, so I'm probably
> greatly oversimplifying.
I had a good hard swing at learning Rust, and I don't think you are
oversimplifying at all. It's a better fit for that deployment, no question,
and nothing in that article surprised me even a little.
On the other hand, for me to have tried to port reposurgeon to Rust
would have been a mind-numbingly stupid idea. And that will be true of
any application above a certain complexity of internal data-structure
management, where having GC moves from bein convenient to an essential tool
for holding dowb your defect rate.
Different jobs, different tools. Engineering is like that.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20200208064449.GA130072%40thyrsus.com.
