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

771–780 of 929 posts

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

#771

Post by _gabe_ »

School-Cotton wrote: post #631
jjk166 wrote: post #625

Earlier quoted context omitted.

In what way does it change the meaning? As I read it, "statistically speaking" is just being used as a parenthetical phrase to qualify that they're not trying to argue literally every rust programmer is superior to literally every c++ programmer, and can be safely omitted so long as no one tries to make some dumb argument like "well I've met one bad rust programmer before" or "so and so is a great programmer and they…

> so and so is a great programmer and they choose c++ Am I crazy? Isn’t that literally exactly what the person I’m responding to was arguing with respect to Carmack?

You cut out part of my full statement which entirely changes the meaning ;)

Here it is in context:

> So I guess John Carmack is inferior and is not an ultimate craftsman.

I didn't realize that their are statistics on what constitutes a craftsman. But I'm willing to change my mind. I'm very curious what those statistics measure though.

Edit: Not to mention like peteradio pointed out, what does a statistically superior programmer look like and where do those statistics live?

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

#773

Post by dleslie »

generichuman wrote: post #768
dleslie wrote: post #746

Earlier quoted context omitted.

If you're not using an engine, with a good editor, then you're already firmly among a niche few. The asset pipeline has been the dominating concern in game development for decades now, folks who willingly toss all that aside to write a game from scratch are among the fringe.

> If you're not using an engine, with a good editor, then you're already firmly among a niche few. Not really. SDL, SFML, Monogame and FNA (and more) do not have editors, but a lot of popular indie titles are shipped with them. > folks who willingly toss all that aside to write a game from scratch are among the fringe Check out Dear Imgui. Indie shops such as exok (makers of Celeste) and AAA companies such as Rocksta…

I'm aware of options like SDL, Raylib et al; despite that, indie is still dominated by editor-heavy tools, like Unity. I've been shipping games for nearly 20y; indie and AAA, and good Editors always win.

Even programmer-focused pipelines tend to evolve into designer and artist focused pipelines over time. It's simple: Dear Imgui doesn't solve the problem of rapidly iterating on an asset from Blender/Maya/Houdini; or from rapidly iterating on level design and scripting; or rapidly iterating on sound import and design; or... Over the course of development many indie studios end up reinventing tools that are already cheap or freely available.

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

#774

Post by JonChesterfield »

ghoward wrote: post #307
pitaj wrote: post #293

Earlier quoted context omitted.

Okay and what about preventing use-after-free and dereferencing null pointers?

Dereferencing NULL pointers: my code is structured such that every function parameter that can be NULL is marked so. And I check those possibly-NULL pointers. This could also be done with a macro: #define y_d(p) ((p) == NULL ? abort(), *p : *p) Otherwise, the compiler (clang, usually) warns me when a NULL pointer is passed in and I have asserts to catch them. Even before I had all of this infrastructure, deferencing…

What calls scope exit if there's a break / return / goto between the allocation and the scopeExit invocation?

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

#775

Post by professoretc »

jokoon wrote: post #766

I highly doubt that it's easy to hire rust developers. Maybe it's possible to hire c++ dev and make them work on a rust project? Anyhow, is there a qt equivalent for rust? Can rust really compete with c++? I've read rust code and I'm sorry but it seems like the steep learning curve is just not worth it, even if the benefits are big. I still believe rust fills the same niche of ada, meaning tight requirements. Most c+…

> Maybe it's possible to hire c++ dev and make them work on a rust project?

Maybe, but not after proclaiming to the internet "your job is obsolete".

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

#776

Post by ModernMech »

ghoward wrote: post #755
mustache_kimono wrote: post #735

Earlier quoted context omitted.

You do you. Maybe it isn't said often enough, but each side (Rust-lovers and Rust-haters) has to be confident enough to allow others to disagree. However, let's be serious, the anti-Rust crowd has not been some bastion of high-minded virtue with its flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..."), mole hill matters of taste ("Egads! The syntax!"), drive by hype hate, and u…

Because it is. And it is because you all say things that imply people like me are terrible, awful, evil, no-good, very bad people for not using Rust. We are not. We just have different preferences. You all have also implied that we are negligent for using C. I don't know about others, but I have not been. That's why I have the challenge to break a release of my `bc`. I actually have not been negligent because I do pu…

