I think depending on the type of project, Rust might already be there. A couple of bullets raise questions:

> ready to use tooling support

This really depends on the use case. If the tooling you're looking for is "Unreal Engine", then Rust is definitely not there yet. But if you want to write network services, databases, CLI tools, etc., I think Rust has been fully viable with good tooling and library support for years now.

> easy to hire if project expands

No doubt hiring experienced Rust developers is hard, because there aren't that many yet. But anecdotally, training Rust developers is much easier than training C++ developers. Rust makes it easier for one or a few experienced folks to have confidence that a larger number of less experienced contributors aren't introducing stability or security issues.

And also you have to check the quality, not only quantity... yes, you get many people if you search "c++ developers" but how good are they? I think people who are into Rust are very motivated, curious people, with some experience. I would really like a study of that, btw :)

As somebody who writes C++ for my job, I don't think the tooling is particularly good so it's funny to me when people talk about that. Languages like Java or Python have good tooling, but C++ is a dumpster fire in terms of tooling.

>Java for enterprise or Android >C# if you are windows developer

Picking Java over kotlin for android, or lumping C# into "just for windows" bucket is exactly the ignorance that leads you to "we don't have choices" conclusion. If you always default to literally top1 language for given domain, then how can you expect to have multiple choices?

I'm not talking about using some brand new gimmick that came out yesterday and will die tomorrow, but if you aren't able to leave your comfort zone even just-so slightly to update your stereotypes about given given domain and its trends, then by definition you won't see the alternatives.

TBH I was shocked by "Python for machine learning". I do not know where that comes from. Maybe because some important toolkits are available for Neural Networks? But machine learning is not neural networks... you can do it with NNs, but there are so many other algorithms... I'm really surprise of this kind of posts in hacker news. I thought the audience here has other experiences.

Python for machine learning is a coincidence of history.

Python is the traditional scripting language for high-performance computing (HPC) going back a very long time, as a wrapper for highly optimized and scalable C libraries. Python on supercomputers wasn't originally used for machine learning but it naturally included support for excellent linear algebra libraries, etc for various types of large-scale modeling. When machine learning first became trendy, data scientists that wanted access to mature library implementations of critical algorithms that worked very well at large scales were mostly limited to C/C++ or Python wrappers of that C/C++. Naturally, they chose Python for the same reason Python was already being used in HPC -- ease of use.

By virtue of its use in supercomputing, Python had uniquely strong support for many types of machine learning before there was a demand for machine learning. If HPC had used some other popular scripting language instead of Python, we'd probably be using that for machine learning right now.

That's literally the only one that didn't shock me. What universe do you live in where machine learning algorithms aren't tied together with Python? And what industry where machine learning is not mainly neural networks?

In the company I work most of it is done in matlab for "putting together" then goes to C++. Again not neural networks. I'm saying all the other machine learning. Maybe rare case.

What kind of machine learning does your company do? It's probably something simple, because for anything complicated, like computer vision, speech recognition, any non-trivial NLP, and large scale recommender systems you do need neural networks.

Autonomous driving, including, for example, computer vision. No NLP or speech. About the "need" or neural networks, there is a lot of discussion going on. As you may know, the "black box" nature of NNs make them a little more difficult than other means, when you have to validate them for safety critical systems.

If you use CV for autonomous driving you use object detectors, and any modern object detector uses a neural network as its backbone.

Used yes. But not the biggest part. Maybe 10% at most.

We are doing L4, so if something goes wrong, the manufacturer is responsible. Once we were in a test car. It was behaving great. At one point, the car "makes the decision" to accelerate and pass. The manager to which we were showing asks "we did the car not waited a little bit? can we change that behavior?". A very long discussion ensued, about data sets, labeling, training... long story short: we have to be able to change behavior (even for perception) in a deterministic way. So the amount of NNs went down dramatically after that.

This is a good point, and I expect in the near future we will be able to simply ask a neural network to explain and change its behavior without retraining. I already see signs of that in prompt engineering used to interact with GPT3 or Dalle2.

It's just going to be as good as asking a human to explain its behaviour. It might be a semi-accurate interpretation of its actions based on its internal knowledge, but it's never going to be the actual thing. The actual decision making inside a neural network is fundamentally not something you could simplify into language exactly.

