Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig and the design choices within

blueberrywren.dev

Post reply on HN
Print view View original

151–160 of 183 posts

Re: Zig and the design choices within

#151

Post by torginus »

pron wrote: post #144
torginus wrote: post #141

Earlier quoted context omitted.

Not in the sense I meant to make the comparison - Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed - this is way worse level of safety than even what C++ with unique_ptr. In contrast if Rust only ensured that a reference doesn't outlive the scope it's valid in (allocated and cleaned up via RAII), a lot of problems with Rust would go away, like you could have 2 mut…

> Zig doesn't even pretend to do memory safety This is simply untrue. Zig offers the same spatial memory safety as Rust does, and that is the kind of memory safety that prevents more dangerous vulnerabilities [1] than the kind Rust offers and Zig doesn't (temporal memory safety). > if you don't free something manually it won't get freed Rust also isn't free of memory leaks, and doesn't even pretend to guarantee that…

You're responding to the emotional appeal part of my post, not the argument itself - I'm sorry for including it, as it had sidetracked the useful conversation.

Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr.

It's essentially C's malloc/free with the added safety of defer (or possibly arenas), but making sure that the program doesn't leak memory (or have use-after-free bugs) falls on the programmer.

And memory leaks are a much lesser problem, as they usually lead to crashes in OoM situation, than gaining access to random blocks of memory.

Besides, the way you trigger memory leaks in Rust/C++ is with circular references, which are much harder to create than just missing a free() somewhere.

If you have memory that's not tied to a function scope's lifetime in Zig (or the scope of an allocator), then you're essentially have to go by C rules

Re: Zig and the design choices within

#152

Post by pron »

sandbags wrote: post #146
pron wrote: post #100

Earlier quoted context omitted.

I wasn't programming yet when C was 10 years old, but I was when C++ was 10 years old (1995), and its adoption was an order of magnitude higher than Rust's is today. I agree that of all popular languages, Python is the latest bloomer, but while it became popular for applications and data processing rather late, it was used a lot for scripting well before then. > Go's was much smaller than rust at 10 Go turned 10 (if…

I don’t have a dog in this race but I was also around at that time and one reason is there was far less choice in 1995 about where you would go from C. C++ was also a vastly simpler language back then (no templates, no exceptions, barely a few hundred command line options). So I am not sure what its adoption then can teach us about language adoption now.

I don't think it's true there was far less choice in 1995. Around that time (a few years later) I was working on a project that was half Ada half C++, and there were a few more exotic choices around. Aside from those, and C, there were still projects in the company back then written in Fortran and even in Jovial. At university, I learnt Esterel for formally-verified embedded software. And that's not even touching on the higher level space, where VB, Delphi, some Smalltalk, and a large selection of other "RAD tools" were being used (my first summer job was on what today would be called an ERP system written in a language called Business Basic). At university, the language I was taught at intro to compsi was Scheme (that was also the embedded-scrpting language we used at work). We were also taught ML and a bit of Haskell.

It's true that not many languages that seemed a reasonable choice at the time survived to this day as reasonable choices.

Re: Zig and the design choices within

#153

Post by Tadpole9181 »

pron wrote: post #78
ModernMech wrote: post #62

Earlier quoted context omitted.

> a relatively advanced age. Maybe you and I have different working definitions of "relative", but Rust hit 1.0 only 10 years ago, whereas the age of the most popular languages is 30+ years. In that sense Rust is relatively young . Indeed, Rust is the youngest language in the TIOBE top 20, and it's more popular than other languages which have been around much longer. The only language which comes close is Swift, and…

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

Typescript is a tool more than a language, so that's not fair at all.

And the rest of those basically had no competition in their domain when they started 30+ years ago. Rust now has to grow next to 30 years of those languages maturing, and convince people to abandon all existing community resources - whereas those languages did not.

Having a low adoption rate is normal in this day and age. Go is kind of an anomaly caused by it's backing by Google.

But it doesn't help that Rust is also in the native space, whose devs are especially stubborn, and is a difficult language with painful syntax.

Re: Zig and the design choices within

#154

Post by pron »

ModernMech wrote: post #145
pron wrote: post #135

Earlier quoted context omitted.

> I dunno, I think you're trying to split hairs if top 20 isn't "very popular". It's very popular compared to Prolog or Haskell, but not compared to languages people use professionally: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... > In general, in order to convince someone to leave their current tools, you have to not only be better but a lot better. I agree. > So when C++ came on the scene, they h…

> I agree it doesn't need to be very popular to survive. But... I think that's the end of it then, yeah? We've established it's popular enough (you set a lower bound at Haskell, which has been around for 35 years, has an active and vibrant community, and is still used in industry), we agree it doesn't need to be more popular, so then this threshold of "very popular" you invented (which I guess is the top 10) is arbit…

