Hacker News Reader

Comment by kprotty | Hacker News Reader

I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1].

These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies.

[0]: https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+a...

[1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro...

View on HN

I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024.

Have you tried rust? how does it compared to zig?

* just asking

Zig is a modern C,

Rust is a modern C++/OCaml

So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

Time to start zig++

Seriously asking, where Go sits in this categorization?

It's also a modern C.

If you enjoy C and wish it was less verbose and more modern, try Go.

Thanks. I write some Go, and feel the same about it. I really enjoy it actually.

Maybe I'll jump to Zig as a side-gig (ha, it rhymes), but I still can't motivate myself to play with Rust. I'm happy with C++ on that regard.

Maybe gccrs will change that, IDK, yet.

Go has a garbage collector though. This makes it unsuitable for many use cases where you could have used C or C++ in the past. Rust and Zig don't have a GC, so they are able to fill this role.

GC is a showstopper for my day job (hard realtime industrial machine control/robotics), but would also be unwanted for other use cases where worst case latency is important, such as realtime audio/video processing, games (where you don't want stutter, remember Minecraft in Java?), servers where tail latency matters a lot, etc.

> GC is a showstopper for my day job (hard realtime industrial machine control/robotics)

Which is a very niche use case to begin with, isn't it? It doesn't really contradict what the parent comment stated about Go feeling like modern C (with a boehm gc included if you will). We're using it this way and it feels just fine. I'd be happy to see parts of our C codebase rewritten in Go, but since that code is security sensitive and has already been through a number of security reviews there's little motivation to do so.

> Which is a very niche use case to begin with, isn't it?

My specific use case is yes, but there are a ton of microcontrollers running realtime tasks all around us: brakes in cars, washing machine controllers, PID loops to regulate fans in your computer, ...

Embedded systems in general are far more common than "normal" computers, and many of them have varying levels of realtime requirements. Don't believe me? Every classical computer or phone will contain multiple microcontrollers, such as an SSD controller, a fan controller, wifi module, cellular baseband processor, ethernet NIC, etc. Depending on the exact specs of your device of course. Each SOC, CPU or GPU will contain multiple hidden helper cores that effectively run as embedded systems (Intel ME, AMD PSP, thermal management, and more). Add to that all the appliances, cars, toys, IOT things, smartcards, etc all around us.

No, I don't think it is niche. Fewer people may work on these, but they run in far more places.

See TamaGo, used to write firmware in Go, being shipped in production.

Not familiar with it, but reading the github page it isn't clear how it deals with GC. Do you happen to know?

Some embedded use cases would be fine with a GC (MicroPython is also a thing after all). Some want deterministic deallocation. Some want no dynamic allocator at all. From what I have seen, far more products are in the latter two categories. While many hobby projects fall into the first two categories. That is of course a broad generalization, but there is some truth to it.

Many products want to avoid allocation entirely either because of the realtime properties, or because they are cost sensitive and it is worth spending a little bit extra dev effort to be able to save an Euro or two and use a cheaper microcontroller where the allocator overhead won't fit (either the code in flash, or just the bookkeeping in RAM).

Yes, just like with real time Java for embedded targets from PTC and Aicas, it is its own implementation with another GC algorithm, additionally there are runtime APIs for regions/arenas.

Here is the commercial product for which it was designed,

https://reversec.com/usb-armory

A presentation from 2024,

https://www.osfc.io/2024/talks/tamago-bare-metal-go-for-arm-...

Not everybody is writing web apps.

You can also see it differently: If the language dictates a 4x increase in memory or CPU usage, you have set a much closer deadline before you need to upgrade the machine or rearchitect your code to become a distributed system by a factor 4 as well.

Previously, delivering a system (likely in C++) that consumed factor 4 fewer resources was an effort that cost developer time at a much higher factor, especially if you had uptime requirements. With Rust and similar low-overhead languages, the ratio changes drastically. It is much cheaper to deliver high-performance solutions that scale to the full capabilities of the hardware.

Go is modern Java, at least based on the main area of usage: server infrastructure and backend services.

i wonder what makes go more modern than java, in terms of features.

The tooling and dependency management probably

I still don't understand how they managed to make a build system as bad as Gradle. It's like they tried to make it as horrible as possible to use.

Yes, every time I fire up an old Android project it needs to download 500MB just for gradle upgrades. It's nuts.

Tbh Go is also really nice for various local tools where you don’t want something as complex as C++ but also don’t want to depend on the full C# runtime (or large bundles when self-contained), or the same with Java.

With Wails it’s also a low friction way to build desktop software (using the heretical web tech that people often reach for, even for this use case), though there are a few GUI frameworks as well.

Either way, self contained executables that are easy to make and during development give you a rich standard library and not too hard of a language to use go a long way!

Go is modern/faster Python.

- It was explicitly intended to "feel dynamically-typed"

- Tries to live by the zen of Python (more than Python itself!)

- Was built during the time it was fashionable to use Python for the kinds of systems it was designed for, with Google thinking at the time that they would benefit from moving their C++ systems to that model if they could avoid incurring the performance problems associated with Python. Guido Van Rossum was also employed at Google during this time. They were invested in that sort of direction.

- Often reads just like Python (when one hasn't gone deep down the rabbit hole of all the crazy Python features)

Nowhere, or wherever C# would sit. Go is a high level managed language.

Go is a language which sits perfectly where using garbage collection is no problem with ya.

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit?

I know, timelines not matching up, etc.

Definitely not. Rust gives you a tangible benefit in terms of correctness. It's such a valuable benefit that it outweighs the burden of incorporating a new language in the kernel, with all that comes with it.

Zig offers no such thing. It would be a like-for-like replacement of an unsafe old language with an unsafe new one. May even be a better language, but that's not enough reason to overcome the burden.

actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker

https://github.com/ityonemo/clr

"More safety than C" is an incredibly low bar. These are hygiene features, which is great, but Rust offers a paradigm shift. It's an entirely different ballpark.

negative. For example bounds checking is turned on by default in Zig, which prevents classes of overflow safety errors.

I don't think you've necessarily understood the scope and impact of the borrow checker. Bounds checking is just a sane default (hygiene), not a game changer.

I mean, I'm the author of this?

https://github.com/ityonemo/clr

so yes, I understand that it's important. It doesn't need to be in the compiler though? I think it's likely the case that you also don't need to have annotations littering the language.

I wish you good luck! Successive attempts to achieve similar levels of analysis without annotations have failed in the C++ space, but I look forward to reading your results.

yeah afaik you cant easily intercept c++ at a meaningful IR in the same way as you can zig. Zig's AIR is almost perfect for this kind of thing.

And “if you enjoy C++/if you enjoy C” are gross oversimplifications.

Memory safety by default in kernel sounds like a good idea :). However I don't think that C is being _replaced_ by Rust code, it's rather that more independent parts that don't need to deeply integrate with the existing C constructs can be written in a memory safe language, and IMO that's a fine tradeoff

I believe Rust is mainly being used for driver development, which seems a great fit (there's so many people of different skill levels who write Linux drivers, so this should help avoid bad driver code being exploited). It may also end up in the core systems, but it also might not fit there as well.

And Zig isn't stable yet

It is not about timelines. Linux Torvalds doesn't spend nights reading bunch of books with crabs on their covers rewriting random bits and pieces of the kernel in Rust. It is basically a dedicated group of people sponsored by megacorps doing the heavy lifting. If megacorps wanted Zig we could have had it in the kernel instead (Linux might have rejected it though, not sure what he thinks of it).

Comparing Rust to C++ feels strange to me.

It’s like people do it just because Zig is very comparable to C. So the more complex Rust must be like something else that is also complex, right? And C++ is complex, so…

But that is a bit nonsensical. Rust isn’t very close to C++ at all.

I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++".

For example, high performance servers (voltlane.net), programming languages (https://github.com/HF-Foundation, https://github.com/lionkor/mcl-rs, and one private one), webservers (beampaint.com) and lots of other domains.

Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

> found no place in which C++ is a better fit than Rust, and so it's my "new C++".

Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.

Rust uses LLVM because it's pretty great, not because you couldn't implement LLVM in Rust.

Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.

If anything, making cranelift an LLVM replacement would likely go counter to its stated goals of being a simple and fast code generator.

Thus Rust cannot really replace C++ when its reference toolchain depends on it.

If you define success for Rust as "everything is written in Rust", then Rust will never be successful. The project also doesn't pursue success in those terms, so it is like complaining about how bad a salmon is at climbing trees.

That is however how the Rust Evangelism Strike Force does it all the time, hence these kind of remarks I tend to do.

C++ is good for some things regardless of its warts due to ecosystem, and Rust is better in some other ones, like being much safer by default.

Both will have to coexist in decades to come, but we have this culture that doesn't accept matches that end in a draw, it is all about being in the right tribe.

So... Like, what? Do you agree that there is no technical reason for LLVM to be written in C++ over Rust?

Have you considered that you perhaps do more damage to the conversation by having it with this hypothetical strike force instead of the people that are actually involved in the conversation? Whose feelings are you trying to protect? What hypocrisy are you trying to expose? Is the strike force with us in the room right now?

I assert there is no reason to rewrite LLVM in Rust.

And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence.

Or ignoring that for the time being NVidia, Intel, AMD, XBox, PlayStation, Nintendo, CERN, Argonne National Laboratory and similar, hardly bother with Rust based software for what they do day to day.

They have employees on WG14, WG21, contribute to GCC/clang upstream, and so far have shown no interest in having Rust around on their SDKs or research papers.

> I assert there is no reason to rewrite LLVM in Rust.

Everybody agrees with that, though? Including the people writing rustc.

There's a space for a different thing that does codegen differently (e.g. Cranelift), but that's neither here nor there.

> And I also assert that the speech that Rust is going to take over the C++, misses on that as long as Rust depends on LLVM for its existence.

There's a huge difference between "Rust depends on LLVM because you couldn't write LLVM in Rust [so we still need C++]" and then "Rust depends on LLVM because LLVM is pretty good". The former is false, the latter is true. Rust is perfectly suited for writing LLVM's eventual replacement, but that's a massive undertaking with very little real value right now.

Rust is young and arguably incomplete for certain use cases, and it'll take a while to mature enough too meet all use cases of C++, but that will happen long before very large institutions are also able to migrate their very large C++ code bases and expertise. This is a multi-decade process.

There are places a language could be a better fit, but which haven't adopted it. E.g. most languages over typescript on the backend, most systems programming languages over Java for games.

The fallacy is to discuss programming languages in isolation without taking the whole ecosystem into consideration.

> Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

That's like saying php is close to haskell because they both have garbage collection.

My take, unfortunately, is that Zig might be a more modern C but that gives us little we don’t already have.

Rust gives us memory safety by default and some awesome ML-ish type system features among other things, which are things we didn’t already have. Memory safety and almost totally automatic memory management with no runtime are big things too.

Go, meanwhile, is like a cleaner more modern Java with less baggage. You might also compare it to Python, but compiled.

Zig gives things we really dont have yet: C + generics + good const eval + good build system + easy cross compilation + modern niceties (optionals, errors, sum types, slices, vectors, arbitrary bit packing, expression freedom).

Are there any other languages that provide this? Would genuinely consider the switch for some stuff if so.

+1 The zig toolchain is the state of the art currently.

C++ added OOP to C.

Rust is not object-oriented.

That makes your statement wrong.

It certainly is according to the various CS definitions of type systems.

Plenty of OOP architectures can be implemented 1:1 in Rust type system.

> Plenty of OOP architectures can be implemented 1:1

Plenty of OOP architecture can be implemented in C. That's an extremely flawed and fuzzy definition. But we've been through this before.

Yet people have to keep be reminded of it.

I think the issue is OOP patterns are one part missing features, one part trying to find common ground for Java, Modula, C++, SmallTalk, that it ends up too broad.

A much saner definition is looking at how languages evolved and how term is used. The way it's used is to describe an inheritance based language. Basically C++ and the descendants.

> one part trying to find common ground for Java, Modula, C++

The primary common ground is that their functions have encapsulation, which is what separates it from functions without encapsulation (i.e. imperative programming). This already has a name: Functional programming.

The issue is that functional, immutable programming language proponents don't like to admit that immutability is not on the same plane as imperative/functional/object-oriented programming. Of course, imperative, functional, and object-oriented language can all be either mutable or immutable, but that seems to evade some.

> SmallTalk

Smalltalk is different. It doesn't use function calling. It uses message passing. This is what object-oriented was originally intended to reference — it not being functional or imperative. In other words, "object-oriented" was coined for Smalltalk, and Smalltalk alone, because of its unique approach — something that really only Objective-C and Ruby have since adopted in a similar way. If you go back and read the original "object-oriented" definition, you'll soon notice it is basically just a Smalltalk laundry list.

> how term is used.

Language evolves, certainly. It is fine for "object-oriented" to mean something else today. The only trouble is that it's not clear to many what to call what was originally known as "object-oriented", etc. That's how we end up in this "no its this", "no its that" nonsense. So, the only question is: What can we agree to call these things that seemly have no name?

> The primary common ground is that their functions have encapsulation

You omitted Smalltalk. Most people would agree that SmallTalk is object-oriented.

But that kinda ruins the common ground thesis.

> Language evolves, certainly. It is fine for "object-oriented" to mean something else today.

pjmlp definition is very fuzzy. It judges object-orientedness based on a few criteria, like inheritance, encapsulation, polymorphism, etc. More checks, stronger OOP.

By that, even Haskell is somewhat OOP, and so is C, assembly, Rust, and any language.

---

What I prefer is looking at it as it's used. And how it's used for appears to be akin to using it as an everyday term fish or fruit.

No one would agree that a cucumber is a fruit. Or that humans are fish. Even though botanically and genetically they are.

> You omitted Smalltalk.

Exactly. It isn't functional. It doesn't use functions. It uses message passing instead. That is exactly why the term "object-oriented" was originally coined for Smalltalk. It didn't fit within the use of "imperative" and "functional" that preceded it.

> But that kinda ruins the common ground thesis.

That is the thesis: That Smalltalk is neither imperative nor functional. That is why it was given its own category. Maybe you've already forgotten, but I will remind that it was Smalltalk's creator that invented the term "object-oriented" for Smalltalk. Smalltalk being considered something different is the only reason for why "object-oriented" exists in the lexicon.

Erlang is the language that challenges the common ground thesis: It has both functions with encapsulation and message passing with encapsulation. However, I think that is easily resolved by accepting that it is both functional and object-oriented. That is what Joe Armstrong himself settled on and I think we can too.

> What I prefer is looking at it as it's used.

And when you look you'll soon find out that there is no commonality here. Everyone has their own vastly different definition. Just look at how many different definitions we got in this thread alone.

> No one would agree that a cucumber is a fruit.

Actually, absent of context defining whether you are referring to culinary or botanical, many actually do think of a cucumber as a fruit. The whole "did you know a tomato is actually a fruit?" is something that made the big leagues in the popular culture. However, your general point is sound: The definitions used are consistent across most people. That is not the case for object-oriented, though. Again, everyone, their brother, and pjmlp have their own thoughts and ideas about what it means. Looking at use isn't going to settle on a useful definition.

Realistically, if you want to effectively use "object-oriented" in your communication, you are going to have to explicitly define it each time.

> That is exactly why the term "object-oriented" was originally coined for Smalltalk.

Sure but your definition doesn't cover it. If language for which the term was coined, it's a bit meaningless, ain't it.

Problem with making encapsulation and polymorphism essential to OOP definition, is that it then starts garbling up functional languages like Haskell and imperative like C.

I can see them being necessary but not enough to classify something as OOP.

> And when you look you'll soon find out that there is no commonality here.

Perhaps, but broadly speaking people agree that C++ and Java are OOP, but for example C isn't.

Same way when people say and give me a fruit (as in fruits and vegetables), you'd be looked oddly if you gave a cucumber, rather than an apple.

Same way can be thought of OOP. The common definition is basically covers Message-passing-languages, and inheritance/prototype based languages.

Fruit = { Apple, Cucumber, … }

Veg = { Cucumber, … }

Fruit As In = Fruit − Veg

Culinary they are separate. But fruit can refer to anything that develops from a pollinated flower. Including cucumber and strawberry.

> Sure but your definition doesn't cover it.

How does it not cover it?

> Problem with making encapsulation and polymorphism essential to OOP definition, is that it then starts garbling up functional languages like Haskell and imperative like C.

Polymorphism? That was never mentioned. Let me reiterate the definitions:

- Imperative: Plain functions (C, Fortran, Pascal).

- Functional: Functions with encapsulation (C++, Java, Haskell, Erlang).

- Object-oriented: Message passing (Smalltalk, Objective-C, Ruby, Erlang).

Let me also reiterate that there are other axis of concerns. Imperative, functional, and object-oriented are not trying to categorize every last feature a programming language might have. Mutable/immutable, or polymorphic/monomorphic, etc. are others concern and can be independently labeled as such.

> Perhaps, but broadly speaking people agree that C++ and Java are OOP

Many do, but just as many hold on to the original definition. Try as you might, you're not going to find a common definition here, I'm afraid. If you want to use the term effectively, you're going to have to explicitly define it each time.

> Polymorphism? That was never mentioned. Let me reiterate the definitions

Sigh. Look at what started this whole discussion.

     > pjmlp: Plenty of OOP architectures can be implemented 1:1 in Rust type system.

It's pjmlp's insistence that Rust is object-oriented.

I'm fine with object-oriented meaning message passing.

I'm fine with object-oriented being used to describe inheritance based langs Java/C#/C++.

But where that fails miserably is when you try implementing inheritance based stuff like DOM in Rust.

You can't have your cake (all capabilities of OOP) and also eat it too (also most of them missing).

Rust was never about inheritance hierarchies or message passing.

It's just structs with privacy modifiers. And functions that are applied to them.

> Look at what started this whole discussion.

If you are pointing out that there is no consistent definition for OOP, I agree. I've said so multiple times. Yes, the proof is in the pudding, as they say.

It is not clear where you think that might otherwise fit into our discussion? I, to the best of my ability, spelled out the historical definitions that we are talking about so that we had a shared understanding. What someone else may have defined the same words as is irrelevant.

I think we can agree that these dividing lines aren't even useful, but the history behind them is understandable. In the beginning there was imperative programming, named to differentiate from unstructured programming. Then came encapsulation, which didn't fit under imperative, so they named it functional to separate it from imperative. But then came Smalltalk, and it recognized that it doesn't fit under imperative or functional, so it gave itself the name "object-oriented".

If we could go back in time we'd realize that none of these names bring any significance [hence why there is no consistent definition] and throw them away. But we cannot go back in time. We could recognize today that they are just a historical curiosity and throw them away now, but it seems there is too much emotional attachment to them at this point.

So, if you want to use them to satisfy your emotional desires, you can! But you need to also explicitly define them each time so that the reader/listener understands what you mean by it. Failure to do so means they will pick their own pet definition, and then you will talk past each other. There is no commonality found around these terms because, again, any definition you choose (pjmlp's, mine, yours, anyone's) none of them convey any truly useful information, so any definition offered is never retained by anyone else.

> It's pjmlp's insistence that Rust is object-oriented.

It is, for some definition of object-oriented. But this perfectly highlights how there isn't useful information to be found in the use of the term. Even if we all agreed on what object-oriented means, what would you learn from it? Nothing, is what. It was a pointless statement and we can accept it as such.

> It is, for some definition of object-oriented.

Sure, for some definition of red, green is red. E.g., colorblind people. I'm interested in more broadly accepted jargon.

The problem is, Rust isn't really object-oriented either. I'm interested in a mostly consistent and hopefully majority definition.

It's not message-passing sense (can't do cool fancy things* a la Ruby or Smalltalk); nor is it inheritance-based (can't do inheritance-based nor prototype-based OOP patterns).

There is one more mathematical definition of whether two features are equal, but it involves languages, local macros, and Turing machines. See https://www.youtube.com/watch?v=43XaZEn2aLc

* There was some kind of message recorder and playback in Ruby/Smalltalk, that I can't find. Basically send methods to objects and record them, then playback them at later date. Will update if I find it.

> The problem is, Rust isn't really object-oriented either. I'm interested in a mostly consistent and hopefully majority definition.

May I suggest "programming language"? I think you will find that most everyone agrees that Rust is a programming language.

In context, it's functional, but I think you rejecting that historical definition means that you agree with me that the attempt at categorization here doesn't provide any useful information. So, the question here is: What specific information is it that you think is failing to be effectively communicated?

If I take a walk down the street and tell the first guy I meet, "Hey, Rust is a programming language", what information did he miss out on that you find critical?

When we establish that, we might find out there is already a widely recognized term. You won't find it in "object-oriented", however. It has never been used in a context where the information was useful. Even the original message passing definition was never useful as you always had to explain what message passing is at the same time anyway, negating the value of a single word to use as a shorthand.

Words are not given to us naturally by the universe. They are a human invention. Consistent definitions for words only become accepted consistently when those humans find utility in adopting something consistent. "If you build it, they will come" only works in movies.

> So, the question here is: What specific information is it that you think is failing to be effectively communicated?

Expressivity. As the video I linked before shows, there is a quantifiable and objective difference between a language that has exceptions and one that doesn't. Or lambda's or async.

What terms like "message passing" and "inheritance-based" capture is unique ability of each language to do something novel* other languages can't. Rust as of now lacks such capabilities, although it can probably simulate them to some extent.

*For message passing, it's the method record and replayer. For inheritance-based it can be something like easy DOM manipulation.

> Expressivity.

Then you might say that Rust is an expressive programming language. But then I'm going to ask: What does expressivity mean?

Ruby is always hailed for its expressivity. Is it also an expressive programming language despite having very little in common with Rust technically?

It seems to me you're going back down the road Kay did thinking that "object-oriented" could become the way to describe his actor based, message passing model. It never caught on because what that means isn't well understood and had to be explained in more detail, so a single word didn't add any value, and thus nobody ever took note of it.

> there is a quantifiable and objective difference between a language that has exceptions and one that doesn't.

Well, I suggest we have a way to say that: {X} {has|does not have} exceptions. The terminology there already exists and is commonplace, as far as I see. If you need to talk about multiple features, then make it a list: {X} has exceptions, lambdas, and inheritance. Laundry list of features are easy to describe. It is when one wants to speak more conceptually that it is harder to find something of actual value as it is usually the concept that you want to explain.

And maybe that's all you really need to get the information conveyed here? "Rust is a programming language" → "Rust is a programming language that has x, y, and z."

> Then you might say that Rust is an expressive programming language.

That's not what I mean. Expressivity allows you to objectively test if two languages are different. The functional/objective/imperative are trying to capture some expressive features.

Using expressivity, you can finally put a Turing machine to that feeling and test it.

> The terminology there already exists and is commonplace, as far as I see.

Missing the point. Message oriented language captures the expressivity of having the ability to send and receive arbitrary methods. This is what I mean.

If OOP or MOP is just a marketing term, then it carries no value.

Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.

I am talking about Rust OOP language features for polymorphism, dynamic and static dispatch, encapsulation, interfaces.

Which allowed me to port 1:1 the Raytracing Weekend tutorial from the original OOP design in C++ to Rust.

Also the OOP model used by COM and WinRT ABIs, that Microsoft makes heavy use of in their Rust integration across various Windows and Office components.

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.

If you make up your own definitions things can be anything you want and have or not have any label.

Absolutely. That's why it is best to stick to the already established definitions. Kay was quite explicit about what "object-oriented" meant when the term was uttered for the first time; including specifically calling out C++ as not being object-oriented.

And yes, we all know the rest of the story about how the C++ guys were butthurt by that callout and have been on a mission to make up their own pet definition that allows C++ to become "object-oriented" ever since. I mean, who wouldn't want to latch onto a term that was about the unique features of a failed programming language that never went anywhere?

Don't you think it's a bit silly to keep rehashing tribalistic arguments that people moved on from 40 years ago?

Once someone offers up the replacement name so that we can continue to talk about what "object-oriented" referred to 40 years ago — and still refers to today, sure. Nobody cares about the exact letters and sounds.

But, until then, no. It is still something we regularly talk about. It needs a name. And lucky for us it already has one — and has had one for 40 years.

As someone who never liked writing anything C++ since 2000+ (did like it before) I cannot agree with this. C++ and Rust are not comparable in this sense at all.

One can argue Rust is what C++ wanted to be maybe. But C++ as it is now is anything but clean and clear.

See my other comment[1]

It replaces C++ for me, so I would say it's "a C++"

[1]: https://news.ycombinator.com/item?id=47334275

And in a world of only you your claim is true.

I think the comparison is fair, strictly in the sense that both Rust and C++ are designed around extensible programming via a sort of subtyping (C++ classes, Rust traits), and similar resource management patterns (ownership, RAII), where Zig and C do not have anything comparable.

I found swift way more enjoyable than rust as a C++ alternative. It even has first class-ish interop now.

Zig is Modula-2/Object Pascal re-packaged with a C like syntax.

Two different philosophical approaches with Zig and Rust.

- Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can.

- Rust: let's make the compiler the guardian of what is safe to do. Unless the developer hits the escape hatch, we will disallow behaviour to keep the developer safe. To allow the compiler to reason about safety we will have an intricate type system which will contain concepts like lifetimes and data mobility. This will get complex sometimes so we will have a macro system to hide that complexity.

Zig is a lot simpler than Rust, but I think it asks more of it's developer.

Rust is a Bugatti Veyron, Zig is a McLaren F1.

That's disingenous, Rust tries to minimize errors, first at compile time then at runtime, even if it at some discomfort of to programer.

Zig goes for simplicity while removing a few footguns. It's more oriented towards programmer enjoyment. Keep in mind that programmers don't distinguish ease of writing code from ease of writing unforeseen errors.

> However we value explicitness and allow the developer to do anything they need to do*

* except for having unused variables. Those are so dangerous the compiler will refuse the code every time.

It’s hard to say that one needs unused variables.

If I comment out sections of code while debugging or iterating I don't want a compile error for some unused variable or argument. Warning. fine, but this happens to me so frequently that the idea of unused variables being an error is insane to me.

It is insane and you are completely right. This has been a part of programming for over 50 years. Unfortunately you aren't going to get anywhere with zig zealots, they just get mad when confronted with things like this that have no justification, but they don't want to admit it's a mistake.

But even the solutions would be so trivial - have a separate 'prod' compiler flag. With that, make these errors, without make these warnings.

Problem solved, everyone happy.

You are right of course, the solution is trivial.

They also made a carriage return crash the compiler so it wouldn't work with any default text files on windows, then they blamed the users for using windows (and their windows version of the compiler!).

It's not exactly logic land, there is a lot of dogma and ideology instead of pragmatism.

Some people would even reply how they were glad it made life difficult for windows users. I don't think they had an answer for why there was a windows version in the first place.

I'm not sure why you shouldn't make your compiler accept CRs (weird design decision), but fixing it on the user-side isn't exactly hard either. I don't know an editor that doesn't have an option for using LF vs CRLF.

The unused variable warning is legitimately really annoying though and has me inserting `_ = x;` all over the place and then forgetting to delete it, which is imo way worse than just... having it be a warning.

I don't know an editor that doesn't have an option for using LF vs CRLF.

And I don't know any other languages that don't parse a carriage return.

The point is that it was intentionally done to antagonize windows even though they put out a windows version. Some people defend this by saying that it's easy to turn off, some people defend it by saying windows users should be antagonized.

No zig people ever said this was a mistake, it was all intentional.

I'm never going to put up with behavior like that with the people making tools actively working against me.

> And I don't know any other languages that don't parse a carriage return.

fair enough.

i think the plan is to make no distinction between error and warning, but have trivial errors still build. that said i wouldn't be surprised if they push that to the end because it seems like a great ultrafilter for keeping annoying people out so they don't try to influence the language.

They are indeed dangerous, and I think this is a pretty good example of why.

https://andrewkelley.me/post/openzfs-bug-ported-zig.html

Same for kernel drivers

don't know if it's still on the table, but Andrew has hinted that the unused variables error may in the future still produce an executable artefact but return an nonzero return code for the compiler. And truly fatal errors would STILL produce an executable artefact too, just one that prints "sorry this compilation had a fatal error" to stdout.

as few footguns as possible

There are no destructors so all the memory ownership footguns are still there.

sure, but when I've written zig this has never been an issue for me. `defer` makes memory management really easy.

If you want to auto-generate destructors, zig has really good comptime features that can let you do that.

defer is still something you have to consciously put in every time so it destroys the value semantics that C++ has, which is the important part. You don't have to "just write defer after a string", you can just use a string.

The 'not a problem for me' is what people would say about manual memory in C too. Defer is better but it isn't as good as what is already in use.

Yes, I've written a few unsafe-focused crates [0], some of which have been modified & merged into the stdlib [1] [2] exposing them to the fringe edge-cases of Rust like strict provenance.

IMO, Rust is good for modeling static constraints - ideal when there's multiple teams of varying skill trying to work on the same codebase, as the contracts for components are a lot clearer. Zig is good for expressing system-level constructs efficiently: doing stuff like self-referential/intrusive data structures, cross-platform simd, and memory transformations is a lot easier in Zig than Rust.

Personally, I like Zig more.

[0] https://crates.io/users/kprotty

[1] https://github.com/rust-lang/rust/pull/95801

[2] https://github.com/rust-lang/rust/blob/a63150b9cb14896fc22f9...

Zig is what you want to write, because it gets out of the way.

Rust is what you want your colleagues to write, to enforce good practices and minimise bugs. It's also what I want my past self to have written, because that guy is always doing things that make my present life harder.

I'd rather my colleagues (and past self) write Rocq.

Rust is what you use when you'd rather spend time doing sales and marketing for Rust than building software.

zig really makes it unappealing to architecture astronaut, and rust pushes you towards it. id rather my colleagues write zig

Reply on news.ycombinator.com