| > Saying it's not perfectly safe is sophistry. Nothing is perfectly safe, but you still don't hand out your sensitive bank information to random person on the Internet/street/etc. You want to make a nuanced argument that calculated unsafety is better than general unsafety, but you don't want to accept a nuanced argument that Rust's safety tools maybe a detriment in some use-cases. > Assume data race happen. Would you prefer to audit 30k lines or 3? Unsafe language is unsafe everywhere. In Rust, you can limit your search to unsafe regions. It depends on the use-case. > Sure, but if your implementation has a data race error, that when triggered happens causing massive loss of funds. First you'll have to find the issue (good luck searching most of language and deps). Then you need to patch it to prevent future errors. And it can happen again. So maybe 3 days here, 5 days there, 4 days there, and so on. This is a strawman argument which doesn't reflect reality. C/C++ is actually the main language used in HPC applications like high frequency trading, and they have massive incentives to choose the correct tool for the job. > If you want HPC and safety use Java/C#/Lisp, no Rust necessary. You can't. I chose HPC deliberately as an example: in HPC performance is the most important constraint. You couldn't use a garbage collected language because you will not be able to optimize memory performance beyond a certain point since you don't have direct control over allocations. > On that I agree. If your game is one and done (no maintenance), no user content, no MP, basically worse that can happen is crash sure go ahead. Jams are in that way perfect candidates for small langs where speed of development is crucial. Then what are we arguing about if you agree with me? > Keep in mind that in Rome everything was written without spaces for hundreds of years. From their POV the spaces would be just unnecessary fluff. You don't know that. They might have looked at spaces and understood immediately that it was an improvement. > And there are still languages that have little to no spaces, so spaces aren't even universally accepted. See Chinese and Japanese. What point are you trying to make? Wouldn't that support my argument that there's room for different modes of programming, both safe and unsafe? > I don't understand, this wasn't specific about just systems language? Going from C# to Zig is a safety downgrade (but a possible performance uplift). And GC langs have been used in OS implementations. I could have also said "most systems programmers don't program in safe languages". The point is the jury is still very much out on whether language-level memory safety is the best solution for all systems programming languages. It's relevant because Zig is the language you are cliticising. > Status quo is C, which has null - a trillion dollar mistake (adjusted for inflation and software spread :P) You can focus on the negatives because C is literally the most successful PL ever which the entire world is built on. People are already talking about how GC is a mistake for a lot of applications. Maybe 10 years from now we will be talking about some big mistake Rust made with async colored functions. Maybe it will turn out Zig's approach is the right one. We don't know yet. > My point that we use Python won in ML because allowing people to achieve value isn't the only important aspect. It's the most important aspect. Every other aspect is just relevant to how you deliver value. > But safety and reducing footguns should be ideals for any language to strive. I'm sorry but you seem to be missing my entire argument. You agree there are tradeoffs. You agree there are use-cases where safety might not be the most critical thing. You have agreed with every component of my argument but you then want to draw the conclusion that safety is somehow a requirement for every new language. |
No. I'm making a simple argument. More safety is better than less safety. You're trying to move argument that since perfect safety is impossible it's not worth pursuing. This is the sophistry part.
> It depends on the use-case.
No it doesn't. Debugging 30k lines is always going to take more than 3/30/300 lines especially when data races are involved.
> This is a strawman argument which doesn't reflect reality.
I said it's a contrived counter example for a contrived example.
> You can't. I chose HPC deliberately as an example: in HPC performance is the most important constraint.
There are HFT systems using Java, few were on HN even. That said, you might have thought of UHFT, but those use FPGA and ASIC, so not even C/C++ would be really correct.
> You don't know that. They might have looked at spaces and understood immediately that it was an improvement.
I know human nature. What we are used to is what we consider natural/ergonomic.
And for the record ancient Greek and Romans made it point of pride to know where and how words end.
> Wouldn't that support my argument that there's room for different modes of programming, both safe and unsafe?
Well, not really. I'm saying ergonomic isn't universal. Due do mixing with English and other such languages what's considered ergonomic is shifting towards spaces and punctuation.
> It's the most important aspect. Every other aspect is just relevant to how you deliver value.
Ok, I see where you are coming from but I fundamentally disagree. If you prioritize delivering stuff fast (move fast, break things) you'll end up with a lot of broken software, and unmaintainable messes along the way.
Maintainability and safety should be primary motivatiors.
Without safety, your performance gains can be rendered moot point anyway. And without maintability your code performance will slowly rot and die.