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

871–880 of 929 posts

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

#871

Post by ncmncm »

sophacles wrote: post #786
ncmncm wrote: post #781

Earlier quoted context omitted.

The topic in this subthread is overbearing Rust evangelists and their effects. To the degree that management pays them any attention -- and a CTO parroting their advocacy in tweets (squawks?) certainly counts -- the threat is real. Other companies' management may be equally affected, in a degree more than just posting idle-hack tweets. Against, the subthread topic is overbearing Rust advocates and, specifically, what…

> Obviously nobody will "lay off all the C++ folks" just because Rust promoters would really like that, and as much as say so 1. If it was so obvious, why did you claim it to be true, and then double down? 2. I have yet to see anyone say or even strongly imply it. The closest I've seen is this thread wherein you take a lot of leaps in reasoning and a very specific path through a large possibility space to divine the…

It is one thing for people to advocate a thing, such as "you should fire all your C++ staff and hire us", and another thing for my employer to obey.

But that difference does not make advocating it less bad, unless they are obviously speaking facetiously and expect it to have no effect. It is very clear people saying it mean it and want that to happen.

Azure CTO's announcement is a success for that advocacy.

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

#872

Post by LtWorf »

supportlocal4h wrote: post #719
LtWorf wrote: post #382

Earlier quoted context omitted.

On the other hand it means you don't automatically get security fixes and have to manually set up CVE monitoring and rebuild your application every time a CVE appears. Of course if it appears in an old version the author won't bother to backport the fix so you will have to bump the dependency to the latest, doing all the API changes that you didn't want to do.

Are we still talking about Rust or have we moved on to general grumbling about life?

Any language with an insufficient standard library and a need to import small modules in large numbers.

rust is one of them.

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

#873

Post by snovv_crash »

pornel wrote: post #527
snovv_crash wrote: post #308

Earlier quoted context omitted.

What's the equivalent in Rust to Eigen, Ceres Solver, OpenCV, JNI and Qt UI bindings? This is my standard stack for C++ and last time I checked Rust couldn't do any of them. This is also my standard stack for building new open source computer vision libraries, growing the available libraries and making my field more locked into C++, increasing the moat Rust would need to cross. Next step, can I compile and deploy for…

Deploying for Windows, macOS, Linux, iOS and Android is way easier with Rust than C(++), because there's one build system and one standard library that supports them all without #ifdefs. The ecosystem takes first-class Windows compatibility seriously instead of having a unix and windows dialects and the unix side saying MS sucks and it's your problem it doesn't compile. The worst part about Rust's cross-platform comp…

Modern C++ has cross platform threads, filesystem access, etc. Unless you're actually trying to use platform specific technology, there's no need for #ifdefs.

For the most part CMake handles the cross platform toolchain issues, so it's just one flag to turn on Release Vs Debug builds, enable LTO, include dependencies etc. Again, it's just platform specific features that require if...endif sections.

The complaints I'm seeing here would be the equivalent of me complaining about Rust's garbage collection, the only difference is that Rust broke everyone's code in removing it while C++ managed to keep almost everything since the 1980s still working.

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

#874

Post by snovv_crash »

sophacles wrote: post #601
snovv_crash wrote: post #331

Earlier quoted context omitted.

If you didn't use C++ with the RAII paradigm, and had to write your own new/delete, your previous C++ experience isn't representative of the complexity of dealing with C++ since C++11. The new standards are a massive upgrade, and now a lot of other things are starting to get major quality of life improvements too (eg. template metaprogramming)

This is a really good point. Just like the Great and Powerful oz telling us not to look behind the curtain or you'll see a goofy old man - C++ is quite mighty if you don't look over there at the other stuff.

Rust only released 1.0 in 2015. If you want to complain about pre-C++11 features, I would like to complain about Rust's garbage collector.

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

#875

Post by dusklight »

gpm wrote: post #228
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…

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…

what do most people use for a generic graph / tree library in rust?

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

#876

Post by eloff »

_gabe_ wrote: post #770
slashdev wrote: post #722

Earlier quoted context omitted.

I think I hit a nerve with this one. If you put out a job ad for any mainstream language (Java, JavaScript, C++, among others) you're inundated by applicants who have no business even working in this industry. If you put an esoteric language like Elixir or Rust, you get a smaller but much higher quality pool of applicants. That's my personal experience, I don't have hard data to back it up. Paul Graham once wrote abo…

