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

451–460 of 929 posts

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

#451

Post by sanxiyn »

LAC-Tech wrote: post #333
TakeBlaster16 wrote: post #51

Earlier quoted context omitted.

Not to say I'm not excited for Zig, but there are still bugs, miscompilations, and many breaking changes planned. Communicate realistic expectations, lest you become the next language evangelism strike force.

I'm not really over-stating zigs readiness. More pointing out how ready rust wasn't at 1.0.

Looking back, Rust 1.0 was unpolished, but was ready to be 1.0. Rust concentrated on ability to make compatibility commitment, and almost all polishing was postponed. Compatibility commitment stood the test of time.

For example, in Rust 1.0 having a destructor increased object size. This was in no way acceptable as a final design, but they made a plan to fix it in a compatible manner, and actual work was postponed and other things were prioritized. It was fixed one year later in Rust 1.12 without any compatibility problem.

Rust was unusually aggressive about this to ship 1.0 as soon as possible. In general, if it could be fixed compatibly, it was postponed. From what I can observe, Zig doesn't seem to do this, so I can believe Zig now is more polished than Rust 1.0. If so, remember it was a deliberate choice of Rust developers for Rust 1.0 to be unpolished.

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

#452

Post by ncmncm »

kllrnohj wrote: post #145
throwaway2037 wrote: post #67

Earlier quoted context omitted.

I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?

It's well defined safe to use a vector after a move: Move constructor. Constructs the container with the contents of other using move semantics. Allocator is obtained by move-construction from the allocator belonging to other. After the move, other is guaranteed to be empty(). https://en.cppreference.com/w/cpp/container/vector/vector Which can be a useful property at times, but also means tooling won't help you here…

What he probably means is he imagines the moved-from vector still has elements in it, and indexes into the empty. Another argument for at() outside loops.

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

#453

Post by [deleted] »

ransom1538 wrote: post #249
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.…

You can find good C++ devs, if ySegmentation fault.

[deleted]

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

#454

Post by ncmncm »

imron wrote: post #101
DannyBee wrote: post #85

Earlier quoted context omitted.

If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/be…

> If by "slip through", you mean "warns you about by default", then yes it lets it slip through. My bad. I should have been more modern. Try this one: #include #include #include int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv {s + "World\n"}; // {now even more modern and warning free} std::cout

In other words, not a problem.

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

#455

Post by fwsgonzo »

hackerlight wrote: post #368
WiSaGaN wrote: post #299

Earlier quoted context omitted.

If you want the lowest software latency as in "latency arbitrage", then probably not. However, even in HFT industry, there are a lot of software that you want very low latency but would still trade a bit latency in exchange for much better productivity, maintainability, and especially robustness provided by the type system of Rust. You want to be fast, and also want to reduce the possibility of hitting a company-brea…

How much slower would Rust be? If C++ delivers 4us and Java delivers 25us tick to trade for a particular strategy (say, book building, some calculations, then order sending), what could Rust get?

There's some extra checks, which are usually branches, so I would guess that the branch predictor gets a little bit more pressured, while also taking a few extra cycles in the branches. But, I think you can still create fast happy paths with Rust just like other languages.

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

#456

Post by lionkor »

bitwize wrote: post #405
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.

Ahhh, okay, good. Am in the process of learning it, but I think I'll stop and get ready to be replaced instead. After all, being in my 20's, ive become too old to "get it".

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

#457

Post by bravura »

ghoward wrote: post #258
customkitchen wrote: post #152

Earlier quoted context omitted.

You can like something and still admit that it is awful. I "liked" C for a long time before there were better options...

I still disagree that it's awful.

The argument you are missing: Your position is bespoke and incompatible. You don't use idioms in your C code. You use idiolect. Thus, you exist in your own universe and are a party of one.

And the clue was something you might not expect...

I programmed C++ for five years, and C for over ten years before that. I don't know rust, but I followed this discussion with great interest.

One of the topics that came up several times was being able to identify who wrote what C++ code based upon their choice of language subset without using blame.

In the pro-rust arguments and C++ counter-arguments and rust counter-counter-arguments and C++ counter-counter-counter arguments in discussions above yours, I was pleasantly surprised to see that grandfather comments were rarely (never?) the same author. At least the rust and C++ arguments were made by different people sharing some sort of group mentality.

Then I hit your thread and saw the grandchild comment: "I understand you think it's awful, but I do like it. Everyone has their preference." and I was like: "Okay. I bet grandparent is also ghoward."

The simple fact that no one is chiming in to grandchild your arguments is the point that you're missing. In fact, the entire subthreads you've spawned involve basically ghoward defending ghoward's position.

It's nice when other people can take over your work. That's what we're after.

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

#458

Post by ncmncm »

1970-01-01 wrote: post #92

Is he actually doing it? Making a plan and a policy to replace the bone marrow of MS with Rust? Or is this just a pie in the sky tweet? I don't know what Mark is like as a CTO, so I really don't know what to expect here.

> I really don't know what to expect here.

I do. This is Microsoft.

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

#459

Post by scoutt »

roca wrote: post #313
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…

> the big problem is that for applications that do need to do non-trivial reference semantics, Rust doesn't really offer much. For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code. And in many cases someone else already wrote that library. For graphs, for example, there is petgraph.…

> For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code.

This is something I never understood. Given that a Rust application is running on top of an OS making OS calls... or uses a huge library like FFMPEG... The only safe portion is like the 1% of code being executed.

"such that the library is a tiny fraction of the application code"

I mean, your Rust app uses sockets to pull a video and save it with FFMPEG. The quantity of code executed to do that is like 99% unsafe and 1% safe. Right?

What are we talking about here? I can still find a bug in FFMPEG and ROP-exploit some code in the safe 1%, right?

The same languages and code Rust evangelists (and Mark Russinovich if not one) are blaming is the only code that makes Rust do something meaninful. Don't you agree?

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

#460

Post by zppln »

Getting kind of tired of these idea that people should apologize for writing in C or C++. I'd much rather have people build useful stuff in whatever languages they're comfortable with, than having them not doing so. Security isn't everything in every application. The usefulness of unsafe code continues to vastly outweigh the costs of the associated CVEs.
Post reply on HN