HN user
But can't you then set up a system such that if a person only picks one source or a few sources, and that turns out to be bad, that it primarily impacts negatively only themselves? Letting it be their own responsibility?
Nitpicking:
https://github.com/thelowsunoverthemoon/mahler.c/blob/4ebfe8...
Should that type have been mah_acci instead of int? mah_acci doesn't seem to be used anywhere.
Also, have you considered using (edit) designated initializer syntax for some of the function calls that take in structs as arguments?
https://cppreference.com/w/c/language/struct_initialization....
struct mah_scale scale = mah_get_scale(
(struct mah_note) {
.tone=MAH_C,
.acci=MAH_NATURAL,
.pitch=4
},
&MAH_BLUES_SCALE, notes,
MAH_ASCEND,
NULL
);Would educating people instead and giving them more options for information, not be better than banning access to information?
Enum matching is one of the better aspects of Rust.
When I update the rust compiler, I do so with very little fear. My code will still work. The rust stdlib backwards compatible story has been very solid.
This is not always true, as seen with rustc 1.80 and the time crate. While it only changed type inference, that still caused some projects like Nix a lot of trouble.
Indeed, unsafe Rust is overall more difficult than C++, like one speaker at a Rust conference claimed: https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
And you are not being honest nor accurate here.
Not Firefox, but Servo has quite a lot of unsafe, even though some of the results are false positives.
https://grep.app/search?f.repo=servo%2Fservo&f.repo.pattern=...
So Servo at the very least cannot be said to be 'safe'. And I believe the Rust code in Firefox is similar.
Wasn't the F-35 budget "explosion", or overruns, caused in general by mismanagement? But I will not argue that C++ is perfect. Instead, the ttps://en.wikipedia.org/wiki/Ariane_flight_V88 , where US$370 million was lost, with code written in Ada, is an example where Ada was presented as a safer language and even mandated in the military industry, but where it turned out less well in practice. Even proclaimed "safer" languages can have catastrophic failures, and one can suspect that they might even be less safe in practice, especially if they need mandates to be picked. Instead of Ada companies or other organizations lobbying to force industry to use their language, maybe it is better if there is free competition, and then the onus is on the software development companies to deliver high quality. Ada has improved since the 1990s, perhaps because it has been forced to compete fairly with C, C++ and other languages. Following that thinking, increased, not decreased, competition should be encouraged.
Your lucky soul analogy argument doesn't make any sense.
People made similar arguments regarding C++ versus Ada. The US military and defense industry even got something like a mandate in the 1990s to only write in Ada.
And then there was https://en.wikipedia.org/wiki/Ariane_flight_V88 , where US$370 million was lost. The code was written in Ada.
And using seat belts and wearing helmets do not help in those cases where 'unsafe' is used to take the seat belts and helmets off. And that is needed in Rust in a number of types of cases, such as some types of performance-sensitive code.
How can you be sure? When I looked at for instance sudo-rs, it proclaimed loudly that it is memory safe, but its code has lots of unsafe.
https://github.com/trifectatechfoundation/sudo-rs
https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo...
And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.
No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are.
Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security.
Using Rust does not necessarily solve this. First, performance-sensitive code can require 'unsafe', and unsafe allows for memory unsafety, thus going back to square one, or further back. And second, memory safety isn't the only source of vulnerabilities. Rust's tagged unions and pattern matching help a lot with general program correctness, however, and C++ is lagging behind there.
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
Edit: Replying to ghusbands:
'unsafe' is a core part of Rust itself, not a separate language. And it occurs often in some types of Rust projects or their dependencies. For instance, to avoid bounds checking and not rely on compiler optimizations, some Rust projects use vec::get_unchecked, which is unsafe. One occurrence in code is here:
https://grep.app/pola-rs/polars/main/crates/polars-io/src/cs...
And there are other reasons than performance to use unsafe, like FFI.
Edit2: ghusbands had a different reply when I wrote the above reply, but edited it since.
Edit3: Ycombinator prevents posting relatively many new comments in a short time span. And ghusbands is also wrong about his answer not being edited without him making that clear.
People also write Rust code that is not memory-safe.
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
Does the Rust implementation not use any unsafe and does not use libraries using unsafe?
Are you really OK with runtime "expression patterns"?
match (0, 1, 2) {
case (F(), 0, G()) => ...
}
How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor.
And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?
Do you know of a good way to measure market share? I know of GitHub's and StackOverflow's surveys, but I'm not sure how well they reflect reality. There is also Redmonk.
GitHub's survey did not say much about Rust I think, despite Rust projects often having lots of starring. Rust projects might have a greater ratio of stars-to-popularity than projects in other languages, though.
StackOverflow's survey was much more optimistic or indicated popularity for Rust.
Redmonk places Rust at place 19th.
What concerns me is that the design of Carbon in aspects seem to have serious issues already now.
In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon?
https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...
Rust projects generally use licenses like MIT instead of GPL, and thus some major corporations support Rust a lot, and thus Rust will continue getting popular.
The GitHub project has some activity at least, and they might be coming with some announcement later this year.
I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems.
That means that, even if a C developer used or added C bindings to DRM when wanting to write a new driver, they would be forced to write their new driver in Rust regardless. That seems to run counter to the promises made by Linus.
When an all-new driver is written in Rust, then working on that driver will require knowing Rust.
But that is not what the claim is about, it is about any new driver, not a specific one.
I don't believe that I am. Especially given the other arguments and claims in the email.
But, is this true or false?
If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
But what about this statement that Linus wrote:
That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
Weren't the old Linux kernel developers promised the opposite by Linus Torvalds? That they would be able to continue writing in C?
https://lkml.org/lkml/2025/2/20/2066
The document claims no subsystem is forced to take Rust
But why then did arcadia_leak imply as far as I understood him that C is needed for performance in D?
But D is not included in the benchmarks game at debian.net, which isn't fair to D either as far as I can tell.
Interesting. That might fit the bill, though I am not completely sure.
Do you happen to know why D has not been accepted into the benchmarks games at debian.net? I heard that D developers contributed D code, but that D was never accepted.
A refcounting algorithm, like that found in Rust's (and C++'s) runtime is such a classic GC that not calling it a GC is just confusing.
But is it not easy to opt out of in C, C++, Zig and Rust, by simply not using the types that use reference counting?
And how does your performance analysis consider techniques like arenas and allocating at startup only?
Weka have a realtime distributed filesystem written in D, used for ML/HPC workloads.
This https://github.com/weka ?
Most of the D repositories appear to have very little activity. The Go repositories seem to have more activity.