that’s a bit misleading, in Rust, x.f(...)
is syntax sugar of f(x::X, ...)
right? So it’s not that f
is a “member function of X
” (as Rust is not big OOP)
I’m not a power programmer, albeit it looks like you might be spot on here for now.
I don’t claim to be anything other than at best a guy who know just enough to get himself into trouble but not enough to get himself out. I am ap Ph.D candidate in Evolution and when it became clear that R and myself were going to have a long lasting problems with how things should be done, I began to search for a language that made more sense to somebody who didn’t want to get a degree in CS to write code to do what I want to with the data I collect. I looked at C (and all the odd little character flavor designations like + and then ++ and then @ and do I remember a ! also?) and found the bracketing as an undue demand on my memory to remember to make sure they are all closed and it made reading code like reading, well a CS textbook.
Tried Python and hated two things about it.
- the whitespace requirements
- and the postfix notation.
Now it may just be me but ln(sin(a)) makes way more sense as it emulates how you write mathematical formulas on paper, than does a.sin().ln(). The postfix notation is really quite confusing to someone like myself because it looks like you are taking the sine of the natural log of what I’m going to guess is ‘a’. or is it ‘a’ (some mathematical function here) sine of the natural log of something else. How to read a.sin().ln() requires me to make a lot of mental manipulations and assumptions that I’d rather not make. I understand ln(sin(a)) without having to do a lot of thinking about it
Also starting indexing at 1 makes way more sense to this non-CS trained mind. I have a datum (which may be a zero) it is one piece of data and should be “cataloged” as such. So while I get the point of setting your time variable to T(0)=0 in my mind that is actually a piece of data that needs an index which in reality is T(1)=0
These are the 3 main reasons I chose to learn Julia and not the other languages
Just my very undereducated CS mind’s opinion.
@Tarny_GG_Channie, this is precisely one of those threads; you’ve done this many many times. Let’s bring this one to a close soon.
@Hexen and others, we’d love to have your inputs on making Julia — and your use of it, if you’re so inclined — better! But we prefer concrete examples (like that BDD solver case sounds interesting) in more focused and more actionable topics. Please don’t hesitate to open new topics to discuss these more focused cases.
In that case, it’s up to the Matrix
or Array
class what its member methods includes. Evidently its member method syntax doesn’t extend to operations on a scalar element.
Thanks for clarifying. Indeed, the mutable type concept in Julia (and Python for that matter, given NumPy was brought up earlier) is implemented by pointer indirection, which obviously cannot store contents inline on the stack, in a field, array element, etc. You would have to use immutable types, and changes would be accomplished by reassignment (which can be helped by Accessors.jl macros) or by mutations of other mutable objects assigned to its fields. For example, you’d use Vector{SVector{3, T}}
instead of Vector{Vector{T}}
if you wanted a contiguous array of XYZ coordinates, then change a Y coordinate with @reset vector[index].y = value
(not entirely sure, but I suppose the Rust analog is Vec<[T; 3]>
instead of Vec<Vec<T>>
). Avoiding additional heap allocations is typical practice for performant Julia (just as multiply dispatched calls aim for static dispatch, not dynamic), and garbage collection isn’t relevant to how that’s done (since you’re more accustomed to Rust, GC is more what’s necessary when multiple mutable references aren’t curbed yet manual management is absent).
Note that C++, Rust, etc use a different, more classic definition of mutability (and variables) that doesn’t really map to Julia/Python’s. It and other high-level features like pointers and references do give more convenient control over memory at the cost of other conveniences (though what’s considered convenient depends on the language’s philosophy and use case). Still, people must design their structures with care if they want significant inline allocation, and that may not always be feasible or desired.
Strictly speaking, Rust types aren’t classes, and rect.area()
is fully equivalent to Rectangle::area(rect)
. However, types are associated with inherent methods (in the same crate, maybe different modules) that take its instances as the first argument self
, which serves the same purpose as classic member functions and provides the same benefits. It’s worth highlighting that such methods are not the only or often most of the functionality for a type, just the basics that everyone else can build on. Rust’s ad hoc traits extend functionality with more self
methods, with the benefits of member method syntax discovery and without the wrapper instances of the adapter pattern. In discussions about the incompatibility of member method discovery with Julia’s multiply dispatched generic functions, it was pointed out that there’s nothing stopping explicit association of basic methods with a type for discovery; don’t need bona fide classes or base Julia to implement that.
There is this article, in Nature Astronomy:
Pierre Augier, Carl Friedrich Bolz-Tereick, Serge Guelton, Ashwin Vishnu Mohanan. Reducing the
ecological impact of computing through education and Python compilers. Nature Astronomy, 2021, 5
(4), pp.334-335. 10.1038/s41550-021-01342-y.
But Julia looks pretty good there:
(disclaimer: that Julia code was optimized in this forum after the authors asked for help. Still, it is just Julia code)
Perhaps you referred to
Chapel folks like to plot code size vs performance, to highlight the “high productivity” languages:
FWIW, C++ is my favorite language.
It’s great for implementing libraries and building abstractions.
I wrote a blog post a couple years ago giving an example of how easy it is to write some succinct relatively fast code, giving auto diff (first and second derivatives) of a matrix exponential example:
The C++ code was shorter and faster than the fastest Julia version. The C++ code had less explicit memory management than the fastest Julia version.
Julia gives a great interactive experience, and Revise is nice for debugging.
I also suspect part of what I like about C++ is that I’ve only used it in personal projects, and never professionally.
That’s not how programming works. All of these languages (Rust, Julia, C++, …) are Turing-complete, and pretty powerful to boost. Everything is viable in all of them.
But at the same time each offers unique advantages. C++ is great for really large teams, and mature projects with a well-defined algorithm. Rust is great if you want to replace C with a modern language that is obsessed with safety. Julia is great for quick prototyping and refactoring.
Implicit in your post is the misconception that a person is an “X user”. It is true that a lot of people focus on a single language, but this does not mean that they are not aware of other languages. Many Julia users know some C++ or Rust, and similarly a lot of C++ programmers have dipped their toes in Julia.
Julia is what it is — if we can improve it, it should be improved for its own sake, not to “attract power users” from other languages.
I am with you, albeit I prefer pure C(89 and 99) because code written in that language will probably compile for a very long time, even after humans manage to wipe themselves out
I went through a couple of phases of my three decade old programming experience with hundreds of projects in dozens of languages and ended up with mainly three languages which allow me to achieve everything I want on a computer in the most efficient way on basically three areas:
- Julia – for my (astro) particle physics research work
- C for everything else
- JavaScript when I have to to web stuff
I don’t think C++ or other programmers need to be “attracted” to Julia. To me, the only people who would benefit most (including the whole community and humanity) are scientists who spam and burn hundreds of millions of CPUs/GPUs hours and IOPS on our clusters and grid with crappy Python code.
That’s my two cents…
edit: typos
I saw that my earlier post was flagged by the Community, and I’m scratching my head a bit as I don’t think it was off-topic, unfocused, inappropriate, or spammy (I even threw in a smile there). I just wanted to say that, although I’ve never met my colleague (I hope he doesn’t mind me saying this) @nsajko in real life, I appreciate his knowledgeable contributions to the Community and his willingness to help others navigate the many intricacies of Julia’s architecture and programming.
This topic was automatically closed after 17 hours. New replies are no longer allowed.