Fast.ai and why Python is not the future of ML with Jeremy Howard | Hacker News Reader

Fast.ai and why Python is not the future of ML with Jeremy Howard

wandb.com

74 pointstosh110 comments

I feel like this misses the point.

Python is used as the language to describe things, but nobody is executing Python on the GPU. Instead, things are transpiled into highly optimized byte code, C++ source, or chains of optimized GPU sharers. See TensorFlow XLA and AOT.

So when I set up a training pipeline with TensorFlow, then it'll barely run any python while training. Instead, the TF C++ core will execute a network of TF CUDA operators for me, all inside one python function call. That's why pythons global interpreter lock is pretty much a non-issue by now.

Since only 1% of my training time is even running inside python, I don't expect any performance benefits from replacing it. And if both are equally fast, I prefer the familiar option, meaning python.

You can be sure that they are both well aware of this, Jeremy is one of the creator of the popular python library, book, and online course fast.ai built on top of PyTorch.

The relevant part of the their discussion is this one:

> Like Python is not the future of machine learning. It can't be. You know, it's so nicely hackable, but it's so frustrating to work with a language where you can't do anything fast enough unless you call out to some external code or C code, and you can't run anything in parallel unless you put in a whole other process. Like I find working with Python, there's just so much overhead in my brain to try to get it to work fast enough. It's obviously fine for a lot of things, but not really in the deep learning world or not really in the machine learning world. So, like, I really hope that Julia is really successful because there's a language with a nicely designed type system and a nicely designed dispatch system and most importantly, it's Julia all the way down so you can get in and write your GPU colonel in Julia, or all the basic stuff is implemented in Júlia all the way down until you hit the LLVM.

Here the point is that when using other languages (such as Julia) you actually can use the same language for your GPU and for the glue that keep your scripts together.

I feel like you (and them) are still missing the point. 99% of users don't write GPU kernels. They use simple function calls and that's all they see. 99% of users don't care if they call CUDA code from Python, or Julia code from Julia, as long as both are equally fast and API is clean (e.g. Pytorch).

This is because 99% of users know only Python, and C++ is too much for them. If the advanced stuff was available in the language they use, larger portion of users would write more advanced stuff.

I prefer Clojure for this. Even simpler than Python, fast, and enables me to match or even surpass the speed expected from mainstream tools.

See this for example: https://dragan.rocks/articles/20/Deep-Diamond-Deep-Learning-...

Did you write gpu kernels in clojure? Or did you make function calls to cudnn like pytorch et al does it?

Both. See https://github.com/uncomplicate/bayadera too.

Whatever the language, you have to make function calls to cuDNN, because cuDNN is optimized by Nvidia, which put serious resources into it. Even if you wrote everything in C++/CUDA, you probably can't match it for the standard stuff.

The custom things that I write, I prefer to write in CUDA kernels + Clojure management code.

Clojure kernels are technically possible in the same way as Julia or whatever kernels are possible, but the thing is that you have to match low-level hardware features anyway, so CUDA C/C++ just makes more sense for kernels, which are tiny part of code anyway.

So if you have to use cuda c/c++, then why not do it from python?

No. You don't use cuda/c++ as it is used from Python. You use cuda/c only in kernels. That is compiled dynamically, in process, from Clojure funcion calls, and 95% of related code is the management code, which is written in Clojure. There is no separate C++ build. You never touch any C++ tools such as CMake or anything. You work dynamically from the Clojure REPL.

As a Pytorch user, I never touch c/cuda code. I never touch cmake. I can work dynamically from python repl. So, again, why should I care how those c/cuda calls are made if I don’t see them?

Because Clojure comes with a platform that supports AOT/JIT compilation out of the box, has several state of the art GC algorithms and in the near future even value types, while offering the same dynamism as Python, with all the capabilities of a Lisp in code manipulation.

Because Python is an ugly, inexpressive, and incredibly verbose language.

How much of a factor is the JVM for supporting this? In other words, I'm curious about how other lisps would fare?

