21–30 of 54 posts
This is going to get really good when zlibc is done, you'll be able to for example, override the c stdlib "free" function in the c code and add features, for example (runtime) UAF/DF detection with metadata tracking (like stacktraces of where the memory was created and freed)
You can already do this with LD_PRELOAD, no?
Earlier quoted context omitted.
Is ocaml a system language?
yes it can be used to create systems and backend tools - it is used to create an OS https://github.com/mirage - it is used to create a transpiler https://melange.re/v2.2.0/ - it was used to create Rust first compiler ocaml is surely a systems language
Writing a OS is more "system", and certainly those using the Mirage operating system use OCaml as a system language.
zig , ocaml, odin many system languages are making the headlines lately its very hard to pick one to learn not sure how to deal with this, learn them all, bet on one, what should we do
I think the two main ones are Rust and Zig. This may be controversial (but it seems very obvious to me) that: Rust is created in the same spirit that created and evolved C++: create a complex and featureful language that enables compiling your solution from a high level representation in an expressive/safe/performant way. Zig is created in the same spirit that created and evolved C: create a simple language that allo…
Unlike C++, ISO C is nothing more than culmination of features that more than 1 compiler has implemented (and doesn't interrupt the compilation process of a micro-controller firmware that was released literally 40+ years ago). Anything else, is GNU C. And it is so incredibly complex and obtuse at times that clang still can't compile glibc after years of work.
Zig was not created with the same spirit that created and evolved C. Zig was created with the idea of a simple C, one that does not match reality, and frankly leans more on Go rather than C. Zig, Odin, V, nearly all these better-C languages are more inspired by Go itself, than what C actually is. What they want from C is just the performance; that's why they're so focused on manual memory management one way or another.
Earlier quoted context omitted.
You can already do this with LD_PRELOAD, no?
Could be wrong, but only if libc is expected to be dynamically linked (and anyways you'd still need zlibc)
This is going to get really good when zlibc is done, you'll be able to for example, override the c stdlib "free" function in the c code and add features, for example (runtime) UAF/DF detection with metadata tracking (like stacktraces of where the memory was created and freed)
I've done this where I use python's ctypes library to write tests for a c codebase. This feels very similar in that it can be tricky to get the type interop correct the first time around. What other strategies/solutions do people like to use for testing their c projects?
Earlier quoted context omitted.
I think the two main ones are Rust and Zig. This may be controversial (but it seems very obvious to me) that: Rust is created in the same spirit that created and evolved C++: create a complex and featureful language that enables compiling your solution from a high level representation in an expressive/safe/performant way. Zig is created in the same spirit that created and evolved C: create a simple language that allo…
There's something to be said about philosophy of simplicity in C. However, C pretty clearly evolved into the opposite direction. This is nearly all due to compiler developers, and the fact that C has to cater to so many different hardware requirements. Unlike C++, ISO C is nothing more than culmination of features that more than 1 compiler has implemented (and doesn't interrupt the compilation process of a micro-cont…
If you squint zig's error return fusion looks a bit like go's tuple error return but it actually is more "first-classing certain c conventions" than "adopting a go pattern". Same goes for slices.
Earlier quoted context omitted.
There's something to be said about philosophy of simplicity in C. However, C pretty clearly evolved into the opposite direction. This is nearly all due to compiler developers, and the fact that C has to cater to so many different hardware requirements. Unlike C++, ISO C is nothing more than culmination of features that more than 1 compiler has implemented (and doesn't interrupt the compilation process of a micro-cont…
Zig borrows some ideas from go. Probably defer is the big one, but if you watch "the road to zig 1.0" you will understand that zig is not really a go derivate. Most things in zig are directly addressing issues in c. If you squint zig's error return fusion looks a bit like go's tuple error return but it actually is more "first-classing certain c conventions" than "adopting a go pattern". Same goes for slices.
C never had the philosophy of keeping things simple through the years. If it did, we would not have time traveling UBs to begin with. The lauded simplicity and explicitness comes directly from Go, where the philosophy was crystalized and preserved very early on.
You might say it is semantics, to call improving upon C being a derivative of Go (with manual memory management). You would be partially correct, it is semantics, but one that holds up very well if you look at how languages developed over the decades.
zig , ocaml, odin many system languages are making the headlines lately its very hard to pick one to learn not sure how to deal with this, learn them all, bet on one, what should we do
Is ocaml a system language?
A colloquial definition of systems language seems close to: "exposes low level details and doesn't have garbage collection." By this definition c, c++, zig and rust are system languages, java and ocaml are not. Go is debatable (and people do debate this).
Personally though, I prefer to think of what types of _systems_ I can build with a language. I can design a framework in a high level language which then transpiles to, say, c. I consider this high level language to be a systems language because it facilitates a system (the framework). Others will disagree but it comes down essentially to a semantic question over what counts as a system language. That debate doesn't seem especially fruitful to me.