5 ms·

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 scien

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++.

thayne 1y ago
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 1y ago
  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.
  - jmaker 1y ago
    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.
  - friendzis 1y ago
    > “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.
  - littlestymaar 1y ago
    > 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.
    - ozgrakkurt 1y ago
      This really depends on what you are working on. As an example, compiling the protobuf stuff can get insanely slow for some reason.
- hexo 1y ago
  rust hits none.
- miki123211 1y ago
  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.
AyanamiKaine 1y ago
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/ https://nim-lang.org/
- k__ 1y ago
  I think, Nim is probably the best fit. It also compiles to JS.
- cb321 1y ago
  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 https://github.com/TinyCC/tinycc
- freethinky 1y ago
  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.
rewgs 1y ago
There's Mojo, but it's been a while since I've heard anything about it. https://www.modular.com/mojo https://www.modular.com/mojo
- pansa2 1y ago
  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 1y ago
    It is still in active development
    - pansa2 1y ago
      So is V-lang
- DeathArrow 1y ago
  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?
antocuni 1y ago
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-and-goals/ https://antocuni.eu/2025/10/29/inside-spy-part-1-motivations...
- lejalv 1y ago
  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 1y ago
    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 1y ago
      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.html https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS..., though it might be outdated).
- TheFlyingFish 1y ago
  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.
yard2010 1y ago
Also, case matching of Scala <3
wjholden 1y ago
I think Julia largely accomplishes these goals except for the platform integration.
- jakobnissen 1y ago
  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 1y ago
  All except maybe the compile times. I read the beginning of the article about the features of Uv; Julia has all that built in.
bigpeopleareold 1y ago
Free Pascal with better tooling?
callamdelaney 1y ago
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 1y ago
  Because writing a.add(b).divide(c) is miserable
- CraigJPerry 1y ago
  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 1y ago
  Instead of writing 2+2, you're suggesting writing 2.plus(2) or plus(2,2).
CraigJPerry 1y ago
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.
movpasd 1y ago
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.
quaintdev 1y ago
I feel so much comfortable with Go's type system than Typescript's
deleted 1y ago
[deleted]
cogman10 1y ago
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).

thayne 1y ago

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 1y ago
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.
- jmaker 1y ago
  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.
- friendzis 1y ago
  > “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.
- littlestymaar 1y ago
  > 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.
  - ozgrakkurt 1y ago
    This really depends on what you are working on. As an example, compiling the protobuf stuff can get insanely slow for some reason.
hexo 1y ago
rust hits none.
miki123211 1y ago
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.

AyanamiKaine 1y ago

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/ https://nim-lang.org/

k__ 1y ago
I think, Nim is probably the best fit. It also compiles to JS.
cb321 1y ago
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 https://github.com/TinyCC/tinycc
freethinky 1y ago
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.

rewgs 1y ago

There's Mojo, but it's been a while since I've heard anything about it. https://www.modular.com/mojo https://www.modular.com/mojo

pansa2 1y ago
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 1y ago
  It is still in active development
  - pansa2 1y ago
    So is V-lang
DeathArrow 1y ago
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?

antocuni 1y ago

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-and-goals/ https://antocuni.eu/2025/10/29/inside-spy-part-1-motivations...

lejalv 1y ago
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 1y ago
  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 1y ago
    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.html https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS..., though it might be outdated).
TheFlyingFish 1y ago
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.

yard2010 1y ago

Also, case matching of Scala <3

wjholden 1y ago

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

jakobnissen 1y ago
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 1y ago
All except maybe the compile times. I read the beginning of the article about the features of Uv; Julia has all that built in.

bigpeopleareold 1y ago

Free Pascal with better tooling?

callamdelaney 1y ago

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 1y ago
Because writing a.add(b).divide(c) is miserable
CraigJPerry 1y ago
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 1y ago
Instead of writing 2+2, you're suggesting writing 2.plus(2) or plus(2,2).

CraigJPerry 1y ago

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.

movpasd 1y ago

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.

quaintdev 1y ago

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

deleted 1y ago

[deleted]

cogman10 1y ago

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).