while of course you're correct on a technical level, I do tend to agree with the statement that Julia is not particularly friendly to bash-scripting-heavy workflows
Meh. For my purposes, Julia strikes a quite nice balance of fussiness versus permissiveness.
Sure, there's things where I find it too fussy and I wish it'd go "yeah yeah I get what you mean" and there's also things where I find myself thinking "man, I really wish you had complained to me about that, it was clearly a bug / bad style!"
But all-in-all, I find it's a language that mostly gets out of my way and lets me code, which I find very useful and nice for scripting.
I think if one finds things like scoping rules annoying for scripting, that might just come down to just knowing and being more familiar with another language that has different rules.
See, I find it the opposite - superficially fussy, but it lets the silliest things slide. I don’t want my function to struggle with type instability in some contexts (perhaps only showing up deep in a physics simulation or motion planning algorithm) and allocate a bunch of memory, I don’t want it to compile in the first place if that’s possible.
As we've been discussing in another thread, it's possible! One can "opt out" of Julia's dynamic behaviors on a function-by-function basis using the JET.jl tool for static analysis: https://aviatesk.github.io/JET.jl/dev/optanalysis/
Why not make this the default everywhere? Well, there are a lot of scientific use cases where it's convenient to have Python-style dynamic typing and interactivity. A cool thing about Julia is that it allows that, while _also_ allowing to achieve high-performance, all within a single language.
For the record, I do also love the static type system and overall design of Rust. But for my day job (research in numerical methods and computational physics), I find Julia to be the most efficient way to get the job done -- rapid algorithm prototyping, data analysis, plot generation, etc.
It may be worthwhile to understand where dynamic typing is helpful since this gets mentioned a lot. Python and other dynamic languages are increasingly reliant on static type checkers.
sorry - why would you expect a local declaration to be in scope for other code?
s is defined in the statement and then is undefined out of that statement because there is no other scope for it - it's at top level. just write s =0 and all is well as s exist in the global scope where your code lives as well...
OP should've written just `s=0`, yes. Because showcases their complaint better since, although works in REPL, also fails when in file. (It's also the example given in docs[1].) Now, it looks like they tried to make it fail.
Yes - the error reporting has always been one of my complaints about Julia (although it's hugely improved). I think that the Julia dev community are really really interested in cool language features and optimisations but much less empathic with numpties like me that can't understand why their code crashes. More work on this would be much better.
Although it's a bit of an challenge to get the interpreter to understand which thing that's out of scope should be in scope for the code to work (because it's all out of scope..)
currently if in a file i have
and I execute this file, I will get an error