661–670 of 675 posts
Earlier quoted context omitted.
Mathematica has this: In[1]: Map((1 + #1)&, {a, b, c}) Out[1]: {a + 1, b + 1, c + 1} See https://reference.wolfram.com/language/ref/Function.html.en for the full story.
What is that & doing there? I thought it looks neat, but then that & ...
https://reference.wolfram.com/language/tutorial/FunctionalOp...
Earlier quoted context omitted.
Apparently you have difficulty with reading comprehension, because my original comment already defines "good code": > The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to…
Defined good code TO YOU. You've failed to recognize there is no objective and universally recognized metric for good code within our industry. The closest thing we have to it is number of defects per line of code and how severe those defects are through CVEs. That's it. You've mistaken your personal preferences and aesthetic sense for absolute truth. The arrogance is astounding.
This is a bad choice to have to make. If you believe otherwise, you are an incompetent software engineer. Full stop. These are not personal preferences or aesthetics - these are facts. If you can't parse why these are bad, then you're incapable of basic logic.
> within our industry
Of course, we can already see that because you're resorting to fallacies instead of addressing the point itself.
> You've failed to recognize there is no objective and universally recognized metric for good code within our industry.
Literally none of that is relevant to the point that I'm making. I don't have to define "good code" in order to point out that something is "bad code".
I'm going to print out this thread and show it to anyone who says that they're considering learning Rust as a warning that this is what the community is like - incapable of using logic, unwilling to admit the slightest fault in their religion despite factual evidence to the contrary, and willing to use dishonest rhetoric and fallacies in their defense.
Earlier quoted context omitted.
This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…
But can deny the use of all operations that might panic like indexing an array?
Earlier quoted context omitted.
Sure, but the point is that you can also build reasonably safe abstractions in C / C++.
The last fifty years have shown us that you can't — at least not sustainably and at scale. You can do so at one moment in time, or for smaller projects, but not in the face of large scale projects with team members changing over time.
Earlier quoted context omitted.
Honestly, I'm wondering what kind of pathology do you see that isn't just a community stereotype, and that won't change with the influx of new programmers? And how does it differ from the average Open-Source Project?
The particular kind of pathology I see here is a strong centralization of the Rust community under the control of an unaccountable leadership caste. The point of free-software licensing is to minimize the control "owners" of software have over their users, protecting those users from abuses by leaders. Somehow Rust users seem to have, to a significant extent, abdicated the rights guaranteed to them by the software li…
It wasn't a serious example. But if tomorrow Oracle decided to monetize Java (which they have for LTS) there is little you could do.
> I'm not sure what the "average open-source project" is.
Look at Github. Take several random non-fork repos. It's most likely a lib written and maintained by 1-3 people, where last update was 4 years ago.
Earlier quoted context omitted.
You could assert. You could throw. I can’t understand how, this modern age where so many programs end up getting hacked, that introducing more UB seems like a good idea. This is one odd the major reasons I switched to rust, just to escape spending my whole life worrying about bugs caused by UB.
Assertions are debug-only. Exceptions are usually not guaranteed to be available and much of the standard library doesn't require them. You could std::abort, and that's about it. I think the issue is that this just isn't particularly good either. If you do that, then you can't catch it like an exception, but you also can't statically verify that it won't happen. C++ needs less of both undefined behavior and runtime e…
Earlier quoted context omitted.
Google has been doing a very similar, but definitely somewhat uglier, thing with StatusOr and Status (as seen in absl and protobuf) for quite some time. A long time ago, there was talk about a similar concept for C++ based on exception objects in a more "standard" way that could feasibly be added to the standard library, the expected class. And... in C++23, std::expected does exist[1], and you don't need to use excep…
I had a look. In classic C++ style, if you use *x to get the ‘expected’ value, when it’s an error object (you forgot to check first and return the error), it’s undefined behaviour! Messing up error handling isn’t hard to do, so putting undefined behaviour here feels very dangerous to me, but it is the C++ way.
Earlier quoted context omitted.
> Note that if panic=unwind you have the opportunity to catch the panic. And now your language has exceptions - which break control flow and make reasoning about a program very difficult - and hard to optimize for a compiler.
Yeah, but this isn't the only bad thing about unwinding. Much worse than just catching panics is the fact that a panic in a thread takes down only that thread (except if it is in the main thread). If your program is multithreaded, panic=unwind makes it much harder to understand how it reacts to errors, unless you take measures to shut down the program if any thread panic (which again, requires catch_unwind if you hav…
Addressed in sibling thread - it’s a poor default to design Rust around.
Earlier quoted context omitted.
> The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? > Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. That’s certainly t…
> The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? I was certainly not, I explicitly said that thread-per-request is as bad as process-per-request. I could even agree that it's the worse of both worlds to some extent - none of the isolation, almost all of the overhead (except if you're using a language with a heavy runtime, like Java, where spaw…
Correction. People who wanted to do async IO went and added additional support for it. The primary driver is node.js.
> And they have simply not been optimized with this kind of scale in mind,
yes, processes do not sacrifice security and reliability. That’s the difference.
The fallacy here is assuming that a process is just worse for hand wavy reasons and that your language feature has fa secret sauce.
If it’s not context switching then that means you have other scheduling problems because you cannot be pre-empted.
> There's a reason typical ulimit configurations are limited to around 1000 threads/processes per system
STILL waiting to hear about your experience of maxing out Linux processes on a web server - and then fixing it with green threads.
I suspect it hasn’t happened.
Earlier quoted context omitted.
> The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? > Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. That’s certainly t…
> The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? Are they? I looked back and I've found this quote of them: "The overhead of process-per-request, or even thread-per-request, is absurd if you're already using a memory safe language." Doesn't seem as an advocacy for thread-per-request to me. > As I said at the beginning this approach is making a…
Apache has years of engineering work - and almost weekly patches to fix issues related to security. Many of these security issues would go away if they were not using special technique to optimize performance.
But the best part of the web is its modular. So now your application doesn’t need to that. It can leverage those benefits without complexity cascade.
For example, Apache can manage more connections than your application needs running processes for.
> I was reading stuff on networking….
That’s exactly my point. Too many people are repeating advice from Google or Facebook and not actually thinking about real problems they face.
Can you serve more requests using specialized task management? Yes. You can make a mini-OS with fewer features to squeeze out more scheduling performance and that’s what some big companies did.
But you will pay for that with reduced security and reliability. To bring it back to my original complaint - you must accept that a crash can bring down multiple requests.
And it’s an insane default to design Rust around. It’s especially confusing to make all these arguments about how “unsafe” languages are, but then ignore OS safety in hopes of squeezing out a little more perf.
> So I wouldn't even try to start thousands of threads.
Please try it before arguing it doesn’t work. Fork bombing is recursive and unrelated.
> if you use a memory-safe language, then it is strange to pay costs for preemptive multitasking just to have separate virtual address spaces
Then why do these “memory-safe” languages need constant security patches? Why does chrome need to wrap each page’s JS in its own process?
In theory you’re right. If they are actually memory-safe then you don’t need to consider address spaces. But in practice the attack surface is massive and processes give you stronger invariants.