I always felt that Python's "There should be one-- and preferably only one --obvious way to do it." was a bit of a mess.
Obviously (to anyone who was around at the time), that plank was written in response to Perl's motto: "There is more than one way to do it."
Zig's original take on this, "Only one obvious way to do things" seems even worse. You see, both languages agree that Perl had it wrong: it is unhelpful to have several different ways to write any future. But they went a little too far: it is not actually bad for it to be possible to write the same thing in more than one way.
Zig's new phrasing: "There is an idiomatic way to do it." captures the CORRECT alternative to Perl's motto. It is not important that there be no alternative ways of writing something, Rather, it is important that there be a single idiomatic way to write it.
This is a losing proposition.
Because just like in Python, it may also generate endless debates on "ok, but what exactly is the idiomatic way for this particular thing here"? Is it A, or B, or maybe C? Since many are always possible, each optimizing for slightly different things, like simplicity, or maintainability, or performance, or readability, or coverage, etc. Groups may form furiously asserting that the idiomatic way must be C, others defending B, or A, and for what. Why does it matter? A young language free from cruft, after a long history of various decisions that led it on certain paths, can boldly claim such nonsense, but makes one wonder how it may look in 30 or 40 years, when other languages/ecosystems will point at its mistakes.
Arguably Perl had it right all along, it's just a simple fact of life, expressed in such a generic manner that there is no need to fight it, since it's obviously true. Python's retort at the time was just clever marketing (aka lies), that worked (fooled a lot of people), it targeted Perl specifically just because that was the main competition back then.
I think people criticize that line in the zen of Python because Python has now become very maximalist. On it's own merits, I think "There should be one obvious way to do it" is much better, less clunky, than "There is an idiomatic way to do it".
Also, importantly, the Zen of Python is kinda written as a set of ideas that Python should aspire to ("there should be one obvious way to do it") instead of a sales pitch of Python's merits. I prefer that.
Yeah, I actually don't care how other people program in the languages I'm using. Give me all the ways to do things. I'll make my own choices, thank you.
Someone cooked up a language just like this ages ago, and today it's one of the most popular languages on the planet! Unfortunately, in modern times people don't like to write/code in this language, so they built some beast on top of it which is the de facto standard right now. But you can still write JavaScript, and you can avoid all the shit parts like "classes" and what not, do classic prototype-style programming, or even layer your own functional/OOP programming on top. Not much you cannot do in JavaScript, probably only a lisp would enable more programming paradigms, but for mainstream languages, it's as close as you can get to True Freedom.
Yes it can. But it's nearly impossible to handle such cases properly. That's why checking each allocation manually is a bad idea. Other languages do this better - they provide nice abstractions, but if something fails, the language runtime terminates the process. The result is the same, but has much less friction.
Also on some systems (like Linux) memory allocation may not fail, but the "allocated" memory may not be available and a program can crash accessing this memory.
Zig is in the space of languages where an abstraction that decides that memory allocations are irrecoverable is not good enough.
If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, or C for that matter. Not every language should be designed to live in the space of "somehow low level but also a good choice for your basic web backend", like Rust.
Nearly impossible in some contexts, where the trade-off makes sense.
There are many scenarios, especially in embedded systems, where it can happen and you want to handle it robustly, e.g. by evicting a cache or flushing a buffer to disk.
Glad to see "Together we serve the users" come back. I miss the old Zig readme that said Zig comes with an MIT license and a humble request to build software that serves the users.
I saw what changed syntactically. I meant I don't really understand what changed semantically. And whether there is any context to why the change was necessary.
I'm guessing the parent is wondering why this is noteworthy enough to be posted and discussed in this thread, and so if there's context they are missing
I recommend you to watch Andrew Kelly interview[0], while I'm not the target audience of Zig, I don't see him driving away any user. Also Jai as for now is a non existing language, just a selected few has access to it, but Jai approach is a kitchen sink, from what I saw it is all over the place in terms of features, now Zig vision feels cohesive.
Activism as in their move away from GitHub? Andrew K recently said in the JetBrains interview that because of moving away, their CI/CD now actually works.
Jai isn't even available publicly. The license isn't decided. Jonathan Blow doesn't want to deal with open source.
Comparing Jai and Zig on that behalf is crazy.
Edit: If that is about political activism it's even more crazy. A dude that rambles about woke stuff is political as well. Maybe just aligns with yours.
I think they banned AI and moved from GitHub to Codeberg. They don't seem too controversial to me, and IMO they've already comprehensively trounced Odin, Jai and C3.
Excuse me, but I think zig grows ever better from driving away users who are driven away by flashy headlines and whatever is the opposite of this “activism” you suggest.
I'm not sure that if this is an obvious question that has been gone through already, but have any of the death threats relating to Rust stuff actually been "verified" or is it just an opinion that has been repeated enough times until it has been accepted as truth?
Just the open amount of discontent towards the language and the community, creates the perfect storm for a malicious individual to pose being a Rust developer that sends death threats for doing things that are not aligned with the values of the language/community.
I always felt that Python's "There should be one-- and preferably only one --obvious way to do it." was a bit of a mess.
Obviously (to anyone who was around at the time), that plank was written in response to Perl's motto: "There is more than one way to do it."
Zig's original take on this, "Only one obvious way to do things" seems even worse. You see, both languages agree that Perl had it wrong: it is unhelpful to have several different ways to write any future. But they went a little too far: it is not actually bad for it to be possible to write the same thing in more than one way.
Zig's new phrasing: "There is an idiomatic way to do it." captures the CORRECT alternative to Perl's motto. It is not important that there be no alternative ways of writing something, Rather, it is important that there be a single idiomatic way to write it.
Also, importantly, the Zen of Python is kinda written as a set of ideas that Python should aspire to ("there should be one obvious way to do it") instead of a sales pitch of Python's merits. I prefer that.
Yes it can. But it's nearly impossible to handle such cases properly. That's why checking each allocation manually is a bad idea. Other languages do this better - they provide nice abstractions, but if something fails, the language runtime terminates the process. The result is the same, but has much less friction.
Also on some systems (like Linux) memory allocation may not fail, but the "allocated" memory may not be available and a program can crash accessing this memory.
If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, or C for that matter. Not every language should be designed to live in the space of "somehow low level but also a good choice for your basic web backend", like Rust.
There are many scenarios, especially in embedded systems, where it can happen and you want to handle it robustly, e.g. by evicting a cache or flushing a buffer to disk.
> - rewordings
> - "memory is a resource" goes without saying
> - emphasize the final point
[0] https://youtu.be/iqddnwKF8HQ
Comparing Jai and Zig on that behalf is crazy.
Edit: If that is about political activism it's even more crazy. A dude that rambles about woke stuff is political as well. Maybe just aligns with yours.
wow, what a self report
Just the open amount of discontent towards the language and the community, creates the perfect storm for a malicious individual to pose being a Rust developer that sends death threats for doing things that are not aligned with the values of the language/community.