←back to thread

ML needs a new programming language – Interview with Chris Lattner

(signalsandthreads.com)
311 points melodyogonna | 1 comments | 05 Sep 25 11:33 UTC | HN request time: 0s | source
Show context
postflopclarity ◴[05 Sep 25 13:59 UTC] No.45138679[source]▶
Julia could be a great language for ML. It needs more mindshare and developer attention though
replies(4): >>45138887 #>>45138911 #>>45139421 #>>45140214 #
singularity2001 ◴[05 Sep 25 14:16 UTC] No.45138887[source]▶
What's the current state of time to first plot and executable size? Last time it was several seconds to get a 200 MB hello world. I'm sure they are moving in the right direction the only questions is are they there yet?
replies(4): >>45139040 #>>45139081 #>>45139086 #>>45140797 #
1. postflopclarity ◴[05 Sep 25 14:34 UTC] No.45139081[source]▶
improving, slowly. 5 steps forward 3 steps back.

1.9 and 1.10 made huge gains in package precompilation and native code caching. then attentions shifted and there were some regressions in compile times due to unrelated things in 1.11 and the upcoming 1.12. but at the same time, 1.12 will contain an experimental new feature `--trim` as well as some further standardization around entry points to run packages as programs, which is a big step towards generating self-contained small binaries. also nearly all efforts in improving tooling are focused on providing static analysis and helping developers make their program more easily compilable.

it's also important a bit to distinguish between a few similar but related needs. most of what I just described applies to generating binaries for arbitrary programs. but for the example you stated "time to first plot" of existing packages, this is already much improved in 1.10 and users (aka non-package-developers) should see sub-second TTFP, and TTFX for most packages they use that have been updated to use the precompilation goodies in recent versions