Totally agree. SWE is the only field where people can call them "Engineers" without having an actual engineering degree.
-13 karma · joined July 8, 2019
I estimated that it took me about 10x the time to implement something than it would have taken if I did that in C. The reason for that could definitely be because I'm not a Rust expert at all. That's fine though because I will happily invest more time in programming if it saves me hours of debugging later. Plus, the claim that "if it compiles, it works" was enough for me to fight the compiler for hours if it gives me no trouble during runtime.
Fast forward a week, we have that binary deployed to a non-critical set of our field devices. A few days later, we get reports of that particular binary crashing. I logged into one of those devices and fetched the logs. The binary was reporting a panic on an MPSC channel's tx send. There was nothing useful in that error message that would point me to the root cause. I had no tools to attach to a running process because I'm on a device with an ancient kernel.
To fix the situtation "temporarily", because the customer is getting infuriated, we redeploy our old C binary. It has been there since. I basically now say "fuck off" to anyone who tells me to use Rust because it doesn't work if it compiles.
$ cat hello.c
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 0;
}
$ cat hello.cpp
#include <iostream>
using namespace std;
int main(void)
{
cout << "hello world" << endl;
return 0;
}
$ gcc -o hello_c hello.c
$ g++ -o hello_cpp hello.cpp
$ ll hello_*
-rwxr-xr-x 1 root root 5880 Dec 5 14:13 hello_c
-rwxr-xr-x 1 root root 7424 Dec 5 14:14 hello_cpp
Sorry, but it does.
Stop this nonsense please. This does not show anything even remotely close to systems programming capability of Go. Write a device driver in Go that performs without lagging, benchmark it and then come back.