4 ms·

I would love to have something like this. With Julia, a programming language that I like very much, it's really a pain.

salty_biscuits 4y ago
I have high hopes for this project https://github.com/JuliaLang/JuliaSyntax.jl https://github.com/JuliaLang/JuliaSyntax.jl
blindseer 4y ago
The first thing I thought when reading this blogpost was "Can I send this to a Julia core dev? Would they understand how much nicer error messages are in other ecosystems?" I think even basic things like the order of error messages is all backwards to me. Take this very silly example: julia> foo() = println(123 * "hello") foo (generic function with 1 method) julia> bar() = foo() bar (generic function with 1 method) julia> baz() = bar() baz (generic function with 1 method) julia> baz() ERROR: MethodError: no method matching *(::Int64, ::String) Closest candidates are: *(::Any, ::Any, ::Any, ::Any...) at operators.jl:591 *(::T, ::T) where T<:Union{Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8} at int.jl:88 *(::Union{AbstractChar, AbstractString}, ::Union{AbstractChar, AbstractString}...) at strings/basic.jl:260 ... Stacktrace: [1] foo() @ Main ./REPL[3]:1 [2] bar() @ Main ./REPL[4]:1 [3] baz() @ Main ./REPL[5]:1 [4] top-level scope @ REPL[6]:1 In Julia the type of the error is printed out immediately at the point where the error occurs, then a bunch of hints about closest candidates, then the function and filename where the error occurred, then the function that called it, then the function that called that. It's all backwards. In order, it's 1. important information 2. arbitrary hint which could be useless 3. most important (where the error occurred) 4. less important 5. less less important When the stacktrace is long, this is so painful to deal with in a REPL environment. You almost always have to scroll to find out information about the error, and you have to scroll just the right amount, or else ... And even the stacktrace arguably doesn't contain all the information it should, demonstrated well by this blog post how nice it could be. VSCode is preferred way of using Julia (for me and for better or for worse for everyone). For long stacktraces I have to first scroll all the way back up to see what is going on. So often I have a very tiny terminal open at the bottom of my screen, and it is EXTREMELY annoying to do that. I often scroll too much and I overshoot, and just finding the error is a challenge. There's so many times where I'm just struggling to find the error, and it's just an exercise in frustration to be honest. Here's the same example in Python. In [1]: def foo(): ...: print("1" + 1) ...: In [2]: def bar(): ...: foo() ...: In [3]: def baz(): ...: bar() ...: In [4]: baz() --------------------------------------------------------------------------- TypeError Traceback (most recent call last) Input In [4], in <cell line: 1>() ----> 1 baz() Input In [3], in baz() 1 def baz(): ----> 2 bar() Input In [2], in bar() 1 def bar(): ----> 2 foo() Input In [1], in foo() 1 def foo(): ----> 2 print("1" + 1) TypeError: can only concatenate str (not "int") to str The last line tells me the error. The line before that tells me where. I can scroll up to find more information if I want to. Why doesn't Julia work like this? Who knows. I've made suggestions on slack and to people in person but I've been met with disdain for the most part. Not to mention that almost ALL my errors are MethodError types. And worst of all, Julia doesn't show you the string of your code in the error, so you have to click on the line that has the file and hope VSCode opens that file at that line. It's SO backwards. If you are using neovim / vim / tmux, you have manually copy paste the line that contains the file name and line number into a new terminal. Or just navigate to the file and line number manually. Ugh. In Python, I can see the error and know what caused the error. In Julia, I see the error, kind of sort of know what might be the problem, try to find the exact file and line, check if my assumptions are correct, if not traverse up the method dispatch call stack and try to predict what might be going on. And I consider myself an experienced Julia developer. For my team members coming from Rust or Python when they get a error running code, it's just brutal during the learning process. I've had people come up to me and say to my face, Julia sucks and I shouldn't write or advocate it anymore. This is barely touching the surface. Error reporting with macros is even worse. My team has managed to segfault our program multiple times and we are left completely in the dust then. There's SOOOOO many examples like this where I think usability in Julia needs to be improved. Sigh. Maybe some day.
- adgjlsfhk1 4y ago
  Yeah we really need to do better on this. One thing that would help a lot is if we moved error messages to a pager system since it would make it a lot easier to jump to beginning/end of error message. A lot of this work is relatively accessible for people new to hacking on Julia's internals if anyone wants to take a shot at it. I think a lot of the reason Julia is lacking some tooling compared to other languages is that Julia attracts a lot of people who don't have traditional CS backgrounds which affects the types of tools that get written. We have state of the art diffeq solvers and really good remote calls to C/Fortran, but the dev tools aren't as mature as I wish they were.

