Julia is fantastic with a great community. The one issue I have though is the use of greek symbols, while great for those formally trained, may have a negative impact on wider adoption for deep learning.
Julia adoption keeps climbing
61–70 of 309 posts
Re: Julia adoption keeps climbing
#62Earlier 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 don't know. I also don't use pypy much, since python+numba is actually fast enough most of the time, and I always see pypy as a fallback to see if I can squeeze a little bit more performance before running a task.
Re: Julia adoption keeps climbing
#63It’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 say the name a lot in making a choice to adopt a language for a project. Names like C, C++, Java, Python are fairly neutral. “Julia” is just an awkward name in this context, in my opinion.
Re: Julia adoption keeps climbing
#64I'm a researcher, doing lots of numerical work both professionally and in hobby projects. While Julia has a lot of technical merits, there are just some superficial, syntax-level design decisions that strongly rub me the wrong way: 1-based indexing (makes interfacing with C code hard), explicit begin/end (verbose & ugly) and column-major indexing (personal preference). I understand that these follow in the footsteps of Fortran (and matlab), but they always feel wrong to me. I grew up on C-based languages, and these things made working with R and Lua difficult whenever I had to interface with any non-numerical code (which somehow even most of my research projects ended up needing). It's a weird hill to die on, but I personally will avoid Julia (and actively discourage students from using it, in case I need to work with their code) for as long as I can due to these design decisions.
Re: Julia adoption keeps climbing
#65Julia uses modern compiler technology to achieve close to native performance. This is not just generating LLVM IR. Julia also has it's own optimization system for language specific optimizations that LLVM struggle to do (due to language specific info getting lost in conversion to LLVM IR). Google's V8 (js interpreter) also uses modern compiler tech but I think it is not as capable as LLVM optimization vise (I don't t…
V8 and the Julia compiler work in quite different ways - because they solve quite different problems. In particular, Julia’s compiler only works well on code that is "type-stable", whereas V8 has no such limitation.
I know that V8 does some interesting stuff with it's types.
Julia's creators considered supporting optimization while designing the language.
Whereas the first javascript engine that even generated machine code came much later it's creation.
Js has weird features like being able to set a getter function to a array index. There was a memory corruption bug in V8 that the implementation of `Array.sort` would call a getter function in the array that would change the size of the array causing a memory corruption. This was used in a exploit.
Creators of V8 created a domain specific language called Torque to implement the language lol.
Re: Julia adoption keeps climbing
#66It’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)
Re: Julia adoption keeps climbing
#67Julia 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…
This is an insightful and level-headed comment that applies equally to R. Although Julia is a growing alternative to Fortran/C/etc for long-running computations, it remains awkward and unpleasant for interactive analysis. Users familiar with Python/R/etc must weight the benefits of Julia against its slow library startup, its cryptic error messages, and its thin documentation. Also, the lack of a community repository…
Yeah, the R community owes a lot of it's stability to Uwe Ligges, and his (sometimes annoying) insistence on CRAN package quality.
Re: Julia adoption keeps climbing
#68Earlier quoted context omitted.
I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.
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.
Re: Julia adoption keeps climbing
#69Earlier quoted context omitted.
I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.
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.
Re: Julia adoption keeps climbing
#70Julia 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.