No, I mean, for example uninitialized pointers are a huge red flag, so seeing one not set to NULL is honestly shocking, especially in crypto code where a stray pointer can lead to crashes or subtle security issues.
Remote: yes
Willing to relocate: no
Technologies: c#, go
Link: https://github.com/hamradiolog-net/adif
Email: please look for it in the git commits
I enjoy creating high performance, well designed, highly maintainable software.
Principal software engineer with 20 years of c# / .net experience. I am looking to pivot to golang, but would also entertain c# related positions. My resume is available upon request. The link is to recent software I’ve written that demonstrates my abilities.
As part of that, I made an ADIF (ham radio logs) parser to learn go. It's more than 2x faster than parsing the same data in json format with the go standard library.
i’m learning golang and made this library that parses ham radio ADIF logs. my goal was to match the speed of the golang json parser. i managed to surpass it by about 2x!
i’m currently employed writing c#, but looking for a job elsewhere and golang seemed like a good way to level up :)
golang is a sidegrade at best, in many ways it's very last century when compared to C#
(even if poorly managed and overbloated enterprise codebases may lead you to believe otherwise, they are quite detached from what modern C# is supposed to look like)
I would tend to agree, and yet there is something intellectually challenging about learning something new! I've been on the c# bandwagon since 2004; assembly and C before that. Go brings back some of that low(er) level feeling :)
I could tell you some horror stories about how my current employer does C#. It is very strange.... can't use var, nuget packages for _every_ class library... and it gets stranger from there on out... unfun!
Honestly, this is a good argument and it should not even be made here but rather when discussing dire and completely self-inflicted state of affairs that a lot of products written with C# are in. It's not just that "the product you see no reason to rewrite in .NET 8" causes talent attrition. It's that it causes that said talent to leave .NET altogether, despite the fact that for greenfield products it's much better at 85% tasks being usually thrown at Go. It's an unfortunate predicament.
Before a bunch of people read this and become confused why their jitter didn't go to 0 "nothing you can do with your home network will ever make your jitter less than when you plug just your PC/Laptop directly into the ISP connection, let it get the public address, and only run a ping from it". Also things you do at home, such as use wireless, will often add a ms or two of occasional jitter even when you use a 6 GHz channel with extremely low contention and interference.
Bufferbloat is good thing to fix in general though and highlights why one should worry less about "how do single ICMP packets behave" and more about "how does actual loaded traffic of the protocol type I'm using behave in real usage". The results are often staggeringly different.
