Hacker News Reader

Comment by systemvoltage | Hacker News Reader

To add to that, even if Julia had excellent documentation literally everywhere and on every library, I wish there were better stack trace and meaningful error messages. Even if Julia performed 10x worse, this overlooked aspect of Julia would make up for it. It is rather unbelievable how much time I need to spend to figure out what's wrong with a particular piece of Julia code.

Founders of Julia - please focus on error messages. Some cool things from Rust: https://doc.rust-lang.org/edition-guide/rust-2018/the-compil...

View on HN

As walnuss says below, these things are already being worked on. If you tried Julia a few months or couple of years ago, you'll find that stacktraces have already got quite a lot better.

One of the things that the Julia community could greatly benefit from is more compiler contributors. Languages like Rust naturally attract compiler folks, and those like Go have the backing of Google.

Julia has more complex compiler due to our dynamic type system, which the users absolutely love. But it also puts a lot of strain on the compiler team, which is quite small. So if any folks with experience in compiler technology on HN are looking for interesting projects to contribute to, please do look into Julia.

We've done better over the years increasing our bus number on the compiler codebase overall. More contributions in all areas of the toolchain would be great to have!

As bystander I love the work you guys are doing, in a way it feels like Dylan was reborn and found a place in scientific computing.

As a user of Julia for 2-3 years, is there any guidance for someone looking to help with the compiler?

It's being worked on. I am rather excited for the upcoming work that makes the parser replaceable and allows us to actually give good syntax errors! There is some discussion about making error printing more configurable so that one can skip stack-frames that are unlikely to be the cause (albeit that's a double-edged sword).

I think this is quite a hard problem to solve. A Python wrapper of some some monolithic C library can check & reject any input which doesn't meet the spec, and tell you why. But a Julia library typically wants to be generic, you should (for instance) be able to pass it weird numbers that contain units/error bars/gradient info, that the library designer knew nothing about, and have these propagate through. When this works it's great, but when it fails, the failure point tends to be 10 layers down, in internal workings you've never heard of. That's part of why error messages are inscrutable.

The debugger has helped a lot for me.

https://julialang.org/blog/2019/03/debuggers/#debugger_and_r...

Lack of stack straces and poor error messages hasn't hindered the adoption of most compiled languages.

Naturally it is something to improve, but I bet that are still bigger fish to fry.

Different users have different problems. I’ll take the recent major advances in, say, start up time and multi threading instead of improvements to the error messages.

I don't think that there's a silver bullet for this. A compiler can only tell you where it caught an error: telling you where the error occurred is equivalent to the hard AI problem.

On the other hand, we the users can do a lot to help. After you've worked through those 30 stack frames to find the one that went wrong, you could send a PR to detect that. In many cases, I suspect it would help to just catch the error then re-throw it from the method that went wrong.

Reply on news.ycombinator.com