8 ms·

I thought this was going to be a longer rant about how python needs to... Go away. Which, as a long time python programmer and contributor, and at one time avid

I thought this was going to be a longer rant about how python needs to... Go away. Which, as a long time python programmer and contributor, and at one time avid proponent of the language, I would entertain the suggestion. I think all of ML being in Python is a collosal mistake that we'll pay for for years. The main reasons being it is slow, its type system is significantly harder to use than other languages, and it's hard to distribute. The only reason to use it is inertia. Obviously inertia can be sufficient for many reasons, but I would like to see the industry consider python last, and instead consider typescript, go, or rust (depending on use case) as a best practice. Python would be considered deprecated and only used for existing codebases like pytorch. Why would you write a web app in Python? Types are terrible, it's slow. There are way better alternatives.

krzyk 9mo ago
Typescript? Why replace a nice language like python with anything coming out of javascript?
- christophilus 9mo ago
  Typescript is a really nice language even though it sits on a janky runtime. I’d love a subset of typescript that compiles to Go or something like that.
  - polynomial 9mo ago
    Isn't that what Project Corsa is supposed to solve?
    - nish__ 9mo ago
      Project Corsa is a rewrite of the TypeScript compiler in Go. I don't think that's what's being asked for.
- fiyec30375 9mo ago
  Typescript is ubiquitous in web, and there are some amazing new frameworks that reuse typescript types on the server and client (trpc, tanstack). It's faster (than python), has ergonomic types, and a massive community + npm ecosystem. Bun advances the state of the art for runtime performance (which anthropic just bought and use for Claude code).
  - bdangubic 9mo ago
    Did you just write both: > The only reason to use it is inertia and > Typescript is ubiquitous in web :-)
    - sinkasapa 9mo ago
      Those are both valid reasons to use both languages. The "only" (whether true or not) is what the argument hinges on. It is roughly the same as saying that the only advantage of X is that it is popular, but Y is also popular and has additional advantages, therefore, Y is better than X. That is a valid argument, whether the premises are true or not.
      - bdangubic 9mo ago
        I do not disagree but if you are going to say that "X" is only used because of "Y", maybe if you are pitching "Z" instead of "X" do not start with the "Y" :)
        Xeronate 9mo ago
        Agree to disagree. He's setting up the argument that Z is strictly better than X.
  - krzyk 9mo ago
    But it comes from Javascript and inherits its issues, and is used mostly because there is no other option on the web and that makes it popular, not its quality, but lack of options. So a closed ecosystem with just one language - Javascript, and any other languages that can be compiled to it. And Typescript is a bandaid to make sensible type system on top of Javascript, and it still leaves option open to use Javascript lack of rules. Concurrency in JS also looks junky. And on readability Python also wins (if we prohibit stupidities like PEP 572)
- hu3 9mo ago
  TypeScript is great! Has shortcomings like all languages but it brought a lot of advanced programming language concepts to the masses!
- IshKebab 9mo ago
  Typescript is a lot nicer than Python in many ways. Especially via Deno, and especially for scripting (imports work like people want!). There are some things that aren't as good, e.g. Python's arbitrary precision integers are definitely nicer for scripting. And I'd say Python's list comprehension syntax is often quite nice even if it is weirdly irregular. But overall Deno is a much better choice for ad-hoc scripting than Python.
  - chpatrick 9mo ago
    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - IshKebab 9mo ago
      I am aware, but Python has that by default. In Javascript it's opt-in and less ergonomic. E.g. try loading a 64-bit integer from JSON.
      - josephg 9mo ago
        I agree, but bigints are missing from json because the json spec defines all numbers as 64 bit floats. Any other kind of number in JSON is nonstandard. JavaScript itself supports bigint literals just fine. Just put an ‘n’ after your number literal. Eg 0xffffffffffffffn. There’s a whole bunch of features I wish we could go in and add to json. Like comments, binary blobs, dates and integers / bigints. It would be so much nicer to work with if it has that stuff.
        IshKebab 9mo ago
        > the json spec defines all numbers as 64 bit floats It absolutely doesn't. It doesn't impose any limits on number precision or magnitude.