Yeah, it's not clear if we will be satisfied with those explanations: "I decided to slow down because I see these (seemingly random and irrelevant) objects around me", because during training on trillions of video frames the model has learned it should slow down when similar object configurations are present to reduce the chance of an accident by 0.0002%.

Even if the given reason is simple, like "I decided to slow down because the car in front of me is red", explicit override of the learned rule ("don't slow down when you see red cars") might potentially increase the chance of the accident by a lot more than 0.0002% because we are messing with the model decision making process.

Python is the main language for PyTorch and TensorFlow, there are few ML frameworks more complete than Scikit-learn, I'm not aware of an equivalent to NumPy in other languages, and this list is probably missing other things I don't use.

What's the alternative for quick ML prototyping?

R, Matlab, Julia are some common alternatives.

Java/Scala I've also seen, specifically things around Spark ML, and Spark compute.

That said, Python is definitely the most common nowadays I'd say.

same can be said to typescript, did not mention them to make the point.

> I played with nim, ziglang and Rust, but it's hard to use them for real product developments at this point for me

What made it hard? For example, Rust seem to fit your bullet list.

> what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it".

You could just use C.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.

I've written firmware, systems software, drivers and plenty else this way. Just because the language gives you rope doesn't mean you _have_ to use all of it. I enjoy how terse and straightforward even good ol' structured non-object oriented code can be.

"Object-oriented" is a niche technique.

Any big-enough system will naturally have some OO-ish parts, just because it has some of almost everything. Most small programs will have none.

Exactly. I couldn't have put it better myself, thanks.

They're techniques after all, models, tools.

same here, but I'm embracing modern c++ these days, not for all low level coding yet though.

Yep, big thing for me is smart pointers and RAII. Everything else is secondary.

I have worked on template-heavy codebases that would really benefit from concepts, though.

Smart pointers and RAII do _so much_! I really like zero-cost abstractions, like a nested scope with a RAII object (which will get optimized out) to implement a BEFORE{} and AFTER{}.

That plus structured bindings return types. :)

This is what I do. Write C in C++. You don't have to use all the fancy new shit. I'll never understand why people get so upset about it.

Then you are writing bad C++ code.

The new features are added specifically because they enable writing better programs. Avoiding them means you are choosing not to write better programs. It is allowed, but not a thing to brag about.

That does not mean every program has to use every feature. But when there is a choice between the new way and the old way to do something, the new way is very probably better.

Passing a reference, where you can, is better than passing a pointer. Passing a lambda is better than passing a function pointer. New for-loops are better than old for-loops. A unique_ptr is a better member than a naked pointer. A compiler-generated destructor is better than a hand-coded one.

And so on.

Absolutely, but none of those are really that new. I guess I'm talking more about boost libraries and that stuff. I just can't be bothered and it doesn't matter for anything I need to write.

They are not especially new, but they are not in C.

C is the language that invites in mistakes. The less C we code, the fewer mistakes we ship.

That C in C++ id the part where most of the serious bugs in C++ come from

Honest question: is it easy to find good C++ programmers these days?

I think it is significantly more difficult to find programmers with domain expertise in the kinds of applications C++ is often used for than the language itself. There are quite a large number of good C++ programmers who have never worked anywhere close to the metal, OS, high-performance, etc, and those skills are often more difficult to learn and come by than the language.

A large amount of C++ development is still focused on enterprise and UI apps, even though one could argue that it is not the best language for that purpose.

that's a good question, I have yet to find a good beginner friendly modern c++ education material, be it a book or some course, that can make c++ learning simpler, to the point and enough to start to work with the language before diverting into those deep concepts.

Someone needs to write a c++ 101 book, followed by 201 and 301 for beginner, intermediate, and advanced users.

“C++ Crash Course” by Starch seems to be such a beginner’s book, can’t recommend it enough. Although, I was learning C++ mostly for hobby projects.

a good book indeed, hope it will have an updated version for c++20/23, which arguably is the most important release since c++11, new stuff such as ranges, std::span even concepts could be added now. I think this book is a bit tough for beginners though.