I don’t think they are missing the point. These abstractions are far from perfect and trying to hunt down why something is not performing and tracing it back to how syntax is being interpreted as data is stored (GPU memory vs system memory vs sent over the pcie bus) or passed between other glue code is a source of frustration I’m sure many people have experienced.

It will take a lot for another language eco system to catch-up to something as broad and deep as python but these issues combined with the horrible experience that is dependency management with pure python vs compiled etc as well as the need for real-time/close to real-time systems, it seems very plausible that something like Julia or other llvm language will become the default over python for _these specific_ use cases, not in general though. Tooling on top of Julia can likely be far better and more easily made than living in python which is another aspect.

trying to hunt down why something is not performing

Again, 99% of the users won't be doing that no matter how good the tracing abilities are. They will post a question on SO/GitHub. Regardless of the language, modern DL frameworks are just too complex for regular users.

I watched an interview with him, his end goal is no code machine learning so when he is saying python isn’t the future it is because he prefers a type system that can’t be achieved with python.

I agree that users don’t care, I use Spark a lot and don’t care if I write scala, python or even c# now.

Have a listen: https://www.wandb.com/podcast/jeremy-howard

(I think I have paraphrased the podcast correctly :) )

end goal is no code machine learning

Now that I agree on. I suspect we will see something like GPT-5 reliably converting plain English into code sooner than Julia displacing Python as king of ML.

Perhaps the fact that 99% of users never write kernels is partial due to the fact that you need to switch languages to do so. Maybe a lot more users might want to write and modify GPU kernels if they had that as an easier option

Writing a fast CUDA kernel requires quite a bit of low level GPU knowledge. You typically do that when you really need it and it's not already available - like when you invented a new sparse GEMM algorithm, or want to speed up convolutions with binary weights/inputs. If you do need that, congrats, you're the 1%, and you're likely to not be afraid of mixing languages and getting your hands dirty with C++.

>Writing a fast CUDA kernel requires quite a bit of low level GPU knowledge

False. Not in Julia: https://juliagpu.gitlab.io/KernelAbstractions.jl/ https://github.com/mcabbott/Tullio.jl

To share the details, here's a post demonstrating Tullio.jl, a Julia-based higher order tensor library, is faster than OpenBLAS for gemm kernels:

https://discourse.julialang.org/t/realistically-how-close-is...

And PaddedMatrices.jl is another example:

https://discourse.julialang.org/t/ann-paddedmatrices-jl-juli...

So there isn't just one example but multiples at this point. RecursiveFactorization's `lu` tends to perform better than MKL for small matrices and this is what we use in the differential equation solvers when there are <100 ODEs.

That's all on CPUs though. KernelAbstractions.jl is the GPU version and that's still being constructed but moving strong.

For the person who downvoted me, care to refute my examples?

I haven't downvoted you, but from KernelAbstractions.jl docs it's not clear you will be able to write a fast kernel (emphasis on fast) without having as much GPU/CUDA knowledge as what's required to write the same fast kernel in CUDA. I might be wrong, and if so that would be great.

Here's an example: not long ago I needed a fast GPU implementation of numpy.unpackbits. I can do it in Pytorch, but it's slow and it wastes a ton of memory. So, my question is: can I write it in Julia as efficiently as I can do it in CUDA? If yes, will it be easier to do so?

KernelAbstractions.jl has some simple examples in its repo [^0]. The API looks simple and elegant. Code looks like regular Julia code. Documentation well behind CUDA, of course.

[^0]: https://github.com/JuliaGPU/KernelAbstractions.jl/blob/maste...

The code is essentially just Julia code:

https://juliagpu.gitlab.io/KernelAbstractions.jl/examples/na...

and you get ~60% of the best known CUDA implementation on that test:

https://juliagpu.gitlab.io/KernelAbstractions.jl/examples/pe...

Not perfect but not awful.

I’m sorry, what does it have to do with my question? I gave a specific example where I couldn’t get what I needed from Pytorch. Would Julia be any different in this situation?

