You don‘t seem to put your own code in a package, so likely you are seeing latency in part due to your own code not being precompiled at all.
I’m a high-school kid who’s had no professional experience with coding. Self-taught myself much of it out of the joy of learning. So I have little to no coding Etiquette lol. I’m improving on that though! I’ve come a long way from when I used to have all my packages clogging up the main Julia environment.
Will look into cleaning my code a little more. But currently, the project is, if I might say, just started. And I’m just playing around with things, tweaking in a bit here and there. I JUST figured out how I might use GLMakie for my project. So, baby steps I guess!
Again, as I mentioned before, not a fully-fledged programmer/data analyst. Just working on personal endeavours. So yeah, it might take me a while to get to know things in more detail… tbh didn’t know we could do that lol. Thank you for the input tho! I’ll check that out once I’m done with my admission process for the undergrad (quite hectic as an international student).
Sure thing!
Yes, I totally understand your feeling about the first mile.
This indeed a drawback of Julia.
A lot of work was put into it to improve this issue (see my last comment about 1.9. 1.10 is even faster), however it is not as fast to startup as python yet. Python is really nice in that regard.
To improve further the startup experience in julia, there are some techniques as other posters mentioned, but they require work from the user and I would certainly not call them easy nor super convenient especially for new users.
If you want to help improve the startup experience in julia, a great way is to post a concrete question here such as for example “repl takes xxx minutes to startup with empty startup.jl file” or “how can I speed up my package load time?” etc
Hope this helps
The thing is… and this is personally my opinion and I do not mean to annoy anyone. But honestly… I don’t particularly like the way plots look natively. Like in the entire scientific community actually.
I mean ok it isn’t bad… And hey… I know there are ways to tweak things to your personal preference and beautify them. And that personal preference isn’t glorified much in the science world.
But gosh these plots look nice! And the thing is, Manim makes it easier to beautify. Not that it’s of utmost necessity. But I feel that’s what Julia lacks… It has the tools to do anything you want. Just not enough packages that let’s you do things easily until you know the nicks and crannies.
Like Manim is a NOBRAINER.
You just install python.
Install Manim.
Call:
Create(Square);
Transform(square, circle)
And it will give you beautiful animations in a second! It’s a lot beginner friendly so to speak. Julia is great. It might have an easy way to get things done with I might not know… but I would love to see it flourish (and improve further on the first run times lol).
(and yeah ok, I’ll look into what ya’ll recommend. But again, the point is, that being able to do things and being able to do things natively are different. This is honestly one of the reasons I fell in love with Julia… Some math constants, Basic Vector algebra, complex numbers, optimised math functions, the scientific syntax with greek letters! OHHH! and quick n easy plotting out of the box)
Thank you!
I do understand that I should be concise with my questions. But honestly, It wasn’t really about how can I reduce the run times… I know that’s a thing in Julia. I just wanted to discuss how things are.
And convey what I feel about Julia. I do hope that is allowed in the discourse… Just discuss how you feel about the entirety of the thing. Not a particular solution to a particular problem but the general state of the language for, as you pointed out, an average new user. (Although, feelings aside, I’ll take into consideration all of the recommendations I got to improve efficiency in future.)
and I promise this is the last one
But truly, someone PLEASE tell these people to have a good colour pallet. If only the native plotting systems made things easier, it would improve the overall experience. (I understand the real fun is in what has been said within the datasets and presentations. But just something that I feel… doesn’t hurt to look at visually beautiful things)
I might have missed it somewhere up there, but Python is compiled on first runs too. There are a couple key reasons why the compilation latency there is much nicer, sometimes unnoticeable:
- Python’s compiler does a lot less work. Most obvious is that it compiles to bytecode, not native code, but it also doesn’t optimize much; I’ve seen some constant literal folding but other than that it pretty much does what you wrote. At least, this used to be the case, as v3.13 added an experimental profiling JIT that will compile hot bytecode to native code, though the semantics of Python limits the efficacy of compiler optimizations much like type-unstable Julia. I haven’t seen any good benchmarks out there, but the developer quotes a 2-9% speed boost in the Github issue, and the copy-and-patch scheme it is based on is known to make slower code (but much more quickly) than LLVM for even a statically typed language.
- Every .py file is its own module, and that allows the compiler to automatically cache its bytecode to .pyc files every time. File-modules idiomatically import instead of evaluating each other. In a language like Julia where modules are structures unrelated to files, you can see that code before an
include(myscript.jl)
can easily change or break what evaluatingmyscript.jl
does; for simple examples, you can add a more specific method or define a conflictingconst
variable. So, every approach to caching compiled Julia code involves isolating it to a module. It is possible to replicateinclude
in Python withexec
, but that can’t be compiled along with the destination file and there’s no point in incorrectly compiling aninclude
d file on its own; of course, this would also limit possible optimizations. You’d need something more complicated like Julia’s package scheme to compile them together, cache it, and track changes to source.
In short, there are fundamental tradeoffs, and different priorities result in different approaches.
Manim was started by 3Blue1Brown, a youtuber particularly renown for animated mathematics, often with a black background that blends nicely into YouTube. It’s a very different and much more sophisticated approach than making static diagrams for academic research. You can’t make a graph move on paper so animation software is useless, and you’re forced to use white backgrounds and limited color to save ink costs on white paper. Different needs for different worlds.
I think the reasons for preferring this or that language is mostly a cultural thing. Julia typically targets scientific programming/hpc and such stuff. While other languages target e.g. OS development, library development, various application development, web-development etc. etc. These communities have different cultures. I know some of them from first hand experience, in particular scientific programming and hacker communities (the old fashion “hacker”, not the malicious one).
These cultures emphasize different things. In HPC you wouldn’t think time-to-first-whatever is particularly important. You care about whether your program takes four months or four hours to run, not whether it takes one or fifty seconds before the computation starts. Similarly with plots, it’s the information content, not the visual appearance that matters. In other communities, it’s the other way around.
These differences permeates all uses of the language. E.g. in python you can use lists of numbers, that’s easy and typically good enough for many scripting uses. But if you want to compute something serious you must convert them to numpy arrays. Most HPC people would find that reminiscent of Cobol’s “usage is computational” declaration, and shy away. (Though Cobol is still used in many banks and insurance companies, for good reasons.)
In short, languages have different ways to do things, and you emulate them in other languages. It’s just a question of habit, and the cultural habits in whatever community you are in.
That said, I think python’s approach to modules, by filename, is a good one. I find julia’s include
quite awkward. But it works, it’s just something to get used to. I’m more concerned about excellent packages which are suddenly abandoned by their developers and left to rot. (No particular in mind, but it’s always a risk in public repos).
It depends on your use case. Makie makes it incredibly easy to make beautiful figures for scientific manuscripts, which is my use case. Getting the same thing with ggplot or matplotlib is a nightmare. But I digress…
You’re in highschool, making cool shit as a hobby, you’ve already taught yourself (at least) two languages, and you’re using them to make stuff you want to make. Awesome! You have preferences about start up time vs execution time, which is a trade-off when choosing your language - that’s also great. It’s important to know your own mind. Given where you are and what you want, Python makes sense.
Many of us have different needs, and the few seconds or even minutes of start up pale in comparison to differences of hours or days in running our code. Different uses, different trade offs, different priorities. All of this is fine.
But I’d like you to consider how this post comes across. I’m certain this wasn’t your intention, but you’re basically saying “this thing you all use is good, but if you put more effort into the things I care about, it would be better.” And nothing in your initial post is really actionable - TTFX is a known problem and heroic efforts have been and are being made to improve it. We cannot magic a larger community into existence - the difference in age between python and julia is larger than the time you’ve been alive, AND python has had a number of large companies that have poured money into it. Julia dev has had a comparatively shoestring budget. Your notes about visual defaults really come down to personal preference, and more polish requires lots of time and effort. See this thread for a bit more on these points
I totally get it. When you’re a fan of something, it makes sense to gripe about the things that aren’t perfect (incidentally, we have gripes channels on slack and zulilp - come join us there!). And at the same time, coming here and writing a long post about the ways you prefer python, when none of your complaints are readily addressable might bum people out. But given what you’ve already managed to do with yourself, I suspect you CAN make a difference. There are many ways you could turn your energy towards improving the language or the ecosystem, and in the long run, they might be more meaningful than some cool visualizations .
Yeah, you’re right… Thank you again. For the above information above Python compilation as well. While it’s true academic research papers need to have those colours, these practices are carried on with purely online resources as well. Which, now that I think about it is obvious. But very unfortunate.
That was… to be honest… ammm. Enlightening? Thank you! Well… Idk… out of words gosh! That… wow! Correct. All of it. I’ll keep that in mind!
Yeah lol I was simulating atoms actually… I haven’t fully developed the skills but I’ll reach there some day. I’m trying to model if we can reach behaviours like those seen in atoms with JUST the physics we know or is there a missing piece (and test out my own little theories). I created a VSEPR model recently randomly putting atoms around a central atom and off the system evolves into the lowest energy state based off of repulsions between different electron domains!
Kinda fun to see things evolve in front of you to see if they behave as you expected. Idk why I said this here but… Thank you! All of you actually! I realise every now and then I annoy people online, I’m sorry for that.
very cool. You might find this notebook fun: https://m3g.github.io/2021_FortranCon/
Which is precisely what I think… and… yeah, you’re right too. This reminds me of my talk to one of the creators of a public repo… Starlight.jl. An “abandoned” Julia package that was only one of it’s kind…
And ig, for a little while I had forgotten my takeaways. Thank you for reminding me…
Everything serves it’s own purpose. Julia has it’s own one. Remote from what languages like python do. Julia, very specifically is a scientific programming language. And it serves that purpose well!
Ig it’s my own fault, and my love for the language… this environment… that I wish to fit this to all use cases. And when I realise somethings not correct, I throw up. Idk… Stubborn aghhh! I’m sorry… although, as stubborn as I am, I would STILL wish to one day, see Julia being used for everything. I know it’s a challenge, not to yap about it. I would be more that willing to contribute myself, if only I had the skills!
I didn’t mean to annoy anyone… sorry. A habit of speaking things up cuz of Reddit heh.
Wow! That’s amazingggg! That’s almost what I want!
Except I want this entire thing to be real-time simulated (hence I decided Python wasn’t so optimised and learnt about Julia). And beautiful! heh.
I’ll figure both out sometime in the future. And yes, I know the beautiful part is unnecessary but…
We’ll here’s my post from last year. To summarise, I don’t want it for myself. I want it to be a publically available thing for people to play around with. Try out different sets of rules, and different sets of particle interactions and see how systems evolve! And, maybe it’s just something particular to me but, I want this to be beautiful! I want people (and kids my age tbh) to be willing to experience the beauty of such a thing.
I’m barely able to work on it, and I know it’s fairly simple. But I’ll create it some day, I know! And it’s gonna look and feel awsome!
Have you looked at the examples on https://beautiful.makie.org/ ?
In particular, you may be interested in the black theme:
If you want interactive help note there is a specific Makie Discord channel:
Also Julia Slack is one of the most interactive programming communities I have encountered to date.
Regarding latency, definitely look into a custom system image:
There is also VSCode support:
https://www.julia-vscode.org/docs/stable/userguide/compilesysimage/
You’d be surprised about the amount of thought that has been put into many of these stylistic choices. “Looking beautiful” is not the only criteria, they are also chosen to be legible to people suffering from color blindness and people who struggle with low visual contrast etc. This is not only important in publications on papers and in PDF, it’s equally important for online publication on a website etc.
I know this straying a bit off-topic, but two things came to my mind when I read this:
- Most scientists are neither trained programmers, nor communicators. I personally think, both should be taught more across all fields of science, but communication skills are arguably more important for scientists – and boy, have I seen some bad presentations, plots, and color-schemes in academia. But also some really beautiful, elegant, and intuitive ones.
- As @baggepinnen just mentioned, many publications nowadays do actually follow certain (somewhat objective) guidelines on how to choose good color schemes, etc. I think the main reason for this is what you mentioned: The defaults of many plotting libraries have implemented these choices, so the user doesn’t have to think much about it (if you are interested in some examples, this blog article and this Stackexchange question come to my mind first)
Shoot! I didn’t think of that aspect of the entire colour thingy! Thank you for bringing that to my notice!