[HN Gopher] GCC 11.1
___________________________________________________________________
GCC 11.1
Author : lelf
Score : 193 points
Date : 2021-04-27 13:24 UTC (9 hours ago)
(HTM) web link (lists.gnu.org)
(TXT) w3m dump (lists.gnu.org)
| yakubin wrote:
| It took this mail a bit over 3 hours to be sent to my mailbox. (I
| subscribe to gcc-announce.) I'm curious what the reason for such
| a delay is. (Nothing wrong with the delay, just curious about the
| technical reason.)
| xkeysc0re wrote:
| They might be using a cron job or some other batch process to
| send the email to each member of the mailing list. There are
| limits to CC and BCC, I believe.
| diegocg wrote:
| Do you use gmail? Gmail restricts the amount of mails that a
| single sender can send, so sometimes mailing lists have to
| retry until gmail lets them send (this is a paint point for the
| Linux kernel mailing list)
| yakubin wrote:
| I use Fastmail.
| anarazel wrote:
| My guess: Sending email to a lot of recipients when you're not
| a large email provider can end up with you getting throttled /
| needing to apply throttling to individual servers to prevent
| blocking.
|
| In the past when I still operated my own email servers I often
| saw list emails minutes before on e.g. gmail.
| boris wrote:
| If anyone is looking for a build system to try C++20 modules with
| GCC, there is build2:
| https://build2.org/blog/build2-cxx20-modules-gcc.xhtml
|
| There is also a repository of module examples (some trying to
| imitate real-world usage like distributing modules as part of a
| library): https://github.com/build2/cxx20-modules-examples/
| mhh__ wrote:
| The changelog isn't final yet, so I'm not sure if I should link
| it or not, but there are some nice additions to the D frontend in
| this one.
|
| "Reports of my death are greatly exaggerated" - GCC
| typon wrote:
| I wish there was a C++ standard that didn't add any features, but
| only fixed bugs or deprecated old features, and possibly improved
| existed features, giving compiler writers a chance to actually
| catch up and developers a chance to stabilize their codebases.
| C++26?
| pjmlp wrote:
| Nope, Python 3 showed what happens.
| PopsiclePete wrote:
| What happens? You become the most-widely used language on the
| planet? The Python 2-3 wars are over. Python 3 won.
| pjmlp wrote:
| I just installed Python 2.7 on my new project because some
| critical libraries used by the customer don't care Python 3
| exists.
| xxpor wrote:
| Open source ones?
| pjmlp wrote:
| To some extent yes, and no I am not going to mention
| which ones.
| xxpor wrote:
| I just can't think of a major open source python lib that
| hasn't added support for 3 if the functionality wasn't
| replaced by a new feature in 3.
| tsimionescu wrote:
| You get 10 years of headaches for everyone who gets close
| to the language. Even today, the python executable in
| Ubuntu is called `python3`, not `python`.
|
| To be fair though, it would be less of a problem for C++
| than it was for Python, since you wouldn't have to depend
| on the compiler from the end-user system.
| xvilka wrote:
| There is. It's called Zig[1]. Usually I would have written
| Rust, but it's good to give Zig more publicity.
|
| [1] https://ziglang.org/
| dralley wrote:
| OP didn't ask for a new language that is stable, they asked
| for a stable C++.
|
| But yes, it's true that Zig aims to be a minimal, stable
| language - when they go to 1.0, which hasn't happened yet.
| It's still changing frequently.
| nsajko wrote:
| This evangelism stuff has really got out of hand on HN - a
| whole new language is literally the opposite of what the
| parent asked for. To make matters worse, the languages you
| choose to evangelize are new/experimental, making your
| comment even less on point.
| accusitive wrote:
| Yeah. I like rust but I feel like its pushed way too hard.
| If its really 'that good', people will slowly pick it up.
|
| I personally don't like c++, but I wouldn't enjoy someone
| going on a rust thread and shilling c++. So I won't shill
| rust on a c++ thread. Seems similar for Zig.
| Ericson2314 wrote:
| It's just shilling.
|
| OP asked for:
|
| > only fixed bugs or deprecated old features
|
| When you get right down to that, you _do_ end up with
| something like Rust. E.g. C++ 's move semantics are weird
| because for historical reasons copying is the default.
| Get rid of those historical reasons, and there's no
| reason not to do it the Rust way.
|
| 40 years of "no big breaking changes" really is a lot of
| cruft.
| jcelerier wrote:
| > and there's no reason not to do it the Rust way
|
| memcpy everywhere is definitely _not_ the best answer to
| every problem
| Ericson2314 wrote:
| If you want a copy constructor, it would work like this:
|
| Copy : Clone :: Move : Relocate
|
| I.e. there would not be the presumption that everything
| is automatically movable _or_ coppiable, there would be
| magic traits to indicate memmove / memcpy and friends,
| and then plain old stdlib super traits for user-defined
| cloning and relocating.
|
| This is the the right design for move constructors, full
| stop.
| FreeFull wrote:
| It's not like C++'s move semantics magically get rid of
| the necessity of copying data either.
| Ericson2314 wrote:
| I meant to write it's _not_ just shilling.
| seoaeu wrote:
| > If its really 'that good', people will slowly pick it
| up.
|
| Empirically, that's been happening?
| overgard wrote:
| Sadly, I really doubt it. The standards committee seems mostly
| interested in adding new template metaprogramming features at
| this point. What I /really/ wish they would focus on is
| modules. 100% of C++ developers suffer from horrible compile
| times, and yet it seems to always get punted.
|
| (Not to mention that forcing developers to write header-only
| libraries to use templates pretty much makes them way less
| attractive anyway)
|
| Edit: maybe I'm wrong? It looks like modules are in C++ 20. No
| idea if any compilers are supporting them yet.
| qalmakka wrote:
| Modules have been released with C++20, but no compiler has a
| complete implementation for them yet. Also the standard
| library hasn't been modularized yet.
| zxzax wrote:
| How is it possible that modules were released, if nobody
| has a working implementation? I was under the impression
| that proposals needed at least a proof-of-concept
| implementation from a sponsor. My exposure to this is
| searching the CMake tracker for this last year and seeing
| that it wasn't even working there yet.
| qalmakka wrote:
| As the other answer said, nobody has (yet) an
| implementation of the _released_ standard, but both GCC
| and especially Clang have had modules very close to what
| stabilized by C++20 for years. You can enable them by
| specifying a flag (-fmodules-ts) on any recent release of
| Clang.
| zxzax wrote:
| I know that but I'm just baffled that the text of the
| standard could be released at a point in time when nobody
| has succeeded at implementing it fully. That seems like
| it would almost guarantee that no one implements the
| standard as it's written, as there is no proof-of-concept
| that it's truly viable... I'd expect to see several
| revisions to this before C++23 as the compilers work out
| the issues.
| jcelerier wrote:
| > How is it possible that modules were released, if
| nobody has a working implementation?
|
| there were plenty of experimental implementations over
| the years, some people have been using some flavour of
| "modules" with MSVC and Clang for something like 5
| years... hell, technically it has always been possible to
| compile code as objective-C++ to leverage the objc module
| system if you could afford to use clang everywhere
| pjmlp wrote:
| Watch the Visual C++ virtual day coming next week.
| vips7L wrote:
| MSVC is expected to have C++20 feature completeness in VS
| 2019 16.10 Preview 3.
|
| https://github.com/microsoft/STL/wiki/Changelog#expected-
| in-...
| nindalf wrote:
| Isn't modules already a part of C++20?
| sesuximo wrote:
| Modules doesn't even really speed up the build if you have a
| highly parallel build... and it's unclear how build tools
| should support it in a uniform way. I think modules will go
| unused but I hope I'm wrong
| petters wrote:
| The standardization work for modules is done. Now all build
| tools and code bases need to start supporting it in a good
| way.
| jcranmer wrote:
| Compiler writers are pretty quick to add support for new
| features--I'd say it's about a year-ish between being added to
| the standard (which is not the same as the actual release it's
| in!) and actually being usable in a compiler.
|
| Where the delay comes into play is that most projects require a
| minimum support of a compiler that's several years out of date.
| And if you're required to support 4-year-old compilers, then
| C++17 features aren't going to be available, despite them being
| available in the newest versions of all compilers. Back in
| 2018, I was working on a project where I gave up and used C++17
| features (constexpr if) because I knew I could get away with
| only supporting a Clang that's a few weeks old.
| beached_whale wrote:
| Pick a C++ version and use that then. Compilers are not
| dropping old versions of the std, but the new versions are just
| that new. No deprecation affects an older version of C++ and no
| one is forcing developers(as seen by the 20-30% that still use
| C++98/03) to upgrade their code bases.
| not2b wrote:
| Yes, all you need to do, with both g++ and clang, is to
| specify the version of the standard that you want. Picking a
| mature standard makes it likely that most bugs have been
| fixed.
| sesuximo wrote:
| Compiler writers aren't that far behind? C++17 is mostly
| supported. C++20 is one year old!
| SubjectToChange wrote:
| "C++20 is one year old!"
|
| The ISO standard was published in December of last year. So,
| technically, C++20 is only four months old.
| seoaeu wrote:
| > C++17 is mostly supported.
|
| For essentially any other language this would be an absurd
| thing to say. For those languages you wouldn't consider a
| feature added until it was supported by the reference
| compiler
| R0b0t1 wrote:
| Some of the additions, like coroutine support, are roughly bug
| fixes.
| PopsiclePete wrote:
| backwards compatibility is a bitch.
|
| But yes, there's a reason why high-visibility C++ projects like
| Chrome basically white-list 30% of the language and keep it
| that way, to some small sub-set they feel is "good enough".
|
| The problem is the fragmentation this causes. I pick these 5
| features of the language, you pick another 7, I can't use your
| lib, etc, etc.
|
| C++ is becoming extremely bloated. Bjarne said as much in one
| of his recent criticisms at the highly-specialized use-case
| proposals that people wanted to make "standard".
|
| I enjoyed his C++11 book but now that's probably all outdated
| "oh we don't do it that way anymore" stuff and I can't afford
| to just buy 2-3 1000-page books every year to keep up. Got
| better things to do.
| johnklos wrote:
| The MODE_CC conversion for VAX is in this version. Yay!
| megous wrote:
| __attribute__ ((malloc (mydealloc, 1))) looks interesting. Didn't
| know about that one.
| akira2501 wrote:
| Likewise, this caught my eye: As in C++, function definitions
| no longer need to give names for unused function parameters.
|
| Goodbye UNUSED() macro!
| [deleted]
| brobdingnagians wrote:
| Good to see the experimental C++23 features[1] starting to get
| support. Looks like literal suffixes for size_t are first. [2]
|
| [1] http://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2019/p059...
|
| [2] https://gcc.gnu.org/gcc-11/changes.html
|
| [3] https://en.wikipedia.org/wiki/C%2B%2B23#cite_note-1
| Decabytes wrote:
| I'm naive about the language development process. I have no area
| of expertise in C++. But coming from a background in Python I've
| seen people complain about Python getting bigger and bigger, and
| people have been complaining about C++ being huge for even
| longer.
|
| In my naive opinion, It seems to me that both C++ and Python have
| reached a point where most people are satisfied with the features
| the language has. Most of the complaints are around warts in the
| language itself that people wish could be fixed (but can't due to
| backwards compatibility).
|
| My question is why the need to keep adding features? Sure if
| something comes out that C++ is desperately lacking, add it in.
| But it seems like that hasn't been the case for a while.
|
| My other question. Would it be possible for a language to work
| like an OS? Where there is a LTS version of the language that is
| supported for X years, and then a new version comes out that
| contains potentially (but not always if it's unnecessary)
| breaking changes? I guess Python was kind of an example of that
| with Py2 to Py3, but no one who started using python after 1.0
| expected there to be a shift like that. But if from the outset
| there is that expectation that after 5-10 years there will be a
| new version that removes warts in an old version would people
| accept that?
|
| It seems to me that the lifecycle of a language that is
| successful is 1. Be the new hotness and solve a problem in the
| programming space 2. Gain traction and users 3. Release version
| 1.0, become bound by decisions that might haunt you for the rest
| of the programs life 4. Accumulate features, bloat and warts 5.
| Have people complain about warts that you can't fix due to
| breaking changes 6. A new language develops that fixes your
| warts. 7. Repeat
|
| It seems like the cognitive load from "upgrading" a language as
| opposed to learning an entirely new language from scratch (even
| if it fixes a lot of your gripes) would be a lot easier.
|
| Having been playing around with Rust for a bit, I've seen the
| conversation come up about warts in Rust, and I think people fear
| if it will eventually become another C++. I think the answer is
| probably yes, if it endures for a similar amount of time that C++
| did
| simias wrote:
| I don't think Python and C++ are really comparable here. Python
| was meant to be fairly minimalist from the start. I think if
| Python "feature froze" right now it'd still remain relevant for
| a long time. As you mention for its core use case you could
| argue that it's feature-complete already.
|
| C++ on the other hand was never small. It was never an
| objective. C++ started as C with classes so it was really just
| a way to have proper OOP in C. Then it grew and grew and grew,
| adding more paradigms along the way.
|
| C++ is in a relatively tough spot because it has to maintain
| backward compatibility all the way back to C89 while at the
| same time attempt to stay relevant when pitted against Rust,
| Zig, D and friends. You can't simplify anything because you'd
| lose backcompat and if you just feature freeze you're doomed to
| become irrelevant in the not-so-far future.
|
| Unlike Python you can't really argue that C++ as it is now is
| feature complete. Dependency management is still a nightmare
| (as is the entire build system really, given that you don't
| have any standard C++ build system). Concepts are also a great
| addition to the language IMO that I've been missing for as long
| as I've used the language.
|
| Coroutines are also fast becoming a standard tool for system
| programming (for better or worse, but that's a different
| discussion), and C++'s support in the standard is still
| experimental.
| frakt0x90 wrote:
| I don't think that's true at all for Python. It's explicitly
| created as a "batteries included" language with a very large
| standard library. This is a quote from PEP 206:
|
| "The Python source distribution has long maintained the
| philosophy of "batteries included" -- having a rich and
| versatile standard library which is immediately available,
| without making the user download separate packages."
| pjmlp wrote:
| Except Python is quite huge as well, and introduces breaking
| changes even across minor versions, people think it is
| simple, but that is actually quite deceiving.
| tsimionescu wrote:
| > C++ is in a relatively tough spot because it has to
| maintain backward compatibility all the way back to C89
|
| C++ does not maintain backwards compatibility with any
| version of C. Almost any relatively large idiomatic C program
| will fail when compiled as C++ for a few simple differences
| (most commonly, in C it is idiomatic to write `int *c =
| malloc(sizeof(int))`, while this is a type error in C++).
| secondcoming wrote:
| New features get added to C++ only when people vote for them. I
| believe _anyone_ gets to cast a vote. You have to write a paper
| that explains the rationale for your idea.
|
| So, features get added because they're considered good ideas.
| ijidak wrote:
| I fear this is the road C# is on.
| jcelerier wrote:
| > In my naive opinion, It seems to me that both C++ and Python
| have reached a point where most people are satisfied with the
| features the language has.
|
| most definitely not. C++ still doesn't have reflection ffs,
| which I am reminded every time I have to type the name of an
| enum or class twice
| spacechild1 wrote:
| Reflection is also one of the things I miss the most.
| Gibbon1 wrote:
| Idle question, if you could toss everything added to C++ in
| the last 20 years in return reflection would that be worth
| it?
| SubjectToChange wrote:
| >My question is why the need to keep adding features? Sure if
| something comes out that C++ is desperately lacking, add it in.
| But it seems like that hasn't been the case for a while.
|
| C++20 does address legitimate pain points of the language. -
| Modules alone can cut 30% off compile times, as well as solving
| some other corner cases. - Coroutines will make writing network
| code easier. - constinit and consteval greatly simplifies the
| horrible TMP hacks C++ programmers are _already using_. - The
| spaceship operator removes a lot of boilerplate when defining
| comparison operators. - Library additions like <format>,
| <bit>, <numbers>, std::jthread, etc, standardize widely used
| operations and libraries.
|
| In contrast, it seems like most of the language features
| proposed for Python are to "keep up" with other languages, e.g.
| the pattern matching proposal. It's made even worse in Python's
| case because it has historically been sold as a simple and easy
| to understand language.
|
| >I think the answer is probably yes, if it endures for a
| similar amount of time that C++ did
|
| Maybe. But Rust is in a much better position to avoid C++ style
| complexity. Editions allow Rust to "clean up" the language
| without breaking existing code (C++ is trying to do the same
| with Epochs). And Rust doesn't try to maintain broad
| compatibility with another language like C++ does with C89.
| Other features, like powerful macro definition facilities, also
| help offload language features to libraries. And most of all,
| Rust can learn from the mistakes of C++, e.g. destructive moves
| are definitely the way to go.
|
| Anyway, it does seem like programming languages are either
| destined to ossify, like C, or sprawl out of control, like C++.
| Although, this problem can be largely avoided if the language
| lets code leverage the compiler, such as Lisp macros.
| fpoling wrote:
| Modules in theory for big source trees with a lot of small
| files and long include lists can reduce compilation time by
| factor of 5 as that time is dominated by repeated parsing of
| headers.
| pjmlp wrote:
| I still don't buy into epochs at the industrial scale
| languages like C and C++ are used today.
|
| It relies on using the same compiler for the whole project,
| no use of binary libraries, or language semantic changes, for
| the whole idea of mixing epochs to work out.
| tene wrote:
| It happens to be the case today that Rust doesn't support
| binary libraries build by different compiler versions, but
| I don't see any way that editions could interfere with
| this.
|
| Editions only include changes that are crate-local, and
| crates using different editions must always be
| interoperable. For example, the module system path changes
| in Rust 2018 change how you organize code within a crate,
| but there's no way for any user of the crate to possibly
| know or care about this. Rust 2018 adds the ? operator, but
| again there's no way for users of the crate to know or care
| about whether code in your crate uses ? or not.
|
| Am I misunderstanding you, or could you share more details
| of how crates specifying different editions could rely on
| them all using the same compiler?
|
| Are there any changes in the 2018 edition, or planned for
| the next edition, that would interfere with using different
| compilers, or binary libraries? What's a possible change
| that you imagine could be introduced as part of a Rust
| edition that would cause interoperability problems here?
| qalmakka wrote:
| The main issue I have with C++ is that you basically have to
| relearn it from scratch every time a standard comes out. C++11
| threw away decades of best practices, and C++17 again changed
| so many things it's hard to keep track of them (for instance,
| stuff like `string_view` has had a _huge_ impact on how I write
| code and how I reason about strings, making `const char *`
| almost disappear from some of my codebases).
|
| C++20 with concepts and ranges will revolutionise everything,
| again, because those features are so big and pervasive they
| make lots of patterns and "older" parts f the language suddenly
| feel like "legacy". For instance, I see concepts vastly
| reducing the need for inheritance in lots of cases, massively
| simplifying what lots of folks like me were already doing with
| SFINAE and templates.
| tsimionescu wrote:
| As far as I understand, that is the whole point of many of
| these changes: there are patterns that people have to bend
| their code into and unsafe constructs that need to be used
| with care, and the newer standards seek to replace patterns
| with language features (e.g. concepts more or less instead of
| SFINAE), or bring safe alternatives to the previously
| necessary unsafe ones (string_view instead of `char*`).
|
| Now, the major concerns that some have is that this will not
| be successful, and that instead of replacing X with Y, you'll
| be left with both X and Y in the language as still necessary
| constructs for new code, making the language ever more
| complicated even if you can disregard the legacy.
|
| C++ already suffers somewhat from the strong ties between
| many of its features (for example, many people would like to
| use C++ without exceptions, but then you can't use `new` or
| constructors that can fail, and without constructors you
| can't use RAII, and so on).
| qalmakka wrote:
| Yes, that's definitely a possibility, but I think most of
| the time when two patterns keep existing, instead of a new
| one just replacing the old one, is most of the time due to
| people refusing to change the ways they write code.
|
| For instance, `new` is basically nothing short of obsolete
| in modern C++, unless when used in "placement new". There
| are legally 0 reasons for ever writing `new T`, unless you
| are implementing `std::make_unique()` in the STL. Disabling
| exceptions is also IMHO a very poor choice - first, because
| there is no valid performance reason to do so, and second
| because it basically cripples half of the STL (and lots of
| other libraries). Using it becomes then tricky to use
| safely, because basically everything might just call std::
| terminate () anywhere without any formal specification, or
| without being declared `noexcept`, by just changing
| compiler options.
|
| C++ exceptions, when used sparingly and for, well,
| exceptional events, are not as bad as people think they
| are. What's very unfortunate is that they got a very bad
| rap in the 90s, and then countless developers have been
| mislead by Java's unfortunate design choices, so they often
| fail to understand that handling failures should always
| considered part of the ordinary code path, and not treated
| as exceptional at all.
|
| I personally use exceptions as if they are a lighter
| version of assert, like `panic` from Rust or Go, in order
| to indicate that some basic code assumption has been
| violated, and thus executing a certain action is no longer
| possible (like, some parameter is malformed and you
| specifically asserted it's not, and such). Using them to
| represent normal runtime failures, such as IO errors, is
| sloppy design, and it's something that is much better
| accomplished by returning error values (which might also
| consist in enum classes or an error struct).
| spacechild1 wrote:
| Just FYI
|
| > but then you can't use `new`
|
| You can certainly use new without exceptions, see
| https://en.cppreference.com/w/cpp/memory/new/nothrow or
| https://stackoverflow.com/a/15292148
|
| > and without constructors you can't use RAII, and so on).
|
| I think RAII is more about _destructors_ (which must never
| throw exceptions). You can certainly write RAII style
| without throwing constructors. Generally, exceptions depend
| on RAII, but not the other way round.
| tsimionescu wrote:
| > You can certainly use new without exceptions, see
| https://en.cppreference.com/w/cpp/memory/new/nothrow or
| https://stackoverflow.com/a/15292148
|
| You can use new without exceptions, but you can't detect
| OOM then, if I'm not mistaken.
|
| > I think RAII is more about destructors (which must
| never throw exceptions). You can certainly write RAII
| style without throwing constructors. Generally,
| exceptions depend on RAII, but not the other way round.
|
| The whole idea of RAiI is that you Acquire a Resource in
| the constructor (during Initialization), so that the
| destructor can guarantee it gets de-allocated.
|
| If you construct your object and then acquire a resource
| in it later, from a function that can return an error
| without throwing, then you introduce complexity in the
| destructor and may risk errors more.
| qalmakka wrote:
| > You can use new without exceptions, but you can't
| detect OOM then, if I'm not mistaken.
|
| AFAIK `new (std::nothrow) T` returns nullptr if
| allocation fails, like std::malloc.
| nsajko wrote:
| > people wish could be fixed (but can't due to backwards
| compatibility)
|
| This is actually not completely true. The only example I can
| think of right now is how C++20 deprecated some uses of
| volatile, but the standards definitely do deprecate features
| and break backwards compatibility. This is done with care, only
| when it makes sense. The standards and individual
| papers/proposals are public, so feel free to take a look, they
| include rationales in such cases.
|
| > My question is why the need to keep adding features? Sure if
| something comes out that C++ is desperately lacking, add it in.
|
| Well, that already is how it works. Just because you don't know
| about some change doesn't mean it wasn't worthwhile.
|
| There are often some complaints regarding the standardization
| process itself though, I think that, e.g., the coroutines
| proposals situation with the multiple competing proposals was
| pretty controversial. But that's just how it is with C, C++
| (and Ada, Pascal, Basic, ...). It seems like the days of ISO
| reigning over programming languages are over though, in that
| newer programming languages aren't given over to ISO.
| ilkkao wrote:
| I don't know what the situation is with the C++ development.
| But in general, based on my experience on standardization work,
| it's really hard to stop a committee from inventing new
| features when the members get paid to participate and make an
| impact. Maybe exaggerated but sometimes I got the feeling that
| some proposal existed only so that the presenter was able to
| justify a week in a nice meeting location like Hawaii.
| 2iP1zbR wrote:
| > it's really hard to stop a committee from inventing new
| features when the members get paid to participate and make an
| impact.
|
| This could also explain most awful, unnecessary GUI updates,
| unprovoked by any customers, throughout software.
| chubot wrote:
| Lots of answers to this, but
|
| (1) Computing is growing as a whole. What was good enough in
| 1980 isn't good enough now. Computing is used for more
| problems, and by more people. Programs are bigger, so there is
| pressure toward compressing common code and idioms. Hardware is
| more capable and more complex: it's more heterogeneous,
| dynamic, has more sensors, etc.
|
| (2) Different problems have different use cases. Your "wart and
| bloat" is another person's feature, and vice versa.
|
| Multi-core, multithreading and GPU are major reasons that
| features have been added to C++, and those were less of a
| concern in 1980 when C++ was conceived. (especially GPU).
|
| The "cycle" you lay out isn't accurate because languages in
| fact do make progress. We're not going around in a circle. Rust
| fixes a lot of things wrong with C and C++; Go and Swift are
| also improvements, etc. (I don't even use those languages, but
| I can recognize the improvements as someone who's been using C
| and C++ for a long time).
|
| I recommend writing some C from scratch to get a feel for this.
| I do this on occcasion, because there are advantages. But you
| will also be extremely hard pressed to do anything that's
| interesting for a user. The gap to bridge is very large.
|
| For example, try writing a web app in C (not for production).
| You can save a lot of code by using CGI, but even then it's not
| fun. (It IS still done; look at the source code to the modern
| cgit UI if interested.)
|
| Also try to modify and understand source code from the 90's
| like GNU bash or CPython. (Interestingly, there is a pretty big
| difference between the codebases, despite being from similar
| eras.) Nonetheless it should be clear from that experience that
| we've made progress.
|
| The progress isn't perfect, but freezing languages in time
| isn't a reasonable option, given the massive change in the
| problems being solved, and the environment.
___________________________________________________________________
(page generated 2021-04-27 23:02 UTC)