C++ Is the New Python(efinancialcareers.com)
efinancialcareers.com
C++ Is the New Python
https://www.efinancialcareers.com/news/2021/07/modern-c-finance-jobs
90 comments
The difference between C++ and Python is that the Python standard library is actually useful to get practical work done (the famous "batteries included" philosophy). The C++ standard library can't quite decide if it wants "academical purity", or solve real world problems, and the result is a remarkably useless mishmash of random ideas.
Maintenance matters. The C++ standard library provides some data structures you shouldn't use. OK, not some, C++ stdlib provides almost exclusively data structures you shouldn't use. But hey, the C++ language itself has some data structures you shouldn't use too (arrays especially).
However, Python's standard library is stuck with urllib, although these days they have the courtesy to tell any poor fool looking at the documentation that Requests exists, if you do use the standard library you get very primitive HTTPS handling, and so many wrong defaults.
Because these standard libraries have so many users, Hyrum's law means that you have to work very hard to fix anything.
However, Python's standard library is stuck with urllib, although these days they have the courtesy to tell any poor fool looking at the documentation that Requests exists, if you do use the standard library you get very primitive HTTPS handling, and so many wrong defaults.
Because these standard libraries have so many users, Hyrum's law means that you have to work very hard to fix anything.
"C++ stdlib provides almost exclusively data structures you shouldn't use"
The containers according to [1] are array, vector, deque, forward_list, list, *set, *map, stack, queue and priority_queue. All of these are good general implementations that can and should be used for most C++ software.
Some classes of software require better performance or certain special guarantees and then it makes sense to consider specialized implementations.
[1] https://en.cppreference.com/w/cpp/container
The containers according to [1] are array, vector, deque, forward_list, list, *set, *map, stack, queue and priority_queue. All of these are good general implementations that can and should be used for most C++ software.
Some classes of software require better performance or certain special guarantees and then it makes sense to consider specialized implementations.
[1] https://en.cppreference.com/w/cpp/container
I think in urllib.request’s case (urllib.parse is fine albeit arguably with a cluncky API) it’s not they need to work very hard to fix it, but the task is impossible. My understanding is that bundling SSL validation in the Python stdlib is a lost cause since Python is updated way too infrequently and the stdlib cannot be easily changed once a Python minor version goes EOL, so they just gave up. If there’s anything Hynum in here, it’s they have their hands tied from removing the module entirely.
> although these days they have the courtesy to tell any poor fool looking at the documentation that Requests exists
Added up with "And when your project scales, Replace asyncio with uvloop, Coroutine with gevent, http.server with gunicorn and everything else with a cython based alternative".
Or personally I just say 'Use go instead' to someone who's just getting into programming for developing a project which could potentially scale.
Added up with "And when your project scales, Replace asyncio with uvloop, Coroutine with gevent, http.server with gunicorn and everything else with a cython based alternative".
Or personally I just say 'Use go instead' to someone who's just getting into programming for developing a project which could potentially scale.
Exactly. Just look at the mess that is the C++ String.
This, of course, causes everyone to roll their own String, which is probably almost as bad.
So, now we have a zillion String libraries, all of which suck.
All because the C++ standard library doesn't provide a decent String.
This, of course, causes everyone to roll their own String, which is probably almost as bad.
So, now we have a zillion String libraries, all of which suck.
All because the C++ standard library doesn't provide a decent String.
std::string is not a mess, it's a good general string implementation which should suffice for many applications. Its only sin is perhaps that it does not support Unicode.
If you look for example at other implementations like fbstring, the main benefit is performance.
If you look for example at other implementations like fbstring, the main benefit is performance.
Damn right! The C++ standard is now at a point where a good standard library would be possible, but it's just not happening.
I find if you combine the standard library with boost, it does become pretty useful... Although some of the libraries in boost are beyond my understanding eg CallableTraits.
I agree that the python standard library is really useful.
I agree that the python standard library is really useful.
boost has quite a few useful libs..
unfortunately, some of the libs put performance first over ease-of-use. which can be a drag.
and then there is compiling boost which is usually a thing where i need to set aside a day or two to get it working on a new platform / project.
unfortunately, some of the libs put performance first over ease-of-use. which can be a drag.
and then there is compiling boost which is usually a thing where i need to set aside a day or two to get it working on a new platform / project.
These kinds of replies are the bane of interesting discussions because they're aggressive and don't contain any information... What is someone that is unfamiliar with the C++ standard library left with after reading it? At most an uneasy feeling, which is not based on any facts.
So here are some facts:
* A good reference for the C++ standard library is https://en.cppreference.com
* The standard library is not as large as .NET or Java, but it covers many essential concepts of which the containers and algorithms are the best known. Besides classics like doubly-linked lists, dynamic arrays (std::vector) or maps, there's also sets, a singly-linked list, stack, queue and priority queue. All data structures have complexity guarantees defined in the C++ standard, which is surprisingly very rare for programming languages.
* The algorithms include sorting and searching but don't stop for example at a simple sort and instead also include a partial and stable sort. Besides binary search and linear search, there's also functions like https://en.cppreference.com/w/cpp/algorithm/lower_bound or https://en.cppreference.com/w/cpp/algorithm/equal_range and several functions for working with heaps, such as make_heap, push_heap, etc. Other interesting algorithms include those for permutations, counting, working with ranges and modifier functions like rotate, sample or random_shuffle. C++ offers a world-class algorithms library.
* The numeric library offers support for many pseudo-random number generation algorithms, and many distributions (https://en.cppreference.com/w/cpp/numeric/random). There are dozens of usual (https://en.cppreference.com/w/cpp/numeric/math) and less usual (https://en.cppreference.com/w/cpp/numeric/special_functions) mathematical functions in there.
* For systems programming there's the date and time utilities, file system, threads and atomics.
* Although standard for most languages at this point, C++ does offer regular expression support in the standard library.
* Many other smaller types and functions such as tuples, complex numbers, a modern union type (std::variant), streams, etc.
When the above is not enough, there's boost, a series of high-quality libraries with a long history which are like an extension of the standard library. My personal favorites from boost include state machines, graphs, numeric conversions, logging, program options, signals (subject-observer implementation) and ASIO for all sorts of IO.
But there's tons of stuff in there, from additional algorithms and containers to JSON parsers to HTTP and web sockets, from process and shared object management to userland threads, IPC, lockfree data structures and so on and so forth.
And if that's still not enough, there's almost certainly another library for it. C++ is one of the most popular programming languages out there and it has decades of history behind it.
So here are some facts:
* A good reference for the C++ standard library is https://en.cppreference.com
* The standard library is not as large as .NET or Java, but it covers many essential concepts of which the containers and algorithms are the best known. Besides classics like doubly-linked lists, dynamic arrays (std::vector) or maps, there's also sets, a singly-linked list, stack, queue and priority queue. All data structures have complexity guarantees defined in the C++ standard, which is surprisingly very rare for programming languages.
* The algorithms include sorting and searching but don't stop for example at a simple sort and instead also include a partial and stable sort. Besides binary search and linear search, there's also functions like https://en.cppreference.com/w/cpp/algorithm/lower_bound or https://en.cppreference.com/w/cpp/algorithm/equal_range and several functions for working with heaps, such as make_heap, push_heap, etc. Other interesting algorithms include those for permutations, counting, working with ranges and modifier functions like rotate, sample or random_shuffle. C++ offers a world-class algorithms library.
* The numeric library offers support for many pseudo-random number generation algorithms, and many distributions (https://en.cppreference.com/w/cpp/numeric/random). There are dozens of usual (https://en.cppreference.com/w/cpp/numeric/math) and less usual (https://en.cppreference.com/w/cpp/numeric/special_functions) mathematical functions in there.
* For systems programming there's the date and time utilities, file system, threads and atomics.
* Although standard for most languages at this point, C++ does offer regular expression support in the standard library.
* Many other smaller types and functions such as tuples, complex numbers, a modern union type (std::variant), streams, etc.
When the above is not enough, there's boost, a series of high-quality libraries with a long history which are like an extension of the standard library. My personal favorites from boost include state machines, graphs, numeric conversions, logging, program options, signals (subject-observer implementation) and ASIO for all sorts of IO.
But there's tons of stuff in there, from additional algorithms and containers to JSON parsers to HTTP and web sockets, from process and shared object management to userland threads, IPC, lockfree data structures and so on and so forth.
And if that's still not enough, there's almost certainly another library for it. C++ is one of the most popular programming languages out there and it has decades of history behind it.
Yeah with python you have pip, with rust there is cargo wih c++ there is a whole painful largely manual process unless you use a big tool like bazel to help reduce the build complexity.
What parts of the C++ standard library do you find useless/random?
Making a comeback? When did it ever go away?
The author talks about high frequency trading and finance applications, but it does not seem he has ever worked in the field. Production HFT is written in C++.
The author talks about high frequency trading and finance applications, but it does not seem he has ever worked in the field. Production HFT is written in C++.
What's interesting is that some of it happens to be written in Haskell.
And Java. I suspect that would be harder to believe to some.
May I politely disagree. A lot of software in financial institutions is written in Java (maybe this is a cultural bias because I happen to live in Western Europe).
The fact that some of the HFT software is (or was) written in Haskell is pretty amazing because when you first look at it, it does not appear to be a good language for being very fast.
solving approach >> tool
Yes it's easy to find orders sent by haskell because they're unfilled and marked 'canceled'.
Funny, coming from machine learning, C++ is taking over from Python there as well. Why? I think it is because Python isn't really a deployment language for this domain (development, yes). Also, C++ lets you bend C in ways that are more Pythonlike (from STL classes to templates to zany overloads). The downside: C++ that has been massaged for years by multiple academics can end up being far more dense and difficult to understand than Python over the same period. For example, look at TFLiteMicro github, it is a snarl of custom idioms in C++. Compared to TensorFlow, it is IMHO a mess and a symptom of unchecked C++ style.
Speaking of "new Pythons", I recently started playing with D and got that impression. It's like the compiled, fast executing Python I have always wanted hidden in plain sight.
I think you might like Nim lang.
Nim to me is basically compiled Python. I really root for it, but it honestly hasn't gotten the traction it deserves
I'm old enough to remember a war between Perl and Python (bioinformatics). I was on team Python and didn't understand why would anyone want to write code in Perl. Python didn't have traction, nor books or libraries.
Fast forward 20 years, and everything is Python or R.
Fast forward 20 years, and everything is Python or R.
Go Lang is C designed after Python existed.
Go Lang is a lot closer to Java 1.2 than it is to C.
It is not object oriented. Interfaces and struct methods with composition and not inheritance is much more C than Java (no not overriding methods) kind of the C or compiled version of duck typing. Reading thru OpenSSL code is not that different from reading thru Go code. Typed but not a artificial hierarchy of types.
I strongly disagree.
Go is an improved C that includes garbage collection (as is needed to make bug-free concurrent programming easier).
Go is an improved C that includes garbage collection (as is needed to make bug-free concurrent programming easier).
[deleted]
It's just "Go". The way I usually describe it is "the sweet spot between C, C++, Python and Java", which, considering who worked on it and where they worked, seems to be closer to reality than just C.
D is such a pleasant language. Super easy to learn too.
I would _love_ to see a book on modern (like C++2021 modern) programming in C++ for Python developers.
As someone who learned C++ when it was C++03 and followed the language as it went through 0x all the way to 20, I have no idea how you would be able to avoid crippling a newcomer with the sheer volume of permutations of symbols and language behaviors that a C++ developer might regularly encounter. As a consequence of the ecosystem of older libraries, I've never had the pleasure of fully stepping away from old C++-isms. There's always a naked pointer or a malloc floating around somewhere in code I have to be able to read.
I still occasionally write C++ when I need to, but it's been a long time since I actually enjoyed doing it.
I still occasionally write C++ when I need to, but it's been a long time since I actually enjoyed doing it.
The closest you'll get to that is probably Scott Meyer's effective modern c++ which is for c++14. Scott has retired around in 2015 so don't expect an updated book.
Actually there is a recently released book[1] by No Starch that gives a tour of modern C++ with details about implementations and librairies and even has a great chapter on unit testing.
[1]:https://www.amazon.com/C-Crash-Course-Josh-Lospinoso/dp/1593...
[1]:https://www.amazon.com/C-Crash-Course-Josh-Lospinoso/dp/1593...
+1 Lospinoso is the real deal
One problem for trying to just learn "modern C++" (so, C++ 20 and explicitly preferring the modern "right" way to do things, Kate Gregory talks about teaching C++ this way) is that C++ got this influential partly by having a lot of libraries. But for a library author, choosing C++20 over C++11 (or worse) means fewer users.
So, sure, all the code from people learning "modern C++" is smart pointers and ranges, but to get work done you have to call this library that takes raw pointers and you're immediately out of your depth.
So, sure, all the code from people learning "modern C++" is smart pointers and ranges, but to get work done you have to call this library that takes raw pointers and you're immediately out of your depth.
raw pointers.. or homegrown strings, vectors and hash tables.
C++ soldiers on because it can support such things and adapt to decades of changing hardware and philosophy. But the pain of using and composing libraries in C++ is not just about not having cargo or npm - it's the lack of consensus on data types for anything beyond C primitives.
C++ soldiers on because it can support such things and adapt to decades of changing hardware and philosophy. But the pain of using and composing libraries in C++ is not just about not having cargo or npm - it's the lack of consensus on data types for anything beyond C primitives.
This sounds like you're describing C++ from 20 years ago. Or maybe some ugly monstrosity like Qt.
Everything uses/supports standard library containers or interfaces now.
Everything uses/supports standard library containers or interfaces now.
There's nothing ugly about Qt. In particular, the core system defines a way to add features to classes that were missing (MOC) and provides a full foundation of types up to network and other event-driven multi-threaded servers. Frankly I think it's one of the best examples of C++ I've seen.
Some counterexamples that I've dealt in the recent years include LLVM, Abseil and Windows COM APIs.
Smart pointers are a weird example because they're ancient. I'd say the majority of C++ libraries expect C++11, many C++14.
Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.
Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.
> Smart pointers are a weird example because they're ancient.
I am an old man, and to me 2011 doesn't feel ancient, but fair. C++ 11 has unique_ptr and shared_ptr (if your library uses a previous generation of smart pointers you're in worse trouble than if it had raw pointers) and that's what you'd probably teach in class today.
> Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.
This is true. So you can't tell. And, with a different hat on it's also something that Kate Gregory has given talks about. As the new maintainer for several MLOC of C++ what can I conclude about this function that takes a raw pointer to a foo ?
Maybe, it just wants to look at a foo, immediately and then has no further interest in it.
Maybe, it will mutate the foo, immediately, and then loses interest.
Maybe, it will hang on to this pointer and use it later, who knows when. Thus, now it "owns" the foo, I hope it will clean up after it ceases using it because I can't now.
Maybe, I'm supposed to provide an "empty" foo and the contents of it afterwards are the primary result of the function.
Those are pretty different, so it's disappointing that we don't learn which it is from the function signature.
I am an old man, and to me 2011 doesn't feel ancient, but fair. C++ 11 has unique_ptr and shared_ptr (if your library uses a previous generation of smart pointers you're in worse trouble than if it had raw pointers) and that's what you'd probably teach in class today.
> Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.
This is true. So you can't tell. And, with a different hat on it's also something that Kate Gregory has given talks about. As the new maintainer for several MLOC of C++ what can I conclude about this function that takes a raw pointer to a foo ?
Maybe, it just wants to look at a foo, immediately and then has no further interest in it.
Maybe, it will mutate the foo, immediately, and then loses interest.
Maybe, it will hang on to this pointer and use it later, who knows when. Thus, now it "owns" the foo, I hope it will clean up after it ceases using it because I can't now.
Maybe, I'm supposed to provide an "empty" foo and the contents of it afterwards are the primary result of the function.
Those are pretty different, so it's disappointing that we don't learn which it is from the function signature.
Huh. There simply aren't that many C++ compilers in the world that matter... who is working with a C++11 compiler, but doesn't have at least C++17? (The core problem with C++20 is that support is still spotty: like, I am waiting with baited breadth for clang to finally get around to P1091R3/P1381R1... they list it as "partial", but it feels like "not even started".)
I'm on the same line. I'd love to see a book focused on practical C++/11/17 with non trivial projects. Effective Modern C++ explains a lot of things, but concrete examples are a lot better.
Some projects in mind:
C++/SFML/SDL2 game programming using modern C++
Interpreter/compiler construction in modern C++
Explains how to implement things in modern C++ (e.g.unique_ptr) without modern C++ (maybe just use C)
Some projects in mind:
C++/SFML/SDL2 game programming using modern C++
Interpreter/compiler construction in modern C++
Explains how to implement things in modern C++ (e.g.unique_ptr) without modern C++ (maybe just use C)
Yes, just talking about the language isn't enough.
Solving somewhat complex problems with standard data structures (maps, trees, hashtables, etc.) and doing it in the modern, efficient way is the kind of thing I'm really looking for.
In Python it's easy (which isn't to say everything should use Python) because you don't have to do anything but use the builtin datastructures and solve your problem.
Maybe modern C++ works the same way but if it does, I still need someone to show it since that isn't how it used to be (to my knowledge).
Solving somewhat complex problems with standard data structures (maps, trees, hashtables, etc.) and doing it in the modern, efficient way is the kind of thing I'm really looking for.
In Python it's easy (which isn't to say everything should use Python) because you don't have to do anything but use the builtin datastructures and solve your problem.
Maybe modern C++ works the same way but if it does, I still need someone to show it since that isn't how it used to be (to my knowledge).
Yeah the thing is I don't know if there is any _good_ small-medium modern C++ code base to read.
Eventually I just gave up and use raw pointers. My theory is that since people don't care about JVM not returning memory to system, they should also not care a bout a few MBs of memory leak in my small game.
Eventually I just gave up and use raw pointers. My theory is that since people don't care about JVM not returning memory to system, they should also not care a bout a few MBs of memory leak in my small game.
What about a book or resources for someone who already knows C++? I haven't used it in 10 years and even then, where I worked at the time, using C++11 features was "off-limits". Just from a cursory glance, a lot seems to have changed since then?
I would love to see a book on modern C++ (11 and beyond) in general, for people used to other languages. I'd like to learn it at some point but it's honestly really intimidating.
All those "language market shares" are not very indicative of the multifaceted language landscape.
C++ is certainly not becoming the language of wannabe research data scientists that made Python grow so much, but of course there are fields where it is growing and there are fields where adoption is decreasing.
I doubt that HFT used Python before a C++ wave swept it, since speed has always been a concern, so I am skeptical of the article.
As to the "Rust is the C++ killer" crowd... show me a really big project using mainly Rust now, as there are uncountable using C++, a network simulator, a desktop application, a physical simulation engine, an operating system, a compiler, anything really big. You perhaps will find one or two, compared to thousands for C++. The best that you can hope is to see Rust seriously compete with Rust 15 years from now. And then overtaking it, perhaps. Best case scenario.
C++ is certainly not becoming the language of wannabe research data scientists that made Python grow so much, but of course there are fields where it is growing and there are fields where adoption is decreasing.
I doubt that HFT used Python before a C++ wave swept it, since speed has always been a concern, so I am skeptical of the article.
As to the "Rust is the C++ killer" crowd... show me a really big project using mainly Rust now, as there are uncountable using C++, a network simulator, a desktop application, a physical simulation engine, an operating system, a compiler, anything really big. You perhaps will find one or two, compared to thousands for C++. The best that you can hope is to see Rust seriously compete with Rust 15 years from now. And then overtaking it, perhaps. Best case scenario.
> show me a really big project using mainly Rust now, as there are uncountable using C++
For starters, the Rust compiler is self hosted and is written in Rust. Many important parts of Firefox are written in Rust. The Linux kernel just added support for Rust. A moment's Googling could turn up plenty of other examples.
For starters, the Rust compiler is self hosted and is written in Rust. Many important parts of Firefox are written in Rust. The Linux kernel just added support for Rust. A moment's Googling could turn up plenty of other examples.
C++ and Rust are not competing languages. In many instances, they actually compliment each other pretty well. Rust offers native interop for C++ code, but the cost of running it is that it's labelled "unsafe" and doesn't offer any of the memory safety that truly "safe" Rust code offers (duh). With that being said though, most of the infrastructure that C++ left behind is perfectly usable in Rust. With that in mind, the "15 year plan" for Rust is to work alongside C++, giving developers a safer, oftentimes easier option for writing performant code.
Rust isn't the anything killer, Rust is Rust. That's why it's so special; it's really in a league of it's own.
Rust isn't the anything killer, Rust is Rust. That's why it's so special; it's really in a league of it's own.
AFAIK speed is only a real issue in the financial sector for very few applications. For most of them the database is the bottle-neck not the programs.
Also, security is generally important in this sector. Both C++ and Python do not have a good track record when it comes to security. C++ has a lot of guns to shoot yourself in the foot. Python is essentially un-typed which means that errors only show up on runtime. Where I live most financial software is still being developed in Java.
Also, security is generally important in this sector. Both C++ and Python do not have a good track record when it comes to security. C++ has a lot of guns to shoot yourself in the foot. Python is essentially un-typed which means that errors only show up on runtime. Where I live most financial software is still being developed in Java.
This is true of public trading platforms, but for the earlier HFT apps that required speed, network was the bottleneck, and writing everything in C allowed them to hack the networking stack to get rid of all the bad assumptions of general-purpose computers that slow you down. Whether it's the BIOS itself or the kernel, or even if you're hacking the actual network appliances, the networking stack is almost certainly written in C, not giving you much of a choice if you have to change it.
In more general quant and financial engineering applications, I think it was ecosystem inertia as much as anything. Many of the simulation and solver frameworks were based on physics libraries written in C++, and quantlib was built on top of Boost. C++ just became a de facto lingua franca for anyone doing that kind of work, and they weren't primarily programmers, so they weren't going to spend a lot of time learning other languages and ecosystems when they were already comfortable with and productive in C++.
In more general quant and financial engineering applications, I think it was ecosystem inertia as much as anything. Many of the simulation and solver frameworks were based on physics libraries written in C++, and quantlib was built on top of Boost. C++ just became a de facto lingua franca for anyone doing that kind of work, and they weren't primarily programmers, so they weren't going to spend a lot of time learning other languages and ecosystems when they were already comfortable with and productive in C++.
Speed is an issue in many domains, for example graphics applications and games, embedded systems and scientific computing.
Yes and Python is fast enough for many of those. It’s very rare that the speed of Python is an actual bottle neck that cannot be worked around and must be replaced in lieu of its effectiveness
No it's not? At least not raw Python. Python calling C, C++ or Fortan could be fast enough but not raw Python.
Python has dynamic, strong typing. C++ has static, weak typing.
Modern Python also has optional static type checking that is already essentially standard for new code.
Modern Python also has optional static type checking that is already essentially standard for new code.
Except with C++ you have a compiler to tell you your code is broken. With Python you have to use MyPy which isn't perfect or write tests with 100% code coverage. I've never seen 100% code coverage...
The C++ compiler and mypy tell you about the same thing: your typing is consistent. Neither is even close to perfect about finding defects.
You have to write unit tests anyway to validate other useful properties about your code. If you’re not close to 100% you’re doing it wrong. Even 100% coverage is a fairly low bar these days.
You have to write unit tests anyway to validate other useful properties about your code. If you’re not close to 100% you’re doing it wrong. Even 100% coverage is a fairly low bar these days.
"C++ is the New Python"... in the finance world. Note that this is an article from efinancialcareers.com - and this article is about how it's popular for high speed trading systems.
Rust is the new, improved C++.
Rust is being added to the Linux kernel and is making inroads in domains where C and C++ have historically been used. It can match (and sometimes exceed) the performance of C and C++ but with better memory safety and sound concurrency.
C++ won't go away anytime soon, but it's practically disingenuous to call C++ "the new Python".
Rust is being added to the Linux kernel and is making inroads in domains where C and C++ have historically been used. It can match (and sometimes exceed) the performance of C and C++ but with better memory safety and sound concurrency.
C++ won't go away anytime soon, but it's practically disingenuous to call C++ "the new Python".
Yeah Rust will mostly kill c++ overtime. I know people keep talking about modern c++ and the language has certainly improved, but it’s nowhere near the productivity of Rust.
With how slow the c++ community moves and how much debt they have I think it’s game over in most arenas
With how slow the c++ community moves and how much debt they have I think it’s game over in most arenas
Exactly the same thing was being said about Java (the first of the C++ killers) back in 1990s. And yet C++ is still around. It is not that easy to kill it seems.
Java did kill most of the C++ usage.
The overall use of the language grew because everything in IT grew a lot during that time, so the niches where Java sucks grew larger than all of the C++ niches at the start.
The real question is if Rust will leave any niche. It looks like it won't, but this is not the kind of question one can really answer.
The overall use of the language grew because everything in IT grew a lot during that time, so the niches where Java sucks grew larger than all of the C++ niches at the start.
The real question is if Rust will leave any niche. It looks like it won't, but this is not the kind of question one can really answer.
Java did replace a lot of c++ and Rust will replace a lot more for low latency applications
Java did replace C++ in many domains, but not all simply because the JVM requires more overhead than C++.
The trade-off was more overhead, but faster development and fewer errors due to not needing to manage memory or other low-level details.
Java is easier to write than C++ and is more portable than C++, but needs more time to get fast and more memory to work with.
By way of comparison, Rust offers all of the speed of C++ and similar low overhead with practically none of the footguns that C++ is known for.
The trade-off was more overhead, but faster development and fewer errors due to not needing to manage memory or other low-level details.
Java is easier to write than C++ and is more portable than C++, but needs more time to get fast and more memory to work with.
By way of comparison, Rust offers all of the speed of C++ and similar low overhead with practically none of the footguns that C++ is known for.
Rust has a steeper learning curve than C++, which offers a on-ramp from C
Huh? Not with anyone I know
[deleted]
Is rust feasible for writing audio applications that are dependent on tight timings, and low latency? E.g a DAW or vst
Why wouldn't it be? There's no forced GC, you can have custom application in arenas, etc. Pretty much all tricks used for low latency are available.
If I'm not mistaken, the entire audio stack in Google's upcoming Fuscia project is being written in Rust, as well as some components of the modern Android stack (specifically the wireless stuff, but don't quote me on that).
I'd thought that one of the biggest advantages of python is that 'non' programmers can use it. All the math majors and data scientists love it and aren't interested in learning C++ . As much as I love C++ I wouldn't trust anyone to write it after a Udemy course and "Learn C++ in 30 days".
Longer term, I'd say Julia is more likely to compete with Python than C++:
* Julia is now at the point that it can be used for interactive development and experimentation without time-to-compile issues;
* the Julia ecosystem is coming along nicely; and
* Julia has always provided near-C performance in production.
* Julia is now at the point that it can be used for interactive development and experimentation without time-to-compile issues;
* the Julia ecosystem is coming along nicely; and
* Julia has always provided near-C performance in production.
Interesting. Numpy within python does give near native speeds for number crunching though does it not? Copying around arrays does feel like an area where python suffers, however.
For me, Python's killer feature is the interactivity. If I can't figure out how to do something in Bash, or if I need to do some math, I just start the Python interpreter
C++ has Cling (terrible name): https://blog.llvm.org/posts/2020-11-30-interactive-cpp-with-...
It's how I do everything now. I need the instant gratification so I pull up ptpython and just start writing line by line. The other way is to use something like fswatch and have the file I'm working on (a small snippet or one function of the larger code base) instantly run after I type :w. I do this with go and node.
Though they may seem more similar in syntax now that python is introducing faux static typing, C++ is definitely not "the new python" imo. The tooling around C++ is still a maze of its own, it doesn't have a proper packaging system, STL errors are still an unreadable mess in gcc (clang does a better job), and you probably won't be using the new syntax in mid-sized and larger companies.
If I have to whip something up quickly, python nearly looks like the pseudo-code your would write on your paper napkin, while C++ will make you battle with pointers, references, and static typing first. For a larger project, you're better off with Rust, Go, or pretty much anything else.
If I have to whip something up quickly, python nearly looks like the pseudo-code your would write on your paper napkin, while C++ will make you battle with pointers, references, and static typing first. For a larger project, you're better off with Rust, Go, or pretty much anything else.
TBH, the only reason I switched from C to Python was because I didn't know how to implement std::vector<type> and std::hash_map<type, type> in C at the time (1995), and GNU C++ didn't support templates.
The site talks so much about C++ in finance that makes it look more like the new COBOL.
Besides, for high-frequency transactions I think there are better alternatives (e.g.:Rust).
Edit: this is a subjective impression, not a statement of a fact. Please feel free to disagree.
Besides, for high-frequency transactions I think there are better alternatives (e.g.:Rust).
Edit: this is a subjective impression, not a statement of a fact. Please feel free to disagree.
Please try to elaborate a bit more than the usual "Rust is a better C++". Do you know of any people in the industry using Rust? Do you know of any successful transition from C++ to Rust? What were the easy part? What were the pain points?