Yeah. This would be really nice. Also, if we had a new “Docs for beginners” section, it would be an easier sell to make a lot of the existing docs a little terser. Right now our docs are fairly verbose, which can make it easy to miss stuff.
8 Likes
I am genuinely curious about how you found your way to Julia for this use-case. Usually people looking to do ML/DL will hit upon one of the relevant community channels (e.g. #flux-bridged, #mlj on Slack or #domain:ml here). Then if something like “what is the Julia equivalent to Sympy?” came up, it would be much easier to redirect to ModellingToolkit because a) the maintainership overlaps and b) most of us are familiar with it. Likewise for questions about IDE startup and performance. I don’t mean to imply you took the wrong path, but it does seem like you’ve put in a great deal more time than the average “Python vs Julia” poster (which is a good thing, thanks for such a detailed post) and I’m surprised we weren’t able to address more of your concerns before this as they came up.
2 Likes
Strange. I just timed it on my computer, starting VSCode, the Julia REPL and executing println("Hello World!") took for me 8 seconds in total.
Edit: I tested with Windows 10 native (no WSL), Julia 1.6.
The 30 seconds for Python is also very slow, could it be related to WSL? Are you using WSL 1 or 2?
2 Likes
The word “beginer” should not imply that parts of Julia’s language are considered high-level content and that the existing documentation is sufficient for those parts.
Documentation should generally be written on the assumption that the reader does not already know something and wants to learn by reading the text of the documentation.
I agree with you that the documentation is verbose, I think the reason most of the sections are verbose is that the author is trying to impress the reader rather than a technical explanation of the features of the language.
Honestly, I do not feel the need for a special package in Julia for my work. Because in the field of data science and machine learning, Python libraries are more than enough for practical and research work.
I like Julia as a language with unique features. I like to learn the language itself, apart from the packages written for it, and if I’m looking for packages for the things I like, it 's because I want to see what interesting things people have written in that language.
When you look at language from this perspective, the first source you look for is usually the language documentation itself.
I do not think so, I first tested Julia on Windows and it worked similarly to the results I posted. Then I said to myself, maybe Julia is not very good for Windows, and then I decided to install it in WSL.
Its WSL2
I doubt that anyone is trying to impress here. One reason for the verbosity of the documentation is that historically it was both a “tutorial” and a technical documentation and has been a strange mixture ever since. Maybe we should split these two variants at some point. One readable, verbose “getting started tutorial” and one technical documentation.
23 Likes
Yes, it will be great.
1 Like
Hey @dariush-bahrami ,
welcome to the community and thanks for your feedback. It’s very much appreciated.
I’m wondering whether you always execute a file directly in VS-code or the command line. I think the more standard way (after using Julia for quite some time) is to open the REPL and then use include to execute the file or include and track it using https://github.com/timholy/Revise.jl
This is by no means a critique of your current way of doing things more a critique to us who don’t publicly show others our workflow 
Regarding some of your other points:
I agree that the number of packages isn’t that big yet and there are still quite a lot of packages missing whereas for others there are quite some which are unmaintained and overlapping. I do think that the PyCall package can be helpful as one can write stuff that is using multiple dispatch and speed on some additional code outside of a package in Julia and can use the size of the Python community to ones advantage in combining their two strength.
Hope you’re giving Julia another chance 
4 Likes
Is that by typing the command directly in the REPL?
I find that execution of code from the editor using Alt+Enter (“Execute Code and Move”) or Shift+Enter (“Execute Code Cell and Move”) remains unresponsive for quite a while after the REPL is already up and responding.
I am currently using the REPL or Jupyter environment to learn Julia. But these environments are not suitable for writing modular code and packages.
Thanks for your suggestion, I will try this
I do not agree with you, because for most problems you will probably find a Python package, and if you want to use Python to solve problems in Julia, Julia will never find the character it deserves. In addition, you can use Python to call Python code. I think the PyCall package has been overused.
For now, despite all the problems I have mentioned, I enjoy learning Julia.
2 Likes
As a shameless plug you might find part of my blog post interesting about workflow with Revise Julia Basics: REPL & Revise
I think most of us package developers use it all the time and load the Julia REPL once in the morning and leave it open for the rest
3 Likes
Thank you, I will definitely try it.
I have only tried PyCall recently so I’m not using it frequently I just find it quite interesting but one can probably argue the other way around works as well. Haven’t tried that though so I’m not sure how well it works.
For my personal project it was just that I used a lot of packages that I find very nice in Julia and was missing one thing I couldn’t find and found out how to do it in Python.
The main point is probably if more than 5% percent or even 10% of your code needs Python library then you might want to look into just using Python if it doesn’t have big downsides based on their huge community and number of packages. If you only need Python for one or two function calls inside your code because Julia is lacking that package then it’s nice that PyCall exists.
I agree with you, but not everyone uses PyCall this way. By overuse, I mean that they use PyCall to port a complete package to Julia as a wrapper for packages in Python. This is not a bad thing in itself, the problem starts with eliminating the need to write new packages in Julia.
1 Like
Yes, I typed it directly into the REPL.
Also right-clicking on a .jl file and select “Julia: Execute File” is rather fast for me.
Alt+Enter / Shift+Enter takes also for me a while after VSCode startup because it seems to wait until the indexing of Julia packages is finished - looks like this issue: [FR] Make inline eval responsive during "indexing packages" · Issue #1962 · julia-vscode/julia-vscode · GitHub
I’m curious, do you have an/a few example/s?
For interest:
As the co-author of TensorFlow.jl, do note that it was made for julia 0.4, which was when julia’s ecosystem was still young.
It’s now basically feature frozen, due to the fact that I have moved on to working on Julia tools like Flux.jl
These days there are a bunch of strong julia alternatives.
Flux.jl, KNet.jl, Avalon.jl (nicely all of which wrap NNLib.jl for many operations)
It’s also not correct to characterize it as a wrapper of python.
It doesn’t really use PyCall, not for most things.
It wraps the LibTensorFlow C-API, for over ten thousand operations.
Just like the python tensorflow library does.
(It technically uses PyCall, but only for a single graph manipulation that doesn’t actually have a C library back-end)
It’s (IMO) a good example of a library that is much easier to write in julia than other languages.
It uses julia’s metaprogramming to generate the wrappers of all the API.
For a while it was a few features ahead of the python tensorflow library, supporting things like xs[i; mask] when writing that in python would have been a bunch of calls to less idiomatic operations like gathernd.
I think more generally you will find that most of those libraries listed do have pure julia alternatives.
In some cases because they are old, and julia alternatives were not written.
in some cases because people have a particular liking the python API, or that they want it as a baseline, or that there is just the gains of a pure julia implementation is less than doing some other thing.
(No need to reinvent the wheel)
For interest, my employer has what is probably the largest production Julia code base (~450K LOC).
Last time I checked the only python dependency we have was for intereacting with SOAP.
At some point we plan to make a julia library for that, or wrap a C library.
Makes sense that there wouldn’t be a julia library, SOAP is almost a legacy format these days.
23 Likes
Can you give specifics? Which parts of the documentation are written to impress rather than inform?