BadInformatics

I think it's more complicated than that. The projects that are getting the funding are usually the hard, technical ones, but that funding also supports better docs + more time for API design. This doesn't apply to bleeding edge stuff, but look back through the core SciML libraries and there's no shortage of effort directed towards "dull" stuff like docs + improving compile times. Likewise for the core language: a lot of recent work is bread and butter engineering like (again) improving compile times, filing rough edges off of APIs and (gradually) tackling the deployment story.

Now, one area where this dull problem work isn't as noticeable is on the "core" deep learning libraries (Flux and Zygote). AFAICT those two haven't received any significant funding for a couple of years, and there is at most 1 full time, active contributor for both of them. Compare with JAX or even higher-level wrapper libraries like Flax, Haiku or PyTorch Lightning, which have 5-10+ full time core devs. Given this, is it surprising that progress on anything (including docs + interface design) is slow?

You're in luck, because (assuming the scans are in a compatible format), this is exactly what 3D Slicer was designed for.

Who is doing more than a couple rounds of interviews outside of (pardon the scare quotes) "tech companies"? Has anyone run into, say, a bank pulling 4+ rounds of interviews, or is this limited to FAANG(M), SV companies and startups that seek to emulate them?

Bronson and Pigott were a nice read, but it's unclear where Föll is getting most of his conjecture from because they certainly don't talk about it. Frankly, the whole piece smacks of the same Diamond-esque "they made fireworks, we made guns" trope that has been thoroughly torn apart since. Now to his credit, he does claim ignorance at the top of the page, but that seems to be quickly forgotten given how much hyperbole is spewed later on.

[1] is a better lay overview of medieval-era steel-making. And for a great breakdown of forces behind European success in the modern era, see Brett Devereaux's series on EU4 [2]

[1] https://www.youtube.com/watch?v=5djVkOgu8vs

[2] https://acoup.blog/2021/05/28/collections-teaching-paradox-e...

Trying to interpret individual radicals of a character as standalone components using their original meaning is enticing, but more often than not incorrect. For example, the character for maternal aunt uses the same radical. Phonetic-semantic compound characters are very, very, common. The standalone pronunciation of 夷 doesn't appear to have turkic/steppe origins either [1].

Moreover, we know Mongolian writing (because of the geopolitics of the time and its status as a younger written tradition) borrowed quite liberally from its southern neighbours. Including, but not limited to, China [2]. So while Wagner's point about proliferation of ironmaking techniques from outside the (nominal) Chinese state at the time makes sense, the whole phonetic angle doesn't.

As for the points about centralization and family name elitism, the first lasted less than 200 years, by which time many formerly aristocratic family names had become _so_ diluted so as to be almost meaningless. One of the main conceits of a major character in RoTK is that he's an average Joe who only gets a modicum of respect for having the same surname as the dynastic family. It also completely ignores the existence of profession-based surnames like 匠 ("artisan", notably 1/2 of 铁匠/blacksmith).

[1] https://en.wikipedia.org/wiki/Dongyi#Yi [2] https://en.wikipedia.org/wiki/Mongolian_writing_systems

It does not, and any discussion of whether certain public health measures should've been implemented should take that into consideration. Toronto-area hospitals were literally sending ICU patients to smaller cities because their own wards were overflowing. Moreover, attrition rates among clinicians (nurses especially) has been atrocious over the past year or so. People are only willing to put up with so much shit for so long, and most provincial systems have zero slack at the moment.

That said, measures like GP described were/are in play in many cities. Seniors time was a fixture in the first few months of the pandemic, especially in smaller areas that did not experience a large caseload.

That's another point too: I think a lot of HN commenters are unaware of just how fragmented and regional the Canadian healthcare system is. No two provinces implemented the same restrictions or policies at the same time, and only a couple put in strict stay-at-home style lockdowns. Note how the article mentions large increases in both Ontario (lax policies, then sudden strict lockdowns) with Alberta (very few restrictions). Even in Ontario, walking outside the biggest few cities would result in an immediate drop of most of the strict measures present in, say, the GTA. I know it's hard to capture this nuance discussing with strangers on some random online forum, but it's essential if we are to properly discuss cause and effect.

Canadaland did a great series on the pathology of Vancouver real estate recently [1]. TL;DL there is no consensus on the root cause, but the usual suspects of bureaucracy, NIMBYism and foreign investment all make an appearance.

