Hacker News: tavert

New comment by tavert in "Is Julia Just a Bubble?"

tavert — Thu, 05 Dec 2019 19:29:09 +0000

Search HN who's hiring threads for companies looking for it. In December's thread I see one, and it's telling that their listing says "teach us all how to deliver more robust software."

New comment by tavert in "Composable multi-threaded parallelism in Julia"

tavert — Tue, 30 Jul 2019 19:09:17 +0000

Mix of C++ and Python. They're both kind of awful in their own way, but well-supported and stable.

New comment by tavert in "Composable multi-threaded parallelism in Julia"

tavert — Mon, 29 Jul 2019 00:00:09 +0000

You're really asking for a Dan Luu sequel here.

New comment by tavert in "Composable multi-threaded parallelism in Julia"

tavert — Fri, 26 Jul 2019 23:41:20 +0000

No one? Ever? https://onlinelibrary.wiley.com/doi/full/10.1002/cpe.3746

New comment by tavert in "Composable multi-threaded parallelism in Julia"

tavert — Wed, 24 Jul 2019 17:28:45 +0000

1. Carelessness, lack of professionalism, and instability from many of the core language and package developers

2. Over concentration of the main contributors within the same startup that has a questionable business model and long-term prospects

3. Language issues that limit the desirability of Julia for use in larger projects

New comment by tavert in "Composable multi-threaded parallelism in Julia"

tavert — Wed, 24 Jul 2019 01:04:45 +0000

Since I stopped using Julia I've kept an eye on the HN Who's Hiring threads for mentions of it. I see one consistent listing from Gambit Research, and occasionally one or two others that come and go. Anecdotal to only sample from HN and not larger listing sites like Indeed etc, but it reinforces my skepticism about industry adoption.

New comment by tavert in "Julia 1.0"

tavert — Mon, 20 Aug 2018 02:24:41 +0000

These incidents were with respect to 0.6-supporting versions of packages. Pinning is a good idea for reproducability but it's not the default, so updating packages or new installs are broken when careless things make it instantly into a release.

Talk to me when google, amazon, microsoft, facebook etc are publicly using and officially supporting julia on cloud platforms or even infrastructure libraries like protobuf.

The carelessness isn't responsible for or helping anything. A good diffeq and optimization suite have been built despite the prevalence of careless practices, not because of them.

It's not a question of money either, just patience and code review and recognition of how many things downstream are going to be affected by mistakes. You'll save more time in not having to put out as many fires than it will cost to slow down and not be in such a rush at all times.

New comment by tavert in "Julia 1.0"

tavert — Sat, 11 Aug 2018 01:09:17 +0000

Just in the last few months BinDeps was broken by a "deprecation fix" that was completely wrong and using a name that didn't exist, and it got merged and released by the patch author before anyone else could look at it, breaking many downstream packages.

Refactorings and major changes in ZMQ.jl and the web stack similarly get merged and released immediately with zero review, still. This is a major problem.

Features in the base language have been deleted during 0.7-DEV because a single core developer didn't like them, despite multiple other core developers voicing disagreement that the features were useful and removing them was not urgent or necessary.

It's not a development culture I would rely on when products and money and jobs are at stake. Even the startup you were working with abandoned julia, correct?

New comment by tavert in "Julia 1.0"

tavert — Fri, 10 Aug 2018 03:12:41 +0000

Large Apache projects, notable widely-used c++ projects like boost, llvm, zmq, cmake, the c++ language standards committee itself, all take their time and rarely if ever release changes/bugfixes immediately. Things go through review, testing, release candidates, and people other than original authors of code provide input before normal users get their hands on anything. The core pydata projects take their time and are cautious about breaking things.

New comment by tavert in "Julia 1.0"

tavert — Thu, 09 Aug 2018 20:41:33 +0000

That will only prevent installation of master of the package or the immediate next few versions on 0.7. The old package versions without a julia upper bound remain available so users on 0.7 or 1.0 will just be held back to old versions of JuliaDB until a new release without an upper bound gets made.

New comment by tavert in "Julia 1.0"

tavert — Thu, 09 Aug 2018 18:41:21 +0000

My mistake, docs there are fine. A few other BinaryBuilder-using packages have neglected to mention this issue, last I checked. And BTW BinaryBuilder is violating even MIT licenses if you don't package and include the license file along with the shared-library download.

New comment by tavert in "Julia 1.0"

tavert — Thu, 09 Aug 2018 18:09:42 +0000

Things are decent on average, but there's a persistent carelessness and rush to do things without paying attention to the consequences. More in packages than base nowadays, but there's a lot of merging and releasing things immediately without waiting for code review that could have caught mistakes before breaking users.

New comment by tavert in "Julia 1.0"

tavert — Thu, 09 Aug 2018 17:27:40 +0000

The reason I ran away from Julia and don't plan on ever using it again, and don't recommend anyone use it outside of academia, is that so much of the community is made up of grad students. So you get a lot of research code and people who have never been professional programmers maintaining most of the ecosystem. Julia Computing is largely made up of people they've hired from the community straight out of grad school.

New comment by tavert in "Julia 1.0"

tavert — Thu, 09 Aug 2018 16:45:18 +0000

That MIT license only applies to the Julia wrapper code. The package downloads and dynamically links into an FFTW shared library, which means any code that uses it needs to be GPL if distributed as a whole.

New comment by tavert in "Julia v1.0 has been released"

tavert — Wed, 08 Aug 2018 22:38:59 +0000

The annual juliacon is happening right now. So yes the last few weeks of this release process have been very rushed. Only around 160 packages have made releases that pass their tests using Julia 1.0.0 at the moment, out of 1900ish total registered packages.

New comment by tavert in "Why Numba and Cython are not substitutes for Julia"

tavert — Mon, 06 Aug 2018 21:30:54 +0000

fastparquet https://github.com/dask/fastparquet

New comment by tavert in "Writing Iterators in Julia 0.7"

tavert — Fri, 06 Jul 2018 22:07:59 +0000

"proper package" in that it has a toml file and a uuid, but it can't be controlled by the package manager in terms of updating, handling installation, or pinning versions. The stdlib "packages" are an awkward in-between state that isn't usable the way a full package would be, the only thing it has forced people to do relative to being included in Base is now you need to do `using LinearAlgebra` to load it in downstream code. That might get fixed eventually so you can express that you depend on the LinearAlgebra 1.0 API to isolate yourself from stdlib breakage, but there's no way to do that today short of doing the work yourself to create a full versioned package with the same content.

New comment by tavert in "Writing Iterators in Julia 0.7"

tavert — Fri, 06 Jul 2018 20:27:18 +0000

stdlib modules aren't versioned separately from the language. That may happen in some 1.x release but it's not usable today.

New comment by tavert in "When an implementation monoculture might be the right thing"

tavert — Tue, 05 Jun 2018 00:01:54 +0000

And that choice of compiler has caused endless headaches for the NumPy and SciPy communities, see e.g. https://github.com/numpy/numpy/wiki/Numerical-software-on-Wi... and https://mingwpy.github.io/motivation.html

VLC's windows binaries are also built with mingw-w64 gcc last I checked, that is likely used even more widely than numpy.

New comment by tavert in "My favorite things that are coming with Julia 1.0"

tavert — Sat, 02 Jun 2018 17:21:20 +0000

All of the MPI communication was happening in C code (the built-in distributed code in Julia exists, and sometimes works, but that's the nicest thing you can say about it - it has not been leaned on heavily at all, and is often awkward to use). Lots of low level bit twiddling was involved in Celeste. Without Keno that application would have been lucky to top 100-200 teraflops.