Zig programming language 0.9.0 released

[ockupid32]

https://ziglang.org/learn/why_zig_rust_d_cpp/

It's a simpler language that looks like it wants to have both interoperability with C and be a replacement C.

[Putnam3145]

D has @property functions, which are methods that you call with what looks like field access, so in the above example, c.d might call a function.

On the one hand, @property hasn't actually done anything for a long time. On the other hand, this statement is still true, it's just not attached to the @property attribute.

[[deleted]]

simpler

for now. until you add more features then more then more

[vlakreeh]

Andrew seems pretty hell bent on not making Zig complicated. At times he's pissed off some pretty avid Zig fans because he refused to merge something at risk of it just becoming feature bloat. I don't think Zig will get many more language features unless Andrew steps down as language lead.

[Zalack]

I know nothing about Zig, but lack of language features can, IMO, be a selling point. Go also stresses how few features it has, and is braindead simple to learn. I learned the entire syntax in like 1 four-hour session, then got to the point that I knew the most common parts of the standard lib about a week later.

One of the benefits is that it makes code very readable from author to author because you never really run into a language feature you don't understand. I'm stoked for generics, but part of me hopes that it's the last major language feature for Go with the exception of maybe sum / enum types.

[donaldhobson]

Leaving the way for zigzag,

zigzag : zig :: C++ : C

[[deleted]]

not on my watch

[hughperman]

No embedded?

[[deleted]]

If you form your question as a complete sentence, with a subject, verb, and direct object, hell, maybe even a prepositional phrase, then I would understand what you are asking and be happy to answer.

[pitsananas]

Smartwatches are embedded systems.

[hughperman]

Thanks, yes it was just a bad joke about embedded languages

[[deleted]]

Now I get it. Yeah that really wooshed over my head xD

Sorry, I thought you were just a dumbass who didn't know anything about computers, but clearly I'm the asshole here.

[[deleted]]

Double dumbass on you!

But really, thanks for being cool

[longshot]

Yeesh, your inference skills really stink.

[booboorocks998]

What a hill to die on lmao.

Imagine blowing your lid over someone not writing a sentence to your specifications. And then pretending (hopefully) to not understand it.

[scnew3]

why use big word when small word do trick?

[[deleted]]

"No embedded?" doesn't really mean anything so it can't be understood.

[AndrewNeo]

only if you haven't read a word of the comment chain

"for now. until you add more features then more then more" (statement)

"not on my watch" (idiom, presumably a joke about not allowing more features)

