Live data from Hacker News

Julia 1.6 addresses latency issues

lwn.net

121–130 of 160 posts

Re: Julia 1.6 addresses latency issues

#121
post #86
post #84

Earlier quoted context omitted.

I use Julia as my main driver these days and have shared some of this experience but not all 1) I use VScode and have had 0 problems with Revise. It Just Works when using the Julia extension + built in REPL. I actually prefer the Julia environment to Python in VScode, I have way fewer problems when doing a Notebook-like workflow where I’m writing library code at the same time 2) Agreed, I also wish there was a better…

> had 0 problems with Revise Try changing a struct.

Yes, that is an important limitation of Revise that I hope goes away.

Until then, consider this work-around: https://github.com/BeastyBlacksmith/ProtoStructs.jl

Re: Julia 1.6 addresses latency issues

#122
post #113
post #112

Earlier quoted context omitted.

Common Lisp actually doesn't specify a mechanism for this. There are implementations that can compile to e.g. DLL: http://www.lispworks.com/documentation/lw71/DV/html/delivery... https://franz.com/support/documentation/current/doc/dll.htm Unfortunately none of the FOSS implementations have this ability (to my knowledge). There is nothing inherently in Common Lisp that mandates the "core dump" delivery model.

One correction to my post above - Corman Lisp is a Free implementation that does have the ability to produce DLLs, but it is limited to Windows: https://github.com/sharplispers/cormanlisp/blob/master/docum...

how about ECL? That should do that, too.

Re: Julia 1.6 addresses latency issues

#123
post #54
post #49

Earlier quoted context omitted.

The main SDKs and programming paradigms for Java and C# both don't mesh well with AOT, though. Reflection, heavy reflection based frameworks. Not that many places use Java/C# AOT compilation, except for games/iOS apps. Almost every place I've seen using Java/C# was using JIT.

Android uses a mix of JIT/AOT, just as most Java embedded development. As for not everything being supported, well that is no different from having C++ code with RTTI and exceptions disabled, or being forced into a specific linking model due to possible problems with a third party dependency.

and that is why they failed to provide proper toolkits for android smartwatch and were forced to call samsung for help

Re: Julia 1.6 addresses latency issues

#124
post #116

Earlier quoted context omitted.

I agree. The Julia community is defensive. When you criticize Julia, often their first reaction is to say you are doing something wrong or to convince you Julia is perfect for everything. I was enthusiastic about Julia but not anymore.

It's not the first community with that attitude that I've witnessed. I've first seen this with Ember.JS (the Javascript framework everybody has forgotten about), then later with the Swift programming language. It could be interesting to investigate why things like this happen and how a community needs to be managed in order not to run into the same problem.

I'm a moderator at Julia's discourse site. We've seen this happen and we're working on improving this, but I'm also (biased and) sympathetic to the "Julia community" writ large.

Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them.

I think some of this tension comes from an expectation mismatch. Some of the changes noted in these comments about how Julia is presented on julialang.org were made specifically due to this sort of expectation mismatch.

This doesn't mean that nobody in the community cares about improving workflows — in fact I know that's not true. But if you want to use Julia today, there are definitely some happy paths that we should guide folks towards.

Re: Julia 1.6 addresses latency issues

#125

Earlier quoted context omitted.

It's not the first community with that attitude that I've witnessed. I've first seen this with Ember.JS (the Javascript framework everybody has forgotten about), then later with the Swift programming language. It could be interesting to investigate why things like this happen and how a community needs to be managed in order not to run into the same problem.

I'm a moderator at Julia's discourse site. We've seen this happen and we're working on improving this, but I'm also (biased and) sympathetic to the "Julia community" writ large. Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just…

> Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them.

And that's exactly what I've seen over and over again, in different communities, such as the ones I've mentioned, this attitude of "you're holding it wrong".

No language or tool can be everything to everybody, that's perfectly reasonable. If the goal of Julia is different from that of people that want to run applications in production—or at least those concerns aren't the most important ones—fair enough. But all too often (and I'm not necessarily talking about Julia here; I haven't spent enough time on the Julia forums, I'm mostly referring to some of the other examples I've cited) real concerns are just dismissed out of hand.

I also don't believe that enforcing certain very specific workflows at the exclusion of any others is necessarily a great way to become a language that lots of people want to use. People come from different backgrounds and have different preferences and needs (sometimes for very good reasons), successful languages like Python recognise this and let you work with a wide range of tools.

Finally, I'm just very skeptical about a certain kind of NIH syndrome that I've seen in some of these communities, something like "encapsulation? well, all these other languages might need it, but we actually don't, because XYZ" or similar things.

Re: Julia 1.6 addresses latency issues

#126

Earlier quoted context omitted.