- chpatrick 9mo ago
  Its type system is miles better than Python and it has some basic stuff Python doesn't have like block scope. Functional programming is also intentionally kind of a pain in Python with the limited lambdas. If TypeScript had the awesome python stdlib and the Numpy/ML ecosystem I would use it over Python in a heartbeat.
  - tehjoker 9mo ago
    you can define a named closure in python, i do it from time to time, though it does seem to surprise others sometimes. i think maybe it's not too common.
    - chpatrick 9mo ago
      I know, it's just very unergonomic.
  - josephg 9mo ago
    Typescript also has significantly better performance. This is largely thanks to the browser wars funnelling an insane amount of engineering effort toward JavaScript engines over the last couple decades. Nodejs runs v8, which is the JavaScript engine used by chrome. And Bun uses JSC, written for safari. For IO bound tasks, it also helps that JavaScript has a much simpler threading model. And it ships an event based IO system out of the box.
dkarl 9mo ago
I'd love to replace Python with something simple, expressive, and strongly typed that compiles to native code. I have a habit of building little CLI tools as conveniences for working with internal APIs, and you wouldn't think you could tell a performance difference between Go and Python for something like that, but you can. After a year or so of writing these tools in Go, I went back to Python because the LOC difference is stark, but every time I run one of them I wish it was written in Go. (OCaml is probably what I'm looking for, but I'm having a hard time getting motivated to tackle it, because I dread dealing with the tooling and dependency management of a 20th century language from academia.)
- fiyec30375 9mo ago
  I suppose you could try typescript which can compile to a single binary using node or bun. Both bun and node do type stripping of ts types, and can compile a cli to a single file executable. This is what anthropic does for Claude code.
- Hasnep 9mo ago
  I bounced off OCaml a few years ago because of the state of the tooling, despite it being almost exactly the language I was looking for. I'm really happy with Gleam now, and recommended it over OCaml for most use cases.
  - dkarl 9mo ago
    I always assumed a runtime specialized for highly concurrent, fault-tolerant, long-running processes would have a noticeable startup penalty, which is one of the things that bothers me about Python. Is that something you notice with Gleam?
    - antsinmypants 9mo ago
      I tried out Gleam for Advent of Code this year. There was a significant difference in startup times, about 13 ms for Python and 120 ms for Gleam. If you want something with minimal startup times then you need a language that complies to native binaries like Zig, Rust or OCaml.
vovavili 9mo ago
This is a needlessly dismissive and narrow-minded attitude. Have you ever tried to use FastAPI?
- fiyec30375 9mo ago
  Yes. Have you ever tried trpc?
  - vovavili 9mo ago
    Implying that existence of your tool of preference in another programming language makes other equally impressive tools something akin to "[colossal] mistake that we'll pay for for years" "simply motivated by inertia" is way below the level of discussion I would expect from Hacker News.
    - carderne 9mo ago
      To be fair, your comment didn't add much either. Their main criticisms of Python were: > it is slow, its type system is significantly harder to use than other languages, and it's hard to distribute Your comment would have been more useful if it had discussed how FastAPI addresses these issues.
      - vovavili 9mo ago
        I would have given the OOP the effort and due respect is formulating my response if it was phrased in the way you're describing. It's only fair that comments that strongly violate the norms of substantive discourse don't get a well-crafted response back.
- yunnpp 9mo ago
  You say he's narrow-minded, but you focus on the least relevant thing of everything he said, speed, and suggest that, somehow, something with "fast" in its name will fix it? Speed is the least concern because things like numpy are written in C and the overhead you pay for is in the glue code and ffi. The lack of a standard distribution system is a big one. Dynamic typing works well for small programs and teams but does not scale when either dimension is increased. But pure Python is inherently slow because of language design. It also cannot be compiled efficiently unless you introduce constraints into the language, at which point you're tackling a subset thereof. No library can fix this.