In short, no.

But then, it's hard to find good programmers for any language, so C++ isn't really any worse off here, and better off than some in that at least there's a bunch of candidates to pick from.

Seems like there's plenty, but a lot of em' are already gainfully employed by Google, MSFT, FB and co.

The good ones mostly leave those shops after a few years. Beware of anybody who looks back on them with fondness.

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gone to C++ or even C.

I like to live in the embedded world and there I think Rust will shortly start to push out C and C++ at the wide-spread, commercial level. This is where my head is at, maybe it helps you formulate your opinion:

First, embedded C++ is not the same a full C++ (with features or library parts missing to accommodate the constrained environment). So I might never see some of the C++2x or even C++1x features. I really don't care about the C++2x standards since I might not see them in the next 10 years.

Second, memory and concurrency issues are real, even when you don't allow dynamic memory allocation after the system is initialized. We test, then test, and then run more tests, and turn on a lot of linters and analyzers but at the end of the day, they're bandaids. You can write terrible code in Rust, but you have to work harder to do it.

Third, if you really need an environment where memory is as fungible as play dough but want something portable (like inside a kernel), there will always be C. Setting up a C callable environment from assembly is well understood. In theory, calling into Rust shouldn't be any harder. But reading disassembled object files from C is generally reasonable assembler for the C I wrote. I haven't really tried doing that with Rust.

Fourth, it will take 5 years or so, but eventually we'll see commercially supported RTOS implementations for Rust that help companies to shield themselves from liability. For example, something like Threadx (AzureRTOS now). This will help push money in a virtuous cycle of better tooling -> more projects -> more money for tool venders -> better tooling.

Fifth, there will be Rust bindings to cover just about everything you do with C++ now (like game development) with high quality, idiot-proof, and portable semantics. You will find that junior developers or fresh-outs will have their skin crawl when asked to write "unsafe" code.

Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada.

But that's in the future. If I had to start a new project today (for a braking system on a train, for example), I would start with C, a validated RTOS, and commercial toolchain. If I had to light up my kid's halloween costume? Embedded Rust as a learning exercise. The rendering engine for a VR headset (with limited batter and compute), probably C++.

Go isn't a competitor to C or C++. I don't know where that idea even comes from. Go is competing with Java and web languages.

Rust is the only real competitor, but given the sheer amount of existing C and C++ code, the idea that they will become legacy languages any time soon is pretty out to lunch.

From Rob Pike - One of the creators of Go. see https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

A lot of command line tooling is being written in Go along with systems software (like basically all of container land). Maybe some of these would have otherwise been written in C or C++. For example, if you use the Azure storage GUI to manage storage the underlying "thing" that copies data from your filesystem to azure storage is written in Go and that's why it works on Windows, Linux, MacOS. C++ is somewhat more portable than C so maybe something like that would have been written in C++? Who knows? But Go is definitely showing up in all sorts of native, command-line stuff. And Rob Pike - one of the people who developed Go - intended it to be a new home for C++ developers as well.

> Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada.

Rust is definitely difficult to learn, but I'll anecdotally say that Rust helped get me into the embedded world as someone with very little C or C++ experience. Unlike Ada, Rust has a modern toolchain and type system that feels very comfortable to developers coming from higher level languages, even if many of the concepts related to manual memory management remain quite difficult.

> Unlike Ada, Rust has a modern toolchain

We have a modern toolchain too :)

    # install compiler and build tools
    alr toolchain --select

    # make, build and run a project
    alr init --bin my_project
    alr build
    alr run

In the aeronautics and space industry Ada was and is popular. Ok, not the biggest industry, but still...

It's a very good language. I learned it graduate school in the mid 1990s. I personally think the learning curve is not particularly steep. But it seems like most developers and the industry would rather enforce coding standards to nerf the foot-guns in C/C++ (https://news.ycombinator.com/item?id=7628746). With Ada there would still be coding standards but I would wager that it wouldn't be as much about inherent problems in the language.

They might both have a rule like: AV Rule 1 Any one function (or method) will contain no more than 200 logical source lines of code (L- SLOCs).

