Exact line count doesn’t really matter here. Both solutions work roughly the same in principle, this Rust one uses about 30 lines to configure clap. Arguably both could use better error handling, but that is not the point here.
My point is that this post is imho pointless - it took me max 10 minutes to write equivalent Go version. It also doesn’t really tell us anything which is not written in the tokio docs. I’m pretty sure you can just as easily write equivalent code in most modern languages.
Simple / easy is relative. See also https://xkcd.com/1053/. Having experience makes things look easy. But if you for instance know http a little but have no idea how the underlying bits and pieces work this can be very enlightening.
Contrary to what you are trying to suggest I didn’t make fun of the author in anything I wrote. But I do try to show that this is low-value content that shouldn’t have been posted to this site - right now this is barely anything more than a hello world.
I mean, if you want to read this kind of beginners posts regularly be my guest - I’m pretty sure there are many other sites where beginners show their discoveries. I just think that lobsters is not a place for this kind of content.
To be fair, 30 of the rust lines are an absurdly verbose parser for 2 CLI arguments, unrelated to the TCP proxy. But you don’t have to hate rust to like golang – it’s not zero-sum.
I personally find simple TCP proxies great for failure testing. E.g. when you want to know how your application behaves when the connection interrupts suddenly, blackhole situations, timeouts, malformed data, etc. It’s often quite hard to test the failure scenarios in any other way. I’ve never found a ready-to-use solution that works perfectly for all possible cases. Usually, it’s much simpler to write your own very quickly in your favourite language and make it do what you want to do.
I recently started building a git-pull-through cache layer https://github.com/sluongng/git-cache. I researched how to do it in Rust and the code turned out to be a lot more complicated than i was comfortable with. Turns out golang just have support for it in Std lib, even lib for testing.
This is more like 60 lines, not 30. This is 30 a tcp proxy in 30 lines (in Go): https://gist.github.com/tumdum/afc52f43c257e655f0071701740b8f60 ;)
Exact line count doesn’t really matter here. Both solutions work roughly the same in principle, this Rust one uses about 30 lines to configure clap. Arguably both could use better error handling, but that is not the point here.
So what does matter here?
The relative simplicity of it and the ease of extending this for local / debugging purposes.
My point is that this post is imho pointless - it took me max 10 minutes to write equivalent Go version. It also doesn’t really tell us anything which is not written in the tokio docs. I’m pretty sure you can just as easily write equivalent code in most modern languages.
Simple / easy is relative. See also https://xkcd.com/1053/. Having experience makes things look easy. But if you for instance know http a little but have no idea how the underlying bits and pieces work this can be very enlightening.
Contrary to what you are trying to suggest I didn’t make fun of the author in anything I wrote. But I do try to show that this is low-value content that shouldn’t have been posted to this site - right now this is barely anything more than a hello world.
I mean, if you want to read this kind of beginners posts regularly be my guest - I’m pretty sure there are many other sites where beginners show their discoveries. I just think that lobsters is not a place for this kind of content.
To be fair, 30 of the rust lines are an absurdly verbose parser for 2 CLI arguments, unrelated to the TCP proxy. But you don’t have to hate rust to like golang – it’s not zero-sum.
Who is hating rust? I like it almost as much as I like Go. In fact I consider myself lucky since I work in a pure rust codebase :)
I personally find simple TCP proxies great for failure testing. E.g. when you want to know how your application behaves when the connection interrupts suddenly, blackhole situations, timeouts, malformed data, etc. It’s often quite hard to test the failure scenarios in any other way. I’ve never found a ready-to-use solution that works perfectly for all possible cases. Usually, it’s much simpler to write your own very quickly in your favourite language and make it do what you want to do.
If its http, golang can do it prob in less than 10 lines with https://golang.org/pkg/net/http/httputil/#NewSingleHostReverseProxy
I recently started building a git-pull-through cache layer https://github.com/sluongng/git-cache. I researched how to do it in Rust and the code turned out to be a lot more complicated than i was comfortable with. Turns out golang just have support for it in Std lib, even lib for testing.