> You all have also implied that we are negligent for using C. I don't know about others, but I have not been.

I’m sorry that people have implied that, but I feel most of the time when Rust people say languages like C should be retired or deprecated, are doing so because your skill and attention to detail does not scale.

Maybe you personally have advanced enough to write safe code, and you have the requisite skills and insight to avoid any and all memory bugs, such that your C code is just as safe as what Rust would compile. That’s great.

But there’s always someone starting out and they will not have your skills. They will make the use after free, null pointer deference, buffer overflows, and other issues that the C language not only allow but encourage.

So the question is: how long do we tolerate new programmers making these mistakes in production code, leading to bugs and exploits for all, when other languages are readily available that would have caught those mistakes before reaching production? C was released 50 years ago, and in the intervening time a lot has been learned about how to write programs, and what language features are desirable in enforcing those practices. We also learned that when practiced aren’t enforced, they aren’t followed. So “just write modern c++”, which is espoused throughout this thread, doesn’t work to make c++ code safer, because it’s not enforced. Not taking advantage of those lessons learned seems like folly, irrespective of how bug-free your particular C codebase is.

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

#777

Post by JonChesterfield »

woodruffw wrote: post #38
MathMonkeyMan wrote: post #15

The C/C++ people hate it when you call it C/C++.

I certainly don't. Although I also write Rust now, so I suspect someone will accuse me of having split loyalties or something equally ridiculous. The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background.

So far that on a CV has always meant "can write neither C nor C++"

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

#778

Post by ajross »

Ygg2 wrote: post #292
ajross wrote: post #223

Earlier quoted context omitted.

That's my take too. Idiomatic Rust is "safe" in the sense that... it disallows most nontrivial data structures. Even a doubly-linked list is impossible to get through the borrow checker. That's... not really that fatal. There's a lot of very useful code that can be written using only runtime-provided[1] containers and straightforward ownership trees. But obviously the big problem is that for applications that do need…

> Even a doubly-linked list is impossible to get through the borrow checker. https://github.com/rust-lang/rust/blob/master/library/alloc/... It's part of standard lib. And you don't get more idiomatic than that.

Yes, and the pointer management is all done using unsafe blocks:

https://github.com/rust-lang/rust/blob/master/library/alloc/...

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

#779

Post by karmakurtisaani »

cygx wrote: post #509
jandrewrogers wrote: post #306

Earlier quoted context omitted.

In fairness, using integer handles instead of pointers is pretty idiomatic in high-performance C++ too. I've never found it to be onerous or complicated.

Sure. But the selling point of Rust is that the compiler will check ownership and lifetimes for you. That goes away if you use integer handles, in which case I might as well use another language.

I'm not sure if that's true. The data still has an owner and when the owner goes out of scope the memory should be freed. Without the concept of ownership you might end up leaking that memory. I could be wrong, but I think that's how it goes.

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

#780

Post by stouset »

chongli wrote: post #734
stouset wrote: post #481

Earlier quoted context omitted.

Yeah, and a ton of people still complain about having to put their seat belt on in the car too.

No, the point is that Rust does not replace C. At best, it’s “safe C++” (and even that’s debatable, given the cyclic references issue discussed here). But for the use cases where even C++ is too much, there is no replacement for C. Zig aspires to be that minimal language. It seems to have a lot of really good ideas. It’s too bad the compiler is so opinionated that a lot of developers will be alienated by it.

> No, the point is that Rust does not replace C. At best, it’s “safe C++”.

This is a meaningless distinction. No language in the history of languages has ever strictly "replaced" another. Over time Rust will eat into the market share of every language to differing amounts. C and C++ top the list of languages that Rust will likely eat into the most, but of course they will still continue to exist and people will find reasons to continue using them.

> But for the use cases where even C++ is too much, there is no replacement for C.

Rust is a significantly less complicated language than C++. But what does this even mean, anyway? Whose use-case is "A systems programming language, but the spec can only be so many pages long?"

> (and even that’s debatable, given the cyclic references issue discussed here)

    struct Node {
        data: T,

        left:   *mut Node,
        right:  *mut Node,
        parent: *mut Node,
    }
Wow, so difficult! If the comparison is C, I don't even have to bother writing a safe abstraction around this.
Post reply on HN