Consider supporting the channel: https://www.youtube.com/channel/UCUanJlIm1l3UpM-OqpN5JQQ/join Recommended textbooks: Quantum mechanics: https://amzn.to/3Ar5dbn or https://amzn.to/3ckXkfL Statistical mechanics: https://amzn.to/3QYcere or https://amzn.to/3cmZb3u Quantum information: https://amzn.to/3Kpjt96 or https://amzn.to/3KpjAl2 My publication list: https://scholar.google.com/citations?user=V2UZXZMAAAAJ&hl=en Instagram: https://www.instagram.com/stat.mech.in.action/ TikTok: https://www.tiktok.com/@stat.mech.in.action?lang=en Twitter: https://twitter.com/JonathonRiddell Discord: https://discord.gg/QK9HhuXBEF 0:00 Intro 4:32 criteria 11:00 Fortran 17:29 C 19:05 C++ 23:10 Julia 27:12 Python 29:44 Matlab 31:20 Mathematica
ADVERTISEMENT
:20 OOP was introduced in Fortran 90 (released in 1990). It's... not great, but it's there.
Julia can call pyplot... Moreover, you get the ITensors library. Many Body Physics and Julia hands down!
As a scientist programmer, I really disagree about the comments over C. Although it is not usually the way-to-go, nothing is better than C. Nothing is faster than C. Nothing is more computationally efficient than C. So being able to delegate certain parts of your tasks to C code written by you is sometimes the most reasonable choice.
hello, thanks for the vid! For reference, Fortran dependency management is getting better. See, for example, the fpm package manager, in development by the fortran-lang group. Just in case anyone wants to learn more. Fortran ftw!
Very good advices in general. I think that the gist is that it varies a lot depending of the field. For instance, I work usually in few-body physics and most of my colleagues uses Fortran (some work with fortran77 and some work with modern fortran). I usually use python for simpler stuff and fortran for more demanding stuff. The language of choosing really depends on the job that is given. I have some code in fortran77 and some code with more modern approaches using coarrays and whatnot. Great video!
C/C++ are certainly starting to show their age. C++ in particular looks like someone who has had too many plastic surgeries to still look young.
Really hope Haskell gains more attention in mathematical physics area!
Python is similar to a markup language. If you have a problem, you say to python call the library written in another language. That means you have to learn python and a some libraries. One for calculation, one for visualization at least. You talked about the wired point syntax. Actually it is a strength of Julia.
Thank you for this great presentation, really nice. I am not sure I understand your point when you say that functional programming is limited for scientific computing compared to object oriented programming. I can't find in which case it is true. Also Julia (multiparadigm) is more functional oriented in its core than object oriented (struct instead of class for instance). So I am a bit confused. Another point: I think it might be fair to compare Makie.jl to matplotlib instead of Plots.jl. Great video anyway!
Julia is great, but coming from MATLAB, I find its error messages can be a bit intimidating to dissect and understand. I think an LLM to customize the error messages for the user(and his background) might be a good thing.
Wild you say Julia isn’t anywhere near as fast as c/cpp/fortran when it regularly competes with them… if it doesn’t it means it was optimized and/or a skill issue..
12:33 about in static languages such as C++ supported by GCC "[needing to worry about] garbage collection" (GC), I believe it's meant that you have to throw it out (and allocate manually), i.e. you only have manual memory management, unlike in GC-based languages like Julia (and Python). Yes, true for C, Fortran, less so for C++ and Rust (RAII gives similar benefit), but you CAN add GC to C and C+ (commonly done, e.g. most web browsers do that). GC-based like Julia (or in effect when you add GC in C++) IS easier. It can have downsides that are all avoidable in Julia, i.e. it allows avoiding heap-allocations (or preallocating there) to to help with real-time or just to eliminate small (unpredictable) overhead. [About Fortran not having OOP later at 14:20, is historically true, but it actually has OOP by now in recent versions, but still probably not much used, or too idiomatic, at least in vast majority of old/current code. And not like OOP is better... there or in C++ or Python, it's not for speed, Julia does away with traditional OOP, but such can be added with packages.]
I realize this video is over a year old, but I think the plotting issues you heard about from julia were referring to the latency problem, or the "time to first plot". If it is the first time using a plotting library in a given session of a julia REPL, it takes a *noticeable(20ish seconds) amount of time to open the plot the first time as it is running the JIT for the plotting function. Later calls in the same session will be lightning quick, but the first time is a little annoying. It has gotten faster over time, but there is still a lag before the first plot is drawn. There are packages that have been made that essentially save a JIT compiled set of commonly used functions like plotters that remove this issue, but it is definitely a work around as opposed to the simplicity of just calling a plot without doing anything special. Also to make julia super fast requires a slight amount of awareness about allocations and avoiding unnecessary type ambiguities, otherwise julia is a very simple language to pick up and just use.
Thanks for the video. Your recomendations are very much in line with my opinions. Personally, I use Julia for all my scientific computing tasks. I did like Matlab, but compared to Julia it is slow, expensive and does not have the easy access to packages and community that Julia has. And I much prefer the syntax of Julia as well.
35:36 Did you say Numba will make your code a LITTLE BIT faster ? In my experience for pure Python code (bereft of compiled libraries) you can expect an easy 50x-100x speedup.
Great video Jonathon! We can talk about it for a looong time 😅 As a computational physics student myself (who used Julia for the past three years for my research projects), I can only confirm your points: 1) R is not popular in physics research. 2) Python or Julia are. Then, maybe, MATLAB (especially in engineering fields). Some researchers still prefer to use C/C++. *Python*: easy to learn, very well documented, etc. Sufficient for most researchers. *Julia*: easy to learn, performance-oriented (almost all Julia libraries are written in Julia as well, Just-In-Time compiled), easy to implement distributed and GPU code (especially writing your own GPU kernels when the task at hand is super specific to your research field). If performance is an issue, and Python does not cut it, Julia is a great choice for computation-heavy programs. Now, how would Python compare to Julia in scientific ML projects? This is what I am hoping to answer next.
Hey Jonathon, I’m an applied math undergrad. How did you manage to get into a physics masters? Did you do computational physics research as an undergrad?
I use C for data generation and anaconda python for processing. One thing I really hate about python (apart from being super confusing) is trying to parse simulation trajectories, there is nothing that i'm aware of that works like fscanf does. Implementing cblas and fftw routines in C is difficult to do at first, but after you've done it once you can just copy and paste from one application to another and it's easy.
MatLab kinda slow
apparently a lot of large climate models GCMs/ESMs are still written in Fortran due to legacy code and raw speed.