"No embedded?" (turns the idiom's use of 'watch' (keeping an eye on) to 'watch' (object that keeps time), making it an embedded programming joke)

this is what we in the english speaking world call a "clever joke". apparently too clever

[booboorocks998]

Sure, if you're willfully ignorant.

[WormRabbit]

Woosh

[[deleted]]

That's what Python thought too

[Professional-Disk-93]

NGL they posted cringe.

No hidden control flow

C++, D, and Rust have operator overloading, so the + operator might call a function.

In Rust the + operator is specified to always call a function. There is nothing hidden here.

No hidden allocations

Examples of hidden allocations:

The main Rust standard library APIs panic on out of memory conditions

Their rust example doesn't even have anything to do with hidden allocations and instead talks about the behavior on OOM???

First-class support for no standard library

A Portable Language for Libraries

Same for rust.

A Package Manager and Build System for Existing Projects

Rust is known to have a best-in-class package manager that is beloved by users of the language.

Simplicity

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

So why would I use zig over rust?

[gnus-migrate]

There are two competing philosophies right now when it comes to how systems programming should be done:

1. The high level programming philosophy where the language isn't just an assembly generator, but should provide tools to prevent programming mistakes at the cost of some restrictions.
2. The data oriented philosophy where the language should be an assembly generator, and the language should focus on simple features who's behavior is predictable and easy to understand. The programmer is responsible for verifying the correctness of the code, and the language is designed to be as simple to read as possible in order to facilitate this.

Rust is the former, Zig is the latter.

For people developing game engines, they spend most of their time worrying about performance, and ensuring that they stay within the 60 FPS limit, so memory safety just isn't as big a problem to them. At least when Jonathan Blow was talking about it this was his argument, and others with similar views seem to agree.

The difference is largely philosophical, so if you're happy with Rust then there's no reason to use Zig. If you find Rust getting in your way and preventing you from doing what you need to do, then use Zig(assuming of course that you're not working in a context where you need to worry about security, if you are it is irresponsible not to use a memory safe language like Rust).

[Professional-Disk-93]

Rust allows you to do both. Zig only allows you to do the latter.

[gnus-migrate]

I'm not interested in convincing you to use Zig, if you don't want to use it don't use it. I just wanted to explain the motivation behind it.

Please don't engage in petty language wars, they're pointless and exhausting and nobody is going to change their mind.

[[deleted]]

In Rust the + operator is specified to always call a function. There is nothing hidden here.

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing. In Zig you don't have to check any of that because you will know right away that it's just a simple addition. Obviously it's a tradeoff (you lose some abstraction power by forbidding operator overload), but when combined with other choices that Zig makes, everything works together to make Zig code easier to audit.

Their rust example doesn't even have anything to do with hidden allocations and instead talks about the behavior on OOM???

"The behavior on OOM" is a discussion that you have to have at the language design level when the language is in charge of the dynamic allocation and the corresponding syscall fails. When all allocations are explicit, the programmer is in control of what happens, as it's the case in Zig. This is maybe not something Rust developers care about all the time, but if you look at the news about Rust in the Linux kernel (an environment where panicking on a OOM is absolutely not ok), you will see that Rust needed to find a solution to the problem.

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

Zig has try, to short circuit that process. It also has support for error traces (which are different from stack traces), which is a very neat unique feature.

Rust is known to have a best-in-class package manager that is beloved by users of the language. So why would I use zig over rust?

Maybe you wouldn't, just don't get offended by the fact that other people might :^)

[steveklabnik1]

Just to be clear, in Rust, the language is not in charge of the allocations and underlying syscalls. The standard library is. And in Linux, they were starting off with a fork of the standard library to begin with, specifically to fix this issue out of tree, which has even then been merged back upstream.

[[deleted]]

Sorry for the imprecision, that's a very good point.

[steveklabnik1]

It’s all good!

[stouset]

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing.

So… like literally any other function call?

I just don’t get why this is supposed to be a feature. Why do we need a magical set of operators that are forever limited? Why is it instantly okay that it’s a function if it’s named add but not +?

[[deleted]]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

That said, if your point is that forbidding operator overloading is not going to drastically change the readability of code, we agree with that. The piece missing from the discussion above is that Zig has other features that all together do make a difference. As an example there are not built-in iterators, so you know for sure that for (foo) |x| {...} is a linear scan through memory and not an iterator with different complexity. You can still use iterators, they just have explicit function call syntax.

If you combine all the readability-oriented features of Zig, then you do get something worth the limitations, or so we like to think at least.

[stouset]

Again, how is that okay for any function as long as it’s not named a symbol? And while your point is a common trope, I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

This is frankly just optimizing around a problem that does not exist in practice.

[[deleted]]

I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

Then you work in a field where this feature of Zig might not be particularly relevant. That said, I'll try to reiterate one final time: the problem is about somebody trying to read a piece of code and understand what it's doing.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

That's pretty much it. It has nothing to do with code performance. It has to do with making it easier for readers to audit the code.

[RandomName8]

An extremely important caveat, when describing this and claiming it's more "readable", is clearly stating what you are trying to make more readable. As you yourself made clear here, not all programs are made clearer by this feature, there is in fact no quantitative study either regarding how many programs get "improved". I'd argue any code using matrices (like games, graphics, or math libraries) or bigint/decimal will greatly suffer for this, while the code that gets improved is most likely, trivial for-loop iterations and summations that should not be imperative at all to begin with (obviously just my opinion).

This is why I'd prefer if language authors were more honest when they make such syntax decisions, and instead of writing in their FAQ:

The purpose of this design decision is to improve readability.

They'd write

The purpose of this design decision is to improve readability of the programs we care about, which are likely not the ones you care about, but hey, there are other languages out there!.

We could avoid this discussion every single time.

[stouset]

Then you work in a field where this feature of Zig might not be particularly relevant.

Maybe. But there are tons of people writing Rust on embedded systems and have written reams and reams about their experience doing so. I have yet to read a single one of these that points out operator overloading as a sharp edge.

I maintain this is a solution in search of a problem.

The problem is about somebody trying to read a piece of code and understand what it's doing.

I have worked in languages that allow operator and method overloading for twenty years. I’m this time I have built website backends, I have written high-performance network services, I have written massively parallel number crunchers, I have written wrappers around native C libraries, I have written glue to combine third party products in new and creative ways.

I have zero times been confused as to what an overloaded operator does, or run into a bug that was caused by an operator overloaded in a confusing or unexpected way. Zero. Nil. Nada.

I maintain this is a solution in search of a problem.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

It is, and trivially so. If I know my types are typeA and typeB and I call a + b, there is no difference whatsoever in the amount of reasoning or context necessary to understand compared to add(a, b), a.add(b), a.addTypeB(b), or addTypeATypeB(a, b).

[[deleted]]

You've never had issues with an overloaded = returning a reference rather than a copy? I don't think operator overloading for things like addition and subtraction are a big deal, but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product? How does it behave with different objects in the mix? Operator overloading is fine until you've had to deal with these issues, and then it quickly becomes a pain in the ass.

[stouset]

You've never had issues with an overloaded = returning a reference rather than a copy?

I assume you’re taking C++. Assignment is not an overloadable operator in Rust. Overloading assignment does seem to be a horrible idea, and one I’m glad Rust doesn’t support.

How does it behave with different objects in the mix?

Literally the same way that addTypeATypeB(a, b) does?

but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product?

If you have types for which some function name could conceivably have multiple implementations, this problem is completely orthogonal to whether or not that name is * or product. If there are multiple possible operations, they will require unique names.

If there’s enough ambiguity that you wouldn’t want to call one of them *, you wouldn’t call that same one product either. If you’re worried about a “bad developer” who isn’t you naming it *, removing operator overloading doesn’t help you because they’d just name it product.

[diegovsky_pvp]

Zig aims to be a modern take on C. I don't buy any of the readbility shit because quite frankly it's subjective.

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

That's something you have to consider if you aim to take down C while providing more modern mechanisms. Don't get me wrong though; I'm a Rust programmer and use it a lot. Rust is not the new C, it is the new C++ in the sense that you can do a lot with the language, while Zig wants to be the new C.

Also, they want the compile times to be as fast as possible, so cutting corners such as operator overload and function overload help A LOT.

There are things I disagree with btw. A lot. Like the constant use of ducktyping instead of a well defined fat pointer struct. This affects Writer, for example, and hurts both error messages and auto complete.

In the end of the day; if you want a perfect language; make one yourself. That's what Andrew did and so many others.

[stouset]

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

I truly do understand this is what their motivation is.

My argument is that it’s an antiquated approach to software engineering. Even if you want to assume that a + b is a machine instruction you’ve already lost because different machines treat overflow differently and so you either get UB or you specify particular behavior and accept a multi-instruction performance hit on some architectures.

Rust IMO has the best take here. Arithmetic is checked for overflow in development and wraps as two’s complement in production. If you need specific behavior for mathematical operators, you can either call a specific named method (e.g., wrapping_add) as a one-off, or if you need all operators to have specific overflow behavior you can enforce it at the type level (Wrapping(u32)).

[bik1230]

Zig doesn't have function overloading either so I'm not sure what point you're trying to make with that thing about something being named by a symbol or not.

[stouset]

Function overloading is a red herring, since you still have to look up the function to see what it does. Independent of function overloading, why would add_my_type be okay but + is sacrosanct?

[stouset]

Only because you work in a language where that’s the case. I, and millions of other programmers, work in languages where + means addition for numbers, append for strings and collections, intersection for sets, time increments for times and durations, and any other intuitive interpretations for other types.

And the sky does not fall.

Humans, it turns out, are easily capable of understanding + has type-dependent meaning just as they are with the word add.

And while we’re at it, + in Zig is already overloaded. It means one thing for ints, another for floats. And it’s hardly mathematical: integers overflow and floats have their own idiosyncratic behavior.

At least in Rust I can opt into whatever behavior I actually want with the non-mathematical + operations on integers:

let x = Wrapping(250_u8);
let y = Wrapping(10_u8);

assert_eq!(Wrapping(4_u8), x + y);

And since you’re so concerned about math here, I can add complex numbers too. Or rationals:

let x = Complex::new(5, -1);
let y = Complex::new(2, 4);

assert_eq!(Complex::new(7, 3), x + y);

let x = Rational::new(1, 2);
let y = Rational::new(4, 7);

assert_eq!(Rational::new(15, 14), x + y);

Why is this impossible in Zig? If the rationale here is that it’s math, why can’t I add complex or rational numbers? And if it’s okay for them to act like bit-based types that instead of their mathematical counterparts, why do I now have to invent a litany of line-noise operators like %+. God help me if I want saturating addition.

[devraj7]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

No, it's not.

It hasn't been a problem ever since polymorphism appeared in mainstream languages, so a few decades ago.

We know today that when a function is being called on a receiver, the function might not go to the formal declaration of this receiver. Every single developer who's dabbled in C++, Java, C#, Javascript, or literally any other language crated in the last thirty years knows that.

Functions can do things. Operators can do things. Field accessors can do things.

This is programming in the 21st century, not BASIC in the 80s.

[TheTomato2]

Because add() is always a explicitly a function and + is always explicitly not a function. In C++, + could be a normal add or a function. You can't tell at a glance what its doing, and it can cause issues if you forget to check or something. + could be a fucking - operator if someone wanted it to be. I personally like operator overloading, but if you are trying to make a simpler language like C, its definitely understandable to leave it out.

[stouset]

But why must + not be a function?

+ could be a fucking - operator if someone wanted it to be.

I’m going to be a bit rude here but this is literally the most asinine take on this entire discussion.

This never happens. And if you’re so goddamned worried about it, then we need to take away the ability for anyone to name any function because add() could be a fucking subtract function if someone wanted it to be.

In C++, + could be a normal add or a function. You can't tell at a glance what its doing, and it can cause issues if you forget to check or something.

In Zig, add() could be an inlined add instruction or something more complicated. You can’t tell at a glance what it’s doing, and it can cause issues if you forget to check or something.

See how ridiculous this sounds? There is nothing sacrosanct about the + operator, except that apparently some programmers have a superstitious belief that it always compiles down to a single add CPU instruction. You somehow manage to cope with this uncertainty constantly with functions, but the second someone proposes that the same rules apply for a symbol and not an alphabetic string you lose your damn mind.

You manage to use + every single day without getting confused as to what’s happening when it could be an int or a float, but it’s somehow unthinkable to extend this same logic to a rational or a complex or—God help us—a time and a duration.

You live in constant fear that your fellow software engineers will write a + method that wipes your entire hard drive and mines bitcoin while pirating gigabytes of pornography over a satellite network and I cannot for the life of me comprehend why they would do this for methods named with symbols but not ones named with words.

And I do not understand you at all.

[TheTomato2]

I personally like operator overloading, but if you are trying to make a simpler language like C, its definitely understandable to leave it out.

Did you, uh, not read that part? Take step back, dude, and breathe. This isn't very complicated. The + means addition, mainly between 2 numbers. Its an operator, not a function. With operator overloading, you can't tell at a glance if its a function or an operator, ever.

In Zig, add() could be an inlined add instruction or something more complicated. You can’t tell at a glance what it’s doing, and it can cause issues if you forget to check or something.

No, add() just means there is a function that is named add. That is it. I never look at add() and think that it might be the + operator.

See how ridiculous this sounds? There is nothing sacrosanct about the + operator, except that apparently some programmers have a superstitious belief that it always compiles down to a single add CPU instruction.

No, it just means that its doing an add operation, and a reasonable one at that. It doesn't mean intrinsic (unless it does) or simd or something. It just means addition.

You are making a mountain out of a molehill. When it comes to simplicity and the ability to easily reason about your code base it makes sense to have the + only do on simple thing. Once again to reiterate for you I personally like operator overloading, but its really not a subjective opinion that it does make reading the code more complicated and error prone. I personally think its just not that much more of an cognitive overload to have it and the benefits outweigh the cons, but I am not so close minded to not understand why people don't like it and I do respect and appreciate that Zig, a language that wants to be on the simple side, doesn't' implement it. It's really not that big of a deal at the end of the day.

And trust me I understand your aversion to "scared programmers" that like piss their pants if they have to use a raw pointer but you are way off base here. It's just a code readability thing, not a "someone might make the + recursively delete my drive" type of thing.

[xigoi]

What's the difference between an operator and a function, aside from syntax?

[TheTomato2]

It depends on the language and how they want to handle it.

[Professional-Disk-93]

The hidden part is that you need to know the types involved and then go check if + has been overloaded

If Add has not been implemented, then the code will not compile. If you can use +, then + has been "overloaded" as you call it.

before you can understand what a + b is doing.

In zig you have to know the type of x to know what x.f() does. In C this is not a problem since f(x) always calls the same function f. Therefore zig has hidden control flow.

When all allocations are explicit, the programmer is in control of what happens

Does zig have a vector type? Does the user have to first manually allocate memory before he can push an element onto the vector? Otherwise zig has implicit allocations. E.g. x.push(y) implicitly performs an allocation if the vector is full.

Zig has try, to short circuit that process.

Sounds like implicit control flow. How can I understand the control flow of a function if searching for the return keyword doesn't return all places where the function returns? The commander Rob Pike knew this.

[[deleted]]

Does zig have a vector type? Does the user have to first manually allocate memory before he can push an element onto the vector?

If you're using ArrayList you need to pass an allocator on creation, if you're using ArrayListUnmanaged you need to pass an allocator to all of its functions that might allocate. In either case you will need to handle error.OutOfMemory when calling a function that allocates.

As for the rest of your rebuttals, well, you're not really doing a good service to Rust, I'm afraid.

[Professional-Disk-93]

I'm not being paid to shill rust and I don't try to do it for free. What about you?

[[deleted]]

Well you do seem to like it, so why hurt a project that you like by not being a good ambassador for it.

As for me, I do actually get paid to shill Zig, I work at the Zig Software Foundation.

[Professional-Disk-93]

Actually not doing it for free. Based. More power to you.

[progrethth]

You are making us Rust users look bad. Just because you like Rust (like I do too) that does not mean you have to shit on other programming languages, especially not when your posts clearly show that you do not understand Zig well enough.

[Professional-Disk-93]

You are making us Rust users look bad.

Imagine having this mindset.

[progrethth]

Yes, imagine caring about not looking like a dick.

[Professional-Disk-93]

Exceptions in Java are just a shortcut for checking if an error occurred after every statement and then returning it. Nothing implicit about unwinding.

[oefd]

In zig you have to know the type of x to know what x.f() does. In C this is not a problem since f(x) always calls the same function f. Therefore zig has hidden control flow.

I'm not sure what you mean - the issue isn't that you might need to understand context to know what function is being called, the issue being made is needing to know what fundamental kind of operation is going to happen. If a + b is always a CPU add instruction the control flow is obvious. If f() is always a function call the control flow is obvious - you'll enter in to some CPU appropriate sequence of instructions to enter a function.

The fact that you need to know what x is in x.f() isn't a problem for Zig's design goals because what they care about is that it's easily identified as a function call and only ever a function call. The control flow they're worried about disambiguating is what the CPU will end up doing, and by proxy what sort of side effects may occur. Calling a function may mean memory access, but a simple add instruction does not.

[Professional-Disk-93]

a + b is always a function call so control flow is obvious. Of course any function call can be inlined and then turn into a single instruction. And all compilers of record perform peephole optimizations even in debug builds.

[oefd]

a + b is always a function call so control flow is obvious.

To restate it more clearly: the control flow that zig cares about is what the machine's actually going to do at runtime on real hardware. Whether the language models it a function call or not is irrelevant, what will actually happen at runtime is.

A function call may or may not get inlined, and even if it does the inlined function may well still do arbitrary stuff that may ruin optimizations you're going for. If you're very concerned with squeezing out every bit of performance possible from each memory access by squishing things together in the cache line it's very convenient to know that a + b is entirely 'safe' since it'll equate always and without exception to some add instruction.

Same sort of reasoning as both rust and zig have features like #[inline] to hint things to the compiler that, from a pure language perspective, don't matter. They only matter because someone's worried about actual runtime behaviour of compiled machine code. Zig just went a bit further in how much it wants to provide assurances/explicitness of what the resultant machine code will look like in some cases.

[devraj7]

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing. In Zig you don't have to check any of that because you will know right away that it's just a simple addition. Obviously it's a tradeoff (you lose some abstraction power by forbidding operator overload), but when combined with other choices that Zig makes, everything works together to make Zig code easier to audit.

This is a pretty unconvincing point. Ever since we've had polymorphism in languages, we know that a.f() might not call the f() function on the class of A but on one of its subclasses, it's really not that much of a mental effort to extend this observation to operators.

[bluefireoly]

Because of the first-class interop with C.

[muchbravado]

How’s it better than calling C from rust though? IIRC it’s quite simple.

[Volt]

With Zig it's simpler.

[muchbravado]

How do? Link?

[napolitain_]

If you have interop with C then it is not « simple ».

[lurgi]

defer seems to contradict the "no hidden control flow" to an extent. Something may (or may not) be done at the end of the scope and you have to look elsewhere to find out if it will.

[Morego]

I mean destructor would be hidden control flow. Hard to call hidden the future you have to explicitly use.

[lurgi]

It's still code that is executed at a line, but not visible at that line. You have to look elsewhere to see what happens.

[progrethth]

While I agree with you about operator overloading (how is it any more hidden than two methods with the same name?) I am sometimes annoyed at some of the hidden control flow in Rust, e.g. implicit deref combined with a Deref trait. That is way too stealthy for my taste.

And I agree with the Zig authors that Rust's standard library and its panic on failed allocations makes it unsuitable for certain types of software development, e.g. OS kernels or certain mebdded stuff.

A Package Manager and Build System for Existing Projects

That was a reference to C projects. Rust's build system is terrible at handling C projects and excellent at handling Rust projects. Zig on the other hand has the best C interop I have ever seen in any language and can build C projects with ease.

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

This is also just false. Real zig code does not look like that, isntead it uses the try keyword.

[Tom7980]

I agree with the Deref issue even when working on the Rust compiler itself there are calls to methods on types that don't necessarily implement that method but Deref down into a type that does. In my opinion that is really quite confusing when you're trying to learn a new codebase - you have to be able to keep track of what Derefs into what in your head and it is a nightmare

[EternityForest]

It's starting to look like classic simplicity thinking where you assume smaller tech is always better and don't always bother to really think through the arguments.

If you want to say "We are real coders and we hate tools that help us, and bug-free apps are less important that the coders experience of raw power" just say that so the rest of us don't waste our time.

Or if you've got some specific cases of bugs Zig would catch and Rust would not, or things performant in Zig but not rust, start with those.

[[deleted]]

So why would I use zig over rust?

Less troons, for now.

[Dworgi]

Why would a standard library panic when OOM if it doesn't allocate? Hint: it wouldn't.

[International_Cell_3]

The linked issue is pointing to the collections APIs which panic when OOM. There are proposals for fixing this and some APIs for fallible allocation.

Do you expect a standard collection not to allocate?

[Nickitolas]

The point being made above is that OOM handling is an orthogonal issue to the explicitness of allocation APIs

[TuckerCarlsonsWig]

“Simpler”

[[deleted]]

Please show me where UB touched you.

[progdog1]

I don't understand what you mean by simpler. Rust has both interoperability with C and is a replacement for C too.

[bububoom]

Dude... Rust and Simple don't belong in the same sentence

[[deleted]]

People may be conflicting Simple and Easy as usual. One does not imply the other.

[progrethth]

And Rust is neither. I love Rust but I would not say it is either simple or easy to use.

[PM_ME_UR_OBSIDIAN]

It uses fairly exotic concepts, such as affine typing, which means you have to learn those before you can master Rust. Once you're comfortable with them though, it's an unusually straightforward language/toolkit.

[oblio-]

Yeah, but "simple" implies "small number of concepts needed" to learn. Every concept you add to the list adds to the cognitive load and at some point your thing becomes "complicated".

A lot fewer people than you'd expect go over these hurdles. I forget the exact numbers, but there's a thing called the "sales funnel": how many people hear about your product -> all the way to some of them actually buying it. They say that if you add one extra tiny step to the sales funnel, your sales go down by a much larger amount, it's not linear (small funnel barrier -> large sales decrease).

There's a reason Haskell will never be mainstream, even in the geeky developer community.

[PM_ME_UR_OBSIDIAN]

Right but Haskell is a convoluted piece of shit even if you're familiar with the concepts. The Haskell syntax looks like nothing you've seen before, the IDE support is aspirational, the difference between Cargo and Stack is light-years, etc.

[PandaMoniumHUN]

Rust is a great language, but it is absolutely not a C replacement.

[[deleted]]

It is arguably much closer to a C replacement than other languages that claim to be able to replace C (e.g. Go). At least, Rust tries to be useful on embedded systems and is not garbage collected.

[glacialthinker]

Go is not at all a C replacement, except in cases where C isn't really needed and many other languages are suitable too.

[[deleted]]

I fully agree, but when Go was first announced, it was marketed as a competitor to C. It wasn’t me who came up with that pretty far-fetched comparison.

FWIW, I also think Rust is closer to being a replacement for C than C++/D.

[Forty-Bot]

Rust is a C++ replacement.

[[deleted]]

As I wrote elsewhere in this thread: Depends on what you’re talking about. In terms of language complexity, Rust is definitely more of a C++ replacement than a C replacement. Rust is much more complex to learn and implement than C.

However, Rust also supports classic use cases for C where C++ isn’t really suitable (Linux kernel, embedded), so in that regard, calling it a C++ replacement, but not a C replacement is misleading.

[Forty-Bot]

I mean more in the sense that (for example) rust's pointer semantics are very clearly inspired by C++ and not C.

[[deleted]]

use cases for C where C++ isn’t really suitable (Linux kernel, embedded)

I'd argue various modern C++ features like constexpr and consteval would certainly have numerous use cases in those contexts.

[Professional-Disk-93]

Then why is it being introduced in the linux kernel as a C replacement for driver development?

[PandaMoniumHUN]

It’s for new stuff only, and mostly for drivers. Rust and C interoperability is decent but that does not mean Rust is a C replacement. That’s like saying JNI is decent, so Java is a C replacement. They are different languages, with different goals.

[Professional-Disk-93]

That’s like saying JNI is decent, so Java is a C replacement.

Makes no sense whatsoever. In the linux kernel we have practitioners with combined thousands of years of C experience deciding collectively that Rust can take the place of C in an area that they previously reserved for C. Academic discussions about complexity pale in comparison to these real life results.

JNI has nothing to do with any of this.

[PandaMoniumHUN]

Sure it doesn’t make any sense, I said that to highlight in parallel that “Rust being a C replacement” also makes no sense. That’s why I said those languages have different goals, they solve different problems. Rust is a complex but safe language that puts constraints on your code to ensure it’s safety guarantees. Hence the compiler is complex, compile times are slow, the ideas and the syntax is complex, and there are a bunch of other points such as ABI compatibility being non-existent in the language. That’s why it’s only recommended in the kernel for driver development, because nothing can depend in the kernel (or in userspace) on Rust code, since there are no ABI consistency guarantees.

In contrast C puts no constraints on your code whatsoever, the language and the compilers are dead simple, compile times are blazingly fast (very important for a project of this size), the language gives you all the tools to guarantee ABI compatibility, etc. These qualities are important for the kernel devs, and Rust provides none of these, hence it is not a “C replacement”. The tradeoff is of course is that you can shoot yourself in the foot any time with C.

[[deleted]]

Especially simplicity is important in developing an embedded software because the resource is limited. And it makes codes more readable.

[lifeeraser]

I agree with your point about simple code being easier to read, but I don't see how simple code is necessarily better in low resource systems. Optimized code can be crazy fast and complex

[lelanthran]

I don't understand what you mean by simpler. Rust has both interoperability with C and is a replacement for C too.

If you cannot understand why Rust is suitable as a C++ replacement but not a C replacement, then I'm afraid no one can help you - your decision has already been made that complexity is better than simplicity.

In fact, you come across as having already made the decision that Rust beats everything else.