If you want to stay in Fintech, I really don't see anything beyond Java, C#, C++, TypeScript (for the Web stuff).

Some Fintech companies might go a bit outside the norm and allow for Haskell, F#, Scala, which they tend to use as DSLs for some workflows.

Then if you into array languages, banking and fintech is one fo the few domains where that have managed to stay around, but those positions seem hard to get.

Dyalog (APL), J, BQN, Kdb+ (Q)

https://www.arraycast.com/resources

I work in Fintech, and we use Python with type checking. It works like a charm. Safer than Java.

It's been years since typing was added to Python, and many people still underestimate it. You're right; Python with strict type hints is more type-safe than Java and Go. It even has features like pattern matching and proper enums, both of which Go lacks.

The only issue is that some libraries (not many!) are still untyped, so you may need to write wrappers or stubs occasionally. But that applies to a small and decreasing minority of libraries.

I only wish Python were faster and had ahead-of-time binary compilation.

You should give Julia a go, can be written completely static if desired (not as static as rust of course, but compared to python it’s miles ahead). Can be made fast, very fast. AOT compilation with trimmed executables is coming in 1.12

Doesn't Julia suffer from very long startup times? One of the things I use Python for is CLI programs. The startup time isn't great either, but Julia was even worse last I tested.

Julia v1.12, the unreleased version which is currently in release candidate stage (and has had a longer RC stage than expected but should be done at least by the end of the year) has the ability to fully ahead of time compile and generate binaries, like you would expect from a language like C. It also trims these binaries so that they are a reasonable size given the elements of the runtime that are used. Thus for good type-stable code you get callable binaries without JIT overhead, and this leads to a much better CLI experience. It will take a bit of time so that there's more package tooling and support built around this feature, but this is the path a lot of the ecosystem CLI tooling is now going and that will be a pretty dramatic shift in the usability for these kinds of use cases which Julia had traditionally ignored.

aot will help a lot. In cases of simple programs you can also start Julia with no optimizations, which trade off the startup latency for runtime speed.

Python sure is slow. It's not that big a problem most of the time, but once it becomes relevant, it becomes super relevant. The lack of AOT binary compilation also is very annoying.

That was a fun one, being safer than Java.

Since we are at it, faster as well.

Not as fun as still having no null safety in Java.

As if Python was any better in that regard, as dynamic language.

Python with type checking is statically type checked. So yes, Python with type checking is better in that regard. And it's safer than Java because there are more classes of errors that Python with type checking will pick up during static type checking than what the Java compiler will pick up.

If Python with added sugar counts, same goes to Java with added sugar.

Can you name any tool that adds static null safety to Java?

JSpecify does. And the work for adding null restricted types to Java has already started:

https://openjdk.org/jeps/8303099

Thank you for sharing this, I was unaware of this and it does seem very promising. I hope that the JEP gets done soon.

As this is, in fact, tacked on, I guess you don't really get much benefit unless you rewrite all your code with these still non-standard annotations.

It does not seem like pointing JSpecify at a standard spring boot codebase will do anything for you. Whereas pointing Mypy to a standard Python codebase will type hints that conform to the language spec will do something for you, as null safety is not tacked on but baked in for python type hints.

Also, the syntax seems awkward and clunky as heck, but I guess for something as essential as null safety it's worth it.

---

From JSpecify, I found the Checker Framework, which also seems really interesting and seems like it supports checking for more types of annotations than just JSpecify annotations. https://checkerframework.org/

You cannot "point" JSpecify to anything. It is a standard like PEP 484, but much smaller, because everything else is already part of the language standard.

> Whereas pointing Mypy to a standard Python codebase will type hints that conform to the language spec will do something for you, as null safety is not tacked on but baked in for python type hints.

That is if you wrote your code base with type hints, just like if you wrote your codebase with jspecify annotations.

How did you do typing? Was it 'hints', or some other outside option.? It always seemed to me that since it isn't baked in, that it comes down to organizational discipline.

We run mypy with `--strict` mode in CI, which means it only passes if we have type hints and if they are correct, or if we have added `# type: ignore[code]` for places where the errors are reported.

And the type hints and behaviour are specified as part of Python, so it's kind of baked in. It's just that the actual type checker is not part of CPython, though Mypy is considered the reference implementation.

We have quite a large code base and very few `# type: ignore[code]` directives.

Some third party code still has poor type hints, but for the most part it's fine, and we get null safety which you don't get for Java.

