Get it together, guys!

Community
21

You have a mistaken impression about the development model of Julia.

There is no single person or entity “behind” it: like most open source projects, it is a collaborative effort. People work on what they consider important. This, of course, may not coincide with what you consider important.

There are many people using Julia to their advantage in the “real world” in research and the private sector. This is because despite some rough edges, Julia is already incredibly powerful and its advantages outweigh the problems for most people. If this is not apparent to you, then you may just not be its target audience, so you should indeed consider using something else. This is fine.

Finally, if you are still entertaining the idea of using Julia, please understand that rants like this are not very likely to change anything about the priorities of people who contribute to the language or packages. The only way to do that is to become a contributor yourself.

32 Likes
22

There is no single person or entity “behind” it: like most open source projects, it is a collaborative effort. People work on what they consider important. This, of course, may not coincide with what you consider important.

That is a bit disingenuous considering how many core contributors seem to be employed by julia computing. However, the rest of your sentence 100% applies: people and companies work on what they consider important. In this case, I imagine (although that’s pure speculation on my end) the money these days is in displacing python/tensorflow, not matlab/simulink, so comparisons with matlab are unlikely to carry a lot of weight as a business case.

The reality remains that julia is a small language right now. With a larger audience, you have companies that can invest in tooling (because it’ll save them money in the long run), and volunteers that are motivated to undertake the ungratifying task of building debuggers and GUIs because they know it’ll make a lot of people very happy. Right now the core devs appear to focus on the fundamentals of the language, which I think is a sound strategy: become the default option for power users in a niche, then expand from there. You’re just there 2-3 years too early :-p

19 Likes
23

Rule of thumb for these kind of posts (sorry for repeating stuff):

  • There is almost never a lack of awareness for problems - especially if they contain broad issues like these that are immediately immanent.
  • Almost always, there is a lack of resources to tackle the problems.
  • if you’re unhappy and things don’t work the way you expect them, maybe it’s simply too early to adopt

Constructive alternatives, if you’re willing to invest (note, this won’t be a 10 min “i post my gripes to discourse” effort):

  • mobilize resources
  • be the resource (a.k.a become a contributor)
  • Lots of projects aren’t started because it’s fuzzy what needs improvement and what the actual problems are. Forumulating an actual strategy to improve things, like in a design document or a sophisticated project description could really help with this. You don’t need to become a contributor, but planning a project takes a lot of resources so writing out a nicely scoped project with API details figured out can already help a ton and might just trigger someone to start working on it. Note though, that this usually requires indepth knowledge of the problems, so it’s pretty likely that you already need to be a contributor to create a helpful project description. But e.g. for the debugging, you could write a document that nails down your current problems, explicitely formulating why you think they are a problem, and best containing sketches of what you expect. If this is well done and well received, it may actually help someone start working on it;)

So all in all, there are no shortcuts to improve Julia - It’s simply a lot of work by everyone…:wink:

42 Likes
24

I appreciate your comments, but my point is a little different.

I’m not exhorting the team to work harder - I’m suggesting reordering priorities.

I would argue that adoption and growing your base is the best thing for the entire community. It will increase your available resources and enable you to do more.

The theme is common among colleagues that I talk to that are considering the language - adoption right now isn’t being held back by language issues, but by environment issues.

I know several people who would like to use Julia but just can’t justify it in a professional environment at this time.

But it’s getting closer, and I want to encourage the effort to push it over the top. People like me want to jump on the bandwagon, but we have bosses or investors that we have to be able to look in the eye and say that we’ve made a responsible decision.

There’s a pent-up enthusiasm for the language, if it can just get the last bit of the way there in terms of usability.

1 Like
25

I think a point that has not been made yet is that Julia can evolve to behave like you want it to, but on the other hand you (as a user) can also evolve to work in more Julia-compatible ways. I think it takes a lot more than a few hours to learn Julia (or any language, really) and if you’re willing to invest that time, you may find that you end up having a very different workflow what you anticipated or what you are used to.

Sometimes this is for bad reasons: you initially had rightful gripes with the language, but after some time you get so accustomed to workarounds that it does not bother you as much any more. Other times it is for good reasons: you understand that it is more efficient to work differently in Julia than what you were used to.

An example of this is that people coming from python are often used to a workflow where they (i) write some script, (ii) fire a python interpreter to test it, (iii) modify the script and go back to (ii). Such a workflow works very well in python, but not so in Julia, where it is more efficient to have a long-lived REPL which runs the various versions of the code as it evolves. Coming from Matlab, where the workflow is almost the same, it is normal that you are only surprised by the need for things like Revise, which are not needed in Matlab. If you had come instead with python background, you would perhaps have been more surprised by this whole development process involving a long-lived interpreter.

So I guess my conclusion is: some of your gripes might disappear with time, but getting to use Julia in a Julian way is going to require some investment (and that would probably be the case even if the Julia development environment was up to your expectations)

13 Likes
26

I’ve used rust, go, and Julia all pre-1.0. I used ruby and python before package management was stable. I used scala and clojure and nodejs in their very early days, as well as mongodb. Historically speaking