I'm a moderator at Julia's discourse site. We've seen this happen and we're working on improving this, but I'm also (biased and) sympathetic to the "Julia community" writ large. Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just…

> Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times —…

I mean, you're totally free to blaze your own development workflow trail. Even better if you can help in the ongoing clearing and paving of the less-used trails. But when someone complains that a less-used trail is rocky, it's gonna be hard for everyone on the golden brick road to avoid suggesting taking their route... especially if it's leading to the same destination.

And yes, that destination does include production.

Re: Julia 1.6 addresses latency issues

#127

Earlier quoted context omitted.

I feel like the DifferentialEquations package is a screamingly obvious counterexample to your claim. It has many sub-modules. Moreover, the whole point of multimethods is to live in the main semantic namespace, you do not need as many name spaces because there are no names to clash.

> you do not need as many name spaces because there are no names to clash. You know, maybe you're right and I can't prove you wrong, but this is the kind of thing that IMHO application developers read and think "yeah no, been there, done that, never again". Because many people's experience is that names do clash, again, and again, and again, and I fail to see why multimethods should solve that.

Does this example help: There is a name defined in Base, e.g. `pop`. In languages that do not use multumethods, when you created your own "FancyContainerLibrary" you need to create a new `pop` and ensure it does not clash with `Base.pop`. In languages with multimethods you just extend `Base.pop` to work on your new type. Julia can do both: it has perfectly normal support for namespaces, but frequently you will be extending Base methods instead of working in your own namespace (of course, all your private functions are usually unexported and available only from your namespace and do not polute the global space).

Re: Julia 1.6 addresses latency issues

#128

Earlier quoted context omitted.

> Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times —…

I mean, you're totally free to blaze your own development workflow trail. Even better if you can help in the ongoing clearing and paving of the less-used trails. But when someone complains that a less-used trail is rocky, it's gonna be hard for everyone on the golden brick road to avoid suggesting taking their route... especially if it's leading to the same destination. And yes, that destination does include producti…

Yes you are, but then you have to wait a minute or so after any single change to any file if you do a script workflow. If you do a Revise workflow you end up doing mostly the same because it just breaks all the time and you have to reload the session. Or you can use some bizarre hack like DaemonMode.jl that also just breaks all the time.

Julia is hard to debug as is (and this is fully acceptable to me due to the architecture) and these hacks on hacks make it just impossible.

Julia suffers from the same "fancy calculator" approach than e.g. R and Matlab, and like those, they refuse to take note of the decades of experience in software development that this just leads to a total mess if you have anything more complicated than a one-off analysis. It's like insisting on editing files with ed because that's how it's always been done.

Re: Julia 1.6 addresses latency issues

#129

Earlier quoted context omitted.

I'm a moderator at Julia's discourse site. We've seen this happen and we're working on improving this, but I'm also (biased and) sympathetic to the "Julia community" writ large. Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just…

> Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times —…

>And that's exactly what I've seen over and over again, in different communities, such as the ones I've mentioned, this attitude of "you're holding it wrong".

You're really reading this wrong. The issue is moreso about personal knowledge. I see this on the Discourse sometimes where someone comes blazing in saying "I want to use PyCharm for Julia and I run into ...", "Special Lisp-only IDE has a Julia plugin and it fails because ...", or "I have this special terminal setup and I no 0 latency and ...". The answer of course is, if you need help, use VS Code or Juno/Atom. Those have a larger userbase which that has fixed exactly those issues and has a helpful dev community on those site which will get you up and running. That's not "you're holding it wrong", that's people trying to help you into an area where they know how to help you. You can shrug it all off and blame it on them, but at the end of the day, people are sharing what they know works, a reliable solution they built for exactly this problem, and then are getting flamed on the internet for having "NIH syndrome" for not fixing some random IDE plugin they've never used. I just don't see how you can expect every person to be an expert on every possible workflow you can imagine and start throwing flame when someone tries to lead you to water.

In the Julia community in particular you tend to have people who are more experts in their scientific domains. I am in that category: I can help you in anything ML, high performance computing, differential equations, etc. but I use Windows and the Juno IDE. If you open an issue about something weird happening on emacs, I wouldn't even know how to get it installed, sorry, that's not my expertise. The Julia community has a lot more people in probabilistic programming than it has Javascript devs, and so people share how they know how to fix your problem "can you run it in VS Code and show the profile?", not "here's how to run some daemon server thing" etc. And that's perfectly fine, it has its advantages and disadvantages.

Re: Julia 1.6 addresses latency issues

#130
post #51

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook. Things that kind of suck about using Julia for production: 1. Never could get R…

How did you cope with the lack of REPL on Rust's side?

Rust REPL'S do exist, though I don't need it very often because the static typing allows me to know exactly what's going on with each line of code.
Post reply on HN