> These two languages were created and pushed by two of the largest corporations on the planet.

I don't think Rust lacks in hype and marketing. It doesn't buy ads in print magazines, but no language does anymore (that's exactly how VB, Delphi, FoxPro, Visual C++, and Java were marketed). And don't forget that while being well-known is necessary for success, it's far from sufficient.

There's also the matter that large corporations may let certain star personalities work on vanity projects, they tend not to invest too heavily in projects they think are unlikely to succeed. In other words, even corporations can't market their path to success, at least not for long. That's why they try to market the things they already believe have a chance of success. Sun acquired technologies developed for Smalltalk and diverted them to Java because they believed Java had a better chance of success.

> This seems to me like cherry picking

Quite the opposite, I think. I can't find a single example of a language with Rust's adoption at age 10 that ended up very popular.

> whereas Rust came from the side project of a lowly Mozilla software engineer

So did C++.

> If you're going to make this claim you've gotta back it up with some data.

I'm backing it up with the market and the idea that in a highly competitive market, any technology that carries a significant competitive advantage in shorter time-to-market or in better reputation etc. should be picked up - at least if it is well-known. It's the claim that a technology gives its adopter a competitive advantage and yet doesn't spread as quickly as previous similar technologies that requires explanation.

> Did anyone make that claim here?

This whole debate is over whether Rust has some "superabled" and unique bottom-line-affecting capabilities compared to Zig.

> Rust is programming language like any other, and at best it's an incremental improvement over current languages

If you see Rust as one avenue for incremental improvement over C++, then we're in complete agreement :)

Re: Zig and the design choices within

#155

Post by munificent »

torben-friis wrote: post #66
munificent wrote: post #7

Earlier quoted context omitted.

> for Ruby is ergonomics… My impression is that this is the main thing for Zig too. The intersection of the set of languages that let you write very low-level code where you have full control over memory and allocation and the set of languages that are enjoyable to program in is pretty small. C is in there if you've internalized many of its warts are fine with all of the many many footguns it has. C++ is in there if…

Ok, that makes sense. So it’s a modern take on low level languages, like rust, but for those that dislike c for being cumbersome rather than for being less secure? Is that a stated goal of the language? Other than the feature to gradually move from c++ it wasn’t super clear from the main pitch.

> for those that dislike c for being cumbersome rather than for being less secure?

I wouldn't say "cumbersome", but perhaps "full of warts and historical baggage".

They have some more details here: https://ziglang.org/learn/why_zig_rust_d_cpp/

Re: Zig and the design choices within

#156

Post by ModernMech »

pron wrote: post #154
ModernMech wrote: post #145

Earlier quoted context omitted.

> I agree it doesn't need to be very popular to survive. But... I think that's the end of it then, yeah? We've established it's popular enough (you set a lower bound at Haskell, which has been around for 35 years, has an active and vibrant community, and is still used in industry), we agree it doesn't need to be more popular, so then this threshold of "very popular" you invented (which I guess is the top 10) is arbit…

> These two languages were created and pushed by two of the largest corporations on the planet. I don't think Rust lacks in hype and marketing. It doesn't buy ads in print magazines, but no language does anymore (that's exactly how VB, Delphi, FoxPro, Visual C++, and Java were marketed). And don't forget that while being well-known is necessary for success, it's far from sufficient. There's also the matter that large…

I have received 3 transmissions from you so far, and you have yet to define "success" or "popularity", nor have you specified the threshold between "popular" and "very popular", despite having agreed with me that these things are not important for languages. Moreover, you haven't brought any figures to bear in supporting your claims. I think if we are going to continue this discussion, you have to substantiate your position -- otherwise I don't think you've said anything here that I haven't already responded to.

Re: Zig and the design choices within

#157

Post by pron »

torginus wrote: post #151
pron wrote: post #144

Earlier quoted context omitted.

> Zig doesn't even pretend to do memory safety This is simply untrue. Zig offers the same spatial memory safety as Rust does, and that is the kind of memory safety that prevents more dangerous vulnerabilities [1] than the kind Rust offers and Zig doesn't (temporal memory safety). > if you don't free something manually it won't get freed Rust also isn't free of memory leaks, and doesn't even pretend to guarantee that…

You're responding to the emotional appeal part of my post, not the argument itself - I'm sorry for including it, as it had sidetracked the useful conversation. Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. It's essentially C's malloc/free with the added safety of defer (or possibly arenas), but making sure that the program doesn't leak memory (or have use-after-free bugs) falls on…

> Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr.

Zig's memory-safety is spatial, which is the more dangerous kind. Your examples are all temporal, and I don't know if I would call them "safety" as the language doesn't enforce or even encourage their use. For example, I work on one of the world's most foundational C++ projects (the HotSpot virtual machine), where neither shared_ptr nor unique_ptr are used at all; the language doesn't complain. There are reference-counted pointer libraries for Zig, too (although I don't think they're popular).

> It's essentially C's malloc/free with the added safety of defer

No, it isn't. First, unlike C or C++, it offers Rust-like spatial memory safety (again, the more important kind). Second, allocation in Zig is much more explicit than in C or C++.

> Besides, the way you trigger memory leaks in Rust/C++ is with circular references, which are much harder to create than just missing a free() somewhere.

They're also much harder to detect, especially when you have a very explicit memory allocation scheme.

> If you have memory that's not tied to a function scope's lifetime in Zig (or the scope of an allocator), then you're essentially have to go by C rules

Again, Zig doesn't seek to offer temporal memory safety, but it does offer the same level of spatial memory safety as Rust does, and while the "rules" of temporal management are similar to C, the way allocation works in Zig makes for a very different experience. An allocating function in Zig looks very different from its C counterpart.

Zig rejects the temporal memory management schemes of C, C++, and Rust - each for different reasons - and prefers a different kind. Of those, only Rust offers temporal memory safety (in the sense that it's controlled by the language) - albeit for a price - and the rest don't.

Re: Zig and the design choices within

#158

Post by lenkite »

torginus wrote: post #112
pizza234 wrote: post #41

Earlier quoted context omitted.

> Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle It is correct that the hype is past its peak, however, the TIOBE trend (if one wants to use that) is actually steadily increasing. > There is still some development in linux "Some development" is a miscarachterization - the official addition to the Linux kernel itself is a…

Here's my 2 cents - a programming language (or any technology, smartphones, LLMs etc) has a honeymoon phase - during which everyone's excited about it and extols its virtues and focuses on how different it is from everything else. Once that's over, people start looking at it with a more pragmatic eye - how much better is this really than what I had before. People start focusing less on the gimmicks and more on everyd…

> Go had it with its green threads and channels, but nowadays most people seem to be not using those that much (I don't think there are a ton of instances of Go processes in prod with 10k threads)

Err..this is incorrect. Some projects who scale to 10k go-routines on a single instance regularly are loki and CockroachDB. Even your common NATS server can scale 5k+ go-routines on single instance and it is not uncommon.

Re: Zig and the design choices within

#159

Post by lenkite »

fransje26 wrote: post #55
guywithahat wrote: post #33

Earlier quoted context omitted.

It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's…

> Rust's popularity seems to be dropping or holding steady in indexes like TIOBE Oh, 14th [1]. That's a lot lower than I would have expected, based purely on the amount of noise surrounding Rust. [1] https://www.tiobe.com/tiobe-index/

Rust is #10 on the PyPL (PopularitY of Programming Language) https://pypl.github.io/PYPL.html

But PYPL has shown Objective-C rising to #4 in the last few months....

Re: Zig and the design choices within

#160

Post by rvrb »

lerno wrote: post #114
rvrb wrote: post #98

Earlier quoted context omitted.

Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult". Software is dangerous. Memory safety is one of a million ways it can be dangerous. A compiler barfing when it thinks you are doing something unsafe with pointers is one approach to dealing with one of the ways that code can be dangerous to execute. Zig does not ignore that particular danger, it just takes a different appro…

I have never heard anyone calling Zig "famously simple" before. In fact, people tend to say it has quite the learning curve. Of course, caveats apply: it is certainly simple compared to some languages, but certainly not compared to others. "Famously simple" seems to indicate it is one of the simplest languages to learn, which seems wrong unless there are some serious qualifications to that statement?

C, C++, Rust, Zig. Rust and C++ have an infamous learning curve. If you know anything about using any systems language other than Zig, Zig is incredibly simple to pick up, like C. Unlike C, it pushes you toward making less mistakes.

If you don't know anything about using a systems language, Zig makes it easier for the people who do to review your code and make sure you didn't mess it up. It does this with very intentional design that makes it easier to understand the full impact of code quickly, reducing the cost of review, making review practical to catch the issues. It also has many other fail safes to catch these problems before they ever reach a production release.

So, yeah, it's totally depending on where you are coming from -- but Zig is not a tool built for a web developer who doesn't know anything about memory to go and ship an application within their first week. It does make it easier for that person to learn the ropes at a steady pace.

Meanwhile, everyone complaining that Zig is not memory safe doesn't seem to care that applications written in Zig do not have the vulnerabilities that memory safety solves on the scale that C does[0].

If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.

If you have, you probably understand there is a niche that Zig fits in and that it isn't surprising it exists to fill it. Like all things in our industry, there is a cost/benefit analysis required for choosing the tools you build with.

No one reasonable has claimed that memory safe languages should not exist, but there is a maddening number of people being disrespectful toward those who think there are other ways of addressing the same problems.

[0]: https://mitchellh.com/writing/ghostty-gtk-rewrite

Post reply on HN