Live data from Hacker News

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

twitter.com

171–180 of 929 posts

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

#171
post #107

Can you even use Rust for Windows GUI programming? Is it a practical choice at all for interfaces?

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?

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

#172

The C/C++ people hate it when you call it C/C++.

I personally don't see this level of pedantry from the people I work with. Even if C90/C99/C11/C++98/C++11/C++17/etc are all different, we understand people use "C/C++" to mean "that pervasive family of languages which most systems and libraries are built on".

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

#173

agreed, zig only from now on

Zig is production ready? I must have missed the 1.0 release announcement

There is nothing wrong with using Zig in production before 1.0. You just need to weigh cost and benefit, including cost of dealing with breaking changes.

For example, Dropbox started to use Rust in production before 1.0, see https://blog.convex.dev/a-tale-of-three-codebases/

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

#174
post #164

It's also time to have a spec & alternative free implementation for Rust. Multiple compilers and standard library implementations for C is the reason why it's so ubiquitous in the embedded space and where Rust can do a lot of positive impact. As of now, Rust does not have a spec: https://users.rust-lang.org/t/where-is-the-rust-language-spe...

> Multiple compilers and standard library implementations for C is the reason why it's so ubiquitous in the embedded space and where Rust can do a lot of positive impact.

I agree that Rust needs a specification, but this is post-hoc: C is popular in embedded because it's the systems programming language that survived the 1970s and 1980s, in no small part thanks to the GNU project.

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

#176

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.

Which part of "new projects" did you miss?

Without a roadmap, plan, and policy, I read this as a "maybe someday" tweet. Seems like something Elon Musk would say.

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

#177

Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1]. I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions. [1]: https://en.wikipedia.org/wiki/Sysinternals

No post body was provided.

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

#178

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

I'd pick Rust over "modern" C++ just because I don't have to deal with 15 compilers, 15 IDEs, 15 build systems, decades of language experiments, kind of compiler-flags driven development

Don't worry, the GNU people are looking to fix that.

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

#179
post #151
post #31

Earlier quoted context omitted.

That's a fairly recent thing that some people do as a kind of virtue signaling. The "C/C++ Users Journal" was a very popular publication and no one took issue with its name. Nor do people take issue with Dr. Dobbs which has a "C/C++" section with articles from highly influential members of the C/C++ community. C++ is a complex language, so people invent ways to show how dedicated they are to it, and nowadays that mea…

> That's a fairly recent thing that some people do as a kind of virtue signaling. If by recent you mean well over 20 years ago. When I began learning C circa 2000, I used to hang out on comp.lang.c, and "C/C++" was very much frowned upon. And for good reason--people felt entitled to ask C++ questions in a C newsgroup, which was and remains a poor idea. Even if they were asking questions relevant to both, e.g. regardi…

Not seeing evidence of your claim. A simple search on comp.lang.c for C/C++ turns up plenty of results and no one, not a single person, is calling it out. Infact there's plenty of discussion on an almost daily basis discussing the two languages almost seamlessly. Looks like there's even a alt.comp.lang.learn.c-c++ newsgroup as well.

For reference I also did a search from 1998 to 2002... once again no one cares or is objecting to the term C/C++ and that term is used quite often. From this search I also just learned that Microsoft's own compiler uses the term "C/C++".

Furthermore, if something is relevant to both languages, such as a question involving pointers, why would it be a bad idea to ask about it in a C newsgroup? If anything, it's preferable to ask a question that is pertinent to both languages, especially one involving pointers, in the C newsgroup.

Certainly asking a strictly C++ question in a C newsgroup would be off-topic and rightly so, but asking a question about pointers or other low-level details that are applicable to both languages is perfectly fine in a C newsgroup.

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

#180
post #109

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

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…

No post body was provided.
Post reply on HN