The Rust Megathread

[Raymund Hofmann]

Code: [Select]

  std::string a = "a";
  std::string_view b = a + "b\n";
  std::cout << b;

Looks like "clang experimental -Wlifetime" in compiler explorer gives a warning about this.

https://godbolt.org/z/zK4HVx

But not very glorious that GCC 9.1 doesn't. Maybe the newest MSVC also catches this with it's static analyzer or warnings.

If the argument for not using C++ is the deficiency of tooling that seems to be fixed rather soon even for the freely available tools or is fixed already for people using commercial static analyzers, it sounds rather compulsive.

Some more information here:

https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/

[bd139]

I prefer to recommend C# these days.

This is a electronics forum, about mostly embedded systems.
Who in his right mind will use a garbage language, meaning a automatic garbage collected only, indeterministic, factually vendor proprietary language and eco-system there?

Possibly only someone who can't handle a gun, always shoots himself in the foot and thus wants to ban all guns.

Lots of embedded applications don't have a real time requirement. As far back as 2004 I've been deploying C# on windows CE in embedded systems. This spans everything from mobile vehicle tracking systems to aircraft. In a lot of cases the application's "embedded" portion is a tiny piece of the picture and most of the application is actually on traditional compute. Hell if you look at a lot of embedded use cases, some of them are even desktop windows builds...



Some points:

1. As for the underlying C# platform (.net), you realise it's open source and supports AOT compilation?
2. As for the platform, you also realise it doesn't matter if it's open source or not? Same as everyone just buys Keil etc. What matters is applicability to the problem domain within the budgetary constraints.

For hard real-time applications you're right. I used Ada on PowerPC when I did that. Note, also not C++ and not C because why the hell would you use that?!?! We used formally verified compilers and formally verified code for those applications, most of which ended with a large boom.

My personal preference for hard real time applications is FORTH and native assembly for ref. I write C for the AVR now for personal interest because it's the path of least resistance and it's cheap as chips and there is precisely zero risk of anything I do causing harm to anyone. I won't touch the Arduino toolchain because of the tangled bastardised C++ nightmare that sits over it. Just managing interrupts and library opinions is a chore.

The "bad boys" will always keep their guns.

Put your gun away. We're not shooting anyone

And about your string_view example, the language allows you to do optimizations crucial in embedded or systems programming that simply aren't possible in less deterministic managed languages, and it's misuse can be detected by tools, either if it happens by accident, incompetence or even intentional like in your example.

I think you miss the point. The point is that this was intentional on my part, because I understand the problem domain. The majority of people do NOT understand the problem domain even people with 20+ years of "embedded experience" so determining intent is difficult from what is presented to you. If there was that much determinism there wouldn't be stuff like http://www.underhanded-c.org/ . With power comes responsibility and most people are too arrogant to handle that responsibility, something I observe here regularly.

The comparison with C# above was strictly to illustrate how many of the problems evaporate if you pick the right tool for the job

Edit: Incidentally the static analysers I have here (Coverity and Sonar) didn't actually pick this use after free up. Valgrind didn't either.

Optimisation, fair enough. I don't argue that. We sometimes have hardware constraints which need to be managed but at no point would I consider even throwing a C++ compiler in that direction. Just the abstractions it forces on you are too large for the hardware. C is about as close to the metal as you can go. It's basically a high level assembler there. The C++ abstractions are just way too high level to even throw anywhere near embedded stuff at that level.

And possibly there are people that want to do bloated toy embedded systems with managed languages, because the alternative is too difficult for them, but i suspect they don't earn much because the customer tends to buy what bangs most for his buck.

The customer spends what the customer wants and that is barely related to what comes out the other end. I actually know someone who's entire business is based on the Parallax Basic Stamp and he does very well and his products work fine. He knows his limits and what the risks are if he migrates everything to C so made a sound engineering decision to buy something in to make that risk go away.

As for money, I make it solving problems, not picking political sides in a battle of engineering requirements. The customer doesn't always care how they are solved. I have to compromise somewhere which means picking technology that won't fail both myself (thus incurring maintenance costs and decline in profit) or the customer (thus incurring wrath).

You see it with something like the Raspberry PI, or Adruino, for example.

The money there is made by selling people something that makes them feel they are a "maker", but what they "design" hardly makes any money by selling it, but of course he may tell others how great it is and increases sales of the "maker" supplies.

