Hacker News Reader

Comment by blippage | Hacker News Reader

I used to be excited about learning new languages, but a few years ago I lost interest and decided to consolidate on just one language. That language was C++.

C++ gets you most of the way to Python, which is as high as you can go (cue Smug Lisp Weenies with "muh macros"). So stop futzing around, and just use C++.

All these other plethora of languages are all well and good, and I'm sure they all have their secret sauce, but is their secret sauce tasty enough to justify a switch?

Unless a language consistently allows you to do in 1 line of code what others can do in 10, then there's little point to them.

Having said that, I have recently been poking my nose into Ada for use in microcontrollers. Their notion of "tasks" seemed quite interesting. A version for AVR didn't really seem to be any better than C, just with a different syntax. The one for the Raspberry Pi Pico didn't support tasks, which took a lot off the shine about the prospect of switching to Ada for me. Maybe it's too early days for the Pico, though.

I also had a quick try at Julia, as I was interested in trying out some DSP. There seemed to be some nice features about it. It seemed quite good at arrays. You can read a binary file very easily and convert it to a different type if required. So it is still on my radar.

I use Python for quick-and-dirty stuff.

Nevertheless, C++ is basically unbeatable generally.

View on HN

Exactly my viewpoint!

The industry prevalence, the community size, the installed codebase size, C compatibility, ability to write code at any level of abstraction, etc. makes C++ THE "Industrial Language" to learn.

I keep telling everybody to learn C and C++ irrespective of whatever else they might be forced to study/use since these literally gives them the ability to work at any level in the Software Stack; C is the "universal glue language" and C++ is the all-encompassing monster :-). Bored writing User mode Applications? Jump into writing Libraries/Frameworks/Kernel/Bare-metal code; all using the same familiar language and toolchains. Familiarity trumps everything else. I myself have successfully transitioned from writing Windows desktop apps(16/32-bit) to Network Protocol state machines to Kernel drivers and Bare-metal MCU code all using C/C++.

"Modern C++" (C++11 and later) has shifted the learning goalposts somewhat but nevertheless all the pre-C++11 knowledge is still the bedrock on which to build the new edifices. As a side-note, i completely disagree with people (mainly the "Modern C++" proponents) trying to divorce C++ from its C roots.

Other than C++, the only other language i am willing to spend time on from a professional/industrial pov is Erlang due to its concurrent/distributed/fault-tolerant features.

>I keep telling everybody to learn C and C++ irrespective of whatever else they might be forced to study/use since these literally gives them the ability to work at any level in the Software Stack

I would have agreed with you for many years, but I feel that we might be at an inflection point right now.

For many years, all new languages that got any traction at all were higher level, a bit (or a lot) slower, much more memory hungry than C and C++ and came with a huge runtime of their own.

These languages have largely replaced C++ for application development, but they are clearly less suitable for lower level tasks such as writing operating systems, drivers, ML frameworks, game engines, browsers, graphics libraries, embedded systems and libraries that are supposed to be usable across language runtimes.

But now there's Rust, which fixes a number of C++ weaknesses, comes with more modern infrastructure (such as cargo), and appears to have significant support within some of the largest corporations.

It's still very much an open question how this is going to end, but for the first time in my life as a professional developer (starting in the early 1990s), I wouldn't be surprised if C++ was in very gradual but terminal decline.

C++ hasn't stand still, if you are in Microsoft ecosystem, vcpkg and NuGET take care of cargo, others can make use of cmake and conan.

Then as much I love borrow checker and being safe by default, there are a couple of C++ domains where Rust isn't even a though in 99.9% of the eco-system.

Just consider that Apple has decided to create a C dialect (basically turning all the knobs to be safe by default) instead of Rust for their iBoot firmware.

>I wouldn't be surprised if C++ was in very gradual but terminal decline.

I am quite sceptical that this will ever happen. C and C++ are fated to live together and forever :-)

