[miki123211]

I wish we had a language that had the syntax of Python (notably including operator overloading, which is absolutely critical for neural networks, ML, data science and numerical computations), the performance, compile times and concurrency support of Go, the type system flexibility of Typescript, and the native platform integration of C/C++.

[AyanamiKaine]

Than you would probably like the Nim[1] programming language. It has the syntax of python, but transpiles to C/C++. A good type system. The main problem would probably the compiles times. Because you basically compile just C/C++ code. And of course the eco-system is much much smaller than Python.

[1] https://nim-lang.org/

[cb321]

Nim compile+link times can be sub-100 milliseconds with tcc [1] (just saw 93 ms on my laptop) which can yield pretty reasonable edit-compile-test cycles.

The grandparent's scientific/Go interests suggests a need for a large, working ecosystem and there are probably several places in ArrayMancer which need some love for "fallback cases" to work with tcc (or elsewhere in the as you note much smaller Nim eco-system).

EDIT: E.g., for ArrayMancer you need to make stb_image.h work with tcc by adding a nim.cfg/config.nims `passC="-DSTBIW_NO_SIMD -DSTBI_NO_SIMD"` directive, though. And, of course, to optimize compile times, just generally speaking, you always want to import only exactly what you really need which absolutely takes more time/thought.

[1] https://github.com/TinyCC/tinycc

[freethinky]

I agree with this sentiment.

I try to learn the basics of new programming language regularly and write a small lisp alike interpreter in it and give myself a maximum of 2 days working on it. It covers things like string handling, regexp, recursion, lambdas, garbage collection, ... and run them through a tiny test suite.

In Python and JS, it was easy to do it and the code was still very readable. In C++, the language I earn my money from, I had a bug I was not able to fix within the given time frame, happening just with gcc not clang, assuming some undefined behavior. In C, I was able to add my own garbage collector with muss less work than I expected ... but

Nim really impressed me, it really felt almost like I wrote it in Python, but an executable which run on its own and being quite a bit faster.

Working mostly in the embedded world, where ecosystem matters somewhat less. If any employee ever would give me a chance to choose a language myself I would definitely try to write a first prototype in Nim.

[k__]

I think, Nim is probably the best fit.

It also compiles to JS.

[thayne]

Rust doesn't quite hit all of those, but it hits a lot of them.

It's syntax is significantly different from python, but it does have operator overloading.

It's performance is comparable to go, and has good concurrency support, although it is different than go, and there are still some rough edges with "async" code. Compile times aren't as good as go though.

The type system is excellent, although I'm not really sure what you mean by "flexible".

And FFI support is great.

[throwup238]

Rust’s compile times are crippling and its type system is easily one of the most rigid of all type systems (lifetimes are part of the type!). The latter is one of Rust’s main selling points because it allows encoding business rules into affine types, but that’s very very far from flexible especially when compared to Typescript (or Python or Haskell and their many ways of polymorphism). Traits add an orthogonal axis of flexibility but they’re still limited by lifetimes (see async_trait and generic associated types and specialization).

“Flexible” means the range from gradual typing (‘any’) to Turing complete conditional types that can do stuff like string parsing (for better or for worse). Structural typing vs instanceof and so on.

There’s really no comparison between Typescript’s type system and Rust’s. It’s worth noting though that Typescript is a bolted on typesystem that has explicitly traded soundness for flexibility. That’s the real tradeoff between Rust and TS IMHO. Rust is sound and expressive but not flexible, while Typescript is expressive and flexible but not sound.

[friendzis]

> “Flexible” means the range from gradual typing (‘any’) to Turing complete conditional types that can do stuff like string parsing (for better or for worse).

So the flexibility means one gets to pretend they are doing typing, but in reality they get to sprinkle the code with void casts, because expressing ideas is apparently hard? For better or worse, that is probably the main pillar Rust is designed on.

[jmaker]

Also, some prominent projects migrated away from TypeScript to JSDoc type comments due to the transpile times in TypeScript. The type checking task takes the more time the more complex the type-level expressions are. Haskell can also take a long time to compile if you turn on a few extensions and move toward dependent types.

