> You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth.
Well, I have been coding since 1986 and the only systems programming languages that survived were the ones adapted by OS vendors.
If a systems programming language isn't adopted by an OS vendor, it becomes yet another application programming language and has to compete in already full arena.
> There's a really good reason for why a lot of software being built for the finance industry is being built in C++.
I do like C++, a lot, given its capabilities. But also dislike the unsafety it inherited from C.
However, I think one of the reasons C and C++ got so widespread is that 20 years ago, Java and .NET kind of killed all the other alternatives capable of produced standalone executables with optimizing compilers. At least from what mainstream developers are comfortable with.
So when a average developer goes looking for a programming language able to deliver binaries without dependencies his/her only options are C and C++, which feeds the circle.
I bet if Java, C# and VB.NET had gone the way of producing binaries like Delphi, Oberon and so on, the domain of C and C++ wouldn't be as it is nowadays.
For example, if Ada compilers were cheaper or if Borland had improved Delphi's toolchain across multiple OS instead of going astray in multiple directions, any of those languages could be in C++'s place.
Actually finance is one of the reasons why both Java and .NET are getting pure AOT compilation support nowadays.
> Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do.
Yet Mesa/Cedar, Oberon and Modula-3 were used successfully to build OSes that, in Oberon and Cedar's case, were used for quite a while as ETHZ and Xerox PARC workstations.
I believe that the need of producing binaries without dependencies (I assume you mean a VM) isn't so widespread, quite the contrary, most developers want a VM underneath because then deployment becomes easier. The loud minority that has historically complained about the widespread usage of the VM have been just that, a minority. And it is funny, because things are progressing in that direction with C++ as well (speaking of LLVM or Emscripten). That is not and has never been the real difference between C++ and Java/.NET, but rather in having versus not having a GC. The main reason for why C++ still wins by a good amount in any benchmark is because for performance sensitive code memory access becomes by far the biggest bottleneck and in C++ there's simply more opportunity for optimizing memory access patterns.
Delphi too lacked a GC. Java and .NET haven't killed Delphi, it is Borland that killed Delphi. This isn't a winner takes all kind of war (well, maybe it is in Windows land). We live in an industry in which multiple programming languages can coexist. For evidence of this you need to look no further than Linux, the Tower of Babel of our age.
And I disagree with you - besides the open-source operating systems that are developed by multiple parties, all "OS vendors" are interested in the lock-in of developers. You're mixing cause and effect I think ... when an "OS vendor" adopts a programming language that isn't created by themselves, that's only because the programming language in question is already popular and here to stay.
Yeah, maybe I have been burned a few times by the usual BOFH IT processes where one can only use the tools that are offered by the OS vendors, and only in special cases is allowed to use third party tooling.
In any case, as language geek, I always wish all programming languages find their place, specially those trying to make programming safer.
Well, I have been coding since 1986 and the only systems programming languages that survived were the ones adapted by OS vendors.
If a systems programming language isn't adopted by an OS vendor, it becomes yet another application programming language and has to compete in already full arena.
> There's a really good reason for why a lot of software being built for the finance industry is being built in C++.
I do like C++, a lot, given its capabilities. But also dislike the unsafety it inherited from C.
However, I think one of the reasons C and C++ got so widespread is that 20 years ago, Java and .NET kind of killed all the other alternatives capable of produced standalone executables with optimizing compilers. At least from what mainstream developers are comfortable with.
So when a average developer goes looking for a programming language able to deliver binaries without dependencies his/her only options are C and C++, which feeds the circle.
I bet if Java, C# and VB.NET had gone the way of producing binaries like Delphi, Oberon and so on, the domain of C and C++ wouldn't be as it is nowadays.
For example, if Ada compilers were cheaper or if Borland had improved Delphi's toolchain across multiple OS instead of going astray in multiple directions, any of those languages could be in C++'s place.
Actually finance is one of the reasons why both Java and .NET are getting pure AOT compilation support nowadays.
> Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do.
Yet Mesa/Cedar, Oberon and Modula-3 were used successfully to build OSes that, in Oberon and Cedar's case, were used for quite a while as ETHZ and Xerox PARC workstations.