Last night, I decided to "practice" writing iterators. Specifically, I wanted to write a class that i could use in a new-style C++ range loop that would give me all files in a directory. Useless but fun practice, I thought.

I had Bjarne's latest book by my side, and the final draft of the C++17 spec in open in a PDF, and it took me a good 2-3 hours of trying before I "got" it.

I'm still not sure I'm doing it correctly, btw. It does compile without warnings, and it works, but I can tweak the iterator function signatures in seemingly incompatible ways and it still doesn't complain and still works, even when I swear it shouldn't. "Ok, surely by doing this I'll break it!" - nope, still works.

I don't love everything about Go, and once in a while I'll wish for more expressiveness, but I was never, ever, as 10% confused with it as I am with whenever I attempt to do something seemingly trivial in C++.

I do agree there's an inherent complexity in the problem domain. It's just that some languages are more helpful than others in dealing with this complexity :)

PS: my own bias: Haskell's seems both easier (in general) and more helpful than C++'s.

Also, since C++ is native, very memory efficient data structures can be written. This property can be leveraged to write very small, very efficient and very resilient loops to be written which can run for months at a time, and since you have the absolute control over memory management, you can prevent unwanted bloating or leaks pretty easily.

Last, but not the least; CPUs weren't that powerful 10-15 years ago. My desktop computer was as fast as the first Raspberry Pi. Python, JS, even Java were very unpleasant experiences back then.

I've never had to go looking to find warts in C++.

Avoiding frameworks and libraries which use unwanted language features and paradigms is very hard. Once these libraries are integrated, it is nearly impossible to restrict a team from using said features elsewhere in the project. Every C++ developer has pet features and features they hate and will never use, but these sets are rarely compatible between developers.

I'd say Rust has a similar level of control. I just rewrote our longest build step (37 minutes on a normal build) in Rust. By having control over when things are allocated I could get it down to about 20 seconds. The previous software is written in Java.

If you want speed you need to choose C, C++ or Rust. If you want it safely, then Rust. I'd argue in my case that Rust was probably the fastest choice. As I probably would have copied more in C/C++. In Rust I can trust that my memory is intact.

I'd also choose C over C++ though. I find it's a much more manageable language. I never found it hard to make the right abstractions in it, except for maybe a lack of generics (which C11 kind of solves for).

C++ is still there, doing what it does best, driving pixels around with maximum performance.

But the upper layer, exposed to app developers and game designers, is done in another language.

Most programmers manipulate characters as if they were ASCII, and that code will break if presented with EBCDIC. The C++ Standard is carefully worded to not assume ASCII encoding.

C++ presumably supports other encodings, but I've never heard of another one that will work. There's RADIX50, but that will never work with C++, for the simple reason that there aren't enough characters in it.

https://en.wikipedia.org/wiki/DEC_Radix-50

You can also see the EBCDIC support in oddities like the digraph support.

As a user of both rust and and C++, I certainly wouldn't consider the the lack of default constructors in rust to be a good thing. Especially for std types like Vec it is really annoying to have to initialize it explicitly.

> The [dcl.init] section of the spec is about 16 pages long and there are about another dozen about how constructors work in the special member functions section.

That is a bad argument if you're comparing to a language that doesnt have a spec. Maybe a complete, exhaustive rust spec would be much longer than the C++ standard?

And rust is going down the same path. Looks like c will reign supreme for shared libraries for the foreseeable future.

Not at all, objects need to be explicitly allocated on heap, otherwise they are value based.

I took care not to list any language that only allows objects as references.

For all its warts, C++ only got adopted inside AT&T and later by almost every C compiler vendor, because it just fitted on their existing toolchains.

Even lack of modules is related to that, C++ object files needed to look just like C ones.

Now that C++ is grown up and can live on its own, it needs to pay for the crazy days of its parties going out with C. :)

State of the art or flavor of the month? For instance, the features from functional programming that C++ and Java recently (in the last decade) added weren't anything new. When functional programming started to become more popular was when their features started showing up in C++ and Java.

If people are concerned that your language is already to large than adding elements from other programming paradigms because they're suddenly what's hot doesn't seem like a great idea. It feels like some languages are chasing the crowd, which can lead to a messy language ("OOP is all the rage now? Our language is all about OOP! Oh, functional is all the rage now? Well, we just nailed on some functional features!").

It's also true that it may not be necessary.

What makes a good language? One that randomly accumulates state of the art ideas about programming without breaking old code, or one that gets out of the way and allows requirements to be expressed reliably and relatively simply?

Of course C++ is used because it's fast. It's fine in limited domains like DSP.

But what is the rationale for a language that whimsically accumulates new features every couple of years, while failing to deal with basic challenges like memory management?

It's not as if it's ever going to reach a critical mass and turn into Haskell.

> Result which is a plain old datatype written in the language, though admittedly it relies on a macro for use

