Live data from Hacker News

Move, simply

herbsutter.com

81–90 of 96 posts

Re: Move, simply

#81
post #67

It's 2020. We have planetary scale computers that do exaflop computations and AIs that can slaughter humans at almost any strategy game. The entire stock market is essentially driven by AI. Drugs are being developed by AI. Bitcoin is consuming more electricity than Ireland. And yet programmers are still fucking around with move constructors, copy semantics, and host of other horseshit foisted upon us by people who th…

> exaflop computations Most certainly written in c++ > and AIs that can slaughter humans at almost any strategy game. Guess in what language is trnsorflow written > Bitcoin Ditto

> Most certainly written in c++

Totally beside the point!

Actually, FORTRAN mops the floor with C++ when it comes to bigtime numerical computations on supercomputers. And they're all running kernels written in good ole C.

Most of the FAANGs are running absolute shittons of Java, Javascript, PHP, and Python. Also running kernels written in C.

> Guess in what language is trnsorflow written

Derp, tensorflow has to interact with GPU drivers which are all C++ interfaces. Btw it generates shader code which is definitely not C++, but some weird vendor languages, which don't have any of this move constructor related garbage.

> Bitcoin

Ditto

Actually the vast majority of bitcoin's computational load is done by ASICs.

Congratulations, you missed the whole point. My point wasn't what languages those things are written in (your Red Herring, not mine), but the fact that we spend an absolute metric shitton of computation on other things, but still expect slow, dumb programmers to fret over niggling details, usually screwing it up in the process, when this task would be far better served by throwing some god damn computational resources at it--you know the ones we waste on O(N^2) compilation tasks and parsing header files over and over and over again....

sigH

Re: Move, simply

#82
C++: a language where you need 10 friggin lectures just to learn to pass variables around. I'm sincerely sorry for anyone who is forced to use this mountain of flaws of a language out of legacy reasons. We as humanity need a plan to reduce the number of C++ lines being written, then to phase out C++ code altogether. This sick roadshow by the ISO committee (and that numbskull Stroustrup) of adding features without fixing any bugs has got to stop. C++ is just horrible, and using it is a waste of time.

Re: Move, simply

#83
post #29

And this is about the point where I finally gave up on C++, I just wish I could get the time I spent learning all the rules and all their exceptions back. It has now morphed into a language where today's optimal code looks horribly inefficient by yesterday's standards. Which adds another layer of uncertainty to what was already a pretty serious mess of a language. Calling this simple is about as silly as it gets. Tha…

But the world is built on C++ and there are no alternatives for it. C is too low level and Rust has garbage collector which may not be fit for the domain C++ is suitable for. No alternatives in the domains where C++ shines.

Re: Move, simply

#84
On a slightly different note, why is the standard not free. I mean not the C++20 but atleast the C++11 standard should be available freely as a single authoritative source.

Re: Move, simply

#85
post #80

This is what I like about Rust: there are no copy constructors. There are no "moved-from" object values. Moves are guaranteed to be nothing more than a shallow `memcpy`. Structs aren't even copyable unless the author explicitly says so, so if a move compiles, I know it's safe and efficient.

But the language is garbage collected, that's not desirable in the domain c++ operates

Re: Move, simply

#86
post #29

And this is about the point where I finally gave up on C++, I just wish I could get the time I spent learning all the rules and all their exceptions back. It has now morphed into a language where today's optimal code looks horribly inefficient by yesterday's standards. Which adds another layer of uncertainty to what was already a pretty serious mess of a language. Calling this simple is about as silly as it gets. Tha…

But the world is built on C++ and there are no alternatives for it. C is too low level and Rust has garbage collector which may not be fit for the domain C++ is suitable for. No alternatives in the domains where C++ shines.

Ada 2012?

Perhaps no other _popular_ alternatives but still there are alternatives.

Re: Move, simply

#87
post #29

And this is about the point where I finally gave up on C++, I just wish I could get the time I spent learning all the rules and all their exceptions back. It has now morphed into a language where today's optimal code looks horribly inefficient by yesterday's standards. Which adds another layer of uncertainty to what was already a pretty serious mess of a language. Calling this simple is about as silly as it gets. Tha…

But the world is built on C++ and there are no alternatives for it. C is too low level and Rust has garbage collector which may not be fit for the domain C++ is suitable for. No alternatives in the domains where C++ shines.

Rust has as much garbage collector as C++ has share_ptr. Put simply, it doesn’t have.

Re: Move, simply

#88
post #17

C++ “move” semantics are simple, but they are still widely misunderstood. No, they aren't simple and the fact that are still widely misunderstood is basically proof of that. Maybe, just maybe, it has something to do with stuffing rvalue references, perfect forwarding and the whole universal-references-template-clusterfuck into one and the same syntax. [1] The default compiler-generated move can leave behind a null sp…

I mean requiring an explicitly defaulted move constructor or something to that effect I wouldn't mind, but personally I also think it's beyond obvious that if you move from a smart pointer that it's going to hold a nullptr after that. I wouldn't consider that hard to understand (or surprising) at all compared to something like even relatively simple thread synchronization, something that comes up for pretty much any native developer eventually these days.

Re: Move, simply

#89
post #29

And this is about the point where I finally gave up on C++, I just wish I could get the time I spent learning all the rules and all their exceptions back. It has now morphed into a language where today's optimal code looks horribly inefficient by yesterday's standards. Which adds another layer of uncertainty to what was already a pretty serious mess of a language. Calling this simple is about as silly as it gets. Tha…

@codr7 - By chance I was just browsing your projects yesterday!

g-fu ¹, a Lisp dialect in Go, is a marvel. Other languages you've been creating (gfoo, cfoo, lila) are tastefully done too.

So I'm in total agreement with you about the monstrosity that is modern C++. Nobody would have designed such a language from scratch.

It seems to be a common fate of popular and long-lived languages (or projects, companies even), that it grows into a complicated monster that would horrify its original creator.

¹ https://github.com/codr7/g-fu

Re: Move, simply

#90
post #80

This is what I like about Rust: there are no copy constructors. There are no "moved-from" object values. Moves are guaranteed to be nothing more than a shallow `memcpy`. Structs aren't even copyable unless the author explicitly says so, so if a move compiles, I know it's safe and efficient.

But the language is garbage collected, that's not desirable in the domain c++ operates

Rust completely dropped GC support in 0.12 — which was released on 9th October, 2014. That happened more than 5 years ago.
Post reply on HN