Blog post about my experiences with Julia

Community
102 
help?> methodwith
search: methodswith

Couldn't find methodwith
Perhaps you meant methodswith or methods
  No documentation found.

  Binding methodwith does not exist.

julia> VERSION
v"1.7.2"
103

Not sure what you want to say here but It tells you in the first line that you probably meant methodswith (note the plural, i.e the extra s).

2 Likes
104

Am exploring some multi-package docs with Pollen.jl. For example, the FastAI.jl docs have documentation for Flux.jl bindings, and adding documentation .md files from other packages would be trivial.

6 Likes
105

Issues with 'distro supplied packages occur frequently in technical computing. I know why people would be attached to the easy and hopefully tested distro packages.
However in HPC it is common to use package managers like Spack and Easybuild so you have a up to date software stack, independent of the distro packages.
In Julia I believe juliaup will become the predominant mechanism, hopefully used ‘behind the scenes’ by Spack and Easybuild.

106

The only thing mentioned in that post that I really feel is a problem is documentation. It’s always helpful when people provide specific areas that documentation is falling short so we can actually move forward. You’re probably right about other languages having better editor support, but I use vim so it doesn’t really bother me much.

The remaining points are mostly driven by what you’re accustomed to or vary greatly between packages (not Julia specific). That’s not to say Julia doesn’t have other sharp edges. There’s a whole channel on Zulip right now about features in other languages we wish we had.

2 Likes
107

As a julia novice, I can second two of Volker’s complaints: I have had difficulty with the “reference” documentation, and I have found many error messages to be quite unhelpful. As a long-time C++ programmer, however, I always type all functions and variables unless there is a specific reason not to. This makes the code easier to read and also seems to produce faster execution in some cases.

1 Like
108

FWIW, I’d like to suggest R and the tidyverse in particular as a gold standard for documentation:

Every function has its usage, arguments (with types!!), and output (with types!!) and lots of examples. There are also ‘vignettes’, like tutorials, that give best practices.

I think it’s worth pointing out @Volker_Weissmann that the idea of ‘methods’ is a bit alien to a lot of ‘dynamic’ language users, so organising documentation by methods doesn’t make sense for Julia. I would also like to say that I think Rust’s documentation is some of the worst I’ve even seen. E.g.:

  • How do I initialise a Date object?
  • How do I add two Dates together?
  • What is the underlying structure of the Date type? (Big shout out to R’s str and Julia’s dump)

This is all there, I know, but it’s buried and very hard to read. I am sure that experienced Rust users/programmers who like the ‘OO’ style can navigate a page like this efficiently, but when I tried to learn Rust a couple of years ago it was like getting blood from a stone - no one would tell me how to do anything quickly!

6 Likes
109

I think the author of the blog post has a typical new Julia user experience. And by typical, I mean that it happens to users who have not grasped the clear advantages and use-cases for Julia. I think the author (@Volker_Weissmann ) would really appreciate what Julia already is by looking (taking a look at the implementation perhaps submitting a PR) at the finest works (no particular order):

  1. DiffEq/SciML
  2. Flux
  3. Plots
  4. Standard Library: LinearAlgebra/Matrices …

Docs and TTFP aside (which have been talked about and worked on) there is nothing solid about this post.

  1. Hard to debug — with repl driven development it’s actually easier to debug than a statically typed language. The most difficult debugging — finding logical code errors is much much harder on static languages.
  2. You only need to import Plots once and use Revise, but if this does not satisfy you, there are other plotting libs like GR or Gaston/gnuplot/unicode
  3. Although the author mentions Julia ecosystem and tooling, I think it’s great that most of the julia packages work together like a charm. Most prominent examples — autodiff with existing functions, base function overloading — length, size, enumerate works with basically everything you expect it to work
4 Likes
110

It is liberating when we get used to how Julia works and keep the type annotations only to where input types have to be constrained.

But I think that has to be accompanied with the (good) habit of organizing the code in small functions, which can be literally “seen” as whole. With some practice one gets the feeling of type-stability.

