On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift).

On the other hand, when weighing one’s feelings against the common good, I guess it’s not really a contest. Plus I suspect a lot of my annoyance with languages like rust stems from not being as familiar with the paradigm. What do you all think?

you are viewing a single comment's thread
view the rest of the comments
[–] 20 points 2 years ago (4 children)

What memory-safe systems programming languages are out there, besides Rust?

  • source
  • hideshow 8 child comments
  • [–] 11 points 2 years ago (2 children)
  • [–] 9 points 2 years ago (1 child)
  • [–] 15 points 2 years ago (2 children)

    I appreciate your answer, but I mentioned systems programming, because I was more interested in languages that do not rely on a garbage collector.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 26 points 2 years ago (1 child)

    To play devil's advocate, most systems programming can be done even with a garbage collector. Midori was a project to build an operating system on a variant of C#, and although the garbage collector did impose technical difficulties, it wasn't a dealbreaker. Go isn't usable everywhere Rust is, but it can in fact be used for many things that previously would have been considered "systems" niches (which is part of why there was a somewhat prevalent misconception in the early days of Rust that they were similar languages). Prominent D developers have defended D's garbage collector (even though it's technically optional). Bjarne Stroustrup, the creator of C++, used to express great confidence that C++ would one day have a garbage collector.

    ...but you're right, Rust and its rise in popularity (and, conversely, the C++ community's resistance to adopt anything with garbage collection) have definitely narrowed the common definition of "systems programming" to exclude anything with a "thick" runtime.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 2 years ago (2 children)

    Wasn't Go designed to be a memory safe systems programming language? I haven't really used it enough to see if it holds true, though.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 years ago

    Go is almost memory safe, but it does suffer from an issue with its thick pointers (type + address) that can cause race conditions to misrepresent the type of a data structure. This can lead to true segmentation faults and out of bound memory accesses, though it will probably be quite difficult (but not impossible) to exploit them.

  • source
  • parent
  • [+] 1 point 2 years ago (2 children)
  • [–] 11 points 2 years ago

    Segfaults aren't particularly dangerous. They mean the problem was caught. The program usually just exits.

    Failing to segfault, thereby allowing a bad memory access, is where the real trouble happens.

  • source
  • parent
  • [–] 0 points 2 years ago (1 child)

    I’m very flaky here, as rust is the big one, but I think zig and/or nim might be

  • source
  • parent
  • hideshow 2 child comments