tavert

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."

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

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

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

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

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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

"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.

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

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.

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.

Academic research. Or prototyping where you want higher performance than Python.

For anything else that requires long-term maintainability and has a business or someone's job depending on it, Julia is a risky choice to make. Few, if any, large organizations have done so yet, and usually don't want to go first.

Well after 1.0, if Julia Computing (who employ almost all of the core developers) is on sustainable financial footing and any large organizations have made investments into adopting and supporting Julia, it might make some sense for non-academic use cases.

2008 or 2017-2018 would be more dramatic examples of recent Formula 1 aero taken to extremes - 2009 was the most aerodynamically restricted year in recent regulations.

The 787 is the only jet-powered passenger aircraft I'm aware of that doesn't use a bleed air system. Any pressurized-cabin turboprop aircraft uses bleed air, and so does the M1 Abrams tank. Bleed air is not just used for cabin pressurization, it's also used for anti-icing systems, cabin temperature control (the high-pressure air is the working fluid, see https://en.wikipedia.org/wiki/Air_cycle_machine), and nitrogen generation systems for fuel tank inerting.

(I worked on the environmental control system for the Gulfstream G650 many years ago)

do any of those require ABI compatibility at the C++ level? win32 API's are generally exposed as C

were you missing compiler runtime libraries? like any code compiled with gcc anywhere that links the runtimes as shared libraries, they'll need to be present for executables to run. depending which variant of mingw-w64 you used, there are more runtime library dependencies than there used to be, like winpthreads for c++11 thread support.

if a comment on a blog post counts as official

There's a link in the article here, but sadly it sounds like they've abandoned Clang/C2. I guess they got normal MSVC up to speed on the C++1y/z they wanted to support, and Clang/LLVM was always better than both at complex numbers, inline assembly, and other C features.

Fair enough, but I actually need gmp more for runtime math, plus fortran deps like lapack and more obscure things. Maybe flang will be production-worthy some day - do you know if they're still outputting a textual representation of IR into string buffers?

if you need to use Structured Exception Handling. Well, with GCC, you can't

You can on 64 bit.

Excellent work. I like to ignore visual studio completely and pretend it doesn't exist, but that's just me :) I've used cygwin's cross-compiler x86_64-w64-mingw32-clang package once in a while, though I find more projects' build systems choke on it and do the wrong thing (libgmp as a notable example) than with x86_64-w64-mingw32-gcc.