Rust compiles fast if your translation units don’t need too much macro expansion. You add something like Diesel, and you can call for the lunch break.

It’s also worth mentioning Scala with Scala Native and maybe Kotlin with Kotlin/Native. OpenJDK Project Panama FFM now gives a better FFI experiences than JNI.

[littlestymaar]

> Rust’s compile times are crippling

It's kind of a meme here on HN but while Rust compilation times are indeed higher than I wished they were, calling them “crippling” is a massive exaggeration.

My daily driver is a mid-range desktop computer from 2018 and I regularly code on a laptop from 2012, and even then it's completely manageable: cargo check is nigh instant on both, incremental compilation in debug mode is more than fast enough and even incremental rebuild in release mode and full debug builds are OK-ish (especially since they don't happen as often as the other above). There's only full builds in release mode that are arguably slow in the 2012 laptop (though on the project where it's the biggest problem, the majority of the time is spent compiling a C++ dependency), but then again it's a very obsolete piece of hardware and this isn't supposed to happen more than every six week when you update your compiler toolchain.

[throwup238]

I welcome you to try to work on a cxx-qt project to understand what crippling compile times look like.

I’m not memeing here, I’ve struggled with this issue on a variety of different projects since I first started using Rust seven years ago.

[RustSupremacist]

Everything about cxx-qt is wrong. The Rust ecosystem deserves better. Not QML. Not any markup-like things like Slint. No immediate mode. And definitely not GTK. So much wasted potential.

[thayne]

So... what do you think GUI on rust should look like?

[ozgrakkurt]

This really depends on what you are working on. As an example, compiling the protobuf stuff can get insanely slow for some reason.

[ViewTrick1002]

For any larger project I would recommend working with a cargo workspace to compile as little as possible on each check/test/run/build.

Then you can build a DAG of crates and stick e.g. the Protobuf stuff in its own separate corner where it only needs to be recompiled on full rebuilds or when you work on it.

Feels a bit shitty to have to resort to managing crates instead of modules simply due to the compile times, but it is what it is.

https://doc.rust-lang.org/cargo/reference/workspaces.html

[jmaker]

Yeah, second that. This is just release management best practice.

And it makes total sense to me, it’s a way of organizing your dependency graph by the lifetimes of your components.

This will also simplify testing, development, and audit. You won’t need to recompile autogen schemas as often as the business logic implementation anyway. Depending on artifacts pushed through a release pipeline is even more reliable. You can QA everything in guaranteed isolation while keeping it conveniently a workspace monorepo.

[lambdaone]

If only someone had a way of automating this! Say perhaps using some kind of digital computer...

[foresterre]

On compile time for Typescript: when projects have large unioned or conditional types, Typescript's compilation time isn't all that fast, and sometimes even slower than Rust, more often when Rust will be compiling incrementally (I write both Rust and Typescript extensively).

Worse, typescript may even run out of it's allocated memory sometimes.

[raverbashing]

Yeah

Go feels like C with training wheels.

