HN user

0xdead

-13 karma
Posts2
Comments46
View on HN
Firefox 73 6 years ago

That's not true. Operating systems don't know if a process is a browser.

If by "write kernel/bare-metal level code" you mean blinking an LED, sure. Writing low level doesn't have to do anything with C or any language for that matter. It requires a deep understanding of the architecture that you're writing code for. Junior JS devs don't have enough experience or the skills to do that.

I have an anecdote to share. I work in embedded space for a living. A web developer (which is quite funny) from another team somehow convinced our director to use Rust for a critical process that involved a lot of concurrent processing. Ok, I said, and began developing that process in Rust.

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.

Being a Noob 6 years ago

The reasoning of the author is totally flawed. If you feel like a noob locally, there is no guarantee that you will not feel like a noob globally too. In other words, it's not always good to feel like a noob.

  $ 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
I see 1544 bytes of bloat. Hope that helps.

Working on real world problems without seeking help from Google/StackOverflow, even if it means reinventing the wheel to make it fit for your particular problem, or even going through pages of documentation/code to find the purpose of a single function. It may sound like a waste of useful time, but it slowly makes you self-sufficient to deal with any kind of issues later on.

Go can be a viable alternative to C as a systems programming language

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.