Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6 addresses latency issues

lwn.net

Post reply on HN
Print view View original

111–120 of 160 posts

Re: Julia 1.6 addresses latency issues

#111

Post by dm3 »

neolog wrote: post #86
tbenst wrote: 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.

That's definitely a problem. I work around by naming all my structs with a `_1` suffix and `%s/_1/_2/g` (VIM find-replacing) every time a struct changes. Otherwise I find Revise works great.

Re: Julia 1.6 addresses latency issues

#112

Post by louai »

nightfly wrote: post #46
reikonomusha wrote: post #28

Earlier quoted context omitted.

Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive a…

The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.

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.

Re: Julia 1.6 addresses latency issues

#113

Post by louai »

louai wrote: post #112
nightfly wrote: post #46

Earlier quoted context omitted.

The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.

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...

Re: Julia 1.6 addresses latency issues

#114

Post by Tainnor »

adgjlsfhk1 wrote: post #72
Tainnor wrote: post #60

Earlier quoted context omitted.

I would also add: 5. The module system is very primitive. 6. The testing framework is extremely barebones. I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.

Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.

I could make a laundry list of features (for example: not being forced into a linear order of includes (or at least having idempotent "include"s), no namespace collision for test files, not having to list all the tests in "runtests.jl",[1] support for pending tests, support for parameterised tests, proper assertion libraries with more useful error output, etc. pp.), but I also feel like Julia developers could just look at any of the other major general purpose languages, almost all of which have better module systems and testing frameworks because these are things that matter to application developers.

[1]: I actually tried to automate some of this in a project: https://gitlab.com/pfrasa/morcrypto/-/blob/master/test/runte...

Re: Julia 1.6 addresses latency issues

#115

Post by Tainnor »

krastanov wrote: post #80
smabie wrote: post #78

Earlier quoted context omitted.

It seemed to me that no one actually made projects that used the module system at all? Like no name spacing what so ever, just a bunch of include!s

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.

Re: Julia 1.6 addresses latency issues

#116

Post by acmj »

jampekka wrote: post #64
smabie wrote: 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…

It's sad to see that the Julia ecosystem does not address these issues at all. Maybe Julia people are in some kind of bubble of people who like Julia and generalize that to all potential users and contributors. The true process is probably that people with other workflows (eg. non-REPL/Notebook) and past experiences (esp. more "general purpose" languages) just give up and are never heard of again. I've ranted about v…

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.

Re: Julia 1.6 addresses latency issues

#117

Post by fishmaster »

neolog wrote: post #86
tbenst wrote: 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.

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

Re: Julia 1.6 addresses latency issues

#118

Post by m_mueller »

oscardssmith wrote: post #104
m_mueller wrote: post #102

Earlier quoted context omitted.

I highly doubt it for one core feature: performance. For a little while it looked like Python 4 might fix this (by using type hints to JIT) , but it was quickly given up. IMO a big shame as it is the one thing holding python back.

I think Julia actually does a pretty good job of showing that the problem isn't types. The problem is semantics. Julia's restriction is eval to the global scope is a perfect example of this. It has a pretty minor on code, but a massive effect on performance. Python has a ton of things like this where a slightly different (and totally breaking) semantic change prevents optimization.

My poinr wasn’t about type system per se but the ability to compile code down to natively execute without going through an interpreter. Whether you solve that through type inference or type hints I honestly don’t care, but afaik Julia has an easier job by allowing you to make types explicit on the data structure side while being flexible for the algorithms. Semantics are certainly also a big part, but it would be nice to have first party support for what Numba does, JITing a reduced set of semantics but keep everything else compatible.

Re: Julia 1.6 addresses latency issues

#119

Post by jonniedie »

fishmaster wrote: post #117
neolog wrote: post #86

Earlier quoted context omitted.

> had 0 problems with Revise Try changing a struct.

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.

Re: Julia 1.6 addresses latency issues

#120

Post by Tainnor »

acmj wrote: post #116
jampekka wrote: post #64

Earlier quoted context omitted.

It's sad to see that the Julia ecosystem does not address these issues at all. Maybe Julia people are in some kind of bubble of people who like Julia and generalize that to all potential users and contributors. The true process is probably that people with other workflows (eg. non-REPL/Notebook) and past experiences (esp. more "general purpose" languages) just give up and are never heard of again. I've ranted about v…

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.
Post reply on HN