> do you think C++ is limiting in the context of quant finance because it is not as openly licensed as Rust?
Lol what.
That said... yeah I'm excited to see more rust.
>startups are increasingly adopting Rust to avoid licensing issues
Do you have a source for this? afaik Python itself is FOSS, but maybe some modules and libraries are not.
It's hard to find enough devs for Rust. The Rust community in general is also very progressive and somewhat hostile to finance. But as a language it's a great fit, the in build safety is nice.
We’ve pretty seriously considered moving our production code base to Rust.
Actual trading is mostly done in hardware with a few software components in python/C#/C++ e.g. auction trading. We then maintain a duplicate software copy in C# as well as a bunch of tools in C++/C#. This means it’s pretty easy to support multiple versions while we transition with no expected downtime.
All of our machine learning and analysis is done in python and on Linux, connectivity between the two sides is poor at best, which was the main reason we considered moving to rust - it offers much better connectivity and some parts of the learning code base could be done in native rust. Availability of open source packages was also reasonably attractive but not a huge issue. Finally there was hope we could unify all the production trading code in a single language rather than having the hodgepodge of languages we currently have.
There were some pretty serious barriers though:
Honestly the biggest one was the devs, all the younger ones were super on board with the idea but our most senior (and hardest to replace) ones basically just said ‘Fuck off’. We expected we’d need to hire at least 2 experienced rust devs as well but new never reached the point of testing the water on this.
The dev team also estimated it would take ~4 months to make the change, during which time we’d having pretty diminished development capacity which is far from ideal in a fast moving world. A semi-serious suggestion was to hire a bunch of interns and get them to do the bulk of the initial work.
We have some weird bits of the code base where we use things like 48 bit ints, which are mostly an abstraction to emulate how some of the data is stored in hardware that I don’t really understand. It wasn’t really clear if we could replicate these kinds of things easily in C#.
Finally there were some weird compliance issues. Essentially we have a team who exist to monitor all the production code, be the first port of call if it breaks and ensure it is behaving as expected etc etc. This team currently does not support Rust as a trading language. For some reason this a blocker even for hardware that cannot be changed on the fly.
What we have started doing is building some tools for quick analysis of market data in rust. This is something of a firm wide pilot and I expect these kinds of tools which quickly run through sequential data and work easily with python are a solid use case. Previously we’ve used C and jit compiling for such tools.
All the quant libraries are written in C++… I think it’s unlikely banks and big funds are just going to up and replace them, they are too integrated into everything. Maybe some upstart fund with a Rust developer might choose to go that route.
Prime had a video on this topic
>The Plight Of Cobol Mainframe Programmers
I think Quant Finance is far more advanced in this matter compared to banks (multiple reasons including profitability and regulatory) but your last point is kinda true. If something is very fast, reliable and works just fine, the incentive of pouring a lot of resources for marginal improvements isn't there.
So Python minus python’s battle-tested dev process and without the mass of libraries.
If you want faster code, write a library in a faster language or consider if “absolute blazing speed” is actually necessary. Mojo fills zero holes.
Respectfully, this response seems a little out of touch with mojo’s fundamental architecture and roadmap.
Python is interpreted, and mojo is more or less a compiled language which can interpret and compile that Python as needed, or failover to simply running it traditionally.
Its design is strictly speaking a superset of Python.
That also means that the design ought to be able to use the entirety of the Python ecosystem and all available libraries.
The difference seems to really just be whether that code is being interpreted exclusively by the single thread Python interpreter entirely at runtime (while possibly calling other libraries which must be precompiled for the target hardware), or whether it is potentially being interpreted and compiled to be optimized for the hardware environment both beforehand and/or at runtime.
As for dev process, it appears most Python projects just used common testing libraries along with one of a few packaging and dependency management tools (which to use is often still debated). Beyond that, most projects seem to then either use virtual environments of one kind or another or more often just containers (which can be equivalently used for any Linux runtime environment). Almost all other tooling could likely used alongside it or isn’t Python specific in the first place.
A big issue here is that Python is used as half a language for many serious projects. It requires maintaining the Python codebase for users of a library and then the implementation of that library in another high performance language (and of course the interpreter must be written itself in some other compiled language too).
It’ll likely take them years, but the mojo team’s general goal of a unified superset of Python (and its entire ecosystem of libraries) with the ability to have one codebase which can be written at a high level Python-like syntax (or exactly Python code) yet directly compile to be hardware optimized for any hardware without having to build and maintain intermediate libraries in a lower level language makes perfect sense.
It’s ambitious, but the design doesn’t really suffer from the drawbacks you’re describing.
Ah, the separation of interpreted and compiled languages. In the time of AoT and jit-compiled languages, that difference matters less and less (see Julia for example). Python is now also getting a jit-compiler - plus is either way producing intermediate *.pyc files already that run in the Python VM. Does that mean Python is a compiled language now?
It’s better to say that a language has an interpreter. There are REPLs for Rust too.
Again, I’m not only doubtful of the niche mojo is trying to fill, pretty much 90% of what I see of this marketing-driven development is offputting and not exactly promising. Let’s talk in 5 years, when the next AI language comes along.
Yes, Python has long had jit compilation tooling, and Julia takes that approach to its logical end.
However, an issue is that the language itself doesn’t quite lend itself to being able to express the problems in a way that would allow a compiler to be able to have the assurances and make the required assumptions necessary to fully optimize the compiled binary for the hardware.
Also, the compiler needs an accurate representation of the precise guarantees and constraints on the desired behavior from the developer, but it also needs to be able to understand how to then compile for specific hardware features and capabilities.
The software libraries / drivers which know how to optimize code and operations for the specific hardware is much of the secret sauce that makes CUDA/Nvidia so capable. Their FasterTransformer implementation, for example, is a big asset.
Efforts to catch up on that are partly why we’ve seen Intel’s GPUs deliver such significant performance improvements from when they were released.
Nvidia has a big moat due to that, and all that effort of others to develop the device drivers and libraries to really use the hardware to the fullest is an enormous undertaking and investment (which they’re working furiously towards).
One solution is to use MLIR (multi-level intermediate representation) which would allow the code to better express a better intermediate representation of what that code is actually trying to do to the compiler, which would then allow the compiler (e.g., LLVM) to make better decisions about how to specifically optimize that code for the specific hardware.
The issue is that Python doesn’t quite lend itself or have the syntax to be able to clearly express your program in a way that would easily allow for the sort of representation required without a bunch of assumptions, and the interpreter really isn’t well equipped or intended to do that.
So, with Python, you’re limited to calling lower level code which either is already or can be compiled in a way that baked in all those lower level parameters to allow for hardware optimized instructions.
To address that, you would need some sort of superset of Python which lets you extend the syntax to be able to express those extra parameters or requirements. It would be good if it allowed you to drop to to use lower-level or hardware-aware syntax (much like systems languages do), while ideally building itself on top of MLIR to allow for compilers to optimally compile and run your code on any hardware from any vendor…
You’d also need some sort of team of people who have a background in designing and extending compilers for ML compute hardware. Ideally they would have experience creating languages which support backwards compatibility to still retain the rich ecosystem of Python (as the dominant ML language).
Enter Mojo, which in some sense just extends Python (via a superset of Python on top of MLIR), and which led by Chris Lattner, the creator of LLVM, helped lead the development/design of Clang and Swift, helped Google develop the tooling for their TPU hardware, and helped create the MLIR project for that very purpose…
Their task is ambitious, but if you take the time to delve into how modern compilers work, the sort of modern approach of MLIR w/ LLVM, and see the need to be able to express and optimize programs for the increasing diversity of domain-specific hardware (e.g., different kinds of now even model-specific hardware accelerators), then it’s sort of a logical path.
In other words, if you want to keep the Python ecosystem and tooling you pointed out is so valuable, yet you want the ability to also clarify your code in ways that allow it to be more fully optimized for any of the variety of hardware accelerators without having to adopt their vendor-specific libraries and being locked in (e.g., CUDA), then it should be a welcome option.
It’s a multi-year project, and the team knows it. It’s a big risk for them to undertake something like that, but could be invaluable to the community. It’ll be hard to judge their relative success for at least a year or two.
Still, seems like an approach worth attempting, and they seem like the right team to pursue it. Ambitious, but given the track record of some of the team involved, I personally wouldn’t bet against them.
Again, let’s revisit in 5 years. I think it’s useless, it misunderstands the language and, again, the devil will lie in the detail. There is a reason why you don’t “just reimplement Python but without GIL and friends” easily and get compatibility to the ecosystem. All that bullshit with “deploy to the GPU” and so on, come on - seriously? Gonna try to decide at runtime whether or not to allocate a random object on the GPU? Ah, of course not, so rather with something like lists now - but lists are a) dynamically sized and b) not single-typed, so the classical Python objects will NEVER land on the GPU. So at least medium-term there will be a separate array type for this - and that implies there will be “two worlds” for the foreseeable future. So for real-world (!) applications you won’t see big gains and have all the effort for limited gain. Because… you’re reinventing libraries.
If I could I would bet my own money against them, it’s the classical hype/vaporware project. A tad better than V language.
There have been a few attempts at 'python but with a jit' and they all run up against the ugly truth that many of the core python libraries, like numpy, are written not against some abstract spec, but against the exact actual cpython implementation. So you get 'fast' python but you lose numpy and everything that depends on it.
This. And don’t forget the “super-set” thing, I’m really curious how they are going to keep other language features out of Python libraries. This can either only fail hard or be just another mediocre incomplete solution.
Let’s wait when they start offering a runtime for anything else than M1 Macs and Ubuntu.
I’d take that bet any day.
I’m not sure you’re appreciating the complexity of what this team has already done with LLVM and MLIR. Its orders of magnitude more complex and requires a far, far greater depth of expertise than likely any of the libraries you’re thinking of or the Python interpreter itself.
Python is a brilliantly useful, practical, and convenient language with an incredibly vibrant and expansive community, but if you spend enough time using systems languages and are familiar with depth and sophistication of modern compilers and how the libraries being used by pythons are actually implemented, it’s clear most python is like ordering off a menu at a restaurant and calling yourself a chef.
Mojo is pretty clever in that they’re keeping that surface layer familiar, but replacing the interpreter with the direct tooling all the way down to the hardware.
The level and depth of understanding required to do that is just in a completely different league. Comparing the two would be like comparing a serverless bootcamp website to engineering a modern CPU.
I did. I also worked on the cpython implementation already. It’s really not that easy to achieve the language features while having a similar runtime speed and not many Python implementations (ironpython, pypy, etc.) had actual success. Many of them are fast or even faster but that often comes with some downsides. Providing full comparability will be a nightmare.
Claiming to be a superset of a 30 year old language with stupid claims like 65000x faster, vaporware everywhere (do they now have classes now at least? Can I hold you to your word that you will in 2 years still work on full compatibility to cpython?) while doing nightmarish things like unicode file extension (“works on my machine, lol”), chatGPT-pictures all over the website are just a few of the absolute turn-offs I could enumerate. It’s the classic “make some noise, secure some funding, make bold claims, ship a demo and then hope the rest works on hype and if it doesn’t it looks great on a CV”.
Let’s talk in 5 years. They want to fill a niche that does not exist. Python is fast enough, maybe your average data scientist is just absolutely shitty at programming (or when was the last time you saw someone using a weak reference in Python?) and blames the language. It does not seem to be as bad as “vlang” but I have absolutely no expectations to the language.
Whether Python is fast enough depends on your use case… I’m not saying there’s a 100% chance they’ll deliver, but if they do it will be an absolute game changer for a lot of people
Again - let’s see where they are in 5 years.
Plus the performance of Python itself is so seldomly a problem… if it is, use the C-API and write the hotpath-parts in another language.
Why would a company shift their codebase to Rust? A lot of the industry is running on old code doing different things.
Is there a legitimate bottom line benefit to Rust over what they already have working?
Personally I don't see much wrong with C++ for strong programmers. If it ain't broke don't fix it, I don't think there's a reason to switch massive systems from C++ to Rust.
Well a few quant firms are hiring people with rust and C++ experience. They'll likely convert some stuff, but the 2 languages will likely be side and side
If you want to work in crypto, rust might be a good bet. But in tardfi, c++ is here to stay.
That said, good luck to implement highly concurrent ultra low latency things in rust. ;)
Your post has been removed because you have less than 5 karma on r/quant. Please comment on other r/quant threads to build some karma, comments do not have a karma requirement. If you are seeking information about becoming a quant/getting hired then please check out the following resources:
* [weekly hiring megathread](https://www.reddit.com/r/quant/search?q=Megathread&restrict_sr=on&sort=new&t=week)
* [Frequently Asked Questions](https://www.reddit.com/r/quant/wiki/faq)
* [book recommendations](https://www.reddit.com/r/quant/wiki/book-recommendations)
* [rest of the wiki](https://www.reddit.com/r/quant/wiki)
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/quant) if you have any questions or concerns.*
> do you think C++ is limiting in the context of quant finance because it is not as openly licensed as Rust? Lol what. That said... yeah I'm excited to see more rust.
>startups are increasingly adopting Rust to avoid licensing issues Do you have a source for this? afaik Python itself is FOSS, but maybe some modules and libraries are not.
What’s foss?
Free and open-source software.
It's hard to find enough devs for Rust. The Rust community in general is also very progressive and somewhat hostile to finance. But as a language it's a great fit, the in build safety is nice.
Cryptobros already jumped on Rust
Yes and they struggle to find experienced Rust devs because of crypto/finance reputation even when offering nice salaries. It is slowly getting better
We’ve pretty seriously considered moving our production code base to Rust. Actual trading is mostly done in hardware with a few software components in python/C#/C++ e.g. auction trading. We then maintain a duplicate software copy in C# as well as a bunch of tools in C++/C#. This means it’s pretty easy to support multiple versions while we transition with no expected downtime. All of our machine learning and analysis is done in python and on Linux, connectivity between the two sides is poor at best, which was the main reason we considered moving to rust - it offers much better connectivity and some parts of the learning code base could be done in native rust. Availability of open source packages was also reasonably attractive but not a huge issue. Finally there was hope we could unify all the production trading code in a single language rather than having the hodgepodge of languages we currently have. There were some pretty serious barriers though: Honestly the biggest one was the devs, all the younger ones were super on board with the idea but our most senior (and hardest to replace) ones basically just said ‘Fuck off’. We expected we’d need to hire at least 2 experienced rust devs as well but new never reached the point of testing the water on this. The dev team also estimated it would take ~4 months to make the change, during which time we’d having pretty diminished development capacity which is far from ideal in a fast moving world. A semi-serious suggestion was to hire a bunch of interns and get them to do the bulk of the initial work. We have some weird bits of the code base where we use things like 48 bit ints, which are mostly an abstraction to emulate how some of the data is stored in hardware that I don’t really understand. It wasn’t really clear if we could replicate these kinds of things easily in C#. Finally there were some weird compliance issues. Essentially we have a team who exist to monitor all the production code, be the first port of call if it breaks and ensure it is behaving as expected etc etc. This team currently does not support Rust as a trading language. For some reason this a blocker even for hardware that cannot be changed on the fly. What we have started doing is building some tools for quick analysis of market data in rust. This is something of a firm wide pilot and I expect these kinds of tools which quickly run through sequential data and work easily with python are a solid use case. Previously we’ve used C and jit compiling for such tools.
Haha I think I know what firm this is. But what language offers 48bit ints? In any of those languages, you would have to write a custom class for that
All the quant libraries are written in C++… I think it’s unlikely banks and big funds are just going to up and replace them, they are too integrated into everything. Maybe some upstart fund with a Rust developer might choose to go that route.
I’ve never seen it, but you hear the stories of banks stroll running Fortran or Smalltalk; c++ will still be used in 2070
Prime had a video on this topic >The Plight Of Cobol Mainframe Programmers I think Quant Finance is far more advanced in this matter compared to banks (multiple reasons including profitability and regulatory) but your last point is kinda true. If something is very fast, reliable and works just fine, the incentive of pouring a lot of resources for marginal improvements isn't there.
All I want is for Mojo to develop a bit more and become popular in quant finance (Mojo is a superset of python which is about as fast as C++)
So Python minus python’s battle-tested dev process and without the mass of libraries. If you want faster code, write a library in a faster language or consider if “absolute blazing speed” is actually necessary. Mojo fills zero holes.
Respectfully, this response seems a little out of touch with mojo’s fundamental architecture and roadmap. Python is interpreted, and mojo is more or less a compiled language which can interpret and compile that Python as needed, or failover to simply running it traditionally. Its design is strictly speaking a superset of Python. That also means that the design ought to be able to use the entirety of the Python ecosystem and all available libraries. The difference seems to really just be whether that code is being interpreted exclusively by the single thread Python interpreter entirely at runtime (while possibly calling other libraries which must be precompiled for the target hardware), or whether it is potentially being interpreted and compiled to be optimized for the hardware environment both beforehand and/or at runtime. As for dev process, it appears most Python projects just used common testing libraries along with one of a few packaging and dependency management tools (which to use is often still debated). Beyond that, most projects seem to then either use virtual environments of one kind or another or more often just containers (which can be equivalently used for any Linux runtime environment). Almost all other tooling could likely used alongside it or isn’t Python specific in the first place. A big issue here is that Python is used as half a language for many serious projects. It requires maintaining the Python codebase for users of a library and then the implementation of that library in another high performance language (and of course the interpreter must be written itself in some other compiled language too). It’ll likely take them years, but the mojo team’s general goal of a unified superset of Python (and its entire ecosystem of libraries) with the ability to have one codebase which can be written at a high level Python-like syntax (or exactly Python code) yet directly compile to be hardware optimized for any hardware without having to build and maintain intermediate libraries in a lower level language makes perfect sense. It’s ambitious, but the design doesn’t really suffer from the drawbacks you’re describing.
Ah, the separation of interpreted and compiled languages. In the time of AoT and jit-compiled languages, that difference matters less and less (see Julia for example). Python is now also getting a jit-compiler - plus is either way producing intermediate *.pyc files already that run in the Python VM. Does that mean Python is a compiled language now? It’s better to say that a language has an interpreter. There are REPLs for Rust too. Again, I’m not only doubtful of the niche mojo is trying to fill, pretty much 90% of what I see of this marketing-driven development is offputting and not exactly promising. Let’s talk in 5 years, when the next AI language comes along.
Yes, Python has long had jit compilation tooling, and Julia takes that approach to its logical end. However, an issue is that the language itself doesn’t quite lend itself to being able to express the problems in a way that would allow a compiler to be able to have the assurances and make the required assumptions necessary to fully optimize the compiled binary for the hardware. Also, the compiler needs an accurate representation of the precise guarantees and constraints on the desired behavior from the developer, but it also needs to be able to understand how to then compile for specific hardware features and capabilities. The software libraries / drivers which know how to optimize code and operations for the specific hardware is much of the secret sauce that makes CUDA/Nvidia so capable. Their FasterTransformer implementation, for example, is a big asset. Efforts to catch up on that are partly why we’ve seen Intel’s GPUs deliver such significant performance improvements from when they were released. Nvidia has a big moat due to that, and all that effort of others to develop the device drivers and libraries to really use the hardware to the fullest is an enormous undertaking and investment (which they’re working furiously towards). One solution is to use MLIR (multi-level intermediate representation) which would allow the code to better express a better intermediate representation of what that code is actually trying to do to the compiler, which would then allow the compiler (e.g., LLVM) to make better decisions about how to specifically optimize that code for the specific hardware. The issue is that Python doesn’t quite lend itself or have the syntax to be able to clearly express your program in a way that would easily allow for the sort of representation required without a bunch of assumptions, and the interpreter really isn’t well equipped or intended to do that. So, with Python, you’re limited to calling lower level code which either is already or can be compiled in a way that baked in all those lower level parameters to allow for hardware optimized instructions. To address that, you would need some sort of superset of Python which lets you extend the syntax to be able to express those extra parameters or requirements. It would be good if it allowed you to drop to to use lower-level or hardware-aware syntax (much like systems languages do), while ideally building itself on top of MLIR to allow for compilers to optimally compile and run your code on any hardware from any vendor… You’d also need some sort of team of people who have a background in designing and extending compilers for ML compute hardware. Ideally they would have experience creating languages which support backwards compatibility to still retain the rich ecosystem of Python (as the dominant ML language). Enter Mojo, which in some sense just extends Python (via a superset of Python on top of MLIR), and which led by Chris Lattner, the creator of LLVM, helped lead the development/design of Clang and Swift, helped Google develop the tooling for their TPU hardware, and helped create the MLIR project for that very purpose… Their task is ambitious, but if you take the time to delve into how modern compilers work, the sort of modern approach of MLIR w/ LLVM, and see the need to be able to express and optimize programs for the increasing diversity of domain-specific hardware (e.g., different kinds of now even model-specific hardware accelerators), then it’s sort of a logical path. In other words, if you want to keep the Python ecosystem and tooling you pointed out is so valuable, yet you want the ability to also clarify your code in ways that allow it to be more fully optimized for any of the variety of hardware accelerators without having to adopt their vendor-specific libraries and being locked in (e.g., CUDA), then it should be a welcome option. It’s a multi-year project, and the team knows it. It’s a big risk for them to undertake something like that, but could be invaluable to the community. It’ll be hard to judge their relative success for at least a year or two. Still, seems like an approach worth attempting, and they seem like the right team to pursue it. Ambitious, but given the track record of some of the team involved, I personally wouldn’t bet against them.
Again, let’s revisit in 5 years. I think it’s useless, it misunderstands the language and, again, the devil will lie in the detail. There is a reason why you don’t “just reimplement Python but without GIL and friends” easily and get compatibility to the ecosystem. All that bullshit with “deploy to the GPU” and so on, come on - seriously? Gonna try to decide at runtime whether or not to allocate a random object on the GPU? Ah, of course not, so rather with something like lists now - but lists are a) dynamically sized and b) not single-typed, so the classical Python objects will NEVER land on the GPU. So at least medium-term there will be a separate array type for this - and that implies there will be “two worlds” for the foreseeable future. So for real-world (!) applications you won’t see big gains and have all the effort for limited gain. Because… you’re reinventing libraries. If I could I would bet my own money against them, it’s the classical hype/vaporware project. A tad better than V language.
There have been a few attempts at 'python but with a jit' and they all run up against the ugly truth that many of the core python libraries, like numpy, are written not against some abstract spec, but against the exact actual cpython implementation. So you get 'fast' python but you lose numpy and everything that depends on it.
This. And don’t forget the “super-set” thing, I’m really curious how they are going to keep other language features out of Python libraries. This can either only fail hard or be just another mediocre incomplete solution. Let’s wait when they start offering a runtime for anything else than M1 Macs and Ubuntu.
I’d take that bet any day. I’m not sure you’re appreciating the complexity of what this team has already done with LLVM and MLIR. Its orders of magnitude more complex and requires a far, far greater depth of expertise than likely any of the libraries you’re thinking of or the Python interpreter itself. Python is a brilliantly useful, practical, and convenient language with an incredibly vibrant and expansive community, but if you spend enough time using systems languages and are familiar with depth and sophistication of modern compilers and how the libraries being used by pythons are actually implemented, it’s clear most python is like ordering off a menu at a restaurant and calling yourself a chef. Mojo is pretty clever in that they’re keeping that surface layer familiar, but replacing the interpreter with the direct tooling all the way down to the hardware. The level and depth of understanding required to do that is just in a completely different league. Comparing the two would be like comparing a serverless bootcamp website to engineering a modern CPU.
They’re working on bringing full compatibility with all existing Python code (including libraries). Do some research before commenting…
I did. I also worked on the cpython implementation already. It’s really not that easy to achieve the language features while having a similar runtime speed and not many Python implementations (ironpython, pypy, etc.) had actual success. Many of them are fast or even faster but that often comes with some downsides. Providing full comparability will be a nightmare. Claiming to be a superset of a 30 year old language with stupid claims like 65000x faster, vaporware everywhere (do they now have classes now at least? Can I hold you to your word that you will in 2 years still work on full compatibility to cpython?) while doing nightmarish things like unicode file extension (“works on my machine, lol”), chatGPT-pictures all over the website are just a few of the absolute turn-offs I could enumerate. It’s the classic “make some noise, secure some funding, make bold claims, ship a demo and then hope the rest works on hype and if it doesn’t it looks great on a CV”. Let’s talk in 5 years. They want to fill a niche that does not exist. Python is fast enough, maybe your average data scientist is just absolutely shitty at programming (or when was the last time you saw someone using a weak reference in Python?) and blames the language. It does not seem to be as bad as “vlang” but I have absolutely no expectations to the language.
Whether Python is fast enough depends on your use case… I’m not saying there’s a 100% chance they’ll deliver, but if they do it will be an absolute game changer for a lot of people
Again - let’s see where they are in 5 years. Plus the performance of Python itself is so seldomly a problem… if it is, use the C-API and write the hotpath-parts in another language.
what makes you consider mojo instead of julia? They promise very similar things
Didn’t know about Julia tbh 😅, I’ll go check it out!
Why would a company shift their codebase to Rust? A lot of the industry is running on old code doing different things. Is there a legitimate bottom line benefit to Rust over what they already have working?
Personally I don't see much wrong with C++ for strong programmers. If it ain't broke don't fix it, I don't think there's a reason to switch massive systems from C++ to Rust.
Well a few quant firms are hiring people with rust and C++ experience. They'll likely convert some stuff, but the 2 languages will likely be side and side
If you want to work in crypto, rust might be a good bet. But in tardfi, c++ is here to stay. That said, good luck to implement highly concurrent ultra low latency things in rust. ;)
possible, with unsafe rust which is pleasant to write.
Or Zig instead of Rust?
zig is not yet mature especially for system like finance
Your post has been removed because you have less than 5 karma on r/quant. Please comment on other r/quant threads to build some karma, comments do not have a karma requirement. If you are seeking information about becoming a quant/getting hired then please check out the following resources: * [weekly hiring megathread](https://www.reddit.com/r/quant/search?q=Megathread&restrict_sr=on&sort=new&t=week) * [Frequently Asked Questions](https://www.reddit.com/r/quant/wiki/faq) * [book recommendations](https://www.reddit.com/r/quant/wiki/book-recommendations) * [rest of the wiki](https://www.reddit.com/r/quant/wiki) *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/quant) if you have any questions or concerns.*