Live data from Hacker News

Ask HN: What is the state of C++ vs. Rust?

news.ycombinator.com

131–140 of 156 posts

Re: Ask HN: What is the state of C++ vs. Rust?

#131

Earlier quoted context omitted.

The words "SIMD", "intrinsic", "__m64", "__m128" do not occur in the C11 draft text; the word "vector" occurs once in example code for an array-with-length struct. http://www.iso-9899.info/n1570.html Intrinsics are not library functions - they would hardly provide the desired performance benefit if they were. Intrinsics are "magic" functions that the compiler has built-in support for, and thus I would call them langu…

I don’t know why authors of GCC invented that non-standard extended C dialect, you better ask them. In Visual C++, the prototype of that intrinsic is valid C99 code: extern __m256d __cdecl _mm256_permute2f128_pd(__m256d, __m256d, int);

Which library contains the definition of "_mm256_permute2f128_pd"?

The likely answer is "none", as these are built-in to Visual C++ in a similar way to GCC, with only superficial differences such as an apparent lack of indirection to some __builtin_foo.

https://msdn.microsoft.com/en-us/library/26td21ds(v=vs.100)....

"An intrinsic is a function known by the compiler that directly maps to a sequence of one or more assembly language instructions. Intrinsic functions are inherently more efficient than called functions because no calling linkage is required."

https://msdn.microsoft.com/en-us/library/y0dh78ez(v=vs.100)....

"The use of intrinsics affects the portability of code, because intrinsics that are available in Visual C++ might not be available if the code is compiled with other compilers and some intrinsics that might be available for some target architectures are not available for all architectures."

Re: Ask HN: What is the state of C++ vs. Rust?

#132

> But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether. There is no "ignoring legacy C++", when you will have to deal with this or that library written 10/15 years ago. C++ is a language where you can't just ignore some parts of it just because they are inconvenient. As for C++ vs Rust, Rust is memory safe, C++ is not and will never be despite all the bells and whistl…

What is "memory safe" for you? If you use C arrays and raw pointers in your C++17 code, it's definitely not memory safe, but the main problem is that it's not modern C++.

Re: Ask HN: What is the state of C++ vs. Rust?

#133

Earlier quoted context omitted.

That's not a code name I've ever heard of: https://en.wikipedia.org/wiki/C%2B%2B17 C+0x was what turned into C++11. The 0x part was just a placeholder for 08 or 09, but it actually ended up taking a few years longer to ratify. Maybe people confuse C++11 with C++0x to get C++0x11.

Yes, the OP used C++0x11 when he probably meant either C++11 or C++0x. By chance, C++0x11 happens to be the hex encoding of the next expected C++ revision. My admittedly content free joke was an attempt at pointing out the error.

Yeah, never can tell how literal people are being around here.

Re: Ask HN: What is the state of C++ vs. Rust?

#134
post #66

Earlier quoted context omitted.

Whatever happened to learning something to broaden your view? I doubt I'll get a job in Clojure anytime soon - but learning it has been the biggest eye opener to me as a programmer in the last 5 years. > The answer to all these questions seems to be "no". In conclusion you shouldn't be learning it and good luck to the company trying to hire people for Rust positions? You're saying you should only learn what the indus…

Learning something to broaden my view is one of my favourite things to do. Except "something" is not a programming language. If there's a worthwhile project that I want to contribute to, I will learn Rust. At least in automotive the industry is not necessarily pushing towards specific tools, they have constraints that limit choices to particular languages.

Not that long ago, the idea of trying to get into the automotive industry with a web background would have been laughable. Now, I frequently get inquiries from auto companies interested in my JavaScript experience, despite the fact that I left the Detroit area a few years ago. Even the auto industry changes when faced with a better way to do things, and its constraints actually seem to align well with Rust's core design principles. All it takes is a first mover.

Re: Ask HN: What is the state of C++ vs. Rust?

#135
post #106
post #72

Earlier quoted context omitted.

Out of curiosity, do you have (open-source) examples of C++ projects that do it right? In my numerous-though-irregular years as a C++ programmers, I haven't seen any project producing code that's convincingly safe. I won't list all the pitfalls of C++ here, but, well, who doesn't have war stories of bugs-because-of-aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-pointer-is-still-being-use…

