Something about Julia from me.
I was big Julia fan using it for last 1.5 year and in my company we are using Julia for data preprocessing and parsing hundred of GB's of data.
(We also use Python for ML and start to moving julia code to Nim for data prepro)
If u consider Julia as ur next language dont use it to any medium to big project outside pure scientific purposes it just isnt ready yet.
We have about 3.5k loc in Julia at the moment for our preprocessing service and as much problems as we have with GC in Julia i never saw in any other language:
random crashesh, memory leaks, big slowdowns with long running processes and there is a lot of topic on julia forum about that still not solved.
Julia is beautiful and easy to use but it is nowhere near stable and/or fast as any other "new" languages (RUST, Nim, Golang, even Swift).
And if u consider using Julia for Deep Learning then best performance and stability in this order are:
Pytorch,
Tensorflow/MXNet/(JAX),
Nothing,
Flux.
Its a long way to go for Flux before it'll be even close in usability considering other flag frameworks.
We're using it in a soft-realtime setting to monitor industrial chlorine production, and for us it has been a very pleasant experience overall. Yes, we've had some issues, but similar to other ecosystem IMO, and our support contract with Julia computing helped us in the one case we really couldn't solve ourselves.
Julia works really well for power users. There are no huge libraries full of C code like pandas or scipy. Instead there are dozens of small, well-tested packages that fill the same role, all hosted on github. That makes fixing issues so much easier.
Granted: outside of numerical/technical computing, the libraries can be lacking (eg. web development) compared to other languages. We're doing it anyway, but it's a more difficult decision.
For data, we're monitoring ~1000 time series per plant, at about 2 points/minute. Julia's speed is not necessary there, but it is critical for historical simulations of algorithms.
> If u consider Julia as ur next language dont use it to any medium to big project outside pure scientific purposes it just isnt ready yet
My employer, Invenia, uses Julia for what I would say is at least a medium sized project.
~200k LOC, ~30 people concurrently working on that code base, literally the core product/system that makes us money.
Julia's not perfect, but I would not blanket discount it out of hand for medium projects.
Like all technologies the tradeoffs need to be investigated with reference to the task (and team) at hand.
> near stable and/or fast as any other "new" languages (RUST, Nim, Golang, even Swift)
This is not my experience, at least for numeric code. It generates faster code than Golang, because it uses an LLVM backend (and actually supports macros and parametric polymorphism, so doesn't need to do the work at runtime), faster numeric code than Rust via @inbounds and @simd annotations (way more work to disable bounds checks in Rust), and faster than Swift because it doesn't have pervasive reference counting that can sneak in and destroy performance.
For numeric code sure but its because Julia are using BLAS (or any other instruction for CPU/GPU u give to LLVM).
Julia (no BLAS) -> In matmul its on pair with Golang and Swift and a bit slower then RUST and Nim.
If u need BLAS then just use lib with that :)
I'm having a hard time trying to follow your argument. You seem to have had some issues with Julia, and I would like to take those issues at face value. It would be nice if you could point to specific issues since we always like to fix things.
However, in response to discussion about Julia having an integrated set of abstractions that provide high performance - you are discussing a collection of features in Rust, Go, Swift, Nim, TensorFlow, Jax, PyTorch, etc. For any single feature, there can always be some other thing that does it better. But it is unclear how that makes one system better than another.
Numeric code doesn't just mean matrix multiplication. If I have a random nested for loop, it will probably run at least as fast as those languages(apart from maybe Nim, never used it) if annotated with @simd and @inbounds. If I'm operating on a small array/matrix, then Julia will blow Go/Rust out of the water via stack-allocated static arrays (https://github.com/JuliaArrays/StaticArrays.jl). These can't be implemented in Go because it doesn't support type parameters, let alone integer type parameters, and is only recently supported in Rust via const generics, which as far as I'm aware haven't stabilised yet.
Here are my early experiments at making a pure-julia multi-threaded BLAS using LoopVectorization.jl https://github.com/MasonProtter/Gaius.jl. It absolutely blows a naive triple for loop out of the water and is quite competitive against OpenBLAS until you get to very big sizes.
For small, statically sized arrays, LoopVectorization + tripple loops is also much faster than MArrays. LoopVectorization doesn't support SArrays yet, because you can't get pointers to them.
MArrays will be stack allocated if they don't escape.
One of my in development packages also uses it's own "stack" (MMap a chunk of memory), so that it can have pointers to fast "stack-alocated" arrays.
I played around with LLVM's alloca a bit, but it seems like I could only ever use a single alloca at a time; if I ever used more than one, LLVM would just return the same pointer each time instead of incrementing it.
If I have to manage incrementing the pointers myself anyway, I may as well use my own stack, too.
For (the problems I have tested and tuned it on), LoopVectorization produces faster code than C/Fortran, e.g.:
https://chriselrod.github.io/LoopVectorization.jl/latest/exa...
But it may be more fair to compare it with plutocc. In my early tests (which involved much larger problem sizes), plutocc does a lot better, because (unlike LoopVectorization) it seems to consider memory/caches rather than just registers allocation and instruction costs.
@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard.
But True about GO in that particular case.
>@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard.
I agree it wouldn't necessarily be faster, but it also wouldn't be slower. Plus in Rust at least disabling bounds checks requires marking code as unsafe, which really gets the community's hackles up.
Your comment was fine. We're grateful to everyone who participates here even though English isn't their first language. HN is a highly international forum.
Sorry to hear that. I do hope you filed issues or chimed in on existing issues.
On deep learning, Flux has a different flexible approach. This is great for certain people. For people who want a library of existing models, Julia can already call TensorFlow and we didn't see the need to reinvent Tensorflow.
I'm also fighting the GC all the time, although I love Julia.
I wish I could tell the compiler to compile a function only if it can do it without using memory allocations. Often I would rather see a compilation error than the GC making performance of a function unpredictable.
I have not seen one, but I would really like to! It's one thing I envy about some other open-source language projects.
I also think Julia would benefit a lot from a list of "we want these but haven't had time for them". People like contributing things they know are desired, and with Julia it's hard to know whether people want or will accept something until you make the PR.
I really like the idea of Julia, and my biggest hope is that it can still replace the use of R in statistics and scientific computing, but I have to agree it is a bit unwieldy in larger projects or as a general programming language and that nim is really promising in this regard.
I have to admit that over the past 20 years, java is like the most stable robust, huge project, multiple teams, IDE friendly, type safe, infinite tooling and libraries language of choice!
This just isn't true. There's a lot of tooling nowadays that provides IDE-like features in text editors, or via command-line tuning. And different people work differently. Where some people use IDEs, others never leave the terminal and just use e.g. vim/emacs, a build system, and a debugger.
Not too surprising. Java was _designed_ by ex Unix engineers at a time that the word "engineer" meant something.
Now we have the cloud/web stack and _Javascript_.
The bar was low enough for Julia to sound good at the start, but it gives the impression of being "designed" "on-the-fly".
Luckily in some parts of the world engineer still means something by law, even in informatics, and one is not allowed to use it just because they went through a six weeks programming bootcamp.
Engineering implies scientific rigour and high intellect. So, no wonder software developers, usually a derided and mistreated collective, just love being called engineer...
Engineering (as in PEng in the US, but my jurisdiction just calls it Engineer) also implies liability, and a risk of losing your license if you fuck up.
Surprised by some of the negativity here! I've been extensively using julia for my graduate physics research and a lot of hobby programming for almost 3 years now and absolutely love it.
It's a beautifully designed language with incredibly responsive and wise developers and 1.4.0 is a great release I've been on 1.4 release candidates for over a month and haven't had a single issue, and love the new features and improvements.
The negativity is warranted if you've ever run Julia or had to maintain it in production. Use it for your own Jupyter notebooks and personal analysis? Great! Need to debug some weird obscure error (which Julia does a poor job of reporting to the user, let alone which line in the stack trace) while having production pressure to get it up and running again? Julia is unquestionably, unarguably and utterly unsuitable. Do not use it in any production workflow, heed my advice as a maintainer of Julia repos and the tech debt that graduate students have created in our company (I am sorry but just stating the facts). You're still unsure? Let's switch sides, you maintain our company's production Julia repositories and I will take your spot to write beautiful code in a couple of hobby projects. I guarantee you, with absolute certainty, you will come down to your knees. You'll lose sleep. You'll hate management for letting this happen.
I'm empathetic about your experience but I have been using Julia in production (financial services use case) for over 2 years and it's absolutely working great for us - developer productivity, performance, etc. We are not stopping and writing more Julia code at the moment.
To be honest, you can incur technical debt with any language. Software must be designed and maintained properly if you need a long-lasting solution. Research projects are also different than production code. Proper training and involvement with the developer community could help a lot.
My suggestion to everyone reading this thread - if you are new to Julia programming and need to work on a production project, do talk to Julia Computing folks. Their consultants can lead you to the right track. In addition, join the Julia Slack and Discourse community. You can almost get instant answers to anything you ask there.
Thank you, I can definitively say that some of the problems arise from poor programming practices than the language itself. But some languages are better at preventing people from writing bad code - see Rust and Go (impeccable packagement, project structure, memory management, RAII, etc) and Python (strict syntax PEP8/black).
Yes, as a grad student I'm not working on large production code-bases, but I am in contact with quite a few people who are working on large julia production code-bases and my impression is that it has worked well for most of them, hence my dismay at the sorts of comments I see here.
In my experience, one of the biggest problems is that people approach julia as "python or matlab but faster", which is going to be a recipe for failure. Julia is a very different language with its own idioms and very different style and if people try to just write Python with Julia syntax I can see how problems arise.
To be clear, I do definitely believe there are some big pain points in julia at scale, but depending on the usage domain and needs, my impression is that julia is an appropriate tool for at least some niches.
That's fair... although I generally found bad code that are not just bad syntax but rather bad design. Bad syntax or even project structure is easy to fix. Bad design is not.
BTW, this kind of discussion is healthy. The Julia core developers are already taking notes and I'm certain they will continue improving the language or ecosystem.
I wonder if the issue here is the graduate students part more than the Julia part (although obviously the tooling needs work). Maintainability is an art that comes with experience (or proper guidance), and I had to deal in college with a ton of really scary C code from other students (like all the program in the main function with 2000 lines scary). And in the same way in a professional scenario (in a polyglot company with mostly young developers) we had to deal with unmaintainable code in multiple languages, from Python to Scala. Even short scripts that were extremely tricky to reproduce in a more sane approach sometimes.
If my job was just that then I would certainly be heavily burned by it and I wouldn't want to touch the language. But the better solution would be to instead learn the language properly and create a serious guideline that everyone has to follow. If people can't use macros properly (or any of Julia's most powerful features), then every PR with a macro requires a very convincing justification and a review from a more experienced developer. If you're adding a new functionality then you have to be sure there isn't cyclic dependencies with other functionalities, and possibly making it a small independent library instead. And more importantly code is not done until it's properly documented, reviewed and unit tested.
I think that this is very insightful. At least in my experience, maintainable code isn't something that naturally arises. It comes from experience and interest in writing code that will need to be maintained. A lot of students (or academic researchers in general) don't really pay much attention to these things, which is totally understandable given their overall incentive structure.
I'm working with a computer science undergrad at the moment who put multiple full versions of his code to into the Github repository. He didn't use branches, he didn't use pull requests for updates, the diff log is just a new file that is the previous one with changes, all of which sort of defeats the purpose of using source control like git. But, as you say, it's something that takes some guidance and experience to understand. I do find that it makes me lean towards tools that encourage good coding practices by design and which make untying knots easier, which it sounds like Julia might not make super easy (I don't have any production experience with it). Obviously, the practices you laid out definitely help to make sure things don't slip through the cracks, though!
Julia is definitely trickier to control because it's an extremely powerful language. After all you can write even programs that can rewrite itself in it (like Cassette/Zygote, which is more than simply AST manipulation but full IR manipulation), there is no limit to how clever your program can be. But that level of introspection in the future could bring amazing linter capability to the language, that could detect all kind of bad practices as you type (for example type piracy, type instabilities, and possibly enforce customizable policies) which will become important tools as more people aim to use the language in production environments.
And until then the best practices for larger project using Julia's paradigm (Multiple Dispatch, which is by itself not as well understood as OOP or functional) will probably become more largely known. I feel like Julia projects should not grow large not because it's not suitable for large scale projects, but because even large scale Julia projects should emerge from the composition of many small and maintainable Julia projects.
I'd love to do a write up on the issues to guide the Julia team towards focusing on production and robustness, investing most of their efforts in a solid debugger support (Juno - totally incapable tool), and stopping all new features and "optimization" projects before getting these things sorted out. I am just too beaten, too bruised and injured to have the mental capacity to write an article. :( I am sorry if I am too harsh.
Harshness is not the problem, credibility is. I don't mean that you sound like you're lying, but that it's impossible for anyone to evaluate your assertion or how it applies to their use case. Anyone who reads your comment (including me) just files it away in their head as "somebody on HN made an unsubstantiated comment that Julia sucks in production in some vague way".
If I were in the position of making or advising someone making the decision of whether or not to use Julia, an unsubstantiated, untestable assertion like that makes virtually no difference in my decision or advice. I hope it's clear this is not an insult, it's just that if I have no way to evaluate your assertion or its applicability, there's no way for me to incorporate it into my decision or advice.
By contrast, if you could point to even one concrete example, I could file it away in my head as "someone on HN pointed out that Julia has X, Y, and Z problem". If I were in a position of making or advising a decision on Julia, I would be able to evaluate whether it applies the use case in question, whether it points to some deeper design problems with Julia, or whether I even think it's a problem at all.
You're right, I see the problem. I'll do an article and post it with detailed analysis. It will take some time because repos are like Tolstoy's quote - "All good repos are alike, every broken repo is broken in its own way". There are issues ranging from startup time, upstream packages breaking, constantly changing ecosystem (given for a new language), quirky behaviors and certain problems related to HTTP package and LibPQ packages that I couldn't even debug. So, I rewrote them in Python.
Until then - I concede, please take it with a grain of salt and use your own judgement.
It's quite possible that certain area of the Julia ecosystem are not not mature enough. The situation continues to improve quickly as far as I can tell.
Rather than rewriting code in Python, we took an approach of using PyCall. It turns out that the overhead of calling Python is very small... at least not to an extent that I had to worry about. For my production system, we used this strategy to access Oracle and Apache Kafka. The code still looks very clean as the calls to the Python packages are just like normal Julia function calls.
I can't fault you for switching to something more battle-tested, but did you file issues for the LibPQ.jl issues you encountered? I wrote and maintain the package and we (and others) use it in production so bug reports are much appreciated.
Ah okay. Bummer. I wasn't necessarily asking you to write it, but maybe others have documented similar problems. I don't use Julia, but would love to here more detailed production environment experiences.
I've thought about this problem, quite a bit, and I think that productionizing Julia would require at least a few additional things above your criticisms about error codes.
1. Get rid of global dependencies. Store all of your dependencies in a project local deps directory with a project lock file.
2. Opinionated file system structure. Maybe you don't need this in one-off scripts but definitely for some sort of "project" layout
3. Force all packages in the package manager to obey these constraint.
You are describing every Julia package.
These are the rules of the package manager.
1. Every package must declare it's dependencies (and to register must declare compat bounds on them, and good devs do that always anyway)
2. Every package must have Project.toml in the base directory, source code goesin `src`, test code goes in `test`, documentation goes in. `docs` (and more structure there if using Documenter.jl)
What more could one want? If a package needs more folder structure within `src` then it should be multiple packages.
3. These are the rules, done.
Further you are describing every sensibly done julia application.
Basically no seriously Julia developer uses the global environment for anything but dev-tools, like BenchmarkTools or ProfileView.
Certainly one does not depend on the content of them for any reused code -- that is what Project.toml and Manifest.toml is for.
Can you point me to some documentation on those best practices. My girlfriend - architectural acoustics consultant - is working on a project in Julia and is having a hell of a time managing dependency shift underneath her program (also she barely knows how to use git).
Sadly I can not point you to a single piece of documentation that covers everything. That's definitely an area Julia can improve.
Writing down the things "everyone" does, so newcomers don't have to learn them again.
And the section on creating one's own project. So as not to need to use the global environment.
And alternative to using `activate` after starting Julia (and my preferred way) is to start Julia with the `--project=.`
And can go further and create projects via PkgTemplates which is was "everyone" does.
Because a good project looks just like a package (one might as well consider them synonyms when looking for thus kind of advice)
https://github.com/invenia/PkgTemplates.jl/tree/v0.6.3
It's got anaconda-like project spaces? While I can see why they did that because it's what people are used to... That's a terrible, terrible choice (I joke there's a reason why docker got invented and it's that conda is awful). Why not just put deps in the project directory instead of in ./julia/..
What's the issue about global dependencies that you're trying to solve? For my production system, we manage version changes by way of Manifest.toml so that we don't get any surprises.
I agree that an opinionated file system structure is nice. Julia already wants you to put source code inside `src` but then underneath you are free to do whatever you want. We generally manage this via coding convention since people can never agree on a standard.
To answer the usual complaint whenever the release announcement gets linked here, the NEWS file is intended to give current users of Julia an overview of all the things that changed that they may want to adjust to. It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening. We've been talking about writing a more casual document like that for the releases, since they do tend to get a fair bit of attention, but that's just one more thing on an already-extensive list of things that need to be done for each release.
”It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening.
The NEWS file may not be designed for that, but IMO, it still is way better than this text, which, for casual followers, doesn’t say much more than “1.4 replaces 1.3, no breaking changes, a few new features”, without even mentioning those features, or why they were added.
Maybe, combining the two in a single document, and copy-pasting NEWS.md in the announcement, would decrease the amount of work and improve things?
Looks like Julia still haven't managed to handle updates well.
I remember being so amazed that they'd blown their 1.0 announcement (went from 0.7 to 1.0 over a Juliacon).
And because there were so many changes (most of which i thought were good), it was pretty broken for new users at that time, which I firmly believe limited their adoption.
And to be clear, I love the idea of Julia, and that first document made me fall in love. And I think that the design for statistical computing is really, really good.
It's just a shame that this ops/packaging stuff is holding them back.
The 0.7 to 1.0 was a planned move that was communicated for over a year. If anything, the 1.0 transition went very smoothly and the Julia community grew significantly soon after its release. All the download and community stats broadly demonstrate this.
IMO, 1.0 was rough not for new users but people who had invested a bunch of time in Julia codes pre 1.0. We anticipated this and therefore had a very carefully planned release strategy to ease the transition with depreciation warnings and preparing 0.7 as a migration aiding release for 0.6 users to 1.0. In fact our release announcement discussed all of this at great length.
> The 0.7 to 1.0 was a planned move that was communicated for over a year.
That sounds as if the communication was of the “1.0 will be released at this date one year in the future” kind. But it was more like saying for a year “it will be finished and released someday” and then, according to the wikipedia, “the release candidate for Julia 1.0 was released on 7 August 2018, and the final version a day later”.
Releasing at JuliaCon was always the communicated goal, though admittedly with a bit of a hedge that we may not manage to get it done. As for the 1.0RC business, 0.7 and 1.0 are the same release except that 0.7 includes additional depreciation earnings that are not in 1.0. This decision was made to keep with our communicated policy of having at least one versions where deprecations would produce a warning. There were a number of 0.7 release candidates in the months leading up to the release. Since the changes in 1.0 were minimal over 0.7, it didn't need extensive validation and the one day was enough to make sure it worked. Would a bit more time have been better? Sure, but in retrospect it was totally fine. 1.0 was a fairly solid release and has gotten more solid with the LTS patch releases that many people still use. The big problem was packages in the ecosystem needing 2-3 months to catch up, but I'm not sure that could have been avoided. One of the learnings we have is that most people won't upgrade their software until the new version is released and upgrading is absolutely necessary.
So, for me at least, the issue was that I downloaded 1.0 (having played with Julia in the past).
When I tried to install packages, I got errors after error as a result of deprecation warnings from 0.7 becoming errors at 1.0.
Again, I really like Julia, and want it to succeed. But the 1.0 situation put me massively off, and killed my plans to start evangelising Julia at my company.
I really enjoy using Julia too but I have also been disappointed with how the updates have played out. Just a few weeks ago I rolled back my installation from v1.2 to the LTS version because of silly errors in the plotting package not allowing me to plot.
Otherwise it really is a pleasure to use, and I have found that the LTS install has zero compatibility issues thus far.
Glad to hear that the LTS version did not have an issue.
I hope you did file an issue with the Plots package. The reason is that we generally like to make sure that regressions like these are not language level regressions. Sometimes package use undocumented internals - but we generally chase each and every single one of these.
It's natural that you'll get publicity and curious onlookers when doing new releases -- might be worth considering that natural audience, too, when writing the NEWS file.
Right, we're of course aware of that audience, which is why I posted that comment. The way the NEWS file gets written is just that each individual commit that makes a change that needs end user attention will add an entry in the relevant section. This is quite hand as people can just 'git blame' the file and automatically find a link to the relevant commit (or they can click through the linked issue). What's missing is a more high level narrative structure of changes in the release, but such a thing would have to be written once the release is done. Usually we do that in the form of a blog post announcing the release. However, invariably, these things end up on HN the second somebody thinks the release is done (or even just for early RCs).
The language has a lot of really nice stuff and the introduction of threads and support for them in the standard libraries (beginning in 1.3) has helped us a lot.
That said, the tooling is still frustrating. Generating compiled binaries is a slow, painful process.
Julia is an amazing, elegant and beautiful language. It's almost perfectly suited for scientific computing and ML. However, I'm not very bullish on its future given s4tf
Swift can get you 90% of the way there, and that extra 10% can be more than made up the by the efforts of apple, google and other companies (including money, network/clout, kaggle which is owned by google etc). Despite predictions to the contrary, Chris Lattner's departure doesn't seem to have slowed down the project, and more team members from google have been added since.
Swift is rapidly approaching usability on windows with investment from google.
Further, at some point google will facilitate Swift's use for android apps, and then Swift's popularity will skyrocket, and all those developers will be naturally inclined to check out the ML stuff. Even facebook is getting in on the party: https://twitter.com/nadavrot/status/1241150682104606720
In addition, Swift has its own benefits over julia for production and large codebases, such as compilation to small binaries and static typing. Julia doesn't have a good story for either of these (yet?), and chasing down type instabilities in larger code isn't fun.
You mean the future of Julia or the future of Flux? While an amazing accomplishment (that is still on the way of becoming truly mature, just like s4tf), Flux is just one of Julia's current ML libraries, and it definitely doesn't feel like a Rails (or maybe Flutter) situation in which the library is larger than the language. ML isn't even Julia's core target (it just happens to fits extremely well with numerical and scientific processing).
Julia will be just fine even if s4tf somehow steals all the mindshare (especially since a mature differentiable programming library will inevitably serve as inspiration for Flux itself) as the language and target audience is not very similar to Swift's and as such Flux and s4tf will also find different niches (for example one can be more used on high performance scientific research thanks to Julia's ecosystem and focus while the other can focus on mobile deployment of ML models).
Who is going to make the scientific ecosystem? Julia and Python's scientific ecosystems are so strong precicesly because they get domain experts in those ecosystems to write the software they need for their niche.
Machine learning programmers aren't about remake DifferentialEquations.jl or scipy in Swift. I've yet to meet a single scientist from a field outside of machine learning who was seriously excited for swift. This sort of machinery is hard to make and takes deep expertise, I really doubt it'll be made in Swift any time soon. Does swift even have plotting libraries yet?
Swift has a good automatic differentiation story, mostly because it is very focused on machine learning use-cases, has corprate backing and all efforts are on one implementation. However, having only one automatic differentiation implementation has drawbacks. It won't be suitable for everyone.
Julia on the other hand has a gigantic basket of different automatic differentiation tools all of which have strengths and weaknesses. This allows people to choose the right tool for the job and explore a very wide design space, allowing us to find which approaches work best for different circumstances. Our AD machinery is still evolving and definitely has problems, but progress has been fast and really encouraging.
Even if Swift becomes the next Python and eats scientific computing, I strongly doubt this will seriously hamper Julia's community. We've been doing great living in Python's shadow. Julia doesn't need to be the most popular language in the world to be useful or successful.
Google and Apple are not going to make a full on scientific ecosystem because they don't have the domain experts or the motive.
Numpy is not the same thing as scipy.
DifferentialEquations.jl in julia is a great example of what it actually takes to make a real, competitive differentiation equation library. The sort of stuff that was built there requires a deep connection to the scientific and mathematics literature. Cash won't cut it.
Another great example that'll resonate with physicists at least is things like ITensors.jl https://github.com/ITensor/ITensors.jl. Apple and Google are not going to make something like that.
It's not JUST google and apple, I'm sure they have enough cash and expertise and will to create enough momentum to attract more domain experts in other areas. Especially once google brain and deepmind start working on things more complex than stacking layers, which is happening now.
In particular, do you have another example aside from DifferentialEquations.jl ?
Neural ODEs are hot enough that something like that could easily pop up in swift.
> It's not JUST google and apple, I'm sure they have enough cash and expertise and will to create enough momentum to attract more domain experts in other areas.
Maybe, but I'm doubtful. Scientific domain experts flock to languages like Python, Julia, Matlab, R, etc. because they're interactive and allow them to quickly iterate on ideas, query data, produce plots, etc. Swift is not much of an interactive language and is not built around that kind of repl driven experience.
> In particular, do you have another example aside from DifferentialEquations.jl ?
Sure, here's a smattering of high quality packages made by and for research scientists:
Apple doesn't care for anything that doesn't work on their OS.
Unless they show to be as committed Microsoft is with .NET Core, Swift will have the same support as Objective-C has had since NeXT days.
As for Google, I still don't believe that they are that committed as well, Chris Lattner left, and SF4T appears more on Reddit and HN comments than on any kind of Tensorflow official communication channels.
If it wasn't for the valiant effort of one single developer not employed from either of them, Swift for Windows wouldn't even exist.
Yes, they hired him, at the end of the race, after he has done everything on his own without any kind of Google support.
On my book being committed, is paying for the race at the start.
When TF4S delivers even the half of what ML.NET or Julia allows for on Windows including IDE, libraries and tooling support, today, and they actually start doing a bit more information then what gets given to Python, C++ and JavaScript then they are actually committed.
I mean, I can't really guess the future, but I kind of feel it's not a simple case of "if you build they'll come" here. Python has a dominance over ML (and over the academy in general) that is beyond any current language, but it didn't bring it's statistics ecosystem to the level of R (and statistics is much closer to ML than pure math and physics). That's because the ML ecosystem does work very well in isolation (it's mostly a black box regressor), and the natural path of evolution is not in different way of processing things, but ways of preprocessing things (for example, how to capture and treat images and sounds before applying the models).
And in this marathon Julia is a very late runner, and Swift didn't even start properly running in this direction.
I think google will invest in the scientific ecosystem since they've shown some interest for diff programming using scientific models, and these are becoming more mainstream, even in pytorch.
Tensorflow Summit came and went with zero information on Swift for Tensorflow, it was all about JavaScript, C++ and Python.
Swift is mostly useless on Windows, with Windows users being told to use Google's cloud infrastructure for doing anything serious.
Even Apple apparently is hiring Rust developers for server side development on Linux, instead of improving Swift's history on Linux.
Keep hoping for Swift on Android, it will never happen, if that depends on Android team, Kotlin/Native might have a place on the NDK, Swift never will get one.
There are also frequent commits to swift master and projects like swift NIO working on windows compat, from google. Also the S4tf stated they had future plans for swift on android.
The difference is that S4TF is an internal google team. I can't imagine they wouldn't coordinate with the android team, especially given the benefits that easy ML will bring to apps.
I wish it had more dedicated IDE besides the atom/electron based ones (like GNU Octave has its own). I think Julia's performance deserves an equally performant IDE.
This. I have been trying to learn Julia so I can promote it to replace Matlab in my company. I think everyone will like the performance, and a more modern and extensive library (also the fact that it's free will save the company a lot of money). But the atom Juno IDE looks so unprofessional, I think we will have a really hard time convincing scientists to use something which can't even undock the editor properly (I know we can open the file in a new window but it's really not the same).
Yeah, that is my guess too. But at least VS code can save your workspace in atom you have to install a package to do that. To programmers it might look like flexibility but to non programmers it just looks like a chore.
I don't really have issues with the performance of Visual Studio Code even though it's electron, but with Julia I mostly use it for the syntax highlighting, linting and autocompletion (plus version control and other external tools). I find it much easier to have a Julia instance running on a drop down terminal or in the second monitor for easy access, Revise so every file I save is automatically loaded in the REPL session and some extras like Rebugger, Infiltrator and OhMyREPL for debugging and some niceties.
This way I can just immediately query and test things using the language itself without having to deal with any sort of constraints or quirks within the editors. And the Julia REPL allows for quickly switching to shell (just pressing ;) when needed. I would hope they keep improving the REPL (and the editor support features like linters) over focusing on a completely new IDE (there is even more potential when considering Lisp languages REPL, plus general usability improvements like first call latency), but I'm biased and that's not the workflow most developers use.
I've been meaning to check Julia out for a while now. Are there any deep learning libraries that are as feature complete and user friendly as PyTorch/ Tensorflow?
I have been using Flux for a year (or more?) and I have never found it to be slower than PyTorch or TF. Granted I am training at most ResNet-20 and mostly smaller models, so maybe there is larger training routines where people have issues. Every single one of these deep learning libraries is mapping to CUDA/BLAS calls under the hood. If you wrote the framework correctly, the performance difference should not be drastically different. And Flux doesn’t have much in terms of overhead. My lab mate uses PyTorch to train the same models as me and his performance is consistently the same or worse.
As for features, I think this is because people coming from TF or PyTorch are used one monolithic package that does everything. That’s intentionally not how Flux or the Julia ecosystem is designed. I’ll admit that there are a lot of preprocessing utility functions that could be better in the larger Julia ML community. But for the most part, the preprocessing required for ML research is available. This is mostly the fault of the community of not having a single document explaining to new users how all the packages work together.
Where the difference between Flux and other ML frameworks is apparent is when you try to do anything other than a vanilla deep learning model. Flux is extensible in a way that the other frameworks are just not. A simple example is with the same lab mate and I trying to recreate a baseline from a paper that involved drawing from a distribution at inference time based on a layer’s output then applying a function to that layer based on the samples drawn. I literally implemented the pseudo code from the paper because in Flux everything is just a function, and chains of models can be looped in a for loop like an array. Dumb pseudo code like statements where you just write for loops are just as fast in Julia. And it was! Meanwhile my friends code came to a grinding halt. He had to resort to numerical approximations for drawing from the distribution because he was forced to only use samplers that “worked well” in PyTorch. This is the disadvantage of a monolithic ML library. I didn’t use “Flux distributions,” I just used the standard distributions package in Julia.
This disadvantage to TF and PyTorch will become even more apparent when you do model-based RL. Flux was designed to be simple and extensible from the start. TF and PyTorch were not.
Ok my fault i was writing from perspective of ML engineer not reasercher (I'm using Julia for 1.5 year now and my bois reaserchers prefer pure julia solutions cause its easier to write u can use symbols and not using OOP etc.)
But for production ready models PyTorch and TF is miles ahead first of all: NLP, audio and vision based packages building frameworks, (attention layers, vocoders etc.)
then u have option to compile models using XLA and use TPU (about 2/3 times cheaper then gpu for most of our models [audio and nlp])
Next inference performance (dunno about now maybe this change but about ~8 months ago flux was about 15-20% time slower [tested on VGG and Resnet's]then pytorch 1.0 without XLA)
Time to make it to production: Sure maybe writing model from scratch can take a bit longer on PyTorch then Flux (if u not using build in torch layers) but getting in into production is a lot faster, first of all u can compile model (something not possible in Flux) and u can just use it anywhere from Azure and AWS to GCP and Alibaba Cloud make a rest api using Flask/Fast-api etc. or just using ONNX.
Dont get me wrong i love Julia and Flux but there is still a LONG way before most people can even consider using Flux on production enviroment not for reasearch or some MVP stuff.
I have no special insight into ML or Julia (though I love it), but one thing I can confirm from experience is that there is a huge difference between getting a model work once in an academic or research setting, and having something reliably and scalable work in production day after day. Mind boggling, totally different challenges.
It depends what you're doing. If you need to write your own kernels, or have small networks where the framework overhead is significant, then it's way faster than Tensorflow (unless you implement your own Tensorflow OP in C++/Cuda, but that's way more painful than just implementing it directly in Flux/Julia). It's hence quite nice for research on new architectures. Flux's autodiff also handles more language features than TF or PyTorch's.
> unless you implement your own Tensorflow OP in C++/Cuda
I don't know exactly what 'OP' means, but there are other ways to do ML in for example C++. I have some good experience with dlib, PyTorch's libtorch is on my todo list.
>I don't know exactly what 'OP' means, but there are other ways to do ML in for example C++.
I think Flux really excels when you're trying to do ML as "differentiable programming" (e.g. model-based reinforcement learning), because it can differentiate so much control flow via Zygote, which hooks into the compiler and differentiates the AST: https://github.com/FluxML/Zygote.jl
What is the state of Julia dataframe? Is it ready for production use? How is the Julia dataframe performance in comparison with R and Python dataframes?
My employer uses DataFrames.jl in production.
It's fine, nothing wrong with it.
Used to be a bit unsafe to unwarey uses, now it's safe by default and you need to do a bit extra to get all the performance.
It's worth knowing it is more like R's DataFrames than like Pandas.
It is getting pretty close to a 1.0 release.
Probably a few months out
(One more minor, then if all goes well 1.0 a month or so later)
Further one should know that there are many tabular data packages in Julia and they all use the interface defined by Tables.jl, and all interop very well.
Query.jl (which is something like Linq or TidyR) works with all of them, and do packages for loadingand saving (CSV.jl, LibPQ.jl etc)
