I breached this subject in hope that Julia could be used for a large software project, which is perhaps a better description than “general-purpose”
I don’t want to argue about imports, you can easily look at how every other popular language does it, and see who’s the odd one out. Not that there’s anything wrong with bold choices, if they actually provide real value, and aren’t just an arbitrary implementation detail.
But the load time is a real show-stopper for me, and at the moment, I don’t see how Julia could support a large software project, or a real product with users that pay. Maybe I’m just missing it.
Anyway, thanks for your replies, and I apologize if I missed someone’s point.
Thanks, but that video avoids all the things that I found confusing. For example, I found it frustrating to develop a package locally and then use it in multiple directories. I realize that question did get answered, but I recalled having a lot more issues with that answer and didn’t want to follow up as I was confused about what I was confused about. I missed R’s install.packages("myPackage") and then being able to call library(myPackage) anywhere.
I’m not saying it’s PackageManager is broken or bad or anything like that. But my impression is that it’s much closer to how Python uses virtual environments which is a new concept to R users. When basic “how to’s”, like the video you linked, make no mention of this whatsoever, perhaps this is why some people find PackageManager confusing and others do not.
Even as a scientific programming backend, Julia was created to solve the two language problem, in which you need a high level language as glue and a low level language for the heavy lifting. Even scientific programs can have a customer that will not run it in a shell, so if it’s not general enough to do adequately well stuff like GUI, web service/cloud deployment and whatever is considered a natural platform to run scientific computing applications in the future (WASM, mobile, IoT devices…) then you’re just running into another two-language problem, one for scientifc computation and one for deployment/user interface.
That said many of those probably do not need the support of the compiler developers, but mostly of the community, Julia is a language that is built to be extended and having ecosystems that compose into something larger than the sum of it’s parts. Just like it can have very clean DSLs for math optimization or differential equations not built-in it can also very clean DSLs for building GUIs, web pages, interfacing with databases all created solely by the community it attracts.
What the compiler support could improve for the “general programming” is basically the same as what the pure scientific community acknowledges, such as the JIT latency issues (time to first plot), easy binary creation (including maybe to create bindings to other languages like C/C++/Fortran do) and overall polish in the experience which will come with the language maturity (including easy of installation, documentation/books for every user background, mature and diverse libraries). And some of the language improvements that are already on the milestones that will help with maintaining larger application, such as a way to better declare/document an interface (instead or doing it solely implicitly through duck typing).
Look, all I’m saying is that my experience with Package Manager was confusing. And I’m trying to give feedback as to why: things like virtual environments are new concepts to R users. If you think that’s all my fault, fine. Just trying to give feedback.
In my experience as an experienced Python user coming to Julia, my python experienced confused the concepts of module and package with file and directory. In Julia I feel like the Python style import is roughly
include(“MyModule.jl”)
using MyModule
For some reason this pattern never occurred to me until I read someone else’s code. I guess maybe it’s something good for a Python tips page. I forget if it’s there.
So, I know Julia is striving to solve the “two language problem” but I tend to agree with the idea that scientific computing domain is the number one priority.
As far as general purpose language features like GUI, file handling, and all the utility function go…as people have said: It’s possible, sure. But I think if and when those get solved its because someone will either write it in Rust (or some other systems language meant for those purposes that can expose a clean C API) and write idiomatic Julia wrappers for it.
And let me emphasize: I know that is the hole down which R and Python went. What I mean is, Julia solves the two language problem for numerical analysis and data science libraries in my opinion. And the beauty of that is the power it gives to understanding how those analysis are done from a researcher/student/data analyst’s viewpoint. And to be able to easily extend and contribute.
All the other stuff it might be trying to put a square peg in a round hole just to say “it can be done”
@pistacliffcho
I’m with you. Don’t take peoples defenses against your user experience shape your view of the community. Julia’s package management system is different. It’s also under development to a certain extent! I started scientific computing in matlab, went to octave, then R, then python, now I’m happily at Julia. So maybe some things are confusing - but over-all I’ve found it less clunky at the end user perspective.
If I had a dollar for everytime I had to install devtools, or watch the R ecosystem I depended on break I’d have like - 10 bucks. So not really wealthy, but definitely a pain. If I had a dollar for everytime I had to burn down a conda install, or a pip misconfiguration I’d probably have 50 dollars. Still not rich - but, after using Julia for about a year I can say I’ve never had a serious package issue. It’s also not bloated at all.
@wsphillips
I gotta agree. I am pretty much tool agnostic provided it’s the right tool for the job. For scientific computing - gotta say Julia has nailed it. Anything it’s lacking it’ll have very soon. If someone wants to write some JS, Rust, C/C++, C#, JAVA, libraries to interface with it, by all means. Julia handles Data, and general compute, whatever someone wants to do with it after is another matter.
Consider a typical say python workflow from the languages used. Interperated in python, dispatches to C, back to python, dispatches to fortan, back to python, output displayed via javascript. Now the same operation in Julia: Command compiled in Julia, output displayed via javascript. Fine by me!
I definitely agree that stuff like GUI should probably be idiomatic wrappers (not unlike Rust having gtk or electron wrappers). In fact that’s not unlike how Julia started on numerical computing, focusing on it’s strong FFI support for C, Fortran, Python and R so people can use the mature tools until the community built something with the same level of quality thanks to the increased development speed that comes from the language design. If for some domain being Julia all the way down is best (like scientific computing, machine learning), then a part of the community should have motivation to implement it, while if in some other domain just using what’s already implemented is good enough then the community can focus on providing the easiest access to those tools without the need to reinvent the wheel.
What’s important to being a general purpose programming language is being able to have access to most functionality without leaving the language. No one says Python isn’t a general purpose language because those tools it provides couldn’t be implemented well in itself. And it wasn’t the Python interpreter team that decided what domains Python would support, it was the library writers and general community.
My point is that what will make Julia more of a general-purpose language isn’t the language design itself (on that level it already is a general-purpose language, as opposed to a DSL, even if it’s not good at everything such as system programming, which it should also not try to be), it’s the breadth of functionality that is available to the programmer, which is decided by it’s library ecosystem and requirements of the community. And I really hope it manages to moves well beyond pure scientific libraries since it makes it a more attractive language to make full products/services around those scientific tools, making it more valuable to more people.
Yeah, that’s understandable. In part, this is because R is not a general purpose language. A lot of best practices for coding and data science can mostly be ignored, so you end up being very productive without learning them. If you’re using the same sets of tools for a bunch of different analyses, it’s fine to have everything installed globally. I think if you just treat julia like R and only work in the default environment, you should have a similar experience.
But Julia docs and people offering help are definitely likely to push you to use projects. Ultimately, it’s easy better for reproducibility, but it is for sure an extra thing to learn.