But Ada would probably not have something like: AV Rule 59 (MISRA Rule 59, Revised) The statements forming the body of an if, else if, else, while, do...while or for statement shall always be enclosed in braces, even if the braces form an empty block.

Or: AV Rule 193 (MISRA Rule 61) Every non-empty case clause in a switch statement shall be terminated with a break statement.

Those two arise from deficiencies in the basic C/C++ syntax. They are probably not fixable in a future revision of the spec because they would break too much code. So we create a coding standard, configure a linter to check for it, wire up our source repository to scan for it on checkin, and make all the leads code review for it.

Ada might have different language specific standards. For example, around not allowing breaks out of infinite loops. Requiring, instead, a loop construct with a testable condition. But even then, you can pragma things out of the compiler to help you enforce behavior. That's "built in."

My comment with Rust is not that Ada is bad or too hard, but rather even a small amount of additional work might be enough for developers and organizations to avoid Rust. There's a lot of Rust advocacy, which is a good thing. However, there was also a lot of activity on comp.lang.ada.advocacy (if I remember the newsgroup correctly). One good thing is that Ada felt "imposed" by a number of people and that automatically stimulates a kind of rejection response. Rust's introduction is definitely more "bottom up."

Rust can't easily bind to many modern, high performance C++ libraries because it lacks a fair amount of the semantics of C++.

I think that may be a red herring. We normally don't link to name mangled C++ libraries, anyway. Most libraries export their useful symbols in de-mangled format for linking to other languages. That way you can basically dlopen and look for the symbol. There are some libraries that are really only intended to be called from C++ and I don't expect anything other than C++ to use those libraries. I'm not sure if Ruby or Python (for example) can deal with mangled names. I think there are some tools that will generate wrappers to make them callable from things that don't understand mangled names, but if you want to make your stuff interoperable - make it C callable.

It isn't that hard to define something like MyType_t which is a pointer. Then some C code to allocate to wrap the MyType so the type is usable from any language.

I don't think this is a material limitation. Anecdotally, we have few issues with sensibly blending C++20 and Rust. Any exported APIs will need to be circumscribed anyway for integrating with other languages.

I wonder how much of (2) is speculative and how much of it is a real need in actual projects.

The negative performance impact of GC in performance-engineered code is neither small nor controversial, it is mechanical consequence of the architecture choices available. Explicit locality and schedule control makes a big difference on modern silicon. Especially for software that is expressly engineered for maximum performance, the GC equivalent won't be particularly close to a non-GC implementation. Some important optimization techniques in GC languages are about effectively disabling the GC.

While some applications written in C++ are not performance sensitive, performance tends to be a major objective when choosing C++ for many applications.

When people complain about "negative performance impact of GC", often they're actually bothered by badly designed languages like Java that force heap-allocation of almost everything.

I think this might have been fixed in latest versions of Java, though, not sure if value types are already in the language or just coming soon.

Aside from that, it's my understanding that GC can be both a blessing and a curse for performance (throughput), that is, an advanced-enough GC implementation should (theoretically?) be faster than manual memory management.

In theory, a GC should never be faster than manual memory management. Anything a GC can do can be done manually, but manual management has much more context about appropriate timing, locality, and resource utilization that a GC can never have. A large aspect of performance in modern systems is how effectively you can pipeline and schedule events through the CPU cache hierarchy.

There are a few different ways a GC impacts code performance. First, even low-latency GCs have a latency similar to a blocking disk op or worse on modern hardware. In high-performance systems we avoid blocking disk ops entirely specifically because it causes a significant loss in throughput, instead using io_submit/io_uring. Worse, we have limited control over when a GC occurs; at least with blocking disk ops we can often defer them until a convenient time. To fit within these processing models, worst case GC latency would need to be much closer to microseconds.

Second, a GC operation tends to thrash the CPU cache, the contents of which were carefully orchestrated by the process to maximize throughput before being interrupted. This is part of the reason high-performance software avoids context-switching at all costs (see also: thread-per-core software architecture). It is also an important and under-appreciated aspect of disk cache replacement algorithms, for example; an algorithm that avoids thrashing the CPU cache can have a higher overall performance than an algorithm that has a higher cache hit rate.