> I think I hit a nerve with this one. It does tend to grate on people when you have developers from a certain community going and calling anybody that doesn't agree with their "One True Way" inferior and not loving their craft. This is literally the No True Scotsman fallacy to a tee. You're essentially saying, "Only a true programmer that loves their craft would use Rust. Clearly if you're not using Rust, you're not…

No, if you're paying attention, what I'm saying is there is no financial incentive to learn Rust, it's not going to help land you a job. You won't learn it in college, you won't learn it at work. So if you know Rust it's because you enjoy your craft enough to invest your own time in learning it just because you're curious about it. So given no other data points, I can guess that the Rust programmer is better than the C++ programmer and be right more often than not. That's not a radical statement, it's pretty intuitive when you think about it. It's not specific to Rust either. I can say the same of any esoteric language. When I see languages like that on a resume, that's a positive signal, even when hiring for C++.

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

#877

Post by orlp »

gpm wrote: post #718
fulafel wrote: post #684

Earlier quoted context omitted.

I meant counted references that were mentioned as an alternative in the GP comment. A generation count indeed could mitigate "use after free" style bugs, but may have a high false negative ratio if many/most objects have same generation. But a glance at slotmap docs didn't yield any hits for a generation I'd being used, do you have a specific link?

> I meant counted references that were mentioned as an alternative in the GP comment. The main problem with reference counted pointers is detecting cycles. Rust doesn't have a cycle detector, but only a concept of "weak" pointers that don't prevent the object they're pointing at from being destroyed, just detect if it has been. This works fine if you have a tree with parent pointers, you make the parent pointers weak…

Hey, slotmap author here.

Once I get around to slotmap 2.0 (as noted by my inactivity, I haven't had much of the good free time + energy combination last year), the default behavior will be to leak the memory of a slot after 2^31 alloc/free pairs in that slot rather than wrapping around. You can still get the old wrapping behavior, but the default will be to never, ever allow spurious references, at the cost of leaking a couple bytes of memory once in a blue moon if you have heavy, heavy churn. That means, amortized, each insertion will leak 3.726 nanobytes if you're storing u32s, which is a fun unit. Note that if you destruct the slotmap the memory is reclaimed of course, I just mean that slotmap itself will not use that piece of memory again.

> The trade off is that there's more overhead than I think you're imagining.

I don't think the overhead is as large as this implies. For SlotMap the memory overhead is ~4bytes plus alignment per element, and insertion/deletion is only a handful instructions and one branch extra compared to a vector push:

https://docs.rs/slotmap/1.0.6/src/slotmap/basic.rs.html#349

An index adds one extra branch compared to a normal index:

https://docs.rs/slotmap/1.0.6/src/slotmap/basic.rs.html#538

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

#878

Post by orlp »

lenkite wrote: post #260
gpm wrote: post #228

Earlier quoted context omitted.

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…

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.

Hey, slotmap author here.

Last year has been a bit rough and I didn't have a whole lot of free time and energy to work on projects at the same time.

That said, I don't believe any of the open issues on slotmap are of immediate need of attention, they are mostly minor feature requests/incremental improvements.

I do have a slotmap 2.0 in the planning that will include most of these improvements and allow further customization and control of the number of bits used for index/generation as well as what to do when the generation would wrap around (either leak that specific slot or allow a spurious reference with a (very) old key).

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

#879

Post by dang »

TedShiller wrote: post #88

Has he ever heard of kernels or device drivers? Probably not.

Hey, could you please stop posting unsubstantive comments to HN? You've been doing it a lot, unfortunately, and we have to ban that sort of account because it's not what this site is for and destroys what is for.

If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

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

#880

Post by scaredginger »

archi42 wrote: post #706
scaredginger wrote: post #582

Earlier quoted context omitted.

Why would you design a list this way? So many things are wrong here; to name just a few: 1. Pointers work fine, you're not solving any problems here. 2. You can't rebind references in C++, so you wouldn't be able to delete nodes 3. Even with this insane approach, why would you use inheritance over a sum type? 4. Extra allocations or statics are needed to hold sentinels. As for why this wouldn't work in Rust, in addit…

I was just wondering how to do that without using 'unsafe' rust. 1. Dereferencing raw pointer is unsafe; but maybe not necessary? 2. `int main (void) { int a = 1; int b = 0; int &ref = a; ref = b; return b; }` 3. union access is unsafe 4. the cost of not having nullptr or similar Obviously a linked list is trival to implement with pointers; but at least in C++ a naive linked list implementation can easily produce lot…

I feel sorry for your coworkers
Post reply on HN