SonarQube/Checkstyle/Kotlin/Scala sugar > Mypy sugar

Type hints and their behaviour are part of the Python language. Kotlin and Scala is not Java. I did not know that checkstyle + SonarQube adds static null safety to Java, but I appreciate that you will share a citation that it adds static null safety. I think everyone coding Java should really learn to use this so they don't create null pointer exceptions.

Scala is the best language I've ever used - all the good parts of Typescript and all the good parts of Java or Rust. And fintech is one of the few niches where you might still be able to find a job using it.

We use Scala as well and are very happy with it. We also have a lot of TS, and at this point we are tempted to just switch to using ScalaJS on the frontend as well because of how much better the language is to use. It feels like Scala 3 fixed a lot of issues people had with the language. The IDE tooling isn’t the best, but even then it feels like the IDE tooling for TS breaks all the time once the project is large enough.

> We also have a lot of TS, and at this point we are tempted to just switch to using ScalaJS on the frontend as well because of how much better the language is to use.

I did that and highly recommend it, at least for new projects - not sure that it's worth the effort of porting an existing project, but ScalaJS just works and I found far fewer rough edges than I expected.

How's the tooling story with Scala these days?

I played with it a long time ago and the IDE (eclipse plugin?) was a bit of a mess, sbt was prone to weird issues and lock ups and the compiler was pretty slow.

Very fun language tho!

Some of the folks now work for JetBrains, thus InteliJ is the one with best support.

Then they decided to focus the remaining effort on Scala Metals, which is based on LSP protocol.

In both cases it is alright for Scala 2, there are some rough edges for Scala 3.

The compiler is faster than it was, but not exactly fast. SBT I avoid as much as possible, so can't really speak to that. The eclipse plugin is sadly abandoned, but IntelliJ has pretty good support.

I had this feeling when Kotlin (that took a lot of ideas from Scala)

Intellij tools are great.

Rust is general purpose. You can use it for anything.

But use the best tool for the job. Ecosystem matters. What are you planning to build?

Okay, Rust is general purpose enough...

But is it general audience? (can every Py/PHP/JS/TS/Java/C# dev become productive in it quickly?)

Also: if you want quick (re)compiles on a larger codebase, Rust is not for you.

I would say yes. I have experience teaching Rust to ~20 yo students of Java, and they are able to be productive in Rust within a semester. Your median Java and C# dev should be able to use Rust. Dunno about Python devs.

Sure they can use it, and learn it in a semester.

Also: good you use Rust in teaching!

But I want a fast on-ramp, quick iterations and clean looking code. (and went with Kotlin because of that -- I like Rust more myself, but I have a business to run, so tradeoffs)

I feel the same way and I think that Gleam is best language that fits this criteria. It has the simplicity of Go but the ergonomics of Kotlin.

I really like Gleam. But if you want a job, that’s probably the worst choice ever. The language is just a few years old and lack libraries for mostly everything. Why are people recommending that here, do you guys work using Gleam??

Let’s be honest , your realistic options for work are Java, C#, C++, and depending on the industry, Swift, Go, Kotlin, Dart and Rust.

Being able to talk passionately and with experience about "exotic" languages during an interview will help you land the job.

I will hire the one that talks about the joy of FP and/or static typing ANYDAY over the programmer with only JS experience an no visible interest to look beyond.

I work in Gleam on my software and it's a treat. I use the FFI for JS libraries all the time.

Take a page from janestreet's book: use ocaml.

Rust is also a general purpose language, there's no reason you can't use it for just about any problem space.

I tried ocaml last year (I knew some Haskell and Scala already) and it was hell. The language itself was pretty, that's true. But the schism between Ocaml's stdlib and Jane Street's core lib was incredibly frustrating.

I guess when you're working at Jane Street, use only their core lib and you get some proper onboarding, things could work great. However you're programming very much in a niche community then.

Java is maturing into a syntactically nice language, albeit slowly, and it's the backbone of many medium and large companies.

You might have trouble finding small companies using anything but JS/Ruby/Python. These companies align more with velocity and cost of engineering, and not so much with performance. That's probably why the volume of interpreted languages is greater than that of "enterprisey" or "performance" languages.

Aren't a lot of those Java employers stuck on an old version of the language, one that's lacking most of those nice features?

A lot are, but there is an equal amount that are of modern versions. It’s a big landscape of employers. I’ve already begun moving my team to Java 25 from 21.

less and less, with the new release cycles.

What you get is either really old (Java 8 stuck on something nasty like weblogic).

Or companies running either cutting edge or LTS.

> Java is maturing into a syntactically nice language, albeit slowly, and it's the backbone of many medium and large companies.

I've heard about Java initiatives to improve it, but can you point to examples of how how Java "is maturing into a syntactically nice language"?

I'm tempted to learn it, but wonder whether it would really become nice enough to become a 'go-to' language (over TS in my case)

I've always felt it was verbose and the need for classes for everything was a bit of a overkill in 90% of circumstances (we're even seeing a pushback against OOP these days).