I have high hopes for this project https://github.com/JuliaLang/JuliaSyntax.jl https://github.com/JuliaLang/JuliaSyntax.jl

blindseer 4y ago

The first thing I thought when reading this blogpost was "Can I send this to a Julia core dev? Would they understand how much nicer error messages are in other ecosystems?" I think even basic things like the order of error messages is all backwards to me. Take this very silly example: julia> foo() = println(123 * "hello") foo (generic function with 1 method) julia> bar() = foo() bar (generic function with 1 method) julia> baz() = bar() baz (generic function with 1 method) julia> baz() ERROR: MethodError: no method matching *(::Int64, ::String) Closest candidates are: *(::Any, ::Any, ::Any, ::Any...) at operators.jl:591 *(::T, ::T) where T<:Union{Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8} at int.jl:88 *(::Union{AbstractChar, AbstractString}, ::Union{AbstractChar, AbstractString}...) at strings/basic.jl:260 ... Stacktrace: [1] foo() @ Main ./REPL[3]:1 [2] bar() @ Main ./REPL[4]:1 [3] baz() @ Main ./REPL[5]:1 [4] top-level scope @ REPL[6]:1 In Julia the type of the error is printed out immediately at the point where the error occurs, then a bunch of hints about closest candidates, then the function and filename where the error occurred, then the function that called it, then the function that called that. It's all backwards. In order, it's 1. important information 2. arbitrary hint which could be useless 3. most important (where the error occurred) 4. less important 5. less less important When the stacktrace is long, this is so painful to deal with in a REPL environment. You almost always have to scroll to find out information about the error, and you have to scroll just the right amount, or else ... And even the stacktrace arguably doesn't contain all the information it should, demonstrated well by this blog post how nice it could be. VSCode is preferred way of using Julia (for me and for better or for worse for everyone). For long stacktraces I have to first scroll all the way back up to see what is going on. So often I have a very tiny terminal open at the bottom of my screen, and it is EXTREMELY annoying to do that. I often scroll too much and I overshoot, and just finding the error is a challenge. There's so many times where I'm just struggling to find the error, and it's just an exercise in frustration to be honest. Here's the same example in Python. In [1]: def foo(): ...: print("1" + 1) ...: In [2]: def bar(): ...: foo() ...: In [3]: def baz(): ...: bar() ...: In [4]: baz() --------------------------------------------------------------------------- TypeError Traceback (most recent call last) Input In [4], in <cell line: 1>() ----> 1 baz() Input In [3], in baz() 1 def baz(): ----> 2 bar() Input In [2], in bar() 1 def bar(): ----> 2 foo() Input In [1], in foo() 1 def foo(): ----> 2 print("1" + 1) TypeError: can only concatenate str (not "int") to str The last line tells me the error. The line before that tells me where. I can scroll up to find more information if I want to. Why doesn't Julia work like this? Who knows. I've made suggestions on slack and to people in person but I've been met with disdain for the most part. Not to mention that almost ALL my errors are MethodError types. And worst of all, Julia doesn't show you the string of your code in the error, so you have to click on the line that has the file and hope VSCode opens that file at that line. It's SO backwards. If you are using neovim / vim / tmux, you have manually copy paste the line that contains the file name and line number into a new terminal. Or just navigate to the file and line number manually. Ugh. In Python, I can see the error and know what caused the error. In Julia, I see the error, kind of sort of know what might be the problem, try to find the exact file and line, check if my assumptions are correct, if not traverse up the method dispatch call stack and try to predict what might be going on. And I consider myself an experienced Julia developer. For my team members coming from Rust or Python when they get a error running code, it's just brutal during the learning process. I've had people come up to me and say to my face, Julia sucks and I shouldn't write or advocate it anymore. This is barely touching the surface. Error reporting with macros is even worse. My team has managed to segfault our program multiple times and we are left completely in the dust then. There's SOOOOO many examples like this where I think usability in Julia needs to be improved. Sigh. Maybe some day.

adgjlsfhk1 4y ago
Yeah we really need to do better on this. One thing that would help a lot is if we moved error messages to a pager system since it would make it a lot easier to jump to beginning/end of error message. A lot of this work is relatively accessible for people new to hacking on Julia's internals if anyone wants to take a shot at it. I think a lot of the reason Julia is lacking some tooling compared to other languages is that Julia attracts a lot of people who don't have traditional CS backgrounds which affects the types of tools that get written. We have state of the art diffeq solvers and really good remote calls to C/Fortran, but the dev tools aren't as mature as I wish they were.