While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers. [1] https://research.google/pubs/secure-by-design-googles-perspe... [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we…
Unlike C/C++, Zig is not inherently memory-unsafe.
Where Rust insists on having either partial safety through the checker or lack of control in unsafe code, Zig provides a toolkit for contructing safe frameworks. Zig also doesn't have main sources of unsafety coming from certain C design mistakes.
Besides, if you are after true memory safety then garbage collection is the way to go.
> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros ar…
This review should be much higher as TFA provides little substance
> Zig for ( 0..9 ) |i| { } > C for (i = 0; i I know an open interval [0..9) makes sense in many cases, but it's counterintuitive and I often forget whether it includes the last value or not. It's the same for python's range(0, 9).
Why are people so obsessed with Zig when Odin has been stable, though not yet with official spec, for such a long time and used in real production for years? Is it just syntax preference or does Zig provide something amazing that I am missing? Not that I use any of them, I am not interested in manual memory management and i stick to Go. But I'm curious.
Zig has a lot of manpower behind it in comparison to Odin and this is one of the most important things for people, they see a proverbial crowd and that builds a lot more interest. With that said, here are a couple of things you have in Zig that you don't get in Odin: - Cross-compilation & cross-linking (more or less works): Odin doesn't do cross-linking. - Comptime; you can actually use it to effectively get Functors…
Thanks for the info. I'm curious to see what people will do when Jai will finally be released next year. So far, Rust has been gaining a lot of traction, although wit ha lot of controversies attached to it. Zig seems to be doing well but the lack of progress towards v1.0 after all those years is quite concerning, making it looks more and more like a toy project rather than something serious. Odin seems to be flying under the radar of most people a bit too much. Jai will have John's name behind it and I am hearing a lot of praise from insiders(people in the beta program). As I said, I have no use for such languages but if i'll do in the future, I'd like to have a clear choice rather than myriad of languages in various stages of development, all trying to do the same thing.
Sometimes if a joke doesn't land, it's because the joke wasn't funny. (Also, yes, a lot of folks here are autistic, maybe cool it with the veiled insults.)
Sure sometimes... other times you get deadpan replies unironically demanding citations and proof of claims. There's nothing veiled or an insult: what I mentioned is a real factor in why people would read that statement and jump to demanding proof. - If I told a room full of plumbers that Sharkbites are actually sponsored by big Water trying to encourage water wastage, it definitely might not land... but none of them…
The feature I want is multimethods -- function overloading based on the runtime (not compile time) type of all the arguments. Programming with it is magical, and its a huge drag to go back to languages without it. Just so much better than common OOP that depends only on the type of one special argument (self, this etc). Common Lisp has had it forever, and Dylan transferred that to a language with more conventional sy…
>The feature I want is multimethods -- function overloading based on the runtime (not compile time) type of all the arguments.
>Programming with it is magical, and its a huge drag to go back to languages without it. Just so much better than common OOP that depends only on the type of one special argument (self, this etc).
Can you give one or two examples? And why is programming with it magical?
I like the idea of the `defer `keyword - you can have automatic cleanup at the end of the scope but you have to make it obvious you are doing so, no hidden execution of anything (unlike c++ destructors).
I would like a language to support both defer and C++ style destructors / Rust Drop. There are good use-cases for having both. For things like a mutex or straight-forward resource cleanup - having a bunch of brain-dead defer statements adds little value and only bloats unnecessary line count. Let the resource type handle its own release/cleanup at scope close. Code is made sweet, succinct and safe.
I like the idea of the `defer `keyword - you can have automatic cleanup at the end of the scope but you have to make it obvious you are doing so, no hidden execution of anything (unlike c++ destructors).
This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.
Tanenbaum was right, the future of the Linux kernel is dire, and it's been a huge setback to operating systems research in practical terms. Fortunately, vendors are gradually moving away from Linux, having been hamstrung by its failures. Google is planning to move to a capability-based microkernel in the coming years for Android and ChromeOS, and Huawei has already done so with HarmonyOS. In a hundred years, Linux wi…
Irregardless of whether this is true, it has not prevented adoption of Linux.