Here are some actual improvements:

- Record classes

public record Point(int x, int y) { }

- Record patterns

record Person(String name, int age) { }

if (obj instanceof Person(String name, int age)) { System.out.println(name + " is " + age); }

- No longer needing to import base Java types - Automatic casting

if (obj instanceof String s) { // use s directly }

Don't get me wrong, I still find some aspects of the language frustrating:

- all pointers are nullable with support from annotation to lessen the pain

- the use of builder class functions (instead of named parameters like in other languages)

- having to define a type for everything (probably the best part of TS is inlining type declarations!)

But these are minor gripes

It has virtual threads, that under most circumstances let you get away from the async model. It has records, that are data-first immutable classes, that can be defined in a single line, with sane equals toString and hash. It has sealed classes as well, the latter two giving you product and sum types, with proper pattern matching.

Also, a very wide-reaching standard library, good enough type system, and possibly the most advanced runtime with very good tooling.

There are some interesting talks and slide decks that I have to search around to find. Here is one: https://speakerdeck.com/bazlur_rahman/breaking-java-stereoty...

Check jbang.dev, and then talks by its author Max Rydahl Andersen. That could be a starting point.

Python with Pyright in strict mode. I work on a ~200kLOC fully typed Python project [0] and am having fun.

[0]: https://github.com/xdslproject/xdsl

Have you worked with TypeScript? I’m working with both every day and I’m always frustrated by the limits of the 'type' system in Python- sure it’s better than nothing but it’s so basic compared to what you can do in TypeScript. It’s very easy to use advanced generics in TypeScript but a hell to do (sometimes outright impossible) in Python.

Yep, although never in a project of a similar size. One advantage of the Python setup is that the types are ignored at runtime, so there's no overhead at startup/compilation time. Although it's also a disadvantage in terms of what you can do in the system, of course.

Deno and latest versions of Nodejs run TS code without transpilation

I agree it is pretty nice (with uv and as long as you REALLY don't care about performance). But even if you are one of the enlightened few to use that setup, you still have to deal with dependencies that don't have type annotations, or only basic ones like `dict`.

Typescript (via Deno) is still a better option IMO.

Nim is a statically typed language with a syntax resembling Python's. https://nim-lang.org/

Sometimes I'm questioning if it has the potential to become more popular in the future if AI becomes adept at translating Python projects to Nim.

IM[EO], the std library and system interfaces are complete obscure made-up trash. The language was fine and tooling is nice, but I decided I'll neveer try to use nim again.

Zig, otoh might be worth another look.

You should try ReScript. The language has improved a lot recently. If Typescript is javascript with types bolted on then ReScript is javascript redesigned the proper way. The lsp is also surprisingly good. All that while still being in the node eco system.

You could try Crystal if you like the other parts of Ruby. But you probably ain't going to find a job writing it anytime soon.

You may want to look into Crystal.

+1 for Crystal, it's a fantastic language and the community is great (on the official forum).

> - Typescript was limited by its option to allow non strictness

That's 100% a project setting you can turn on or off though, it's like -Wall in C++ projects.

I'm also a back-end dev who's worked in fintech and IME, TypeScript is a great choice.

From my experience with python, none of its type checking libraries are complete enough.

>That's 100% a project setting you can turn on or off though, it's like -Wall in C++ projects.

I know, it’s just not realistically up to me. I depend on the team/company culture which I’d rather not have in the picture - I’ve already gone through trying to fight the sea of unknown/any.

I have the same dilemma: a strongly typed / modern language with good tooling / library support. I'm also considering Kotlin / Gleam. With Kotlin, practically speaking, we're talking JVM again, along with its resource requirements.

C# is the right answer here.

What's wrong with Java? It's used everywhere from FinTech startups to banks/insurers, with features like decimal arithmetic introduced specially for finance a long time ago, multiple runtimes (Oracle/JVM, IBM T9, GraalVM), a very healthy ecosystem of libs/packages, etc.

>What's wrong with Java? It's used everywhere from FinTech startups to banks/insurers

As the OP, it’s not even the language for me but the implications of companies that use it.

It’s a non starter for startup/scaleups and strongly related with oldish companies and consulting firms, which in turn translates to far worse working conditions (not remote friendly, overtime, dress code, etc).

Mind that it might just be a local culture thing, your mileage may vary.

I usually ask at interviews what version of Java they are using. If they are on >8 of >11, then that's a pretty good green flag.

And it's a non-starter for startups, because it's not hyped enough, not for a technical reason.

Many of them would be way better off with a standard traditional Spring app.

My startup switched from python to Java and saw our productivity explode. Using modern Java versions in a non enterprise way (no frameworks, minimal oop, minimal DI, functional features like immutable objects, optional, etc) is quite nice. Our ability to deliver performant and working features was orders of magnitude faster than python. The ecosystem of libraries is crazy deep which also helps build quickly.

I won’t deny there’s a lot of bad Java written, but IMO it’s actually one of the best languages for a startup if any of your code needs good performance.

100%. Java has an amazing standard library, amazing IDE support, AOT compilation, JIT optimizations, static typing, runs much faster generally, and supports multi-threading... seems like a no-brainer to me.

If you have very good developers, go with whatever they feel most efficient with, (as long as there are enough libraries). But if you’re planning on getting big, do add a transition to stabler tech like Java, C#. They’re boring tech and full of guardrails. Which is what you want when performance is not your main concern.

> It’s a non starter for startup/scaleups and strongly related with oldish companies and consulting firms, which in turn translates to far worse working conditions (not remote friendly, overtime, dress code, etc).

mkay

Answer the question.

Maven and Gradle suck.

Julia https://www.reddit.com/r/Julia/comments/1efxp0j/julias_advan...

C++ of course. Backend and Fintech.

Have you really been using Node or even Typescript as backend dev in fintech? After 15 years in fintech I have never heard anything like that. For the backend it's mostly Java with some sprinkles of C#, Cobol or Python.

Yup, the previous company I used to work for just had a successful exit last year too. I guess it was an iteration speed thing, though as you say python is becoming popular as well and IMO it is not anymore suited to finance than node is, other than the connection with data science.

Do you think those languages are scratching the itch? If not maybe we need to pick a suitable underdog and champion its use. Clojure comes to mind. Or Unison. Something where immutability shines.

Moonbit lang is currently the best language I've seen (not a joke).

Thank you for this, I just checked it out and it looks really great

I do like Swift but it also suffers a bit from identity crisis. The compiler experience is quite disappointing too—I found myself helping the compiler more than the compiler helped me.

I've since moved to Rust and have not looked back. Importantly, rust-analyzer runs circles around the Swift VSCode plugin (or Xcode for that matter)

The identitiy is clear, it is a language first and foremost for Apple ecosystems.

It also needs to target GNU/Linux, because Apple got rid of their server offerings, thus anyone doing server code for applications on the Apple ecosystem, that wants to stay in a single language needs to be able to write such software on GNU/Linux with Swift.

Windows well, since they have the open source story, it kind of falls from there as complement.

On the revamped website they are quite clear about the identity.

Cloud Services, CLI and Embedded as the main targets for the open source version.

Have you tried it since 6.2 came out with approachable concurrency enabled? The compiler is quite useful.

No, I think I stopped using it in 5-something. Will try to play with it again to see how it feels these days, thank you.

Though I must admit it's hard for me to imagine using anything other than Rust for 90% of projects.

I'm the same but opposite, I like Rust but find myself using Swift most of the time. They sort of do the same thing but coming from opposite directions. Can't go wrong with either imo.

I really do wanna try Kotlin at some point as well. Rust, Kotlin, and Swift feel like the future of languages to me.

If OP wants to run on Windows, Swift is a non-starter. It barely runs there.

Fintech should have lots of C++ jobs no? They also seem to use ML languages like OCaml and Haskell more than the average industry...

More Java than C++ in my opinion. And, get this, JS! We shall see how far OpenFin will actually go in that space because they will potentially drive a ton of JS across orgs in finance

D?

Kotlin!

Gleam?