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

It's time to halt starting any new projects in C/C++

twitter.com

Post reply on HN
Print view View original

841–850 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#841

Post by ghoward »

Arnavion wrote: post #477
gavinhoward wrote: post #435

Earlier quoted context omitted.

Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be…

>Notice that I said to find a memory bug in a release, not just any commit. You did not say anything of the sort. >But I also said to find one in the program, not the library. You did not say anything of the sort. You said: >>The code is my `bc`. [1] >>Find a memory bug, any memory bug, in my `bc` after 1.0. >>[1]: https://git.yzena.com/gavin/bc But okay, let's acknowledge the moved goalposts. >I issue that challenge…

I realize I should answer the signal part.

tokio::signal-type code would not work for `bc` signals.

`bc` is a special program; most programs are I/O-bound, but `bc` is both I/O- and CPU-bound. And it's interactive, so it's got to respond to the user as fast as possible.

It's quite possible for a user to enter an expression, not realizing how expensive it is to compute (since `bc`'s numbers can be arbitrarily large). In that case, a `SIGINT` should be responded to instantly.

Turning signals into an event stream to read would not do that because the signal handler literally has to `longjmp()` out of itself.

It won't `longjmp()` out if it's not safe to do so, but it can be safe to do so. And when it is not safe to do so, it will set a flag and return normally.

Then the code that wasn't safe to jump around finishes, it will check the flag and jump itself once it is safe.

This is what keeps my `bc` responsive even if you have a long-running computation.

To see this, compile and run my `bc`, and give it this input:

    >>> 2^2^32
It will hang because it's calculating a LARGE number.

Press Ctrl+C. It will instantly return to the input prompt.

I might be wrong that tokio::signal cannot do that, and if so, I apologize. But it doesn't appear so from your description.

Also, I have the same sort of code in my new project to turn signals into an event stream in C.

Re: It's time to halt starting any new projects in C/C++

#842

Post by bowlerman »

jeff-davis wrote: post #831
bowlerman wrote: post #824

Earlier quoted context omitted.

> Maybe there needs to be a tiny (incomplete?) rust compiler. Or maybe there should be an interpreter. In which case the issue is "Rust doesn't have a small compiler" or "Rust doesn't have an interpreter". Having multiple compilers won't necessarily mean that those issues are resolved. A more generic argument would be something like "the existing compiler doesn't cover my use cases".

So then when program X misbehaves on one compiler and not the other, is it a program bug or a compiler bug? Typically this would be resolved with a language standard.

That's the way it's resolved in languages with a standard, multiple compilers and no preference towards any of the compilers. This doesn't mean it has to be done this way in Rust.

It seems like Rust is leaning towards doing that like it's done in python. One reference implementation, a language reference and a bunch of design documents (PEP, RFC). There are some areas where the language reference is lacking right now but that can be, and is being, fixed over time.

Re: It's time to halt starting any new projects in C/C++

#843

Post by stouset »

ghoward wrote: post #837
stouset wrote: post #823

Earlier quoted context omitted.

> But I've spent gobs of time trying to understand async/await and failed. It wasn't as much time as I spent honing my C, but it was a lot. And I did not seem to make progress. I've said this elsewhere but as a long-time Rust user I have literally never used or even encountered async/await. It exists, and I could use it if I needed to, but I never have nor have I had to spend effort avoiding it or thinking about it.…

I'm glad you said this because my impression of Rust async/await until now was that it was unavoidable, mostly because I heard that all of the big-name crates, the ones you would use in just about every project, use async/await.

I think you hear about them more because there’s been a lot of pent up demand for async and people who’ve been waiting for it are excited. But I can count on zero hands the number of times I’ve wanted to use a crate but the only one available required async.

Re: It's time to halt starting any new projects in C/C++

#844

Post by 0x457 »

Jataman606 wrote: post #593
jeff-davis wrote: post #440

As much as I like rust, I feel the statement is a bit premature. Rust has only one real compiler and no independent language standard. Rust is also the only alternative that is really being discussed most places. For an idea as major as "deprecate C/C++" you really want a couple solid alternatives. Rust is not perfect for everything, and so its easy to pick on the weaknesses and say "that's why we're sticking with C/…

> Rust has only one real compiler I never understood why it is a problem for some people. Single compiler means more people working on it instead of recreating same work multiple times (modules and coroutines are still not fully supported across all 3 biggest compilers).

What they're really saying is, "I can't build it with GCC", but that would sound too evangelical. Why they need GCC is another question.

Note to whoever I've angered: Please, don't reply with your reasoning why you need GCC. I don't care about your reasoning and that GCC unlike LLVM supports this platform that only used on calculators made by defunct company and sold whole 3 of them.

Re: It's time to halt starting any new projects in C/C++

#845

Post by cercatrova »

ncmncm wrote: post #703
sophacles wrote: post #597

Earlier quoted context omitted.

"Hey C++ developer, you should use rust instead" is very different than "Hey C++ developer, I don't want you to have a job". Do you not see the difference?