Don't have a link to such a project, I didn't really look. I am seriously considering starting one though, perhaps it's necessary.

I am genuinely interested.

Also, I just realized that doing this right might require dropping lots of legacy C++ code, more or less as would starting in Rust.

Re: Ask HN: What is the state of C++ vs. Rust?

#136
post #82

Earlier quoted context omitted.

> I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me. May i ask why memory issues are not a pressing issue for you? having to hunt down memory corruptions / access to dangling pointer / memory leaks is a pretty frequent occupation for me (as a C/C++ developer). There are tools like v…

Probably because people with experience know how to handle these things up front so that they don't occur. I've been writing C and C++ for a decade now and for the last 6 years or so i have had very few issues which stem from any of the things you mention.

> Probably because people with experience know how to handle these things up front so that they don't occur. bla bla bla.

especially if you are dealing with a large code base with shifting requirements, where the code has been written over a long time by a lot of people; in a real world system you just can't make these assumptions regarding 'skill' at all. Even skilled people will have to deal with issues like invalidated iterators / containers that have been modified in non obvious ways / lots of other goodies as well.

there are a lot of projects/products like this, my guess is that this is the case with the majority of projects.

Re: Ask HN: What is the state of C++ vs. Rust?

#137

> But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether. There is no "ignoring legacy C++", when you will have to deal with this or that library written 10/15 years ago. C++ is a language where you can't just ignore some parts of it just because they are inconvenient. As for C++ vs Rust, Rust is memory safe, C++ is not and will never be despite all the bells and whistl…

What is "memory safe" for you? If you use C arrays and raw pointers in your C++17 code, it's definitely not memory safe, but the main problem is that it's not modern C++.

Even modern C++ isn't memory safe. Most straightforward example is to move a uniq_ptr, which makes it a nullptr, ready to be dereferenced and cause UB.

Re: Ask HN: What is the state of C++ vs. Rust?

#138

Earlier quoted context omitted.

I don’t know why authors of GCC invented that non-standard extended C dialect, you better ask them. In Visual C++, the prototype of that intrinsic is valid C99 code: extern __m256d __cdecl _mm256_permute2f128_pd(__m256d, __m256d, int);

Which library contains the definition of "_mm256_permute2f128_pd"? The likely answer is "none", as these are built-in to Visual C++ in a similar way to GCC, with only superficial differences such as an apparent lack of indirection to some __builtin_foo. https://msdn.microsoft.com/en-us/library/26td21ds(v=vs.100).... "An intrinsic is a function known by the compiler that directly maps to a sequence of one or more asse…

I know how intrinsic work, thanks. Use them a lot in C++.

C99 language spec says nothing about the things you’re talking about. It only specifies the language, not how C compilers implement various features.

From the programmer’s point of view (except when the programmer works on the compiler itself), intrinsics are just C library functions, only inline, and very performant if done right. Fully compliant with C99 and C++ language specs.

Re: Ask HN: What is the state of C++ vs. Rust?

#139

Earlier quoted context omitted.

What is "memory safe" for you? If you use C arrays and raw pointers in your C++17 code, it's definitely not memory safe, but the main problem is that it's not modern C++.

Even modern C++ isn't memory safe. Most straightforward example is to move a uniq_ptr, which makes it a nullptr, ready to be dereferenced and cause UB.

How does it happen? Non-const unique_ptr& used as a function parameter?

Re: Ask HN: What is the state of C++ vs. Rust?

#140

Earlier quoted context omitted.

> Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had). I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, e…

Surprisingly, it's already not that painful. I recently wrote a tiny JSON service with Iron and Diesel and it wasn't that much longer or complex compared to Go. The biggest headache was figuring out how Diesel works, and it would have been a lot easier using raw queries with something like rust-postgres (which would be the way to go in Go or Node). Once the ecosystem matures a little bit more I don't see why Rust wou…

Macros 1.1 should make working with Diesel easier for the programmer, compared to the incompatible compiler plugin APIs.

I think the sweet spot with rust might leveraging metaprogramming, for instance, generating a REST database API from a schema and having the resulting code compile to something faster the most languages like python or ruby, and at least on par with Go, Java, or swift.

Post reply on HN