41–50 of 54 posts
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?
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
> its very hard to pick one to learn If you don't know it already, you learn C, as well as you can. It is not a hard language to learn, but it has a lot of footguns. That's why you learn it along with tools like Valgrind & sanitizers. Then you look at Rust. That's somewhat harder to learn, but nails some important details you need to think about while writing C. It will make some things obvious that you'd need to lea…
I'm not sure I agree. Anything which attempts to constrain "anytype" makes the language much, much more complicated.
For example, if it were constrained, Zig "allocgate" would likely have necessitated compiler changes instead of just library changes.
And I often think that we conflate two different things--"Generic" and "Libraries like the big boys build".
I generally don't need fully generic programming.
What I do need is the ability to build a library that works exactly like the standard library. All libraries need to be precisely equal in expressive power and composability to those that have been officially "blessed".
Oddly, Rust fails at this due to things like the Orphan Rule even though its "genericity" is quite expansive. The invasiveness of Serde is a prime example. If an external crate doesn't support Serde, you can't add it. You have to literally copy the entire library over to your code in order to add Serde support. This blocks an alternative to Serde from ever arising because it will never be as convenient as Serde which has been "blessed" by the community.
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.
1. It only allows function calls instead of any expression.
2. It allocates memory dynamically and attaches the function call expression to the function, rather than the current scope exit. This has surprising and harmful consequences if you use it inside a loop.
So, I wouldn't say that zig's defer is borrowed from Go.
Unit test it with TXR: $ pwd /home/kaz/ustreamer $ gcc -D_GNU_SOURCE -shared src/libs/base64.c -o base64.o $ valgrind txr --free-all ==8785== Memcheck, a memory error detector ==8785== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8785== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==8785== Command: txr --free-all ==8785== This is the TXR Lisp interactive listener of TXR 292.…
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
> its very hard to pick one to learn If you don't know it already, you learn C, as well as you can. It is not a hard language to learn, but it has a lot of footguns. That's why you learn it along with tools like Valgrind & sanitizers. Then you look at Rust. That's somewhat harder to learn, but nails some important details you need to think about while writing C. It will make some things obvious that you'd need to lea…
Technically speaking, Java and C# would serve somewhat different purposes and I would rather recommend Kotlin and C# with the former serving higher-level code goals better with existential types, SRTPs and overall strong type system and the latter for lower-level and/or performance-sensitive code with SIMD, pointers/byrefs, struct generics (zero-cost abstractions) and free/cheap interop.
The only concern is how well Kotlin Native works today regarding compatibility. NativeAOT has seen a lot of work to improve this and scenarios that will never be supported (runtime reflection emit which needs JIT or arbitrary unbound reflection) are now well-documented.
You may also be interested in Bflat[0] which has 'UEFI' as a target or even Zerosharp[1] as a demonstration how far you can push this (which is, of course, impractical, just use Rust :D)
[0] https://github.com/bflattened/bflat
[1] https://github.com/MichalStrehovsky/zerosharp/tree/master/no...
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?
Curious now if you could use D in the same way? Walter Bright built a faster preprocessor for Facebook (kind of a sidenote and not fully relevant), wouldnt surprise me if D is another good candidate especially given its age.
Yes: https://dlang.org/spec/importc.html The D compiler(s), as Zig, can be used to compile C code... and D code can import C files as if they were D modules (as in Zig, there are some special types to represent C strings and other types that are not exactly the same).
Earlier quoted context omitted.
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.
Go's defer is incredibly flawed: 1. It only allows function calls instead of any expression. 2. It allocates memory dynamically and attaches the function call expression to the function, rather than the current scope exit. This has surprising and harmful consequences if you use it inside a loop. So, I wouldn't say that zig's defer is borrowed from Go.
Edit: ok rewatched it and I didn't see that come up, i was just misremembering
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?