strunz 9mo ago
I swear the only the people who care about Python types are on Hacker News comments. I've never actually worked with or met someone who cared so much about it, and the ones that care at all seem just fine with type hints.
- hu3 9mo ago
  Perhaps some people that cared moved to other languages. And part of those who still complain are momentarily stuck with it. Just like survivorship bias. It's productive to ponder on the issues experienced by those who never returned.
- josephg 9mo ago
  The people we happen to work with is an incredibly biased sample set of all software engineers. As an example, almost everyone I’ve worked with in my career likes using macOS and Linux. But there are entire software engineering sub communities who stick to windows. For them, macOS is a quaint toy. If you’ve never met or worked with people who care about typing, I think that says more about your workplace and coworkers than anything. I’ve worked with plenty of engineers who consider dynamic typing to be abhorrent. Especially at places like FAANG. Long before typescript, before nodejs, before even “JavaScript the good parts”, Google wrote their own JavaScript compiler called Closure. The compiler is written in Java. It could do many things - but as far as I can tell, the main purpose of the compiler was to add types to JavaScript. Why? Because googlers would rather write a compiler from scratch than use a dynamically typed language. I know it was used to make the the early versions of Gmail. It may still be in use to this day.
rahen 9mo ago
"> I think all of ML being in Python is a colossal mistake that we'll pay for for years. Market pressure. Early ML frameworks were in Lisp, then eventually Lua with Torch, but demand dictated the choice of Python because "it's simple" even if the result is cobbled together. Lisp is arguably still the most suitable language for neural networks for a lot of reasons beyond the scope of this post, but the tooling is missing. I’m developing such a framework right now, though I have no illusions that many will adopt it. Python may not be elegant or efficient, but it's simple, and that's what people want.
- Joker_vD 9mo ago
  Gee, I wonder why the tooling for ML in Lisp is missing even though the early ML frameworks were in Lisp. Perhaps there is something about the language that stifles truly wide collaboration?
  - rahen 9mo ago
    I doubt it considering there are massive Clojure codebases with large teams collaborating on them every day. The lack of Lisp tooling and the prevalence of Python are more a result of inertia, low barrier to entry and ecosystem lock-in.
- wild_egg 9mo ago
  What sort of tooling is missing in Lisp? I'd love to check out your framework if you've shared it somewhere
  - rahen 9mo ago
    Lisp isn't missing anything, it's a natural fit for AI/ML. It’s the ecosystem's tooling that needs catching up. The code hasn't reached RC yet, but I'll definitely post a Show HN once it's ready for a preview.
tayo42 9mo ago
How much does python really impact ml? All of the libraries are wrappers around C code that uses gpus any way, it's distributed and inference can be written in faster languages for serving anyway?
- roadside_picnic 9mo ago
  You're thinking only about the final step where we're just doing a bunch of matrix computation. The real work Python does in the ML world is automatic differentiation. Python has multiple excellent options for this: JAX, Pytorch, Tensorflow, autograd, etc. Each of these libraries excels for different use cases. I also believe these are cases where Python the language is part of the reason these libraries exist (whereas, to your point, for the matrix operations pretty much any language could implement these C wrappers). Python does make it easy to perform meta-programming and is very flexible when you need to manipulate the language itself.
CamperBob2 9mo ago
I think all of ML being in Python is a colossal mistake that we'll pay for for years. If ML fulfills its promise, it won't matter in the least what language the code is/was written in. If it doesn't, it won't matter anyway.
solatic 9mo ago
100%. With that said... there is a reason why ML went with Python. GPU programming requires C-based libraries. NodeJS does not have a good FFI story, and neither does Rust or Go. Yes, there's support, but Python's FFI support is actually better here. Zig is too immature here. The world deserves a Python-like language with a better type system, a better distribution system, and not nearly as much dynamism footguns / rope for people to hang themselves with.
- NetMageSCW 9mo ago
  C#/.Net? (Their too strong focus on worthless backwards compatibility and slow (very slow) development speed on basic language features not withstanding.)
  - Xeronate 9mo ago
    Admittedly I haven't used C# in a few years, but to my knowledge it is much more ergonomic than java and personally it's my preferred language. Only thing stopping me from using it more is it has a much smaller community than java/python etc. Wondering what you think is missing.
