4 ms·

>I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Go or Rust? They might not quite match yo

>I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Go or Rust? They might not quite match your dream outlined above, but I think in practice they are pretty much used with the purpose of achieving something similar. They both can be "unsafe" as needed and integrate well with C and ASM.

marktangotango 11y ago
Vala gets no love in these discussions; a C# subset that compiles to C and gobject.
- gue5t 11y ago
  Vala is not a C# subset (though it does significantly resemble C#) and really isn't intended or suitable for writing high-performance code or reusable low-level libraries like C or C++ are; it's a way to write GObject-style C without as much boilerplate as it takes in C. For that niche it's quite nice, and helps avoid refcounting errors which can be very subtle in C, but Vala is still a fairly leaky abstraction over the C to which it compiles.
nickpsecurity 11y ago
Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Rust barely survived some beginner OS projects without its bloat and performance problems showing up. Once comparison I read showed Rust's compiler caught many bugs that slipped through Go's due to Rust design choices. I'm pulling for Rust in particular because its team made clever, design choices for their safety-vs-performance&control tradeoffs. Yet, right now, both are inferior to C, C++, Ada, the old Modulas, and even Fortran for bare metal applications. So, it's not a dream so much as me wanting to see an excellent middleware implemented in a language proven for decades to do what the two you referenced hope to do someday. Using proven methods, even if ugly or unpopular, is just what engineers do when solving new problems. I'd happily use the same thing built in Rust (not Go as it's less safe) if they can get it more compact and fast. Meanwhile, I have to use C++ and C implementations because that's what's available.
- voidlogic 11y ago
  >Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Can you expand on this? I have had no issue getting to C levels of performance by using "unsafe" or ASM a few small critical sections as needed (tight bodies of inner loops, etc or mmap based allocation).
  - nickpsecurity 11y ago
    Going from what people on different projects and forums said when I was Googling it. I could assess its current state better with a few questions. Can it run in kernel mode on bare metal? Can it run without a sizeable runtime? Are its core abstractions for common uses (arrays, strings, etc) at C++ performance at least? Are basic, demo algorithms small enough as object code to fit into a L1 cache? These would be a nice start on assessing it as a true C++ alternative for varieties of systems programming. Come to think of it, I might also look to see if any C++ developers in high-end gaming have tried it. They're so tight on efficiency (and skilled at getting it) that might tell me plenty.

marktangotango 11y ago

Vala gets no love in these discussions; a C# subset that compiles to C and gobject.

gue5t 11y ago
Vala is not a C# subset (though it does significantly resemble C#) and really isn't intended or suitable for writing high-performance code or reusable low-level libraries like C or C++ are; it's a way to write GObject-style C without as much boilerplate as it takes in C. For that niche it's quite nice, and helps avoid refcounting errors which can be very subtle in C, but Vala is still a fairly leaky abstraction over the C to which it compiles.

nickpsecurity 11y ago

Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Rust barely survived some beginner OS projects without its bloat and performance problems showing up. Once comparison I read showed Rust's compiler caught many bugs that slipped through Go's due to Rust design choices. I'm pulling for Rust in particular because its team made clever, design choices for their safety-vs-performance&control tradeoffs. Yet, right now, both are inferior to C, C++, Ada, the old Modulas, and even Fortran for bare metal applications. So, it's not a dream so much as me wanting to see an excellent middleware implemented in a language proven for decades to do what the two you referenced hope to do someday. Using proven methods, even if ugly or unpopular, is just what engineers do when solving new problems. I'd happily use the same thing built in Rust (not Go as it's less safe) if they can get it more compact and fast. Meanwhile, I have to use C++ and C implementations because that's what's available.

voidlogic 11y ago
>Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Can you expand on this? I have had no issue getting to C levels of performance by using "unsafe" or ASM a few small critical sections as needed (tight bodies of inner loops, etc or mmap based allocation).
- nickpsecurity 11y ago
  Going from what people on different projects and forums said when I was Googling it. I could assess its current state better with a few questions. Can it run in kernel mode on bare metal? Can it run without a sizeable runtime? Are its core abstractions for common uses (arrays, strings, etc) at C++ performance at least? Are basic, demo algorithms small enough as object code to fit into a L1 cache? These would be a nice start on assessing it as a true C++ alternative for varieties of systems programming. Come to think of it, I might also look to see if any C++ developers in high-end gaming have tried it. They're so tight on efficiency (and skilled at getting it) that might tell me plenty.