15 ms·

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be sai

by pron 1y ago

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requires less competence than other forms of thinking about a program, then why Rust? Why not ATS? After all, Rust does let you eliminate certain bugs at compile time, but ATS lets you eliminate so many more.

whytevuhuni 1y ago
> Why not ATS? As in, why not use a language with much stronger formal verification? Because people have tried it and failed. Like you said, Rust is hard, it already feels at the limit of what people can handle. But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while. I very much doubt the same could be said about ATS.
- pron 1y ago
  > But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time, would be preferable to Rust. You see, the problem is that these arguments cannot lead us to an objective preference unless we compared Rust to all other points on the spectrum, especially since Rust proponents already must accept that the best point is not on any extreme. So we know that languages that guarantee more than C but more productive than ATS are preferable. Guess what? Zig is right there, too, so that argument can't be used to prefer Rust over Zig.
  - whytevuhuni 1y ago
    Sure, that makes sense. I agree this is all very subjective, given we don't have the benefit of hindsight for what Zig can accomplish yet. I think where we disagree is that you believe Zig is as safe as Rust (by making it easier to make other things safer). I don't believe so (my first impression of Zig was Bun repeatedly segfaulting), and I'm just sad that people are choosing the easy route and going for more insecure software, when it finally looked like we made such great progress, with a language people can actually use. I agree with simpler, but there's so many other things that can be changed or removed from Rust, and still leave in lifetimes, or something similar.
    - pron 1y ago
      > I think where we disagree is that you believe Zig is as safe as Rust Quite the opposite. Rust is definitely safer in the simple sense that it guarantees more memory safety. But that's very different from saying that Zig is closer to C than to Rust (Zig's memory safety is much closer to Rust's than to C's), and it also doesn't mean that it's easier to write more correct/secure software in Rust (because there are just too many factors). > and I'm just sad that people are choosing the easy route and going for more insecure software The jump from "segfaulting" to "insecure" is unjustified, as not all causes of segfaults map to equally exploitable vulnerabilities. Java programs, for example, segfault much less than Rust programs. Does that mean Rust programs are significantly less secure?
      - zozbot234 1y ago
        > Zig's memory safety is much closer to Rust's than to C's This is arguable. Zig's issues with memory safety are not limited to such things as use-after-free ("temporal" memory safety in a rather obvious sense). Without something very much like Rust's borrow checker and affine types, you can't feasibly prevent a program from inadvertently e.g. stashing a pointer somewhwere to an inner feld of a tagged union, and reusing that pointer later even though the union itself may have mutated to a different tag, which results in undetected type punning and potentially wild pointers. The issue of iterators to a collection being invalidated by mutation is quite similar in spirit, and again has nothing to do with the heap per se. Rust prevents these issues across the board. The fact that it also manages to prevent temporal memory unsafety altogether is simply a bonus that essentially comes "for free" given the borrow checking approach.
ModernMech 1y ago
> 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 that one had the advantage of Apple pushing it as the main language for iOS development, Rust never had that kind of marketing and corporate support.
- pron 1y ago
  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.
  - kennykartman 1y ago
    I'm curious, do you have figures for this? I was not around when C or C++ were 10, but I was when python was and as a long time python user I would say that the pycommunity was much smaller at 10 then the rust community at 10. So my gut feeling is that your statement is false at least wrt python, but I'm happy to change my mind if you have sound data. Edit: just to add some more anecdotal evidence from my memory of languages I used: java community was pretty bigger than rust at 10. Go's was much smaller than rust at 10. I'd be happy to check my beliefs against actual data :)
    - pron 1y ago
      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 we want to count from 1.0) only 3 years ago, and Go's adoption in 2022 was much bigger than Rust's today.
kennykartman 1y ago
> then why Rust? Why not ATS? After all, Rust does let you eliminate certain bugs at compile time, but ATS lets you eliminate so many more. Of course it's subjective, but I think there is a perception of perceived benefit over effort. Zig gives much perceived benefit over low effort. Rust gives much perceived benefit over more effort. Even more effort for ATS. But the benefit is relative: nobody cares to create totally bug-free software when the software is not critical at all. In addition, most programmers think that solving bugs is part of the job more than preventing them. Solving segfaults is often easier than thinking about formal systems, so the perceived benefit is higher in Zig than ATS - at least for programmers that know C, pointers and the like. Note how the majority of programmers don't deal with memory allocations at all: they use JavaScript and Python, memory is managed. For them, solving memory bugs is not something that makes sense, so the effort of dealing with memory is enough to renounce that freedom altogether. Rust is a very good middle ground: it's a complex language, but there's lot of room for improving its ergonomics.
- pron 1y ago
  > Rust is a very good middle ground: it's a complex language, but there's lot of room for improving its ergonomics. I certainly agree Rust is a much better middle ground than either C or ATS. But so is Zig. What's harder to support objectively is that Rust is a better middle ground than Zig (or vice-versa). We just don't know! They both make different tradeoffs that we can't objectively rule on. So all I'm saying is that we're left with subjective preferences, and that's fine, because that's all we have! So let's stick to saying "I like Rust's design better" or "I like Zig's design better", and stop trying to come up with objective reasons that are just not well-founded. At the very least, people should stop comparing Zig to C as part of an argument that claims Rust is good because it prevents the vulnerabilities associated with memory-safety violations, as Zig prevents the most dangerous of those, too.