- uxcolumbo 9mo ago
  What about Elixir? https://pragprog.com/titles/smelixir/machine-learning-in-elixir/ https://pragprog.com/titles/smelixir/machine-learning-in-eli... A Practical Guide to Machine Learning in Elixir - Chris Grainger https://www.youtube.com/watch?v=Es08MRtSkoE https://www.youtube.com/watch?v=Es08MRtSkoE
  - solid_fuel 9mo ago
    I've actually done a fair bit of ML work in Elixir, in practice I found: 1) It's generally harder to interface with existing libraries and models (example: whisperX [0] is a library that combines generic whisper speech recognition models with some additional tools like discrete-time-warping to create a transcription with more accurate time stamp alignment - something that was very helpful when generating subtitles. But because most of this logic just lives in the python library, using this in Elixir requires writing a lot more tooling around the existing bumblebee whisper implementation [1]). but, 2) It's way easier to ship models I built and trained entirely with Elixir's ML ecosystem - EXLA, NX, Bumblebee. I trained a few models doing basic visual recognition tasks (detecting scene transitions, credits, title cards, etc), using the existing CLIP model as a visual frontend and then training a small classifier on the output of CLIP. It was pretty straightforward to do with Elixir, and I love that I can run the same exact code on my laptop and server without dealing with lots of dependencies and environment issues. Livebook is also incredibly nice, my typical workflow has become prototyping things in Livebook with some custom visualization tools that I made and then just connecting to a livebook instance running on EC2 to do the actual training run. From there shipping and using the model is seamless, and I just publish the wrapping module as a library on our corporate github, which lets anyone else import it straight into livebook and use it. [0] https://github.com/m-bain/whisperX https://github.com/m-bain/whisperX [1] https://hexdocs.pm/bumblebee/Bumblebee.Audio.Whisper.html https://hexdocs.pm/bumblebee/Bumblebee.Audio.Whisper.html
robomartin 9mo ago
> I think all of ML being in Python is a collosal mistake that we'll pay for for years. > The main reasons being it is slow, <snip>, and it's hard to distribute. Don't forget that Python consumes approximately 70x more power when compared to C.
- fwip 9mo ago
  Not really applicable to ML. The massive amount of compute running on the GPU is not executing in Python, and is basically the same regardless of host language.
  - robomartin 9mo ago
    There's a lot of non-GPU hardware surrounding every kind of data center. If this is coded in Python, it is using 70x more energy than C.
    - fwip 9mo ago
      Not in any meaningful way, no.
superice 9mo ago
It’s especially frustrating that dependency hell seems to be embedded in the Python culture. The amount of “oh no this lib will only work with Python 3.10+ and a slew of other libs at random versions we won’t bother to tell you” while some other lib that it depends on will only work on “3.8.56z but not if you look at it funny and only if you say pretty please” is maddening. Semver is apparently not standard practice either. I am probably biased against Python, so take this opinion with a grain of salt, but it feels to me like a whole ecosystem of amateur software devs (but professional ML-engineers, data scientists etc) cobbling together something that barely works. I’m old enough at this point that I remember the whole old guard of software engineers falling over themselves to hate on JS and Node, call the ecosystem immature, and be quick to point out how that is not “real” software. But in the past 10-15 years it appears JS and Node got their shit together, while Python is still completely and utterly stuck in managing dependencies and environments like it is 2012. And if you ask professional Pythonistas about this, you always get an answer like “oh it’s actually really easy, you must not have taken the time to really look at it, because Python is easy, it’s just pseudocode look how amazing it all is” I really wish ML hadn’t standarized on Python. As a user of ML tools ans frameworks but not a fulltime ML engineer it just constant pain.
- fastasucan 9mo ago
  >It’s especially frustrating that dependency hell seems to be embedded in the Python culture. The amount of “oh no this lib will only work with Python 3.10+ and a slew of other libs at random versions we won’t bother to tell you” while some other lib that it depends on will only work on “3.8.56z but not if you look at it funny and only if you say pretty please” is maddening. Semver is apparently not standard practice either. There is no problems with this in modern python if you just use the right tooling.