[1] https://www.canadaland.com/podcast/real-estate-3-terminal-ci...

Vancouver may have "no industry" relative to SV, but it is a veritable black hole for tech on the west coast of Canada. The same rat race of high-skilled, well-paying jobs only being available in HCoL cities is just as much of an issue north of the border. The even smaller gap between compensation and CoL in Vancouver, Toronto, etc. just serves to make things more miserable.

Saying all the underdog competitors should team up is a nice idea, but as anyone who has seen how the standards sausage is made (or, indeed, has tried something similar) will tell you, it is often more difficult than everyone going their own way. It might be unintuitive, but coordination is hard even when you're not jockeying for position with your collaborators. This is why I mentioned the silver bullet part: a surface level analysis leads one to believe collaboration is the optimal path, but that starts to show cracks real quickly once one starts actually digging into the details.

To end things on a somewhat brighter note, there will be no sea change unless people put in the time and effort to get stuff like Vulkan compute working. As-is, most ML people (somewhat rightfully) expect accelerator support to be handed to them on a silver platter. That's fine, but I'd argue by doing so we lose the right to complain about big libraries and hardware vendors doing what's best for their own interests instead of for the ecosystem as a whole.

Do you think AMD should solve every problem CUDA solves for their customers too?

They had no choice. Getting a bunch of HPC people to completely rewrite their code for a different API is a tough pill to swallow when you're trying to win supercomputer contracts. Would they have preferred to spend development resources elsewhere? Probably, they've even got their own standards and SDKs from days past.

everyone else using GPU's is running fast as they can towards Vulkan

I'm not qualified to comment on the entirety of it, but I can say that basically no claim in this statement is true:

1. Not everyone doing compute is using GPUs. Companies are increasingly designing and releasing their own custom hardware (TPUs, IPUs, NPUs, etc.)

2. Not everyone using GPUs is cares about Vulkan. Certainly many folks doing graphics stuff don't, and DirectX is as healthy as ever. There have been bits and pieces of work around Vulkan compute for mobile ML model deployment, but it's a tiny niche and doesn't involve discrete GPUs at all.

Is it just too soon too early in the adoption curve

Yes. Vulkan compute is still missing many of the niceties of more developed compute APIs. Tooling is one big part of that: writing shaders using GLSL is a pretty big step down from using whatever language you were using before (C++, Fortran, Python, etc).

do ya'll think there are more serious obstructions long term to building a more Vulkan centric AI/ML toolkit

You could probably write a whole page about this, but TL;DR yes. It would take at least as much effort as AMD and Intel put into their respective compute stacks to get Vulkan ML anywhere near ready for prime time. You need to have inference, training, cross-device communication, headless GPU usage, reasonably wide compatibility, not garbage performance, framework integration, passable tooling and more.

Sure these are all feasible, but who has the incentive to put in the time to do it? The big 3 vendors have their supercomputer contracts already, so all they need to do is keep maintaining their 1st-party compute stacks. Interop also requires going through Khronos, which is its own political quagmire when it comes to standardization. Nvidia already managed to obstruct OpenCL into obscurity, why would they do anything different here? Downstream libraries have also poured untold millions into existing compute stacks, OR rely on the vendors to implement that functionality for them. This is before we even get into custom hardware like TPUs that don't behave like a GPU at all.

So in short, there is little inevitable about this at all. The reason people may have been frustrated by your comment is because Vulkan compute comes up all the time as some silver bullet that will save us from the walled gardens of CUDA and co (especially for ML, arguably the most complex and expensive subdomain of them all). We'd all like it to come true, but until all of the aforementioned points are addressed this will remain primarily in pipe dream territory.

I've mentioned this on other forums, but it would help to have some kind of easily visible, public tracker for this progress. Even a text file, set of GitHub issues or project board would do.

Why? Because as-is, most people still believe support for gfx1000 cards is non-existent in any ROCm library. Of course that's not the case as you've pointed out here, but without any good sign of forward progress, your average user is going to assume close to zero support. Vague comments like https://github.com/RadeonOpenCompute/ROCm/issues/1542 are better than nothing, but don't inspire that much confidence without some more detail.

Google may have coined the term (not sure about this), but it's far from their own thing [1]. PWA should've been a blanket term for a set of standards and guidelines for developing web apps. Those include progressive enhancement, which I don't think most people would expect.