>it's not clear you will be able to write a fast kernel (emphasis on fast) without having as much GPU/CUDA knowledge as what's required to write the same fast kernel in CUDA. I might be wrong, and if so that would be great.

What I showed was the the essentially no-knowledge pure Julia code gets to ~60% of the optimized CUDA kernel that libraries tend to wrap. Take that as you will for whether that means that means that a user requires to write a "fast kernel": it's a data point and if you define that as fast enough then Julia does it, or if you require 100% as fast as the fastest CUDA kernel ever found :shrug: it doesn't get there quite yet because there's a lot of people working on getting it there.

It answers your question because it's a specific case of KA's compile structured loops with annotations to low level CUDA code.

If you could express the problem in generalized index notation, tullio.jl is an even higher level abstraction that uses KA

I don't know about the numpy function you mentioned, but here's a KA matmul. Definitely doesn't look like it has any CUDA specific things. Just a regular loop with some restrictions

@kernel function matmul_kernel!(a, b, c) i, j = @index(Global, NTuple)

    # creating a temporary sum variable for matrix multiplication
    tmp_sum = zero(eltype(c))
    for k = 1:size(a)[2]
        tmp_sum += a[i,k] * b[k, j]
    end

    c[i,j] = tmp_sum

end

Wish I had time to write the code and compare to pytorch for you though

Here's a Tulio example. Tulip also provides source to source derivatives. Both KA and Tulio work in the CPU with the same code

using Tullio, OffsetArrays

# A convolution with cyclic indices mat = zeros(10,10,1); mat[2,2] = 101; mat[10,10] = 1; @tullio kern[i,j] := 1/(1+i^2+j^2) (i in -3:3, j in -3:3)

@tullio out[x,y,c] := begin xi = mod(x+i, axes(mat,1)) # xi = ... means that it won't be summed, yj = mod(y+j, axes(mat,2)) @inbounds trunc(Int, mat[xi, yj, c] * kern[i,j]) # and disables automatic @inbounds, end (x in 1:10, y in 1:10) # and prevents range of x from being inferred.

It's mostly just math!

One of the reasons CUDA wipedout OpenCL is due to its polyglot support, no need to get hands dirty with C++.

Fortran, Java, .NET. Julia, D, Rust and anything else able to either generate PTX or integrate with CUDA LLVM backend can be used.

And notably, CUDA.jl or whatever Julia package you use for gpu acceleration still has to incorporate CUDA, the same way Pytorch does.

So to the end user who doesn't want to write CUDA, I don't see why using a Julia package for gpu acceleration is any better than using PyTorch in Python.

Wrong. Julia can call out to Cuda kernels, but it also does codegen for custom ops and types. Technically with enough engineering time, someone could rewrite all those C cuda kernels in julia, and julia would just generate low level machine GPU code on the fly.

Pytorch on the other hand HAS to glue together c and c++ cuda code.

You mean like PyCuda?

Nope. PyCuda is writing inline C cuda and hardly integrated with python.

Julia has four layers of GPU abstractions, each being successively easier to use ( bit a bit less control. ), all in pure Julia and reusing the compiler and normal Julia abstractions and integrated with AD etc

CUDA.JL, GPUArrays.jl, kernelabstracions.jl, tullio.jl.

At the highest levels you just write normal loops or index notation and the code and backward pass generated. Also generic to backend-simd and multithreading cpu and soon AMD rock, intel accelerator and distributed

This all composed with deep learning libs etc

Indeed.

The main questionable implicit assumption that is made is that Python can't "the future" (which is severely underspecified without a time horizon) because of what is bad about it today. It even is literally there "Python isn't the future... It can't be" <because something in Python is bad>.

That's highly questionable, because it leaves out - that people appear to have reasons to adopt Python, likely because of something that is good about it, (this complements the observation that not that many people might be impacted by the disadvantages). - that Python and the ML tools in Python might not be static and actually evolve in "the future".