krzyk 9mo ago

Typescript? Why replace a nice language like python with anything coming out of javascript?

christophilus 9mo ago
Typescript is a really nice language even though it sits on a janky runtime. I’d love a subset of typescript that compiles to Go or something like that.
- polynomial 9mo ago
  Isn't that what Project Corsa is supposed to solve?
  - nish__ 9mo ago
    Project Corsa is a rewrite of the TypeScript compiler in Go. I don't think that's what's being asked for.
fiyec30375 9mo ago
Typescript is ubiquitous in web, and there are some amazing new frameworks that reuse typescript types on the server and client (trpc, tanstack). It's faster (than python), has ergonomic types, and a massive community + npm ecosystem. Bun advances the state of the art for runtime performance (which anthropic just bought and use for Claude code).
- bdangubic 9mo ago
  Did you just write both: > The only reason to use it is inertia and > Typescript is ubiquitous in web :-)
  - sinkasapa 9mo ago
    Those are both valid reasons to use both languages. The "only" (whether true or not) is what the argument hinges on. It is roughly the same as saying that the only advantage of X is that it is popular, but Y is also popular and has additional advantages, therefore, Y is better than X. That is a valid argument, whether the premises are true or not.
    - bdangubic 9mo ago
      I do not disagree but if you are going to say that "X" is only used because of "Y", maybe if you are pitching "Z" instead of "X" do not start with the "Y" :)
      - Xeronate 9mo ago
        Agree to disagree. He's setting up the argument that Z is strictly better than X.
- krzyk 9mo ago
  But it comes from Javascript and inherits its issues, and is used mostly because there is no other option on the web and that makes it popular, not its quality, but lack of options. So a closed ecosystem with just one language - Javascript, and any other languages that can be compiled to it. And Typescript is a bandaid to make sensible type system on top of Javascript, and it still leaves option open to use Javascript lack of rules. Concurrency in JS also looks junky. And on readability Python also wins (if we prohibit stupidities like PEP 572)
hu3 9mo ago
TypeScript is great! Has shortcomings like all languages but it brought a lot of advanced programming language concepts to the masses!
IshKebab 9mo ago
Typescript is a lot nicer than Python in many ways. Especially via Deno, and especially for scripting (imports work like people want!). There are some things that aren't as good, e.g. Python's arbitrary precision integers are definitely nicer for scripting. And I'd say Python's list comprehension syntax is often quite nice even if it is weirdly irregular. But overall Deno is a much better choice for ad-hoc scripting than Python.
- chpatrick 9mo ago
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - IshKebab 9mo ago
    I am aware, but Python has that by default. In Javascript it's opt-in and less ergonomic. E.g. try loading a 64-bit integer from JSON.
    - josephg 9mo ago
      I agree, but bigints are missing from json because the json spec defines all numbers as 64 bit floats. Any other kind of number in JSON is nonstandard. JavaScript itself supports bigint literals just fine. Just put an ‘n’ after your number literal. Eg 0xffffffffffffffn. There’s a whole bunch of features I wish we could go in and add to json. Like comments, binary blobs, dates and integers / bigints. It would be so much nicer to work with if it has that stuff.
      - IshKebab 9mo ago
        > the json spec defines all numbers as 64 bit floats It absolutely doesn't. It doesn't impose any limits on number precision or magnitude.
