Comment by ChrisRackauckas | Hacker News Reader

Comment by ChrisRackauckas | Hacker News Reader

Parent Full thread

ChrisRackauckas

>I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language.

What? It's basically a meme at this point for major contributors to write a list of what they think is bad. The language's creator did a nice Youtube video "What's bad about Julia?" at JuliaCon 2019 (https://www.youtube.com/watch?v=TPuJsgyu87U), one of my most popular blog posts of all time is "7 Julia Gotchas and How To Handle Them" (https://www.stochasticlifestyle.com/7-julia-gotchas-handle/), etc. What the community pushes back about is things that are factually incorrect or just silly and repetitive, like the n+1th discussion about 1-based indexing. It's stuff below like, "I want to do an interactive workflow but not use the REPL, so it's not working well"... well the REPL is literally the interactive piece that caches the compilation so just use it if that's what you're trying to do? Yes, nobody has time for that nonsense, but everyone chimes in for real substantive discussions like changing the Base iterator API, programming patterns that would reduce recompilation, etc.

I don't think that's fair. Your blog post is not about what you think is bad - at least, it doesn't read like it. It reads like a list of stumbling blocks and how to get around them. This is not the same as listing the major problems with the language.

Jeff's talk is indeed great, but... it's not mostly about what he thinks is bad, either. That part is quickly swept aside with "just so you know we know". The talk is really about some very specific problems in the type system that are so obscure that I don't even consider them worth mentioning in a blogpost about Julia's weaknesses.

>It reads like a list of stumbling blocks and how to get around them. This is not the same as listing the major problems with the language.

I mean, if by stumbling blocks you mean all of the things I thought was bad and all of the work arounds you have to know to get work done? I think the difference is that normally when I gripe I like to then elucidate why the bad things exist. To me that's more productive because digging into "why is it like that" starts to point towards "how do you fix it". But yes, giving the full detailed backstory behind what leads to the gripe naturally softens the blow because the reader then understands its purpose, but that's just reality. Very few things are truly and purely awful when you really see the full reason for them. Usually it's just an engineering trade-off.

Any language has stumbling blocks. That's _really_ different from fundamental issues with the language. There is no working around most of the issues mentioned here.

I think a million and one posts on 1-based indexing and "why no OOP" or some perceived weakness of the modules system and other silly things like that have led to a base defensive attitude.

But this post is criticism from someone actively using the language, well thought out, and things that you can not work around. It includes real currently unresolvable pain points.

And it doesn't sound like the Julia lang team has a plan for how to address them. Or it's not communicating that plan. After all, the talk you link by Jeff Bezanson name checks many of the issues raised here two years ago, to then continue to not talk about them ever again.

This feels like classic feedback from the Julia community. It really stifles any hope I have of the language recovering. I know there are reasons behind things, but they also seem blind to fixing the obvious stuff because of them

And yet, would you not agree that the most important pain points do improve over time? Most of the things I mention in the post: Latency, stability, ecosystem maturity, static analysis and the IDE experience is notably better now than just 1 year ago.

Yes "user experience" things like that are improving. And StaticCompiler/GPUCompiler is making good progress.

But I see no movement on the deeper problems, like the limitations of the type system (no effort on traits, function types, interfaces, etc).

I agree progress on the deeper problems is slow, and I also think that it is slow because 90%+ of the issues people have with Julia are "user experience" things (see any of the help forums as well as all of the previous HN discussions). Given a limited amount of resources, it's difficult to justify a deep dive into revamping the type system (AIUI multiple dispatch with complex types + traits is mostly unexplored territory) over improving latency and tooling. That's not to say it shouldn't be done, but in the absence of some significant (financial and development) support behind it I don't think the type system work will be prioritized.

(No response needed, just something to consider.)

In any large system, there are many problems that could have technical solutions but they're missed for one reason or another. Design mistakes occur from time to time and we can choose how we respond when they do. I want experts from other communities to join us, and they need to see that Julia will take their feedback seriously. With all due respect to your major contributions, I think we'll be better off if people in leadership roles take a more critical view of Julia, especially in public.

Yeah. Mike's "Iterate on it" [1] is a real "what's bad" post, as is OP's.

[1] https://mikeinnes.github.io/2020/06/04/iterate.html

>> I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language.

> well the REPL is literally the interactive piece that caches the compilation so just use it if that's what you're trying to do?

This answer may be exactly the kind of hostility that the GP is talking about.

People may have legitimate reasons for not using the REPL. Instead of adressing these reasons you dismiss them. A textbook case of "holding it wrong".

The thing is no one is saying that starting a process every time isn't a valid way to work — it works great in most scripting languages. What people are saying is that since it's slow and annoying in Julia currently, you might want to consider a REPL-based workflow with Revise. If the response to that is "But I don't wanna use the REPL!!" then what can one do? Ok, don't use the REPL. But as everyone has agreed, it's going to be a bit annoying. If that's a dealbreaker for you then you may not want to use Julia just yet — which is totally ok!

That interaction unfortunately seems to often get characterized as "The Julia devs don't care about startup time! They insist on REPL-driven development and refuse to work on it." Never mind that improving startup time and package loading has been the number one priority of the compiler team since Julia 1.0 and that it's gotten about 10x faster. There's also ongoing work to make it even faster using system images.

Sounds like expanding this into a blog post would be helpful

Reply on news.ycombinator.com