I don't understand what he wanna imply. Both are programming languages, and we should just let people decide what is best for them. How is Rust lang creating a problem that Zig lang developer is saying "Let us exists".
The rust philosophy is very correctness oriented and safety focused.
This, combined with a general frustration with how broken software engineering is as a whole, has led to the mindset in part of the rust community that using anything less than very rigorous type checking is unprofessional and dangerous (think Therac-25, https://en.wikipedia.org/wiki/Therac-25).
Zig is in a sense the antithesis to that statement, in that it eschews complex tools like a sophisticated type system, in favour of simplicity and programmer enforced contracts, with the reasoning that it is easier to informally proof correctness of a simple system, than to formally proof correctness of a very complex system. The correctness of the latter often being a somewhat shallow property that is still able to miss the intended semantics (think memory vs logic bugs).
The closest analogy in programming language communities is probably clojure vs scala or haskell.
In fact there is an interesting paper on code quality, where clojure compared quite favourably to statically typed languages, despite it's dynamic nature.
https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. The Rust devs are still working on giving a full semantics for the 'unsafe' superset of the language, and this currently involves quite a few pitfalls that just don't exist elsewhere in the same way.
(And btw, unsafe code cannot be ignored altogether since it comes up naturally in any interaction with outside, non-Rust code. Additionally, idiomatically "safe" APIs can sometimes introduce restrictions that leave some performance gains on the table compared to well-written unsafe interfaces.)
Yes I wholeheartedly agree, rust is definitely overpromising in that department.
The language has grown too large too quickly imho, and having the compiler as a formally verifying aide when the foundations/axioms aren't defined yet certainly leaves a bad aftertaste for me.
However, the very same can be said for zig. Given that it is such a simple language, development has focused on a many interesting things including incredible performance, but one has to wonder if the priority shouldn't have been correctness and a fully working compiler that can handle e.g. packed unions.
> Zig can easily be more correct than unsafe code in Rust.
Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x = if (false) { X(); } }` sometimes calls X. It is not possible to be "more correct" in such a language.
Zig inspired me to think deeply about comptime evaluation and how it could be made into a coherent language, and in that respect it is a useful toy language, but no more. (In zig the comptime idea is incoherent: You cannot run ordinary zig code at comptime because of core differences in behavior. For example, there's no allocation allowed, except that code which appears literally in a comptime block can sometimes append arrays together; but this still means you can't run ordinary code.)
Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code.
This one is quite funny. Normally you'd use `if (a) ... else |b| ...` if the type of `a` was an error union, and you'd get the `if` branch if it was not an error and the `else` branch if it was an error. So I suspect that there's a coercion from bool to some error union here. Error unions with lazily computed error sets are allowed, and (as a result of this or of other choices about the ergonomics of conditionally-compiled code that would be made of #typedefs in C) error unions with empty error sets are allowed. Wow.
As someone considering whether to learn rust or zig next for hobby projects, this does seem a pretty big deal breaker for zig, at least in its current state. But since zig still hasn't really even reached the 1.0.0, it is expected to have compiler bugs like this? Or do you believe this is something that can't be fixed due to fundamental language design?
It's not expected to have miscompilation bugs like this by 1.0. These are bugs in the stage1 (original C++) compiler implementation, not language design issues as the poster claims. The language still has design issues that are being addressed (result location, async, etc.) but they're unrelated to `if` bugging out in this case.
The stage1 compiler is currently being phased out for the stage2 compiler (Zig implementation). As of current master branch, stage1 is disabled by default (can be re-enabled with `-fstage1`) in favor of stage2.
Stage2 is like a Band-Aid on an amputee. It is built with stage1. Any compiler built such that `if (false)` branches can run will also miscompile code, even if its source is 100% correct. (Spoiler alert: its source will not be 100% correct.)
1) Stage2 is intended as more than just fixes for stage1; It includes performance improvements, more codegen backends (direct x86/arm/wasm to avoid LLVM, C, etc.), will allow for incremental linking, hot reloading, and more.
2) The miscompilation in question is `if (false) else |capture| {}` not just `if (false)`. The latter is misinformation.
3) Miscompilations are conditional. Saying that the entire compiler is invalid given they exist is like saying rustc is invalid / can't uphold safety invariants given long standing compiler bugs allowing safe code to trigger UB / segfault [0] [1]. Both of such conclusions aren't true in practice.
It's not uncommon for LLVM releases to come with regressions that cause miscompilations. The compiler toolchain industry is very different from what you seem to think it is.
I am only moderately surprised by this, because I have seen some less egrigious intermittent miscompilations in stage1 such as this one: https://github.com/ziglang/zig/issues/11786
I cannot provide the full program in which it failed, and the small programs I tried did not cause it to fail at the time.
I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on.
Edit: after seeing the linked issue in a sibling comment, this is even less surprising. stage1's handling of basically any complex expression in struct/tuple literals is quite bad. I've mostly had it crash the compiler, but it's not surprising that it can also just evaluate incorrectly. It seems plausible that the actual solution to all this is to use stage2 instead, but we cannot move all of our programs to stage2 today because we use async.
> Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust.
If you worry about unsafety in Rust, then you should know you can run miri on your unsafe code to check for undefined behavior, in addition to most C tools used like valgrind, etc.
"Can be more" correct is a bit weaselish (corrolarry it "Can be less"). Sure. You can write bad code in any language. Rust gives you tools to limit sets of memory errors, and on top of that you can use C-standard tools, -AND- even Rust specific tools.
And on top of that it offers sets of tools to eliminate possible errors in safe Rust code (see Clippy).
I admittedly don't follow Rust or Zig very closely, but I think Kelley's comment is about the communities supporting the languages, not the languages themselves.
The sense I get from reading a few Twitter threads is that members of the Zig community feel that the Rust community disagrees so strongly with some of Zig's design decisions that the Rust folks suggest that the world would be better without Zig.
Rust the language isn't causing a problem, but certain members of the Rust community (cited elsewhere in this thread) don't seem to be "letting Zig exist" as Andrew Kelley puts it. One can only be bullied so many times before hitting back.
> It's perfectly reasonable to take the position that it's deeply problematic for a language aiming for wide use in 2022 to not be memory safe. There's no requirement that you "focus on tradeoffs", especially since real people get hurt by memory safety problems.
And my message was already about someone else calling Zig users irresponsible. Talk about toxicity.
pcwalton's problem is that he doesn't distinguish between different levels of memory safety. It might be "deeply problematic" for a language aiming for wide use in 2022 not to be make some significant efforts toward memory safety, but it doesn't have to be Rust levels. Rust itself isn't 100% memory safe, because a lot of code has to be marked "unsafe" even when it actually is safe and then it might contain other bugs completely unrelated to the reason for the marking and those might go undetected. Similarly, languages like Java and Python are even more memory-safe than Rust, but programs written in them are hardly bug-free either.
If you eliminate enough memory-safety bugs, then other classes start to dominate and should also be addressed. Rust is beyond this point, but to get there it diverted resources from addressing other kinds of bugs and has also made some severe usability/productivity tradeoffs. Zig might or might not be at that point, but it certainly promises to get there and to do so without the same drawbacks. Ultimately the question is which language lets you write more bug-free code per month. A reasonable argument could be made that it's Rust and a reasonable argument could be made that it's Zig. Only time will tell, but only if both continue to exist and evolve, which pcwalton and others seem unwilling to let happen. What's "deeply problematic" is their belief that Rust's goals and approaches represent The One Right Way and no others can be allowed to exist.
The VP of community calling people a "full-time safety coomer" is... well it's something. Not exactly sure what, but not something that says "Hey, Zig has a nice community".
It's a term that means approximately "obsessively-masturbating neckbeard". The tweet is derisively saying that pcwalton's focus on safety is equivalent to masturbation.
Whether one agrees with Zig's approach or not, it'd be pretty reasonable to say "Zig doesn't focus on this sort of thing". However, I'd go so far as to say that any language community that has a prominent person slinging aggressive insults like this is one to avoid.
I don't quite get why this is flagged, hence I vouched for it.
Calling someone a "full time safety coomer" seems innapropriate for someone holding the title of "vp of community" in the Zig foundation.
It certainly makes me reevaluate the zig community, which thus far was at times a bit childish, but always friendly.
While I see this might violate "Eschew flamebait.", a constructive reflection of the interactions between the rust and zig community still feels like a worthwhile endeavour.
I don't understand how this could turn you off. Is it good? Is it useful? Use it. Who cares if some community rep guy is a perfect princess or a bit of an asshat.
You aren't really hanging out with the guy who wrote that tweet when you use zig. And it seems a bit hasty to extrapolate his behavior to be representative of the entire community, if you think that matters.
Using a niche language often means interacting with its community. I don't mind if a couple of fans duke it out, but when somebody like Loris resorts to ad hominem attacks, that's pretty telling. Egos are getting in the way, they've lost sight of the goal and now it's just another content-free slapfest. It isn't a good look. If I report a bug in the language, is somebody important going to take it personally and flame me for it?
Nobody is going to take a bug report personally because it isn't the same as implying the project is pointless and even morally wrong whenever the opportunity arises.
For what it's worth, I only handle GH issues relative to the autodoc system. I can say with confidence that all Zig core contributors are nicer than me, although today this statement does sound less convincing than usual.
I acted out, and I'm acknowledging the mistake. If you want to submit a bug report, make sure to follow the template and you will be treated well.
I appreciate the humility here. For the record, I'm not immediately concerned about the Zig community; my comment above is more of an elaboration on why such behavior can be offputting.
I think your point was fair. I don't intend to bend to every single outraged comment on social media, but my ultimate interest is to experience (and contribute to) the best that computer science has to offer. Humility is a small price to pay for that as otherwise it's impossible to recognize one's own mistakes.
First, I’m not a zig user, or a zig community member so I don’t really care that much whether you use it or not. But it comes off as a bit immature to let a single person’s actions turn you off from an entire language. I’m sure it would be easy to find some shitty behavior from some individual in almost every community. There are dozens of examples in linux, in ruby, in python, in rust, etc.
Open source communities are not homogenous, and they involve humans. People have bad days, people say things that aren’t well thought out, some times it takes a while for someone to come around to why what they said was hurtful, counter productive, etc. I don’t know the country of origin for this person, but some cultures have a much more direct and confrontational style of communication.
Use the language or don’t, but if this is the reason you don’t, maybe spend some time reflecting on why a relatively unimportant interaction appears to have affected you so strongly.
Anyways, Loris Cro is not a random single person, he's more like the public face of the leadership team. For context, Loris is framing the greater conversation as punching back against Rust's dishonest marketing practices.
Should this matter if you like to use the tool? Not for me. But I'm not going to be confused when people look at the PR smell and feel averted.
That's a fair argument. I should be understandably held to higher standards than the average community member. I got into a heated discussion and fell into one of the common social media fallacies, ultimately acting in a distruptive way.
As for the marketing debate, trying to manage expectations wrt to Zig is one of the main things that I do, and sometimes people do get too excited and imagine that the tool is able to do things that it ultimately cannot. Tampering that enthusiasm and trying to stay concrete is something that I try to do with great care. My impression is that when it comes to Rust, some of the arguments in extreme favor of rust (Rust protects you from everything) and also against Rust (Rust is useless because the compiler uses LLVM, which is C++) IMO both stem from mistakes in how the safety story is taught.
That said, I'm saying this to provide context to my perspective, not as a justification to my outburst.
I think this interaction looked particularly bad because the person you replied to was pointing out a true detail, in the common style of nerds pointing out details, and readers will generally not have context about your previous interactions with them.
Yes. It's don't think it's fair to called "a heated discussion". pcwalton made a small correction about a claim someone made concerning the database, and croloris/kristoff_it made a response he subsequently regretted and deleted. There was no heat until he introduced it.
pcwalton said on 9/9/2022 that Zig was "a massive step backwards for the industry". He believes that all new languages should be "memory safe"; anything that doesn't meet his definition of memory safe is against "consensus".
Patrik's comment came before croloris's flame, and around the same time Zig was praised in the recent GameJam thread. The trade-off between memory safety and performance triggered a minor flamewar which Patrick heated by asserting that Zig wasn't memory safe and it violated "consensus".
To slightly correct you, as I think you’re misreading the tweets, he said the change in the consensus of wanting memory safety to not caring about it was a massive step back for the industry.
He was asking if the idea of memory safety was consensus and didn’t say that things against it were not consensus.
> My impression is that when it comes to Rust, some of the arguments in extreme favor of rust (Rust protects you from everything) and also against Rust (Rust is useless because the compiler uses LLVM, which is C++) IMO both stem from mistakes in how the safety story is taught.
I see this, and I agree that rust evangelists often go way too far and motte & bailey in arguments about safety. These arguments are safe to ignore. More importantly, if you engage with that class of argument; there's no winning. You certainly won't convince them of a thing, but you risk looking the fool. Keep your head up and talk about the many merits of Zig.
I see the opposite as an equally big problem: bad messaging creates Rust haters who occasionally try to interact with the Zig community, lowering the quality of the community experience if not pushed away. That's another thing that I've been doing and thus fueling my annoyance towards bad messaging around safety.
As I said in a few places, I do apologize for the outburst. Deleting the tweet is part of showing that I do mean to take back my words. As for the time delay, some of it is because it took me a bit to cool down, some of it is just that I wasn't checking on Twitter. One of my usual rants is that I keep Twitter notifications disabled and that the app keeps nagging me about it.
> Hard not to be turned off of the Zig language after this kind of thing.
can you explain that? I see this as one person (a person who is not the Zig language itself) having an opinion, being passionate about it, then realizing a mistake was made, and then learning from it and (very likely) becoming a better person for it?
or are you really someone who thinks "Eric Clapton is super duper racist so it's hard not to be turned off of music entirely"
I do what the person behind those tweets did very often, on this site, and every time I realize my mistake and become a better person because of what I learn.
The Zig language community is small. I think it’s more comparable to “Eric Clapton is a valued member of the local music scene, so I’d rather not engage with that scene”.
Not that he’s actually comparable to Eric Clapton, but yknow.
Lately it seems like everything has some weird community aspect to it that becomes relevant because (?), single player games have communities now, even brands and, I guess now, programming languages(certainly enough to have a VP of community). Sure stuff like comp.lang.$language has been a thing for forever but that was not at that level.
I probably went into a bit of a ramble but the point i'm getting at is that odds are this "community" is most likely not representative of the people that actually use the language and to not assume people who do are automatically part of it, not saying you were, but some words of caution I suppose.
And furthermore, although that is unrelated to your point but more in a general statement for the younger people: You don't need to join a community or even talk to people to use a language or api or whatever, they're tools and using them or not should be based on where your technical interests lie or what you're trying to solve, not trying to be part of a social circle where the only thing you have in common is that you all wrote some lines of code in a certain script. Don't let yourself be defined by such things and don't do it to yourselves.
Open source projects definitely have communities and it’s not an artificial thing. You have the developers and consumers of the project and they have a lot of social interactions.
Neither are the other communities listed artificial(maybe the brands? not sure). Open source projects communities I'd relate more to the comp.lang.$language, and I guess the social interaction would be relevant, but are there really enough people contributing to a project to have a "vp of community"? this is what raised the red flag for me, well that and someone making up a "cute" name to refer to themselves as part of an in-group like languages were youtube channels("Rustaceans"). I guess the edit I made would clear up where I was with my previous comment.
Must be a generational thing or something. I've used a ton of languages and I've never interacted with the "community" of said language.
I might've been on an (unofficial?) IRC channel for the language, but that's about it. Never felt the need to belong in a community for a hecking programming language =)
IIRC the trend, including the obligatory cutesy avatar (and PL as a life-style choice /g), started with Java. And Java was ~coincidental with internet breaking out of universities. So my guess would be that it's 'an internet thing'.
p.s. 'Rotary Club' popped into my head after posting this. Possibly this is a manifestation of "learned" (lol) and professional associations for a domain that famously lacks professional credentials, so 'birds of a feather' naturally form around the specialized tools and their users. And we get PL feel good conferences, the language hero (Gosling, Pike, et al.), the stuffed animals, and the rest of it.
Some degree of childish-ness is to be expected from a language that's young. I'll snicker at the "coomer" comment when I get home from the office, but it doesn't change the fact that I won't be using Zig at work anytime soon. Not for anything serious, at least.
To be clear, the comment changes nothing about Zig's nonexistent viability in a professional space. As a career C programmer, I believe that Zig has always been every luddite's backhanded answer to Rust made manifest.
Your second sentence answers your first. On HN, let's stick to the intellectually interesting topics and steer clear of the ones that are mostly just drama.
This is particularly important here, because both of these languages are popular topics already. We don't have space for all of them—frontpage space is the scarcest resource on HN—so we need to be discriminating about which are the best ones.
It must be super frustrating to be working on and promoting Zig. Zig has a bunch of its own innovative language features. It has amazing cross-compilation. It is a major improvement over C that still feels closer in spirit to C than C++.
…but Rust has changed how people view languages. It has brought focus on compile-time safety, and shown it's possible and practical. It has shown that data races can be caught at compile time. It has shown that GC vs manual memory management has a third option.
The main thing I guess is dealing with C APIs in C++. You do have to use C APIs in Rust as well though, but maybe dealing directly with plain C APIs is less common because of how annoying it is. The only way to avoid that pain is to make a Wrapper library that exposes a more idiomatic and possibly "safe" interface. C++ can wrap C APIs just as well though.
I agree with you though, C++ has been doing RAII for a while and I'm not sure why people seem to think Rust invented it. Idiomatic C++ APIs and code are just as "automatic" as Rust for the most part!
Even though ownership and borrowing are theoretically orthogonal, they're both needed to make a complete safe system (the context was about managing memory for safety, not merely having a syntax sugar for malloc/free.)
Unique ownership prevents leaks and double-free, and borrow checking prevents use-after-free. Borrowing is necessary to temporarily relax the exclusivity of uniquely-owned objects and access their interior. Access to interior of a unique_ptr (and shared_ptr) decays it to a reference or a bare pointer that is not managed by the smart pointer any more, and can be left dangling. Borrow checker eliminates the manual "be careful not to leave dangling pointers" part.
I'd definitely consider it a third option, "garbage collection" to me strongly implies the existence of a "garbage collecter" à la tracing collectors. Reference counting injects reference checks/increments and destructors into the program itself, which means you don't have a separate routine running independently (and nondeterministically) of the main program.
The phrase "garbage collection" has also come to be somewhat associated with tracing's specific characteristics (IMO). Manual memory management is performant and deterministic, but unsafe. Tracing garbage collection is performant and safe, but nondeterministic. Reference counting is deterministic and safe, but not as performant. If you throw Rust into the mix as a fourth option I suppose you could add a "flexible" characteristic.
> Reference counting is deterministic and safe, but not as performant.
Not as performant in a theoretical model with unlimited memory that all costs the same to access. ie it’s not actually faster in practice when peak memory matters and swap exists.
It’s deterministic, doesn’t scan memory, and the program only runs the exact instructions you see in its binary instead of stopping and having some part of the runtime appear from nowhere and change things. So… it’s not garbage collection, it’s a dual to it.
Rust avoids copies and occasionally proves single ownership instead of having RCs. This seems to me to be overoptimization and a waste of programmer time. Copies are fine and you don’t need to prove them away.
Replies to my comment are questioning whether that was really a third or third-and-a-halfth option, but my point was that previously mainstream languages offered either memory managed by a run-time with an overhead (this includes ARC), or depended on diligence of the programmer to work correctly (Rust has copied C++ move semantics, but made moves automatic and checked).
Rust's ownership + borrowing instead of being somewhere on the axis of performance vs correctness trade-off, has traded off generality/flexibility instead (infamous for being unfit for doubly-linked lists). Unlike ARC, it works without a run-time, and on bare allocations and stack objects too. Unlike C++, it has zero-cost slices/substrings without a risk of dangling pointers.
Let’s also remember that there are real human beings involved and remember to be kind, forgiving, and not fall into vindictiveness. I don’t think this person is a terrible human being just because of a single gaffe in twitter. I’m sure we’ve all had a lot of gaffes in our time on the internets.
I have no idea what’s even the point of making such comments. We’ve seen dozens of programming languages in the last few decades and all of those languages have their own unique set of features.
I’ve learned Rust, Prolog, Fortran, and licked a bit of Ada in the last 4 weeks only. That adds to at least a dozen I worked professionally in the last 22 years. All I can say: yeah, whatever you do in your programming language X, has been done in the past. We all stand on the shoulders of giants.
What was that quote? “Talk is cheap. Show me the code”?
I do agree that the term "safe" shouldn't be used as a shorthand for "memory-safe". Memory safety is only a subset of correctness, and "safe" in my ears sounds misleadingly like a stronger promise. (And the "unsafe" keyword does not necessarily mean memory-unsafe, but simply unchecked.) There's no real harm in this, but I'm a fairly sensitive person and can't help but feel slightly shamed even when I have a case that legitimately requires the use of unsafe Rust, which can be mildly frustrating. That's something that I need to get over, though; I don't think Rust should change.
To be clear, I really like Rust (oh, that I could never write C++ again). There are some astonishingly underdeveloped parts here and there [1], and I've a few pet peeves, but it's fun to use and I think it's a great step in the right direction. I'm really grateful to all the people who work on it.
on the language itself, no. on the community surrounding the language? yeah, maybe. they're people you may have to wind up interacting with if you adopt the language.
If we could get the zig of formal methods to team up with zig ... Omg ... I've played here and there with spin, and a few others but nothing yet stuck for the long term. Fm helps safety in all aspects not just memory.
I really hope Zig could reflect on Rust, and adopt a No Hype, No Zealots, and no Evangelism, Show, dont tell, Good old fashion engineering philosophy. Zig already has enough spotlight with a few high profile usage like bun. It doesn't need any drama to gain reach.
Just ignore the Rust people's comment. It gets ugly in a hurry.
As the target of the barb (which I don't care about--I don't even know what a "coomer" is and I don't care to research it), I flagged this submission. The whole thing is just drama and isn't appropriate for HN.
97 comments
[ 2.0 ms ] story [ 127 ms ] thread>I see a lot of toxic Rust vs Zig discourse on Twitter right now. I want to clarify my stance:
>I'm happy Rust exists and I think it offers a compelling set of tradeoffs.
>If Rust people can afford Zig the same courtesy, then I see our relationship as collaborative.
>Let us exist.
https://twitter.com/andy_kelley/status/1568679389113757698
Zig is in a sense the antithesis to that statement, in that it eschews complex tools like a sophisticated type system, in favour of simplicity and programmer enforced contracts, with the reasoning that it is easier to informally proof correctness of a simple system, than to formally proof correctness of a very complex system. The correctness of the latter often being a somewhat shallow property that is still able to miss the intended semantics (think memory vs logic bugs).
The closest analogy in programming language communities is probably clojure vs scala or haskell. In fact there is an interesting paper on code quality, where clojure compared quite favourably to statically typed languages, despite it's dynamic nature. https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
(And btw, unsafe code cannot be ignored altogether since it comes up naturally in any interaction with outside, non-Rust code. Additionally, idiomatically "safe" APIs can sometimes introduce restrictions that leave some performance gains on the table compared to well-written unsafe interfaces.)
In a sense rust hasn't managed to reach it's de Bruijn criterion yet, see https://lawrencecpaulson.github.io/2022/01/05/LCF.html
However, the very same can be said for zig. Given that it is such a simple language, development has focused on a many interesting things including incredible performance, but one has to wonder if the priority shouldn't have been correctness and a fully working compiler that can handle e.g. packed unions.
Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x = if (false) { X(); } }` sometimes calls X. It is not possible to be "more correct" in such a language.
Zig inspired me to think deeply about comptime evaluation and how it could be made into a coherent language, and in that respect it is a useful toy language, but no more. (In zig the comptime idea is incoherent: You cannot run ordinary zig code at comptime because of core differences in behavior. For example, there's no allocation allowed, except that code which appears literally in a comptime block can sometimes append arrays together; but this still means you can't run ordinary code.)
ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040
Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code.
More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097
This one is quite funny. Normally you'd use `if (a) ... else |b| ...` if the type of `a` was an error union, and you'd get the `if` branch if it was not an error and the `else` branch if it was an error. So I suspect that there's a coercion from bool to some error union here. Error unions with lazily computed error sets are allowed, and (as a result of this or of other choices about the ergonomics of conditionally-compiled code that would be made of #typedefs in C) error unions with empty error sets are allowed. Wow.
The stage1 compiler is currently being phased out for the stage2 compiler (Zig implementation). As of current master branch, stage1 is disabled by default (can be re-enabled with `-fstage1`) in favor of stage2.
2) The miscompilation in question is `if (false) else |capture| {}` not just `if (false)`. The latter is misinformation.
3) Miscompilations are conditional. Saying that the entire compiler is invalid given they exist is like saying rustc is invalid / can't uphold safety invariants given long standing compiler bugs allowing safe code to trigger UB / segfault [0] [1]. Both of such conclusions aren't true in practice.
[0]: https://crates.io/crates/fake-static [1]: https://github.com/rust-lang/rust/issues/25860
I cannot provide the full program in which it failed, and the small programs I tried did not cause it to fail at the time.
I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on.
Edit: after seeing the linked issue in a sibling comment, this is even less surprising. stage1's handling of basically any complex expression in struct/tuple literals is quite bad. I've mostly had it crash the compiler, but it's not surprising that it can also just evaluate incorrectly. It seems plausible that the actual solution to all this is to use stage2 instead, but we cannot move all of our programs to stage2 today because we use async.
If you worry about unsafety in Rust, then you should know you can run miri on your unsafe code to check for undefined behavior, in addition to most C tools used like valgrind, etc.
"Can be more" correct is a bit weaselish (corrolarry it "Can be less"). Sure. You can write bad code in any language. Rust gives you tools to limit sets of memory errors, and on top of that you can use C-standard tools, -AND- even Rust specific tools.
And on top of that it offers sets of tools to eliminate possible errors in safe Rust code (see Clippy).
The sense I get from reading a few Twitter threads is that members of the Zig community feel that the Rust community disagrees so strongly with some of Zig's design decisions that the Rust folks suggest that the world would be better without Zig.
Maybe this has something to do with this line from former Rust team member:
> I don't see much room for a new language that isn't memory-safe in 2022.
>A massive step backwards for the industry. :(
https://twitter.com/pcwalton/status/1568306598795431936?s=46...
:(
> It's perfectly reasonable to take the position that it's deeply problematic for a language aiming for wide use in 2022 to not be memory safe. There's no requirement that you "focus on tradeoffs", especially since real people get hurt by memory safety problems.
And my message was already about someone else calling Zig users irresponsible. Talk about toxicity.
If you eliminate enough memory-safety bugs, then other classes start to dominate and should also be addressed. Rust is beyond this point, but to get there it diverted resources from addressing other kinds of bugs and has also made some severe usability/productivity tradeoffs. Zig might or might not be at that point, but it certainly promises to get there and to do so without the same drawbacks. Ultimately the question is which language lets you write more bug-free code per month. A reasonable argument could be made that it's Rust and a reasonable argument could be made that it's Zig. Only time will tell, but only if both continue to exist and evolve, which pcwalton and others seem unwilling to let happen. What's "deeply problematic" is their belief that Rust's goals and approaches represent The One Right Way and no others can be allowed to exist.
If you follow Zig and Rust closely on HN you may have more sympathy as to why they think that.
https://www.urbandictionary.com/define.php?term=Coomer
Whether one agrees with Zig's approach or not, it'd be pretty reasonable to say "Zig doesn't focus on this sort of thing". However, I'd go so far as to say that any language community that has a prominent person slinging aggressive insults like this is one to avoid.
Calling someone a "full time safety coomer" seems innapropriate for someone holding the title of "vp of community" in the Zig foundation.
It certainly makes me reevaluate the zig community, which thus far was at times a bit childish, but always friendly.
While I see this might violate "Eschew flamebait.", a constructive reflection of the interactions between the rust and zig community still feels like a worthwhile endeavour.
Edit: After some research it seems that the author has since apologised https://twitter.com/croloris/status/1568704125826748416
Hard not to be turned off of the Zig language after this kind of thing. Looks like he deleted the original tweet and is in full damage control mode
I acted out, and I'm acknowledging the mistake. If you want to submit a bug report, make sure to follow the template and you will be treated well.
Open source communities are not homogenous, and they involve humans. People have bad days, people say things that aren’t well thought out, some times it takes a while for someone to come around to why what they said was hurtful, counter productive, etc. I don’t know the country of origin for this person, but some cultures have a much more direct and confrontational style of communication.
Use the language or don’t, but if this is the reason you don’t, maybe spend some time reflecting on why a relatively unimportant interaction appears to have affected you so strongly.
https://en.wiktionary.org/wiki/MINASWAN
Anyways, Loris Cro is not a random single person, he's more like the public face of the leadership team. For context, Loris is framing the greater conversation as punching back against Rust's dishonest marketing practices.
Should this matter if you like to use the tool? Not for me. But I'm not going to be confused when people look at the PR smell and feel averted.
As for the marketing debate, trying to manage expectations wrt to Zig is one of the main things that I do, and sometimes people do get too excited and imagine that the tool is able to do things that it ultimately cannot. Tampering that enthusiasm and trying to stay concrete is something that I try to do with great care. My impression is that when it comes to Rust, some of the arguments in extreme favor of rust (Rust protects you from everything) and also against Rust (Rust is useless because the compiler uses LLVM, which is C++) IMO both stem from mistakes in how the safety story is taught.
That said, I'm saying this to provide context to my perspective, not as a justification to my outburst.
https://twitter.com/pcwalton/status/1568302065851707392
Patrik's comment came before croloris's flame, and around the same time Zig was praised in the recent GameJam thread. The trade-off between memory safety and performance triggered a minor flamewar which Patrick heated by asserting that Zig wasn't memory safe and it violated "consensus".
https://news.ycombinator.com/item?id=32783244
He was asking if the idea of memory safety was consensus and didn’t say that things against it were not consensus.
I see this, and I agree that rust evangelists often go way too far and motte & bailey in arguments about safety. These arguments are safe to ignore. More importantly, if you engage with that class of argument; there's no winning. You certainly won't convince them of a thing, but you risk looking the fool. Keep your head up and talk about the many merits of Zig.
can you explain that? I see this as one person (a person who is not the Zig language itself) having an opinion, being passionate about it, then realizing a mistake was made, and then learning from it and (very likely) becoming a better person for it?
or are you really someone who thinks "Eric Clapton is super duper racist so it's hard not to be turned off of music entirely"
I do what the person behind those tweets did very often, on this site, and every time I realize my mistake and become a better person because of what I learn.
Not that he’s actually comparable to Eric Clapton, but yknow.
Lately it seems like everything has some weird community aspect to it that becomes relevant because (?), single player games have communities now, even brands and, I guess now, programming languages(certainly enough to have a VP of community). Sure stuff like comp.lang.$language has been a thing for forever but that was not at that level.
I probably went into a bit of a ramble but the point i'm getting at is that odds are this "community" is most likely not representative of the people that actually use the language and to not assume people who do are automatically part of it, not saying you were, but some words of caution I suppose.
And furthermore, although that is unrelated to your point but more in a general statement for the younger people: You don't need to join a community or even talk to people to use a language or api or whatever, they're tools and using them or not should be based on where your technical interests lie or what you're trying to solve, not trying to be part of a social circle where the only thing you have in common is that you all wrote some lines of code in a certain script. Don't let yourself be defined by such things and don't do it to yourselves.
I might've been on an (unofficial?) IRC channel for the language, but that's about it. Never felt the need to belong in a community for a hecking programming language =)
p.s. 'Rotary Club' popped into my head after posting this. Possibly this is a manifestation of "learned" (lol) and professional associations for a domain that famously lacks professional credentials, so 'birds of a feather' naturally form around the specialized tools and their users. And we get PL feel good conferences, the language hero (Gosling, Pike, et al.), the stuffed animals, and the rest of it.
https://en.wikipedia.org/wiki/Learned_societies#History
To be clear, the comment changes nothing about Zig's nonexistent viability in a professional space. As a career C programmer, I believe that Zig has always been every luddite's backhanded answer to Rust made manifest.
This is particularly important here, because both of these languages are popular topics already. We don't have space for all of them—frontpage space is the scarcest resource on HN—so we need to be discriminating about which are the best ones.
https://mobile.twitter.com/croloris/status/15685704943030517...
Does anyone have a copy?
…but Rust has changed how people view languages. It has brought focus on compile-time safety, and shown it's possible and practical. It has shown that data races can be caught at compile time. It has shown that GC vs manual memory management has a third option.
C++ had shown this long before Rust.
The main thing I guess is dealing with C APIs in C++. You do have to use C APIs in Rust as well though, but maybe dealing directly with plain C APIs is less common because of how annoying it is. The only way to avoid that pain is to make a Wrapper library that exposes a more idiomatic and possibly "safe" interface. C++ can wrap C APIs just as well though.
I agree with you though, C++ has been doing RAII for a while and I'm not sure why people seem to think Rust invented it. Idiomatic C++ APIs and code are just as "automatic" as Rust for the most part!
(Your literal question is a straw man: no, those aren't different, but Rust offers more.)
Unique ownership prevents leaks and double-free, and borrow checking prevents use-after-free. Borrowing is necessary to temporarily relax the exclusivity of uniquely-owned objects and access their interior. Access to interior of a unique_ptr (and shared_ptr) decays it to a reference or a bare pointer that is not managed by the smart pointer any more, and can be left dangling. Borrow checker eliminates the manual "be careful not to leave dangling pointers" part.
Objective-C has only existed a few decades now.
AFAIK Objective-C has lots of reference counting.
The phrase "garbage collection" has also come to be somewhat associated with tracing's specific characteristics (IMO). Manual memory management is performant and deterministic, but unsafe. Tracing garbage collection is performant and safe, but nondeterministic. Reference counting is deterministic and safe, but not as performant. If you throw Rust into the mix as a fourth option I suppose you could add a "flexible" characteristic.
Not as performant in a theoretical model with unlimited memory that all costs the same to access. ie it’s not actually faster in practice when peak memory matters and swap exists.
Rust avoids copies and occasionally proves single ownership instead of having RCs. This seems to me to be overoptimization and a waste of programmer time. Copies are fine and you don’t need to prove them away.
Rust's ownership + borrowing instead of being somewhere on the axis of performance vs correctness trade-off, has traded off generality/flexibility instead (infamous for being unfit for doubly-linked lists). Unlike ARC, it works without a run-time, and on bare allocations and stack objects too. Unlike C++, it has zero-cost slices/substrings without a risk of dangling pointers.
“Coomer is an internet meme based on an illustration of a scraggly male character who is mocked as an excessive masturbator.”
So calling someone a “safety coomer” isn’t great - especially from a “VP of community”. Let’s just agree not to do that again and move on.
Personally I’m more annoyed that a small language foundation would hand out VP titles.
Let’s also remember that there are real human beings involved and remember to be kind, forgiving, and not fall into vindictiveness. I don’t think this person is a terrible human being just because of a single gaffe in twitter. I’m sure we’ve all had a lot of gaffes in our time on the internets.
I’ve learned Rust, Prolog, Fortran, and licked a bit of Ada in the last 4 weeks only. That adds to at least a dozen I worked professionally in the last 22 years. All I can say: yeah, whatever you do in your programming language X, has been done in the past. We all stand on the shoulders of giants.
What was that quote? “Talk is cheap. Show me the code”?
To be clear, I really like Rust (oh, that I could never write C++ again). There are some astonishingly underdeveloped parts here and there [1], and I've a few pet peeves, but it's fun to use and I think it's a great step in the right direction. I'm really grateful to all the people who work on it.
[1] I just ran into https://github.com/rust-lang/rust/issues/55795, for example.
Just ignore the Rust people's comment. It gets ugly in a hurry.
As far as I can tell, the heated nature of the discussion stems from that?
Essentially language fight on the internet is just as political as any other controversial topics, if not more.