I'll avoid getting into the "maker" discussion here but that's just a marketing fad, a hashtag to shove on any old shit to try and sell it.

If we stick to the commercial side of this there is a market for high level languages in embedded systems and yes it is because they are easier but this is because it reduces time to market and risk profile for what you are doing.

C++ is a joke for everything. It doesn't fit anywhere. It only exists simply because of momentum. On the desktop it's dying on it's arse; people are rewriting shit in JavaScript and Electron and other high level languages. No one wants to deal with ATL/MFC/Qt any more. Apple are even walking away from Objective-C now and implementing their own higher level language. Mozilla are heading to Rust. On the embedded side of things, C++ has as much non determinism as on the desktop. C is marginally better but at the same time, it's a mess of non-determinism as well. Even the basic ANSI C specification has more unknowns than knowns in it.

Now my day job these days, past that history of embedded work at various levels, mostly consists of attempting to prevent large financial companies from doing stupid stupid things and giving them sound architectural advice. I've learned a lot over the years from C and C++ and that is basically summarised as:

If you want to spend money maintaining shit with a high failure and security risk, pick C or C++.

Now back to the Ad Hominem side of things, now we're done with the technical evaluation. Honestly I've worked with people with your general attitude of superiority and arrogance and fired them sharpish!

Code: [Select]

  std::string a = "a";
  std::string_view b = a + "b\n";
  std::cout << b;

Looks like "clang experimental -Wlifetime" in compiler explorer gives a warning about this.

https://godbolt.org/z/zK4HVx

But not very glorious that GCC 9.1 doesn't. Maybe the newest MSVC also catches this with it's static analyzer or warnings.

If the argument for not using C++ is the deficiency of tooling that seems to be fixed rather soon even for the freely available tools or is fixed already for people using commercial static analyzers, it sounds rather compulsive.

Some more information here:

https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/

This covers my point nicely:

1. GCC doesn't. MSVC maybe. clang does. Non-determinism.
2. clang experimental warn feature flags this. Experimental.
3. I am not harry potter and don't wish to have to shout "Expelliarmus!" every time I accidentally load up the foot gun.

The deficiency is not the tool chain but the language design and specification and the crack in the pipe that was smoked by Stroustrop.

[magic]

Correct. It's a use after free 

So easy to fire a footgun it's unreal.

Same thing in C#


  var a = "a";
  var b = a + "b\n";
  Console.WriteLine(b);