Unfortunately, the term has been co-opted to mean "website I can install/pin as an app". Again, Google is probably to blame for this, but AFAICT it was never meant to be the meaning of the term. What it does do is create misunderstandings, like a sibling thread claiming that (desktop) Firefox doesn't support PWAs because you can't install anything.

[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web...

Transformers.jl and TextAnalysis.jl already provide quite a bit of functionality for NLP, though to my knowledge neither makes use of RNNs. You may be interested in commenting on https://github.com/FluxML/Flux.jl/issues/1678.

The community staying very active has been the biggest factor here IMO. The predecessor to the current Definitive Edition, the rather disastrous (engine-wise, not content-wise) HD Edition, was created in part by co-opting community made mod content and hiring on some of the creators. This has continued for both the Definitive Edition and AOE 4.

Likewise, most of the biggest pros and casters started their careers 5-10+ years ago working on community tournaments and other grassroots events. Even though there's a lot more money now with investment from Microsoft, Red Bull and others, that grassroots core has stuck around and feels (at least to me) more fresh than the very corporate machinery around Blizzard RTSes. It's funny to think that the most anticipated LAN tournament is literally held in someone's apartment (https://www.ageofempires.com/news/nac3-tournament/)!

From TFA:

We’ll also be hosting a Q&A session 02.08., 10PM UTC (03.08., 12AM CEST | 8AM AEST). Jeremy will be there, too. Meeting link will follow soon.

My understanding is that he's at least been aware of this since early development (just over a year), so make of that what you will.

Having tried fastai for a "serious" research project and helped (just a bit) towards FastAI.jl development, here's my take:

motivation behind this is unclear.

Julia currently has two main DL libraries. Flux, which is somewhere between PyTorch and (tf.)Keras abstraction wise, and Knet, which is a little lower level (think just below PyTorch/around where MXNet Gluon sits). Frameworks like fastai, PyTorch Lightning and Keras demonstrate that there's a desire for higher-level, more batteries included libraries. FastAI.jl is looking to fill that gap in Julia.

Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet.

This is correct. That said, FastAI.jl is not and does not plan to be a copy of the Python API (hence "inspired by"). One consequence of this is that integration with other libraries is much easier, e.g. https://github.com/chengchingwen/Transformers.jl for NLP tasks.

What is the timeline for FastAI.jl to achieve parity?

When should I choose FastAI.jl vs fastai?

This depends on your use cases and how comfortable you are with a) Julia b) having to roll some of your own code. For the first, I'd recommend poking around with the language before as well as using the linked dev channel in TFA to get an informed opinion.

FastAI.jl itself is composed of multiple constituent packages that can and are used independently, so there's also the option of mixing and matching. For example, https://github.com/lorenzoh/DataLoaders.jl is completely library agnostic.

https://github.com/jkrumbiegel/Chain.jl would probably work there, but you're not the only one who would like to see this in the language/stdlib itself.

For sure, I didn't mean to imply they weren't looking at compute too! https://github.com/apache/arrow-datafusion is another example of the shared compute vision. What I was trying to point out is that (at least for Arrow core) they seem to eschew FFI and generating shared libraries in favour of from scratch implementations in other compiled languages and direct bindings in interpreted ones.

As much as many of us would like it to be, the kind of data science work you see Scala used for is a pretty small part of what Julia is used for.

I think a big part of that is because DS rarely involves writing fast numeric kernels or hot inner loops, i.e. user code that needs to do numeric stuff quickly. This is in large part because very large organizations have poured untold millions into libraries that already handle this (e.g Spark).

In domains where this has not happened or that have more bespoke requirements (e.g. modelling and simulation), something like Julia is far more compelling. That's not to say it's not viable, but unless more practitioners start feeling stuck in a rut [1] I don't see the mindshare changing dramatically.

[1] https://dl.acm.org/doi/10.1145/3317550.3321441

Regarding RL, did you look at https://juliareinforcementlearning.org/? I haven't used it myself, so it would be interesting to know where it's lacking.

To your point about static analysis, https://github.com/aviatesk/JET.jl appears far more capable than comparable systems for other dynamic languages.

I'd like to see those as well, with the caveat that I've yet to see a language implement some of them performantly (e.g. arguments against higher-kinded types in Rust).

