3 ms·
I feel like in the end most of it just comes down to how memory is managed and the type system, at least if you consider C++ instead of C. Personally I just wi
by Tobba_ 9y ago
I feel like in the end most of it just comes down to how memory is managed and the type system, at least if you consider C++ instead of C.
Personally I just wish for something like C# without the garbage collector (and some good options for static compilation). Right now it just seems like the only two choices are C(++)/Rust, where your only option is to deal with everything manually even if the compiler or optimizer would know better, and most dynamic GCd languages, where your only option is summoning Cthulhu to do it for you.
- fileeditview 9y agoI have slight hopes for Zig. Maybe there will finally be a real C replacement. I never understood why C has not been brought into modern context. Go is probably nearest but it has GC and C interop seems cumbersome.
- Tobba_ 9y agoLooks like a mash-up between C and Rust, though with somewhat funky syntax. Still, C(++) with no preprocessor and non-nullable pointers is a huge improvement on it's own, but is that full-blown CTFE with first-class types I see? Hot damn. I could definitely see myself using that if it evolves further.
- flavio81 9y ago>, and most dynamic GCd languages In Common Lisp there are tricks to avoid doing dynamical allocations within your critical (read "requires high performance") code, so the GC doesn't bother you. Couple this with type declarations, "inline" declarations (which tell the Lisp compiler to inline certain functions) and, if you know what you're doing, the Lisp code will compile to pretty good (read: fast, optimized) machine language that will run seriously fast (at the same speed or close to the same speed than C or Fortran.) So you can choose to avoid needing the GC on your high performance code, and enjoy the comfort of garbage-collected dynamic memory management on the code that is not so performance-critical.