[deleted]
Giving up on Julia
71–80 of 242 posts
Re: Giving up on Julia
#72I know R and have used Octave. I started learning Julia this morning after a physicist recommended it to me after he switched from python. I used Jupyter/Julia to simulate a neuron as a practice exercise. This is my experience as a beginner:
1. The static typing makes a big and positive difference. Its nice having a statically typed repl.
2. The documentation is good.
3. Using unicode symbols and \mu style tab completion is nice, especially in Jupyter where you can use the same symbols in latex style equations.
4. The base install is a bit bare. It would be nice if batteries were included - distributions and dataframes in particular.
5. R uses 1 based indexing and it was no shock to see this in Julia.
6. I had no problems with the mix of lisp and C++ in the source code. The lisp implementation is beautiful and worth a read.
Generally, I was shocked to see a blog post like this given that my first day with Julia was so positive.
Re: Giving up on Julia
#73Earlier quoted context omitted.
Nim compiles to c, hence you can just call c functions. All you need is a signature, which can even be generated automatically from a c header. You can manually allocate memory if you want, and you can also pass pointers, either to manually allocated or gc memory. The gc will not run when c is working, since it is triggered by allocation
So if I call from Nim to C (passing a gc'd Nim-owned pointer), then that C routine calls back into Nim (via a function pointer, or some other way through the FFI), the nested Nim routine may trigger gc and wipe out the pointer my C code is working with?
You can instruct the Nim GC to not do that using GC_ref (http://nim-lang.org/docs/system.html#GC_ref,string).
Re: Giving up on Julia
#74Earlier quoted context omitted.
So if I call from Nim to C (passing a gc'd Nim-owned pointer), then that C routine calls back into Nim (via a function pointer, or some other way through the FFI), the nested Nim routine may trigger gc and wipe out the pointer my C code is working with?
You can instruct the Nim GC to not do that using GC_ref ( http://nim-lang.org/docs/system.html#GC_ref,string ).
That's what I figured. So not "trivial".
Re: Giving up on Julia
#75Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…
The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than about my programming world and are ready to make my life miserable stating the point.
Now, I don't know if people from that different world (Fortran, Matlab, some other languages used in academia maybe) would feel the same way about 0 based indexing but it certainly sends the message to programmers outside those domains.
Re: Giving up on Julia
#76Seems 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).
Uh, I think you're forgetting PHP. Not to mention Clojure is at least as popular as Go. Dynamic typing isn't going anywhere, desire for 'gradual typing' is a very niche but vocal desire in the dynamic language communities. It may lose some mindshare but there are a lot of options to lose that to these days since even the holdouts of 'annoying' static typing with terrible type systems like C++ or Java are making it more and more feasible to ignore/not specify the types in your code.
Re: Giving up on Julia
#77Complaining about microbenchmark performance, then perf benchmarking in a completely unscientific way, is pretty bad
(These are non-quiesced machines, etc)
The error bars show it's probably slower, but i'm pretty sure he's not going to get valid measurements to 0.002s by running it once with time without doing things like disabling CPU throttling, etc :)
Of course, looking at julia's microbenchmark for C, they had to do a bunch of things to get the compilers to stop optimizing away their benchmarks, so that should tell you something right there :)
The example they give of sprintf calls is completely misleading, since sprintf_chk is going to be several hundred instructions itself.
Follow https://github.com/lattera/glibc/blob/master/debug/sprintf_c... all the way down the rabbit hole :)
Re: Giving up on Julia
#78Re: Giving up on Julia
#79Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…
Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…
If distances used 1 based indexing:
metric distance conversion chart:
cm m km
1 1.00 1.00000
2 1.01 1.00001
3 1.02 1.00002
...
101 2.00 1.00100
...
100000 1000.99 1.99999
One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.
Re: Giving up on Julia
#80Earlier quoted context omitted.
Not just FORTRAN, but R and MATLAB also use one-based indexing. It's also, at least historically, the convention for matrix notation. IMO do whatever attracts more users, as that is what Julia needs most. Without a large community moving from MATLAB, R, and other languages, Julia will never take off.
Erlang also. In most functional languages using list indices are an anti-pattern. Pattern matching and generalized iteration is a much more elegant way to handle most things you would use an index for.
Well, sort of. Erlang has the array module, which does actually index at 0, intentionally to feel like an array from another language.
The primitive collection types index at 1, but, as you said, are almost never indexed that way. I'm not sure the motivation as to why, but the fact it feels clunky to use them that way is a benefit, as it raises resistance when you're using them wrong (as indexing them almost always is).