Lastly, when there is a large stall (e.g. a millisecond) in the processing pipeline outside the control of the process, the effects of that propagate through the rest of the system. It become very difficult to guarantee robust behaviors, safety, or resource bounds when code can stop running at arbitrary points in time. While the GC is happening, finite queues are filling up. Protecting against this requires conservative architectures that leave a lot of performance on the table. If all non-deterministic behavior is asynchronous, we can optimize away many things that can never happen.

A lot of modern performance comes down to exquisite orchestration, scheduling, and timing in complex processes. A GC is like a giant, slow chaos monkey that randomly destroys the choreography that was so carefully created to produce that high-performance.

> performance tends to be a major objective

My comment is about the thinking behind making this decision, C++ or not. It wasn't "is it speculative that GC will add a cost?" or something like that.

I wonder how much of the thinking that leads one to conclude "I need so much performance here that I can't afford a managed language", for example, is real carefully thought vs. speculative.

In my experience 99% speculative and WRONG. Who said: "early optimization is the root of all evil"? :) Today more and more is possible to have a GC without terrible performance issues. Some weeks ago I read an article here in HN, about LISP used for safety critical systems. That bad fame of GC comes from the early versions of Java... but I've been using GC languages a LOT, and never had those "stop the world" moments.

The expression is "premature optimization". And, Donald Knuth.

GC overhead is always hard to measure except end-to-end, because it is distributed over everything else that happens. Cache misses, TLB shoot-downs. Mitigations are very difficult to place.

Practically, you usually just have to settle for lower performance, and most people do. Double or triple your core count and memory allocation, and bull ahead.

Not my bailiwick but I feel like early Java's problem was a combination of everything not a simple primitive is an object that goes on the heap plus a GC optimized for batch throughput vs latency. Bonus it's Java all the way down to the bitter end.

I'm with you. One should look at latency requirements and the ratio of profit vs server costs when making a decision. AKA when your product generates $250k/month, you're paying three programmers $40k/month, and your AWS bill is $500/month isn't the time to try and shave pennies.

Go's garbage collector is faster than you imagine. Have you used it?

Go is a good replacement for C and C++ for almost all purposes.

Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway.

The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).

Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good fit to the problem.

I like go, I use it on occasion. If I stick to the simple stuff it is really easy to think about and if it is just a back end on a big server, why not. But that is a niche case for me. I usually prototype in matlab, then implement in c++, and yes, often cuda too, but I think saying that go is almost always a drop in for c++ is missing the vast majority of what c++ is used for. Go is not a systems language, it benchmarks slower than many vm lamguages like java and c#. It's gimmick is that it compiles really fast and is easy to reason about, so it is good for velocity. But it sacrifices a lot for that. FFI compatibility, and runtime speed foremost. Sometimes those things don't matter. But for systems programming, dsp, embedded, or AAA games they are deal breakers.

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely.

For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't.

The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't.

Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage.

Trying to target that with go would add a lot of extra challenge.

I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature.

The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.

C++ allows you to control your memory allocations.

You can use mark and sweep, you can us reference counting, you can use arenas, you can use local stack, you can use shared memory, you can have custom allocators for any object, you can avoid memory allocations altogether, and any combination of these.

C is the same. Java can do some of this, if you twist it hard enough. Go cannot. That's ok -- often, even most of the time, you don't care, and then Go is a fine language.

But C++ is useful in a much wider set of domains than many people think, because it offers a level of control that many other languages don't.

My favourite analogy? Go (etc) is like an Apple product: smooth, and shiny, and tries to be idiot-proof, but you can only do it the Go way. C++ is more Linux: a mess of incompatible, incomplete, infuriating things that let you do absolutely anything you want, if you invest the effort.

As a Go expert, you should consider fixing it, and more people will be willing to use Go for performance-oriented projects. Like it or not, a lot of people go to the benchmarks game website to think about programming language performance.

Compare GC Java with GC Go.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Thanks for the work separating out the solutions. It really helps compare the sort of code I'd actually write in those languages. Also, what is the reasoning behind no numpy? I'd never do something like nbody or Mandelbrot without numpy or torch in my actual job, so it isn't idiomatic in a way. Not a complaint, I could always fork it if I cared enough, just curious about the reasoning. I know pypy didn't really want to be involved. Thought it might be like that for numpy?