It does not. It relies on a special construct (!) or macro (try!) for convenience, but these are not necessary (a popular alternative is to use the various HoFs instead) and desugar to pretty trivial (if possibly repetitive) code:

    macro_rules! try {
        ($expr:expr) => (match $expr {
            $crate::result::Result::Ok(val) => val,
            $crate::result::Result::Err(err) => {
                return $crate::result::Result::Err($crate::convert::From::from(err))
            }
        })
    }

Object Pascal was created by Apple for Lisa and Mac OS, with collaboration from Niklaus Wirth.

Borland then adopted it to Turbo Pascal 5.5 for MS-DOS.

Turbo Pascal 6.0 and 7.0 for MS-DOS, followed by Turbo Pascal 1.0 and 1.5 for Windows 3.x took up ideas from C++.

Borland then rebooted Turbo Pascal with Delphi, but to avoid creating too much confusion among Pascal developers, they kept calling their dialect Object Pascal, even though they completly rebooted the object model.

This is how you declare objects in Object Pascal.

    type
        PTPoint = ^TPoint;
        TPoint = object
           x: Integer;
           y: Integer;
        end;
        
    var
      valuePointOnGlobalMemory: TPoint;
      valuePointOnTheHeap: PTPoint;

    begin
      {Can use it right away}
      valuePointOnGlobalMemory.x := 10;
      valuePointOnGlobalMemory.y := 20;
      
      {Need to heap allocate first}
      New(valuePointOnTheHeap);
      valuePointOnTheHeap^.x := 10;
      valuePointOnTheHeap^.y := 20;
      Dispose(valuePointOnTheHeap);
      
      {....}
    end.

There isn't "The ONE true OOP way", just like there isn't "The ONE true FP way" or "The ONE true LP way".

Each paradigm has a set of concepts of what they might mean, and many languages cherry pick from there.

Rust and Go implement polymorphism via traits and interfaces respectively.

Rust and Go implement encapsulation via struct methods and modules.

Rust and Go implement containment.

Rust and Go allow for delegation.

Rust allows for type extensions via a mix of generics and traits.

Go allows for struct embedding as a kind of type extension.

Class based inheritance is not a requirement for a language to be OO.

CS literature is full of languages that explored other kinds of OO.

Only if you use every other feature. Don't do that. Use the features you need (and understand well), not every feature. It actually becomes much like you say C is, except that you don't have to write the features.

There's also the case though where the Rust compiler isn't helping you, but is just wrong.

Must of them are going to be fixed by non-lexical lifetimes soon though.

So far it looks like you're ranting.

1. I've "exposed" parts of the private implementation in that they were in the header file, yes. They were also labeled "private". That means that someone can read that and gain more information about my implementation then they could from just public information, I suppose. It also means that nobody can actually use them in code, because they're private. So you can think of that as "exposing" if you want, but it's not something that I've ever recognized as any kind of a problem, let alone one worth solving.

2. If you change only the private parts of the class and try to link other code to it without recompiling the other code, yes, you can get a broken compiled binary. That is certainly true. But I could do that in C almost as easily (if everything that uses the struct layout isn't in the same source file). And makefiles that keep track of dependencies aren't exactly rocket science. Neither are clean builds.

Maybe I just don't have your problems, but I'm still not seeing this as much of an issue at all.

Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.

To be fair, this happens with every language I've been associated with, even C. Just look at those people who do metaprogramming with the C preprocessor. It's madness!

I used to do that too, as a young programmer. It took about 10 years to grind that out of me. One advantage of us older programmers is we show how clever we are by writing amazingly simple and understandable code. :-)

This happens with every language that has a lot of features. You have to try them before you can form an opinion.

It has been a long time since I worked on an application so trivial that parts of it weren't broken out into separate libraries. Most often, those libraries end up being maintained by people other than their users, and the users always end up using the library in unexpected ways or contexts so these protective measures always become necessary.

Perhaps more to the point, I don't think there should even be multiple constructors each called in different situations that it takes several pages to describe. This complexity mostly exists because the people who defined C++ don't seem to understand the significance of value vs. reference semantics, as the OP also noted. Move semantics and rvalue references represent a tacit omission that the previous semantics were broken, but they just introduce even more non-intuitive syntax and another few pages to describe what happens in which situations. That's exactly the kind of spurious complexity that makes compiler writers want to go on killing sprees and folks like me want to avoid the whole morass.

By that criteria, every single statically typed language is "wrong on some level", you'll always find something you want to do/express which a specific language's compiler will not accept. That's not very helpful.

> Sometimes however you do care

I'm not saying people should not care, caring about lexical lifetimes being a pain in the ass is perfectly sensible (there's a reason why non-lexical lifetimes are being implemented after all). I'm saying there's a gulf between "the compiler does not allow X" and "the compiler is wrong", and lexical lifetimes are the former.

Which is just because once you learned how pointers behave. Similarly, if you'd just take the time to learn the basics of rvalues, moving, RVO, ..., you won't be scared by them anymore. Might thake longer than pointers, sure, but it's worth it.

