6 ms·

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probabl

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulnerabilities because you forgot a weird edge case while managing a pointer is really worrying. For simple programs is not that complicated, but for complex multi threaded ones it becomes really hard. And the fact that event the most expert programmers make these mistakes, leaves me not much hope. So perhaps systems programming is not for me? But what exactly is systems programming? Is it developing OS kernels, writing drivers and embedded microcontroller systems? Or is it more. I'm not very interested in writing any of those. But I do want to write programs that are fast and run as fast as C or C++, and I want a language which allows good control of resources and has minimal overhead. Sometimes these programs are multi-threaded and quite complex, so I want memory and type safety and I want tools to crate abstractions to tame complexity a little bit. Is all this out of the systems programming definition?

kretaceous 4y ago
Seems like you need Go then? You mention you want memory management, type safety and proper abstractions, hence the suggestion. Of course, you also mentioned C's syntax as awkward for you, so you might feel the same with Go's syntax.
- xyzzy4747 4y ago
  Go is not a fast language compared to C/C++/Rust. It’s more in line with Java as it’s also garbage collected.
  - kretaceous 4y ago
    That's fair. Go is not as fast and cannot manage resources as well as the languages you mentioned.
  - Tozen 4y ago
    Go, despite using GC, is still a compiled language. From what I've seen (including various test results), Go is usually faster than Java. There is also the issue of, what is fast enough? A lot of times, people don't really have the speed requirements they say or think they do. To include the code they have written, could be better optimized. It's often better to be more specific about what the requirements are, before making blanket statements about a language not being fast enough. Clearly, many people are fine with how fast Go is.
  - BaculumMeumEst 4y ago
    You state that as a blank and white fact, but there's nuance. https://github.com/lotabout/skim/issues/317#issuecomment-652492431 https://github.com/lotabout/skim/issues/317#issuecomment-652...
xyzzy4747 4y ago
I think Rust is what you need. It basically won’t compile if your code would have runtime errors or memory leaks, except for cases you need to explicitly handle. The linters in VSCode also make it pretty practical to use. It’s been a joy to program in since I started about a month ago.
- proto_lambda 4y ago
  > It basically won’t compile if your code would have runtime errors or memory leaks While Rust does move a lot of errors from runtime to compile time, there are still a lot of ways to create runtime errors (which must obviously the case if your program handles any input at all). Rust also does not stop you from creating memory leaks; there's even the `Box::leak()` method[1] that allows you to simply leak a heap allocation. [1]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
  - xyzzy4747 4y ago
    The difference is you need to explicitly handle cases that would cause runtime errors where you have to use .unwrap() or match selectors, which makes it safer in general. Since the values are wrapped in Result or Option enums. Code that doesn’t create these types isn’t possible to have runtime errors which reduces cognitive burden when coding. And yes you can write non-idiomatic Rust that lets you leak memory but it doesn’t happen by accident like in C/C++.
    - zozbot234 4y ago
      > Code that doesn’t create these types isn’t possible to have runtime errors Rust code can still panic and unwind at runtime. There's some ongoing work on supporting guaranteed-not-to-panic code for very specific uses (similar for guaranteed-not-to-leak, which is a related problem), but it's a long way off and will not be applicable to anything that must interact with the system in any way.
- LandR 4y ago
  And the compoper error messages are fantastic for beginners.