Julia does not have a usability problem.

More specifically, I’ve worked in startups my whole career. Ironically they tend to be very conservative in tech choices, where the usability problems are well known and normalized.
Besides Matlab, I’m curious what languages are considered usable?

9 Likes
27

I don’t think this is a viable route of contributing.

It is not very useful to design an API for a package in any language without being at least a semi-experienced user of that language, and I am not sure that there are many people in an open-source project who would find specs useful from someone who is otherwise not willing to contribute and is not a user of the language.

I think that it is important to realize that at this point, Julia and its ecosystem are mature enough that one needs to be a regular user, and in most cases at least an occasional contributor to even see the most important problems and their interdependence. Naturally, the fundamental problems require quite a bit of perspective:

Realistically, at this point people who don’t even use Julia are likely to have zero impact on its development (except if they are well-recognized in another language community Julia can learn from).

9 Likes
28

I agree, that’s why I added the note “realistically, you would need to be a contributor for that” :wink:
But in the case of a debugger UI, I can see how a user could actually make a sophisticated contribution in terms of figuring out an improved user experience! Stuff like this is really hard to design, but sometimes easy to implement. But it would still need lots of work to figure out all the gotchas, to actually take away work from the developer.
edit: there is also a high chance that something like that will be dismissed - so It’s kind of risky to put work into this, if you’re not willing to implement it yourself in the worst case.

I’m not exhorting the team to work harder - I’m suggesting reordering priorities.

@Brad_Hines By “awareness isn’t missing” I also meant, that awareness that priorities could be ordered differently isn’t missing.
The core devs discuss this almost daily and came up with the current priority list. There is a small chance, especially with very well known issues like debugger support, that they aren’t on the radar and haven’t been discussed a 100 times to be a top priority. So mentioning it here has very little chance to change anything, if you don’t bring anything new to the table. The “new stuff” would be anything I put on the list :wink:

6 Likes
29

I don’t get that many occasions to try new languages, but I’ve had two experiences of note in the last five years or so.

Python just worked when I tried it. A colleague said “download this package” and that was all I had to do to start being productive.

My other recent experience of note is the Arduino environment. I was able to download and install it and was flashing LEDs in about ten minutes.

Arduino is a pretty interesting case, actually. If doesn’t let you do anything you couldn’t do before, but it makes it easy. Even though it’s a dumbed-down environment for a professional programmer, I still do a lot of work in it just because it offers so little friction.

1 Like
30

In general, if you want to see substantial changes in the language you need to pay for them. Either with money or with your time. Reordering the dev’s priorities is unlikely to happen because of a post like this – there’s a reason why people focus their work on certain areas.

Still, recording your first experiences with the language is helpful, just be aware that it’s probably not going to directly change anything.

Why not?

That’s unfortunate. Should be fixed with the next release.

Installing Julia seems pretty easy to me – you download the installer, install it, and can then start a REPL and say pkg> add SomePackage. Just like that.

If you’re talking about IDEs – yes, Juno lacks polish. Should be fairly easy to install though.
It’s unfortunate that JuliaPro had a bug that you ran into, but apart from that it should also be pretty close to the Ardunio experience.

While that’s probably true for package APIs and so, newcomers do have a unique perspective on UX issues (e.g. the debugger stuff mentioned by OP). Usually there are good reasons as to why certain aspects of the UX are lacking, but it’d still be valuable to have a vision to work towards.

10 Likes
31

Wait, you didn’t try using Julia in a terminal instead of in Juno? The debugger is really well implemented and easy to use if you’re just using a REPL.

I admit there were times when I wished that people would just buckle down and focus on a nice IDE, but why would you want someone who can create interactive multithreading to spend their time working on GUI interfaces?

In my experience the raw implementation of Julia is fine. Until someone is willing to pay developers (not researchers) to work on Julia you’ll probably get very slow progress on GUI interfaces.

9 Likes
32

I kind of secretly hope that never happens. I am pretty sure that serious funding would have created an Official IDE with all kinds of bells and whistles, that in turn only work in the Official IDE. This happened to a lot of languages which cost Serious Money — since you are paying for it, you get a Serious IDE (which, of course, does not mean it has basic functionality that open source editors had since the 1980s). But Julia remained IDE-agnostic so it works with Emacs, VS Code, Juno/Atom, Sublime Text, and Vim.

Fortunately, since Julia proper is free software, it is unlikely that anyone would shell out money for just an IDE. So we are safe.

13 Likes
33

I’m not sure about that. Python has some serious IDEs, and R has Rstudio. I hadn’t heard that those languages changed much because of that, at least not Python.

But I’m not hoping for a dedicated IDE, I think solid plugins for high-quality editors is the right approach.

1 Like
34

There was a serious IDE built with Qt very early on (v0.2), it was working pretty well (iirc I started to use Julia with it). Sadly there’s wasn’t much interest/support for it at the time and it fizzled out. It was a missed opportunity for sure (doesn’t Rstudio makes money ?).

https://github.com/forio/julia-studio

