Hacker News Reader

Comment by sharikous | Hacker News Reader

macOS on ARM is still tier 2 and not tier 1?

Not related to this but I think Julia is too ambitious too succeed, at least in a normal timeframe. Languages like Rust and even Python managed to improve a lot more compared to their goals than Julia compared to the goal "a modern language, a modern top edge research level scientific library rewritten from scratch".

I enjoy the community that is backing it, really, but there is still no solid core. A lot of research level cool functions and algorithms, yes. But you still suffer from lagginess, inexact calculations and language idiosyncrasies. In short too much dispersion and divergence in this project. It's almost like this language was designed by academics...

View on HN

Rust is keeping macOS Arm as Tier 2 as well, mostly not because of lack of interest but because CI platforms can’t support all the demand for Arm builds. MacStadium, Azure, AWS and others keep adding extra capacity but the build queues are still too long.

So you either promote Arm Mac as tier 1, but now every PR takes extra hours to get merged, or you keep it at tier 2 for now and only build on Arm, say, once a day. Rust developers choose the later, because with their commit traffic they can’t afford such delays.

As the build machines capacity increases arm macOS will be promoted to Tier 1. Don’t read too much into tiers. Tier 2 is still pretty well supported from a language user perspective. Julia situation is pretty much the same.

We actually have a stack of M1 mac minis on top of a refrigerator to run CI. It's working pretty well for how janky it is.

You might be right that Julia's sky high ambitions make it seem like a failure no matter what it does. I mean, it could have strived for just being a pleasant dynamic language with a fast amortized running time, and then it would have succeeded in 2018.

But is it not better to both achieve you mediocre goals and also have extremely ambitious goals that may still be achieved, than merely having mediocre goals?

I don't really agree that Julia right now doesn't have anything to show for its huge amibitions. In my opinion it's already the best language for science by quite a large margin. I understand it still lacks some tooling, reliability and deployment options to be attractive for many industrial clients (though Julia is already making inroads in industry - I have an old friend from college who uses Julia in production). It's also understandable that some people used it and found the latency unacceptable. The thing is - there is no reason to believe that tooling, reliability and deployment options won't come around. The stuff is being built. It's just happening "too" slowly right now.

MacOS on ARM is technically tier 2, but we expect to promote it to tier 1 within a month or so. Basically we just want to make sure that 1.8 is as stable on M1 as we think it is. Until you have thousands of users testing everything, it's hard to declare confidently that everything works perfectly.

You may have a particular measure of success in mind, but it seems to me that Julia has already succeeded: it is a new language for scientific computing that met its goals of providing high level abstractions and an expressive syntax while not compromising on performance. Its public release was in 2012 and it’s already one of only four languages used in high-performance scientific computing. Of course, in many areas its ecosystem is immature; but in others, such as differential equation solving, it’s a leader.

What the heck?

Before making a claim like this you better define what you mean by "succeed" and what you mean by "normal timeframe".

Julia has been around since 2010-ish. The equivalent timeframe for python was late-90s.

The federal reserve bank uses (used?) Julia to model economics... Jokes about whether that is a succeed or fail for society at large, aside, it's hard to argue that adoption by at least one very significant player doesn't constitute success for a PL.

I don't think such a defensive response is necessary. Julia's claims have been rather lofty since the beginning and the degree to which they have been achieved is different to everyone.

Without defining more precisely what succeeding and the timeframe means it is difficult to know what OP was after but the fed example stands well on its own.

This. I was hoping Julia would be a quicker and more pleasant R. Instead it's turning into a super ambitious language that wants to be as fast as C++ but that makes it slightly less pleasant and useful than R. And if I need C++ speed I can just write C++...

> And if I need C++ speed I can just write C++...

Maybe I'm being pedantic here, but surely you can't "just write C++". If you could, why would you ever use R, which is way slower, less backwards compatible and can't be shipped as a binary?

I'm guessing you use R because it's easier to use than C++, interactive, and quicker to get stuff done in. That sounds to me like a list of criteria where Julia should aspire to beating R - if we can.

With RCpp writing a function in C++ that you can then use from R is easy. So you do as much as you can in R, then if you reach a bottleneck, use a lil CPP, then R. It's still nice.

Same with python. But then you have the following problem: How do you use tools that were designed to exploit the introspection of these languages when you have C++ submodules?

This is called "the two language problem", and it is not just about ergonomics (e.g. you do not seem to have issues with the ergonomics of this approach). Rather the issue is that now I can not have a library that introspects my R code and performs automatic differentiation or some other advanced compile pass over my code, because not all of the code is written in R. This is also why most of the advanced SciPy functionality can not be used with Tensorflow, or use Jax's autodiff feature with Pandas dataframes or Pillow images.

In many cases this might not matter, but when creating sophisticated large computational packages, the level of interoperability that Julia provides is both incredibly empowering and as of yet unsurpassed.

> when creating sophisticated large computational packages, the level of interoperability that Julia provides is both incredibly empowering and as of yet unsurpassed

It's difficult for outsiders to know what to think when confronted with so divergent opinions:

"I would hit bugs of this severity often enough to make me question the correctness of any moderately complex computation in Julia.

This was particularly true when trying a novel combination of packages or functions — composing together functionality from multiple sources was a significant source of bugs."

That is a very reasonable complaint, and I think the core devs (of the language and of the flagship ecosystem projects) take it fairly seriously. For me personally, it has been incredibly empowering to be able to mix and match very diverse packages, but maybe I am just used to defensive coding: I start with tests, including randomized tests and contract tests.

On the other hand, though, I have not encountered more bugs in the Julia ecosystem than in the Sympy or Theano (deprecated now) or Tensorflow or Pytorch systems when I was using them to build "sophisticated large computational packages".

Maybe the happy users are just not as vocal, but that is a silly excuse.

Both opinions go hand in hand, in fact.

Julia allows packages to interoperate in a way most other mainstream languages simply don't, due to the combination of its multiple dispatch and the type hierarchy. The fact that the language allows this interoperability to such level is very useful and empowering. But making proper use of this interoperablity means writing careful generic code that doesn't make narrow assumptions based only on currently known uses of it.

Different parts of the ecosystem do this with different degress of care and success, with newer ones being better at it as lessons are learned and implemented. Yuri happened to work on parts of the ecosystem that were not-so-new, and made combinations that hadn't been commonly attempted. That doesn't mean that these weren't issues that need fixing and preventing in the future, for sure. But hitting bugs of this severity often isn't the typical experience for the average user - if it was, Julia would hardly have as many users, much less ones like NASA.

Reply on news.ycombinator.com