Most compiler bugs are situations where the compiler allows stuff it should not or generates incorrect code.

> "being too limited for what I'm trying to do" also sounds like a bug. So this reads to me as "aside from when they are wrong, compilers are not wrong" ;)

Most every compiler is "too limited" to do some things, that is a big reason why dynamically typed languages are still a thing. For instance I can't tell Java to just take any object with an attribute "foo" despite it being the only thing I want to use (and I don't even care about its type) — bypassing the compiler via reflection aside. Do you think that's a bug in the compiler?

My point is that if you want to be entirely safe from the ABI point of view, modules don't help you at all

Basically subsequent C++ compilers provide the possibility of some subset of C++ which is considered modern. Then files can be marked with it, at which point the C++ compilers reject deprecated idioms. Over time this should take over, I think most of the JS in the wild is now using strict mode.

I can't be the first person to think of this. There must be a reason something like this hasn't gotten traction.

Would be nice to just do a fork and you either pass -std=c11 or -std=c20.

In that sense, you are absolutely right.

However, for simplicity I only thought about the out of the box experience, or by the de-facto implementation of the said languages, since it’s the most popular usage scenario as well.

NGEN

https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...

AOT Compilation for Windows 8.x store apps, based on Singularity's Bartok compiler

https://channel9.msdn.com/Events/Build/2012/3-005

https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an...

AOT Compilation for Windows 10 store apps, using Visual C++ backend

https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

https://docs.microsoft.com/en-us/dotnet/framework/net-native...

~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc.

No template, no virtual functions. Worked very well at that time.

The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the target code.

The classes are shared within company for different machines (biotech robots) to maximize code reuse.

[1] - http://blog.japaric.io/

Here's an article from 1998 that gives an example of C++ being used in military avionics systems:

http://www.cs.wustl.edu/~schmidt/TAO-boeing.html

It's been used in civilian avionics for a long time, too. Not that it's necessarily the best choice in those environments, but "starting to accept" seems like a mischaracterization.

If you're still dealing with an 8051, I'll agree that you're less likely to have moved to C++.

One other thought: Embedded toolchains are typically set at the start of the (original) project. I don't remember ever seeing a compiler upgrade happen in an existing embedded code base. And some embedded code bases live for decades.

Well largely on RaspberryPi kind of platforms, which aren't even even embedded systems. More like miniaturized desktops.

Then there is just C and only C. C dominance there isn't going to be replaced anytime soon, if ever.

The thing with embedded is you have two cases, hard real time and just don't care.

Well then Rust, D, Swift, Go, Rust, Haskell, OCaml are not native by that measure.

C# integration with Win32, COM and UWP (aka COM reborned) is painless comparing with any of them.

I eventually moved into Java/.NET stacks, but still follow on C++, as my to go tool when they need some unmanaged help.

No parallel in C++?!!!??

That is where EJBs and Spring come from.

The enterprise architects that created those kind of designs, were the same ones that on earlier decade were doing them with C++.

Apparently micro-services are now a thing, well on the late 90's we had Sun RPC, CORBA, DCOM. All tied together with a cluster distributed transaction management.

Sprinkled with code generation tools, based either on UML or Booch diagrams.

It was lovely, then came Java with CORBA support out of the box, RMI and GC. So they moved camps.

And yes, I am also to blame for a few CORBA objects, maybe still runing on a couple of HP-UX systems.

I replied a good language shouldn't need boilerplate code automatically inserted.

I'm writing a core service in Go because Java 9 broke a Maven plug-in (that I don't need now). Holy crap is it painful. I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the functions, or use closures that define all of your routes in such a way as to make the db visible.

Even if you get past the difficulty of hiding everything, it's oddly not a good language for web services. The handler interface in mux doesn't allow you to return an error! No error in GO! So you're either going to have a tonne of boilerplate for the routes, or use panic, which by all the reading I've seen is a terrible thing to do. Regardless of which you choice, Go appears to lack the niceties of prebinding the JSON into a struct. Boilerplate. Oh, and you have to do the same to write the JSON out!

Now Java allows for annotations, and types with constructors in the input parameters of the route handler. Spring will inject interface implementations by name or type. All of this and Transactions! It will automatically bind the JSON to the input variable and automatically create the JSON format on the return.

Ever tried to use transactions with Go? You have have to personally keep track of it. Every SQL call has to peg against the transaction because the connection pool won't manage it for you. Also the DB and Transaction structures have the same general interface, but DON'T implement a COMMON INTERFACE! That idea, in 2018, is an experimental feature that MIGHT NOT GET PICKED UP. The maintainers of the standard SQL library said figure it out for yourself.

Really, I don't think that Java brings that much complexity now. It use to. But you can get a new developer up and running in Java within 2 months. It will be better structurally, easily testable, and safer than Go.

Go is like a tricycle. It's simple and it will get you there, but doing anything complex will require a lot of effort. Java is like a 10-speed Schwinn. Fast, moderately complex, but easily understood when kept within the wheelhouse of Spring + Core Language.