chpatrick 9mo ago
Its type system is miles better than Python and it has some basic stuff Python doesn't have like block scope. Functional programming is also intentionally kind of a pain in Python with the limited lambdas. If TypeScript had the awesome python stdlib and the Numpy/ML ecosystem I would use it over Python in a heartbeat.
- tehjoker 9mo ago
  you can define a named closure in python, i do it from time to time, though it does seem to surprise others sometimes. i think maybe it's not too common.
  - chpatrick 9mo ago
    I know, it's just very unergonomic.
- josephg 9mo ago
  Typescript also has significantly better performance. This is largely thanks to the browser wars funnelling an insane amount of engineering effort toward JavaScript engines over the last couple decades. Nodejs runs v8, which is the JavaScript engine used by chrome. And Bun uses JSC, written for safari. For IO bound tasks, it also helps that JavaScript has a much simpler threading model. And it ships an event based IO system out of the box.

dkarl 9mo ago

I'd love to replace Python with something simple, expressive, and strongly typed that compiles to native code. I have a habit of building little CLI tools as conveniences for working with internal APIs, and you wouldn't think you could tell a performance difference between Go and Python for something like that, but you can. After a year or so of writing these tools in Go, I went back to Python because the LOC difference is stark, but every time I run one of them I wish it was written in Go. (OCaml is probably what I'm looking for, but I'm having a hard time getting motivated to tackle it, because I dread dealing with the tooling and dependency management of a 20th century language from academia.)

fiyec30375 9mo ago
I suppose you could try typescript which can compile to a single binary using node or bun. Both bun and node do type stripping of ts types, and can compile a cli to a single file executable. This is what anthropic does for Claude code.
Hasnep 9mo ago
I bounced off OCaml a few years ago because of the state of the tooling, despite it being almost exactly the language I was looking for. I'm really happy with Gleam now, and recommended it over OCaml for most use cases.
- dkarl 9mo ago
  I always assumed a runtime specialized for highly concurrent, fault-tolerant, long-running processes would have a noticeable startup penalty, which is one of the things that bothers me about Python. Is that something you notice with Gleam?
  - antsinmypants 9mo ago
    I tried out Gleam for Advent of Code this year. There was a significant difference in startup times, about 13 ms for Python and 120 ms for Gleam. If you want something with minimal startup times then you need a language that complies to native binaries like Zig, Rust or OCaml.

vovavili 9mo ago

This is a needlessly dismissive and narrow-minded attitude. Have you ever tried to use FastAPI?

fiyec30375 9mo ago
Yes. Have you ever tried trpc?
- vovavili 9mo ago
  Implying that existence of your tool of preference in another programming language makes other equally impressive tools something akin to "[colossal] mistake that we'll pay for for years" "simply motivated by inertia" is way below the level of discussion I would expect from Hacker News.
  - carderne 9mo ago
    To be fair, your comment didn't add much either. Their main criticisms of Python were: > it is slow, its type system is significantly harder to use than other languages, and it's hard to distribute Your comment would have been more useful if it had discussed how FastAPI addresses these issues.
    - vovavili 9mo ago
      I would have given the OOP the effort and due respect is formulating my response if it was phrased in the way you're describing. It's only fair that comments that strongly violate the norms of substantive discourse don't get a well-crafted response back.
yunnpp 9mo ago
You say he's narrow-minded, but you focus on the least relevant thing of everything he said, speed, and suggest that, somehow, something with "fast" in its name will fix it? Speed is the least concern because things like numpy are written in C and the overhead you pay for is in the glue code and ffi. The lack of a standard distribution system is a big one. Dynamic typing works well for small programs and teams but does not scale when either dimension is increased. But pure Python is inherently slow because of language design. It also cannot be compiled efficiently unless you introduce constraints into the language, at which point you're tackling a subset thereof. No library can fix this.

strunz 9mo ago

I swear the only the people who care about Python types are on Hacker News comments. I've never actually worked with or met someone who cared so much about it, and the ones that care at all seem just fine with type hints.

