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

Introduce a memory safe compilation mode inspired by Fil-C

codeberg.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Introduce a memory safe compilation mode inspired by Fil-C

#41

Post by mbStavola »

alexrp wrote: post #31
chlorion wrote: post #25

Earlier quoted context omitted.

Apparently I'm not. Directly from andrewk himself: If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say This itself is hostility towards anyone who isn't a zig expert pretty much.

You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way. I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place. If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on…

The difference is that Rust doesn't gate comments on proof-of-use, even if core contributors might find it annoying. Honestly, this is the first I've heard of such a policy in a project (though no doubt it exists elsewhere, in the infinite span of F/OSS projects).

This isn't to say Zig's stance is unreasonable, it may even be sensible. But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case. Some people may be welcome to do that; even if there is a strong technical argument or important questions being posed, you are explicitly not welcome unless you meet that criteria, as evidenced by real comments being deleted from that issue.

Re: Introduce a memory safe compilation mode inspired by Fil-C

#42

Post by z0ltan »

alexrp wrote: post #31
chlorion wrote: post #25

Earlier quoted context omitted.

Apparently I'm not. Directly from andrewk himself: If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say This itself is hostility towards anyone who isn't a zig expert pretty much.

You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way. I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place. If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on…

[dead]

Re: Introduce a memory safe compilation mode inspired by Fil-C

#43

Post by davemp »

tstack wrote: post #30
davemp wrote: post #26

Without explicitly entering the language holy wars. I think there’s an interesting trade-off here. Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead. Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from…

You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug. > Another key pro to capabilities is that you can actually have a memory safe interface without having to…

Looks like Mr. Kelly agrees with you. From the zen of zig:

- Runtime crashes are better than bugs.

- Compile errors are better than runtime crashes.

- Incremental improvements.

- Avoid local maximums.

Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.

Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though that may be too much complexity to stomach.

Re: Introduce a memory safe compilation mode inspired by Fil-C

#44

Post by RustSupremacist »

One of the banned individuals was indeed not serious: https://xcancel.com/Malix_Labs/status/2079172393105227839

I am guilty in the Rust community of being too obsessed with Zig. I don't know why. There are many other languages mentioned in a negative way but for some reason, mentioning Rust makes people very sensitive. Meanwhile, we have no problem disparaging other languages to support Rust. For those of us who have Rust and are happy with Rust, why do we need to concern ourselves with another language and their issue tracker? This happened when it was announced that TypeScript was being rewritten in Go too. I want the Rust community to be better even if it means not interacting with other programming languages. There is nothing to gain acting like bullies and thugs.

Re: Introduce a memory safe compilation mode inspired by Fil-C

#45

Post by tstack »

davemp wrote: post #43
tstack wrote: post #30

Earlier quoted context omitted.

You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug. > Another key pro to capabilities is that you can actually have a memory safe interface without having to…

Looks like Mr. Kelly agrees with you. From the zen of zig: - Runtime crashes are better than bugs. - Compile errors are better than runtime crashes. - Incremental improvements. - Avoid local maximums. Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here. Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though…

> Looks like Mr. Kelly agrees with you. From the zen of zig:

... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense.

> Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.

Many of those languages go to great lengths to avoid raw indexing: rich iterators, arenas with branded indexes, checked gets, and so on... But, sure, if you ignore all that and do `get(i).unwrap()`. Then, yes, things are exactly the "same".

I have no problem with people choosing the set of tradeoffs that works for their context. I have a problem with people acting like those tradeoffs don't exist.

Re: Introduce a memory safe compilation mode inspired by Fil-C

#46

Post by alexrp »

mbStavola wrote: post #41
alexrp wrote: post #31

Earlier quoted context omitted.

You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way. I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place. If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on…

The difference is that Rust doesn't gate comments on proof-of-use, even if core contributors might find it annoying. Honestly, this is the first I've heard of such a policy in a project (though no doubt it exists elsewhere, in the infinite span of F/OSS projects). This isn't to say Zig's stance is unreasonable, it may even be sensible. But you cannot state that people are "welcome to engage and debate the idea on its…

> But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case.

I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.

> as evidenced by real comments being deleted from that issue.

Which real comments were deleted?

Re: Introduce a memory safe compilation mode inspired by Fil-C

#47

Post by andrewflnr »

pjmlp wrote: post #36
andrewflnr wrote: post #12

Earlier quoted context omitted.

They focus on Rust because it's the global standard everything is compared to these days. It would be good for it to have some competition, even if we also wish its critics were more careful in their phrasing.

Not when one isn't against the use of managed languages in systems programming, like Swift, D, C# (AOT), Nim, OCaml or oldies that lost the language wars from the 90's, like Modula-3, Oberon, Component Pascal,...

Lots of people are against that, though. Clearly. I agree that it's silly sometimes (I dearly wish OCaml or something like it was mainstream), but the implicit definition of the category that rust, zig, etc are competing in is non-managed languages.

The only point is that it's not weird for Zig to compare itself to Rust.

Re: Introduce a memory safe compilation mode inspired by Fil-C

#48

Post by davemp »

tstack wrote: post #45
davemp wrote: post #43

Earlier quoted context omitted.

Looks like Mr. Kelly agrees with you. From the zen of zig: - Runtime crashes are better than bugs. - Compile errors are better than runtime crashes. - Incremental improvements. - Avoid local maximums. Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here. Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though…

> Looks like Mr. Kelly agrees with you. From the zen of zig: ... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense. > Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here. M…

> No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors

>> Compile errors are better than runtime crashes

I don’t think you’re being fair here.

Re: Introduce a memory safe compilation mode inspired by Fil-C

#49

Post by pjmlp »

andrewflnr wrote: post #47
pjmlp wrote: post #36

Earlier quoted context omitted.

Not when one isn't against the use of managed languages in systems programming, like Swift, D, C# (AOT), Nim, OCaml or oldies that lost the language wars from the 90's, like Modula-3, Oberon, Component Pascal,...

Lots of people are against that, though. Clearly. I agree that it's silly sometimes (I dearly wish OCaml or something like it was mainstream), but the implicit definition of the category that rust, zig, etc are competing in is non-managed languages. The only point is that it's not weird for Zig to compare itself to Rust.

Right, however Zig is late to the party, its approach to safety is like using Modula-2 or Object Pascal.

Also, not only it is hard to see which big corp would make using Zig unavoidable, AI driven programming makes most languages irrelevant, it is a matter to ask what flavour should be output be.

Which is like, why are we even arguing for manual memory management, when is the LLM doing the work.

Post reply on HN