Skip to main content

“Dev by a thousand cuts”

That’s often what #rustlang feels like. I started learning C in the late 80s and BASIC before that. Since then I’ve become an expert in several languages and proficient in several others. I’m an experienced #polyglot and though the rust compiler is by far the most helpful - and pushing other compilers to improve - there’s a lot of sharp edges in the grammar itself. Some other polyglots I’m getting into the language agree.

#polyglot #RustLang
in reply to Heath Stewart

Esteban K�ber :rust:
Esteban K�ber :rust:
• •
could you elaborate on the sharp edges you're encountering? We are aware of many, but it's good to double check in case there are any we don't know about yet.
in reply to Esteban K�ber :rust:

Heath Stewart
Heath Stewart
• •

you just beat my self-reply! 🙂 My instance still limits length.

That’s the main one for me. For many others - especially those new to the language or memory management in general - it all about lifetimes of which you’ve no doubt heard plenty.

Many are interested to learn in my division and I’m trying to put together a sort of curriculum so these things have been top of mind. I don’t have good solutions for how to solve them.

in reply to Heath Stewart

Esteban K�ber :rust:
Esteban K�ber :rust:
• •
my general advice is "keep calm and call clone". You can get people used to the rest of the language before getting too bogged down with lifetimes. The biggest source of pain is structs and enums with lifetimes, so I would avoid storing references in fields except in the simplest of cases at first.
in reply to Esteban K�ber :rust:

Heath Stewart
Heath Stewart
• •

I’ve also been warning people about refs on structs and enums. Often times the memory overhead of allocating isn’t worth it if a ref is only used for that reason. We’ve been taking that approach in the new stuff I’ve been driving.

About clone: that underscores my apprehension in more perf-related work - understanding when we’ll be allocating. Of course, with clone I’d always expect it unless using Arc and the like.

in reply to Heath Stewart

Esteban K�ber :rust:
Esteban K�ber :rust:
• •
I'm apprehensive about pushing people just learning the language towards the most performant approaches early on, because thats how you end in the pit of "I don't know if I need a magic incantation or the language just won't accept it at all". I prefer getting people to working prototype first, and then measure performance. Armed with a flame graph you might get rid of a bunch of unnecessary allocations, but many would remain because they are not in the critical path.
in reply to Esteban K�ber :rust:

Esteban K�ber :rust:
Esteban K�ber :rust:
• •
same with people avoiding Box<dyn Trait> because of the v-table jump: almost every time ive heard that as the justification, after measuring there was no real difference in production workloads.
in reply to Esteban K�ber :rust:

Larry Osterman
Larry Osterman
• •

Two related stories. When we were designing the Windows Runtime, one of the significant sources of contention was whether WinRT types should follow the COM model of dispatch through a vtable or the C++ model of direct function calls for most function calls

One of the developers on the team prototyped two implementations of the same class, one of which exclusively used direct method calls, the other which indirected through a vtable.

Much to their surprise, the *worst* case for the vtable dispatch code was that it performed at parity with the direct call, even though there was a memory indirection involved in the method call.

Second story: When I built the POP3 and IMAP servers for Exchange back in the mid 90s, the message retrieval code was implemented by writing the contents of the message to a file on disk, then calling TransmitFile to transfer it to the client.

A new dev manager came in, and after I had explained how it worked, he told me that there was no possible way this could be faster than using non-blocking sockets entirely in user mode to get the best performance.

So at their insistence, I built a non-blocking socket implementation, and tested it.

The "more efficient" version was orders of magnitude slower and consumed significantly more CPU time than the original implementation. That result was largely because (a) the files created were "super temporary files" and (b) the TransmitFile was designed to be as efficient as possible.

The moral of the stories: Never trust your assumptions about performance, because they are almost certainly incorrect.

⇧