Live data from Hacker News

Julia 1.6 addresses latency issues

lwn.net

131–140 of 160 posts

Re: Julia 1.6 addresses latency issues

#131
post #54

Earlier quoted context omitted.

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

Better watch the Wear talks, the only thing they are getting from Samsung is the Faces designer and the commitement to drop Tizen for Wear.

Is is still plain old Java/Kotlin/C++ as usual.

Press should be better informed, but that is asking too much in modern times.

Re: Julia 1.6 addresses latency issues

#132

Earlier quoted context omitted.

Wrap it in a module, then you can change it without any problems. It's not ideal, but it works very well in practice.

Revise can’t change structs in modules either. The only sane way I’ve found to handle this is using a Pluto notebook. But that’s not for everybody.

I can definitely redefine a struct in a module.

Re: Julia 1.6 addresses latency issues

#133

Earlier quoted context omitted.

Revise can’t change structs in modules either. The only sane way I’ve found to handle this is using a Pluto notebook. But that’s not for everybody.

I can definitely redefine a struct in a module.

Really? I’d love to know how to do that because I run against this issue every day. Are you in the package’s environment or using `includet`?

Re: Julia 1.6 addresses latency issues

#134

Earlier quoted context omitted.

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 arch…

And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses.

I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where you'll find the best success in both tooling and code structure for sustainable (and modern) development. We need to do a better job of helping folks more effectively develop and work with Julia before it becomes frustrating.

Re: Julia 1.6 addresses latency issues

#135

Earlier quoted context omitted.

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 arch…

And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses. I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where y…

Friction in general, or friction specific to Julia?

My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow session".

Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to being just stupid or something. But this is how it comes off to me, I think you mean something else, but I don't know what that is.

My approach is: I want files with code and I want to run some of those with some kind of entry point. And preferably organize it to files or something like that. This is the usual setup for general purpose programming languages. In general purpose programming you rarely tend to stick solely to one language, any larger project is usually a mishmash of different stuff, e.g. glue code in python, tight loops in C, maybe some bash thrown around to do some more trivial chores.

This is the overall structure of practically all general purpose programming languages. This requires interfacing with these languages (often done in bash or something in unixy systems at least) and tools that work regardless of language (e.g. version control, grepping, Make etc). Julia (and R and Matlab etc) just plain refuse to even consider this as a valid approach. If you mention it somewhere, you tend to get some bizarre instant putdowns that provide no real rationale, i.e. "you're just holding it wrong".

In programming I tend to think the whole computer and its OS and so on as the programming tool. My impression is that for Julia folks Julia is something totally separate from anything else in the computer. But I don't understand why. Is it that its felt that changing syntax on the fly is too cognitively demanding or something? This is something that one gets used to very fast. And also tends to ease the IMHO weird hung-ups on syntax. In fact, I think Julia has made some (IMHO misguided) syntactic decisions because they just want to do something differently from Python just for the sake of being different. I find this totally senseless.

Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable? It wouldn't take anything away from people using REPLs and Notebooks. We don't want to change the language, the language is fine and that's why we'd like to use it but just cant because these paper cuts!

I've expanded on my rationale for my workflow and how Julia makes it really difficult e.g. here, where I admittedly started with too strong wordings out of frustration: https://news.ycombinator.com/item?id=26134970

Re: Julia 1.6 addresses latency issues

#136
post #38

Earlier quoted context omitted.

Multiple dispatch and generic programming make Julia a productive language to work with. However, a given program may have unnecessary function specializations (which affect startup compile time) or unexpected dynamic dispatches (which affect runtime performance). These can be addressed with some important development patterns: checking for type stability via @code_warntype, using opaque structs or @nospecialize when…

This is exactly the problem with Julia, to achieve those (soo much vaunted) c-like-speeds you need quite a few contortions.

I don't think those contortions are all that crazy compared to what you have to do in C though anyways. And you can choose where to spend your effort in optimizing functions.

Sometimes, a function really is performance critical so you spend a ton of time fiddling with it to make it blazing fast, other times you write something non-optimal but straightforward. It's all the same language though, and unlike tools like Cython, you don't lose all your nice high level language features when you drop down to 'high performance julia code'.

Re: Julia 1.6 addresses latency issues

#137
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…

I'm just curious. Do you do symbolic math in Rust? I found a crate [1] that is a wrapper for SymEngine. However, it is no longer maintained.

[1] https://github.com/podo-os/symengine.rs

Re: Julia 1.6 addresses latency issues

#138

Earlier quoted context omitted.

And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses. I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where y…

Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow se…

> Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable?

Look, everyone wants static compilation, and it's almost certainly going to happen eventually. It's not unreasonable at all to want that. The only thing that would be unreasonable is to (apparently repeatedly!) imply or assert that this lack of static compilation (and/or better caching) is due to some bizarre perversion on the part of the community.

If you want it to happen faster, then stop complaining about it on HN, get familiar with the current attempts at true static compilation in e.g. https://github.com/tshort/StaticCompiler.jl/pull/46 and start contributing yourself.

Re: Julia 1.6 addresses latency issues

#139

Earlier quoted context omitted.

And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses. I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where y…

Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow se…

Couldn't agree more. What you said is a design flaw that the Julia community keeps denying. The Julia community also behaves defensively when it comes to performance. They refuse to accept that Julia doesn't compete with C/Rust on many non-numeric tasks in the real world. In addition, the Julia community has its own circle, its own style to write code. They will trash your code even if it is efficient and logically correct. I once compared implementations in different languages and found Julia is slower than others. Several of them jumped at me, criticized my coding style and blamed me for their fault. But in the end they couldn't improve the performance. At the Julia discourse, I was alone in the argument. That was a really bad experience.

Re: Julia 1.6 addresses latency issues

#140
post #107

Earlier quoted context omitted.

If you want a harder guarantee, well written numerical code will be as fast as any other language. If you find a counter example, let us know (it's probably something that should be fixed). For string processing and other gc heavy code, Julia has further to go. Julia's gc is pretty basic, and needs a lot of love. That said, for dataframes like workloads, Julia usually manages to hand with the best (data.table), and i…

My assumption is that there's nothing outstanding or remarkable about Julia's performance. Comparing to Python/Perl/Ruby/TCL is a good way to make any language seem fast, and comparing to C++ is a good way to make any language seem expressive. I'd be far more interested to hear about comparisons with alternatives that might actually be competitive - non-scripting languages with a reputation for being expressive, such…

If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written. Furthermore, Julia has been used on some of the world's fastest super-computers (in the performance critical bits), which as far as I know isn't true of Swift/Kotlin/C#.

Expressiveness is hard to judge objectively, but in my opinion at least, Multiple Dispatch is a massive win for writing composable, re-usable code, and there really isn't anything that compares on that front to Julia.

Post reply on HN