“An easier C++” is not targeted at C++ programmers who want something easier, but coders who are running up against performance issues in their language of choice, and who find C++/Rust/etc. daunting.
When programming in Matlab, I either have to implement bottlenecks in C or C++, or just accept that I’ve reached an impasse. The latter alternative is what I always chose. Julia is for people like me.
Reproducible environments that users can download, install and use.
It’s one thing to claim that this work has not succeeded, and point out where you think it falls short. It’s another thing to bring accusations of people not giving a damn, or deliberately ignoring problems. The latter is unnecessary, inflammatory and insulting, and is more likely to derail the conversation than to help it forward.
Consider your agenda, is it just to blow off steam, or to be helpful?
It’s also worth remembering that many of the tooling projects being discussed here are one- or two-person shows with little to no institutional support. Given this background, I think it is important to appreciate what has been achieved, even if certain things can be improved.
Agreed. I think it could help promote Julia as a simpler C++ rather than a faster Python. The expectations of new users will be very different and it would give time to so many interesting projects to bridge the gap between Python and Julia.
As I guessed, you appear to be not interested in solutions. Still let me show a possible one:
cd("./shalom")myscript.jlusing Revise; includet("myscript.jl") add(x, y) = x + yRepeat the last two steps. E.g. redefine the function, make it add(x, y, z) = x + y + z
Now, try to execute in REPL:
julia> add(2,3)
ERROR: MethodError: no method matching add(::Int64, ::Int64)
You see, the old definition is gone, and the new one is here:
julia> add(2,3,4)
9
If THAT sounds too complicated, then be warned: The rest of Julia (and any other programming language) requires way more mental effort than that.
Hmm, not sure what you mean. Project environments are perfectly reproducible by either putting tight bounds on dependencies, or shipping code with a manifest[1].
Getting a dev environment up and running is a matter of minutes in my experience.
As long as you stick to the same Julia version. The issue of packages not bounding Julia compatibility correctly, has been brought up elsewhere. ↩︎
You have just seen, that it could be just as likely been considered, that Zig already fulfills that role.
And that is a very different language, then Julia.
So, I think any notion of “Julia is a different form of X” is inherently flawed.
What fascinates me about Julia, is that it’s probably one of the more unique languages.
I really love looking into new, and very innovative languages, who do things different.
What Julia does with its type system, multiple dispatch, and the strong scientific background of the community, is unmatched, and really contributes to the value proposition of Julia.
To me, and again, I may be different here, is Julia ideally seen as one of the firsts of its kind.
The first of a new generation.
And not so much as a new iteration of something old.
As said, I think people from old languages are not as likely to come over, as some people still think.
So comparing languages with each other might be not as effective, because it short sells the value.
@Eben60 You have a typo, its include("myscript.jl")
I will try that now, and I like to note, that I always said the approach in the video is too complicated.
Somebody said VSCode supports that process, and I now wonder why this is not what the |> button does by default.
It seems not very well documented either.
To have a dev container, or something similar, as part of the official installation instructions.
Ideally, we would default to reproducible systems, when we advise other people how to start with Julia.
They are just much more reliable.
I’ll make a radical proposal: let’s close this thread. It’s become a kind of airing of grievances thread and it has the constant potential to turn into something much worse, but I’m not confident that it has any remaining potential to turn into something much better.
No, it is includet with the t. That’s a Revise function, meaning “include and track”.
Julia is readily available as a Dev Container from inside VSCode! Just tried it out; worked immediately.
I concur though, that it might not be as well advertised as it could. This could be discussed further in a new, more specific thread.
That’s not true, I was able to play with Julia just by installing Julia and the Julia vscode extension, that’s it. Anyway creating a new package of a matter of writing generate mypackage I don’t see an issue here
3 posts were split to a new topic: Making Revise the default?
I would prefer to require registered packages to have every exported function and the corresponding arguments and return type to be documented, with reasonable exceptions for methods already documented. I’m not sure if the documentation rate quoted in this posting is still accurate, but it seems low. I’m willing to spend more time working in a smaller coding community as long as the documentation is complete.
I would also like docstrings to have structure like Roxygen.jl I think it would make it easier for the ide extensions to provide assistance while coding if the documentation had more structure. I know it can be controversial, but I think that writing more structured documentation will be useful for ai code assistance tools to train on (preferable with lots of repeated documentation and examples despite what the manual says).
Before closing the thread, I would suggest one last thing. I hope the Julia community can revisit the topic of this thread each year through a roundtable at Julia Con or a question in the annual survey.
I would not worry about this. A variation of this thread seems to happen every month or so.
I agree, but this is hard to automate. You can keep an eye on #new-packages-feed on Slack (or Zulip) and leave a blocking comment on the registration PR for new packages that lack documentation.
If I might make a few final constructive comments before this gets closed, I do think we need a “clearer” ecosystem for users. As I’ve come to understand Julia, it tries to have a minimal standard library with only some basic packages likely to have fairly broad applicability. For example, the LinearAlgebra package is part of the stdlib, and contains basic operations such as dot & cross product, eigenvalues, direct solve via \, etc.
So me, as an end-user, I don’t feel the need to go find a NumPy-like package to provide those functionalities. However, LinearAlgebra doesn’t include “advanced” capabilities like Krylov solvers, polynomial fitting, etc., so for those I need to go find a package. And those packages are typically “single-focused” on doing one thing, and that one thing well. It can be a bit of a maze, then, to find a set of packages that provide all the functionality of something like Matlab’s base install, or of SciPy or NumPy.
It would be nice, IMO, if there was a curated list on Julia’s homepage of “user-recommended” packages for different domains. Something similar to what NumPy’s webpage has:
We’ve got a good start on the official Julia webpage with:
But it doesn’t quite help me if I’m a new user wanting to rewrite a Matlab project that does finite-difference method on a DNS fluids problem. I’d propose a “Recommended Ecosystems” page that plainly lists various ecosystems and packages. I know there are sites like Julia Packages, JuliaHub, and Julia.jl, but it would be nice to have a curated list directly on the Julia homepage, that simplifies things for new users.
The second thing that would be nice would be if it were possible to simply install an entire organization of packages. For instance, I’d love to be able to simply do Pkg.add_organization( "JuliaMath" ) and not have to manually add each package. JuliaMath is, in many ways, that “user-curated” ecosystem of packages I’m looking for as a “novice” user. If I want to use the erfc function (that is part of both Matlab and Python standard libraries) I don’t want to go searching for the package, but rather would be nice if JuliaMath were a simple-to-install “catch-all” for standard mathematics capabilities. Then we could tell users “if your project uses advanced mathematics, add the JuliaMath library”.
The last thing I’ll mention is that it might be nice, perhaps, to consider expanding the standard library. Why do I need to add the SpecialFunctions.jl package to have access to gamma, erf, Bessel functions? While I think I understand this is because Julia doesn’t want to “play favorites”, it doesn’t seem like there are any other projects that compete in this area. Plus, it then seems odd that LinearAlgebra is included in the standard library, when that seems like a package that shouldn’t based on my own observations of what are/aren’t included in the standard library. This kind of harkens back to the first point, I find it odd that LinearAlgebra has something as “obscure” to a layperson as a generalized-eigenvalue solver function, but not a conjugate gradient or GMRES solver. It’s odd that while neither Python or C++ include linear algebra in their standard libraries, that Julia does; and while both Python and C++ include “special functions” in their standard libraries, Julia doesn’t. It just all seems very arbitrary (to me).
Anyways, hopefully those were constructive (rather than grievance-airing) and I’m happy to participate in future discussions on those topics (in separate threads?) and contribute to source where I can.
I think this is another very big problem to getting new users to adopt Julia–the difficulty in recognizing the importance of defaults and informational constraints. Among experienced Julia devs, the assumption is defaults don’t matter, so we don’t have to change them.
However, just because a change is easy for experienced users doesn’t mean it’s easy for new users, who often don’t even know a feature exists. What percentage of Julia users do you think know about julia --project? My guess is less than 5%. (I didn’t know about it until today, and I’ve written a couple of packages!)
Other examples of poor defaults that are easy to miss when you’re learning Julia:
In theory, Julia is supposed to be just as easy to pick up as Python, like it promises in its advertising. In practice, all these details are just too easy to miss. Just because it’s easy after you learn how to use it, doesn’t mean it’s easy to learn how to use it. Right now, these kinds of defaults mean it takes me a lot longer to teach a new user to learn Julia than it does to teach them Python.
52 posts were split to a new topic: Naming positional arguments at call site