Arrow is getting support for N-d arrays, so if anything they're expanding in that area (which is exciting). I don't think they're interested in creating a universal libarrow though, the point of the data format and C data interface is to have languages define their own implementations.

Revise.jl inside the REPL is annoying as hell to use when you start messing with structs.

And Revise.jl kind of proves the fact that incremental compilation is entirely possible. If it wasn't possible at all due to $maximum_dynamic_insanity that wouldn't even work.

I agree it's disengenuous to say that Revise is the answer to all problems when struct redefinition is still not possible. Yes you can toss them in a module, but then why allow defining them in global scope at all? Thus far I haven't seen any theoretical limitations either, since Common Lisp variants seem to be able to do something similar.

That said, I would not look at most other dynamic languages for this. Having a mandatory VM is an express non-goal in Julia, and if you want one then you'll have to face off against all the other people asking for better static compilation. Again, compiled lisps show us that a VM isn't even necessary to get this level of dynamism or low latency incremental compilation.

The claim around having to recompile the entire world has already been addressed in a sibling thread, so I'll not rehash it here.

Can you elaborate on where the hole is? Jeff Bezanson's thesis work on Julia was undoubtedly PLT, as were some of the other folks at the Julia Lab now (e.g. Shuhei Kadowaki). Keno Fischer is very much into all things PLT, as can be evidenced by his work on Diffractor (see this ACM SIGPLAN presentation [1]). Ditto for James Fairbanks and all the people working on Catlab.jl's [2] ecosystem.

Where I do agree with you is that PLT awareness has not permeated the entire community as much as I'd like to see. Certainly one feels a need sometimes to push back against increased "Matlab-ification" of the language. However, it is also nice to see a direct line between rather theoretical concepts like abstract interpretation and very practical use cases like GPU computation.

[1] https://www.youtube.com/watch?v=mQnSRfseu0c [2] https://github.com/AlgebraicJulia/Catlab.jl [3] https://en.wikipedia.org/wiki/Abstract_interpretation

Julia does appear to have a higher than usual proportion of package authors to total users, FWIW. I think it's both a blessing and a curse, because feedback around gaps in the ecosystem is sometimes brushed away with "write your own package". That is, because a large part of the community writes packages to scratch their own itch (I've yet to see one written for citations), they expect others to do the same (which may not be fair).

This is definitely not just a you problem. There are resources out there like [1] and [2], but much less in the way of curation and a dearth of end-to-end tutorials/walkthroughs.

I'm not sure how best to improve the situation, but the current state of things leaves much to be desired. If you're willing, don't hesitate to post about your experience and any feedback you have on the community forums.

[1] https://www.youtube.com/watch?v=dczkYlOM2sg [2] https://github.com/juliohm/julia-distributed-computing

I do wonder if you'd see similar reactionary claims about Elixir being a general-purpose language if the community experienced constant shallow and misinformed claims to the contrary (which Julia has in abundance, for some reason). Imagine if every 10th post about Elixir on HN was "I will never use it because I work in embedded and it has zero support there" when Nerves is a google search away.

From another perspective, if we consider "general purpose" to mean "focuses on most of the things I care about", then you could argue (and I'd agree) that Elixir appears more general purpose for a larger number of people. Specifically, most devs work on networked services, and networked services are bread and butter for BEAM languages.

Lastly, there is also a strong tendency to dismiss anything with a whiff of academic attachment as unfit for "real" industry work. This effects not just Julia, but also Scala, OCaml, Haskell, TLA+, and more. Though I do empathize with the perspective, It is often taken to the point of caricature-you can show someone a dozen companies using some tech and it'll be as if you said nothing at all!

I agree progress on the deeper problems is slow, and I also think that it is slow because 90%+ of the issues people have with Julia are "user experience" things (see any of the help forums as well as all of the previous HN discussions). Given a limited amount of resources, it's difficult to justify a deep dive into revamping the type system (AIUI multiple dispatch with complex types + traits is mostly unexplored territory) over improving latency and tooling. That's not to say it shouldn't be done, but in the absence of some significant (financial and development) support behind it I don't think the type system work will be prioritized.

You may be interested in the current initiative around compiler plugins [1]. One of the explicit design goals is offload to alternative backends like GPUs or Wasm, but you could see how that would extend to something like Cranelift as well.

That said, LLVM codegen performance is very much a tail wagging the dog thing, and I wish upstream put a significantly larger focus on it [2]

[1] https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?view [2] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html