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.
Giving up on Julia
31–40 of 242 posts
Re: Giving up on Julia
#32Seems 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?
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
#33Earlier 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.
Re: Giving up on Julia
#34Seems 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
#35If you want to replace Matlab you should use Octave, julia is for making your next climate model, not for "hello world" ricing
Re: Giving up on Julia
#36Earlier 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.
Re: Giving up on Julia
#37Earlier 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?
$ 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
194Re: Giving up on Julia
#38You 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…
Re: Giving up on Julia
#39You 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
#40If 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.