Rust feels like riding a bike where one leg pedals the front wheel and another one pedals the back wheel, and you have one handlebar for each wheel as well and a very smart alarm system but it is very clunky to ride (and they tell you it's "flexible")

[u8080]

Pretty normal bike for those who used to C++ bikes before.

[raverbashing]

Yes, you pedal the C++ bike by squeezing the brake handles and brake by pedaling backwards

[NeutralCrane]

I feel like if Python’s lack of typing is going to be considered a drawback, then the solution needs to be true typing. Rust’s strict typing is an advantage, not a drawback.

[miki123211]

Among other things, a flexible type system is one where you can write a function that takes objects with keys in snake_case, and then (recursively) converts them into camelCase. In Typescript, you can make such a function generic, and it'll all type check. Your code editor will even offer autocomplete for the camelCase keys, even though the only explicit type definition is camel_case.

[hexo]

rust hits none.

[antocuni]

This looks exactly what I'm trying to do with SPy -- although SPy is still "not there" and it's WIP. I literally wrote an intro post about it yesterday: https://antocuni.eu/2025/10/29/inside-spy-part-1-motivations...

[TheFlyingFish]

SPy looks really interesting! I've run across projects like MyPyc before, but as you say they kill a lot of the "joy" of Python by removing things like decorators and operator overloading.

One question, more out of curiosity than any genuine need: do you (or do you plan to) support any kind of trait/interface based polymorphism? E.g. it's a pretty common idiom to have a function that works on "any iterable type" and that sort of thing, which seems like it would be best modeled as an interface. I guess you could argue that's at odds with Python's tradition of "duck typing" but then again, so is static typing in general so I'm not sure.

[antocuni]

I haven't fully decided which route to take in that direction, but I think I'd like to support something similar do "go": you declare an interface (or, in python typing terms a Protocol) and then all the types which have the right methods automatically implement that interface/protocol

[lejalv]

This is an enlightening post and I am very excited about SPy.

I only wish discussions happened elsewhere than Discord, e.g. Zulip, where you can have web-public channels, which is great for searchable documentation, and you can interact with channels by email if you so desire.

[antocuni]

thank you for the feedback! I wasn't aware of these features of Zulip, there are way too many competing technologies in this space and I miss the days in which everybody was IRC and that's it.

[lejalv]

I know... but given how Slack plays games with archiving, I'd be wary of entrusting user conversations to Discord (plus, there is https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS..., though it might be outdated).

[CraigJPerry]

Mojo is aiming at that. I've decided it's this years advent of code language for me and kinda looking forward to learning more about it.

[wjholden]

I think Julia largely accomplishes these goals except for the platform integration.

[jakobnissen]

It also has poor tooling when compared to Python. Julia's package manager is good, and so is it's tools for performance optimisation, but for type checking, app/cli creation, semver checking and IDE integration, the tooling is quite bad. Also, the compile times are shit, and the type system makes it very hard to make a type checker in the first place.

[leephillips]

All except maybe the compile times. I read the beginning of the article about the features of Uv; Julia has all that built in.

[rewgs]

There's Mojo, but it's been a while since I've heard anything about it.

https://www.modular.com/mojo

[DeathArrow]

Is it ready to use? Does it have libraries, tools and documentation? Is it usable for anything else beside AI? Does it work on all major platforms?

[pansa2]

There’s been a lot of hype around Mojo, but is anyone actually using it?

Does it deliver on the bold claims of its designers?

[melodyogonna]

It is still in active development

[pansa2]

So is V-lang

[cogman10]

Kotlin on a modern JVM comes pretty close.

* Performance - the JVM is very competitive with C/C++ performance.

* Compile times - Not go fast, but not C/C++/Rust slow.

* Concurrency - Virtual threads (finalized in 21) bring in the concurrency capabilities of go to the JVM

* Type System Flexibility - Kotlin isn't quite as flexible as Typescript, but it's pretty close. It's more flexible than java but not as flexible as scala. I think it strikes a good middle ground.

* Native platform integration - This is probably the weakest part of the JVM but it's gotten a lot better with the work done on Project Panama (mostly delivered in 22). Jextract makes it a lot easier to make native integrations with Java. Definitely not as painful as the JNI days.

There's also kotlin native that you could play around with (I haven't).

[quaintdev]

I feel so much comfortable with Go's type system than Typescript's

[callamdelaney]

Why would operator overloading be absolutely critical? Just use methods. The pipe operator already has around 15 uses and counting, it doesn’t need more

[saagarjha]

Because writing a.add(b).divide(c) is miserable

[CraigJPerry]

That's a fine approach for "plumbing" type work, you know "join this thing to that thing then call that thing" - and that is most of the code in the world today but it falls apart in math heavy code.

You really just want operators when you're performing tons of operations, it's an absolute wall of text when it's all method calls.

[ogogmad]

Instead of writing 2+2, you're suggesting writing 2.plus(2) or plus(2,2).

[yard2010]

Also, case matching of Scala <3

[bigpeopleareold]

Free Pascal with better tooling?

[movpasd]

You may be interested in Mojo, it's a project by Chris Lattner. It aims to have Python-like syntax and smooth integration with Python but allow Rust-like low-level control (I believe it has a borrow checker). Unfortunately, I believe it's proprietary.