I do. "New programs should not be in C++" means, exactly, "You should be laid off so they can hire me instead". If you had something that could do what I need, I would be using it already. It cannot. But you want to bypass me and fool managers, instead, with FUD about memory faults I don't code and have not in years. I have spent strictly more time in the past five years filing compiler bug reports than chasing memor…

Have you even used Rust? Based on your other comments, it just seems like you have an axe to grind against anyone who uses Rust, coming up with accusations of "Rust devs trying to take 'er jerbs"

Re: It's time to halt starting any new projects in C/C++

#846

Post by 0x457 »

kayson wrote: post #107

Can you even use Rust for Windows GUI programming? Is it a practical choice at all for interfaces?

No, it isn't. Yes, you can make Windows or macOS or Linux GUI in rust. Yes, there are options, but:

- ecosystem for GUI is weak

- Can't' imagine using anything, but relm or gtk-rs

- Existing GUI paradigms don't work well in Rust at all

As much as I love writing rust, I would rather write "core" in rust and link with it from something else for GUI.

Re: It's time to halt starting any new projects in C/C++

#847

Post by 0x457 »

chriswarbo wrote: post #840
kimixa wrote: post #732

Earlier quoted context omitted.

If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust. The difference is that "discouragement" is in the compiler itself not external lint tools (though many of those "lint tools" are just optional arguments to the compiler). The big difference is the general community having less of a spread of opinions on wh…

> If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust. You seem to have misunderstood my point. Whether or not you (or I) happen to be using this or feature of a language is irrelevant; the question is whether it's valid input to the toolchain . For comparison, the existence of an SQL injection vulnerability…

Also, "unsafe" in rust doesn't turn it into C++'s wild west.

Re: It's time to halt starting any new projects in C/C++

#848

Post by stouset »

ghoward wrote: post #834
stouset wrote: post #816

Earlier quoted context omitted.

> This industry grew too fast for its own good. It would have been better if it had had a master and apprentice model. The best programmers would be "masters" (in the sense of master and apprentice), and juniors would be apprentices who would write code under the master until the master thought them good enough to be journeymen (moving up from junior), and over time, such journeymen would themselves come to be recogn…

> I 1,000% agree with this perspective. I also actually suspect that some form of professional licensing and/or personal liability would benefit the industry greatly, in that it would give more power to engineers to decline to build software irresponsibly due to pressure from management. I also 1,000% agree with this. In fact, if there is any activism I do within the industry, it's pushing for this. > Obviously this…

> I want to hear why it might be a disastrous idea. I can't see how it would be because it would lead to less but better quality software, and if bad software actually costs more in the long run, it would actually save the industry money! So I fail to see how it would be disastrous.

My answer to this is probably too large for a reply here, but TL;DR is that software engineering is an enormous, complex field. I do know that there are far more ways to do something like this wrong than there are ways to do it right, but I have no idea what would be the right way. Language-based licensing makes sense, but so does licensing for sub-fields like security-related areas (handling PII, cryptography, even different areas of cryptography), operating systems (Windows, macOS, Linux, *BSD, et al), and large frameworks (Hibernate, Rails, React, etc.). But I imagine in practice things would get real murky real quick.

And it's also something where it could easily become too onerous and impossible to develop software.

Re: It's time to halt starting any new projects in C/C++

#849

Post by rng_civ »

LtWorf wrote: post #733
woodruffw wrote: post #658

Earlier quoted context omitted.

One of the guarantees that Unsafe Rust makes is that well-formed unsafe code cannot trigger unsoundness in safe code. In other words: I very rarely write unsafe code myself. When I bring in others’ unsafe code, I use cargo-geiger and siderophile (which I help maintain) to quantify it.

It's not a guaranteed guarantee as far as I can understand. Or such bugreports would make no sense: https://github.com/denoland/deno/issues/15020

According to the RustBelt paper [0]:

> so long as the only unsafe code in a well-typed λRust program is confined to libraries that satisfy their verification conditions, the program is safe to execute.

I think the main caveat is that IIRC, the RustBelt unsafe rules do not cover ALL uses of unsafe in the wild, they analyze only a subset of Rust as whole, and of course, unsafe usage actually has to obey the rules. But I'm hardly an expert here.

That bug report basically says they broke the unsafe rules and thus the guarantee no longer holds (and there is UB).

[0] https://dl.acm.org/doi/abs/10.1145/3158154

Re: It's time to halt starting any new projects in C/C++

#850

Post by patrick451 »

chriswarbo wrote: post #839
einpoklum wrote: post #827

Earlier quoted context omitted.

> All the old, problematic approaches are still valid code, and hence from a security perspective they are vulnerabilities. So, you would mandate using Rust without "unsafe", then? Good luck with that.

Perfect is the enemy of good. If you can avoid "unsafe", then yes: forbid it. If you can't, then permit it for only those modules which need it; and have them expose a safer API, for use by the rest of the safe-subset-of-Rust system.

This argument is indistinguishable from what you are trying to rebut.
Post reply on HN