
Comparing C and Rust Network Protocol Exercises - signa11
https://ayende.com/blog/185859-A/comparing-c-and-rust-network-protocol-exercises
======
hyperman1
It's hard to say anything without comparing the source code. I don't see a
github reference, so I don't know if it is available.

I know his pain of rust's type inference gone insane. When things get too
strange, I got in the habit of partially constraining the inferred type - you
don't have to specify the full type BTW, only the part you want to constrain.
Also, I'm playing with intellij which shows the inferred type in the code
while you type, very nice.

OTOH, his workflow seems to demonstrate why C doesn't cut it: He spends an
important amount of time to debug trough it. He is carefull and still valgrind
finds errors. Trying to handle all errors in rust is too much of a burden,
which probably means a lot of C errors go unhandled.

These things indicate incomplete understanding of what the C code is actually
doing (instead of what it is supposed to do). Now I get the impression he is a
more than capable enough developer. And still a simple but not trivial task of
< 1kloc contains these kinds of errors. Do you want to trust the stability and
security of your networking to this C code?

Don't get me wrong. I'm not hacking on the guy. He could be me, as I have
comparable experiences in C and in rust as he describes. But the truth is, I
wrote tons of bugs in C and found even more in other people's C code.

Rust takes more thinking things through. It feels slower writing the code.
You'll spend a lot of time waiting on the compiler while it does it utter best
to hate you and shred your work to pieces. You can't quick and dirty hack
trough a job like you do in C. But in the end, the rust result is a lot more
trustworthy, and that aspect alone gains you a lot of time lost on
troubleshooting all kinds of weird crashes.

~~~
ncmncm
It would help if tutorials would advise you not to lean more heavily than you
must on type inference. They have a second goal of selling you on the
language, and inference is an attractive feature, in simple programs.

You often can't avoid relying on type inference in clever libraries, where the
author can't necessarily spell the annotation. It is on the library author to
keep that from leaking out to users.

Bugs in Rust and modern C++ are fewer and bigger, because they more often
result from misunderstanding the problem or library preconditions than
expressing the solution. There are plenty of such bugs, but you have those in
C, too, on top of the others.

~~~
hyperman1
I still live in Java6 land. I love inference, despite their occasional dark
side.

    
    
      Map<String,List<Someclass>> x=new HashMap<String,List<Someclass>>();
    

The problem of modern C++ is all of old C++ comes along for the ride. Even if
you write only modern code, and manage to withstand the 'this once only' siren
song there are all your (ex-)colleagues writing in their own style.

One of the major plusses of rust is that it gives you basic guarantees. C++
can't do that.

~~~
joshdev
Type inference is super handy in a lot of places. The problem I've run into in
the rust book and other intro docs is they almost always use type inference,
which makes it harder to learn what is going on. I'd prefer they used explicit
types to start and then ease into type inference.

------
hsaliak
To the point of having something similar to defer in C. Gnu C has attribute
cleanup[1][2] which is supported by both GCC and Clang.

Sure its not portable in the strictest sense but these two compilers offer
wide enough support that may be sufficient for your use case. systemd uses it,
for example.

glib is also a good general purpose library, you do not need to use GObject or
it's event loop to make use of it.

[1] [http://gcc.gnu.org/onlinedocs/gcc/Common-Variable-
Attributes...](http://gcc.gnu.org/onlinedocs/gcc/Common-Variable-
Attributes.html)

[2][http://echorand.me/site/notes/articles/c_cleanup/cleanup_att...](http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html)

~~~
jorangreef
Zig (a modern, safer C) has defer:

[https://ziglang.org/documentation/master/#defer](https://ziglang.org/documentation/master/#defer)

------
ncmncm
The comments on the article page (not here) show that the commenters are not
reading the article carefully.

This is a scrupulously written article with deeply meaningful conclusions.
Rust is an immature language -- a stage every language goes through! -- and
you can tell. What no one knows, yet, is whether its designers have painted
themselves into a corner that prevents fixing it. The compiler, too, is
immature, and will certainly get better at localizing the causes of problems,
but that is a research project.

C++ is legitimately criticized for complexity that comes from its complicated
history. It inherited all of C's warts, and more from early experiments that
didn't pan out. You can mostly avoid most of them, but promiscuous integer
conversion and overflow always lurk, and you never know when you will
encounter old-school code that revives the old monsters.

Rust claims benefits from not inheriting legacy hacks (except C linking
conventions, which affect function call details), but is rapidly growing its
own legacy of past design choices that constrain future choices. The only
limits on this problem are foresight and mathematical rigor of design
formalisms, and both are limited.

It might be that Rust programmers will need to learn to rely less on type
inference, and state types "unnecessarily", just to get understandable error
messages. Improvements in the compiler might include its identifying choke
points where such a type annotation would help.

Modern C++ coding gives much the same experience of spending extra time
satisfying the compiler, then the program mostly works when you do; but the
error messages don't take hours to figure out. Usually, the most obscure
complaints come out as mismatches between long function-and-template argument
lists, where you have to pick out the one word that doesn't match, but these
take minutes, not hours, and could be automated without a research project.
Much of that will disappear (not all!), with Concepts in C++20.

The difference between the C and C++/Rust experiences is very much like the
difference with interpreted languages -- you depend a great deal more on
exhaustive testing when the compiler does less.

------
jorangreef
I think the author would appreciate Zig
([https://ziglang.org](https://ziglang.org)).

Zig strikes the perfect balance between C and Rust.

The documentation is the best place to start.

It's worth supporting Zig on Patreon:
[https://www.patreon.com/andrewrk](https://www.patreon.com/andrewrk)

