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

731–740 of 929 posts

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

#731

Post by generichuman »

metaltyphoon wrote: post #688
generichuman wrote: post #426

Earlier quoted context omitted.

Only if you're using Unity / Monogame / other custom game engines that use C# as their scripting language. Unity (IL2CPP) and Monogame (BRUTE) transpile the C# (byte)code to C++ to be able to deploy to consoles and the C# version they support lags several versions behind. I don't think we can call C# "the new King of gamedev" until it is officially supported by console makers but it seems unrealistic for a couple of…

Well say no more then https://blog.unity.com/technology/unity-and-net-whats-next

As far as I can tell this only improves things on the Unity side.

What I have in mind is just making a game that can run on PS5/Xbox/Switch without using anything other than C# itself (and the platform API). No engines.

I vaguely remember proof-of-concepts/experiments on Nintendo Switch that made it possible to deploy NET Core AOT builds, but it was in some gitter chatroom so sadly I can't find it again.

Anyway, we still have at least a decade before C# or something else with GC takes over. C# is good enough, but something similar to Swift would make me happier.

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

#732

Post by kimixa »

chriswarbo wrote: post #682
kimixa wrote: post #666

Lumping C and C++ together implies much about the use of the language - "modern" C++ features go out of their way to avoid memory unsafe and bug-prone operations (avoiding raw pointer arithmetic, no manual new/delete memory management etc). Comparing Rust against the overlapping subset of "C" and "C++" is rather disingenuous. It's like writing /everything/ in Rust in an unsafe block and avoiding all the tools that ac…

"Modern C++" versus "older-style C++" is a meaningless, hand-wavey distinction: if your toolchain accepts "older-style C++" then you're using a vulnerable language; if your toolchain rejects "older-style C++" (e.g. using lint rules) then you're not programming in C++, you're using a safer language which just-so-happens to be a subset of C++. That doesn't affect how vulnerable the C++ language is.

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 what the recommended subset is, not helped by that changing over the age of the language, and not being clear about what the general epoch of the language are to highlight things that may be generally replaces by a better construct. Honestly, I'd say the biggest failing of the C++ updates today are lacking some similar epoch system - where older constructs can actually be deprecated from the language.

It would be interesting to see if rust gets exactly the same thing as the community expands, and accumulating language updates affect the generally accepted best practices. It's clear Rust doesn't intend to be completely static, with significant language features being added every version. I wonder if one day we'll look at today's rust in the same way as someone focused on "modern" c++ looks at c++98 C-with-classes style code.

Everyone uses a subset of any language, that's what coding styles and common patterns are. A definition of this subset is a really useful thing you can do for any non-trivial project IMHO, for any language.

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

#733

Post by LtWorf »

woodruffw wrote: post #658
LtWorf wrote: post #649

Earlier quoted context omitted.

Do you vet all of your dependencies' code for unsoundness when using unsafe?

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

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

#734

Post by chongli »

stouset wrote: post #481
chongli wrote: post #401

Earlier quoted context omitted.

Sorry to stretch the analogy beyond recognition but a lot of people who would prefer C over Rust want to build a bathtub for the baby without dragging the rest of the greater metro area into the picture.

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.

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

#735

Post by mustache_kimono »

gonzus wrote: post #651
ghoward wrote: post #470

Earlier quoted context omitted.

It's not lost on me at all. I prefer to finish software. [1] I get it to where it needs to be and put it in maintenance mode. I don't accept outside contributions. [2] I prefer to work alone to keep the scope of my software manageable and to reduce communication overhead. And to avoid working with people. People are too complicated. I obsessively document my software. [3] I comment all of my code. I wrote design docu…

I was going to start this reply by saying "I am not necessarily defending / supporting ghoward's position", but after I read his whole reply, I realize I am. I enjoy writing C (more than C++); I do not find it awful. If you cannot accept that, then there is nothing I can say to change your mind. What I don't understand is this atavistic obsession that "everyone must migrate to rust now", and "C is so dangerous in can…

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 unexplained red-herring cul de sacs ("I doesn't have a spec!" Okay, why do you need a spec?).

> I'm defending my position because it appears you all think it's not acceptable. You're wrong.

I'm not sure this and sentiments like it represent something less narrow-minded? Most of the time, it seems kinda resentful?

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

#737

Post by jeff-davis »

bowlerman wrote: post #541
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/…

Having a standard is overrated. What you usually want is clearly defined behavior and a good backwards compat story. Standards only make sense to me in the presence of multiple compilers or formal verification. There is ongoing work on supporting the second use case. I don't understand why people want multiple compilers.

"I don't understand why people want multiple compilers."

Most people don't. But most development moved away from C/C++ before rust.

If you want to call C & C++ "deprecated" you can't ignore the margins, which is exactly where those languages thrive.

Maybe there needs to be a tiny (incomplete?) rust compiler. Or maybe there should be an interpreter.

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

#738

Post by [deleted] »

baq wrote: post #392
hgs3 wrote: post #211

I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…

Cyclical data structures are difficult to reason about , full stop - not only for the borrow checker. Unsafe is there if you need it. It gives you C pointers for everyone and their debugger to blow up on. The difference is Rust makes you painfully aware that CS 101 is actually hardcore engineering.

[deleted]

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

#739

Post by cjk »

Meh. I agree with the sentiment, but in practice, I’m not sure we’re there yet. Maybe once Rust has a more robust standard library and less language-level churn we’ll be there.

If you’re writing something safety-critical, sure, use a memory-safe language like Rust/Go/etc. Otherwise, I think C++ is still plenty viable.

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

#740

Post by snickerbockers »

LunaSea wrote: post #581
tsujamin wrote: post #370

Earlier quoted context omitted.

get back to me when there's equivalents of KPP/Credential Guard/a stable driver API/etc

Do we still have ads in the operating system?

tbf the win 11 update finally stopped shilling minecraft in the start menu, although its still trying way too hard to convince me that their app store isnt a complete waste of money that will be gone in a decade.
Post reply on HN