sirwhinesalot 4y ago
Rust sounds like what you want, though be prepared to deal with near C++ levels of complexity at times (lots of Rust code is too macro happy for my tastes). That said, the way to deal with memory management in C is to... not do much of it. I know that sounds like a cop-out but the patterns you're supposed to use in languages like Zig and Odin are the same ones you'd use in C to keep your mind sane. Do not do Reference Counting or Single Owner + Borrowing (RAII), it'll drive you insane without the automation languages like Swift and Rust or C++ give you. Instead, the way you're supposed to do things, are big "manager objects". Only these manager objects are ever explicitly allocated and freed, everything stored within them is managed by them and they expose only safe handles to the outside world (e.g. generational handles). Most of the time these manager objects will store some dynamic arrays, hash maps or pools within them that get freed when they are also freed. Note that unlike RAII there is no real "nesting". The managers are responsible for the lifetimes of their whole "object tree". Any temporary data should be allocated using a temporary allocator (like an Arena allocator) which gets freed at the appropriate place for the application (end of a frame in a game, or end of a request in a web server). Never store pointers to something within the temporary allocator in "long lived" data structures inside the manager object. Follow these rules and things get manageable, Zig and Odin have lots of facilities in their standard libraries to make this easier, in C you're mostly on your own but there are some libraries you could use like the Apache Portable Runtime.
- dqpb 4y ago
  I’ll admit, the fact that Hello World requires a macro, dissuaded me from learning Rust for years.
  - Cyberdog 4y ago
    You’re using the past tense. Did your mind change?
  - WaffleIronMaker 4y ago
    Technically, you don't need a macro at all: use std::io::Write; fn main() { std::io::stdout().write(b"Hello, world!\n").unwrap(); } The reason people often use println! is that println! is variadic and can support any number of arguments to format in the string. For example: println!("x is: {}", x); This also has the benefit of allowing type checking at compile time, as opposed to using a function like printf in C, which does not have such power. Additionally, this allows Rust to take references to the variables entered without the programmer's specification, in order to prevent unnecessary copying. These reasons tie directly into Rust's philosophy of making it easy to write reliable, performant code.
hsn915 4y ago
The wikipedia definition of systems programming seems to exclude it https://en.wikipedia.org/wiki/Systems_programming https://en.wikipedia.org/wiki/Systems_programming
- IshKebab 4y ago
  I'm not sure what you mean by "it" but nothing in that page precludes languages with runtimes from writing system software. I'd say Go can definitely claim to be a systems language.
sanderjd 4y ago
Yeah this kind of framing always rubs me the wrong way. I don't "dread" manual memory management. Indeed, from a personal standpoint I really like thinking about stuff like that while I'm programming. It's part of the fun puzzle aspect that got me into all this. But as a professional, I know that there is heaps of evidence over many decades that it is unwise for me to indulge this fancy, when working on real systems that real people use and which may be exposed to the internet. I consider it a bummer, but I'm very persuaded that this is unwise for pretty much all of the software I work on.
- abainbridge 4y ago
  You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap objects smaller than a page (eg 4KB), and unmapping larger ones so that future accesses are a seg fault. The heap also needs to not create new objects at the same address as deleted ones, but we have 64-bit address spaces, so maybe that's fine. These all have costs, but so do all solutions to these problems. I can't think of any reasons that a language with manual memory management has to be less safe than one with a Garbage Collector / ARC.
  - sanderjd 4y ago
    By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something like Rust, which is safe without garbage collection or ARC, but I also wouldn't call it "manual memory management". The trade off they took for this is complexity in the language.
    - 4y ago

kretaceous 4y ago

Seems like you need Go then? You mention you want memory management, type safety and proper abstractions, hence the suggestion. Of course, you also mentioned C's syntax as awkward for you, so you might feel the same with Go's syntax.

xyzzy4747 4y ago
Go is not a fast language compared to C/C++/Rust. It’s more in line with Java as it’s also garbage collected.
- kretaceous 4y ago
  That's fair. Go is not as fast and cannot manage resources as well as the languages you mentioned.
- Tozen 4y ago
  Go, despite using GC, is still a compiled language. From what I've seen (including various test results), Go is usually faster than Java. There is also the issue of, what is fast enough? A lot of times, people don't really have the speed requirements they say or think they do. To include the code they have written, could be better optimized. It's often better to be more specific about what the requirements are, before making blanket statements about a language not being fast enough. Clearly, many people are fine with how fast Go is.
- BaculumMeumEst 4y ago
  You state that as a blank and white fact, but there's nuance. https://github.com/lotabout/skim/issues/317#issuecomment-652492431 https://github.com/lotabout/skim/issues/317#issuecomment-652...

xyzzy4747 4y ago

I think Rust is what you need. It basically won’t compile if your code would have runtime errors or memory leaks, except for cases you need to explicitly handle. The linters in VSCode also make it pretty practical to use. It’s been a joy to program in since I started about a month ago.