hu3 9mo ago
Perhaps some people that cared moved to other languages. And part of those who still complain are momentarily stuck with it. Just like survivorship bias. It's productive to ponder on the issues experienced by those who never returned.
josephg 9mo ago
The people we happen to work with is an incredibly biased sample set of all software engineers. As an example, almost everyone I’ve worked with in my career likes using macOS and Linux. But there are entire software engineering sub communities who stick to windows. For them, macOS is a quaint toy. If you’ve never met or worked with people who care about typing, I think that says more about your workplace and coworkers than anything. I’ve worked with plenty of engineers who consider dynamic typing to be abhorrent. Especially at places like FAANG. Long before typescript, before nodejs, before even “JavaScript the good parts”, Google wrote their own JavaScript compiler called Closure. The compiler is written in Java. It could do many things - but as far as I can tell, the main purpose of the compiler was to add types to JavaScript. Why? Because googlers would rather write a compiler from scratch than use a dynamically typed language. I know it was used to make the the early versions of Gmail. It may still be in use to this day.

rahen 9mo ago

"> I think all of ML being in Python is a colossal mistake that we'll pay for for years. Market pressure. Early ML frameworks were in Lisp, then eventually Lua with Torch, but demand dictated the choice of Python because "it's simple" even if the result is cobbled together. Lisp is arguably still the most suitable language for neural networks for a lot of reasons beyond the scope of this post, but the tooling is missing. I’m developing such a framework right now, though I have no illusions that many will adopt it. Python may not be elegant or efficient, but it's simple, and that's what people want.

Joker_vD 9mo ago
Gee, I wonder why the tooling for ML in Lisp is missing even though the early ML frameworks were in Lisp. Perhaps there is something about the language that stifles truly wide collaboration?
- rahen 9mo ago
  I doubt it considering there are massive Clojure codebases with large teams collaborating on them every day. The lack of Lisp tooling and the prevalence of Python are more a result of inertia, low barrier to entry and ecosystem lock-in.
wild_egg 9mo ago
What sort of tooling is missing in Lisp? I'd love to check out your framework if you've shared it somewhere
- rahen 9mo ago
  Lisp isn't missing anything, it's a natural fit for AI/ML. It’s the ecosystem's tooling that needs catching up. The code hasn't reached RC yet, but I'll definitely post a Show HN once it's ready for a preview.

tayo42 9mo ago

How much does python really impact ml? All of the libraries are wrappers around C code that uses gpus any way, it's distributed and inference can be written in faster languages for serving anyway?

roadside_picnic 9mo ago
You're thinking only about the final step where we're just doing a bunch of matrix computation. The real work Python does in the ML world is automatic differentiation. Python has multiple excellent options for this: JAX, Pytorch, Tensorflow, autograd, etc. Each of these libraries excels for different use cases. I also believe these are cases where Python the language is part of the reason these libraries exist (whereas, to your point, for the matrix operations pretty much any language could implement these C wrappers). Python does make it easy to perform meta-programming and is very flexible when you need to manipulate the language itself.

CamperBob2 9mo ago

I think all of ML being in Python is a colossal mistake that we'll pay for for years. If ML fulfills its promise, it won't matter in the least what language the code is/was written in. If it doesn't, it won't matter anyway.

solatic 9mo ago

100%. With that said... there is a reason why ML went with Python. GPU programming requires C-based libraries. NodeJS does not have a good FFI story, and neither does Rust or Go. Yes, there's support, but Python's FFI support is actually better here. Zig is too immature here. The world deserves a Python-like language with a better type system, a better distribution system, and not nearly as much dynamism footguns / rope for people to hang themselves with.

NetMageSCW 9mo ago
C#/.Net? (Their too strong focus on worthless backwards compatibility and slow (very slow) development speed on basic language features not withstanding.)
- Xeronate 9mo ago
  Admittedly I haven't used C# in a few years, but to my knowledge it is much more ergonomic than java and personally it's my preferred language. Only thing stopping me from using it more is it has a much smaller community than java/python etc. Wondering what you think is missing.
