Live data from Hacker News

Giving up on Julia

zverovich.net

31–40 of 242 posts

Re: Giving up on Julia

#31
post #27

When the author compares the number of CPU instructions that sprintf compiles to in both C and Julia, he fails to take into account dynamic linking in C: jmp __sprintf_chk I would guess that another few hundred instructions run as a result of this jmp. Thus, the difference in the number of instructions that C's sprintf and Julia's @sprintf compile to are not as drastic as the author makes it seem.

Also note that the author asks for the native code for arguments of type `(AbstractString, Float64)`. The first is an abstract type — which means that this code will never get called in the first place. Julia will resolve the type of the string, and then dispatch to the concrete implementation. Which, for an ASCIIString, is 3x shorter.

This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?

Re: Giving up on Julia

#32
post #14

Seems like for the last five years every language has been gaining popularity. Now they're all losing popularity. Except rust, perhaps, and elm. What gives?

Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy).

I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).

Re: Giving up on Julia

#33
post #22

Earlier quoted context omitted.

I liked how the Template Numerical Toolkit implemented one-based indexing: // Construct matrix. Elements are not initialized. // To initialize all elements to zero use // Matrix a(2, 2, 0.0). Matrix a(2, 2); // Assign elements to first row using // Fortran-style one-based indexing. a(1,1) = 0.5; a(1,2) = 1.0; // Assign elements to second row using // C-style zero-based indexing. a[1][0] = 1.5; a[1][1] = 2.0; -- http:…

This syntax is available in julia as well, but I'm not sure it's a great idea to encourage mixing the two indexing behaviors, even if they have different syntax. As I hinted in the original reply, I have seen very few cases where the choice of index offset actually makes a difference. For example, loops over indices generally use `eachindex` which doesn't care about your choice of index base.

That's interesting - thanks. I don't think anyone is eager to mix indexing behaviors either.

Re: Giving up on Julia

#34
post #14

Seems like for the last five years every language has been gaining popularity. Now they're all losing popularity. Except rust, perhaps, and elm. What gives?

Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).

Why is strong/dynamic typing considered such a big deal?

Re: Giving up on Julia

#36
post #33

Earlier quoted context omitted.

This syntax is available in julia as well, but I'm not sure it's a great idea to encourage mixing the two indexing behaviors, even if they have different syntax. As I hinted in the original reply, I have seen very few cases where the choice of index offset actually makes a difference. For example, loops over indices generally use `eachindex` which doesn't care about your choice of index base.

That's interesting - thanks. I don't think anyone is eager to mix indexing behaviors either.

I just realized that when I said, "this syntax is available", people might have understood it to mean, "you can use this syntax to index arrays" (which is not true for the array type defined in base). What I meant was, "you can define an array type with this indexing behavior without changing the language (since you can override the behavior of both () and [] on a particular type)".

Re: Giving up on Julia

#37
post #31
post #27

Earlier quoted context omitted.

Also note that the author asks for the native code for arguments of type `(AbstractString, Float64)`. The first is an abstract type — which means that this code will never get called in the first place. Julia will resolve the type of the string, and then dispatch to the concrete implementation. Which, for an ASCIIString, is 3x shorter.

This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?

It's the same on 0.4, and Strings are getting a big overhaul on 0.5. Here are the results for 0.4:

    $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (AbstractString, Float64))' | wc -l
    WARNING: Returned code may not match what actually runs.
         628

    $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (ASCIIString, Float64))' | wc -l
         194

    $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (UTF8String, Float64))' | wc -l
         194

Re: Giving up on Julia

#38
post #11

You know, you take a potshot at Go in there, but I observe that none of the negative bullet points apply to Go. My real point here not being "Go rocks", but that languages are more than just the collection of bullet-point features they claim on their home page. I think this is another one of those things that says obvious when I say it directly, but a lot of people are not letting it inform their actions. Also I love…

Go has a set of completely different issues but that's a topic for another post =).

Re: Giving up on Julia

#39
To me the biggest thing that Julia brings to the table is the amazing concurrency support.

You can not only easily create parallel tasks on your machine, but on any machine that you have ssh access to that also has Julia installed.

That is simply amazing. Until something else can do that, Julia is going no where but up in my mind.

Re: Giving up on Julia

#40
post #26
post #15

If you want to replace Matlab you should use Octave, julia is for making your next climate model, not for "hello world" ricing

Octave is much slower than MATLAB.

True, but if performance is your key concern, you shouldn't use either of them. Octave and MATLAB are great for prototyping matrix based numerical algorithms. And for this purpose I find Octave much more pleasant, since it is less nitpicky regarding its syntax. And once I have something that works and want to apply it to huge datasets, I usually rewrite my code in C++.
Post reply on HN