It seems to me a curious lack of reflection substituted for by being particularly assertive about it.

To my mind Python not being the future is more likely to happen if Python becomes less likable or the attempts to improve the shortcomings (which are there, HPy as a medium-term way to get out of the "C extension vs. parallelism/speedup/GIL" corner, mypyc/numba/TorchScript/JAX pushing the "what can be efficiently expressed in Python" boundary) fail.

Julia, Swift, Dex-Lang, HaskTorch all get things right that Python doesn't. But do they get all the things right that Python does get right?

Disclaimer: I'm biased because I like Python and have some involvement in Python ML tools.

Jeremy's literal statement is:

"Like Python is not the future of machine learning. It can't be. You know, it's so nicely hackable, but it's so frustrating to work with a language where you can't do anything fast enough unless you call out to some external code or C code, and you can't run anything in parallel unless you put in a whole other process."

So exactly the point made here.

Can someone tell me why ml/dl projects don't include even a requirement.txt or list of dependencies often?

I have always wondered why. I see so many projects that miss those. Projects from big companies and teams. Are they intentionally adding hurdles to using the code?

I get that a language like Julia is better for library writers, but in my opinion Python is better for library users, and that has more weight. It will drive faster adoption, making the library popular. Meanwhile, the easily-written better-language library gathers cobwebs.

I think Julia will gain some adoption replacing Fortran-, C- and C++ based libraries that can then also be used within Python. If you use any numerical packages, the above is already what you’re using under the hood.

I also think that not enough people are aware of the performance limitations of NumPy code and how much more straightforward it can be to drop into a lower level language once you cross a certain optimization barrier. This is where Julia can increasingly serve an important role.

This will not happen. There is so much hype around Julia and false claims such as Julia outperforming Fortran, etc. One can always design an isolated benchmark in which Julia outperforms any other language. But what people care, is performance in practice. And false claims will only hurt Julia in the long run, in the same way VolksWagen got badly hurt for its "US diesel emission fraud".

It's a compiled language with a close-to-baremetal type system and implemented as an LLVM frontend. I don't see what would make it slower than e.g. Fortran except for a couple more years of LLVM backend optimizations required (which I still think will happen given LLVM's adoption), but probably I'm missing something here.

And do you have any evidence that well written (but still high level) Julia isn't faster/as fast as fortran in practice?

Poorly written code in any language will be slow, so don't start with that.

Does Julia play well with Rust code? I see Rust as the future replacement for C++ so that would be important.

tbh. I don't yet see many use cases for that. or are there popular Rust numeric libraries I'm not aware of?

Here's one project idea: `sled` is a transactional KV store written in Rust. Might be fun to build an embedded DB in Julia using sled as the storage engine.

I don’t see anything intrinsic to Julia that makes it more difficult than Python. Personally, I find the language a bit more consistent.

Python is better for library users in the sense that Python has more libraries, but I remember not many years ago when nobody was doing anything serious in Python for statistics because the libraries were so poor and so few compared to R.

Julia has some great libraries being built that leverage some of the properties of Julia that Python can’t easily match.

Will Julia “beat” Python? Maybe in the sense that Python has “beaten” R. Note that R continues to do just fine, thank you. So too will Python do fine. But you may be surprised to find some killer libraries or frameworks that are firmly in Julia’s domain in the future.

As a library user, I far prefer Julia to python. With Julia I don't have to deal with python's ugly math syntax, terrible abstractions, SLOWWW custom types ) and 3-5 different array/collection "type" systems.

Jeremy has amended his comments regarding the viability of Julia Computing based on new information he received: https://twitter.com/jeremyphoward/status/1302678869158182912...

The financials are more secure than stated in the video. (I don't work there, but I'm a fan)

I love Julia, but what I don't get in this particular instance is to what extent it actually allows you to write code that you can't with Python. Sure, cassette allows you to do more powerful automatic differentiation, and various GPU arrays packages make writing code that runs on GPUs very natural, but it doesn't seem like that big an improvement over using a framework like TF / Pytorch / Numba in Python. Sure, those libraries aren't written fully in Python, but neither are Julia gpu libraries - you obviously have to convert to CUDA or similar code at some point to run on the GPU.

