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

591–600 of 929 posts

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

#591

Post by ModernMech »

petmon wrote: post #422
baq wrote: post #402

Earlier quoted context omitted.

> 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.

It's common in other programming languages for string literals to have type string. It's weird and confusing that they do not in both Rust and in C++.

It’s weird and confusing, but also performant. Remember Rust is first and foremost a systems language. You can get a 10x speed boost by using the right string (str vs string) in certain circumstances.

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

#592

Post by pizza234 »

perlgeek wrote: post #519
pizza234 wrote: post #506

Earlier quoted context omitted.

This is a tricky subject. Rust being a low-level library, adding something means inherently choosing a preferred approach to a problem rather than another, which may be disagreeble. The consequence is that there would be still the sub-sub-dependencies problem, because the author of a crate may decide that the stdlib implementation is not appropriate for the use-case (Rust is low-level; low-level development is typica…

Clearly different people have different needs. Having two distinct "products" could help here. There could be a "bare rust" that is minimal and unopinionated, and used by those that need a small footprint, for example. A "battery included rust" could have common solutions to common problems that are hard to solve with "bare rust", at the expense of making choices that are best avoided for "bare rust". My current outs…

> Having two distinct "products" could help here. There could be a "bare rust" that is minimal and unopinionated, and used by those that need a small footprint, for example

There is already, it's the nostd.

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

#593

Post by Jataman606 »

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).

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

#594

Post by sophacles »

noobermin wrote: post #213
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.…

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT…

Buggy whip manufacturers were also concerned that the car was just a conspiracy to drive them out of business.

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

#595

Post by shadowgovt »

ncmncm wrote: post #408
shadowgovt wrote: post #218

Earlier quoted context omitted.

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.

It's smelly if you have enough people on the team to know what new code versus old code smells like.

If your developers are coming to the table with some C++ tutorial books written a decade ago, good luck. Invest in a decent linter and opinionated format checker.

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

#596

Post by ChrisSD »

gpm wrote: post #278
lenkite wrote: post #260

Earlier quoted context omitted.

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

I just glanced through the small number of open issues, and none seem like actual issues so much as potential improvements. The maintainer seems to still be around, and I've never found that a standard library is faster at merging improvements than third party libraries, rather the exact opposite (for good reason, the standard library needs to avoid breaking changes at nearly all costs). While I think there are valid…

Yeah, I'd emphasize that moving something to the standard library doesn't magically solve maintenance issues. In fact if the community can't even maintain something then that's a strong argument for it not to be moved somewhere that's much harder to contribute to, whose maintainers have a lot else on their plate and where any API mistakes are for forever.

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

#597

Post by sophacles »

ncmncm wrote: post #400
Ar-Curunir wrote: post #261

Earlier quoted context omitted.

No Rust Evangelist is out there thinking, "Hm, how do I put C/C++ developers out of business today"

I see you do not have much contact with Rust evangelists.

"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?

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

#598

Post by thisiswrongggg »

slashdev wrote: post #549

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

>> The hiring market is way better for Rust because it's not mainstream.

The ratio of C++/rust jobs where I am (EU country) is 5564/54. And these 54 jobs are mostly in cryptocurrencies.

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

#599

Post by Jensson »

nindalf wrote: post #587
galangalalgol wrote: post #567

Earlier quoted context omitted.

If you're commanding officer orders a bayonet charge in the late 19th century it is safe to say they don't understand the change rifles have brought to the fight. Reference Picket's charge.

I was saying a commanders accuracy with a rifle isn’t relevant to their ability to decide tactics or strategy. Nothing you’ve said contradicts what I said.

But the commander hasn't tried a machine gun and thinks that a bayonet charge will still work like it did before.

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

#600

Post by kllrnohj »

sanxiyn wrote: post #159
kllrnohj wrote: post #136

Earlier quoted context omitted.

Is anyone attempting to do the same with C though? Carbon & cppfront, if successful, would only "save" C++. C would still be left out to dry. Then again, the C committee is also pretty much phoning it in and has been for quite a while now.

Yes. Microsoft Research is working on "Checked C": https://www.microsoft.com/en-us/research/project/checked-c/ As a test, someone ported FreeBSD's networking stack to Checked C. It was easy and there was no overhead to performance and binary size.

That's pretty interesting. It really undersells itself in the intro description where it sounds something more like clang's ubsan -fsanitize=bounds, but in actuality it's adding other features as well including generics. Although that said, it's somewhat odd that memory lifetime is entirely ignored by it. All the changes seem to be laser focused on bounds checks and bounds checks only (with generics being to eliminate `void*` specifically so that, you guessed it, bounds checking can be done)
Post reply on HN