Hacker News Reader

> 2) I personally found that Julia community is slightly hostile to feedback and negativity. May be it is just me but it has way too much hype-driven-positivity that leads to delusion.

I want to push back on this a bit, which I acknowledge is very ironic. In the past few years people consistently post on Discourse asking for fundamental changes to the language to make it more resemble python, C++, or whatever their preferred language is.

People often say Go is great because there is "only one way of doing things", yet people are very resistant to being told "the way" to do something in Julia. This has happened enough that it's prompted a pinned PSA on discourse: https://discourse.julialang.org/t/psa-julia-is-not-at-that-s...

It gets tiring! And i'm not sure how the community should handle these requests, but I don't think it's fair to blame all of the negativity on the Julia community when these somewhat misinformed, or even bad-faith posts are so frequent.

Completely agree with 4 and 5. I use Julia regularly and while it is great for scripts and proof of concepts of mathematical stuff it might be too complicated to implement in Python or in C++ once one starts to grow an application it is tremendously frustrating.

I have clear and satisfying workflows in C (vim + make + gdb + valgrind) and Python (vim/vs code, pdb) but I cannot say that debugging and tracing errors is a comfortable experience in Julia. Essential development tools are relegated to third-party libraries (e.g. Revise.jl and Debugger.jl) and are often clunky or responsiveness is limited (e.g. Revise.jl won't work when you change a struct)

I believe the problem is that, because of Julia is marketed towards scientific computing and HPC, it draws mostly from an academic user base which is not that interested in software development.

> I believe the problem is that, because of Julia is marketed towards scientific computing and HPC, it draws mostly from an academic user base which is not that interested in software development.

Although you have a point regarding Revise and Debugger, the last paragraph makes no sense at all. As a counterexample, Haskell drew mostly from an academic user base and many Haskell idioms have ended up in other real world *production* languages like Python (e.g. map, filter, reduce).

> It does not make sense at all.

Please, I am open to see why you think so.

> As a counterexample, Haskell drew mostly from an academic user base

May I infer from this statement that you agree with me that Julia draws mostly from an academic user base? In that case, I do not see how your counterexample invalidates what I said. Perhaps some constructs from Julia end up in "real world production languages" but what I said is that the development experience in Julia is subpar and it shows when one is trying to develop larger codebases where software engineering practices become more important.

> I personally found that Julia community is slightly hostile to feedback and negativity. May be it is just me but it has way too much hype-driven-positivity that leads to delusion.

Part of the problem, at least from what I observed here and in other dev communities, was that Julia had a large number of bad faith critics (probably larger than the number of active users, at the time) from about 0.2 to 0.5 or so. I'm talking about everyone who compared the runtime of hello world in the REPL, with start up time, to that of a compiled executable. There were piles and piles of fake benchmarks that did little more than compare BLAS bindings as though the differences were intrinsic to the language.

Sure, the Julia community could have reacted better to such (and a few people did: BenchmarkTools.jl was an early win in this area), but few people do react that way in practice.

Yeah, that might be true. I've read very poor criticisms of Julia other places on the Internet. Most famously perhaps the "giving up on Julia" blog. In fact, the lack of good criticism was what prompted me to write this post.

I probably should have added that I certainly find your post to be good criticism.

> observed here

For example?

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Agree with all of this except

> 5) I really like official libraries, not SomeBasicFunctionality.jl dependency. I am spoiled by Python.

Python's standard library is full of bad code that nobody has time to improve [1]. Over time, Julia packages will surpass the standard library too but we'll still be hauling it around and spending core-dev time on it for for backward-compatibility reasons. We should have a much much smaller standard library.

[1] https://pyfound.blogspot.com/2019/05/amber-brown-batteries-i...

I think the only difference is whether something is officially supported or not. When it is officially supported, it tends to not break and has to run through a bunch of tests that ensure that std lib doesn't break with every programming language release. It tightly couples them. With off the shelf libraries, there is always a delay.

I also have an ideological take - I think of programming languages as a tool box and like a car mechanic, you want to have dependable tools that are robust, don't break and has good support. Basic algorithms and datastructures should always be included in the programming language - this is subjective but I firmly believe in it.

Others have commented on stacktraces, so I wanted to mention that the debugging experience in VS Code (the replacement for Atom-based Juno) is much improved as of the past couple of months. Worth a revisit if you're using it already.

Regarding stdlib support, I feel like it's a toss-up. For numeric and data processing code, Julia has a much richer stdlib whereas I need at least Numpy in Python (and even then, working with anything not array-shaped is a pain). For more systems-y stuff though, Python has a much fuller stdlib (e.g. reading/writing a bunch of archive formats). The end result for me is that scripting with Julia feels high friction, and doing anything which requires any kind of throughput with Python feels like pulling teeth.

Point 4 is going to get explicit dev time after the initial stages of the new general purpose compiler plugin infra is completed.

Then, proper debugging and introspection tools will be easier to build.

Note that stack traces are a bunch better in 1.7 (not yet perfect though).

I like that they are colored now, but really what needs to be added is type parameter collapasing. In most cases, you want to see `::Dual{...}`, i.e. "it's a dual number", not `::Dual{typeof(ODESolution{sfjeoisjfsfsjslikj},sfsef,sefs}` (these can literally get to 3000 characters long). As an example of this, see the stacktraces in something like https://github.com/SciML/DiffEqOperators.jl/issues/419 . The thing is that it gives back more type information than the strictest dispatch: no function is dispatching off of that first 3000 character type parameter, so you know that printing that chunk of information is actually not informative to any method decisions. Automated type abbreviations could take that heuristic and chop out a lot of the cruft.

this would be beneficial not just for stacktraces but for printing values, too.

Well said, point 4 really resonates with me, they seem to want to be different over just using things that work well