2 Likes
35

In recent years I’ve come to understand that there tends to be a big difference in attitude from people who are expecting a “product”, and those who are simply looking for a programming language.

What I mean by “product” is that some people seem to be expecting

  • A mature, stable language with a regular release schedule.
  • Mature, stable tools such as debuggers and linters.
  • A mature, stable IDE with all sorts of GUI elements.
  • A variety of mature, stable packages.
  • A curated list of tools and packages.
  • Perhaps a single download and installer that installs absolutely everything you might want to use.

Alternatively, others of us, when starting to use Julia, were expecting a mature (or perhaps not even mature), stable language only, and if we wanted any of these other things we’d have to evaluate what’s available.

The “product” concept is rather new to me, especially for a programming language, and I suspect that is the case for many other users here as well.

Matlab is proprietary, and has been around quite along time, so they certainly have developed a “product”. Python has also been around a very long time, and as an open source project has much more in common with Julia than Matlab, but for some reason I’ve yet to discover, Python seems to be the recipient of an almost unimaginable amount of time and effort on the parts of a very lage number of people who, again for reasons I can’t understand, have tried implementing just about everything under the sun in Python. There are, as a result, a number of packages in which people have gathered a whole bunch of very mature, polished Python “stuff”, and assembled it into a “product”.

As for Julia: I think you will find that it feels quite impressively mature for a language so young. Bugs in the language itself are quite rare. While there is no regular release schedule, development in Julia is quite active, and the core devs do an extremely professional job at deciding what gets merged. The debugger is pretty new. I find it works quite well, but I’d agree there is still some awkwardness in teh debugging workflow. It’s certainly fair to say that the debugger is immature. If a really mature debugger is really important to you, my advice would be stay tuned. There is already a bewildering variety of really interesting Julia packages at various levels of maturity, stability and maintenance. There certainly exists a large enough subset of these which are quite stable and relatively mature that Julia is quite usable as a language without the need to rely too much on calling other languages (though it has good interoperability with C, C++ and Python at least). I agree that there is a discovery problem: it’s hard to tell what to use, especially when you are starting out. That problem is not unique to Julia. I’m not aware of any curated lists. Julia has a variety of editor plugins also at varying levels of maturity. I can’t really speak to these since, as a vim user, I’m more than satisfied with the vim plugin, the excellent Julia REPL, and Revise which is an essential part of my workflow.

At this point, the reasons to use Julia are the merits of the language itself, and the merits of some of the packages available for it. In most cases the latter are derived from the former. I suspect that a “product” containing Julia, the likes of which people looking for that sort of thing are likely to be satisfied with will exist at some time in the future, but that is probably still years off. In the meantime, I’m quite satisfied with how things are working out.

20 Likes
36

There is a highly regular release cycle: a new 1.x release branch is made every 4-5 months and the release happens whenever that release branch stabilizes, i.e. has no more release-blocking bugs.

8 Likes
37

I don’t really get the argument that Julia is “less usable” than Matlab. It’s been a long time since I used Matlab, but as I remember the interface was “friendly”, but the language itself was a mess. There was very little in the way of abstraction, and it required every function to be in a separate file, a constraint that encourages poor programming practices. Really, it didn’t seem useful to me beyond simple prototyping. And you have to pay for it, and no one can use your code unless they also pay for it. It’s just extremely limiting.

Personally (and it’s all personal preference) from what I know, I think the core developers’ priorities are exactly right. Yes, there’s a strong focus on performance; without it we wouldn’t have the sweet, sweet v1.3 multithreading. But usability is also a strong focus. I’d rather use Pkg than Conda any day of the week. Revise is a godsend. A simple Ctrl-S updates the module loaded in the REPL? That’s nuts!! And Julia is already very usable from Atom or VS Code, with things progressing quickly. And you don’t even have to pay for it!

35 Likes
38

Ive begun to agree with this as Ive watched sublime and RStudio over the last couple years. Im fully aware they’re different beasts, but in both cases a smaller group of developers that have a complex development pipeline makes the road to features long and complicated.

VSCode and Atom have found a way to make this much more manageable for GUIs. I try VSCode every couple of days and it’s been really impressive how well Julia is progressing. Unfortunately, my laptop is nearly 5 years old and Atom becomes unbearably slow most the time.

I apologize if this IDE conversation seems off from the OP but most of the issues mentioned are only problematic in an IDE. I’m just hoping this will help some people realize how superficial these problems are for the language itself.

2 Likes
39

RStudio is run by a company that has completely changed R and the packages people use. It funded the tidyverse which essentially created a sublanguage that people now ask if it’s even R, and whether it has been detrimental to the language. For a detailed response, see:

10 Likes
40

That’s an interesting link, thanks! I chuckled at

I would give as an example the fact that R has various object-oriented programming (OOP) paradigms to choose from, such as S3, S4 and R6.

and

An interview of prominent R developer Heather Turner, for instance, gushes in amazement that “Her description of how she accomplishes her work is fascinating – including the fact that she prefers Emacs over RStudio!”

2 Likes