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

401–410 of 929 posts

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

#401

Post by chongli »

stouset wrote: post #224
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…

Seriously, just use unsafe. “Welp, can’t write a doubly-linked list in safe Rust so I might as well use C” is throwing the baby, the bathtub, and the rest of the greater metro area out with the bathwater.

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.

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

#402

Post by baq »

lenkite wrote: post #269
jnwatson wrote: post #161

Earlier quoted context omitted.

You don’t have to know about exception safety, move semantics, meta-template higgery jiggery, or the 30 years of cruft that C++ has accumulated. Good riddance.

You don't need to know about about 6 different string types, arcane borrow checker workarounds, RefCell complexity, massive async cruft - acquired by Rust in just 2 years. C++ will still be used heavily when Rust is buried 6 feet under and HN moves to the next hype language.

> 6 different string types

have fun living your life pretending all strings are of the same type. spoiler alert: it's the wrong kind of fun. it's a bit easier if you're from a native English speaking country, but only until you get blown up by utf-8 (if you're lucky) in production.

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

#403

Post by baq »

ninefathom wrote: post #242

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything…

> beginners

> OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU

what?

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

#405

Post by bitwize »

ReactiveJelly wrote: post #76

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Yep. C and C++ devs, Rust really isn't for you; it's for your replacement.

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

#406

Post by ninefathom »

humanrebar wrote: post #320
Ar-Curunir wrote: post #267

Earlier quoted context omitted.

What? You can totally compile Rust for compatibility with python libraries or Ruby libraries or whatever you want. Rust can offer the same API that C/C++ offer, so it can be a drop-in replacement.

...as long as you're fine shelling out to cargo, right? What if that's not appropriate or ergonomic? There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point. And it's common enough to have linked programs in which python calls C that calls C++ that calls Fortr…

"There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point."

Yep. The Rust ecosystem is very much a product of the always-connected, move-fast-and-break-things, DevOps-CI/CD-SCRUM-Agile, horizontal scaling world... which is fine right up until the point where it needs to be used outside of that world, at which point all hell breaks loose.

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

#407

Post by latency-guy2 »

pclmulqdq wrote: post #119
mappu wrote: post #66

Earlier quoted context omitted.

You see it a lot more often from the Microsoft world since MSVC only supported "C/C++" as a combined language, there was no separate C compiler.

MSVC is a C++ compiler only. It doesn't actually support C.

It does, but I know why you have this interpretation and I think it's fair to have it.

MS only created their compiler to support C all the way up to C89 and it's original standard, with some Microsoftisms in it. MS did not update their compiler to support C99 and subsequent updates until, I think the late 2010s. Since then, they have updated and supported some of the newest C standards.

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

#408

Post by ncmncm »

shadowgovt wrote: post #218
crabbygrabby wrote: post #127

Earlier quoted context omitted.

Really interesting take, I've had the opposite experience. I've also seen very talented c++ devs screw things up in prod that rust doesn't even allow for. Really recommend taking it more seriously, it's fun once you get a handle on it. Also the tooling is really good now.

C++ has grown several language tools to let you write reliable, safe code. ... But it can't shed the old stuff without breaking backwards compatibility, and that's what bites you. The fact that smart pointers exist now doesn't stop a developer from passing around non -const char* with no size specifier and calling that a "buffer," and because the language is so old and accreted most of its safety features later, the…

It can't shed the old stuff, but it is very, very suspicious -- smelly -- when any of it appears in new code.

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

#409

Post by blub »

It’s jarring to see how somebody’s fame in a specific domain makes them believe they can dictate what other companies and entire industries can use.

Read his internals book - much appreciated back when I was doing Windows programming. Used his tools - very nice while I was still using Windows.

But I never looked to Mark Russinovich or any Microsoft guys to advice on what programming language to use. What’s the point of making such an arrogant proclamation?

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

#410

Post by ncmncm »

Ar-Curunir wrote: post #263
bitL wrote: post #109

Earlier quoted context omitted.

Dunno. Young devs can pick basic Rust constructs fast but when it comes to complicated stuff where performance is critical... There must be raw talent and lot of grind. IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. C++ for talented folks makes life easier there. Like JavaScript, yet another language written for bad…

It's not easier to write "super complex stuff" in C++ than in Rust, precisely because C++ has much more cruft that the compiler can't check for you. And so what if Rust is lowering the bar for entry to systems programming? I'd much rather fresh ideas and fresh blood enter the field, than it slowly dying as the only people with arcane C/C++ knowledge slowly retire/die.

There is still quite a lot that you can only ever express in C++. So, no. And plenty of that, you will never be able to express in Rust.
Post reply on HN