It’s possible (even true in my opinion) that garbage collected functional languages and low level languages like Zig are both great, and serve different purposes.
I actually ship stuff in Haskell believe it or not. I also think Zig is very cool and have played around with it quite a bit. Yes, garbage collection hurts performance, but the reality is that the overwhelming majority of all software does not suffer from the performance loss between well written code in a reasonably performant functional gc language and a highly performant language with manual memory management. It’s just not important. But not having to deal with the cognitive overhead of managing memory and being able to deal in domain specific abstractions only is a massive win for developer productivity and code base simplicity and correctness.
I think OxCamls approach of opting in to more direct control of performance is interesting. I also think it’s great that many functional patterns are making their way into imperative first languages. Language selection is always about trades offs for your specific use case. My team writes Haskell instead of Rust because Haskell is plenty fast for our use case and we don’t have to write lifetime annotations everywhere and think about borrowing. If we needed more performance we would have no choice but to explore other languages and sacrifice some developer experience and productivity, that’s very reasonable. I’m also not saying performance doesn’t matter (if you’re writing for loops in Python, stop). But this read to me like “because better performance exits with manual memory management, all garbage collectors are bad, so I’ll force zig to be something it’s not in order to gain performance I probably don’t need”. Which to me is an odd take. A more measured way of thinking about this might be, it can be useful to leverage functional patterns where appropriate in low level languages, if you find yourself needing to write code in one.
This. It's valuable b/c if you have many thousands of python devs using astral tooling all day, and it tightly integrates with subscription based openai products...likelihood of openai product usage increases. Same idea with the anthropic bun deal. Remains to be seen what those integrations are and if it translates to more subs, but that's the current thesis. Buy user base -> cram our ai tool into the workflow of that user base.
I am a strategist at a smallish boutique quant investment firm. This is how we think about hiring a junior person. It's not all that different for a more senior person, but actual development experience would likely be more important, we would expect more contribution sooner from a more experienced person. More senior jobs also might have more specific responsibilities and therefore require more specific knowledge of technologies, etc. Many junior analyst roles support the team as a whole and there is less concern around experience with specific technologies, typically.
When we hire a junior person we are interested in math background, ability to communicate real world value of various models to our investment process and familiarity with computer science and software engineering concepts more than we care about experience with specific languages or technologies. That being said, C++ does still dominate this space so having exposure to it certainly would not hurt.
I work in quantitative finance and have wanted to to start using OCaml at work for years. I just find that unless you are at a shop like Jane Street with a well developed proprietary code base, internally developed tooling, etc, there just isn't the ecosystem available for me to be nearly as productive as I can be in other well accepted languages in the quant dev space...which is a bummer. It's been a little while since the last time I investigated this though.