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.
I would like more details. There are definitely situations where neither a car nor a human could respond quickly enough to a situation on the road.
for example, I recently hit a deer. The dashcam shows that I had less than 100 feet from when the deer became visible due to terrain to impact while driving at 60 mph. Keeping in mind that stopping a car in 100 feet at 60 mph is impossible. Most vehicles need more than triple that without accounting for human reaction time.
This is called "overdriving your vision", and it's so common that it boggles my mind. (This opinion might have something to do with the deer I hit when I first started driving...)
We will inevitably see "AVs are too cautious! Let me go faster!" complaints as AVs drive in more places. But, really humans just suck at risk assessment. And at driving. Driving like a human is comforting in some contexts, but that should not be a goal when it trades away too much safety.
There is a difference between driving too fast around a corner to stop for something stationary on the road and driving through countryside where something might jump out.
I live in a country with deer but the number of incidences of them interacting with road users is so low that it does not factor in to my risk tolerance.
The risks vary with speed. At 30mph a deer will be injured and damage your car, and you might have to call animal control to find the deer if it was able to get away. At 45mph there is a good chance the deer will impact your windshield. If it breaks through, that's how people die in animal collisions. They get kicked to death by a frantic, panicked, injured animal.
On many roads if a deer jumps across the road at the wrong time there’s literally nothing you can do. You can’t always drive at 30mph on back country roads just because a deer might hop out at you.
World of difference between, 30, 40, 50 and 60. Feels like something I have noticed between west and east coast drivers. Latter really send it on country turns and just trust the road. West coast, particularly montana, when vision is reduced, speed slows down. Just too many animals or road obstacles (eg: rocks, planks of wood) to just trust the road.
Yeah, I was a bit glib. My impression is more specifically of the greater northwest vs rest. Perhaps just "the west" vs "the east".
Indiana drivers for example really do send it (in my experience). Which is not east coast of course.
There is a good bit of nuance... I would perhaps say more simply east of Mississippi vs west, but Texas varies by region and so-Cal drivers vary a lot as well, particularly compared to nor-Cal and central+eastern california. (I don't have an impression for nevada and new mexico drivers - I dont have any experience on country roads in those states)
You are responding in a thread about a person saying they were driving at 60 when the deer only became visible "due to terrain" at 100 feet away, and therefore hitting it is no reflection on their skill or choices as a driver.
I suppose we're meant to interpret charitably here, but it really seems to me like there is a big difference between the scenario described and the one you're talking about, where the deer really does fling itself out in front of you.
I've had a person, high on drugs, walk out from between bushes that were along the road. I screeched to a halt in front of them, but 1 second later and physics would have made it impossible, regardless of reaction time (or non-negligible speed).
The article explains the investigation is based upon visibility issues... what is your point? I don't think any reasonable person doubts there are circumstances where nothing could adequately respond in order to prevent a crash. It seems a rather odd assumption to reach that these crashes would be in one of those scenarios such that we should be explained to otherwise, no less so when the report facially explains this to not be the case.
we took a road trip last summer about 4000 miles in our model Y Long range. You end up supercharging approximately every three hours for about 15 minutes. it actually worked out very well because our first stop of the day was almost always lunch. we picked hotels that had chargers on site so we started each day with enough charge to make the next supercharger.
There's 3 Tesla superchargers between Vegas to Reno, in Beatty, Tonopah and Hawthorne, which is roughly 1/4, 1/2 and 3/4 of the way through. So definitely doable but definitely less convenient than an ICE car that can make that drive in one shot without refueling.
So stop in Tonopah NV,which is half way inbetween. Most EVs have the range to make it that far. I just picked that town by looking at a map - I'm sure there are a couple other choices even tough it is a desolate area.
I don't know if there is a charger there today, but it is an obvious place where one is likely to be added sometime.
Remote: Remote (Preferred), Hybrid
Willing to relocate: No
Technologies: Expert level C# skills, Golang (want to get into it more!), SQL Server, PostgreSQL, Docker/Podman, Cosmos DB, AWS, Azure, Cloudflare, .NET Maui / Blazor, Bootstrap CSS, Vim, Linux, Windows, Entity Framework, Kubernetes, Terraform
Email: greg+hn@gregd.org
Linked In: https://www.linkedin.com/in/k9cts/
Github: https://github.com/farmergreg/
Résumé/CV: https://www.gregd.org/resume/hacker-news/
I LOVE: Creating well designed, maintainable, high performance systems.
Example Code: https://github.com/farmergreg/adif processing Ham Radio log files at more than 2x the speed of other comparable parsers.