uxcolumbo 9mo ago
What about Elixir? https://pragprog.com/titles/smelixir/machine-learning-in-elixir/ https://pragprog.com/titles/smelixir/machine-learning-in-eli... A Practical Guide to Machine Learning in Elixir - Chris Grainger https://www.youtube.com/watch?v=Es08MRtSkoE https://www.youtube.com/watch?v=Es08MRtSkoE
- solid_fuel 9mo ago
  I've actually done a fair bit of ML work in Elixir, in practice I found: 1) It's generally harder to interface with existing libraries and models (example: whisperX [0] is a library that combines generic whisper speech recognition models with some additional tools like discrete-time-warping to create a transcription with more accurate time stamp alignment - something that was very helpful when generating subtitles. But because most of this logic just lives in the python library, using this in Elixir requires writing a lot more tooling around the existing bumblebee whisper implementation [1]). but, 2) It's way easier to ship models I built and trained entirely with Elixir's ML ecosystem - EXLA, NX, Bumblebee. I trained a few models doing basic visual recognition tasks (detecting scene transitions, credits, title cards, etc), using the existing CLIP model as a visual frontend and then training a small classifier on the output of CLIP. It was pretty straightforward to do with Elixir, and I love that I can run the same exact code on my laptop and server without dealing with lots of dependencies and environment issues. Livebook is also incredibly nice, my typical workflow has become prototyping things in Livebook with some custom visualization tools that I made and then just connecting to a livebook instance running on EC2 to do the actual training run. From there shipping and using the model is seamless, and I just publish the wrapping module as a library on our corporate github, which lets anyone else import it straight into livebook and use it. [0] https://github.com/m-bain/whisperX https://github.com/m-bain/whisperX [1] https://hexdocs.pm/bumblebee/Bumblebee.Audio.Whisper.html https://hexdocs.pm/bumblebee/Bumblebee.Audio.Whisper.html

robomartin 9mo ago

> I think all of ML being in Python is a collosal mistake that we'll pay for for years. > The main reasons being it is slow, <snip>, and it's hard to distribute. Don't forget that Python consumes approximately 70x more power when compared to C.

fwip 9mo ago
Not really applicable to ML. The massive amount of compute running on the GPU is not executing in Python, and is basically the same regardless of host language.
- robomartin 9mo ago
  There's a lot of non-GPU hardware surrounding every kind of data center. If this is coded in Python, it is using 70x more energy than C.
  - fwip 9mo ago
    Not in any meaningful way, no.

superice 9mo ago

It’s especially frustrating that dependency hell seems to be embedded in the Python culture. The amount of “oh no this lib will only work with Python 3.10+ and a slew of other libs at random versions we won’t bother to tell you” while some other lib that it depends on will only work on “3.8.56z but not if you look at it funny and only if you say pretty please” is maddening. Semver is apparently not standard practice either. I am probably biased against Python, so take this opinion with a grain of salt, but it feels to me like a whole ecosystem of amateur software devs (but professional ML-engineers, data scientists etc) cobbling together something that barely works. I’m old enough at this point that I remember the whole old guard of software engineers falling over themselves to hate on JS and Node, call the ecosystem immature, and be quick to point out how that is not “real” software. But in the past 10-15 years it appears JS and Node got their shit together, while Python is still completely and utterly stuck in managing dependencies and environments like it is 2012. And if you ask professional Pythonistas about this, you always get an answer like “oh it’s actually really easy, you must not have taken the time to really look at it, because Python is easy, it’s just pseudocode look how amazing it all is” I really wish ML hadn’t standarized on Python. As a user of ML tools ans frameworks but not a fulltime ML engineer it just constant pain.

fastasucan 9mo ago
>It’s especially frustrating that dependency hell seems to be embedded in the Python culture. The amount of “oh no this lib will only work with Python 3.10+ and a slew of other libs at random versions we won’t bother to tell you” while some other lib that it depends on will only work on “3.8.56z but not if you look at it funny and only if you say pretty please” is maddening. Semver is apparently not standard practice either. There is no problems with this in modern python if you just use the right tooling.