News for hackers. Stuff that matters.
Re:Julia v1.1 Release Notes by KenoFischer on Sunday January 27, 2019 @11:55PM (#19015402)
Worth pointing out that after the 1.0 release we've moved to a time-based release schedule, so this is mostly just accumulated niceties from the past three months. Lots of bigger things bring worked on separately .
Re:Julia v1.1 Release Notes by mlevental on Monday January 28, 2019 @09:11AM (#19017505)
this weekend I tried to experiment with Julia on Ubuntu 18 and found it's still very rough.

1. repl in juno is slow. like broken rendering slow. checking fallback renderer didn't help.

2. dependencies move too quickly. I was trying to reproduce the neural odes code

https://julialang.org/blog/2019/01/fluxdiffeq

and it's broken. one of the dependencies symengine uses some kind of is_windows check https://github.com/symengine/SymEngine.jl/pull/150

which is fixed but at .5.0 which is not what symengine was pinned to (.4.3.0) and add symengine#master didn't work (neither the hash).

3. what is precompiling and why does it happen every single time I restart the interpreter? can I just compile once and be done with it? because it takes minutes each time.

4. getting jupyter to recongize my kernel took I don't even know what? first it wasn't there then after trying to run ijulia notebook from repl, which didn't work, it was there.

Re:Julia v1.1 Release Notes by Certhas on Monday January 28, 2019 @09:55AM (#19017826)
I agree it's rough, but your experience isn't completely typical either. Fallback Renderer works for me on Ubuntu 18 (and everyone on my team with various different Linux flavours).

Pre-compilation shouldn't trigger all the time, and there is an explicit workflow page about how to avoid constantly triggering the need to restart Julia and JIT everything. It reduced my amount of cursing tremendously.

The ecosystem has improved loads since 1.0 came out but is still lacking in some corners.

The pay off for us has been worth it, but with so much outdated information out there, the tooling in a rough-around-the-edges state, and the documentation of core packages sometimes lacking it's also not something you can easily dip your toes into unfortunately.

Re:Julia v1.1 Release Notes by ChrisRackauckas on Monday January 28, 2019 @03:01PM (#19020540)
>and it's broken. one of the dependencies symengine uses some kind of is_windows check https://github.com/symengine/SymEngine.jl/pull/150

What do you mean it's broken? Is it because SymEngine couldn't install? SymEngine seems to have a lot of issues because it relies on Conda and builds its dependencies in an odd way. Python package management is notoriously rough, which is why we are excising it from DiffEq v6.0 (https://github.com/JuliaDiffEq/DifferentialEquations.jl/issu...).

Re:Julia v1.1 Release Notes by mlevental on Monday January 28, 2019 @03:45PM (#19020911)
the code written as is, is broken, as in yes i couldn't get DifferntialEquations to install, because somewhere in the dependency graph some package pins/pulls SymEngine v0.4.3 which has a deprecated use of is_windows, which is fixed in the PR that i linked to

https://github.com/symengine/SymEngine.jl/pull/150/files

the obvious fix was to update to the latest version of SymEngine using the #master modifier with Pkg.add() but it didn't work - it kept ignoring #master and adding v0.4.3 nonetheless. i then tried #5dfc78a, the hash of master, and neither did that work.

Re:Julia v1.1 Release Notes by nur0n on Monday January 28, 2019 @05:54PM (#19021882)
This is a known `Pkg` bug (the patch should be merged this week). In the meantime, you have to `pkg> rm SymEngine` followed by `pkg> add SymEngine#master`.
Re:Julia v1.1 Release Notes by nur0n on Monday January 28, 2019 @02:04PM (#19020121)
To be fair, points 1,2, and 4 are regarding the ecosystem, not the language. There are definitely rough edges, but one can not expect a fully mature ecosystem only a few months after 1.0 has been released.

For a streamlined workflow, I recommend Emacs + Revise.jl. I just edit my code in an Emacs buffer, and the Revise automatically updates the REPL to reflect the source. This makes the code feel tangible, more than any other language I have experienced.

Re:Julia v1.1 Release Notes by mlevental on Monday January 28, 2019 @02:12PM (#19020177)
>To be fair, points 1

juno is a product of the team

https://juliacomputing.com/products/juliapro.html

i'm assuming it's where they hope to make the bulk of the revenue from

Re:Julia v1.1 Release Notes by chrispeel on Friday February 08, 2019 @08:50PM (#19120198)
There are many more people who work on the language than those who work at Julia Computing.
Re:Julia v1.1 Release Notes by nur0n on Monday January 28, 2019 @02:14PM (#19020189)
JuliaComputing is not Julia the language
Re:Julia v1.1 Release Notes by mlevental on Monday January 28, 2019 @02:19PM (#19020225)
you're being pedantic; i'm aware juliacomputing is not /the/ language. in fact it's an organization of people that maintain the language AND the juno ide.

what is the value proposition of julia? productivity of python with the speed of c (or some kind of tagline like this). a large part of the productivity of python is the fantastic set of tools around python. hence it's quite fair to judge julia proper on the polish of the tools that you need in order to be productive in julia.

Re:Julia v1.1 Release Notes by nur0n on Monday January 28, 2019 @05:48PM (#19021828)
Apologies, I wasn't trying to be pedantic. My point is that Juno is decoupled from the language itself. You don't have do depend on it to be productive with Julia.

I agree that tooling has a significant influence on the productivity of a language. One does not only adopt a language, but the ecosystem and community around it. I think we both agree on this. I am simply trying to point out that there is an unavoidable delay between the maturity of the language and the maturity of the ecosystem. I think its fair to take this delay into account.

Re:Julia v1.1 Release Notes by elcritch on Monday January 28, 2019 @12:21AM (#19015471)
Anyone looked at running Julia via webassembly? I keep thinking it'd be awesome to run Jupyter notebooks completely in the browser. Given Julia builds on LLVM, perhaps it wouldn't be that challenging technologically.
Re:Julia v1.1 Release Notes by tomkwong on Monday January 28, 2019 @03:14AM (#19015934)
Looks like an experimental package exists https://github.com/tshort/ExportWebAssembly.jl

It's also one of the Google Summer of Code projects https://julialang.org/soc/projects/general.html

Re:Julia v1.1 Release Notes by leethargo on Monday January 28, 2019 @03:15AM (#19015939)
This is being worked on. Check out this project: https://github.com/Keno/julia-wasm

I think that currently, the Julia intepreter is compiled to Wasm, so LLVM is not yet involved?

Re:Julia v1.1 Release Notes by IshKebab on Monday January 28, 2019 @09:15AM (#19017531)
Does it still take 10 seconds to load the plotting library?
Re:Julia v1.1 Release Notes by Certhas on Monday January 28, 2019 @10:20AM (#19018064)
On my laptop it takes 4seconds on a fresh instance, 0.8 seconds if I am reloading.

But it also gives all the tools for not having to restart the interpreter very often these days.

Re:Julia v1.1 Release Notes by azhenley on Sunday January 27, 2019 @11:44PM (#19015372)
All sorts of small changes throughout. Dozens of standard library changes. The new language features are listed as:

- An exception stack is maintained on each task.

- The experimental macro Base.@locals returns a dictionary of current local variable names and values.

- Binary ~ can now be dotted, as in x .~ y .

Re:Julia v1.1 Release Notes by agumonkey on Sunday January 27, 2019 @09:44PM (#19015072)