Uh, the question was not actually about languages, but about use of glibc.

You can have a C that doesn't use glibc and doesn't have this problem. The question here is whether Rust, which in using the system libc will often use glibc on linux systems, has a way of working around this problem elegantly.

Because the point of Rust is to be a better C.

So? That doesn't mean every submitted article mentioning C or C++ has to immediately be filled with comments on how Rust is so much better, safer, etc - So is Java and C#, and you don't see those communities espousing their language the same way!

Because Java and C# are not system programming languages and are not intended to replace C?

Would I want my init system written in Java or C#? Hell no. Would I want it written in Rust? Yes please maybe it will crash less and have fewer CVEs.

I have a belief that every time a C developer switches to Rust, users benefit (unless developer goes crazy from Rust's cognitive load, but this is a separate issue :) )

If you ask me rust is also not for programming systems. (the error handling specifically)

Side note: Who even started the whole "x is a system programming language" ? Who said you can't write "system software"[0] in just about any language that can (directly or indirectly) do "lower level" things. For example the MS Singularity OS has a virtual machine and all the drivers and everything is high level code.

>Would I want my init system written in Java or C#? Hell no. Would I want it written in Rust? Yes please maybe it will crash less and have fewer CVEs.

Contrary to popular belief init systems are simple and can be written in any language. Not to mention that when people talk about inits they don't think about the actual initialization part (mounting, setting network, etc) but about the starting of programs part. Those two things are similar from a far but are really not so much.

>I have a belief that every time a C developer switches to Rust, users benefit (unless developer goes crazy from Rust's cognitive load, but this is a separate issue :) )

I have a belief that people should make up their own mind and do whatever they want. This topic is about C and only about C. All other talk is "noise".

Note that i actually like programming in C as i like optimized programs, so i may be biased. (although not nearly as biased as the rust crowd)

[0] https://en.wikipedia.org/wiki/System_programming_language

> This topic is about C and only about C. All other talk is "noise".

Why do you get to decide? There are a lot of people in this thread talking about similar issues in other languages (Python, Rust, etc) and other functions (like fopen() and exit()). I think those discussions are very on-topic.

Why isn't this topic about "issues between threads and setenv in any language that uses glibc"?

Why isn't this topic about "issues between threads and other functions in any language that uses glibc"?

If you don't like a particular conversation in this topic, you can collapse it and move on.

From one (or more) of the comments here you can see that the reasoning for rust in topics about C is "everybody should write rust instead of C". At least for some people.

One other comment got it right, it is annoying to have multiple rust comments in every thread about C.

But you are right, best way to deal with these kinds of... i don't want to be rude, is ignoring.

PS Thank you for addressing the rest of the comment, not just the part you made personal.

In some things it is, while in some things it ain't. In some things haskell is better then bout, in some things it ain't. In fact the same could be said about most programming languages.

But that is not the point...

Yes, mentioning Rust on every C/C++ is fairly annoying...

glibc is a library that is used by countless programming languages. The question of "how do languages with a focus on safety deal with the unsafety of glibc" is a perfectly valid question.

I think it's a natural comparison to expect, since Rust aims to fix many of C/C++ shortcomings.

Rust marketing.

Because it's HN and there is a segment of the population here who feel compelled to promote the New Shiny any chance they get, irrespective of how terrible it looks, or how badly it squanders their credibility.

In this case, for example, the underlying issue (as usual) isn't "C language BAD!" it's that the function call isn't thread-safe. Which can happen in any language, including Rust.

I'm not an expert, but I thought safe rust had guaranteed thread safety?

https://doc.rust-lang.org/book/concurrency.html

"Thread safety" is more than just protection against data races, which (AFAIK--I am quite happy to acknowledge being wrong here) is the guarantee Rust makes.

Part of the issue with that slogan is that "thread safety" doesn't have any specific definition. Yes, we're specifically talking about data races, as well as the general Send/Sync bounds, but for a blurb on the home page, "thread safety" is the best thing we could come up with. Pitches need to be succinct and get the idea across, but due to the succinctness, can't capture 100% of the details.

No doubt, and I wasn't intending to ding the docs. Rust docs are a paradigm to be emulated in almost every case in my opinion.

None taken! This issue has come up on HN before, just trying to clarify and support what you were saying.