Literally no concern.[

Now let's try same thing in C++

Code: [Select]

string a = "a";
string b = a + "b\n";
cout << b;You are just trying hard to create buggy code by using some obscure nonsense nobody normally uses. I had to look up what a string_view is.

Compiler assumes programmer is a dumbass

No comment here

[bd139]

string_view is in <string>. Someone will use it even if you tell them not to. And it will escape through code review. And it will escape through specifications because humans are responsible for enforcing all of them.

Lets throw unicode in. std::string doesn't cut it. std::wstring has portability issues.  std:u16string and std:u32string have BOM interpretation issues in different STL implementations. std::u8string isn't coming until C++20...

I know that because I wasted a whole fucking day of my life on that shit.

It's also the sort of issue that causes my enjoyment of Последний Герой on my Citroen's embedded radio to decline as the track title is empty. So this is necessary, in 2019, in embedded systems.

I'm not wrong and a massive chunk of the industry happens to be on the same side of the fence. The whole thing is a poorly specified and engineered mess.

[magic]

I worked on a moderately complex, multithreaded C++ project for a few years. I just don't remember segfaults and concurrency bugs as a serious issue. And code review was effective at keeping the dumbasses from comitting obvious crap

C++ is a crude mess, I don't think anyone denies it. But there are things you can do in a language with pointers and a Turing-complete metaprogramming system that you simply couldn't do equally easily and/or with the same performance in a safe, statically verified langugage, precisely because it's safe and boring.

I acknowledge most people would be better off programming in Java; in fact, I always say that people should only touch C++ if they plan to use it for hours a day and for years. At the same time, I think the world would be better if less people programmed computers, not more.

You can rave about the superiority of JavaScript and Rust to C all you want, but at the end of the day, all that Web 2.0 garbage is sluggish and buggy like Windows 3.1 era desktop software written in C running on i386. Or worse. Why? Because it allows idiots with no clue about computers to make software

I understand that this battle is mostly lost. It's always cheaper to hire code monkeys writing in some BDSM language and tell the customer to buy a faster CPU. I will have a laugh if Moore Law hits the wall within my lifetime, though

[bd139]

If you think I'm a fan of all that web 2.0 garbage you'd be wrong.

Back in the late 1980s and early 1990s I used Acorn RISC OS machines. They were pretty powerful ARM beasts, in fact where the ARM CPU originated. They had a well defined low-high level abstraction which meant you could write the majority of what you did in an HLL (BASIC in fact) and drop to assembler as needed. I think we need something in that space again. I'm certainly not suggesting BASIC today, but something in that space.

Really I'd like to see a stepped platform abstraction based on the same, well defined language. This is possible but means a lot of starting again and no traction which is why other attempts have failed. The abstraction should be as follows:

1. Low level (core/embedded/kernel). native memory access. Inline assembly. No libraries other than static data structures.
2. Mid level (systems/network programming). No memory access outside allocator (reference management or GC). Higher level data structures and libraries. Network access.
3. High level (end user). No memory access outside allocator (with GC). No inline assembly. Higher level data structures and libraries still and user interface

Something along the lines of Algol / Oberon would be the sweet spot between functional and usable. Go is actually closest to the mark believe it or not.

FORTH actually covers all of them as well. You can redefine some of the words on lower level abstractions at startup to stop hardware access.

[Raymund Hofmann]

Lots of embedded applications don't have a real time requirement. As far back as 2004 I've been deploying C# on windows CE in embedded systems. This spans everything from mobile vehicle tracking systems to aircraft. In a lot of cases the application's "embedded" portion is a tiny piece of the picture and most of the application is actually on traditional compute. Hell if you look at a lot of embedded use cases, some of them are even desktop windows builds...

These Windows powered Tektronix devices were dreadful, luckily these ar history.

All embedded systems have real time requirements, you ignore that by simply talking only about the UI part. And even there, you have users only accepting non determinism to some degree.

And it looks like this UI part is transitioning into the browser and done in JavaScript or maybe even C++ compiled to WASM running in the browser in the future.

It makes sense, you can get so many "web hipsters" competing for a job to give you a cool UI with a corn flower blue button. They really shouldn't be punished with C++, though.

Who cares about the language here, it is a war of UI platforms/toolkits and the end of the vendor specific platforms is dawning.

Some points:

1. As for the underlying C# platform (.net), you realise it's open source and supports AOT compilation?

Didn't i say "factually"?
It is a more symbolic act to to prolong the life of C# and it's eco-system, to extract the most business out of the C# community.
Fair, but hell i never would want to be forced to annoy myself doing real embedded work with C# or any other managed garbage collected language.

For new things i would rather go the browser approach, meaning put the UI in the browser, interface this to the C++ real embedded part.
Other people see this as a threat, so we got Blazor.

The "bad boys" will always keep their guns.

Put your gun away. We're not shooting anyone

You need help understanding my analogies?

...

C++ is a joke for everything. It doesn't fit anywhere.

...

If you want to spend money maintaining shit with a high failure and security risk, pick C or C++.

Do you realize that without C++, there would be no internet, no browsers, no infrastructure, no mobile phone networks, no factory automation?

Ok, some defense done with ADA would be left so we could fight a war then because the infrastructure is gone.

This covers my point nicely:

1. GCC doesn't. MSVC maybe. clang does. Non-determinism.

You really slander the meaning of the word "determinism" here.

It is easily known from the beginning, easy to determine if you get the check or not, so you can act appropriately simply by telling the not that capable programmers to avoid std::string_view and other things that require high responsibility and proficiency or restrict them to their managed language sandbox because it works better for them to do the corn flower blue button UI.

2. clang experimental warn feature flags this. Experimental.

It already works, soon it will not be experimental anymore, it will also be in GCC and it is free and open source.
But i guess you want to turn it into a original sin.

3. I am not harry potter and don't wish to have to shout "Expelliarmus!" every time I accidentally load up the foot gun.

Sounds like you have a very superstitious approach to engineering.

The deficiency is not the tool chain but the language design and specification and the crack in the pipe that was smoked by Stroustrop.

A nice ad hominem.
He possibly gets a lot of that and counters: There are two kind of programming languages, ones that everyone complains about and the ones nobody is using.

[bd139]

Do you realize that without C++, there would be no internet, no browsers, no infrastructure, no mobile phone networks, no factory automation?

First web browser: objective C
First web server: C
Operating systems of the era: C (not C++). Even the "C++" that NT was written in was C. It only got C++ from ATL/MFC and above. Win32 was C!
What infrastructure? It's all C.
Mobile phone networks? Plenty of Erlang there and kernels from the above. AT&T's telecoms products were built on C and UNIX.
Factory automation? I spent several years doing automation and touched C precisely zero times. It was surprisingly perhaps all VB4 on NT 3.51 talking to things on RS422/GPIB stuff that ran ladder logic or some other vile proprietary shit. We even had some SBCL in there. That was nice.

Most of the Internet to this day runs on C and ASICs and SFA else.

Now C sucks for different reasons but the scope is tiny and we'd have been fine without C++. We'd be a LOT further along without C++. It's one of those mistakes the human race hasn't quite got over yet like smoking, putting lead in gas and bagpipes.

A nice ad hominem.
He possibly gets a lot of that and counters: There are two kind of programming languages, ones that everyone complains about and the ones nobody is using.

C++ job trends ...



I look forward to watching him eat those words for supper.

[tggzzz]

If the argument for not using C++ is the deficiency of tooling that seems to be fixed rather soon even for the freely available tools or is fixed already for people using commercial static analyzers, it sounds rather compulsive.

The problem with that is that the c++ mob have been claiming that for the past quarter century. Many people have drawn the comparison with fusion power

The tools are still nowhere as good as tools for Java in 1996 or Smalltalk in 1985. BTW both HP and Tektronix have had very good portable instrument products based on Smaltalk, so don't recommit your "this is an embedded forum" mistakes.

There are fundamental reasons why the tools can never be as good. Start by considering the effects of #define macros, and the ability to cast a fish into bicycle. After you have not solved those, you  can move onto more subtle problem.

BTW, you really should listen to bd139;  his points are valid. But somehow I doubt you will.

I should note that he has more patience than me in clearing up other people's messes. I have done it, but prefer to be less well financially rewarded by merely cleaning up my own mistakes

[bd139]

Also worth a read before you consider C++ appropriate for low level stuff...

https://web.archive.org/web/20140111204548/http://msdn.microsoft.com/en-us/windows/hardware/gg487420.aspx

An oldie but a goodie and it smells of architectural regret.

[tggzzz]

Something along the lines of Algol / Oberon would be the sweet spot between functional and usable. Go is actually closest to the mark believe it or not.

FORTH actually covers all of them as well. You can redefine some of the words on lower level abstractions at startup to stop hardware access.

The key usecases for the future will be around many core processors with many threads and non-uniformly memory architectures, with networking thrown in for good measure.

C et al spent 40 years explicitly avoiding those issues. Maybe the new standards will help, but that won't be proven for a decade. And I'll bet the promise will be negated by legacy code and normal programmers.

I don't see how Algol (of fond memory) helps there,  and I don't know Oberon. Erlang has a strong commercial track record. For the embedded commercial arena, I like the modern incarnation of CSP and Occam, i.e. xC

[Raymund Hofmann]

C++ is a crude mess, I don't think anyone denies it.

Frankly, i also thought C++98 did more harm than good as many overeager "programmers" have ridden it close to death.
Maybe also the Java shock helped C++98 to become a zombie.

But the Java shock, which was countered with C#, was followed 10 years later by the disillusion about Moores law, there is no free lunch anymore.

http://www.gotw.ca/publications/concurrency-ddj.htm

And it got worse, even the wonder battery that is supposed to save BEVs is draining too quickly in our mobile devices with all the Java, JavaScript and managed, non AOT languages. And you never can have too much RAM and it even needs power to store all this not yet collected garbage data.

This revived interest and work in C++ and i would say with respectable results, possibly extending the life of C++ significantly.

So good news for the haters of C++, probably they will not lose their purpose until the end of their life.

This brings me back to the Rust topic.
It looks like these Rust activists here are motivated by hate for C++ to a unhealthy degree.
It is just because like i said, C++ is a mess, but not such a mess that abandnoning it is worth it or generally mandatory, esp. as it is continuously improving including tooling.

And then i think even Firefox, which i am using as a web browser, while preferring chromium for dedicated apps, is not 100% Rust, there are definitely C++ libraries used and then maybe extensions done in C++.

One should view the dogma of Rust superiority by their activists with this in mind.

Oh, i found something:

https://github.com/4e6/firefox-lang-stats/blob/63912019312ac0b25701092b06fde64bec341f64/git-file-stats.log

...
217 rst
...
3299 c
...
7170 cpp
...

Interesting would be also to know the trend here.

I suspect Rust seriously lags behind in the ambitions of it's activists and then C++11,17,20 is making so much bad news that they see themselves forced to step their hate up.

[bd139]

Something along the lines of Algol / Oberon would be the sweet spot between functional and usable. Go is actually closest to the mark believe it or not.

FORTH actually covers all of them as well. You can redefine some of the words on lower level abstractions at startup to stop hardware access.

The key usecases for the future will be around many core processors with many threads and non-uniformly memory architectures, with networking thrown in for good measure.

C et al spent 40 years explicitly avoiding those issues. Maybe the new standards will help, but that won't be proven for a decade. And I'll bet the promise will be negated by legacy code and normal programmers.

I don't see how Algol (of fond memory) helps there,  and I don't know Oberon. Erlang has a strong commercial track record. For the embedded commercial arena, I like the modern incarnation of CSP and Occam, i.e. xC

Totally agree.

C-like languages are dead in that space. Everything is too mutable to handle concurrency effectively and scale well. Most of the synchronisation primitives we use are to work around that.

Erlang is a good one for sure. I've got an Erlang stack up here although it mostly runs RabbitMQ spewing stuff between C# and python programs as that's what my usual problem domain desires. Algol 68 - look up "par". The "par" from XC and Haskell came from there

I should note that he has more patience than me in clearing up other people's messes. I have done it, but prefer to be less well financially rewarded by merely cleaning up my own mistakes

Patience comes from knowing you don't have to renew 

[bd139]

It looks like these Rust activists here are motivated by hate for C++ to a unhealthy degree.

Not a Rust activist here for ref.

Incidentally I just spent an hour with Rust and I hate it as much as C++ almost immediately. There's even more intent hiding in punctuation! Starting to look like Perl where every time the cat walks on the keyboard, apart from the dose of toxoplasma gondii, it churns out a valid perl program.

[andersm]

Starting to look like Perl where every time the cat walks on the keyboard, apart from the dose of toxoplasma gondii, it churns out a valid perl program.

This paper was making the rounds early this summer.

Edit: Another link: Programmer migration patterns

[Raymund Hofmann]

Do you realize that without C++, there would be no internet, no browsers, no infrastructure, no mobile phone networks, no factory automation?

Your "firsts" and list of anecdotes all are close to irrelvant, far from being a realistic picture.

A nice ad hominem.
He possibly gets a lot of that and counters: There are two kind of programming languages, ones that everyone complains about and the ones nobody is using.

C++ job trends ...



I look forward to watching him eat those words for supper.

You are so loving.

BTW, these percentages are inflated by the web/JS/Java bubble. The absolute numbers for C++ job trends are rising.

One can even see the that the brave new Java world or however you call it has ended as the percentages seem to stagnate since a few years despite the total number of "programmers" still rising. 
And i think the C++ jobs may be less volatile than some others, of course when you can handle C++, its evolution and don't hate it.

But who needs it rising? It is not for everyone, only for the ones who can efficiently use it.
And then it is making big progress in making programmers more productive, the ones who can handle it, of course.

[bd139]

Starting to look like Perl where every time the cat walks on the keyboard, apart from the dose of toxoplasma gondii, it churns out a valid perl program.

This paper was making the rounds early this summer.

Hahaha hadn't seen that. That's hilarious

But who needs it rising? It is not for everyone, only for the ones who can efficiently use it.
And then it is making big progress in making programmers more productive, the ones who can handle it, of course.

Some of us can handle it but choose only to do so when we're paid danger money. Some people never get to a position where they can make that choice

[Raymund Hofmann]

C-like languages are dead in that space. Everything is too mutable to handle concurrency effectively and scale well. Most of the synchronisation primitives we use are to work around that.

The concurrency problem is not a problem of the language, it is a problem of the programmer.

I rather expect these programmer deficiencies getting eased by compilers and virtual machines like WASM, for example.

Simply because the programmer not only has the burden to implement a effective parallel solution but also to take most available and increasingly diversifying architectures into account.
He is thrown back to basically coding "machine specific parallel assembly", or overly generic and repetitive code which again burdens run time and coding performance, regardless of the used language, one could conclude.

I rather think the generated machine code for virtual machines of the future, maybe running in a browser, has some additional information making mapping of the functions and their data flow to the heterogeneous and diverse user machines viable.

So a productive combination of AOT and JIT, not only have JIT because the bubble paid for it.

[tggzzz]

Starting to look like Perl where every time the cat walks on the keyboard, apart from the dose of toxoplasma gondii, it churns out a valid perl program.

This paper was making the rounds early this summer.

Hahaha hadn't seen that. That's hilarious

But who needs it rising? It is not for everyone, only for the ones who can efficiently use it.
And then it is making big progress in making programmers more productive, the ones who can handle it, of course.

Some of us can handle it but choose only to do so when we're paid danger money. Some people never get to a position where they can make that choice

And then there's the Dunning-Kruger effect.

[tggzzz]

C-like languages are dead in that space. Everything is too mutable to handle concurrency effectively and scale well. Most of the synchronisation primitives we use are to work around that.

The concurrency problem is not a problem of the language, it is a problem of the programmer.

If the language doesn't haver primitives with the necessary semantics, then even the best programmer cannot succeed. Those with Dunning-Jruger syndrome might think they have succeeded, but...

If you build a castle on sand, it doesn't matter how good the builders are.

Until very recently, c didn't have the semantics. It remains to be seen whether the semantics are sufficient, and whether they are implemented correctly.

[bd139]

And then there's the Dunning-Kruger effect.

My entire business runs on pretending that doesn't exist

[Karel]

Interesting thread, I subscribed to it. Some comments acknowledge what I experienced.
After reading all this, it convinced me even more to stick with plain C for MCU's.

[Raymund Hofmann]

C-like languages are dead in that space. Everything is too mutable to handle concurrency effectively and scale well. Most of the synchronisation primitives we use are to work around that.

The concurrency problem is not a problem of the language, it is a problem of the programmer.

If the language doesn't haver primitives with the necessary semantics, then even the best programmer cannot succeed. Those with Dunning-Jruger syndrome might think they have succeeded, but...

If you build a castle on sand, it doesn't matter how good the builders are.

Until very recently, c didn't have the semantics. It remains to be seen whether the semantics are sufficient, and whether they are implemented correctly.

Looks like you just read the first sentence and it was sufficient to trigger your denial. Isn't that what Dunning Kruger described?

My point was that burdening the programmer with more primitives and semantics probably will not work, because if it would, it could have worked since more than 20 years and we wouldn't wait for anything to compute while 7/8 cores and 2 GPUs are idling.

[Raymund Hofmann]

Interesting thread, I subscribed to it. Some comments acknowledge what I experienced.
After reading all this, it convinced me even more to stick with plain C for MCU's.

Shouldn't you use Rust according to how this thread started?

You also can have a look there:
https://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems

Looks like it didn't kill all people who did use some C++ while being very careful about certain of it's features and constructs.
No, it rather benefited them.

[SiliconWizard]

string_view is in <string>. Someone will use it even if you tell them not to. And it will escape through code review. And it will escape through specifications because humans are responsible for enforcing all of them.

Yep. string_view appeared in C++17 if I'm not mistaken. This is still relatively new (and explains probably why GCC doesn't catch the problem).
I agree with you, the spirit of C++ itself makes it a heavily fragmented language (meaning almost every developer will use their own subset).

In your example, using too recent features can be easily avoided in your team by using a rule of NOT writing C++17 code. As I reckon, many teams still don't even use C+11... this is relatively easy to enforce if you use automated build systems. Just enable the C++ standard you wish to support. Any feature not supported will not compile (for GCC 8.x, I had to explicitely set std=c++17 in order for your piece of code to compile, otherwise GCC gave a message about not supporting string_view).

But yeah C++ is really a gigantic mess.
Still, to play devil's advocate here, your example could use a user-defined class instead of the standard string_view, and lead to a similar bug. So this is not completely a problem related to the language itself.