Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jakobnissen
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
30 ms
·
361.
▲
by
jakobnissen
6y ago
Probably yes - but 10 years is more likely than 5. Python really gained steam when it was 15+ years old. Julia has two years since its 1.0 release. But it will eventually take over Python, unless something third comes and takes the cake bef
362.
▲
by
jakobnissen
6y ago
You can "using PKG" and then type "pkg"add MyPackage""
363.
▲
by
jakobnissen
6y ago
I would argue that if those really are your major gripes about Julia, you either have very bad priorities, or don't know enough about Julia to contribute to this conversation.
364.
▲
by
jakobnissen
6y ago
Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading. However, for many, many small
365.
▲
by
jakobnissen
6y ago
It does happen, though. C has mostly replaced FORTRAN for scientific applications. Not entirely, FORTRAN is (infamously) still used, but I don't know anyone who has started a new project with FORTRAN. Just 6 years ago, I was taught Per
366.
▲
by
jakobnissen
6y ago
You can, but Pluto is (I would argue) a better notebook than Jupyter. Regardless, the latency experienced with Julia applies equally whether you use Pluto, Jupyter, or any other front-end.
367.
▲
by
jakobnissen
6y ago
What a great write-up. I used to work in metagenomics, where we would assemble environments with hundreds of bacterial genomes. We developed a deep-learning approach to binning the assembly, Vamb, which worked really well. In hindsight, our
368.
▲
by
jakobnissen
6y ago
Indeed you are right, that would be much easier. DNA assembly is an insanely hard computational problem. The issue there is that it's difficult to actually build a sequencing machine that can sequence more than a few hundred base pairs
369.
▲
by
jakobnissen
6y ago
Only somewhat, because the errors are systematic, and not random. Using the R9 pore flowcells, I've basically given up on getting correct consensus sequences even for influenza genomes (without manual correction, which is too labour in
370.
▲
by
jakobnissen
6y ago
I have a colleague who is working on a portable field kit with a minION + laptop + car battery with the intent of being able to sequence and identify pathogens directly in the field, even with no electric grid. Turns out the hardest part is
371.
▲
by
jakobnissen
6y ago
Of course it's intrinsic to Julia. What do you mean? Julia is a JIT-compiled language, and so gets the curse of JIT-compilation: Compilation latency. That's unavoidable* * Okay, technically, someone could write an interpreter for
372.
▲
by
jakobnissen
6y ago
The main selling point is the speed. Julia is high performance - in the same class as C, C++, Rust etc (perhaps 1.5x slower on average, but still pretty fast). This allows you to write all your code in Julia rather than just the surface l
373.
▲
by
jakobnissen
6y ago
I can't tell you why it was originally chosen, but there is a PR underway to have tasklocal RNG in Julia. That necessitates a smaller RNG, and we'll probably land on xoshiro256 Ref: https://github.com/JuliaLang&#
374.
▲
by
jakobnissen
6y ago
Unfortunately, you are right - but mostly when discussing programming languages on the Internet. In forums like this, we (Julians) often want to make a case for Julia. Since most soon-to-be Julians come from Python, R or Matlab, it'
375.
▲
by
jakobnissen
6y ago
I think you're hitting on the main pain point of Julia. My bet is that we'll see strong typing dominate in the coming decade, with assistance from linters/static analysis becoming default. Unfortunately, this is not too easy
376.
▲
by
jakobnissen
6y ago
... but Cython is not Python, is it? The argument that "Python can do it, you just have to use something other than Python) is very weird to me. I began looking into Julia because I was forced into Cython during a project and I loathed
377.
▲
by
jakobnissen
6y ago
In my experience, the big "problem" with Julia's performance is that while it's actually a compiled language, it's also dynamic. In most compiled languages, if you write code the compiler can't completely infer
378.
▲
by
jakobnissen
6y ago
The problem with Numba is that it only really works in small, limited usecases. Good for e.g. Numpy arrays, but can it provide these massive speedups with custom classes? Arrays of strings? Sets? Probably not, since both Julia and Numba rel
379.
▲
by
jakobnissen
6y ago
What would true progress look like to you? Specifically regarding Julia's main use case of interactive yet performant programming?
380.
▲
by
jakobnissen
6y ago
I think ODEs and numerical computing gets mentioned because it was the first area where Julia packages outshined all alternatives. It originated among physicists and mathematicians, so it has a "head start" in these areas. Julia i
381.
▲
by
jakobnissen
6y ago
The idea is to keep the amount of global state as low as possible. Pluto.jl creates a dependency graph between cells: If cell A defines foo, and cell B uses foo, then cell B depends on cell A. Whenever cell A is updated, cell B will automat
382.
▲
by
jakobnissen
6y ago
I've switched from Jupyter to Pluto recently. Here's a few experiences with it. * The fact that I can actually use the source files later because they're just Julia files is incredibly useful. I often copy-paste from them int
383.
▲
by
jakobnissen
6y ago
Not quite. Pluto is also built on JavaScript (of course, since it's a browser notebook). The main advantages of Pluto is that * The sources files are executable Julia files with minimal metadata, so it plays nice with Git. Also, the co
384.
▲
by
jakobnissen
6y ago
I very well might! As I said, I really do need an interactive language for some (most?) tasks, but it would be nice to complement it with a static language. I've been drawn to Rust since it seems to be enjoyable and less full of arcane
385.
▲
by
jakobnissen
6y ago
I don't think this is entirely accurate. When you develop software, you don't repeatedly unload and load your dependencies (which is what causes Julia's startup time). You probably only develop one package, which you then rel
386.
▲
by
jakobnissen
6y ago
Bioinformatician here. It's certainly a drawback. There is no quesiton that Python etc. are more expressive and quick to write in than C are. Some bioinformaticians swear to static languages for reasons other than speed (e.g. static ty
387.
▲
by
jakobnissen
6y ago
I reviewed the first Julia benchmark. The second one is based on this not-very-thorough "experimental" lib I've never heard of from a person not very well-versed in Julia, so I don't think that's representative at a