at_compile_time 1y ago
Rust's real superpower is its tooling. Cargo handles package management, building, testing, documentation, and publishing. The compiler's errors explain what went wrong and where it happened. Installing the toolchain with rustup is quick and painless, even on Windows. I can't know that it's best in class, but it's certainly the best I've used. I can see another language having a more expressive type system, I've come up against the limitations of Rust's type system more than once, but the tradeoff isn't worth it if I have to go 20 years back in time in terms of tooling.
- pron 1y ago
  Rust is much older than Zig, though, and there's nothing stopping Zig (or any future language that doesn't adopt Rust's precise set of guarantees) from having the same, or possibly better. Given Zig's immaturity, I certainly wouldn't use it for any serious production software today. BTW, I'm not saying Rust is bad. All I'm saying is that the attempt at proving it's objectively best by leaning on memory-safety is not really as objective as the people who make that claim seem to think it is.
  - at_compile_time 1y ago
    I hadn't heard of ATS before, and I think that I mistook your using it as an example of "more isn't always better" and thought you were suggesting it as an actual alternative. I'm looking for the next thing I want to learn, and have been leaning towards logic programming and theorem provers, so you inadvertently piqued my interest.
    - pron 1y ago
      Sure, just keep in mind that various formal verification tools vary greatly in their usability, even theorem provers. I.e. the experience with ATS will be quite different from Lean, which will be quite different from TLA+.
asa400 1y ago
> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. What are we measuring? Lines of code? Number of programmers employed? Number of new applications started? Rust is in: Linux, Windows, Azure, all over AWS, Amazon's Prime video, Cloudflare's proxy, Firefox, Python's `cryptography` package, Zed editor. This is just the sample I know of. Is this low adoption?
- pron 1y ago
  > What are we measuring? Lines of code? Number of programmers employed? Number of new applications started? They're correlated, but number of programmers employed is something that's relatively easy to measure. > Is this low adoption? For a language this old? Yes. That people talk so much about specific projects that use Rust only underlines that: Rust is now as old as Java was when JDK 6 came out; older than PHP was when PHP 5 came out or Facebook was launched; older than C++ was when Windows NT came out.
JuniperMesos 1y ago
> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. How much adoption should we expect Rust to have at this point, and how does it compare to other languages? I certainly don't have the impression that Rust has relatively low adoption in a general sense, although I'm also a fan of the language and make a point of being in programming communities that are interested in Rust too.

by pron 1y ago

whytevuhuni 1y ago

> Why not ATS? As in, why not use a language with much stronger formal verification? Because people have tried it and failed. Like you said, Rust is hard, it already feels at the limit of what people can handle. But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while. I very much doubt the same could be said about ATS.

pron 1y ago
> But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time, would be preferable to Rust. You see, the problem is that these arguments cannot lead us to an objective preference unless we compared Rust to all other points on the spectrum, especially since Rust proponents already must accept that the best point is not on any extreme. So we know that languages that guarantee more than C but more productive than ATS are preferable. Guess what? Zig is right there, too, so that argument can't be used to prefer Rust over Zig.
- whytevuhuni 1y ago
  Sure, that makes sense. I agree this is all very subjective, given we don't have the benefit of hindsight for what Zig can accomplish yet. I think where we disagree is that you believe Zig is as safe as Rust (by making it easier to make other things safer). I don't believe so (my first impression of Zig was Bun repeatedly segfaulting), and I'm just sad that people are choosing the easy route and going for more insecure software, when it finally looked like we made such great progress, with a language people can actually use. I agree with simpler, but there's so many other things that can be changed or removed from Rust, and still leave in lifetimes, or something similar.
  - pron 1y ago
    > I think where we disagree is that you believe Zig is as safe as Rust Quite the opposite. Rust is definitely safer in the simple sense that it guarantees more memory safety. But that's very different from saying that Zig is closer to C than to Rust (Zig's memory safety is much closer to Rust's than to C's), and it also doesn't mean that it's easier to write more correct/secure software in Rust (because there are just too many factors). > and I'm just sad that people are choosing the easy route and going for more insecure software The jump from "segfaulting" to "insecure" is unjustified, as not all causes of segfaults map to equally exploitable vulnerabilities. Java programs, for example, segfault much less than Rust programs. Does that mean Rust programs are significantly less secure?
    - zozbot234 1y ago
      > Zig's memory safety is much closer to Rust's than to C's This is arguable. Zig's issues with memory safety are not limited to such things as use-after-free ("temporal" memory safety in a rather obvious sense). Without something very much like Rust's borrow checker and affine types, you can't feasibly prevent a program from inadvertently e.g. stashing a pointer somewhwere to an inner feld of a tagged union, and reusing that pointer later even though the union itself may have mutated to a different tag, which results in undetected type punning and potentially wild pointers. The issue of iterators to a collection being invalidated by mutation is quite similar in spirit, and again has nothing to do with the heap per se. Rust prevents these issues across the board. The fact that it also manages to prevent temporal memory unsafety altogether is simply a bonus that essentially comes "for free" given the borrow checking approach.