5 Likes
111

The classic doc string pattern with the signature and a couple sentences is really good for REPL use, but sometimes I want a lot more detail than what’s there. I think DocStringExtensions.jl is a good direction for making it easier to compose documentation and perhaps we could get additional subtypes to Abbreviation that correspond to common documentation sections (like R’s @ tags). Then these could be searched/presented in online documentation in more verbose and accessible formats.

3 Likes
112

You should look at it, Fortran is meant to be used for mathematical/numerical/scientific computing. C never was, but got forced into that duty. If you are induced into OO, though, then neither Fortran, nor Julia will work for you, since the paradigm is different. I never liked OO, so for me the POV is different.

2 Likes
113

Lol. This whole thread is an example of what happens when a conversation starts with a punch in the face. It doesnt immediately result in sitting down with cups of tea.

9 Likes
114

Using from_calendar_date, from_ordinal_date, from_iso_week_date or from_julian_day.

You can’t. What should the result even be? 1970 is nothing special. You can however, add a Duration.

The underlying structure of Date is not part of the public API. Relying on it is considered a bug. If you something forces you to rely on it, this “something” is the problem, not the documentation.

(Also, you can click on source and find date.rs - source with

pub struct Date {
    /// Bitpacked field containing both the year and ordinal.
    // |     xx     | xxxxxxxxxxxxxxxxxxxxx | xxxxxxxxx |
    // |   2 bits   |        21 bits        |  9 bits   |
    // | unassigned |         year          |  ordinal  |
    // The year is 15 bits when `large-dates` is not enabled.
    value: i32,
}

)

115

You are the first one I met who thinks that dynamic typed languages are easier to debug.

116

:wave:t2: I also feel that way and I’ve debugged quite a lot of both. If you have a logical error, being able to drop into the REPL and work through your code is so powerful and helpful. Dynamic languages also tend to have much richer and easier testing frameworks, so you can take whatever you did in the REPL to test and stick it in a test file to automate it.

16 Likes
117

Are you talking about GitHub - JuliaDebug/Debugger.jl: Julia debugger

118

No, I usually use print debugging (or logging) to isolate where a problem is happening and with what inputs. Then I just cut and paste code into the REPL to understand the bug. Debuggers are fine but they’re a bit inflexible.

16 Likes
119

And you can even quickly simulate a tiny part of the whole code to see if this particular one causes the bug. It is much more intuitive for me to debug than setting breaking points and going through the code line by line etc.

3 Likes
120

Ah yes, “shields me from basically all your criticism” sounds just right. You should consider adding it as a subtitle :wink:

Hot loops in Julia are quite fast, but you have to wait quite long for your program to start up.

The Julia ecosystem is quite immature and buggy, at least compared to rust or python.

These are not “descriptions of certain problems” or “sharing your experiences”. I’m afraid these are diagnoses and generalizations. Probably this is why the blogpost still sounds like a rant (even though you toned it down).

The mental habits I meant is precisely not to jump to the conclusions, do not generalize, but be curious, allow yourself to be mistaken and to learn new ways of getting things done. This wouldn’t solve any problems with julia for sure. But would definitely make your experiences with julia (and basically any other language) much more pleasant. And that’s what the blogpost is about, isn’t it? :wink:

Ok, then I’m the second;) I used to work in a very large C++ project and found that thousands (I’m not exaggerating) of lines of GCC output when a substitution in template fails are incredibly useful. Therefore I decided to switch tools and I’m fine with julia stacktraces. life is too short to spend time with tools you don’t enjoy using :wink:

10 Likes
121

Count me as third. The problem with static languages is how much of a bother it is to do small experiments with just the part of the code (be it a whole function or just part of a function) to check some assumptions. Even if you do everything by the the book (use small functions, have automated tests, etc…), in the best case you will yet need add a temporary call to the function in the tests, comment all the rest of the tests, and compile probably a lot of unrelated things, just to test something.

12 Likes