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

441–450 of 929 posts

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

#441

Post by ghoward »

howinteresting wrote: post #366
ghoward wrote: post #135

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…

No one's talking about your personal project here. The audience is teams of people building software to be used in production.

Except that the tweet was pretty absolute. He could have had a reply tweet with something like "unless you have to or you're doing a hobby project." I took issue with the absolutism.

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

#442

Post by eru »

px43 wrote: post #206
a-dub wrote: post #47

Earlier quoted context omitted.

absolutely! came here to say just that. also the excellent book "windows internals", which is kind of like the bsd red book, or the magic garden svr4 book, but for systems derived from the windows nt kernel. but perhaps his best work is this: https://learn.microsoft.com/en-us/sysinternals/downloads/blu... a screensaver that produces a realistic blue screen (kernel panic) for the version of the operating system and ke…

Also IMO it's best to avoid his fiction books, Zero Day etc. It's been about a decade since I read it, but it was the first book I've ever read where I felt uncomfortable with the level of detail the author went to when describing the breasts of every female character. The random awkward sex scenes thrown in for no reason was a weird choice. Most importantly, there's also a complete lack of understanding of the under…

> Most importantly, there's also a complete lack of understanding of the underlying motivations behind both Islamic terror organizations, and cyber crime groups.

Compare https://www.gwern.net/Terrorism-is-not-about-Terror

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

#443

Post by the__alchemist »

dynamite-ready wrote: post #418

I think this is a silly idea. There are still loads of questions surrounding Rust. Especially about it's practicality... There are articles denigrating the likes of the trait and async systems on HN almost every day. And even ignoring that argument, any language is viable, so long as it can be used to build what you want to build.

The nice thing about the trait and async problems are you can ignore them if you minimize and/or are selective with dependencies.

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

#444

Post by Ygg2 »

vasama wrote: post #387
Ygg2 wrote: post #292

Earlier quoted context omitted.

> Even a doubly-linked list is impossible to get through the borrow checker. https://github.com/rust-lang/rust/blob/master/library/alloc/... It's part of standard lib. And you don't get more idiomatic than that.

That looks like an allocating container. Probably the most useful property of linked lists and other node based data structures is the ability to make them intrusive and to avoid dynamic allocation. In some domains you just don't have a runtime allocator available to you, so this library would be useless.

> That looks like an allocating container

Depends what you mean by that. It has 2 pointer to other nodes and element on the heap (EDIT: Not stack). It's bog standard double linked list.

If you're looking for intrusive lists those a very niche data structure.

https://docs.rs/intrusive-collections/latest/intrusive_colle...

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

#445

Post by pkolaczk »

ajross wrote: post #223
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…

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…

> for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already. Use your smart pointers. Use your containers. Follow the rules everyone tells you about not using bare new/malloc. And... it's basically just as safe

This is "don't write bugs, lol, and you're safe" argument. It has been demonstrated many, many times on HN, that you can cause UB in C++ using just high-level standard containers and smart pointers, without doing anything suspicious with raw pointers. Bugs of that kind are virtually impossible to detect during a typical code-review. So it is not "just as safe". It is tad safer than C, but nowhere near Rust.

> But the space between "Need to stay away from C++" and "Should probably just have written it in Go" seems to be getting smaller and not larger.

That might sound as a rant, but IMHO the designers of Go sadly made some odd choices in areas unrelated to memory management, which put me off from Go. Go is not just Rust with borrow checker replaced by tracing GC. It is a completely different language, with a much different "feel":

* some syntax choices that seem to have no justification other than "we wanted to make it look different than other languages" (ok, one can get used to it)

* no sum types / unions / enums

* code generation / copy pasting instead of proper macros

* error handling not really better than in C (caused by no sum types)

* visibility controlled by character case (so when you want to unprivate sth, you have to find-replace all occurrences; I guess this stupid idea originates from Python)

* unused stuff is hard error (terrible for prototyping)

* you don't need generics, but we've just added them anyways ;d

* no tools for controlling mutability/immutability/sharing (which is still useful in GCed languages)

* data races possible, accidental mutable sharing possible

* no RAII for deterministic destruction of non-memory resources (`defer` doesn't even come close)

* package/dependency management IMHO subpar compared to cargo

When trying to learn Go, I had exactly same feeling as when I first learned Java (after C++) - that the authors of the language designed it for people less capable than the creators themselves. So I didn't like it.

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

#446

Post by abareplace »

cutierust wrote: post #171
jiggawatts wrote: post #120

Earlier quoted context omitted.

In theory yes, but there's a lot of quirks and limitations. The main issues are: - Rust string types assume UTF-8, but Windows generally uses double-byte Unicode encodings. The Windows string type isn't even UTF16, because it can include invalid code points. This means that at every API call there will be the overhead of converting the string encodings and having to "deal" with invalid strings somehow. - Rust compila…

Pretty sure most win32 now has an alternative utf8 function?

No, they don't. We typically use the UTF-16 functions (with the W suffix).

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

#447

Post by fathrowaway12 »

diego_moita wrote: post #198
foomatic wrote: post #184

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

It's not _that_ complicated these days. structs, classes strings, vectors, hash maps, unique_ptr, references, non-owning pointers where it makes sense, basic templates. Boom. You also need basics like ownership, order of construction/destruction, value categories, move semantics, special member functions, RAII, etc. All the fancy perfect forwarding and template magic are wrapped up in libraries most don't need to think to hard about. Most people rarely write code that actually manages resource lifecycle directly. It's all wrapped up in RAII.

If you read the whole spec, it looks super complicated. But getting to a mental model that works in 99% of cases is not _that_ hard.

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

#448

Post by Ygg2 »

kramerger wrote: post #332
virgulino wrote: post #251

You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... He extensively reverse engineered and documented "Windows Internals" details before joinin…

Well... He is also written some horrible fiction novels, so the guys is not perfect.

Why are fiction novels relevant to field of computer languages? This seems like ad hominem.

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

#449

Post by pjmlp »

becurious wrote: post #201
jiggawatts wrote: post #120

Earlier quoted context omitted.

In theory yes, but there's a lot of quirks and limitations. The main issues are: - Rust string types assume UTF-8, but Windows generally uses double-byte Unicode encodings. The Windows string type isn't even UTF16, because it can include invalid code points. This means that at every API call there will be the overhead of converting the string encodings and having to "deal" with invalid strings somehow. - Rust compila…

I tried to spin up a project with the Microsoft Rust bindings but for what I needed (DirectX12) there’s a lot of necessary helpers in the header files that haven’t got ported over there. And working from one of the samples it was nowhere near as reliable as the C++ version. Beyond ‘oh the C++ code isn’t catching errors’ - every HRESULT was checked as it was using the WinRT bindings. Kenny Kerr has done an excellent j…

I disagree with the "excelent job" for C++.

Using C++/WinRT is like going back to developing COM with Visual C++ 6.0, but I guess that is what WinDev craves for.

They should have provided a proper development experience for IDL files, automatic merges of generated code, and only then, deprecate C++/CX.

Not deprecating C++/CX, and leaving us with editing IDL files with a Notepad like experience, and manually merging generated code.

Rust/WinRT is even worse in regards to WinUI tooling.

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

#450

Post by pjmlp »

alexeiz wrote: post #394

The Azure CTO knows as much about C++ as to easily confuse it with C. Anybody who say C/C++ is not aware that C++ is vastly different from C and it can't be combined into a single "language" like this. Mark Russinovich puts his ignorance on full display here.

On the contrary, this kind of critic only reveals the ignorance of English grammar rules regarding the use of /.
Post reply on HN