[HN Gopher] C++20, How Hard Could It Be
___________________________________________________________________
C++20, How Hard Could It Be
Author : pyler
Score : 280 points
Date : 2022-09-25 09:11 UTC (13 hours ago)
(HTM) web link (docs.google.com)
(TXT) w3m dump (docs.google.com)
| kwant_kiddo wrote:
| I started reading the link "bans everything to start with anyway"
| in the slides:
|
| https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...
|
| And I noticed the ban of shared_ptr and <chrono>. I know the use
| of shard_ptr should be done cautiously, but just banning it from
| use? How do the Chromium devs solve a problem that requires
| shared ownership? I guess you can come a long way with singletons
| and consumer/producer queues. But are raw-pointers just used
| instead of shared_ptr when shared ownership is needed?
|
| Also banning use of <chrono> ?
|
| Can someone try to explain the possible reasons?
| adzm wrote:
| Chromium has an existing ecosystem with a variety of smart
| pointers already.
| kwant_kiddo wrote:
| yeah I found this when stumping upon
| https://source.chromium.org/chromium I guess that makes sense
| as well.
| bialpio wrote:
| As for <chrono>, the link you provided also has a (short)
| justification behind the decision:
| https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...
|
| Regarding smart pointers, not sure if you also found this:
| https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...
| mnahkies wrote:
| My introduction to c++ was a variant of this book
| https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/0672...
| when I was about 12. However one thing that really stuck with me
| was a professor at university saying "if you think you know c++
| that just means you don't know it well enough to know you don't
| know it"
| soheil wrote:
| The original quote is from Feynman about quantum mechanics.
| karolsputo wrote:
| Your comment reminded me of a beautiful post by Peter Norvig
| [0].
|
| He covers learning programming and books like the one you
| mentioned.
|
| [0] https://norvig.com/21-days.html
| epinephrinios wrote:
| https://reasonandmeaning.com/2019/11/03/socrates-i-know-that...
| imajoredinecon wrote:
| @dang: Would it be better to have the first part of the title be
| "Google Chrome" or maybe "Chromium"? The content doesn't deal
| with Google's internal codebase.
| iamstupidsimple wrote:
| @dang doesn't work, you're best off emailing hn@ycombinator.com
| intelVISA wrote:
| Expected the worst but pretty happy with Kasting's breakdown
| here. Admittedly most of these issues are self-inflicted but at
| least it's better than the usual "C++ bad" meme
| camdenlock wrote:
| I'm usually somewhat critical of Rust... but not when I encounter
| C++. What an over-engineered shitshow. Rust looks like a simple
| set of useful tools compared to C++'s convoluted warehouse of
| horrors.
| ncmncm wrote:
| What you don't use, you don't understand.
| JonChesterfield wrote:
| Way too many of those points are "this sane looking code no
| longer works, fix by rewriting it to be significantly longer"
| spoiler wrote:
| I kinda feel bad for taking this jab at C++, since it feels a
| bit below the belt... But that's kinda C++'s thing, isn't it?
|
| You can either do the correct thing, or the succinct thing.
| There's hardly ever a satisfying compromise between the two
| either. Obviously, we want to do the correct thing most of the
| time, so that's why C++ ends up being full of ceremonious
| implementations in practice.
|
| And alas, they're usually equally ceremonious to use, because
| abstractions in C++ are so incredibly leaky because of its poor
| type system.
|
| I'm not sure why that is, but my gut tells me it's all this
| backwards [pseudo]compatibility.
| JonChesterfield wrote:
| That seems a fair observation to me, with the tweak that
| "correct" changes over time. C++ code can be written
| perfectly and still rot as the ecosystem changes, without
| changing the source.
|
| We are really keen on preserving backwards compatibility, but
| break existing code anyway. We will not define a stable ABI,
| but also won't fix stdlib if it breaks ABI.
|
| Also all code definitely has UB in it waiting for a compiler
| change to expose it as wrong and deserving of no longer
| working.
|
| Ceremonious captures the state of the art accurately.
| deadbeeves wrote:
| >C++ code can be written perfectly and still rot as the
| ecosystem changes, without changing the source.
|
| But that's true of any system that depends on other systems
| with lax respect for contracts, or with no contract. You
| can depend on a third-party function get_time() that
| returns the seconds since the program started, and later on
| if its maintainers decide to change it to return a UNIX
| timestamp because they realized the wording was vague
| enough to allow it, any code that makes the wrong
| assumption will break.
|
| C++ is, I would say, quite good as far as backwards
| compatibility goes. The problem IMO is that it's rather
| complex and some of its features have been misunderstood
| over time, such as the meaning of volatile or inline, and
| thus people have been writing subtly broken code that just
| happened to work when they originally wrote it.
| kllrnohj wrote:
| Eh? There's the NVI comparison operator that fits that bill and
| maybe the std::forward_iterator one but the rest? Most of the
| other fixes was less code that's also simpler. Or are you
| getting thrown off by things like the enum slides where it's _3
| different solutions_ all presented on a single slide?
| xyzzy4747 wrote:
| I wonder how long it would take an experienced developer to
| rewrite all of Chrome in Rust. It would probably take a special
| person though who is an expert in C++, Rust, and the codebase.
| superdimwit wrote:
| 30 years?
| xyzzy4747 wrote:
| Why do you think that? How complicated could it possibly be?
| Also as a person becomes more of an expert in a specific
| thing, they make progress much faster (if they remain
| motivated).
|
| Also it's just rewriting the logic. One could theoretically
| write unit tests for every function to make sure the
| inputs/outputs match.
| epinephrinios wrote:
| There are no "special" persons or superheroes. It is all about
| time + money.
|
| If a tech giant wants this to happen - e.g. because memory un-
| safety is mostly the root of all evil - they can use people
| from the current team and throw a few millions on hiring new
| talent.
| schemescape wrote:
| Wow, I didn't know Google banned exceptions in their C++ code,
| but the style guide that is linked indicates that they are indeed
| banned:
|
| https://google.github.io/styleguide/cppguide.html#Exceptions
| NBJack wrote:
| Why does this sound familiar?
|
| https://go.dev/doc/faq#exceptions
| camdenlock wrote:
| Go = GOAT
| DannyBee wrote:
| Yes, they have been banned forever, and not just for size
| reasons.
|
| In the end, it makes code very difficult to reason about.
|
| It was a deliberate design goal of C++ exceptions that
| intermediate libraries/callers/etc do not have to be aware of,
| or handle, exceptions. There is no way to verify or check that
| all exceptions are caught by someone, etc. This is, as i said,
| deliberate.
|
| This is quite nice in smaller systems, where you pretty much
| know every dependency and what calls will do.
|
| But in larger, complex systems, where it is very hard to know
| or control every level of dependency, it is quite painful and
| fragile, because something 37 levels deep might suddenly throw
| new exceptions (or exceptions at all), violate 0 of the API
| guarantees that are being made[1], and start crashing your
| program in edge cases.
|
| Among other things
|
| [1] It's very easy for one library to say "we throw exceptions,
| something must catch them", and the dependent to say "we
| propagate all exceptions, we don't catch them". Even if
| something promises to catch them in the middle, it will very
| quickly get lost as it gets further away from the library
| actually throwing the exceptions.
|
| The fact that you may be able to successfully assign blame or
| root cause to the problem doesn't help - being able to say
| something like "this library 36 levels deep in my dependency
| tree is not following best practices" is not a particularly
| helpful thing for development.
| ncmncm wrote:
| This sounds nice but is not true. The bigger the system is,
| the more value you get from exceptions.
|
| The cost is that cleanup operations have to be in
| destructors. Do that, and exceptions demand almost no
| attention.
|
| Problems show up only when some prima donna declares throwing
| exceptions from what they call isn't allowed.
| gravypod wrote:
| (Opinions are my own)
|
| Google uses absl::Status / absl::StatusOr as a replacement
| for what people would usually use exceptions for.
|
| The benefits:
|
| 1. As an end user of a large library I can tell you exactly
| which calls are "guaranteed" to succeed without learning
| anything else about the code.
|
| 2. It is impossible to ignore a Status/StatusOr which makes
| it impossible to ignore a failure. You have to explicitly
| ignore the return value which is easy to spot in code
| review.
|
| 3. You can return your exception across RPC an boundary
| with added detail so if a caller of your service.
|
| 4. You can (very easily) enrich the Status with metadata at
| every single point. So much so that it is very common.
|
| 5. You can enrich the way "exceptions" works in a way that
| makes sense for your company by changing the structure of
| Status.
|
| Cons:
|
| 1. It is more unnatural than dedicated syntax like
| try/catch.
|
| 2. You can't bubble exceptions up the stack automatically
| so there are macros that do this for you (https://cs.openso
| urce.google/search?q=ASSIGN_OR_RETURN&sq=)
| DannyBee wrote:
| You literally provide no evidence of your view, just
| assertions. Not even reasoned argument or examples. Just
| assertions. Assertions that lots of people who are serious
| experts in c++, library design, etc, are prima donnas.
|
| You see how that isn't particularly helpful or constructive
| to discussion, right?
|
| Maybe you'd like to at least point out the very large scale
| systems that are using and getting benefits from
| exceptions, as you claim exists? I can't personally name a
| single one.
| chrisseaton wrote:
| When a new C++ feature is proposed does the proposer have to
| provide a reference implementation? How can features be missing
| from the major compilers?
| JonChesterfield wrote:
| No. Ideally there would be an implementation before it ships in
| a standard but that's not considered necessary.
| pjmlp wrote:
| Yes to some extent, depends on how one wants to defend their
| paper at ISO, during the several voting sessions.
|
| Even when they do, it is in prototype done by the paper's
| author, not necessarily something that you can merge right away
| into upstream.
|
| Visual C++ is already there in C++20 and increasingly improving
| C++23 support as well.
| chrisseaton wrote:
| I wonder if a feature has been accepted that turned out to
| not be tractably implementable!
|
| I work on Ruby compilers and people often suggest features
| that they don't realise would be catastrophic for performance
| if implemented, or are sometimes literally impossible to
| implement.
| pwdisswordfish9 wrote:
| Does memory_order_consume count?
|
| > people often suggest features that they don't realise
| would be catastrophic for performance if implemented, or
| are sometimes literally impossible to implement.
|
| Oh, that's every language.
| Sharlin wrote:
| Template export was implemented by a single compiler
| vendor, and that served as a cautionary tale for all other
| vendors against trying the same.
| pjmlp wrote:
| Except Visual C++ already has those ideas implemented,
| so....
|
| Even exported templates, as hard as they were, the EDG
| folks actually implemented them, only others decided not to
| follow upon.
|
| The current state with clang is a mix of MIT like license,
| and those that profit from it not caring about upstream,
| even GCC is doing better.
| hi_herbert wrote:
| I'm pretty sure this rethoric is fallacious, most
| VMs/languages are not GPL and have MIT-like licenses and
| yet do not have the issue. It's just that clang lack
| human resources. Compagnies are not really secretly
| maintaining their own fork of clang with full support for
| modern c++. It's not in their economic interest to have
| to fo all tjis engineering. Instead of malice it'd just
| plain mediocrity. Yes there are trillion dollars
| companies that would benefit from better c++ but either
| they use GCC, either they fail to understand that clang
| needs funding by pure and quite universal mediocrity.
| Also the thing is, most languages do not afford to have
| multiple serious implementations because it is
| economically absurd, it divide progress by 2 and
| duplicate the bug surface by 2. GCC at least for the
| foreseeable future is the de facto C++ implementation.
| pjmlp wrote:
| The facto only for FOSS systems I guess.
| kllrnohj wrote:
| Same reason caniuse.com exists for browsers. This just comes
| from the territory of a language/runtime/platform that doesn't
| have a monopoly implementation.
| kazinator wrote:
| Why only an unhip, old geezer would write outdated drivel like:
| const int MAX_SIZE = 1024; const int HEADER_SIZE = 128;
| set_content_size(HEADER_SIZE - MAX_SIZE);
| ncmncm wrote:
| Probably less geezery to write
| set_content_size(MAX_SIZE-HEADER_SIZE);
|
| Sayin'.
| tomohawk wrote:
| I mentioned to a former team mate who has been doing c++ for 30
| years or so that he might take a look at go or rust for a lot of
| the things they're doing.
|
| His response was, "I already have a new language to learn: c++".
| raverbashing wrote:
| So, it seems most problems are C++ making things extra
| bureaucratic and annoying. Cool
|
| The "pre/post increment of volatiles is deprecated" sounds like a
| huge pain. I can't imagine a worse waste of developer time than
| fixing such a minor thing (and to be fair C allowing both a++ /
| ++a should never have existed)
| scatters wrote:
| That's been undeprecated in C++23. It's mildly embarrassing,
| but it shows the process works.
| cpeterso wrote:
| Are all of C++20's volatile deprecations un-deprecated in
| C++23? This doc from 2020 lists all:
|
| https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2020/p21...
|
| But this proposal from 2021 suggests only undeprecating
| bitwise compound operations:
|
| https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2021/p23...
| scatters wrote:
| Sorry, you're right, my bad. People are actually writing
| compound arithmetic assignment ops on volatiles, huh.
| fatneckbeardz wrote:
| don't you mean ++C23
| mgaunard wrote:
| well to begin with if you're using volatile, you're probbaly
| doing something wrong already.
|
| The valid use cases for it are ridiculously few.
| munch117 wrote:
| But if you're using volatile correctly, then there's nothing
| wrong with ++*v.
|
| I was wondering about that slide that says the meaning is
| unclear, I don't see what's unclear about it. What particular
| assembly instructions it translates into is irrelevant. It's
| not like ++ is guaranteed atomic or anything.
| RicardoLuis0 wrote:
| it's not guaranteed atomic, and if you ARE using volatiles,
| "maybe" doesn't really cut it, so now you need to do `++*v`
| the proper way (ex. `lock cmpxchg` /
| `__atomic_compare_exchange`), or explicitly write it out
| the long way (`*v = *v + 1`) and risk the small chance of
| the value changing under you between read/write
| bugfix-66 wrote:
| pclmulqdq wrote:
| Sometimes you need to avoid GC or have direct control of your
| threading model and you need a language that is more expressive
| than C. Your only two options here with broad adoption are C++
| and Rust, both of which are very complicated languages.
|
| Other languages like Zig, Ocaml, and Erlang have legitimate
| claims to similar performance to C++/Rust with expressiveness,
| but they do not have the same adoption.
| bugfix-66 wrote:
| See my comment elsewhere in this thread, where I argue that
| Go is a good replacement for C/C++ for almost all purposes.
| pclmulqdq wrote:
| I have spent several years writing C++ in circumstances
| where Go is a terrible C++ replacement. In these cases, you
| either need manual control of memory or you have extremely
| tight requirements on either speed or memory usage. In both
| cases, Go falls short, and C++ actually works relatively
| well (so does Rust - everything I am saying about C++ here
| applies to Rust as well). Despite C++ having a large spec
| and being complicated, it pushes all of that complexity to
| compile time. At runtime, you pay nothing for the
| complexity of the language.
|
| Please elaborate to me as to why Go is an appropriate C++
| replacement for:
|
| * Trading systems that use direct NIC access and need sub-
| microsecond execution times.
|
| * Performance-oriented databases (like ScyllaDB or
| Aerospike). Like trading systems, these are characterized
| by having custom shared-nothing (often stackless)
| asynchronous runtimes that need direct control of syscalls,
| and optimized IPC and synchronization primitives.
|
| * Libraries like memcpy, math libraries, compression
| libraries, and encryption libraries, which need _both_ SIMD
| intrinsics and minimal overhead compared to assembly
| implementations (Go fails on the second part of this
| criterion - even the Go calling convention has significant
| overhead). And no, you do not need to write these in
| assembly: C and C++ versions are far more readable and
| equally fast.
|
| * Memory allocators, which cannot circularly depend on
| another memory allocator.
|
| * Embedded systems with constrained memory footprints.
|
| * Hardware drivers.
|
| * Code for non-CPU machines, like GPUs or DSPs.
|
| Almost all the real use cases for Rust, C, or C++ are not
| suitable for Go. Go is only a suitable replacement for
| systems programming languages in places where Java is also
| a suitable replacement: when you have a powerful computer
| and fairly loose constraints, and you are primarily doing
| business logic.
| ncmncm wrote:
| Go was specifically designed as a language for un-demanding
| applications written by coders with strictly limited
| skills.
|
| That is most applications, in practice. Unpleasantly often,
| though, applications move from un-demanding to demanding,
| and then having been coded in Go is unfortunate. A nimble
| organization will code a C++ program for that use case.
| Lesser shops will lumber along patching the Go code.
| togaen wrote:
| These slides are profoundly uninteresting.
| cletus wrote:
| Just a note but I'm fairly certain this is purely from the
| perspective of Google Chrome, meaning it excludes google3
| (Google's repo for nearly all Google services). I don't know this
| for a fact but I suspect it's the case. I only bring it up
| because google3 C++ is (or was; it's now been years since I've
| done this directly) a very different beast. It was notionally
| compliant with recent standards but a very restrictive subset of
| features were allowed.
|
| The C++ standard currently sits at >1800 pages. Looking through
| these examples, I'm honestly horrified. The semantics around
| moving and copying and the many ways you can initialize a
| variable [1] and how you can mess that up so it's actually a copy
| instead of a move is just mind-bending.
|
| Can we also talk about how in 2022 we're still talking about and
| getting wrong const-correctness? I guess we're going ever further
| now because this presentation touches on _constexpr correctness_
| (as in const vs constexpr).
|
| Another thought: problems like comparisons between base and
| derived problems shouldn't even be problems (IMHO) because you've
| already messed up by wanting that behaviour.
|
| The change about not doing arithmetic on enum values is a good
| one but pretty late.
|
| TIL this is a valid way to cast:
| size_t{expanded_size}
|
| [1]: https://en.cppreference.com/w/cpp/language/initialization
| arinlen wrote:
| > _The C++ standard currently sits at >1800 pages. Looking
| through these examples, I'm honestly horrified._
|
| I feel you're embelishing too much your personal feeling of
| horror. The C++20 standard doc is a hair smaller than 1900
| pages, but the complete core language is specified in the first
| 460 pages, of which around 100 are dedicated to templates.
|
| Thus around 1400 pages of a 1900page doc are dedicated to
| specify libraries that throughout the years have been adopted
| by the standard. We're talking about stuff that was released
| with Boost and since then was deemed appropriate to make it
| standard.
|
| Focusing on the 460 pages that specify the core language, most
| of this content has not been changed since C++98. The C++14 doc
| covered the core language with around 420 pages. Thus it makes
| zero sense to claim than suddenly C++ became horrifying because
| of the extra 20 sheets of paper you need to print out.
| cletus wrote:
| You could focus on those 460 pages but I'll raise 2 points:
|
| 1. There's still a lot of complexity and ambiguity you can
| fit in 460 pages. This presentation notes one example of
| decrement operators on volatile variables being deprecated
| because the behaviour was undefined; and
|
| 2. Can you really separate the standard library from the
| language at this point? Things like move semantics depend on
| std. Does anyone actually use C++ without any of the standard
| library?
| cesaref wrote:
| 1. The problem you've highlighted (pre/post increment of
| volatiles) is present in C, and hasn't been addressed
| there. This is a problem in c2x on compiler explorer for
| example. So i'd probably say laying this at the feet of the
| overly large C++ language spec isn't fair. I'm going to
| probably say it's been there since K&R C days (I think
| volatile was supported even that far back, but my memory is
| a bit hazy about such things).
|
| 2. This is a good point. I'd counter it by asking does
| anyone use _all_ of the standard library in a project? If I
| were to include what i 'd ever used, it's probably a subset
| of the standard.
|
| I hadn't thought about std::move, and actually had to look
| up which header it's pulled in from, since it tends to get
| pulled in by other stuff i'm using!
| [deleted]
| deadbeeves wrote:
| 1. No, that's wrong. Incrementing a volatile isn't
| undefined. The problem is that some people are using
| volatile when they actually want atomic variables, so the
| behavior of the program becomes undefined when you have two
| threads incrementing the same volatile variable at the same
| time. The compiler might or might not compile
| volatile_variable++ into an atomic operation, but some
| people wrote code under the misunderstanding of the
| language that it always would.
|
| 2. Sure. While it's true that using certain features of the
| language technically requires parts of the standard
| library, those parts are very few and very simple. What is
| there? std::move(), std::pair and std::tuple, <typeinfo>,
| and perhaps a couple other things?
| jcelerier wrote:
| std::move is just syntax sugar over static_cast<T&&>(t) ;
| the language feature that needs library support afaik
| are:
|
| - Overloading some of the "new" operators (need #include
| <new>)
|
| - <initializer_list>
|
| - typeid which needs <typeinfo> as you said
|
| I don't see which parts of the language need pair and
| tuple at all?
| deadbeeves wrote:
| I was mistaken. I thought you needed std::tuple for
| structured binding, but it seems the language can also
| destructure other types.
| jcelerier wrote:
| it's not that you need it, it's that when destructuring,
| std::tuple_size / std::tuple_element are implicitly
| checked to see how destructuring can be made to work if
| you have a type with some custom destructuring. (example:
| https://gcc.godbolt.org/z/5jq61oox7)
|
| If they are not available or just not overloaded (e.g.
| when destructuring some basic struct) it just falls back
| to the destructuring one expects. So you need <tuple> for
| the specific case of implementing custom destructuring,
| that is one more case to add to the list :)
| quest88 wrote:
| This whole thread is why c++ is..bad. It just leaves me
| with a sense of hopelessness.
| jcelerier wrote:
| Which language do you use?
| deadbeeves wrote:
| You're being overdramatic. You don't need to be a
| language lawyer to use C++ correctly and effectively.
| arinlen wrote:
| > _This whole thread is why c++ is..bad. It just leaves
| me with a sense of hopelessness._
|
| You've tried to force your personal misconceptions as
| some kind of gotchas that justify you irrational dislike
| for a programming language, and once each and every
| misconception you had was dispelled and debunked, your
| reaction was to double-down on your irrational belief.
|
| This does not flag failures in a language.
| polio wrote:
| Couldn't you still use move semantics without std::move?
| You'd just have to write your own cast to an rvalue-
| reference.
| pjmlp wrote:
| The standard includes the standard library, a tiny set of pages
| when compared against Python, Java, F#, C# language reference,
| VM reference + standard library printout.
| germandiago wrote:
| I cannot reply to your comment from "proof?" for gcc is better
| than clang at generating binaries.
|
| But here I found some benchmarks (did not inspect though):
| https://www.phoronix.com/review/11900k-gcc11-clang12/2
| [deleted]
| superkuh wrote:
| The word for this is "future shock".
| oxff wrote:
| Writing Chromium grade C++ seems like a hard job with all these
| extrinsic rules and regulations to make it work
| meibo wrote:
| You'll see these kind of rules at every place that cares about
| their C++ codebase. It's just not a language like Java, C# or
| JS where you can throw stuff at the wall and it'll probably
| work out.
| otabdeveloper4 wrote:
| > Java, C#
|
| Maybe.
|
| > JS
|
| Hell no. "Frameworks" like React or Vue exist solely for the
| purpose of retaining developer sanity in the face of
| unregulated JS code.
| speedgoose wrote:
| Anyone serious with TypeScript/JavaScript has many Eslint
| rules to keep the codebase sain.
| white_dragon88 wrote:
| Sane
| pjmlp wrote:
| Even for Java, C# and JS we do enforce such kind of rules,
| e.g. https://sonarqube.org
| diceduckmonk wrote:
| Is there a case for or against incrementally adopting Rust ?
| hi_herbert wrote:
| Betting on carbon would allow transparent FFI like Kotlin,
| typescript or graalvm achieve, which is economically
| disruptive. Rust seems more like a plan B
| izacus wrote:
| Which of these things is Rust immune to? How stable is it over
| a 10, 15, 20 year life? How old can the code be that Rust
| compiler still compiles and links successfully and bug-free?
| otabdeveloper4 wrote:
| Don't worry your little brain about these silly things.
| Programming is hard, let's go (language) shopping instead!
| pornel wrote:
| Rust does well on this front. There's a new release every 6
| weeks, and majority of users jump on it straight away (to
| complete shock of everyone not used to it).
|
| Rust has editions which keep old code working without any
| changes, even if you mix it with new code, even if you do it
| with macros. It has rustfix that automatically migrates
| majority of the old code.
|
| Rust has a standard project layout, standard test runner, and
| a central code repository, which enables testing language
| releases against nearly all publicly available code (see
| "crater run").
|
| The language itself is stricter, with the safe subset being
| free of UB, so there's less stuff to break to begin with. You
| can't suddenly use a moved-from object.
|
| There's even "cap lints" feature that disables `-Werror`
| equivalent for dependencies, so that new lints don't break
| your builds.
| morelisp wrote:
| > Rust does well on this front.
|
| Rust needs to _exist_ for at least 20 years before you can
| say it "does well" on 20yo projects.
|
| > majority of users jump on it straight away
|
| This is a sign of a language with a tiny mostly-hobbyist
| user-base.
| spoiler wrote:
| > This is a sign of a language with a tiny mostly-
| hobbyist user-base.
|
| Or that the tooling is so trivially easy to update that
| people don't need to think about it. Sometimes if I want
| to upgrade GCC I need to upgrade the whole os, or have
| multiple versions installed and be careful where they're
| installed lest I incur Ubuntu's wrath
| fortran77 wrote:
| How on earth can you predict that rust will be stable in 20
| years?
| nextstepguy wrote:
| Not true. I picked up a git repo 18 months old. I tried to
| set up my rust dev stack to match the version in cargo.
| Then hit a lot of issues with dependencies due to abandoned
| repos used for the crates. I gave up and moved on.
| pornel wrote:
| A random person on github abandoning their pet project is
| not the kind of language stability we're talking about
| here. It's not the kind of complaint you'd write to the
| ISO committee.
|
| You may have run into a project using nightly Rust, which
| is an _explicitly unstable_ version for testing of
| experimental not-yet-finished features. Using it requires
| users to intentionally opt out of having language
| stability. C++ also has GNU and Clang extensions and
| experimental implementations of not-yet-standardized
| features.
|
| However, the normal workflow is using a stable version of
| the compiler. It is backwards compatible with the 1.0
| release from 2015, except handful of edge cases that you
| won't run into an average project.
|
| Users are encouraged to use crates.io and keep Cargo.lock
| which guarantees they get the same dependencies that
| worked last time.
| pclmulqdq wrote:
| > Rust has a standard project layout, standard test runner,
| and a central code repository, which enables testing
| language releases against nearly all publicly available
| code (see "crater run").
|
| I'm not sure why this is treated as a selling point. It
| helps projects up to a point, but the minute you want to do
| something that doesn't fit the mold, it makes things a lot
| harder. All of these products are orthogonal to a language,
| and yet they are very tightly bundled with the idea of
| using the Rust language. It certainly makes "business
| logic" systems and web backends easier to implement, but
| I'm not sure many people were building those in C++ to
| begin with (except in legacy systems, where you are stuck
| with what you have).
|
| Also, I'm not sure how a language that is less than 10
| years old (in its released, 1.x versions) has any claim to
| having no problems with evolution over the next 10 years.
| dtolnay wrote:
| _> the minute you want to do something that doesn 't fit
| the mold, it makes things a lot harder_
|
| This is not my experience at all; it's been extremely
| helpful for doing things outside the mold:
|
| In a work codebase that is millions of lines of first-
| party Rust code with thousands of third-party Rust
| dependencies from crates.io, we're building with Buck not
| Cargo because that is what the rest of the monorepo uses
| for C++ and other languages. It's fantastic for this that
| all the third-party projects describe their dependency
| graph in the same standard Cargo manifest format and
| follow a standard project layout, even though our builds
| do not use Cargo, because we can programmatically
| translate them to Buck targets.
| pjmlp wrote:
| Editions only work for easy stuff, superficial grammar
| changes, and in a context where all dependencies are
| compiled from scratch with exactly the same compiler, aware
| of all editions.
|
| How many editions are rustc, rust-gcc, cranelift and
| whatever might come, being still kept up to date in 40
| years (C++ age)?
|
| What about all the language changes that actually require
| semantic changes, how are epochs supposed to deal with
| inter-editions calls where the epochs have incompatible ABI
| expectations between caller and callee, regarded expected
| compiler behavior?
| spoiler wrote:
| Rust is so trivially updated that claiming using the
| latest compiler is problematic almost sounds like a bad
| faith argument. Everyone in the Rust ecosystem updates
| withing a few days, because of how trivial it is.
|
| Also if you go to GitHub and see a package that's not
| been updated in 5years, do you think enthusiastically "oh
| yeah, I'm gonna use this"? Because IMO, if it's not been
| updated in years, it's probably abandonware.
|
| And another point is that I'm happy for them to
| deprecate/remove 40-year old (or less even) design
| decisions that have become outdated. Thinking all design
| decisions are immune to time decay like is foolish.
|
| The ABI discussion is a bit worn out by now. Everyone
| will just tell you to use use C ABI if you need
| compatibility (until something better comes along?), And
| there's is a plethora of methods for all sorts of
| languages to help bridge language gaps.
| pjmlp wrote:
| Plenty of enterprise software has not been updated in 5
| years, and keeps delivering business value.
|
| Suggesting to stick with the OS C ABI (there isn't such
| thing as C ABI), assuming it was written in V, for
| compatibility between Rust libraries is kind of ironic.
|
| It is a matter to which kind of industry domains Rust
| folks want to cater to.
| diydsp wrote:
| This how i got traumatized by rust: i had a simple task, 1
| day long. Write a routine, use a standard output format,
| theb parse the results. It was to be presented in front of
| 20 peers the next day. Decided to try the last part in
| rust...
|
| Did a few tutorials, not all of them "worked," but i
| scratched my head and moved on. Started writing the parser.
| No examples worked. Couldn't put together any reference
| code. Even copying straight from web pages!
|
| Switched to python. Done in 45 minutes. Told the whole
| story to the group. Had a laugh. Manager quipped, "that was
| when you went from leading edge... to bleeding edge." :)
|
| Later i learned rust was still making breaking changes,
| leaving a wake of dysfunctional tutorials.
| Canttrustthatlanguage.jpg. Thought i'd go back someday when
| they get it straightened out.
| kubb wrote:
| You were set up for failure: "do something for tomorrow
| in a new complex technology, and present in front of
| multiple peers".
|
| Your solution - to use a different technology designed
| with different requirements, that you were already
| familiar with, and that you knew could do the job, was
| the right solution in your situation.
|
| Your conclusion could be revised and improved.
| avgcorrection wrote:
| > You were set up for failure: "do something for tomorrow
| in a new complex technology, and present in front of
| multiple peers".
|
| Perhaps you missed this part
|
| > > Decided to try the last part in rust...
| herdcall wrote:
| I don't know when you tried it, but I had a similar need
| (build a query parser for a tiny SQL subset in a day) a
| few weeks back, and it took me may be a couple of hours.
| Actually, picking the library was the more painful part,
| and this is a problem with Rust IMO, because for most
| non-trivial new things you (at least I) typically need to
| dig through crates.io, research, experiment, etc. Anyway,
| FYI I ended up using PEST (pest.rs) if you still have a
| need.
| avgcorrection wrote:
| Embarrasing that you are so unaware that you present this
| story as anything but a failure on your own part. Yeah,
| so you chose a language that you didn't know for a task
| that you needed done in 24 hours? Whew, that's an
| unforced-error story for the campfire.
| diydsp wrote:
| I dont feel embarrassed. I'm glad I took the chance. I
| take chances like that regularly. I don't consider it a
| failure at all. My team and manager considered me a
| badass and leader for taking the leap, and we all had a
| good laugh, too.
|
| "If you want to succeed, you must double your number of
| failures."
|
| I have had so many suprises and successes by taking
| chances like that. And even when I don't come out ahead
| in the short term, I at least get exposure to and
| practice on new things.
| avgcorrection wrote:
| Oh, a badass too? Well carry on then, coding stud.
| tonetheman wrote:
| Ok here come the rust apologists.
|
| Well when rust makes changes every 6 weeks we all hold hands
| and update all of our code.
| jokoon wrote:
| Rust is too hard to learn.
|
| I like it, but it only aims at replacing ada, not c++.
|
| I asked around and there is currently no good way to make
| modern native ui apps with rust.
|
| It would be okay if the syntax of rust looked a bit more like
| C, but it doesn't, it can be a bit difficult to read.
| oconnor663 wrote:
| Rust's learning story has some interesting dichotomies in it.
| For sure, no one disputes that learning Rust is harder than
| say Python or Java. But how does it compare to C or C++? My
| take (which I have no proof for, to be clear) is that
| learning Rust is _much_ easier than either of those if you
| 're truly starting from zero. Some scattered thoughts about
| this:
|
| - Experienced C and C++ devs have to unlearn certain patterns
| when they start Rust. C++ experience _can_ be a huge help,
| but if you insist on using the patterns you 're used to in
| Rust, you often have a terrible time and feel like the
| compiler can't handle useful programs.
|
| - Particularly with C, what we usually mean when we say
| "learn" has gotten kind of out of date. If someone with a few
| years of programming experience says they "know" Python, we
| might assume they can make an HTTP request and parse some
| JSON with a couple minutes of googling the relevant API docs.
| But of course in C, those tasks are much more challenging,
| and we often allow that someone has "learned" C even if they
| can't do those things without great difficulty. Part of C's
| reputation for being (comparatively) easy to learn is that we
| don't expect programmers to be able to do the same variety of
| tasks with it.
|
| - A lot depends on what standard of correctness and security
| we want to apply. For example, writing multithreaded code in
| Rust has an extra steep learning curve, but the resulting
| code is data-race-free once it compiles. Writing big
| multithreaded programs without data races takes many years of
| experience in C and C++, and it might be genuinely impossible
| for sufficiently large projects. So depending on what we
| understand "learning to write multithreaded programs" to
| mean, we could say that Rust is much harder but also that
| Rust is much easier.
| glandium wrote:
| They are experimenting
| https://chromium.googlesource.com/chromium/src/+/refs/heads/...
| Existenceblinks wrote:
| Is there any common module that can be shared amongst browser
| engines? I can feel though it sounds hard to extract these
| common stuff into .. "browser engine common core"? (e.g. http
| s://github.com/SerenityOS/serenity/tree/master/Userland/...).
| That would be nice for next gen browser invention.
| sbdncuvh wrote:
| hi_herbert wrote:
| You can find some module candidates here
| https://github.com/servo/servo/issues/24026#issue-483508434
| The one that make the most economic sense would be for
| mozilla to drop spidermonkey and make v8 faster instead
| worker767424 wrote:
| In a few months, I might be switching to a team with a C++
| project. A lot of the team is new to C++, and there's nothing
| about the project that needs C++, Java would have been fine.
|
| This doesn't look very fun.
| echelon wrote:
| If there's ever a big production outage, you can make the case
| for Java.
| jupp0r wrote:
| Because Java is known to magically never cause production
| outages?
| echelon wrote:
| Because the OP described inheriting a C++ app his team
| doesn't know how to manage.
|
| It's a language where segfaults, memory leaks, and other
| problematic issues are easy to manifest.
|
| I assume they have deep Java knowledge, since they
| suggested it themselves.
| compiler-guy wrote:
| This would likely result in worse problems. Things You
| Should Never Do, Part I
|
| https://www.joelonsoftware.com/2000/04/06/things-you-
| should-...
| echelon wrote:
| This has _never_ been my experience, and Joel isn 't an
| all-seeing oracle.
|
| In just one notable example, a company I was at had a
| team develop an important platform in Node.js when the
| rest of the company was hired for and familiar with
| Java/Ruby. This app ran our 3rd party API gateway and was
| a central part of how our company was attempting to grow.
|
| The Node.js team left wholesale to go found CockroachDB,
| which left nobody at the company who had the expertise to
| take over. You'd think that someone at a fairly large
| company would have Node.js experience, but it wasn't the
| case that we could staff the team back up easily.
|
| There were several major production outages and the app
| lagged behind in development for the entirety of its
| life. We also had to port our protoc changes and traffic
| stack just to serve this one app. This despite being a
| central part of our upmarket strategy.
|
| Ultimately it was completely rewritten. And nobody
| regretted that decision. We carefully weighed the pros
| and cons.
|
| There's something to be said for a company that
| standardizes on one or two languages. Letting engineers
| have free reign leaves you with Haskell and Erlang
| littered in important places, with a very tiny bus
| factor.
| compiler-guy wrote:
| No one said to let everyone have a free for all with a
| million different languages. Rewriting things creates its
| own set of bugs. Every time.
| chippiewill wrote:
| C++ has a lot of sharp edges. Skimming through the slides it
| seems as though Chromium hit upon a lot of the big problems
| because:
|
| 1. Google always seem to enjoy bucking the trend in terms of
| recommended ways to do things and end up using niche features
| that are likely to be deprecated 2. Chromium is a stupidly
| massive codebase so they have more things to fix just purely
| through scale
|
| If you stick to the sane subset of the language that any
| competent modern C++ development shop would then you wouldn't
| encounter any of these problems except small/easy stuff like
| the new reserved keywords.
|
| That being said, if you don't have a team that's already
| experienced in C++ then picking C++ is a bizarre choice.
| worker767424 wrote:
| C++ was the right choice for broader organizational reasons,
| but the wrong choice for what the project needs.
| jupp0r wrote:
| Compared to Java, modern C++ isn't so bad. Dependency
| management and build systems are the main problems. Both of
| those should be solved in an existing project.
| synergy20 wrote:
| Say I have a new project to start today. I need pick a language
| to use: 1. a well-tested language 2. can
| not use garbage collector due to *performance* requirement
| 3. easy to hire if project expands. 4. ready to use tooling
| support 5. widely available tutorials and info on the web.
| 6. language is itself alive and updated 7. project can be
| scaled over time.
|
| what options do I have? I have to pick up c++ in this case. it
| falls to the saying "a language is either blamed, or nobody uses
| it".
|
| Javascript for the web, Python for machine learning, C for low
| level and system coding, Go for some native cloud and DevOps,
| Java for enterprise or Android, C# if you're a windows developer,
| Swift if you are doing Apple, we actually don't have a lot of
| choices when you need deliver things faster.
|
| I played with nim, ziglang and Rust, but it's hard to use them
| for real product developments at this point for me.
| phoehne wrote:
| The way I look at it is we're in a transitional period. A
| language like Go or Rust can replace some of the C++ lift, but
| we're not sure because they're not a large body of experience
| with those languages. I suspect, but can't say with any
| certainty, that we'll wind up in a world where the use case for
| C++ shrinks significantly. Rust and Go will eat into the share
| of new Greenfield systems that would have normally gone to C++
| or even C.
|
| I like to live in the embedded world and there I think Rust
| will shortly start to push out C and C++ at the wide-spread,
| commercial level. This is where my head is at, maybe it helps
| you formulate your opinion:
|
| First, embedded C++ is not the same a full C++ (with features
| or library parts missing to accommodate the constrained
| environment). So I might never see some of the C++2x or even
| C++1x features. I really don't care about the C++2x standards
| since I might not see them in the next 10 years.
|
| Second, memory and concurrency issues are real, even when you
| don't allow dynamic memory allocation after the system is
| initialized. We test, then test, and then run more tests, and
| turn on a lot of linters and analyzers but at the end of the
| day, they're bandaids. You can write terrible code in Rust, but
| you have to work harder to do it.
|
| Third, if you really need an environment where memory is as
| fungible as play dough but want something portable (like inside
| a kernel), there will always be C. Setting up a C callable
| environment from assembly is well understood. In theory,
| calling into Rust shouldn't be any harder. But reading
| disassembled object files from C is generally reasonable
| assembler for the C I wrote. I haven't really tried doing that
| with Rust.
|
| Fourth, it will take 5 years or so, but eventually we'll see
| commercially supported RTOS implementations for Rust that help
| companies to shield themselves from liability. For example,
| something like Threadx (AzureRTOS now). This will help push
| money in a virtuous cycle of better tooling -> more projects ->
| more money for tool venders -> better tooling.
|
| Fifth, there will be Rust bindings to cover just about
| everything you do with C++ now (like game development) with
| high quality, idiot-proof, and portable semantics. You will
| find that junior developers or fresh-outs will have their skin
| crawl when asked to write "unsafe" code.
|
| Sixth, there's counter evidence to support a lack of adoption
| of new languages. Ada provides many of the same concurrency and
| memory safety guarantees as Rust, and has been available since
| 1983, but it is not widely adopted. It is harder to use and
| requires significant developer training. If Rust is
| significantly more challenging for developers, it may go the
| way of Ada.
|
| But that's in the future. If I had to start a new project today
| (for a braking system on a train, for example), I would start
| with C, a validated RTOS, and commercial toolchain. If I had to
| light up my kid's halloween costume? Embedded Rust as a
| learning exercise. The rendering engine for a VR headset (with
| limited batter and compute), probably C++.
| __jem wrote:
| > Sixth, there's counter evidence to support a lack of
| adoption of new languages. Ada provides many of the same
| concurrency and memory safety guarantees as Rust, and has
| been available since 1983, but it is not widely adopted. It
| is harder to use and requires significant developer training.
| If Rust is significantly more challenging for developers, it
| may go the way of Ada.
|
| Rust is definitely difficult to learn, but I'll anecdotally
| say that Rust helped get me into the embedded world as
| someone with very little C or C++ experience. Unlike Ada,
| Rust has a modern toolchain and type system that feels very
| comfortable to developers coming from higher level languages,
| even if many of the concepts related to manual memory
| management remain quite difficult.
| pyjarrett wrote:
| > Unlike Ada, Rust has a modern toolchain
|
| We have a modern toolchain too :) #
| install compiler and build tools alr toolchain
| --select # make, build and run a project
| alr init --bin my_project alr build alr run
| f1shy wrote:
| In the aeronautics and space industry Ada was and is
| popular. Ok, not the biggest industry, but still...
| phoehne wrote:
| It's a very good language. I learned it graduate school
| in the mid 1990s. I personally think the learning curve
| is not particularly steep. But it seems like most
| developers and the industry would rather enforce coding
| standards to nerf the foot-guns in C/C++
| (https://news.ycombinator.com/item?id=7628746). With Ada
| there would still be coding standards but I would wager
| that it wouldn't be as much about inherent problems in
| the language.
|
| They might both have a rule like: AV Rule 1 Any one
| function (or method) will contain no more than 200
| logical source lines of code (L- SLOCs).
|
| But Ada would probably not have something like: AV Rule
| 59 (MISRA Rule 59, Revised) The statements forming the
| body of an if, else if, else, while, do...while or for
| statement shall always be enclosed in braces, even if the
| braces form an empty block.
|
| Or: AV Rule 193 (MISRA Rule 61) Every non-empty case
| clause in a switch statement shall be terminated with a
| break statement.
|
| Those two arise from deficiencies in the basic C/C++
| syntax. They are probably not fixable in a future
| revision of the spec because they would break too much
| code. So we create a coding standard, configure a linter
| to check for it, wire up our source repository to scan
| for it on checkin, and make all the leads code review for
| it.
|
| Ada might have different language specific standards. For
| example, around not allowing breaks out of infinite
| loops. Requiring, instead, a loop construct with a
| testable condition. But even then, you can pragma things
| out of the compiler to help you enforce behavior. That's
| "built in."
|
| My comment with Rust is not that Ada is bad or too hard,
| but rather even a small amount of additional work might
| be enough for developers and organizations to avoid Rust.
| There's a lot of Rust advocacy, which is a good thing.
| However, there was also a lot of activity on
| comp.lang.ada.advocacy (if I remember the newsgroup
| correctly). One good thing is that Ada felt "imposed" by
| a number of people and that automatically stimulates a
| kind of rejection response. Rust's introduction is
| definitely more "bottom up."
| sudosysgen wrote:
| Rust can't easily bind to many modern, high performance C++
| libraries because it lacks a fair amount of the semantics of
| C++.
| phoehne wrote:
| I think that may be a red herring. We normally don't link
| to name mangled C++ libraries, anyway. Most libraries
| export their useful symbols in de-mangled format for
| linking to other languages. That way you can basically
| dlopen and look for the symbol. There are some libraries
| that are really only intended to be called from C++ and I
| don't expect anything other than C++ to use those
| libraries. I'm not sure if Ruby or Python (for example) can
| deal with mangled names. I think there are some tools that
| will generate wrappers to make them callable from things
| that don't understand mangled names, but if you want to
| make your stuff interoperable - make it C callable.
|
| It isn't that hard to define something like MyType_t which
| is a pointer. Then some C code to allocate to wrap the
| MyType so the type is usable from any language.
| TinkersW wrote:
| Go isn't a competitor to C or C++. I don't know where that
| idea even comes from. Go is competing with Java and web
| languages.
|
| Rust is the only real competitor, but given the sheer amount
| of existing C and C++ code, the idea that they will become
| legacy languages any time soon is pretty out to lunch.
| phoehne wrote:
| From Rob Pike - One of the creators of Go. see
| https://commandcenter.blogspot.com/2012/06/less-is-
| exponenti...
|
| A lot of command line tooling is being written in Go along
| with systems software (like basically all of container
| land). Maybe some of these would have otherwise been
| written in C or C++. For example, if you use the Azure
| storage GUI to manage storage the underlying "thing" that
| copies data from your filesystem to azure storage is
| written in Go and that's why it works on Windows, Linux,
| MacOS. C++ is somewhat more portable than C so maybe
| something like that would have been written in C++? Who
| knows? But Go is definitely showing up in all sorts of
| native, command-line stuff. And Rob Pike - one of the
| people who developed Go - intended it to be a new home for
| C++ developers as well.
| logicchains wrote:
| > what options do I have? I have to pick up c++ in this case.
| it falls to the saying "a language is either blamed, or nobody
| uses it".
|
| You could just use C.
| synergy20 wrote:
| or use a subset of c++ that does everything c does, plus OOP,
| RAII and smart pointers for free, and it compiles and links
| with c code smoothly as well. the only price to pay is that
| libstdc++ runtime must be present, which is just a few MBs
| that can even fit for small embedded boards.
| loxias wrote:
| I've written firmware, systems software, drivers and plenty
| else this way. Just because the language gives you rope
| doesn't mean you _have_ to use all of it. I enjoy how terse
| and straightforward even good ol' structured non-object
| oriented code can be.
| ncmncm wrote:
| "Object-oriented" is a niche technique.
|
| Any big-enough system will naturally have some OO-ish
| parts, just because it has some of almost everything.
| Most small programs will have none.
| synergy20 wrote:
| same here, but I'm embracing modern c++ these days, not
| for all low level coding yet though.
| kfajdsl wrote:
| Yep, big thing for me is smart pointers and RAII.
| Everything else is secondary.
|
| I have worked on template-heavy codebases that would
| _really_ benefit from concepts, though.
| alar44 wrote:
| This is what I do. Write C in C++. You don't have to use
| all the fancy new shit. I'll never understand why people
| get so upset about it.
| ncmncm wrote:
| Then you are writing bad C++ code.
|
| The new features are added specifically because they
| enable writing better programs. Avoiding them means you
| are choosing not to write better programs. It is allowed,
| but not a thing to brag about.
|
| That does not mean every program has to use every
| feature. But when there is a choice between the new way
| and the old way to do something, the new way is very
| probably better.
|
| Passing a reference, where you can, is better than
| passing a pointer. Passing a lambda is better than
| passing a function pointer. New for-loops are better than
| old for-loops. A unique_ptr is a better member than a
| naked pointer. A compiler-generated destructor is better
| than a hand-coded one.
|
| And so on.
| alar44 wrote:
| Absolutely, but none of those are really that new. I
| guess I'm talking more about boost libraries and that
| stuff. I just can't be bothered and it doesn't matter for
| anything I need to write.
| bluGill wrote:
| That C in C++ id the part where most of the serious bugs
| in C++ come from
| didibus wrote:
| > I played with nim, ziglang and Rust, but it's hard to use
| them for real product developments at this point for me
|
| What made it hard? For example, Rust seem to fit your bullet
| list.
| oconnor663 wrote:
| I think depending on the type of project, Rust might already be
| there. A couple of bullets raise questions:
|
| > ready to use tooling support
|
| This really depends on the use case. If the tooling you're
| looking for is "Unreal Engine", then Rust is definitely not
| there yet. But if you want to write network services,
| databases, CLI tools, etc., I think Rust has been fully viable
| with good tooling and library support for years now.
|
| > easy to hire if project expands
|
| No doubt hiring experienced Rust developers is hard, because
| there aren't that many yet. But anecdotally, training Rust
| developers is much easier than training C++ developers. Rust
| makes it easier for one or a few experienced folks to have
| confidence that a larger number of less experienced
| contributors aren't introducing stability or security issues.
| f1shy wrote:
| And also you have to check the quality, not only quantity...
| yes, you get many people if you search "c++ developers" but
| how good are they? I think people who are into Rust are very
| motivated, curious people, with some experience. I would
| really like a study of that, btw :)
| slaymaker1907 wrote:
| As somebody who writes C++ for my job, I don't think the
| tooling is particularly good so it's funny to me when people
| talk about that. Languages like Java or Python have good
| tooling, but C++ is a dumpster fire in terms of tooling.
| bugfix-66 wrote:
| Go's garbage collector is faster than you imagine. Have you
| used it?
|
| Go is a good replacement for C and C++ for almost all purposes.
|
| Most purposes where Go is inapplicable should be using explicit
| SIMD (GCC intrinsics) or CUDA C anyway.
|
| The others purposes where Go is inapplicable are low-level
| real-time stuff that should be written in C for a specialized
| software stack (e.g., software in a car).
| doliveira wrote:
| What are people using C and C++ for that you can comfortably
| use Go instead?
| bugfix-66 wrote:
| For example, I work at a company (a company you hear about
| daily here on Hacker News) that has a compiler generating
| linear algebra kernels.
|
| The compiler is a huge assemblage of C++ templates,
| stitched together with a little Python.
|
| The generated code is in an assembly language for a highly
| parallel machine, and needs to be heavily optimized down to
| the cycle.
|
| But the compiler itself does NOT need to be so minutely
| tuned. It needs to be maintainable and it needs to allow
| easy development of complex code generators.
|
| Go would be a great choice for the compiler.
|
| Instead, we struggle with C++ templates, CMake'ing our code
| slowly and with absurd complexity, modifying the compiler
| slowly and with great difficulty...
| spyremeown wrote:
| I've read all of your comments and I commend you trying
| to illuminate these people. Some of them seem to be
| living in the 1990s, spewing the usual hocuspocus about
| programming languages, the kind of thing you hear once
| and it becomes a myth. It's like people don't want to
| reevaluate their choices, and it's insane we keep using
| this god-forsaken language when we have much better
| tooling, as you said.
| ncmncm wrote:
| Sounds like you have a code-quality problem more than a
| language problem. In that situation, switching languages
| probably would not help you much.
|
| Get a handle on your code quality, and put the language
| features to work to solve problems for you. Then Go will
| increasingly look pitifully inadequate.
| pclmulqdq wrote:
| Honestly, it sounds like C++ is just a poor choice for
| this project, since you are not so interested in
| performance and you are a lot more interested in
| developer speed. It is not an example as to why Go is a
| good replacement for C++ in _almost every_ project. This
| is a case where you could replace C++ with any business-
| logic-oriented programming language and you would be
| happier. It just so happens that your language of choice
| is Go (and presumably the tech lead 's language of choice
| is C++ for some unknowable reason).
|
| Also, you should not discount compiler speed completely.
| You, yourself, were upset at the speed of a compile
| process. All of your users are going to be waiting to get
| things done while the compiler is running, so you might
| want to do some math as to how much a 10% slowdown would
| cost in developer salaries. The makers of gcc, LLVM, and
| clang spend a lot of effort on improving the speed of
| their compiler to make sure that you have minimal time
| waste.
| galangalalgol wrote:
| Even with version 1.18 the median is 3x slower than c++ in
| the benchmark game. And most of those programs don't even
| exercise the GC (other than binary trees benchmark). If you
| are targeting a quadcore arm embedded type thing with no gpu,
| go is going to take something that saturated one core, and
| make it saturate 3, if you are lucky enough it is easily
| parallelized. Even when a gpu is available, it often isn't a
| good fit to the problem.
|
| I like go, I use it on occasion. If I stick to the simple
| stuff it is really easy to think about and if it is just a
| back end on a big server, why not. But that is a niche case
| for me. I usually prototype in matlab, then implement in c++,
| and yes, often cuda too, but I think saying that go is almost
| always a drop in for c++ is missing the vast majority of what
| c++ is used for. Go is not a systems language, it benchmarks
| slower than many vm lamguages like java and c#. It's gimmick
| is that it compiles really fast and is easy to reason about,
| so it is good for velocity. But it sacrifices a lot for that.
| FFI compatibility, and runtime speed foremost. Sometimes
| those things don't matter. But for systems programming, dsp,
| embedded, or AAA games they are deal breakers.
| bugfix-66 wrote:
| I don't know if you've read the benchmark code from The
| Benchmark Game, but anyone who has looked at the code takes
| those results with a grain of salt, or discards them
| entirely.
|
| For example, the C/C++ implementations use arena
| allocators, and they could do the same for the Go
| implementations, but they don't.
|
| The Benchmark Game is a joke. Here it is, for anyone who
| wants a good laugh: https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| __d wrote:
| C++ allows you to control your memory allocations.
|
| You can use mark and sweep, you can us reference
| counting, you can use arenas, you can use local stack,
| you can use shared memory, you can have custom allocators
| for any object, you can avoid memory allocations
| altogether, and any combination of these.
|
| C is the same. Java can do some of this, if you twist it
| hard enough. Go cannot. That's ok -- often, even most of
| the time, you don't care, and then Go is a fine language.
|
| But C++ is useful in a much wider set of domains than
| many people think, because it offers a level of control
| that many other languages don't.
|
| My favourite analogy? Go (etc) is like an Apple product:
| smooth, and shiny, and tries to be idiot-proof, but you
| can only do it the Go way. C++ is more Linux: a mess of
| incompatible, incomplete, infuriating things that let you
| do absolutely anything you want, if you invest the
| effort.
| galangalalgol wrote:
| I looked again at the idiomatic solutions and of the GC
| languages, on the benchmarks that are relevant to me, go
| leads the pack (except unchecked swift which doesn't
| really count, and julia which I think may use actual
| magic). I feel somewhat vindicated in not bothering to
| learn c# yet. I am trying to become more fluent at julia
| though. It already has a very extensive set of libraries
| from it's community. I may eventually use julia for the
| things I reach for go for now, and probably some of the
| things I use matlab, c++ and cuda for.
| igouy wrote:
| Compare GC Java with GC Go.
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| galangalalgol wrote:
| Thanks for the work separating out the solutions. It
| really helps compare the sort of code I'd actually write
| in those languages. Also, what is the reasoning behind no
| numpy? I'd never do something like nbody or Mandelbrot
| without numpy or torch in my actual job, so it isn't
| idiomatic in a way. Not a complaint, I could always fork
| it if I cared enough, just curious about the reasoning. I
| know pypy didn't really want to be involved. Thought it
| might be like that for numpy?
| igouy wrote:
| pidigits and regex-redux explicitly allow use of C
| libraries.
| galangalalgol wrote:
| I disagree, but they do take some effort to use
| effectively. Isaac (or someone) has spent a lot of time
| segregating out idiomatic simple, and overoptimized
| solutions. I have looked at the programs, and within the
| idiomatic programs similar to the types of stuff I do
| (not a lot of allocation) go varies between 30% and 300%
| more CPU time. And I have used it as I said. Because go
| is compiled to native people keep suggesting it is a
| systems language. Fortran is compiled to native too, but
| I don't want to write a kernel driver in it. Go has a
| huge niche, back-end. I think it has plenty of
| competition there with java and c#, but I reach for go
| because it makes things quick and easy. I might learn c#
| if back-end was my day to day, but it isn't.
|
| Using c++17 (don't know 20 yet) for very small embedded
| targets works fine, easy FFI into the BSP, small to no
| runtime depending on usage.
|
| Trying to target that with go would add a lot of extra
| challenge.
|
| I think something like rust or preferably a subset of it
| for c++ ise cases makes sense. My next project without a
| GPU I have penciled in rust on the plan. The other
| developers are excited. Still too hard to use gpu with
| it. Or rather too immature.
|
| The other developers like go too, but throughput will be
| critical without the gpu, and every little bit will
| count. And for numeric code it wouldn't just be a little
| bit of a hit. I wouldn't even suggest julia, and that is
| as close to a do-it-all language as I have seen.
| pclmulqdq wrote:
| As a Go expert, you should consider fixing it, and more
| people will be willing to use Go for performance-oriented
| projects. Like it or not, a lot of people go to the
| benchmarks game website to think about programming
| language performance.
| surajrmal wrote:
| go has other problems that preclude it from being a good
| option including binary size, memory usage, and portability.
| There are certainly a lot of places it is a good choice for,
| but I can't really imagine using it anywhere I use c++ today.
| bugfix-66 wrote:
| Portability?
|
| Are you saying Go has portability problems?
|
| Can you elaborate on that very surprising claim?
| synergy20 wrote:
| when you talk about macos/windows/linux without CGO yes
| Go is very portable and easy to use, when you need CGO,
| or you need work on other architecture or OSes, Go is
| pretty much a no-go. and c/c++ are still the only ones
| close to the claim "runs on everything".
| synergy20 wrote:
| Go will give me VSS of hundred of Gigabits on a MIPS board
| that has only 64MB memory, it's a known 'feature' by design.
| Its binary size is at least 10x larger than C/C++.
|
| Go also has the stop-the-world GC problem, GC is great but it
| does have a price tag.
|
| I like Go a _lot_ and use it in some projects, but I
| certainly will not claim it can replace C++ 'generally', not
| at all.
| bugfix-66 wrote:
| Sure, you can always find extremely constrained, embedded,
| or real-time safety-critical applications where only a
| carefully chosen subset of C is applicable. You shouldn't
| be using the sprawling C++20 there, either.
|
| But for pretty much everything else (see the caveats in my
| comment above) you are better off, a lot better off, using
| Go.
| jandrewrogers wrote:
| C++17/20 is superior to Go, and widely used, for anything
| that looks like high-performance data infrastructure,
| which is a broad class of software. There are classes of
| common architectural optimizations that aren't feasible
| with a garbage collector because of how it interacts with
| scheduling and CPU caches. Even 1 millisecond for a GC
| pause -- often considered "low latency" -- is much too
| slow when standard operation rates are tens of millions
| per second.
|
| Go is very good for many things but it does not offer
| competitive performance for these types of applications
| because design elements that have a large impact on
| throughput are poorly supported.
| Koshkin wrote:
| Sounds like Fortran to me.
| scottLobster wrote:
| Fortran is easy to hire for?
| phao wrote:
| For numerical and scientific (high performance) jobs,
| possibly not that much harder than C++. For other jobs, I
| doubt it and would stick to C++.
|
| The issue is that, for example, you might be getting people
| with poor software engineering training per se. You risk
| hiring some very smart phd that writes code that works and
| runs really fast, but isn't that readable, extendable,
| maintainable, testable, etc.
| llanowarelves wrote:
| Your second paragraph describes what I see with Python ML
| guys.
| phao wrote:
| I see it in a lot of matlab code as well.
| the_af wrote:
| Honest question: is it easy to find _good_ C++ programmers
| these days?
| fathrowaway12 wrote:
| Seems like there's plenty, but a lot of em' are already
| gainfully employed by Google, MSFT, FB and co.
| ncmncm wrote:
| The good ones mostly leave those shops after a few years.
| Beware of anybody who looks back on them with fondness.
| jandrewrogers wrote:
| I think it is significantly more difficult to find
| programmers with domain expertise in the kinds of
| applications C++ is often used for than the language itself.
| There are quite a large number of good C++ programmers who
| have never worked anywhere close to the metal, OS, high-
| performance, etc, and those skills are often more difficult
| to learn and come by than the language.
|
| A large amount of C++ development is still focused on
| enterprise and UI apps, even though one could argue that it
| is not the best language for that purpose.
| synergy20 wrote:
| that's a good question, I have yet to find a good beginner
| friendly modern c++ education material, be it a book or some
| course, that can make c++ learning simpler, to the point and
| enough to start to work with the language before diverting
| into those deep concepts.
|
| Someone needs to write a c++ 101 book, followed by 201 and
| 301 for beginner, intermediate, and advanced users.
| user432678 wrote:
| "C++ Crash Course" by Starch seems to be such a beginner's
| book, can't recommend it enough. Although, I was learning
| C++ mostly for hobby projects.
| synergy20 wrote:
| a good book indeed, hope it will have an updated version
| for c++20/23, which arguably is the most important
| release since c++11, new stuff such as ranges, std::span
| even concepts could be added now. I think this book is a
| bit tough for beginners though.
| [deleted]
| __d wrote:
| In short, no.
|
| But then, it's hard to find good programmers for any
| language, so C++ isn't really any worse off here, and better
| off than some in that at least there's a bunch of candidates
| to pick from.
| phao wrote:
| I wonder how much of (2) is speculative and how much of it is a
| real need in actual projects.
| f1shy wrote:
| In my experience 99% speculative and _WRONG_. Who said:
| "early optimization is the root of all evil"? :) Today more
| and more is possible to have a GC without terrible
| performance issues. Some weeks ago I read an article here in
| HN, about LISP used for safety critical systems. That bad
| fame of GC comes from the early versions of Java... but I've
| been using GC languages a LOT, and never had those "stop the
| world" moments.
| ncmncm wrote:
| The expression is "premature optimization". And, Donald
| Knuth.
|
| GC overhead is always hard to measure except end-to-end,
| because it is distributed over everything else that
| happens. Cache misses, TLB shoot-downs. Mitigations are
| very difficult to place.
|
| Practically, you usually just have to settle for lower
| performance, and most people do. Double or triple your core
| count and memory allocation, and bull ahead.
| jandrewrogers wrote:
| The negative performance impact of GC in performance-
| engineered code is neither small nor controversial, it is
| mechanical consequence of the architecture choices available.
| Explicit locality and schedule control makes a big difference
| on modern silicon. Especially for software that is expressly
| engineered for maximum performance, the GC equivalent won't
| be particularly close to a non-GC implementation. Some
| important optimization techniques in GC languages are about
| effectively disabling the GC.
|
| While some applications written in C++ are not performance
| sensitive, performance tends to be a major objective when
| choosing C++ for many applications.
| phao wrote:
| > performance tends to be a major objective
|
| My comment is about the thinking behind making this
| decision, C++ or not. It wasn't "is it speculative that GC
| will add a cost?" or something like that.
|
| I wonder how much of the thinking that leads one to
| conclude "I need so much performance here that I can't
| afford a managed language", for example, is real carefully
| thought vs. speculative.
| Xeamek wrote:
| >Java for enterprise or Android >C# if you are windows
| developer
|
| Picking Java over kotlin for android, or lumping C# into "just
| for windows" bucket is exactly the ignorance that leads you to
| "we don't have choices" conclusion. If you always default to
| literally top1 language for given domain, then how can you
| expect to have multiple choices?
|
| I'm not talking about using some brand new gimmick that came
| out yesterday and will die tomorrow, but if you aren't able to
| leave your comfort zone even just-so slightly to update your
| stereotypes about given given domain and its trends, then by
| definition you won't see the alternatives.
| f1shy wrote:
| TBH I was shocked by "Python for machine learning". I do not
| know where that comes from. Maybe because some important
| toolkits are available for Neural Networks? But machine
| learning is not neural networks... you _can_ do it with NNs,
| but there are so many other algorithms... I 'm really
| surprise of this kind of posts in hacker news. I thought the
| audience here has other experiences.
| tinco wrote:
| That's literally the only one that didn't shock me. What
| universe do you live in where machine learning algorithms
| aren't tied together with Python? And what industry where
| machine learning is not mainly neural networks?
| f1shy wrote:
| In the company I work most of it is done in matlab for
| "putting together" then goes to C++. Again not neural
| networks. I'm saying all the other machine learning.
| Maybe rare case.
| p1esk wrote:
| What kind of machine learning does your company do? It's
| probably something simple, because for anything
| complicated, like computer vision, speech recognition,
| any non-trivial NLP, and large scale recommender systems
| you do need neural networks.
| f1shy wrote:
| Autonomous driving, including, for example, computer
| vision. No NLP or speech. About the "need" or neural
| networks, there is a lot of discussion going on. As you
| may know, the "black box" nature of NNs make them a
| little more difficult than other means, when you have to
| validate them for safety critical systems.
| p1esk wrote:
| If you use CV for autonomous driving you use object
| detectors, and any modern object detector uses a neural
| network as its backbone.
| jandrewrogers wrote:
| Python for machine learning is a coincidence of history.
|
| Python is the traditional scripting language for high-
| performance computing (HPC) going back a very long time, as
| a wrapper for highly optimized and scalable C libraries.
| Python on supercomputers wasn't originally used for machine
| learning but it naturally included support for excellent
| linear algebra libraries, etc for various types of large-
| scale modeling. When machine learning first became trendy,
| data scientists that wanted access to mature library
| implementations of critical algorithms that worked very
| well at large scales were mostly limited to C/C++ or Python
| wrappers of that C/C++. Naturally, they chose Python for
| the same reason Python was already being used in HPC --
| ease of use.
|
| By virtue of its use in supercomputing, Python had uniquely
| strong support for many types of machine learning before
| there was a demand for machine learning. If HPC had used
| some other popular scripting language instead of Python,
| we'd probably be using that for machine learning right now.
| plonk wrote:
| Python is the main language for PyTorch and TensorFlow,
| there are few ML frameworks more complete than Scikit-
| learn, I'm not aware of an equivalent to NumPy in other
| languages, and this list is probably missing other things I
| don't use.
|
| What's the alternative for quick ML prototyping?
| didibus wrote:
| R, Matlab, Julia are some common alternatives.
|
| Java/Scala I've also seen, specifically things around
| Spark ML, and Spark compute.
|
| That said, Python is definitely the most common nowadays
| I'd say.
| synergy20 wrote:
| same can be said to typescript, did not mention them to make
| the point.
| f1shy wrote:
| Honest question, do not want to insult anybody: I've heard lots
| of times, that the reason why C++ sometimes is weird and complex,
| is because utter care is taking in maintaining backward
| compatibility. Sorry if I'm wrong, but I remember seeing a video
| about variable initialization, which showed many ways of
| initializing variables, and at the end, the excuse was "all
| because we have to maintain compatibility to C". No my question,
| again, _please do not think I 'm insulting anybody_: This
| presentation seems to show the compatibility between most recent
| releases is not very good. What am I missing here?
| mrazomor wrote:
| The presentation mostly lists warnings and notices about
| deprecation. If you turn them all off, most likely the
| compilation would pass.
|
| So, backwards compatibility is there (if we ignore newly
| introduced keywords).
| MauranKilom wrote:
| > This presentation seems to show the compatibility between
| most recent releases is not very good.
|
| Half of the "features" shown in the presentation are
| exceedingly niche. It's just that a 20 million LOC (or however
| many Chrome has right now) code base is almost guaranteed to
| exercise every niche feature somewhere.
|
| Having helped with C++ standard transitions of a code base half
| an order of magnitude smaller, the amount of issues requiring
| code changes was minuscule so far. You tend to have much more
| boring problems, like:
|
| - "We can't use newer C++ because C++/CLI doesn't support it"
|
| - "We can't use newer C++ in these headers because they end up
| included in CUDA code, and that compiler only supports C++14"
|
| - "We have to wait for a new version of <tool> before we can
| lint/sanitize/profile/format our code"
|
| - "This third-party code has the compiler up in arms now
| because it does questionable things"
| dureuill wrote:
| As expected modules are relegated to some later time ("will be
| its own experiment")
| pjmlp wrote:
| Thanks clang lagging behind ISO C++, you can use them today on
| Visual Studio 2022.
| JonChesterfield wrote:
| Clang had modules ages ago. Still does I think, but not the
| same thing as was standardised.
| pjmlp wrote:
| What it has are pseudo modules implementated via
| configuration files called module maps, completely
| unrelated to how C++20 modules work.
| mike_hock wrote:
| Can't blame them. Modules are Microsoft sabotaging the
| standard so they can be the only conforming implementation,
| just like with the Office .doc format.
|
| Modules are unimplementable shite. They would be great if
| this was the first iteration of the language, but they're a
| nightmare to fit into the existing ecosystem. If they get
| support in open source compilers, we can look forward to at
| least one or two decades of a mixed modules/headers mess in
| open source projects.
| pjmlp wrote:
| Yet, somehow the GCC folks manage to keep improving their
| modules support, slow and steady.
|
| If they were unimplementable, there wouldn't exist already
| two major C++ compilers supporting them to some degree.
|
| It is only clang with their module maps pseudo concept that
| keeps lagging, that and plenty of other C++20 features.
| mike_hock wrote:
| Implementable by compilers, sure. Implementable by the
| ecosystem at large, yes, over the course of several
| decades.
|
| Edit: Also, module support better be 100% binary
| compatible between GCC and Clang, or it's worse than
| complete garbage.
| pjmlp wrote:
| As if you could expect any kind of ABI compatibility
| between GCC and clang binary libraries today, and
| apparently it doesn't make them a complete garbage, go
| figure.
| leni536 wrote:
| umm, you can
|
| edit: to elaborate both g++ and clang++ implement the
| Itanium C++ ABI[1]. You might get binary incompatibility
| by mixing standard libraries, so just don't do that.
|
| [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html
| pjmlp wrote:
| Which is exactly what happens when using shared objects.
|
| Additionally the C++ ABI doesn't tell anything about how
| each binary library was compiled regarding compiler and
| linker switches that affect runtime behaviour.
| leni536 wrote:
| > Which is exactly what happens when using shared
| objects.
|
| Right. This has nothing to do to gcc, clang and even C++
| though. I would be surprised if you could freely link C
| shared objects linked to different libc implementations.
|
| On most Linux distros both gcc and clang link to
| libstdc++, so everything works out of the box. I imagine
| this is not the case for MacOS xcode and gcc from
| homebrew.
| karterk wrote:
| What are some ways in which they are bad/broken?
| dureuill wrote:
| modules were my #1 wanted feature in C++, but they are
| very disappointing to me:
|
| - they allow `.` in their names to signify hierarchy, but
| have no built-in notion of hierarchy or submodule. This
| means possible error messages will have to be suboptimal
|
| - they are orthogonal to namespaces, meaning if you have
| a module `foo.bar` any identifier it will export will be
| in the global namespace unless you put it in the
| `foo::bar` namespace in the `foo.bar` module file. As a
| user this means that I can import a `foo.bar` module and
| expect symbols to be imported in any namespace.
|
| - btw, what happens if different modules import the same
| name? I'll let you guess:-D. Modules were the chance to
| eliminate this kind of issues by eliminating the notion
| of shared namespaces, but oh well...
|
| - modules have interface units, implementation units,
| partitions, interface partition and implementation
| partition. There must be exactly one non partition
| interface unit, called the primary module interface.
| Instead of, you know, just having modules and submodules
| files like all modern module systems in existence.
|
| - Modules add new and fun ways to get ill-formed, no
| diagnostic required programs. Such as not re-exporting
| all interface partitions.
|
| I really hoped that modules were the chance of
| introducing a simpler compilation model for C++. I'm not
| pleased with the result.
|
| Some references:
|
| [0]: https://vector-of-bool.github.io/2019/01/27/modules-
| doa.html
|
| [1]: https://vector-of-
| bool.github.io/2019/03/10/modules-1.html
| tele_ski wrote:
| Yikes, I was so excited for modules back when I was still
| writing C++17 and a bit of early 20. Sad they have so
| many problems with them and/or are just plain not
| implemented still. Honestly I'm happy I'ved moved on from
| the language
| sbf501 wrote:
| Slide 37: can't even use ++ anymore. Ouch. (at least on volatile,
| but still)
|
| Best line in the deck:
|
| "Only write complicated code when you truly need performance.
| Comment if you do...."
| khoobid_shoma wrote:
| It's easier to say goodbye C++!
| speedgoose wrote:
| A full rewrite seems extremely expensive and long. I'm afraid
| C++ isn't going anywhere in our lifetime.
| Kwpolska wrote:
| C++ can stay, but people can make a decision not to use it
| for anything and not to take any jobs involving C++ (or other
| systems/bare-metal-ish languages).
| pjmlp wrote:
| C is 10 years younger than COBOL, C++ is 20 years younger than
| COBOL, COBOL is still around.
| krater23 wrote:
| It's more easy to just don't adopt the new standard.
| misnome wrote:
| Wait, so the words "concepts" and "requires" were newly made
| keywords, and this breaks code, but the words "yield" and "await"
| were determined too important and too common to standards members
| that they needed to be renamed to the horrifically ugly
| "co_await" and "co_yield"?
|
| Also, last time I actually tried to use C++20 none of the
| standard library implementations had std::format; has this
| changed now?
| StephanTLavavej wrote:
| std::format is available, with all C++20 Defect Reports
| implemented, in VS 2019 16.11.14 (and all later 16.11.x) and VS
| 2022 17.2 (and all later 17.x).
| AlexeyBrin wrote:
| > last time I actually tried to use C++20 none of the standard
| library implementations had std::format; has this changed now?
|
| MSVC is the only major implementation that has std::format for
| now.
| Forricide wrote:
| It's so funny to me that MSVC has become the cutting edge of
| C++ standards implementation. I remember starting out when it
| was a joke compared to Clang - although I was a novice, so
| who knows how complete my knowledge was at the time.
|
| In any case, it's a really impressive effort from STL and the
| rest of their library team. STL has some incredible CPPCon
| talks, too.
| tialaramex wrote:
| One way you could interpret this (definitely not the only
| way) would be that Microsoft - or some group within
| Microsoft - sees C++ as a possible legacy system, with an
| opportunity to make a lot of money by judging correctly
| what customers want and how much income you need to justify
| that support as existing offerings rust out (so to speak).
|
| Do you have any particular CPPCon talks to recommend ?
|
| My favourite is "Abseil's Open Source Hashtables: 2 Years
| In" by Matt Kulukundis, Matt's a fine speaker but what
| makes it so fun is that Hyrum Wright is in the audience
| yelling interjections as a result of Hyrum's law (this is
| scripted). For example Matt explains a significant size
| optimisation for people who only have a few things in their
| map, it's just smaller with no other consequences - right?
| Hyrum points out that now rehash happens earlier, so if you
| depend on it not to invalidate references during the first
| 15 insertions you are screwed. Guess whether any real
| Google code did that...
| a1369209993 wrote:
| > "Abseil's Open Source Hashtables: 2 Years In"
|
| URL seems to be
| https://www.youtube.com/watch?v=JZE3_0qvrMg ?
| Forricide wrote:
| I really love this talk in particular:
| https://www.youtube.com/watch?v=4P_kbF0EbZM (On charconv)
|
| But any of the ones I've seen from Stephan have been
| fantastic, I think, although I'm not actually sure if
| I've seen more. He seems to have a lot of talks on very
| specific subjects, which can be really fun.
|
| > Hyrum Wright is in the audience yelling interjections
| as a result of Hyrum's law
|
| This sounds absolutely hilarious, I'll have to take a
| look.
| StephanTLavavej wrote:
| I'm glad you liked my charconv talk! Here's a complete
| list of my recorded conference talks:
|
| BoostCon/C++Now 2012: Regex In C++11 And Boost:
| https://youtu.be/mUZL-PRWMeg
|
| GoingNative 2012: STL11: Magic && Secrets:
| https://docs.microsoft.com/en-
| us/events/goingnative-2012/stl...
|
| GoingNative 2013: Don't Help The Compiler:
| https://docs.microsoft.com/en-
| us/events/goingnative-2013/don...
|
| GoingNative 2013: rand() Considered Harmful:
| https://docs.microsoft.com/en-
| us/events/goingnative-2013/ran...
|
| CppCon 2014: STL Features And Implementation Techniques:
| https://youtu.be/dTeKf5Oek2c
|
| CppCon 2015: functional: What's New, And Proper Usage:
| https://youtu.be/zt7ThwVfap0
|
| CppCon 2016: tuple: What's New, And How It Works:
| https://youtu.be/JhgWFYfdIho
|
| CppCon 2018: Class Template Argument Deduction for
| Everyone: https://youtu.be/-H-ut6j1BYU
|
| CppCon 2019: Floating-Point charconv: Making Your Code
| 10x Faster With C++17's Final Boss:
| https://youtu.be/4P_kbF0EbZM
|
| CppCon 2020: C++20 STL Features: 1 Year of Development on
| GitHub: https://youtu.be/8kjRx8vo6y4
|
| Pure Virtual C++ 2022: MSVC C++20/23 Update:
| https://youtu.be/DAl37n2XOwk
| shadowofneptune wrote:
| I love the idea of placing a gadfly in the crowd to
| provide a dialogue.
| fouronnes3 wrote:
| One day in the far away future the standard C++ hello world
| will use 'import std;' and 'std::print' and it will be
| glorious.
| scatters wrote:
| The far away future? You mean next year?
| fouronnes3 wrote:
| I don't mean available as in the committee has published
| their final version of the standard that allows it. I mean
| available in production.
| scatters wrote:
| Oh, that'll probably be sooner, then; STL is already
| working on it. Also if you want to use it now, fmt has an
| implementation.
| germandiago wrote:
| That will be in cpp2 already:
| https://github.com/hsutter/cppfront
| jmillikin wrote:
| When I was going to university the computer science
| department's primary system had two compilers available, GCC
| 2.96[0] and TenDRA. GCC was generally more popular but it
| didn't have std::string and any code that threw an exception
| would crash, so adventurous students would use TenDRA for
| development.
|
| One of the stranger behaviors of TenDRA was that it put all
| standard library symbols, _including the C headers_ , into
| namespace std. A hello world in TenDRA looked like this:
| #include <cstdio> // no <stdio.h> available int
| main() { std::printf("Hello, world!\n");
| return 0; }
|
| It was not glorious. If anything ... the opposite. When
| TenDRA deigned to compile your program it would generally
| work (excepting bugs in the code itself), but getting it to
| accept any sort of third-party code was impossible because of
| the std namespace thing.
|
| I ended up writing a bunch of utilities for strings,
| including a unit testing library that spawned each test as a
| subprocess (to avoid exceptions) just so I could use GCC
| instead.
|
| [0] There is no such version recorded on the GNU project
| website.
| yyyk wrote:
| >There is no such version recorded on the GNU project
| website.
|
| It's sort-of recorded. It's not in the version list since
| there wasn't a release, just distros making a mess:
|
| https://gcc.gnu.org/gcc-2.96.html
| tolciho wrote:
| 2.96 exists, at least in the RedHat world.
| $ rpm -qi gcc Name : gcc
| Relocations: (not relocateable) Version : 2.96
| Vendor: Red Hat, Inc. Release : 110
| Build Date: Fri 12 Apr 2002 10:30:47 PM UTC Install
| date: Thu 20 Jan 2011 03:34:36 AM UTC Build Host:
| daffy.perf.redhat.com Group :
| Development/Languages Source RPM:
| gcc-2.96-110.src.rpm Size : 8389509
| License: GPL Packager : Red Hat, Inc.
| <http://bugzilla.redhat.com/bugzilla> URL :
| http://gcc.gnu.org Summary : The GNU cc and gcc
| C compilers. Description : The gcc package
| includes the cc and gcc GNU compilers for compiling C
| code. $ cat /etc/redhat-release Red Hat
| Linux release 7.3 (Valhalla)
| [deleted]
| frutiger wrote:
| https://en.cppreference.com/w/cpp/header/cstdio#Synopsis.
| [deleted]
| jdougan wrote:
| GCC 2.96 was a development version that incorrectly got
| released by Redhat on Redhat 7 (and possibly other
| distros).
|
| https://gcc.gnu.org/legacy-ml/gcc-
| announce/2000/msg00003.htm...
| jmillikin wrote:
| This was on a DEC Tru64 system, very far from any sort of
| Linux.
|
| My personal suspicion is that someone (student or
| faculty) got their hands on a CVS snapshot and installed
| it system wide. That's the only explanation I can think
| of for it being so broken.
| alternatetwo wrote:
| Fairly sure some PS2 SDKs also shipped GCC 2.96, which is
| why I know this tidbit of info.
| Sharlin wrote:
| C symbols are _supposed_ to be in std if you use the cstdio
| style headers. It's just that for a very long time
| compilers put them into the global namespace too.
| Calavar wrote:
| GCC, Clang, and MSVC all still duplicate c* header
| definitions into the global namespace by default as far
| as I'm aware.
|
| In fact, the last time I checked, the MSVC cstdio header
| was implemented more or less like this:
| namespace std { #include <stdio.h> }
| using namespace std;
|
| It's kind of crazy how major compilers have been ignoring
| the standard for so long that people consider a standard
| compliant compiler to be weird and broken.
| Forricide wrote:
| > It's kind of crazy how major compilers have been
| ignoring the standard for so long that people consider a
| standard compliant compiler to be weird and broken.
|
| I had absolutely no idea this wasn't even supposed to be
| the case (although I was aware of the duplication in
| std::). Guess it makes sense that the standard would shy
| away from global namespace pollution - I suppose one of
| the compilers perhaps did this for long enough that the
| others ended up duplicating it to increase code
| compatibility?
| gpderetta wrote:
| That the as actually not conforming. It was made
| conforming in c++11 because it was pointless to have the
| standard say something that all major implementations
| would ignore.
| pjmlp wrote:
| Already available in C++23.
| tialaramex wrote:
| The future tense seems better here. This _will_ (almost
| certainly) be available in C++ 23.
|
| In the context of Chromium, this slide deck, that means in
| about 2026.
|
| So if you're starting a three year degree next week, and
| you already know Google will hire you for the Chromium team
| straight after because you're the perfect person for that,
| you won't be writing std::print() calls in that codebase
| yet 'cos that's too early.
| pjmlp wrote:
| Well, they could convince their management to restart
| doing clang contributions for ISO C++ compliance, or
| maybe allocate 20% of their time for that.
| layer8 wrote:
| `std::this_thread::yield` already existed at the time, and
| "yield" was presumed to also be a common identifier in
| financial and agricultural contexts.
|
| I'm nevertheless surprised that new noncontextual and
| previously-unreserved-identifier keywords were added at all. In
| earlier times, the approach would have been to use a reserved
| identifier like "_Yield" for the keyword, and to provide a
| standard opt-in header that would `#define yield _Yield`. Maybe
| they don't want to add dependencies on the preprocessor
| anymore.
| Sharlin wrote:
| I'm not sure C++ has ever used the `_Yield` hack, except for
| C compatibility? C on the other hand uses it all the time.
| layer8 wrote:
| It could be that I'm remembering it from C.
| chippiewill wrote:
| It's super common in C because C doesn't have namespaces
| and templates which means stuff C++ implements as
| namespaced library classes C has to implement as language
| keywords.
|
| A good example is atomics. C++11 introduced
| `std::atomic`, C11 introduced the keyword `_Atomic`
| [deleted]
| codeflo wrote:
| Many are of the listed items are merely being deprecated. These
| shouldn't really qualify as breaking changes. In fact, the
| ability to migrate away incrementally is precisely the point of
| deprecating instead of removing a feature.
|
| What surprises me is that a lot of the deprecated functionality
| seems really recent -- C++14 or newer. Compatibility is C++'s big
| thing, that's historically why it kept almost all of C as a
| sublanguage. I know organizations where migrating to C++11 is
| still an ongoing process. It's not great news if features become
| obsolete faster than many users can adopt them.
| kristopolous wrote:
| It's a branding problem. They should probably be viewed as
| different flavors. Using say herbs or colors instead of numbers
| would help.
|
| If every time they're going to add things, remove things and
| break things then we're in practice talking different strands.
|
| Imagine some preprocessor where you can mix them like
|
| #flavor(ginger)
|
| Instead of say c++11 and then proceed with whatever flavor as
| necessary.
|
| I know you can do that at the linker and with makefiles and
| compile flags, this is about a more sane presentation.
| arinlen wrote:
| > _It 's a branding problem. They should probably be viewed
| as different flavors._
|
| They are already different language versions. They're
| specified in entirely different standards. I don't see what's
| left to be confused about. At most, perhaps the C++ standard
| committee could be criticized for repeatedly going out of
| their way to maximize backward compatibility.
|
| > _If every time they 're going to add things, remove things
| and break things then we're in practice talking different
| strands._
|
| They are already different standard. What's there to miss?
|
| > _I know you can do that at the linker and with makefiles
| and compile flags, this is about a more sane presentation._
|
| This take doesn't make sense. The C++ version being used in a
| project is a property of the project, not of the translation
| unit or individual files. A project is comprised of multiple
| declarations and corresponding definitions, which are spread
| around and reused and make sense as a whole. It would not
| make sense to, say, have a translation unit comprised of X
| C++11 definitions mixed with Y C++20 definitions.
| gpderetta wrote:
| Not only it is possible, it is routinely done. At $WORK we
| have libraries that are use std=20 features in its
| implementation and only expose a c++=14 interface because
| that's what expected by our clients.
|
| It is mildly painful, bit not more painful than restricting
| to c++14.
| kristopolous wrote:
| There's a lot there.
|
| Let's get the technical part done first.
|
| Historically after you create object files the linker
| doesn't care what c++ standard the source was. So you could
| carefully combine different standards. I guess I have to
| establish I'm talking about the GNU toolchain here and that
| it's been a few years since I've done this. I'll try it
| again when I get home, maybe that all blows up now.
|
| Now about the other parts. I totally agree with you.
| However we're dealing with humans and if they see
| incrementing numbers then the word "upgrade" and
| "deprecated" and "unsupported", maybe even "inefficient"
| gets bandied about just because we're using numbers.
|
| We have to go back to the core lesson of Perl 6, it
| shouldn't have been called Perl 6 because it suggests a
| hierarchical comparison and relationship that isn't an
| accurate depiction of reality.
|
| I wish everyone was sincere and competent but there's a
| natural tenancy to act based on the context that a
| structure affords.
|
| Churchill stated it as "we shape our buildings and
| afterwards our buildings shape us".
|
| So if the standards are better understood as siblings of
| each other then we need to brand them accordingly and not
| through a structure that suggests hierarchy, quantity of
| features, and degrees of relevance.
|
| Thanks for your response. I enjoyed reading it
| tialaramex wrote:
| > Historically after you create object files the linker
| doesn't care what c++ standard the source was.
|
| Mechanically this is true, but just because we can link
| object files together doesn't mean the resulting program
| makes sense.
|
| Suppose I have an object file I made with GCC's copy-on-
| write C++ 98 strings and then I linked that to an object
| file I made with GCC's modern C++ 11 short string
| optimised strings. If these objects think they're talking
| about the same string then the resulting executable is
| nonsense and will probably crash or misbehave badly.
|
| It might be helpful to think of WG21's attitude to
| compatibility as occupying a sort of "strategic
| ambiguity" akin to the US stance on Taiwan. For example
| when it comes to ABI changes, the committee voted that
| they shouldn't happen... yet. Not that they will happen
| within some horizon, but nor that they won't happen.
| kasajian wrote:
| The real solution, which decades from now will be the eventual
| common-place, but no one dares to imaging the possibility today
| is that when languages deprecate a feature, the compilers
| deliver code-mods that migrate your code-base perfectly.
|
| But people are afraid of going that route because of the bad
| press around Python 2 / 3. We need a new generation of
| developers that don't remember that.
|
| Today, there's already static-code analysis tools that
| automatically migrate entire code-bases to use new language
| constructs. The technology is there. It's the people who lack
| imagination to make it happen.
|
| Once it becomes commonplace, a large % of developers will care
| very little if some obscure feature of C is dropped. They'll
| just enjoy having a more streamlined language with all the
| legacy crap gone.
| sixstringtheory wrote:
| Swift is another one that has had a really bad migration
| between major versions, I can't really remember now but it
| was either 2->3 or 3->4. They had a static migrator and it
| barely helped, it would get into loops where it would e.g.
| flip flop between two different uncompileable fixups.
|
| Seems like this is a really hard problem, what is an example
| of a platform that has solved it perfectly or is even close?
| Swift was a brand new language, it should be easiest to do it
| there vs any system with legacy (although it was designed to
| interoperate with ObjC, so... maybe legacy remains).
| pixelrevision wrote:
| It was 2-3. My take at the time was that they built an add-
| on to crash xcode.
| Calavar wrote:
| UB throws a huge wrench into all of this. The behavior of a
| C++ program is defined by a combination of the code, the
| compiler, the compiler flags, and the target archecture. You
| can't write a source to source translator that preserves the
| semantics of a program with UB without that extra information
| about how it was compiled. It's a very hairy problem.
| 01100011 wrote:
| Doesn't Google Abseil, the standard library replacement, do
| this?
|
| https://abseil.io/
| ncmncm wrote:
| It is not a replacement, it is a staging ground and annex.
| tialaramex wrote:
| Transformations are difficult.
|
| Rust provides best effort transformation for its Editions
| (which only touch syntax) in cargo fix --edition, but even
| that's only best effort. If a proc macro does something
| ludicrous (see Mara's whichever-compiles! macro for example)
| how can the transformation hope to keep up?
|
| C++ versions are in much deeper, they not only change the
| language syntax, but also semantics of existing features.
| Sometimes the intended effect is null (but intentions may not
| match reality) and sometimes it is not.
|
| C++ also substantially changes the standard library. Rust's
| standard library grows but doesn't get redefined in new
| Editions, so if you call a deprecated Rust function it's not
| going anywhere, whereas a deprecated C++ method might
| actually go away in a future version.
|
| It's a shame that the best effort tools aren't provided with
| C++ compilers, but even if they were provided on a large
| codebase it's only the beginning for large projects.
| tialaramex wrote:
| Mostly deprecations mean something was deemed to be a bad idea,
| which means it's _at the very least_ worth taking a moment to
| evaluate whether somehow they were a good idea when you did
| them.
|
| For example should I have a method whose parameters are
| volatile? Well, why did I do that? It didn't do anything in C++
| 17 and it still doesn't do anything in C++ 20 but now it's
| deprecated. Programs are written _first and foremost_ to be
| read by other humans, but what was I trying to communicate by
| writing "volatile" on a parameter ?
|
| The deprecation of composite operators on volatiles is an even
| better example. Those _do_ something, but what they do might
| surprise programmers. Rewriting and then reading the rewritten
| example is an opportunity to discover that your code was
| _broken anyway_ because now it 's obvious. This obviousness is
| why deprecating the composites happened (and why it's sad that
| C++ 23 un-deprecates some of them).
| dataflow wrote:
| > Mostly deprecations mean something was deemed to be a bad
| idea
|
| "Most" maybe by count, but I'm not sure if it's "most" by
| usage frequency. There have been & will be lots of
| nonsensical deprecations that are _much_ more common in
| existing code than "putting volatile on an object argument"
| (which I've honestly never even seen anyone do in my life)...
| like static (which was undeprecated, thankfully, but how were
| people supposed to know this ahead of time?),
| std::aligned_storage, std::bind1st, std::iterator. They're
| frustrating as heck, have questionable merits to begin with,
| and working around the deprecations in existing code provides
| practically zero business value.
| tialaramex wrote:
| So as I understand this, you don't agree that std::iterator
| was deemed to be a bad idea?
|
| I mean, I personally would feel comfortable defending the
| idea that _is_ a bad idea, but that 's not even what I'm
| saying, I'm only saying it was _deemed_ to be a bad idea,
| which is exactly what the proposal for deprecating it
| explains.
| dataflow wrote:
| No, all I'm saying is that, as I see it, (a) it wasn't
| causing enough harm (if any at all) to warrant
| deprecation, and (b) that removing it doesn't deliver any
| worthwhile benefit either.
| evouga wrote:
| The volatile parameters deprecation is one of the stranger
| decisions, though, since there are _plenty_ of constructions
| that don't do anything but are still allowed by the language.
| I see this as a matter of style that might be useful to warn
| about, but shouldn't be policed as an error by the compiler.
| me_again wrote:
| Deprecated features are compiler warnings, not compiler
| errors, unless you use -Werror or the like.
| jcelerier wrote:
| > Programs are written first and foremost to be read by other
| humans
|
| extremely bold assumption. plenty of write-only or use-once
| code in the wild.
| tialaramex wrote:
| Fair, lets modify that to just "humans" not "other humans"
| and say instead that programs _should_ be written first and
| foremost with this in mind.
|
| I have never discovered a reliable way to discern whether I
| will re-use some code. Of course I could just delete it
| after first use and declare it "use-once" that way, but
| that's cheating, if I just have to type in the same program
| tomorrow we should admit that deleting it and rewriting it
| was a pessimisation.
|
| In the specific case of volatile parameters I can't figure
| out whether writing this in use-once code is more stupid or
| less stupid. On the one hand, you aren't misleading anybody
| else because the compiler knows perfectly well this doesn't
| do anything, on the other hand with the only human
| participant being yourself maybe _you_ think it does
| something and whatever that is you 're wrong so that's very
| bad.
| ModernMech wrote:
| I think if write-only code were the norm, then APL would be
| more popular.
| jcelerier wrote:
| But there are APL, k, j and other array lang programs.
| You can't do as if those don't exist when talking about
| programming as a whole. Perl used to be pretty popular
| too.
| gpderetta wrote:
| K is very niche, but in its niche is a extremely popular.
| ModernMech wrote:
| I didn't say array programming doesn't exist, I said it's
| not popular. How many people actually use those languages
| compared to e.g. Python, where readability is one of its
| main features.
|
| > Perl used to be pretty popular too
|
| And now it's a meme due to how illegible it is.
|
| I'll put it this way, there's a reason Brainfuck is a
| joke lang instead of something people seriously use.
|
| Also, reading and writing are not orthogonal skills. One
| has to read to be able to write. I read my programs
| constantly as I'm writing them.
| jcelerier wrote:
| and I am not writing about popularity, just saying that
| there are many in an absolute sense (which is honestly
| the only thing that matters in practice, relying on
| popularity of things relative to each other in a state of
| abundance is absolutely stupid)
| ModernMech wrote:
| Then I don't understand your point. The initial claim was
| that programs are written for human consumption first and
| foremost. To me, you seem to be replying that programming
| languages exist that are write only. In that case,
| agreed. But I don't see how that is meant to counter the
| claim that programs are written for humans.
| jcelerier wrote:
| I disagree with the "first and foremost" part - more
| precisely, I don't think it makes any sense to speak
| about this. There are people whose entire career will be
| only APL-ish or whatever funky ML-derived dialect,
| writing programs in a team of 1 and basically converting
| their thought processes directly into code, and their
| experience matters exactly as much as the experience of
| the X million developers in easier / more team/read-
| oriented languages matters.
| mort96 wrote:
| Is there a link to a recording anywhere? I find that slides
| usually miss a lot of the interesting information. Talks are more
| than their slides.
| amelius wrote:
| I stopped using C++ after lambdas were introduced (10 years ago
| or so?)
|
| Is there anything I can read to get up to date quickly?
| smhaziq wrote:
| https://learn.microsoft.com/en-us/cpp/cpp/welcome-back-to-cp...
| stefanos82 wrote:
| I would suggest to go through
| https://github.com/AnthonyCalandra/modern-cpp-features ; it's
| quite clean.
| kristopolous wrote:
| Broken link
| pivo wrote:
| Remove the trailing semicolon
| https://github.com/AnthonyCalandra/modern-cpp-features
| pjmlp wrote:
| Bjarne's "Tour of C++", 3rd edition.
| pornel wrote:
| Is one release really causing so many problems? I thought C++
| treated backwards compatibility as a holy thing.
| TonyTrapp wrote:
| From what I can gather, a majority of the problems reported
| there are new compiler warnings being triggered. Especially if
| you enable all compiler warnings to catch potential defects,
| any upgrade to a new compiler version will typically introduce
| a ton of new warnings that you have to work around.
|
| Edit: There are also quite a few deprecation warnings, which
| are also not errors per se, but nevertheless you'd want to
| avoid using deprecated stuff of course.
| redox99 wrote:
| When you have large codebases, _everything_ causes problems.
| When I worked with Unreal Engine, minor MSVC releases (same C++
| standard, same everything, just going from lets say 17.0 to
| 17.1) would sometimes make the code not compile anymore. Either
| because of new MSVC bugs, or because of incorrect code that was
| previously allowed.
| IshKebab wrote:
| It generally does although they _have_ made technically
| breaking changes in the past (e.g. `auto`). This is the first
| release I 've used where they broke something in actual code I
| use because of the comparison operator changes.
|
| However it was easy to fix and actually it was because whoever
| wrote it did it wrong. Google also found a breakage that was
| hiding a bug.
|
| So maybe their new stance is "only break incorrect code"? I
| dunno. I feel like a small amount of breakage is reasonable
| anyway. Breaking change absolutionists are generally just being
| dogmatic, and haven't really thought through what _zero_
| breaking changes really implies.
|
| E.g. in languages with introspection it technically means you
| can't change _anything_.
| pjmlp wrote:
| They also broke the code of the few users that made use of
| exception specifications.
| pjmlp wrote:
| All languages break backwards compatibility, just not to the
| extent of Python 3.
|
| Heck even Go folks are discovering their stable guarantee isn't
| as stable as they thought.
| kardianos wrote:
| Re Go, sure, but most (all?) of those have to do with
| security updates that may impact features. The discussion is
| how to make them less painful or opt-in/out in the standard
| library. None of this has to do with the language itself.
| pjmlp wrote:
| A break is a break, regardless of the cause.
| forgotpwd16 wrote:
| It doesn't cause problems as in old things don't work as in it
| takes time to get advantage of newly introduced ones and
| replace anything considered deprecated (edit: and rename
| variables clashing with new keywords).
| leni536 wrote:
| Not mentioned here, but some stuff we bumped into:
|
| * std::filesystem::path broke some APIs with the introduction of
| u8string.
|
| * some deprecated interfaces of std::allocator got removed.
|
| It was easy enough to resolve and we are in the process of
| switching to C++20.
| butterisgood wrote:
| Damn. May as well have used a language that isn't released yet
| like Zig. That's a ton of problems.
| TinkersW wrote:
| Um no. When I upgraded it was a few hours of work at most, for
| Google since its code base is extremely large maybe a few days
| to weeks.
| Matumio wrote:
| Probably no big issue for a small to medium codebase. But I
| doubt the "just a few days" estimate for something as big as
| a web-browser. If I read correctly they even found use-after-
| move bugs during the process.
| TinkersW wrote:
| The use after move existed prior, just wasn't moving even
| though they had written move.
|
| It is also written in a way that a linter should be able to
| detect if you disallow use after move.
|
| https://source.chromium.org/chromium/chromium/src/+/main:co
| m...
| ninepoints wrote:
| Is this a joke?
| mrazomor wrote:
| Very useful presentation. Full of details, but easy to consume.
|
| On voices against stripped down C++ (via code style): I find it
| working great in practice. Makes the codebase manageable, and
| keeps people away from using unnecessary complex language
| features (imagine Java code heavy with streams or reflection, or
| Python code that resolves most of dependencies at runtime,
| javascript full of eval(), etc.). Switching to a new language is
| half-baked plan.
| jcelerier wrote:
| > imagine Java code heavy with streams or reflection, or Python
| code that resolves most of dependencies at runtime, javascript
| full of eval(), etc.
|
| all these things are sometimes the best solution to a given
| problem
| hi_herbert wrote:
| Ad-hoc black or white bans are very retrograde and costly for
| tje most part and usually stem from purity thinking. Case in
| point reflection in Java is a godsend. I use it very rarely
| because it'd uses only comes for very specific needs but when I
| use it, the alternative either doed not exist or usually would
| be much more uglier. As for streams well it's just regular
| functors (map, filter) they are used in every language and are
| very useful. Now I agree about two things: 1) the stream api is
| a bit (not that much though) verbose, which significantly
| contrast with Kotlin. Although e.g .toList() helps 2) yes
| develpers especially junior ones are eager to abuse functors in
| an unreadable mess. When there is complexity using loops is
| usually more readable. Streams however are very fit for regular
| ETL that represents ~70% of code for most simple apps. The
| pinnacle of complexity would be e.g. Reactive streams such as
| rxjava.
|
| I agree python dependencies are a worldwide shame and eval() is
| very niche (but again should not be universality banned
| assuming good developers, maybe though one could conditionally
| ban it aka it would trigger a lint during code review that
| would need explicit validation.
|
| As for the topic at hands, google style bans are insane e.g. No
| Exceptions lol
| f1shy wrote:
| I agree with this comment, and cannot understand why is
| downvoted. I would like the one that downvoted comments on
| why. My thinking, more or less in line with the comment is:
| instead of investing energy, time and resources in writing
| laws of what is allowed and what no (often without
| rationale). Use that time, effort and energy in educating
| developers, so that, if those prohibitions are really
| sensible, they will anyway refrain from doing that. You get
| the benefit of not having to change the bans. By doing
| regular code reviews, you can detect ill formed code, and
| discuss with the developers. Maybe some developer has
| something to teach to the "big experts" who write those
| documents?
| mrazomor wrote:
| What's easier: writing set of rules to drop language
| features or educating 10k engineers? It's difficult alone
| to have those engineers follow the style guide (even with
| help from linters etc).
|
| Average engineer, in any company, doesn't care about the
| language they use. Just wants to get stuff done. And that's
| how it should be.
| hi_herbert wrote:
| f1shy wrote:
| My experience says, if you want to do one project. By all
| means, it's easier to have a standard where you drop
| features. -- But beware: you need either good engineers
| or you have to educate them, anyway.
|
| If you have constant new projects, each one with very
| different requirements and needs, it will not be so easy
| to make a standard "one size fits all".
|
| Also, again, you will not be doing "just one" standard, I
| would not subestimate the effort of such rulesets. You
| will have to the modify and modify it constantly (I know
| it from the company I'm, there are whole teams working on
| that, doing meetings constantly with stakeholders, and
| replying to exception requirements). In the long run, I
| would prefer to have good engineers, that do not need to
| be lead in each little step. --and having to check if
| they adhere to the rules!
|
| I like the phrase: "If you think education is expensive,
| try with ignorance" Or: - I'm afraid to waste money
| educating our employees, and then they leave us - What if
| we do not educate them, and they stay?!
| mrazomor wrote:
| "no exceptions" is one of the best parts of Google style
| guide, IMO. Note that, banning of exceptions introduced
| returning status (error codes done right). It makes it easier
| to follow the code and makes the code more readable (but, you
| need a few macros, unfortunately).
| hi_herbert wrote:
| ncmncm wrote:
| OK if you like 10-15% performance loss off the top.
|
| And incompatibility with the rest of the world.
| GnarfGnarf wrote:
| The Boeing 377 Stratocruiser was the epitome of piston
| technology: 28-cylinder radial engine that needed more
| maintenance than flying time. It vibrated so hard that it
| separated from the wing.
|
| https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser
| B1FF_PSUVM wrote:
| Leads to
| https://en.wikipedia.org/wiki/Aero_Spacelines_Pregnant_Guppy
|
| As some comedian used to quip, Pregnant Guppy would be a good
| band name.
| pinkorchid wrote:
| Maybe you're being hyperbolic, but the catastrophic engine
| separations in the Stratocruiser were due to propeller
| failures.
|
| http://enginehistory.org/Propellers/B377Props.pdf
| cpact wrote:
| philliphaydon wrote:
| This might be a stupid question. But is there performance
| degradation between versions of c++?
|
| I saw a couple of stack overflow questions last week of people
| complaining about c++ 17 being slower 14, and 14 being slower
| than 11.
|
| But I find it hard to believe. I just started learning c++
| recently and can't find a conclusive answer.
| d110af5ccf wrote:
| Those are just versions of the standard. What people would be
| comparing is the performance of particular implementations.
| It's entirely possible that a less mature implementation would
| have problems.
| philliphaydon wrote:
| Yeah that makes sense, thanks.
| kadoban wrote:
| If you're writing the same code, almost certainly not.
|
| The only way there would be would be if the compiler either
| can't optimize something as well because the lang changes
| requirements (this seems unlikely), or if they have bugs or
| inefficiencies because they haven't spent much time on the new
| standard.
|
| If you're using new stuff from the new standard, they could be
| slower or faster or undecidable, really depends.
| jcelerier wrote:
| There is at least one language-enforced performance
| improvement: C++17 enforces some amount of RVO. Thus some stuff
| that would have been copied in previous standard is now not
| anymore. More standard types supporting move semantics & such
| also mean that generic code which correctly calls std::move /
| std::forward may do fewer copies the more recent standard you
| use.
| pclmulqdq wrote:
| The "idiomatic" version is slowly getting slower because the
| idioms are getting higher-level and more expressive. If you
| don't use the idioms, you can have the same speed. Smart
| pointers (including unique_ptr<Foo>) have non-zero overhead
| compared to Foo*. The object oriented parts can introduce
| significant slowdowns. Template code can have huge code
| footprints if you are not careful, which slows things down.
|
| If you are looking for cycle-level performance, you likely need
| to use a more C-like subset of the language, but you can still
| use many conveniences like RAII and the smart pointers with 0
| overhead (when construct/destruct are not in the critical
| path).
| ncmncm wrote:
| The above is commonly encountered, but not good advice.
|
| Most important, defend your hot path against incursions.
| E.g., don't pass smart pointer arguments around on hot paths.
| That is what matters.
|
| New language features are not slower than old features. But
| there are slow constructs to use carefully. Which they are
| will always surprise you, usually pleasantly. For example,
| almost everything around lambdas is fast, fast, fast, except
| =capture.
|
| Measure often. Look for surprises.
| jcelerier wrote:
| > Don't pass smart pointer arguments around on hot paths.
|
| oh this so much.. I remember optimizing a particle system
| which would copy a shared_ptr for each particle on every
| update operation... IIRC just switching to references ended
| up being 10+ times faster
| latency-guy2 wrote:
| If you can design your system so you rarely if ever use
| pointers, that would be the single best thing you can do
| for your C++ codebase
|
| I like to enlighten my interns every summer about the
| reality of pointers, and how much of a noob trap they
| are, and that yes, their professor lied to them in some
| ways
| jcelerier wrote:
| sadly this was not "my system" but was something for a
| 2-3 day project on an unknown codebase so a deeper
| refactoring was out-of-the-question
| pclmulqdq wrote:
| I literally said not to construct or destruct smart
| pointers on the hot path.
|
| Also, my experience with lambdas has been otherwise. There
| are a lot of cases where lambdas need a heap allocation
| when you otherwise wouldn't. However, being able to use FP
| ideas can make up for that.
| pjmlp wrote:
| It is so ironic, that now that Apple and Google decided to focus
| on their own language stacks, the C and C++ compiler vendors that
| profit from clang's license aren't that keen in making the
| upstream work for catching up with ISO C++.
|
| Thus making the once famous clang having an honorable third place
| in ISO C++ compliancy.
|
| Seeing this from a Google team makes it even more ironic.
| otabdeveloper4 wrote:
| gcc is better than clang on every metric. Sorry, it's the
| facts. -\\_(tsu)_/-
| loxias wrote:
| Whoa, really? Since when??
|
| After a lifetime of using GCC, I (like many others) moved to
| clang a few years ago, out of frustration with the slow
| development of GCC, a desire to use new C++ features, and
| stayed because of the superior error messages and, in my use
| cases anyway, superior code generation.
|
| In addition, I gather it's a much cleaner and easier to
| maintain code base. As a result, we get to have cool things
| like emscripten, llvmpipe, all sorts of static analysis tools
| that would be more challenging to build in the GCC universe,
| and much more.
|
| Honestly, I thought GCC was slowing down development wise.
|
| Is GCC worth trying again? Can you name a few "cool new
| things" I can do with GCC that I can't with clang? There's
| plenty of the opposite...
| intelVISA wrote:
| LLVM always delivers the cooler stuff I'll admit but GCC is
| ahead as an optimizing compiler, general lang support and
| generating cryptic messages.
| secondcoming wrote:
| Interesting, I've generally found that clang is better at
| optimising, especially when it comes to auto-
| vectorisation.
| superdimwit wrote:
| Agreed, autovec is in my experience where clang really
| shines.
| germandiago wrote:
| GCC is quite up to date. Also, the code generation used to
| be better. I do not know right now. But I think it still
| might have a slight advantage.
| pjmlp wrote:
| C++20 support comes to mind, the plethora of supported
| hardware as well.
| ncmncm wrote:
| Gcc pretty consistently delivers slightly faster code.
| DannyBee wrote:
| This is often true for SPEC, but not true for real world
| code.
|
| Or at least, we _extensively_ tested this at Google,
| before, during, and after the move to LLVM.
|
| On many thousands of libraries, binaries, etc, made up of
| hundreds of millions of lines of C++.
|
| While there were wins and losses, on average, LLVM was a
| consistent net positive.
|
| That was true despite having spent 5+ years of having a
| large team dedicated to doing nothing but finding places
| to improve performance of GCC compiled code (and
| contributing back patches), and doing so very
| successfully.
|
| That said, as time approaches infinity, the compilers are
| going to generate the best code for the things that
| someone took the time to analyze and make the compiler
| better at.
|
| There is, in the end, no magic that makes GCC better than
| LLVM or vice versa. The vast majority of it is tuning and
| improving things little by little for whatever targets
| someone is trying to improve.
| pyler wrote:
| proof?
| ncmncm wrote:
| Keyword there is "slightly".
| loxias wrote:
| Not in my experience! Though it was a few years ago, I'll
| have to re-evaluate. In the past, when doing
| numeric/scientific programming -- lots of dataflow, it
| was much easier to "coax" clang to generate the right
| (performant) assembly than GCC. I guess my use is less
| typical -- the internet agrees with you. :)
|
| Hurrah for competition!
|
| (of course, neither GCC or clang could _ever_ beat ICC at
| some of my tests.. _grumble_ )
| DannyBee wrote:
| "(of course, neither GCC or clang could _ever_ beat ICC
| at some of my tests.. grumble)"
|
| They never tried, honestly - ICC had plenty of defaults
| that were targeted at performance above correctness.
|
| That's fine - but it wasn't what either clang or gcc was
| going to go for. Even when trying to compare apples to
| apples, folks often compared them by trying to get
| GCC/Clang to emulate the correctness level of ICC (IE
| give GCC/Clang more freedom), rather than the other way
| around :)
|
| Which, again, similarly understandable, but also a thing
| that you'd have to spend a while on in GCC/Clang to get
| to a reasonable place)
|
| Small-number-of-target compilers like ICC are also
| fundamentally easier. Lots of techniques (IE optimal
| register allocation[1], etc) that add up to performance
| gains are a lot more tractable to really good applied
| engineering when they don't have to be so general.
|
| Similarly small-target-market compilers are also easier.
| Over time, high performance was literally ICC's only
| remaining market. So they can spend their days working on
| that. GCC/Clang had to care about a lot more.
|
| [1] This happens to now be a bad example because advances
| finally made this particular thing tractable. But it took
| years more, and feel free to replace it with something
| like "optimal integrated register allocation and
| scheduling" or whatever is still intractable to
| generalize.
| spoiler wrote:
| I've always preferred clang for its better lints, and
| friendlier error messages (sans some decrepit parts around
| templates that are equally horrendous everywhere)...
|
| And _theoretically_ clang has better ASM output in some cases
| I say theoretically, because it 's been shown that GCC's
| "worse" ASM performs better; I'm not really an architecture
| aficionad, so I can't comment as to why that is.
|
| Also, it's been a few years now since I did C/C++. So, maybe
| these are no longer the case.
|
| Anyway, I've kinda pointed out what I like about clang over
| gcc, but I'd be curious what you prefer in gcc.
| newobj wrote:
| clang doesn't output asm
| spoiler wrote:
| I'm not sure what you mean? You can use `-S`
| hi_herbert wrote:
| I wonder how up to date is the old belief of better error
| messages. The was some great redhat blogs about structured
| error messages in newer GCC.
| spoiler wrote:
| Ok, that's kinda true I suppose; I remember that GCC's
| error messages have indeed gotten better after a major
| version release.
|
| Also, when you say structured, do you mean errors over
| LSP, or do you mean more structure in the formatting when
| reporting in CLI?
| bayindirh wrote:
| GCC returns pretty nice, colored and structured error
| messages in CLI for quite some time.
| hi_herbert wrote:
| I meant in cli a bit like rust arrows logs
| yakubin wrote:
| GCC has gotten better indeed, but it's still in a
| different league than Clang. I still get into situations
| where I can't make heads-or-tails of what GCC is saying
| to me, which can usually be easily solved by switching to
| Clang.
| nikic wrote:
| One problem here is that GCC emits certain warnings as
| part of the optimizer, which results in many false
| positives that are essentially impossible for the lay
| programmer to understand. For example, jump threading
| might duplicate some code path and propagate constants in
| it, and then warn about an uninitialized variable / out
| of range access / etc in that code-path, even though it
| does not exist in that form in the original program.
| MauranKilom wrote:
| Funny enough, this is exactly the kind of situation where
| other people cry "why did the compiler not warn me about
| basing optimizations on UB".
| hi_herbert wrote:
| I don't do C++ anymore but I will forever remember the
| Vtable hell "messages" when doing OOP and doing a slight
| unintuitive mistake about destructor or constructor. Is
| this still a thing in clang?
| hi_herbert wrote:
| What is the status of ubsan, msan, tsan and others support
| for GCC though? Last time I checked they were a bit behind. I
| agree GCC make clang obscolete regarding C++ support and even
| performance. I don't know a comprehensive alternative to
| clang linter but I'm sure there are a few.
|
| Given that llvm receive more human resources than gcc by far,
| I once expected it to outperform gcc generally (e.g support
| for polyhedral optimizations, BOLT, etc) Unfortunately
| weirdly it seems llvm performance is mostly stagnant. I
| personally suspect we are reaching increasingly diminishing
| returns with AOT and that the performance graal would be a
| hybrid that also does JIT at runtime (beyond PGO therefore)
| and more interpretable than BOLT
| ghosty141 wrote:
| At work GCC is a lot slower than clang, the project uses a
| bit much template magic but still, clang is faster.
|
| Where does this GCC is faster thing come from? I personally
| havent experienced it
| pyler wrote:
| Old hype thing created by gcc fanboys :)
|
| They always claims so.
| hi_herbert wrote:
| I mean faster runtime performance, I have no clue about
| compilation time. Well I'm basing this on the countless
| benchmarks I've seen, e.g. on phoronix over the decade.
| Also you have to understand that Clang -O2 is (was)
| "unfair" as GCC did not enable autovectorization until
| -O3. This has (is being?) changed.
| Rochus wrote:
| Why is it ironic?
| yakubin wrote:
| I think the main differentiators for clang were more readable
| error messages than the mess GCC had (and still has), and
| faster compilation (here it lost a bit of its advantage over
| time). I haven't heard of anyone praising it over GCC based on
| standard compliance.
|
| That said, when I explore weird edge cases in how differently
| Clang and GCC parse source code, and how differently they
| optimise it, in my experience Clang is still the more logical
| one, whenever there is a disparity, whereas the way GCC parses
| code and what code it produces is sometimes completely baffling
| (and that's not just optimisation stuff - without any
| optimisations enabled I encountered miscompilations a lot more
| with GCC than Clang).
|
| I also consider C++ a language for mostly old projects. I start
| new ones in other languages and don't consider repeated
| rewrites every two standards, because the "modern c++" crowd
| found a new way to initialise variables, to be a good
| investment of my time.
| germandiago wrote:
| > I start new ones in other languages and don't consider
| repeated rewrites every two standards, because the "modern
| c++" crowd found a new way to initialise variables, to be a
| good investment of my time.
|
| Same here, but I update my new code as I go if there is a
| better/safer way to do it that does not impact in any bad way
| my codebase.
| cogman10 wrote:
| > I haven't heard of anyone praising it over GCC based on
| standard compliance.
|
| Back in the day (C++0x era), it was near bleeding edge. Clang
| had all the proposed 0x features ready to go before C++11 was
| released.
|
| It took a while for GCC to get all the C++11 features after
| the release.
| qsdf38100 wrote:
| You don't have to rewrite anything. C++ keeps backward
| compatibility. You don't have to make it sound like it's the
| case, and you don't have to shame the "modern c++ crowd" over
| that false claim. That's just uncalled for, unconstructive
| and partisan discourse. I expect better from HN.
| jnwatson wrote:
| Did you see the original post? Lots of code changes were
| required for Chrome. That's not backwards compatible.
| qsdf38100 wrote:
| It's 99.9% backward compatible. The comment makes it
| sound like it's a huge pain every 2 years, as if it was
| the "python 2 to 3" level of pain.
|
| I went through a lot of these new versions, starting with
| c++11, and can't remember one time I had to change
| anything to my code based, appart from silencing
| deprecation warnings for unicode stuff.
|
| Now I get that chromium-like code bases are huge and that
| the 0.1% of backward incompatibility is still a pain.
| Now, with that level of hugeness of code bases,
| maintaining it when the language evolves is going to be a
| pain. C++ has been very careful with backward compat,
| breaking very few things, compared to other languages. So
| these criticisms really are uncalled for to me. Sounds
| like good ol c++ bashing trying to sound wise.
|
| I felt the comment wasn't fair and wasn't an honest
| criticism. Sorry for my angry comment. We live in rough
| times.
| nikic wrote:
| This has no relation to Clang's permissive license. The problem
| here is generally that nobody has implemented the necessary
| support, not that they have implemented support in their
| private forks but did not bother to upstream it. A GPL-style
| license doesn't magically force contributors to start working
| on a particular feature.
|
| Google at least is one of the largest contributors to the LLVM
| project -- it's just that their contributions don't tend to
| focus on Clang frontend work.
| compiler-guy wrote:
| Anymore. Google used to contribute quite a lot to libc++
| especially, but have found that the language is going in a
| direction that doesn't meet its needs.
|
| Not sure why Google would continue to contribute under those
| circumstances.
| mkoubaa wrote:
| The thing vendors care about more than anything is making
| upstream work supported.
|
| Google isn't even complaining about things, this is a very dry
| technical document about their experience, for an amount of
| work they certainly expected and were possibly even pleasantly
| surprised about.
|
| These sorts of things are routine in massive code bases
___________________________________________________________________
(page generated 2022-09-25 23:00 UTC)