proto_lambda 4y ago
> It basically won’t compile if your code would have runtime errors or memory leaks While Rust does move a lot of errors from runtime to compile time, there are still a lot of ways to create runtime errors (which must obviously the case if your program handles any input at all). Rust also does not stop you from creating memory leaks; there's even the `Box::leak()` method[1] that allows you to simply leak a heap allocation. [1]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
- xyzzy4747 4y ago
  The difference is you need to explicitly handle cases that would cause runtime errors where you have to use .unwrap() or match selectors, which makes it safer in general. Since the values are wrapped in Result or Option enums. Code that doesn’t create these types isn’t possible to have runtime errors which reduces cognitive burden when coding. And yes you can write non-idiomatic Rust that lets you leak memory but it doesn’t happen by accident like in C/C++.
  - zozbot234 4y ago
    > Code that doesn’t create these types isn’t possible to have runtime errors Rust code can still panic and unwind at runtime. There's some ongoing work on supporting guaranteed-not-to-panic code for very specific uses (similar for guaranteed-not-to-leak, which is a related problem), but it's a long way off and will not be applicable to anything that must interact with the system in any way.
LandR 4y ago
And the compoper error messages are fantastic for beginners.

sirwhinesalot 4y ago

Rust sounds like what you want, though be prepared to deal with near C++ levels of complexity at times (lots of Rust code is too macro happy for my tastes). That said, the way to deal with memory management in C is to... not do much of it. I know that sounds like a cop-out but the patterns you're supposed to use in languages like Zig and Odin are the same ones you'd use in C to keep your mind sane. Do not do Reference Counting or Single Owner + Borrowing (RAII), it'll drive you insane without the automation languages like Swift and Rust or C++ give you. Instead, the way you're supposed to do things, are big "manager objects". Only these manager objects are ever explicitly allocated and freed, everything stored within them is managed by them and they expose only safe handles to the outside world (e.g. generational handles). Most of the time these manager objects will store some dynamic arrays, hash maps or pools within them that get freed when they are also freed. Note that unlike RAII there is no real "nesting". The managers are responsible for the lifetimes of their whole "object tree". Any temporary data should be allocated using a temporary allocator (like an Arena allocator) which gets freed at the appropriate place for the application (end of a frame in a game, or end of a request in a web server). Never store pointers to something within the temporary allocator in "long lived" data structures inside the manager object. Follow these rules and things get manageable, Zig and Odin have lots of facilities in their standard libraries to make this easier, in C you're mostly on your own but there are some libraries you could use like the Apache Portable Runtime.

dqpb 4y ago
I’ll admit, the fact that Hello World requires a macro, dissuaded me from learning Rust for years.
- Cyberdog 4y ago
  You’re using the past tense. Did your mind change?
- WaffleIronMaker 4y ago
  Technically, you don't need a macro at all: use std::io::Write; fn main() { std::io::stdout().write(b"Hello, world!\n").unwrap(); } The reason people often use println! is that println! is variadic and can support any number of arguments to format in the string. For example: println!("x is: {}", x); This also has the benefit of allowing type checking at compile time, as opposed to using a function like printf in C, which does not have such power. Additionally, this allows Rust to take references to the variables entered without the programmer's specification, in order to prevent unnecessary copying. These reasons tie directly into Rust's philosophy of making it easy to write reliable, performant code.

hsn915 4y ago

The wikipedia definition of systems programming seems to exclude it https://en.wikipedia.org/wiki/Systems_programming https://en.wikipedia.org/wiki/Systems_programming

IshKebab 4y ago
I'm not sure what you mean by "it" but nothing in that page precludes languages with runtimes from writing system software. I'd say Go can definitely claim to be a systems language.

sanderjd 4y ago

Yeah this kind of framing always rubs me the wrong way. I don't "dread" manual memory management. Indeed, from a personal standpoint I really like thinking about stuff like that while I'm programming. It's part of the fun puzzle aspect that got me into all this. But as a professional, I know that there is heaps of evidence over many decades that it is unwise for me to indulge this fancy, when working on real systems that real people use and which may be exposed to the internet. I consider it a bummer, but I'm very persuaded that this is unwise for pretty much all of the software I work on.

abainbridge 4y ago
You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap objects smaller than a page (eg 4KB), and unmapping larger ones so that future accesses are a seg fault. The heap also needs to not create new objects at the same address as deleted ones, but we have 64-bit address spaces, so maybe that's fine. These all have costs, but so do all solutions to these problems. I can't think of any reasons that a language with manual memory management has to be less safe than one with a Garbage Collector / ARC.
- sanderjd 4y ago
  By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something like Rust, which is safe without garbage collection or ARC, but I also wouldn't call it "manual memory management". The trade off they took for this is complexity in the language.
  - 4y ago