The "accidental" rise of Web Applications gave a fillip to other languages simply because most of the early programmers were non-CS people. But once these apps hit their limits at scale they had no other option but to fallback to C++. So most often you only have a shim/skeleton app written in some other language whereas the libraries/guts are all written in C++.

Despite the hype around certain newish languages, and their promoters' desperation to denigrate what they see as the competition, C++ usage is still growing very, very fast. In any given week, more people pick up C++ for the first time than have ever heard of the new ones.

Up until the pandemic hit, for several years running, more people attended each ISO C++ Standard meeting (in places as far-flung as Hawaii and Prague) than any previous meeting. Attendance at C++ conferences, and at the same time the total number of C++ conferences, including for smaller and smaller regions, has shot up year after year.

So any perception that C++ use is in decline, or even not exploding, is wholly a product of propaganda. C++ people code while others hype.

The jobs numbers paint a rather different picture, at least here in the UK: https://www.itjobswatch.co.uk/jobs/uk/c++.do

But that‘s not even what I‘m talking about as it merely reflects the fact that C++ has been replaced by higher level languages for development of regular business applications.

What I‘m saying is that now for the first time there is actual momentum behind a language that is a suitable replacement for C++ in its remaining core domains.

And that momentum is driven by serious computer science concerns within large companies rather than by the usual suspects when it comes to hype cycles.

I‘m not predicting C++‘s decline. I‘m merely saying that it would no longer surprise me as there is now both the substance and the momentum to drive such a development.

The top salaries listed on that page are at the very low end of what is available to experienced coders.

I switched to C# after a decade of writing C++. My productivity went up and bug count went down. The main thing I found was when looking at any particular problem I need to spend less of my mental energy reasoning about the language so can spend more on the problem at hand.

Also it seemed no matter how well I learned the language there was always something there to trip me up.

Faster build times help as well (one project went from 10 minutes to less than one whilst increasing the feature count).

I still write some C++ but only if I can't avoid it.