ModernMech 1y ago

> 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 that one had the advantage of Apple pushing it as the main language for iOS development, Rust never had that kind of marketing and corporate support.

pron 1y ago
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.
- kennykartman 1y ago
  I'm curious, do you have figures for this? I was not around when C or C++ were 10, but I was when python was and as a long time python user I would say that the pycommunity was much smaller at 10 then the rust community at 10. So my gut feeling is that your statement is false at least wrt python, but I'm happy to change my mind if you have sound data. Edit: just to add some more anecdotal evidence from my memory of languages I used: java community was pretty bigger than rust at 10. Go's was much smaller than rust at 10. I'd be happy to check my beliefs against actual data :)
  - pron 1y ago
    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 we want to count from 1.0) only 3 years ago, and Go's adoption in 2022 was much bigger than Rust's today.

kennykartman 1y ago

> then why Rust? Why not ATS? After all, Rust does let you eliminate certain bugs at compile time, but ATS lets you eliminate so many more. Of course it's subjective, but I think there is a perception of perceived benefit over effort. Zig gives much perceived benefit over low effort. Rust gives much perceived benefit over more effort. Even more effort for ATS. But the benefit is relative: nobody cares to create totally bug-free software when the software is not critical at all. In addition, most programmers think that solving bugs is part of the job more than preventing them. Solving segfaults is often easier than thinking about formal systems, so the perceived benefit is higher in Zig than ATS - at least for programmers that know C, pointers and the like. Note how the majority of programmers don't deal with memory allocations at all: they use JavaScript and Python, memory is managed. For them, solving memory bugs is not something that makes sense, so the effort of dealing with memory is enough to renounce that freedom altogether. Rust is a very good middle ground: it's a complex language, but there's lot of room for improving its ergonomics.

pron 1y ago
> Rust is a very good middle ground: it's a complex language, but there's lot of room for improving its ergonomics. I certainly agree Rust is a much better middle ground than either C or ATS. But so is Zig. What's harder to support objectively is that Rust is a better middle ground than Zig (or vice-versa). We just don't know! They both make different tradeoffs that we can't objectively rule on. So all I'm saying is that we're left with subjective preferences, and that's fine, because that's all we have! So let's stick to saying "I like Rust's design better" or "I like Zig's design better", and stop trying to come up with objective reasons that are just not well-founded. At the very least, people should stop comparing Zig to C as part of an argument that claims Rust is good because it prevents the vulnerabilities associated with memory-safety violations, as Zig prevents the most dangerous of those, too.

at_compile_time 1y ago

Rust's real superpower is its tooling. Cargo handles package management, building, testing, documentation, and publishing. The compiler's errors explain what went wrong and where it happened. Installing the toolchain with rustup is quick and painless, even on Windows. I can't know that it's best in class, but it's certainly the best I've used. I can see another language having a more expressive type system, I've come up against the limitations of Rust's type system more than once, but the tradeoff isn't worth it if I have to go 20 years back in time in terms of tooling.

pron 1y ago
Rust is much older than Zig, though, and there's nothing stopping Zig (or any future language that doesn't adopt Rust's precise set of guarantees) from having the same, or possibly better. Given Zig's immaturity, I certainly wouldn't use it for any serious production software today. BTW, I'm not saying Rust is bad. All I'm saying is that the attempt at proving it's objectively best by leaning on memory-safety is not really as objective as the people who make that claim seem to think it is.
- at_compile_time 1y ago
  I hadn't heard of ATS before, and I think that I mistook your using it as an example of "more isn't always better" and thought you were suggesting it as an actual alternative. I'm looking for the next thing I want to learn, and have been leaning towards logic programming and theorem provers, so you inadvertently piqued my interest.
  - pron 1y ago
    Sure, just keep in mind that various formal verification tools vary greatly in their usability, even theorem provers. I.e. the experience with ATS will be quite different from Lean, which will be quite different from TLA+.

asa400 1y ago

> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. What are we measuring? Lines of code? Number of programmers employed? Number of new applications started? Rust is in: Linux, Windows, Azure, all over AWS, Amazon's Prime video, Cloudflare's proxy, Firefox, Python's `cryptography` package, Zed editor. This is just the sample I know of. Is this low adoption?

pron 1y ago
> What are we measuring? Lines of code? Number of programmers employed? Number of new applications started? They're correlated, but number of programmers employed is something that's relatively easy to measure. > Is this low adoption? For a language this old? Yes. That people talk so much about specific projects that use Rust only underlines that: Rust is now as old as Java was when JDK 6 came out; older than PHP was when PHP 5 came out or Facebook was launched; older than C++ was when Windows NT came out.

JuniperMesos 1y ago

> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. How much adoption should we expect Rust to have at this point, and how does it compare to other languages? I certainly don't have the impression that Rust has relatively low adoption in a general sense, although I'm also a fan of the language and make a point of being in programming communities that are interested in Rust too.