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

Julia adoption keeps climbing

hpcwire.com

Post reply on HN
Print view View original

71–80 of 309 posts

Re: Julia adoption keeps climbing

#71

Post by jpsamaroo »

sgt101 wrote: post #60
fsh wrote: post #52

Earlier quoted context omitted.

I think that a slow JIT is problematic in any application except for non-interactive numerical calculations. For example in a GUI software or in a server application it would be very undesirable to have each function run a million times slower the first time it gets called.

For GUI's I don't see this as an issue - JITs run alot faster than humans. All of Javascript is on a JIT - and thats the dominant UI for now! For servers generally you find that users are all calling the same function so it's very rare that you hit a blip - much more commonly users get performance problems from something else in the stack like the network or the client, and while Javascript is the dominant front end…

JavaScript's JIT is a tracing JIT, so it can compile code in the background while the interpreter/less optimized compiled code is actually running. In Julia, the compiler runs first, and then the compiled code is run. This will probably eventually change as Julia's compiler improves, but regardless, it's important to note this distinction.

Re: Julia adoption keeps climbing

#72

Post by ForHackernews »

physicsguy wrote: post #45
bsdubernerd wrote: post #10

Earlier quoted context omitted.

In my tests I frequently switch between cpython, pypy and julia (depending on the libraries/task I want to perform) and I haven't found the JIT overhead to be worse than pypy on average. Count me as one of the 1-based index haters, but I do love multiple dispatch and the language in general. As a language for explorative tools and analysis is on par of python (strict preference between the two according to taste). To…

Are many scientists using PyPy though? I never saw it in use in academia even though I'd tried it out personally.

I've never seen PyPy used anywhere by anyone, except for in talks about PyPy at PyCon.

Re: Julia adoption keeps climbing

#73

Post by carterschonwald »

jakobnissen wrote: post #68
enriquto wrote: post #44

Earlier quoted context omitted.

Wait, why can't you use a regular jupyter notebook for julia? The "ju" in "jupyter" stands for what, then?

You can, but Pluto is (I would argue) a better notebook than Jupyter. Regardless, the latency experienced with Julia applies equally whether you use Pluto, Jupyter, or any other front-end.

Pluto is a notebook design the world needs. It’s nice enough for it to motivate me to use Julia for some new prjects.

But yeah latency kills :)

Re: Julia adoption keeps climbing

#74

Post by szemet »

mlthoughts2018 wrote: post #58
pansa2 wrote: post #49

Earlier quoted context omitted.

> prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-lev…

Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython. The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python.…

> Using extension modules is just a time-tested, highly organized, modular, robust design pattern.

I really don't get this. I'am fully on the side that limitations may increase design quality. E.g I accept the argument that Haskell immutability often leads to good design, I also believe the same true for Rust ownership rules (it often forces a design where components have a well defined responsibility: this component only manages resource X starting from { until }.)

But having a performance boundary between components, why would that help?

E.g. This algorithm will be fast with floats but will be slow with complex numbers. Or: You can provide X,Y as callback function to our component, it will be blessed and fast, but providing your custom function Z it will be slow.

So you should implement support for callback Z in a different layer but not for callback X,Y, and you should rewrite your algorithm in a lower level layer just to support complex numbers. Will this really lead to a better design?

Re: Julia adoption keeps climbing

#75

Post by jakobnissen »

uncrex wrote: post #70
superbcarrot wrote: post #4

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that should work intuitively sometimes doesn't, and when you get a cryptic error message, it's difficult to find relevant help online. And when you do find help, some of it is out of date because the language has changed over the past few years. - You can squeeze a lot o…

> way better People like to substitute "10x better" here but I think the real number is 100,000x better, aka it's not possible by default. Q: What it would take to replace Windows? A: iPhone was a new product category that targetted a new market.

It does happen, though. C has mostly replaced FORTRAN for scientific applications. Not entirely, FORTRAN is (infamously) still used, but I don't know anyone who has started a new project with FORTRAN.

Just 6 years ago, I was taught Perl in my Introduction to Bioinformatics course. The teachers were still using Perl because it used to be the go-to language for bioinformaticians. The year after, and every year since, they've taught using Python.

Re: Julia adoption keeps climbing

#76

Post by amelius »

My gripes, feel free to disagree:

1. Julia uses base-1 indexing.

2. Julia uses an "end" keyword everywhere, which is imho too verbose (and the corresponding "begin" is missing so it's inconsistent).

Re: Julia adoption keeps climbing

#77

Post by jakobnissen »

cricci16 wrote: post #8

In my modest experience the perfect Julia slogan would be: "fast as C, easy as python, but NEVER the two together" All the sentences: "When you’re writing various algorithms, you don’t necessarily want to think about whether you’re on a GPU, or whether you’re on a distributed computer. You don’t necessarily want to think about how you’ve implemented the specific data structure. What you want to do is talk about what…

Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading.

However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, where ever you can gain maximal performance with high-level syntax, you can just choose to do that. A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen.

Re: Julia adoption keeps climbing

#78

Post by D13Fd »

mhd wrote: post #66
D13Fd wrote: post #63

It’s extremely silly, but I don’t really like the name Julia for a programming language. It’s just a bit uncomfortable to have a programming language with a particular, kind of formal-sounding human name like Julia (or like Michael, Lauren, or Jonathan). It just feels weird to me. I know a number of people (family, friends, colleagues) named Julia. I honestly think it could have an effect on adoption. People have to…

What about "Ada", "Miranda" or "Haskell"? First names, too, albeit ones much less common these days. ("Linda" the language isn't even in that category, popularity-wise, although the source of the name seems to be a weirder story)

I had no idea that “Ada” and “Haskell” were intended to be people names. Those are not super common names. And I had totally forgotten about Miranda, which I agree has the same issue.

Re: Julia adoption keeps climbing

#79

Post by enriquto »

spacedome wrote: post #69
enriquto wrote: post #44

Earlier quoted context omitted.

Wait, why can't you use a regular jupyter notebook for julia? The "ju" in "jupyter" stands for what, then?

You absolutely can use regular jupyter notebooks for julia! Pluto has some advantages, like being stored as a normal julia file. The julia startup time issues affect both.

> being stored as a normal julia file.

Oh, man, this is indeed a major feature. My main point of friction with jupyter notebooks is the stupid json ipynb format. Why can't it be just a regular language file with comments?

Re: Julia adoption keeps climbing

#80

Post by dan-robertson »

I’ve used juli a few times over the years.

For some numerical things it’s nice with easy interfaces to modern algorithms. I solved a differential equation recently and it just worked. And Julia feels like a much more proper programming language than matlab.

At the lower level (which I haven’t looked at in a while so may have changed) I found it a bit confusing and messy. The subtyping and method selection are tricky to get right and they are fundamental to important parts of the language like it’s numeric tower. But libraries seem to just work.

Macros were horrific and the ast is inscrutable and liable to change from one version to the next. Quasiquoting was also tricky. So I wouldn’t recommend trying to do anything weird with them. But maybe they are good now.

Pluto notebooks seem a great concept. I tried them recently and mostly they worked (sometimes they didn’t get dependencies right but it’s still beta). I felt like I was fighting a bit with plots.jl. I don’t know if there are things that weren’t obvious to me that I was missing or if it can just be a bit annoying. I haven’t tried gadfly but I would like to at some point. I’ve heard good things about ggplot2 which it is inspired by.

I felt like documentation was a bit lacking in good straightforward tutorials and examples. As well as documentation in general. But I don’t want to put too much emphasis on that.

Post reply on HN