Now you’re encouraging me again, a bit. I want to do ALL of those things. I think Julia can do it. I think one of the benefits of them spending all that money on python is Julia can borrow from python and get similar performance for a fraction of the development price. We don’t need to re-invent algorithms, just re-implement.
I too have a desire to work in one language, but I think the beautiful of Julia is that our interoperability is stellar. So if you don’t have a tool you want, just use PythonCall. Or a ccall into C(++) etc.
Rustaceans want to “oxidized” everything because they want to reap the benefits of everything running through their awesome compiler. But we have the luxury of balancing rewriting when it makes sense and just calling out to other languages when the rewrite cost doesn’t make sense.
1 Like
Is it easier to program non-ML algorithms on the GPU using Julia than using other programming languages?
By the way, I just found an article (via Hacker news) about new programming languages and it talks about Julia.
1 Like
yeah, but then I feel like the only logical option then is for Julia ML to:
- stop developing any native Julia DL libraries / framework
- try to get Torch via PyCall or something and write whatever rules we need for it
and I don’t like that direction 
2 Likes
agreed. But I think the key is to make Julia be able to do some of these things maybe not quite as efficiently, but have some other major advantage, like for example composability.
1 Like
Another advantage might be to utilize the homoiconicity more. If you can express an algorithm in some syntax restricted to the kinds of things that can be made fast on a GPU and then take that syntax and transform it to GPU code then maybe stamping out hubcaps in Julia is just as fast as PyTorch or Tensorflow or whatever, and the DSL is much more ergonomic.
I think the goal is not being defined clearly. What exactly is the next level of popularity? What are the next two or three levels of popularity? Moving Julia into enterprise space is definitely NOT the next level, so let’s take the temperature down a bit.
There have been a lot of suggestions made to this thread addressing specific wants or specific challenges. I would imagine that Julia has some group that helps to do market research. Take surveys, find out what researchers need, programmers need, businesses need. Rate the results based upon where Julia is strong, and find that sweet spot between need, impact, and ease of implementation. Then start to seed projects to work towards those sweet spots like Google Summer of Code, or other similar initiatives.
As far as reaching the next level of popularity… that is a matter of adoption. It always will be. For now, Julia is a popular tool among researchers, academics, hobbyists, and a few other specialized professions. If the key to increasing adoption is building wrappers for well-established libraries, then by all means, do it. Don’t reinvent the wheel. As nice as it would be to have all Julia packages written in pure Julia, I think it is neither practical nor inclusive.
As a new user still learning Julia… I can relate to the challenges about up-to-date documentation and up-to-date instructional materials and examples. If the community can keep these materials up-to-date then new users will learn the language more easily. This is growing pains for any new language.
Julia already has amazing differentiators when compared to already well established languages. I think it is already capable of doing much of what Python can do, and getting better. If we keep a culture of quality software, make Julia easier to learn and adopt, and a focus on achievable technical goals, then we will grow in popularity. Furthermore, if languages like Python want to make wrappers to use Julia, then it only makes Julia look better, and begs the question “Why don’t you do the whole project in Julia?” One day, we will reach that point.
Thank you Julia DEVS and contributors!! 
6 Likes
I think more than anything Julia needs to become simpler and easier to learn in order for it to take off. Specifically, the documentation at https://docs.julialang.org/en/v1/manual/ is full of CS jargon and difficult for self-taught coders to understand. Case-in-point, the documentation on Types alone, if printed, takes up 36 pages. The entire language should be learnable while reading 36 pages of documentation, not just the Types. I think 2/3 of the documentation can be hidden under an “advanced” view flag, or something like that - stuff that experienced Julia programmers have learned they rarely or never used. The goal should be to allow a newbie who’s been coding in python for 2 years but doesn’t know CS concepts to learn everything they need to know about the language in 3h of reading. Everything they read needs to be high impact - not some implementation detail.
In order to facilitate this, we’d need a lot less stuff to document. Julia’s syntax allows for about 5 different ways to simple things, and we should reduce this to 1 or 2. I’m thinking for loops, function composition, and pipes as one example. We really only need 1 or 2 of those 3. Another example: julia has 11 different division functions (Mathematical Operations and Elementary Functions · The Julia Language). That should really just be 3 (float division, integer division, and modulo). The rest can be built from those three, can’t they?
The problem with having hundreds of functions in the Base documentation, is that it lowers the signal to noise ratio of “stuff I need to learn to get started”. I’d be find with these being in some math package or something like that, but still less is more. Another example: do we really need 5 different log functions or can we just have one, log(b,x)? Is log2(x) really that much better than log(2,x)? It doubles the number of functions to learn and only saves you one comma. Julia is riddled with decisions like that. I’d love to use a new version of Julia that is the minimal version - something you can learn in an afternoon and start writing code the next day.
If there’s some part of the Manual that is written to explain how some internals work because of the 1% of cases where the normal abstraction breaks down, let’s spend some time fixing the leaks in the abstraction instead of just patching it over with more Documentation.
Part of the reason julia has made it’s foothold in the data sciences is that Data Scientists and Mathematicians are probably the only people in the world who can tolerate this level of complexity/learning curve. 98% of programmers out there are just wanting to get something done and they don’t want to have to study a language for a month to know enough to read other people’s code or accomplish something. They just wanna learn something in a day and apply it the next day. The closer Julia can get to that goal the better, and it seems that so far we’ve done everything wrong in that regard.
It’s time to boil Julia down to it’s essentials so the rest of the world can see the great things it has to offer before their eyes glaze over and they decide it’s not for them.
6 Likes
Julia developers are slowly fixing Julia’s most problematic cons (according to the latest survey): cannot generate self-contained binaries, slow compile times and confusing error messages.
I keep wondering if the main problem for wider adoption is the lack of effective promotion rather than any technical issues.
1 Like
The issue with the Julia Documentation is not that one, actually. That Documentation is really great, once you have some experience with the language. The problem is on one side much simpler, which is that the Documentation link at the julia page should not point to that as the apparent first source of learning information. On the other side it is harder, because there should be another documentation page with more the characteristics of what you describe, and for having that someone would have to do quite a lot of work. Maybe something in the “learning julia” page is closer to what you describe.
Concerning the expectations of data scientists, I don’t think there is nothing that Julia the language can do about that. The 98% of people that want to get something done in 3 hours are not “programmers”, are users of some library/package, and it is the job of package authors show that they can get their job done in 3 hours.
By the way, I don’t think reading manuals is the entry point for learning anything, not even how to use a washing machine. This is one part of the python docs. I would bet money that nobody reads that as a learning source.
6 Likes
Not to derail your point about documentation (which is something I agree with strongly), but numpy has four variants of log as well (the same as Julia), and I don’t think this has kept people from learning it.
It’s a manual. What language are you comparing against? Let’s look at Python’s official tutorial, e.g. the chapter on classes:
https://docs.python.org/3/tutorial/classes.html#
I’d say the first four paragraphs are already full of CS jargons. Beginner programmers must be wondering why they’re hearing about Modula-3, C++, and Smalltalk in the tutorial… And when I go to the section on multiple inheritance:
https://docs.python.org/3/tutorial/classes.html#multiple-inheritance
The text on dynamic ordering of method resolution is not exactly beginner friendly, either?
The model of 4 types of documentation is really good, and what you’re talking about is learning oriented tutorials, and should be a separate document.
9 Likes
Speaking of which, I like the way Typescript (which may have a even more complicated type system than Julia!) approaches this dilemma: https://www.typescriptlang.org/docs/
They have a getting started on the left, written for people from diverse backgrounds who come to the language. In the middle, they have the handbook for “everyday” usage, where 90% of common usage is, and then deep dives and other stuff (cheatsheets) in the right.
It seems to work well since JS+TS is even more popular than Python.
I don’t particularly like the Python manual. It’s has a lot of cruft in it, which makes sense given the long time span of Python’s development, and the haphazard evolution of it over time.
4 Likes
I’m not comparing to other languages. I’m comparing to the ideal first user experience. If we’re going to innovate, that’s the thing to do.
And yes the manual is exactly what someone needs to read to get started (RTFM), but that means the manual should be much more approachable. Every other resource will just be examples and if you don’t read the manual you’ll not understand what you need to understand. But there’s a lot of stuff in there that i hope you god we don’t actually need to know to code in the language. Took me three days to read it over and half the time my eyes kept glazing over because i couldn’t think for the life of me how or why this should be relevant. Let’s fix the abstractions so they don’t leak, and then just teach the abstractions, not the gotchas. A first user experience with a hundred “things to look out for” is overwhelming. If we can’t fix things then maybe the software can look out for the things and print helpful messages with links to a specific page in the advanced section when they’re detected (if they’re rare). That’ll save everyone who will never experience that thing from having to read about it.
3 Likes
Any powerful language will have multiple ways of doing anything, that is unavoidable, unless you either explicitly disallow some of them in artificial ways, or make the language less powerful.
Function composition and pipes are related, but how does for loops fit in here? There’s no connection.
I could not find those 11 functions from your link.
It’s not:
Improving beginner documentation sounds like a commendable endeavor. Razing the language to the ground for advanced users in order to help new users does not.
16 Likes
A comparison of the document structure of Julia and JuMP, I think JuMP document is better for learning.
12 Likes
I’m afraid I don’t understand what’s wrong with the learning curve. Julia is simpler than c++/etc… and similar to python syntax-wise.
1 Like