To be fair, he said the Rust community has little real-world respect. Linux considering the inclusion of Rust on technical merit is unrelated to the bunch of yahoos who have made a certain technology their identity.
I have a hard time believing that as well. What is the definition of community? Is it the RIIR fanboys? Is it /r/rust? Is it users.rust-lang.org?
Each of these subcommunities is quite sizable, and the last two definitely make an effort to squash RIIR-type overzealotry.
If you're still going to define the Rust community by the latter, it would be fair game to define the C/C++ community by the very vocal people who insist that there's nothing wrong with the lack of memory-safety in those languages.
> Is it the RIIR fanboys? Is it /r/rust? Is it users.rust-lang.org?
Does it matter? Which one of those do you think has the respect of the real world? I'd say none of them. Frankly, I have never heard of these communities (if we are to call them that), and if I had to guess I'd say their only claim to fame is writing silly comments on the internet, which certainly doesn't garner respect even on the internet, let alone in the real world.
> the last two definitely make an effort to squash RIIR-type overzealotry.
A further indication of not having respect. "Quiet you, you're making me look bad" is not something someone who already has respect is concerned with. Maybe someone seeking respect.
> Which one of those do you think has the respect of the real world?
Judging by the direction of C++ apologists these days - probably the people that promote Rust as a better LLVM-compiled language than it's alternatives? Renouncing them would kinda mean renouncing the concept of IR as a whole, which coincidentally seems to be the saving grace of the C programming language too. Without intermediate representation, both languages are unfit for commercial or optimization-sensitive applications.
The entire world of compiled languages has always been a ravenous and ego-fuelled madhouse. This recent attempt to slough off the discourse onto the Rust community is stupid, because if we dig down to the compiler level we're literally arguing over semantics. If you wouldn't call LLVM or Valgrind advocates "overzealous" then you probably don't have a rational reason to say it to Rust advocates either. And I just say that as a guy who wants my kernel to not suck balls.
You've precisely pinpointed the nuance that seems to elude so many: the distinction between the technical merits of Rust and the often overzealous antics of its most ardent adherents.
It's amusing how some conflate corporate adoption with universal admiration for a community's demeanor. Perhaps if more could separate the tool from its torchbearers, we'd have fewer misguided defenses and more meaningful discourse.
Meanwhile it is already shipping on Android Linux regardless of upstream, while Microsoft ships it on Windows, is making use of TockOS for firmware like on Pluton security CPU.
This is wrong. There is a lot of respect for rust, being used by Microsoft, Google, etc. (and i'd argue its a bad thing because it's stifling innovation and sucking up a lot of air for people who want temporal memory safety without all the... technical baggage that rust cones with)
This understates what Zig has accomplished. The GeneralPurposeAllocator used in Debug or ReleaseSafe modes will detect use-after-free, double-free, and memory leaks. This isn't a second tool and a bunch of flags which you have to set up and use, it's literally the default choice for memory allocation.
Zig also has bounds checking, and is null safe: these are important ingredients in spacial and temporal memory safety, respectively. The bounds checks can be turned off, but length is part of an array type, and slices include the runtime length, so it's still doing much better than the classic degrade-to-pointer you get with C (C++ doesn't use arrays much but it shares the problem in a more complex way). Runtime safety can be turned on and off on a per-block basis, which in the right hands gives fine-grained control.
Which isn't to say you're wrong: in Zig, you manage memory, and that means that memory bugs are not only possible, but they will happen and must be found and corrected in testing. But saying it's "just like" C and C++ is pushing it imho.
Zig is aiming to make memory bugs as easy or hard to detect as ordinary logic bugs, the kind of thing which it's tractable to detect and correct for with rigorous testing. It also has much better support for arenas than any other language, since allocators are explicitly passed: this can conglomerate potential memory bugs into one point in a program's execution. There are more features like this than I can feasibly fit into a Hacker News post.
Saying that Zig is not a memory-safe language is just correct. But it's possible to write memory-safe code in Zig, to say otherwise would be like claiming that you can't traverse a tree in Python because the language won't help the traversal code be bug-free by construction.
The leading example is TigerBeetle, which chose an architecture which statically allocates all memory on load. This prohibits any temporal memory safety problems, leaving only spacial memory bugs as an option. TigerBeetle insists on no bugs at all, and is willing to do the enormous amount of testing which is necessary to get any amount of confidence that the goal is accomplished.
There's a place for a language with manual memory management, which instead focuses on easing the extreme pain and pointless difficulty of writing memory-correct code in C. Zig is doing a great job of becoming that language.
Lets start with controlled types (RAII), generics, type driven programming, tasks and monitors for concurrency and parallel programming, certification profiles for high integrity computing (where people die when bugs happen), formal proofs in the type system, contracts.
My point is not that use-after-free or other resource allocation problems do not exist. The point is that in vanilla C any solution one might come up with is too fragile. Reasonable patterns require a very, very steady hand to work (which means it doesn't scale).
C++ came up with a few consistent language-level RAII-based solutions to the problem. Rust came up with a single big consistent language-level approach. Both Rust and C++ insist on using it in all cases.
What Zig does, and which I like, is that it refocuses the language on tools that make it easy to codify the right thing without making it a cornerstone of the language itself. But without introducing the kind of complexity C++ (and Rust to an extent) is famous for.
At its core, it takes the Modula-2 type system from 1978 and makes is appealing to C devs, with sprinkles of compile time programming on top, not as powerful as Lisp macros.
Much better than raw C, but still it leaves things to be desired in the context of safe systems programming.
Well, Rust makes one BIG bet, and then keeps adding everything else, just like C++ keeps doing.
The thing is: people don't want everything.
For the kind of things that are expected to be build in C and C-inspired languages it just doesn't make sense to have Lisp-like macros, or 2 flavours of macros like in Rust, or the accidental kind of metaprogramming C++ is famous for.
Comptime does the job just fine here, replacing the unpredictable macro mess.
Yes and if assholes like you keep spreading FUD the likelihood of this stuff getting built as add-ons decreases. Your behavior in this thread exactly makes my point about how rust sucks the atmosphere out of the discourse, so thank you I guess.
We have to ban accounts that post like this. I don't want to ban you, so if you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules, we'd appreciate it. That means thoughtful, respectful conversation, regardless of how wrong others are or you feel they are.
Edit: I took a look at your recent comments and you don't seem to be in the habit of doing things like this (that's good!) so it should be easy to fix.
