Live data from Hacker News

JuliaCon 2019 Videos

youtube.com

11–20 of 26 posts

Re: JuliaCon 2019 Videos

#11
post #9
post #7

Earlier quoted context omitted.

That's mostly because Julia doesn't have yet an interpreter (outside of the debugger), only a JIT compiler. Thankfully the "time to first plot" is the new priority for the compiler team since the multithreading is already working.

I hope it goes well, this has been a common complaint for half a decade now.

This is a rather unfair statement given that the first stable version of Julia was released only a year ago.

Re: JuliaCon 2019 Videos

#12
post #7
post #6

Earlier quoted context omitted.

I came for the speed, and I left because of the speed. It's impressive how the interpreter is slow to start..

That's mostly because Julia doesn't have yet an interpreter (outside of the debugger), only a JIT compiler. Thankfully the "time to first plot" is the new priority for the compiler team since the multithreading is already working.

That's nice, thanks for the information !

Re: JuliaCon 2019 Videos

#13
post #7

Earlier quoted context omitted.

That's mostly because Julia doesn't have yet an interpreter (outside of the debugger), only a JIT compiler. Thankfully the "time to first plot" is the new priority for the compiler team since the multithreading is already working.

Most Common Lisp compilers survive well with incremental compilation. Build-times and development are very fast, with no interpreter in sight.

There are many approaches they could go, they could improve the live session approach (for example saving between sessions), which could also help people who repeatedly run scripts on the bash (for example with a --save-session flag). It wouldn't solve the very first plot but it would help all "first plot within the current run", which is probably most of the complaints.

The one that people would probably appreciate the most would be an AoT alternative (allowing you to create a runnable/linkable binary with a function/module without embedding the compiler, at the cost of the dynamic features such as eval).

Re: JuliaCon 2019 Videos

#14
post #6
post #5

Julia: come for the syntax, stay for the speed https://www.nature.com/articles/d41586-019-02310-3

I came for the speed, and I left because of the speed. It's impressive how the interpreter is slow to start..

To me it looks quite fast, specially when compared having to build native libraries to plug into Python.

Re: JuliaCon 2019 Videos

#15
post #9

Earlier quoted context omitted.

I hope it goes well, this has been a common complaint for half a decade now.

This is a rather unfair statement given that the first stable version of Julia was released only a year ago.

There has been a lot of other work over the last five years with a constant stream of new people talking about iteration and start up times with constant promises that it will be fixed soon.

Re: JuliaCon 2019 Videos

#16
post #7

Earlier quoted context omitted.

That's mostly because Julia doesn't have yet an interpreter (outside of the debugger), only a JIT compiler. Thankfully the "time to first plot" is the new priority for the compiler team since the multithreading is already working.

Most Common Lisp compilers survive well with incremental compilation. Build-times and development are very fast, with no interpreter in sight.

Yea, but common lisp is also missing nearly all the numerical libraries I need like sparse matrices. Yes, I'm sure someone has a wrapper somewhere, but Julia has native support for all of that and is really nice. It also has much better support for a lot of things like plotting.

Re: JuliaCon 2019 Videos

#17
It would be great if Julia were to take a page from the Rust playbook and have some focused initiatives around making the language more accessible to its potential audience. I've been impressed with how introspective and constructively self-critical the Rust stewardship has been. I don't get the same sense from Julia, but maybe I'm missing things.

The "time to first plot" issue bothers me far less than the weak documentation and low-friendliness error messages. I'm not sure where this documentation style comes from that the official Julia docs use, where the left side of the page is permanently taken up with a low information density TOC and the detailed discussion in any real content section is either terse or somewhat superficial, but that imbalance is very frustrating. Try for example to find where in the Multi-Dimensional Array section the eachrow() iterator is introduced. There doesn't seem to be an attempt to develop something equivalent to the Klabnik & Nichols Rust book.

There are some awesome packages in the Julia ecosystem, but the "slap something onto GitHub in one night" style of documentation definitely hurts.

Making error messages more approachable will also help driving toward Julia as the technical computing lingua franca for engineering students.

Re: JuliaCon 2019 Videos

#18

It would be great if Julia were to take a page from the Rust playbook and have some focused initiatives around making the language more accessible to its potential audience. I've been impressed with how introspective and constructively self-critical the Rust stewardship has been. I don't get the same sense from Julia, but maybe I'm missing things. The "time to first plot" issue bothers me far less than the weak docum…

The documentation style (permanent TOC on the right) seems to copy python's Sphinx style. And you are quite right about the lack of visible effort in making error messages more useful.

Re: JuliaCon 2019 Videos

#19
I have been willing to try Julia for a long time now.

Yesterday I finally put time aside to port some stuff I have been doing in Python to Julia.

1st: install Julia - used a snap on Ubuntu, fine

2nd: get jupyter to work with Julia: a bit complex, but achievable

3rd: install Julia support for vscode: Julia kernel keeps crashing in vscode

4th: Port a routine from Python to Julia: some nice language features, some scary: importing a package exposes all its functions to the all namespace - this seems quite awful! (EDIT: Thank you for pointing out that I should use `import` instead of `use`, in order not to put everything in the same namespace).

5th: Try to read a Parquet file - doesn't work because it was compressed with zstd (something all 3 libraries for parquet in Python support)

6th: realize that there is no package in Julia that even allows to write parquet files

Conclusion: maybe in a few years Julia will be my go-to language, but right now, it's too underdeveloped in order to be able to do real work with it.

Re: JuliaCon 2019 Videos

#20
post #19

I have been willing to try Julia for a long time now. Yesterday I finally put time aside to port some stuff I have been doing in Python to Julia. 1st: install Julia - used a snap on Ubuntu, fine 2nd: get jupyter to work with Julia: a bit complex, but achievable 3rd: install Julia support for vscode: Julia kernel keeps crashing in vscode 4th: Port a routine from Python to Julia: some nice language features, some scary…

Use import instead of using if you don't want things in your namespace.
Post reply on HN