Agreed. C++ passed the complexity threshold (where it's "worth it") for me a while back.

I still use a subset of modern C++ when I'm doing something cross-platform, and Qt helps, but it too often felt I was fighting a war on two fronts (the language, and the problem) when I was trying to keep up. So I gave up trying. And life is a lot happier now.

As a Mac guy, I still think ObjC (yes, I know, you don't like the syntax) was pretty much at the optimal level of complexity and performance. Not as fast as C++ in general, but plenty fast enough for 99% of things. Wonderful standard library with Foundation, and ARC really works well - memory management just isn't a thing I have to think about when I'm using it.

Swift ? Well, now I'm in the "I hate the syntax" camp :) I like my code to look neat (which is easy with C++ and C) and Swift just looks fugly to me.

Having written C++ for 30 years now, which is 75% of my life, I don't disagree from a personal point of view.

However, at one point I was teaching programming at the university. At that point you realize that C++ is .. huge. It may be fine for me, but is it the right choice for someone starting out?

That said I do love new languages personally. I like to study how they do things. I found that Clojure had nearly the exact concurrency model I prefer to use in C++, and much nicer metaprogramming. As a result, I use it for all web stuff these days.

It is PL/I style of huge, however the more time I spend in other ecosystems, they aren't that small either.

I would fail a C++20 pub quizz, but I surely wouldn't fair much better if the questions would be about Java 17, Python 3.9, C# 10, .... including runtimes and standard libraries during their existence.

>"I would fail a C++20 pub quizz"

Same here. It does not preclude creating high quality products though. I learn / fish out of my memory features on on need basis. Due to writing software for the last 40 years I have very good understanding what should be available and where but remember everything in multiple languages in detail is pure insanity. And in my opinion that knowledge is not what defines being good programmer.

The thing I find almost impossible to store in my own memory is which C++ version a feature was added in, so when working on a C++14 codebase, I write class template parameter deduction dependent code and then have to check CPP Reference to see why I was wrong. I agree that memorizing gobs of this stuff isn’t important.

Same here, but also applies to other languages as well, sigh.

I think the main difference is languages like C# don't have the foot guns that C++ does. You can start using them and write reasonable code straight away. I always felt with C++ you need to know a lot before you write your first line of code.

They do actually, like semantics of variables declared in foreach loops, how closures are captured, some of the runtime changes that require appconfig settigs for the old behavior, for example.

I've never used a programming language that is as hostile to programmers who have bugs as C++.

C is worse.

I'm not sure that's true. C's simplicity helps it out here.

Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code.

But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors.

C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop.

I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing.

Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.

C's supposed simplicity is wholly a mirage. "Limited" would be the accurate description.

Everyone's chief exposure to complexity is the code written in the language, where the complexity comes from the problem domain and everything it takes to wrangle that complexity with what the language has to offer. By that measure, C's sharp limits mean that your exposure to complexity is much greater in a C program than in a C++ program.

> Nevertheless, C++ is basically unbeatable generally.

If your only measurement is "how many different distinct features are specified by the language", then, well, yes ... C++ is unbeatable for the number of different ways to do one thing.

If the measurement is instead "how much effort is needed to know enough C++ to move from team to team?", then the outlook is bleak for C++. Because the language itself is so huge, everyone uses a different 80% of it.

C++ is hard to use, because to use any of it, you basically have to know all of it, which is a rather large surface area to cover.

Is there another language that requires as much language-knowledge as C++? I can't think of one.

But the proposed solution to that seems to be "learn more languages", which is not exactly effortless.

I feel some people love learning new languages, while others just want to get shit done. C++ seems geared towards the latter - I don't (always) want to futz around with a new language, ecosystem, and toolchain when I just want to get something out the door. Programming is a tool, not an end for a lot of people.

Exactly. I've been coding C++ for 22 years and feel I know less now then I did back then. The language has grown. But at the same time I feel 10x more productive in it than 20 years ago.

I respectfully disagree. Once you know the core, say 25%, which I've seen devs with 5 years experience in unrelated language pick up basics in a couple of months of full time practice, and then become pretty good at after a year, then switching between teams that use different parts of the remaining 75% is as painless as anything else. I've seen people struggle way more with differences in web development dev envs than c++ and JavaScript is supposed to be simple! (It is but all the rest of the complexity of work comes along for the ride too no matter the language.)

Of course c++ isn't the right tool for every job and as each decade passed there are more languages that do certain tasks better.

Java, C#, F#, Scala, Clojure, Haskell, OCaml, Python, Ruby,... come to mind.

Yes doing "Hello World" is much easier than C++, however when one actually dives into the ecosystem, programing culture and language improvements since they exist, then it isn't that cut clear to keep skills up to date.

Try to move someone stuck in the ways of Java 7 into a team taking full advantage of Java 16, language, runtime features and libraries.

Talking to myself, but ...

I poked around with Logo a couple of years ago. It was invented in 1967. It is a dynamic language, and actually pretty good. I remember thinking that there didn't appear to be any obvious deficiencies in the language.

Dylan is also a powerful language, heavily inspired from Lisp, but "without the toenail clippings." It tried it out, but the compiler seemed a bit flakey at the time, so I didn't pursue it much further.

Then there's Pascal. It's very fast to compile, I think chiefly because, unlike C, syntax isn't context-sensitive. Old Pascal suffered from daftness like strings having to be of pre-defined length. It got me to thinking that this might actually be a strength if you're programming microcontrollers. But anyway, this silly restriction was lifted. Pascal is a language that's very easy to get to grips with. C++ wins out over Pascal for application development because it has resource management, not just pointer management (which pascal doesn't have, either).

There's actually a project called Ultibo, which is a "unikernel" for the Raspberry Pi, written in Pascal. You can compile your own kernel using Lazarus. Getting up to speed was pretty straightforward. To mind it had a fatal flaw, though: it had a pre-emptive scheduler, and thus wasn't particularly useful as an RTOS.

What a lot of this illustrates is that anything that can be invented has been invented. Mostly, anyway. The number of programming languages has exploded over the last decade. What do the do - really do - that hasn't been done before?

Here's an idea ... if you want to create a new language, then take a working Pascal, and add your own ingredients. Its syntax is designed to be easily parseable, so you should have a good basis from which to work.

Object Pascal also has resource managment, specially the later improvements added by Delphi, and RemObjects Pascal.

Ada also has it since Ada 95.

So what would this new Pascal like version bring to the table?

"So what would this new Pascal like version bring to the table? "

The kind of thing I had in mind is for creating Domain Specific Languages - more toy systems than any new earth-shattering paradigm. It's up to the tinkerer. Like, maybe someone wants to add coroutines to the language, for example.

I had one idea in that I'd like to add a nicer way of expressing the parsing of data.

Maybe a Cobol, but nicer. Or a Snobol, but in a more general-purpose language.

Another idea is in the realm of microcontrollers. It could write start-up code for peripherals, and ensure its usage doesn't conflict. I'm not a Rust programmer, but I am aware that it is the kind of problem it addresses.

BUT, the thing about compilers is that a function call is just a function call, it has no idea of intent. By extending the language, you can give the compiler that intent. So certain functions can have compile-time semantics as well as run-time semantics. You could probably achieve the same kind of thing with Lisp.

Anything where one feels the need/desire to extend syntax, basically.

You have been able to use Pascal and Oberon for microcontrollers for years actually.

https://www.mikroe.com/mikropascal

https://www.astrobe.com/default.htm

> All these other plethora of languages are all well and good, and I'm sure they all have their secret sauce, but is their secret sauce tasty enough to justify a switch?

the evidence of all the code not written in C++ and Python suggests the answer is "yes"

I've considered doing this - I spend so much time learning new languages that I am average in many but not an expert in one. However, when I look at what language to pick for that 'one', I can't decide. It's gone from Python -> Common Lisp -> Rust, etc... What are some arguments for C++ to be The One?

C++ has a great reach, from bare metal to very high level of abstraction. It can be squeezed to support almost any paradigm, oop to functional. You can make dynamic object systems, build a reflection system or a garbage collector. You can do compile time programming.

In general, a systems language is a great asset in your toolbelt. A high level one can let you shape your own environment to great detail.

In the end I think most systems languages will take you to a similar place. Many others have fewer footguns or better ergonomics than C++. Its distinctive feature/bug is having no opinion of almost anything. Or alternatively, you can find subcommunities with almost any opinion.

But is it truly practical to use in 'higher-abstraction' apps like web or mobile? I mostly work in higher-level systems programming but dabble in most areas when I want/need to.

>But is it truly practical to use in 'higher-abstraction' apps like web or mobile?

Yes absolutely. Once you become familiar with the language the barrier is not that high. Familiarity trumps everything else.

That said, since i am not a Web/mobile developer i had collected some resources to help me learn how to use C++ for Web/Mobile apps, you may find it useful;

https://levelup.gitconnected.com/cross-platform-mobile-and-w...

https://github.com/Microsoft/cpprestsdk

https://medium.com/@ivan.mejia/modern-c-micro-service-implem...

Not really. If you want to do iOS development, there's no point in using C++. The Swift interop with C++ is very painful.

I think for Android development, the NDK support is much better and there you might be able to leverage C++ much easier.

I have been working on many mobile apps that would share a C++ model between iOS and Android, and use platform-specific code for views.

Web and mobile is possible but anyone experience in both will realise c++ is only suitable for a minor subset of these.

>Its distinctive feature/bug is having no opinion of almost anything

This single phrase has clarified the workings of the C++ standards body like nothing else; When in doubt, add it in!

History shows this to be just plain wrong. There are many examples but for example look how long doubts about concepts held back that feature.

This very submission is 160 pages documenting this very fact.

Indeed. I have a lot of sympathy for the viewpoint that c++ is a very very complicated language in it's entirety, but not much sympathy for the idea that features are added willy-nilly.

It's a product of its time, massive success, and a herculean effort to retain backwards compatibility. It can be frustrating at times but I can seem to make great things with it still.

All the coolest problem domains (embedded/robotics, games, creative content creation software, systems) run on C/C++ and will for the rest of your career. If you dual wield C++ sword and Python dagger it gets even better (computer vision)

Good point. I think the rust hype threw me off incase it's going to replace C++ but I do agree with GP in that it's probably going to be more like a C/C++ split.

This post has convinced me to look at C++ again. Last time I used it I got put off by the lack of dependency manager so linking things like Boost sucked. Any tips on a modern tool chain?

To pick on the sibiling comment, these are the C++ versions of crates.io.

https://vcpkg.io/en/packages.html

https://conan.io/center/

Plus they can also host binary packages, so you don't have to build the world, just your own stuff.

For some of us that matters.

They certainly are package sites, but they don't seem very like crates.io

I looked at random at the "quote" crate on crates.io and, since I've heard of it and it was on that front page, the "abseil" package from vcpkg

First thing I'm wondering is, is this the thing I thought I might need, or did I mishear somebody and I wanted a different thing? Crates.io provides me detailed information about the crate in one click. Yes, this is what I hoped it was, and here's a great description of how to use it. But on vcpkg there's a single line describing Abseil, and it's cut off for some reason with no indication how to read more. Maybe if I paid Microsoft money I'd know? No idea.

OK. Let's use assume we did want this, both are clear here, crates.io gives me the text to add to cargo to use quote in my program, while vcpkg tells me to invoke a slightly awkward command to get abseil, but either would become natural very quickly I'm sure.

Now, we need a bit more information. On crates.io in two clicks I'm looking at programming documentation for quote, explaining how I should use it with working examples. In one more click I'm reading syntax highlighted source code for the actual quote! macro, in case I'm curious how that works. I am suitably horrified, I definitely want somebody else to solve this problem for me.

But on vcpkg after a few moments with no idea I realise that the Octo-cat icon labelled "Star" is a link to a GitHub repo for Abseil, and this seems the only possible way forward. Alas, the GitHub repo also doesn't really document Abseil, but it does eventually produce a link to another third party site about Abseil, and on that site I get told to install Bazel, a build system that Abseil likes so that I can get "started" learning how to use Abseil.

OK, maybe Abseil is special. Not good news, but lets try something different. What does vcpkg have in the way of Hazard Pointers? It suggests libcds. We can again get to a GitHub, which provides us with a (HTTP) link to a doxygen doc site. Clunky but functional, at least it doesn't want me to install separate build tools. I could learn how to use this, although it lacks search and the examples are poor it is serviceable.

But you're right, vcpkg can include binary packages and so you don't have to build the world and if that is all that matters you're onto a winner.

I could reply about all the issues that make crates.io a non starter for many corporations, but then this would escalate into a Rust vs C++ and better not.

I'm very far from an expert, but Microsoft has been making some nice ecosystem improvements. Check out vcpkg if you haven't had a chance to yet

See my other post in this thread for some reasons making C++ "The One" language to learn.

You mention;

>I am average in many but not an expert in one

This is exactly why i am always wary when people give me a long list of languages they "know". They may know the superficial syntax but not the commonly used "idioms" of the language which is what is necessary for fluent expression in the language. This takes time and effort which i would rather spend with a single language and try to truly "master" it as far as possible. The situation is exactly analogous to learning "Natural Languages". You may be fluent in one or a couple while knowing a few introductory phrases/expressions in half a dozen more.

That it includes almost every possible feature ever posited in a language? /jk, sort of

It's kind of a double edged sword...

Although I've been doing C++ for about a decade now, the one thing that is making me somewhat wary of its future is the difficulty of versioning key components of the language. Sure there are tricks with namespaces to version things to get around ABI breaks (to a degree; this is a world of problems), but fundamental features of the language are set in stone in a way that is very unfortunate.

The latest I've come across is the "R-value lifetime disaster". Arno gave a great talk at cppnow this year [0] highlighting this and Arthur O'Dwyer gave a great rebuttal / follow-up that is also worth considering [1]. The gist of it is that have const& also bind to r values (T&&) causes information about the lifetime to be thrown away. In reality, the "universal binding" ought to have been const&&, as that encodes "can't modify this thing" and "it may not live longer than this function call". This is quite a footgun, but I'm not sure if there's a way to change it with some sort of "language epochs", especially considering that this will have to be exposed in modules / headers so that different "epochs" don't try to link to or use each other's code!

[0] https://www.youtube.com/watch?v=sb7cj-3l1Kc [1] https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetim...

The importance of the observation is radically exaggerated.

When the compiler can see both the call site and the function definition (such as when the function is inline, or a template) it is free to ignore ABI.

If there is a break, it will either be wholly backward-compatible, so that new code can still call old functions, or be a whole separate build target, like the jump from x86 to amd64, with no possibility of linkage mistakes. (There must be people reading here who don't recall the move from 32- to 64-bit x86. It was wholly painless for programmers; not so much for OS distributors.) Imagine building for ARM today; you are at absolutely no risk of accidentally linking x86 code.

Yes when you can compile from scratch it does not matter anymore, but as you mentioned it has mostly to do with software vendors (OS distros, proprietary apps, etc). There are things that are basically disallowed for upgrades in the standard library because certain things (e.g. class member layout, default vs. empty user-defined constructor, such as the register promotion issue when pair<> was '=default' from the empty constructor).

I think Marshall Clow gives a pretty good overview of the ABI issues at a high level [0].

[0] https://www.youtube.com/watch?v=-XjUiLgJE2Y

I, and the company I was at, switched from C++ to Java in the 1990's, and garbage collection was a major productivity boost. Lately it's been Python and JavaScript. Has C++ come up with ways to help with manual memory management, to make it as convenient as garbage collected languages, or almost as convenient?

Programming in C++ today is very little like C++ in the 90s.

No one coding modern C++ feels any envy for other languages' GC.

Yes, modern c++ code wont have manually deleting objects in memory.

I looked at job boards last month and didn’t come across a single posting for c++ developers outside of gaming. What sorts of companies hire c++ developers and what do you build? Are the pay and career respects as strong as web focused options?

I really enjoy c++, or at least the subset I used for my game last year

The highest-paid programming jobs are all C++, and will be for a long, long time.

But job boards are not the place to look for those.

> The highest-paid programming jobs are all C++, and will be for a long, long time.

Not supported; argumentation by mere assertion.

> But job boards are not the place to look for those.

Yeah, we gathered that from the GP. Supporting your argument would require not just repeating where the proof isn't, but showing where it is.

The software development community is connected globally and there's doubtlessly a common culture which is shared between software developers which visit social networks like HN, github, reddit, etc. One aspect of this culture which bothers me in particular is the idea that learning programming languages is unconditionally good.

I've focused on C++ and Python, but never used the latter for big projects and even that showed. I had to reach for the docs more, I had to look into idioms or patterns more for Python whereas my C++ flowed.

While it took me maybe one or two weeks to become familiar with the syntax of a language and write reasonably idiomatic code, it took months to really grasp the ecosystem and more than a year of work in that language to use it like a native and develop expertise in it.

The languages which I've had to learn for specific projects, such as Objective-C, Java or C# have been mostly forgotten. There's a very strong correlation there with the size and length of the project. I think some knowledge is still there and I would be faster to reach competency if I had to use them again, but I would in no way claim to know for example Objective-C now.

Now that I haven't programmed seriously in about two years because of a role change, I can definitely see the impact on my C++ skills: I don't know much about C++17 and up and I've started to find code harder to grasp. Not individual pieces of code, but rather the whole, as if when I step back I no longer have an intuitive grasp about it. I find some language constructs ugly and confusing and no longer feel so attached to C++ or even programming surprisingly enough. Ironically I've been doing some data science stuff in Python, so my skills are pretty much the same there.

I don't like learning programming languages unless I also get something else in return for the time invested. For example I've found an interesting book about systems programming (Rust in Action), so I'll recap my systems programming and also learn some Rust on the side. Pure language books like Programming Rust, even if targeted at C++ programmers and otherwise good do nothing for me. I'd rather learn more about the software/hardware areas I'm interested in.

> One aspect of this culture which bothers me in particular is the idea that learning programming languages is unconditionally good.

Stated exactly like that, yes, that's probably not a good idea.

Stated like "learning new programming languages that are significantly different than the ones you already know is unconditionally good" - that's very close to truth.

The languages you named are Objective-C, C++, Java, C#, and Python. From my perspective, those languages are so similar as to be almost the same.

Learning Red, Io, (a) Lisp, Prolog, Smalltalk, Curry, TLA+, Coq/Lean (or any other theorem prover, actually), Erlang, or (a) FORTH will actually give you an experience that's significantly different than anything else you've used before, with accompanying new ways of thinking that you can apply to your other languages and projects.

100000%. As I mentioned in another thread on this post I was going to take a look at C++ again and since then started playing about on a little game. Almost immediately I approached the problem like Haskell and started passing data as GameState{} structs between pure functions. Using other languages for enough time has made me avoid global/mutable data like the plague and I _think_ I'm a better person for it.

I'd add an array language like APL or J to that list. Idris is worth mentioning, but maybe Curry+Coq cover that space. Maybe Icon too.

Concepts, Techniques, and Models of Computer Programming [1] with Mozart/Oz covers a lot of ground by itself.

[1] https://www.goodreads.com/book/show/772585.Concepts_Techniqu...

That may be, however I'm not looking for experiences when learning software engineering topics. Instead I want something that fits together with my existing knowledge framework and delivers significant benefits.

Programming languages are table stakes and they compete for attention with the things which do matter in a project, like the social aspects and project management, team skills, development ecosystem and domain knowledge among others. Having for example deep knowledge the kernel would be more useful to me than all of the languages in your list combined.

Agree with all your points.

>While it took me maybe one or two weeks to become familiar with the syntax of a language and write reasonably idiomatic code, it took months to really grasp the ecosystem and more than a year of work in that language to use it like a native and develop expertise in it

Very true. I am always mystified when people tell me that i should be able to "pick up" a new language in a couple of weeks. I find learning even a so-called "easy" language like Python somewhat "difficult". Unless i read/write a lot of Python code there is no way i can get fluent in it to feel comfortable with it.

Thanks for the mention of Rust in Action! I am curious about how you found you discovered it.

I like to browse the catalogues of various publishers that I consider of good quality and look for interesting books. Another one that caught my eye was "Rust for Rustaceans" (still in development), which admittedly is a pure language book, but it describes more specialised topics, which aren't typically found in regular books about Rust.

C++ is great, but requires a lot of work to get some things you get in Python for free, such as duck typing and monkey patching. These are really nice things to use in a web framework, which is why Python web frameworks seem to do so much more than C++ web frameworks (they do the same amount, but in C++ there's a lot more boilerplate to set up the framework).

Julia has macros too yknow

Why C++ over Rust? I’m genuinely asking, not trying to evangelize.

I'm not the parent poster but I think this question might be more interesting in 10 years when rust possibly has a larger industry foothold? I agree and I am actively trying to move my career from C++ towards Rust but its slow and Rust isn't particularly heavily used outside of crypto, which is something I am not interested in, from looking at openings for Rust over the past year. I do think it is great that larger companies like FB/Microsoft are now starting to invest in the language though.

My biggest issue with C++ is that although it does seem to be adding lots of good quality of life changes with the recent standards for developers it has inherit flaws that without breaking backwards compatibility it can never be as safe as Rust. And I think C++ is probably right to not break backwards compatibility, it has too large of a user base that will most likely splinter, it reminds me of the python 2/3 problems.

If we are being honest, there is no actual competition between C++ and Rust. Rust is a darling of HN, but practically unheard-of outside these four walls. C++ is the workhorse of industry, and it will be for many years to come. The difference between last week's population of professional C++ coders and this week's is larger than the total number of professional Rust coders. That will be true next week, too.

At this point, it appears that Rust could well survive and become a mainstream language, eventually, but that is by no means assured. While that puts it well ahead of any other language created in this millennium, it is very far from ready to raise a family on.

Remember, Ada had far more investment and industry backing than Rust will have for a long time to come, but was wiped out. Fighter planes are coded in C++, not Ada.

> Fighter planes are coded in C++, not Ada.

https://www.adacore.com/customers/eurofighter-typhoon https://www.adacore.com/customers/amx-modernization-program https://www.adacore.com/customers/arinc-653 https://www.adacore.com/company/our-customers

I'm not sure where this perspective comes from. Rust is growing extremely quickly, far outside the HN bubble.

Rust is used by, and financially supported by, many of the learning companies in the technology industry: Microsoft, Google, Facebook, AWS, Dropbox, and others. It's being piloted for use in the Linux kernel and is already accepted into Android.

Unlike Ada, its development was never bootstrapped by public funds and so all of its growth is due to its practical benefits.

I don't know why fighter planes are the standard to reach, but Rust is even being used in aerospace: both Rocketlab and SpaceX have made public statements supporting Rust or are hiring people with Rust expertise.

Rust usage is growing pretty quickly, a lot like C++ at its age. "Extremely" is a meaningless term in this context.

"Used by <Big Company>" means much, much less than most people who mention it believe. The bigger the company, the more likely it is that they use literally anything at all you can think of, and the correspondingly less it means that they do. They might even be using it in a certain project deemed strategic. But we all know how many of even "strategic" projects at big companies end up canceled, even when they seemed to be a success. You can be certain that they are not using it for anything central to how the company makes its money.

It is more interesting when a $company uses $newtech where it will only have an income if the project succeeds. But you probably never heard of $company, otherwise, so have no way to evaluate how important it is.

SpaceX has said publicly it uses C++ for mission-critical work. Like other $billions companies, they do a lot of things. Saying they do Rust, too, makes them seem edgy in circles where people are likely to hear about it, regardless of how much they actually depend on it. So it is really hard to tell.

Absolutely valid points. I'm definitely inside the filter bubble wrt Rust. It will be fascinating to see where things will be by 2030.

For me it was exactly the other way around, focused exclusively on C++ for almost 20 years, and then eventually got fed up with where the language was going post-C++11 (basically: let's try to cram every feature from every language ever into C++). First I "branched out" to Python for cross-platform scripting stuff, then rediscovered C99, and now I'm keeping a close eye on the new small languages that have been enabled by LLVM. Of course I still also code in C++ when needed because a lot of libraries are written in C++, and most of my current projects end up being a mix of C and C++ code, but C99 is just so much more enjoyable that I prefer it now over C++ as the "top-level" language in a project, with the C++ parts wrapped away under C APIs.

TL;DR: I think it's not healthy for a language to try to do everything.

PS: Learning and regularly using other languages also feeds back improvements into my C and C++ coding.

C++ is moving a bit fast these days, isn't it? What I really like(d?) about systems programming and C++ is that the time invested accumulates and one realizes that they can achieve mastery or something close to it. If you look at JS for example, it's like starting over every 2 years.

See, that's where the "++" part of C++ comes in. They give you an extra year before you have to start over!

/s (in case anyone couldn't tell...)

Reply on news.ycombinator.com