pidigits and regex-redux explicitly allow use of C libraries.

I looked again at the idiomatic solutions and of the GC languages, on the benchmarks that are relevant to me, go leads the pack (except unchecked swift which doesn't really count, and julia which I think may use actual magic). I feel somewhat vindicated in not bothering to learn c# yet. I am trying to become more fluent at julia though. It already has a very extensive set of libraries from it's community. I may eventually use julia for the things I reach for go for now, and probably some of the things I use matlab, c++ and cuda for.

Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++.

Go also has the stop-the-world GC problem, GC is great but it does have a price tag.

I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.

Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either.

But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.

C++17/20 is superior to Go, and widely used, for anything that looks like high-performance data infrastructure, which is a broad class of software. There are classes of common architectural optimizations that aren't feasible with a garbage collector because of how it interacts with scheduling and CPU caches. Even 1 millisecond for a GC pause -- often considered "low latency" -- is much too slow when standard operation rates are tens of millions per second.

Go is very good for many things but it does not offer competitive performance for these types of applications because design elements that have a large impact on throughput are poorly supported.

go has other problems that preclude it from being a good option including binary size, memory usage, and portability. There are certainly a lot of places it is a good choice for, but I can't really imagine using it anywhere I use c++ today.

Portability?

Are you saying Go has portability problems?

Can you elaborate on that very surprising claim?

when you talk about macos/windows/linux without CGO yes Go is very portable and easy to use, when you need CGO, or you need work on other architecture or OSes, Go is pretty much a no-go. and c/c++ are still the only ones close to the claim "runs on everything".

What are people using C and C++ for that you can comfortably use Go instead?

For example, I work at a company (a company you hear about daily here on Hacker News) that has a compiler generating linear algebra kernels.

The compiler is a huge assemblage of C++ templates, stitched together with a little Python.

The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle.

But the compiler itself does NOT need to be so minutely tuned. It needs to be maintainable and it needs to allow easy development of complex code generators.

Go would be a great choice for the compiler.

Instead, we struggle with C++ templates, CMake'ing our code slowly and with absurd complexity, modifying the compiler slowly and with great difficulty...

Honestly, it sounds like C++ is just a poor choice for this project, since you are not so interested in performance and you are a lot more interested in developer speed. It is not an example as to why Go is a good replacement for C++ in almost every project. This is a case where you could replace C++ with any business-logic-oriented programming language and you would be happier. It just so happens that your language of choice is Go (and presumably the tech lead's language of choice is C++ for some unknowable reason).

Also, you should not discount compiler speed completely. You, yourself, were upset at the speed of a compile process. All of your users are going to be waiting to get things done while the compiler is running, so you might want to do some math as to how much a 10% slowdown would cost in developer salaries. The makers of gcc, LLVM, and clang spend a lot of effort on improving the speed of their compiler to make sure that you have minimal time waste.

Honestly Go would be a bad choice as well, wouldn't it? It's not like it has much in the way of abstractions.

Sounds like you have a code-quality problem more than a language problem. In that situation, switching languages probably would not help you much.

Get a handle on your code quality, and put the language features to work to solve problems for you. Then Go will increasingly look pitifully inadequate.

I've read all of your comments and I commend you trying to illuminate these people. Some of them seem to be living in the 1990s, spewing the usual hocuspocus about programming languages, the kind of thing you hear once and it becomes a myth. It's like people don't want to reevaluate their choices, and it's insane we keep using this god-forsaken language when we have much better tooling, as you said.

Sounds like Fortran to me.

Fortran is easy to hire for?

For numerical and scientific (high performance) jobs, possibly not that much harder than C++. For other jobs, I doubt it and would stick to C++.

The issue is that, for example, you might be getting people with poor software engineering training per se. You risk hiring some very smart phd that writes code that works and runs really fast, but isn't that readable, extendable, maintainable, testable, etc.

Your second paragraph describes what I see with Python ML guys.

It's generally true for ML and data science, regardless of the language.

I see it in a lot of matlab code as well.