Julia brings great improvements in ability to write simple idiomatic serial code that runs at near C speeds on the CPU (whereas idiomatic Python code is at least 10x slower if you use an optimal compiler, and 1000x slower if you use the standard python interpreter). But for highly parallel code dependent on element-wise or broadcasting array operations, I just don't see the issue with Python.

""" [...] it is possible to perform kernel-like operations without actually writing your own GPU kernels: a = CUDA.zeros(1024) b = CUDA.ones(1024) a.^2 .+ sin.(b) """ [https://juliagpu.gitlab.io/CUDA.jl/usage/overview/#The-CuArr...]

As far as I know, that example code creates an ad-hoc kernel that performs the computation in a single pass.

I honestly don't know if that is possible in other frameworks.

Yeah, that's definitely available in Python frameworks. (I was wrong to mention Numba - I think CuPy would be a better example: https://docs.cupy.dev/en/stable/overview.html)

That's right, I found it: https://docs.cupy.dev/en/stable/tutorial/kernel.html#kernel-...

Calling out to array libraries in an interpreter (Python+Numpy, MATLAB, whatever) leaves a lot of optimizations on the table. The abstraction is not zero-cost.

For example, the simple array expression v+cw (where v,w are vectors and c is a scalar) can be calculated using fused multiply-add instructions. But this is not possible when called in an interpreter, which has to make separate calls for each array operation. For the same reason, this same calculation may saturate the memory bus. This is not an issue with Julia or other compiled languages. Not sure how Numba and/or PyPy optimizes it.

>neither are Julia gpu libraries

Julia is wonderful and I'm really hoping it catches on: https://julialang.org/

Unfortunately, it lacks a big-name sponsor like Go or Rust.

It has enough of them,

https://juliacomputing.com/case-studies/

Like I said in a another comment. To me Julia has the potential to be the modern fortran.

Python versatility is miles ahead. You can build Web APIs, Web apps, automation scrips, data scrapping and so on.

Python is not the de facto language of ML nowadays because its performance. All the underlying performance sensitive code is written is C/C++/Fortran.

Also, cython, which has great integration with python, is growing a lot and has been used in some cool projects such as aiohttp, fastapi, and spacy. So one more alternative to write fast code without giving up on python entirely.

I would argue that Julia can be similarly flexible than Python, but you have to be more explicit that you need this flexibility.

For instance, in python you happily add a string to the list [1,2,3], but not in Julia because the list has been created as a vector of integers. However, if you create the list as Any[1,2,3], then you can append a variable of any type.

> Python versatility is miles ahead. You can build Web APIs, Web apps, automation scrips, data scrapping and so on.

What? And you somehow cannot do that in Julia?

> So one more alternative to write fast code without giving up on python entirely.

I don't have to give up on Python, I can just use all libraries from Julia with PyCall. I'm just glad I don't have to use Python the language anymore than absolutely necessary.

> What? And you somehow cannot do that in Julia?

You definitely can. My point is that python libs are more mature and there are more options to choose from than Julia.

Julia libraries are plenty mature enough to be useful and Julia's 10x advantage in numerical computing far outweighs the difference in many cases.

Modern Fortran and C++ can be just as productive, and C++ based repls are starting to appear as well, which removes the dual language headache.

Python community better embrace JIT tooling, now that projects like TensorFlow and Torch are going polyglot.

What do you mean by JIT tooling?

Stuff like PyPy being used alongside CPython instead of a very interesting project that very few bother to use.

As somebody who is just getting into learning Python for web development and ML, am I better off switching to Julia right now? How steep is the learning curve compared to Python, and does it have a framework similar to Django for building web apps?

IMHO, no, stick with Python. Of course you can fiddle with Julia but Python is used in many fronts and much more versatile.

If Python were a blocker for the adoption and development of ML, it wouldn't be the default language of the most popular ML libs.

The reason is, the high performant code is written in C++/C/Fortran. Python is just used to glue everything and provide a nice and rich interface. That's what really matters.

To me Julia is more to Fortran than Python. And it doesn't have many usages outside numeric programming.

Scapping the Web, building rest APIs, Performing Data Analysis, Automation scripts is much easier in Python than Julia or Swift.

Edit: typos

Two years ago when I started experimenting with Julia and the Flux DL library, I paused to code up non numerical problems in Julia: web scraping, making REST calls, SPARQL queries, build simple web site, etc. Julia was OK for all of these tasks.

I am going to watch Julia adoption, and use it more, when and if it becomes more popular.

And It's improved by miles for those things

> much more versatile.

> To me Julia is more to Fortran than Python. And it doesn't have many usages outside numeric programming.

Again, you're making unsubstantiated claims.

> Python is just used to glue everything and provide a nice and rich interface. That's what really matters.

So, now I have to not only learn Python but also Fortran/C++/C because the underlying library that I might want to adapt is written in one of these languages. In Julia the DL library, for example, is written in Julia. What you are claiming is a pro is actually a con.

> Scapping the Web, building rest APIs, Performing Data Analysis, Automation scripts is much easier in Python than Julia or Swift.

That might be true for Swift, but certainly not for Julia.

So, now I have to not only learn Python but also Fortran/C++/C because the underlying library that I might want to adapt is written in one of these languages.

Basically the only time you'll want to do this from Python is if there is specific Fortran or C++ library you want to use. You'd have to do the same in Swift or Julia in this case.

Only if the library is not written in Julia, yes. The point here is that Julia is efficient enough that deep learning libraries can be written in pure Julia, not C/C++/Fortran.

And yet... no widely used DL library is in Julia, and they are all in Python.

It's kind of a silly point to try to score: "it's possible to write an efficient deep learning library in Julia (although no one has done it yet), and yes, you can do the same in Numpy in Python, and XLA in Python will outpeform it, but someone else wrote some C/C++ there to make that possible!"

You are much more likely to want to write CUDA kernels (in C!) than you are to write C framework code to interface with Python for machine learning.

The person is looking to "get into ML". I've been working as a professional ML developer for 6 years, and I've never written any C or C++ for it.

> although no one has done it yet

This may be generally true (though the benchmarks I've seen show Knet.jl and sometimes Flux.jl on par with TF/PyTorch with a single machine + single GPU), but there are definitely domains where it is categorically not. The most prominent one is neural *DEs, where the SciML [1] ecosystem has SOTA performance. You can really see Python/C++-based frameworks struggle here because they have slow "glue code" and don't (one could argue can't effectively) optimize for latency. That's not a problem for most CV models and transformers, but really stunts research into more dynamic approaches.

[1] https://sciml.ai/

This sounds more like it's a new field.

I started looking for benchmarks (because it sounds like the kind of thing JAX would do well) and the very first link I clicked included:

Wraps for common C/Fortran methods like Sundials and Hairer's radau

which is exactly what was claimed wasn't needed.

>I started looking for benchmarks (because it sounds like the kind of thing JAX would do well)

Currently Jax has an in-progress stiff ODE solver that's about 200x slower than SciPy

https://github.com/google/jax/issues/3686#issuecomment-65709...

and SciPy (with JIT) is about 50x-100x slower than the pure Julia methods

https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa...

so Jax has more than a little bit of a way to go.

Those aren't needed, but they are options. "he templated implementation allows arbitrary array and number types to be compatible, giving compatibility with arbitrary precision floating point numbers, GPU-based computations, unit-checked arithmetic, and other features. "

Those are exactly the things wrapping fortran and c won't give you

> So, now I have to not only learn Python but also Fortran/C++/C because the underlying library that I might want to adapt is written in one of these languages. In Julia the DL library, for example, is written in Julia. What you are claiming is a pro is actually a con.

You don't need to learn C/C++ or fortran. I've been working with python and ML for about 4 years and haven't touched any C/C++ or fortran to get work done. I agree that it'd be better if we could do everything with just one language but the truth is that Julia is not that language. It's great for HPC but expressive enough for generic things like Web.

How is it not generic enough for the web?

See https://genieframework.com/ and interact.jl

Once it can compile it web assembly (work in progress) it be the obvious choice.

No, use Python. Python is a good choice for web development, and will remain the de-facto choice for ML for the foreseeable future. If you plan on learning both web development and ML, that will be quite enough work without throwing a second language into the mix right away.

Julia might be a good thing to explore once you're up and running.

Don't worry, you will get a lot of good things by learning Python. And when you become comfortable with your first programming language learning new ones will be way faster.

The most important for newcomers is to pick one language and stick with it long enough to know it well (I would advise for a general-purpose programming language such as python). It will take time before you bump into its limits, and when that happen you can start to look around how things are being done in other languages.

If you're just learning, I guess it doesn't really matter. Just don't become one of those people who thinks Python is great because it's the only language they know.

My advice would be to use TensorFlow because it works flawlessly on Google Colab and in Jupyter notebooks.

The latter two are tools to send ML models and training pipelines around, so kind of like Google Docs for AI. Colab is on the internet, Jupyter on your PC.

That way, you can easily exchange your experiments with others and/or asks for help online.

Tensorflow is much worse than PyTorch, IMO. I wouldn't recommend it to a beginner in any case.

What are the main differences that make pytorch better?

You might want to recommend the Keras APIs for TensorFlow for people learning DL. The fastai and PyTorch libraries are also good when learning.

Agreed, with something like a C++20 JIT based workflows remove the dual language barrier, and then there is Julia, and other JIT based languages with GPGPU backends.

It's sort of one of those provocative statements that just mis-represents things to make controversy.

I also believe Python is not the future of ML but it's because the future is more about the space maturing and becoming commoditised and "boring" which probably means, being completely honest, things that people have no interest in happening like it migrating over to the JVM etc.

But who wants to talk about that?

I'm surprised nobody mentioned about D language for AI type of applications.

It's a very fast compiled language and compile faster than most of its competitors.

I supports interactive programming with rdmd and can work as a kernel inside Jupyter notebook through Jupyter's wire protocol[1].

It has friendly python vibe to it due to default to GC based ecosystem (but you choose to let go the GC where appropriate).

With the introduction of DPP, its FFI capability to C/C++ is second to none if the needs arise to interface with the existing libraries in those languages and it can also easily interface seamlessly with python and R libraries! [2]

It also has a growing library for big data analysis [3] and one of the main users of D is WekaIO, one of the prominent big data companies with the claim of the world's fastest file system for data storage [4].

If you insist on multiple dispatch style like Julia, you can emulate it as well in D [5].

If you want to see the glimpse of what D can offer for data science domain please check this "D is for Data Science" article [6].

Finally if you want to see D in action against Julia and Chapel for kernel matrix calculations that's common in AI type of applications please check this post [7].

[1] https://github.com/symmetryinvestments/jupyter-wire

[2] https://dlang.org/blog/2020/01/27/d-for-data-science-calling...

[3] https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

[4] http://docs.algorithm.dlang.io/latest/mir_ndslice.html

[5] https://en.wikipedia.org/wiki/Multiple_dispatch#D

[6] https://tech.nextroll.com/blog/data/2014/11/17/d-is-for-data...

[7] https://dlang.org/blog/2020/06/03/a-look-at-chapel-d-and-jul...

D is weird to me. Ive only looked breifly at it, but I liked what I saw. I'm assuming it had some early issues or completely failed to market itself for too long because it seems to see very little use compared to similar languages.

Yes, your impression is correct but D is still a young language compared to Python, and it just has been around for 20 years now (18 to be exact).

For comparison, at the age of 20 years (around 2010) Python was still playing a second fiddle to Perl, and at the same time Ruby was fast becoming popular due to RoR.

The good news is that now D already passed the growing pain problem regarding the transition from D1 to D2 (e.g. Tango library issue), very similar to Python transition from 2 to 3 that happened fairly recently, or perhaps it's still happening now.

tl;dr python is slow and cant parallel. Julia is better because it's fast and julia all the way down.

tldr;

Jeremy Howard says python will always be calling out to something else that's faster and more parallel. Writing fast python has too much cognitive overhead. He hopes Julia catches on because it's Julia all the way down.

I think that's one of the strength of Python:

- implement your work intensive logic with the adapted tools

- glue everything together with Python

I used to think that until I found Scala. It's easier than writing Python - I can write pretty much the same thing as I would in Python, but I have a more complete IDE and I can ask it what the types of things are. I'd never want to use a Java/C++-style language for exploratory programming, but it turns out not all reasonable-performance languages are like that.

I think you're trying to oversell here, Scala is bloated with lots of paradigms and lots of features. It's pretty hard to know what to use. Python in most ML frameworks is just a frontend, other beefy stuff gets processed by c++ or c

> Scala is bloated with lots of paradigms and lots of features. It's pretty hard to know what to use.

It's a flexible language, but I wouldn't say bloated - there actually aren't so many language-level features, but the features there are are very general. Some parts are simpler, e.g. in Python I struggle to remember which method you have to define to overload the * operator, whereas in Scala you just define a method called * . But I'd agree that there are a bunch of overcomplicated frameworks that can be pretty confusing - it's not always an easy language to get started with. But I stand by the statement that you can write Python-like code in it, at least once you know what you're doing.

> Python in most ML frameworks is just a frontend, other beefy stuff gets processed by c++ or c

Right, and that introduces a bunch of overhead and possibilities for weird errors - e.g. when you hit a bug in a library you pretty much have to learn how to debug C. In Python the benefits are worth it, but there's undeniably an overhead - if you could use the same language top-to-bottom but still have all the nice things Python gives you, that would be a much nicer way to work.

I actually do lots of exploration with C++ and ReSharper. There's excellent C++ libraries for everything these days. And cmake has made them easy to install.

I really don't see it. No first-class REPL and REPLs/IDEs will always be limited due to the ecosystem relying on macros; no proper dependency manager and certainly nothing comparable to maven central/CPAN/etc. And the language is missing even the most basic support for sum types, making its type system painfully restrictive.

conan and vcpkg are the proper dependency management.

Macros are less of an issue with modern IDEs, and that is hardly any different from any other language with macro support, including Scala.

Except, there are several languages as dynamic as Python that don't need "adapted tools", because they also offer AOT/JIT compilers in the same package.

How many times you've tried glueing C++/C code with Python?

It's a pain in the ass, and there is no need to pretend that it's great just because Python sucks (performance wise).

Ever heard of pybind11? It's easy as fuck.

How is that a strength? Why should you need to implement the work intensive logic in one language and glue it together in another?

The standard reply to this that has been repeated over and over is that for 99.99999% of the people performing such a task they are not going to implement the work intensive logic, they are going to use a well-tested and well-supported library that is built and maintained by domain experts.

Which can have bindings to every language in existence, thus diminishing even more the role of Python.

Given the choice between using library bindings in Python and similar bindings in C++ or Java, the world has voted with their feet. When it comes to easy to use glue languages, Python won.

Who said those are the only two options available?

Python seems to have won.

Yes! People who compare python to Julia miss the point. Python is not really used as a programming language, Python is the new bash.

Tcl did it first, look where it is now.

Alternatives abound.

Why would it diminish the role of Python ?

One of the strength of Python is its capacity to integrate with anything. We never said it was the only language with that strength.

With Python comes an ecosystem, another language another ecosystem. Choose the tool that fits your need.

That's a function of the available tools, not of the opportunities to do so. Julia makes writing custom kernels easy.

Reply on news.ycombinator.com