BadInformatics

The naming is unfortunate, but JuliaInterpreter is not the built-in one but a separate package for use in external tooling. The built-in one can be run globally via the --compile=min CLI flag. Likewise, you can also pass -O0 to -O3 to configure the level of optimization (which, predictably, affects latency).

As for IR representation, I'm not aware of any limitations of the IR (remember, there are multiple levels) over a LuaJIT-style bytecode for interpretation performance. After all, the Futamura projections tell us that a compiler is really an interpreter that's undergone some partial application. Of course, that's a theoretical correspondence that has little bearing on real-world performance, but I don't think you can confidently say that Julia's lowered or unlowered IR forms are fundamentally bad for fast interpretation.

Julia does have a minimal compilation path with an interpreter. You can even configure this on a per-module basis, which I believe some of the plotting packages do to reduce latency. There is even a JIT-style dynamic compiler which works similarly to the VMs you listed: https://github.com/tisztamo/Catwalk.jl/.

IMO, the bigger issue is one of predictability and control. Some users may not care about latency at all, whereas others have it as a primary concern. JS and related runtimes don't give you much control over when optimization and are thus black boxes, whereas Julia has known semantics around it. I think fine-grained tools to externally control optimization behaviour for certain modules (in addition to the current global CLI options and per-package opt-ins) would go a long way towards addressing this.

They aren't collisions so much as overloads. e.g. GPUArrays implements the same base AbstractArray methods. I'm not a big fan of using either (in any language) because it obscures where imports come from, and AFAICT overloads are created even with a plain import.

Others have commented on stacktraces, so I wanted to mention that the debugging experience in VS Code (the replacement for Atom-based Juno) is much improved as of the past couple of months. Worth a revisit if you're using it already.

Regarding stdlib support, I feel like it's a toss-up. For numeric and data processing code, Julia has a much richer stdlib whereas I need at least Numpy in Python (and even then, working with anything not array-shaped is a pain). For more systems-y stuff though, Python has a much fuller stdlib (e.g. reading/writing a bunch of archive formats). The end result for me is that scripting with Julia feels high friction, and doing anything which requires any kind of throughput with Python feels like pulling teeth.

IIRC an explicit design goal was to enable circular deps (hence why imported bindings are considered "live". It's interesting to see this works in practice though, I've never tried using them myself.

As mentioned in TFA, the author has both written and spoken about software engineering research and related topics in some depth before. Though fiery, I think it does its job as a more informal cautionary tale on accepting research in the field without a critical gaze.

Analyses like [1] and [2] (from the same author) are extraordinarily valuable because they help us wade through the firehose of published studies to find what (if any) conclusions may be gleaned. Without such a filter, we are fated to a) repeat work by slogging through the torrent ourselves, or b) taking stuff at face value. Certainly there is no shortage of the latter happening on forums like this, and I wonder how many misinformed decisions are made as a result.

[1] https://danluu.com/empirical-pl/ [2] https://www.hillelwayne.com/post/are-we-really-engineers/

Yeah, this is true in China as well IME. Perhaps TFA is extrapolating from experiences in other East Asian countries?

For a more nuanced and far more detailed counterpoint, see https://www.hillelwayne.com/tags/crossover-project/ (discussed in https://news.ycombinator.com/item?id=25823907).

As has been mentioned in this article and many previous takedowns of SQL the language, it's a pretty poor approximation of both relational calculus and relational algebra. So in that sense, SQL barely has a leg to stand on. If anything, SQL not adhering more closely to those techniques is why query planning is so fraught in modern relational DBs. A language like the one described in TFA would be both closer to the relational model as theorized and probably easier/more consistent to optimize.

Note that because blocks in Julia are expressions, you can do multi-line expressions in comprehensions that you wouldn't be able to do in Python:

    [
       let y = x + 1
         z = 2y
         -z
       end 
       for x in 1:5
    ]

Looks like HN ate the exclamation mark, using the slug url title would've been better.

Personally, I was first taught about the basics of data warehousing and the needs of common OLAP workflows before ever touching a cube. Cubes were just another way of accessing and slicing the same data, but far from the only way. This has only become more apparent as more and more analytics isn't relying on the traditional RDBMS-based data warehouse structure in favour of more exotic sources.

Funnily enough, Microsoft does use Qt for parts of the OneDrive UI: https://forum.qt.io/topic/87898/microsoft-onedrive-sync-uses.... What that says about the state of UI framework fragmentation on Windows is up to interpretation.

It helps here to have good shortcuts (i.e. \tex like commands) for all the symbols. Otherwise writing them is a PITA and nobody will do it (e.g. Go supports full unicode identifiers, when was the last time you saw one in the wild?)

The sibling comment has already touched on the compiler side of things, so let me touch on the rest:

> A stronger culture of functional programming could make your code faster and easier to understand. It's often (though not always) easier for tooling to optimize pure functions over immutable data structures (and arrays). Arrays are currently mutable, and there is too much emphasis on mutating functions.

Yes and no. Immutable data structures shine in 2 scenarios:

1. Small types that can be represented with a couple of machine words. Julia supports this already through via stack allocated immutable struct types and packages like StaticArrays [1] 2. Persistent data structures as found in most FP languages.

Note how neither of these capture the large, (semi-)contiguous array types used for most numerical computing. These arrays are only "easier to optimize" if one has a Sufficiently Smart Compiler to work with. Here we don't even need to talk about Julia: the reason even Numba kernels in Python land are written in a mutating style is because such a compiler does not exist. You may be able to define something for a limited subset of programs like TensorFlow does, but the moment you step outside that small closed world you're back to needing mutation and loops to get a reasonable level of performance. What's more, the fancy ML graph compiler (as well as Numpy and vectorized R) is dispatching to C++/Fortran/CUDA routines that, not surprisingly, are also loop-heavy and mutating.

Should Julia do a better job of trying to optimize non-mutating array operations? Most definitely. Is this a hard problem that has consumed untold FAANG developer hours [2] and spawned an entire LLVM subproject [3] to address it? Also yes.

> The iteration protocol can be made more memory-efficient for large collections and simpler...

Yup, this has been a consistent bugbear of the core team as well. The JuliaFolds ecosystem [4] offers a compelling alternative with fusion, automatic parallelism, etc. in line with that blog post (which, I should note, is a much different beast from Rust's iterator interface/Rayon), but it doesn't seem like the API will be changing until a breaking language release is planned.

> In general, systems languages don't make language decisions lightly. They have committees, discuss how other languages do things, make proposals. This allows more perspectives on each decision. That would be an improvement over the more ad-hoc style of Julia development, as long as Julia can avoid adding every possible feature, which is a risk of expanding the decision-making body.

I'd argue this is a property of mature, widely used languages instead of systems languages. Python, Ruby, JS, PHP, C# and Java are all examples of "non-systems" languages that do everything you list, while Nim and Zig (note: both less well adopted) are examples of "systems" languages that don't have such a formalized governance model.

Julia (along with Elixir) are somewhere in between: All design talk and decision making is public and relatively centralized on GitHub issues. There is no fixed RFC template, but proposals go through a lot of scrutiny from both the core team and community, as well as at least one round of a formal triage (run by the core team, but open to all). Any changes are also tested for backwards compat via PkgEval, which works much like Crater in Rust. There was a brief effort to get more structured RFCs [5], but I think it failed because the community just isn't large enough yet. Note how all the languages with a process like this are a) large, and b) developed it organically as the userbase grew. In other words, you'll probably see something similar pop up when the time savings provided by a more structured/formal process outweighs the overhead of additional formalization.

[1] https://github.com/JuliaArrays/StaticArrays.jl [2] https://www.tensorflow.org/xla, https://tvm.apache.org, https://github.com/pytorch/glow, etc etc etc. [3] https://mlir.llvm.org/ [4] https://github.com/JuliaFolds [5] https://github.com/JuliaLang/Juleps

I can think of at least 5 "core" contributors (out of only 20 or so) off the top of my head who have a PL or systems background. Given some time, I could easily find 10-15 more who are affiliated with the Julia Lab, Julia Computing or community regulars. Hell, most of the Julia Lab's projects are systems stuff.

The biggest group outside of numerical computing in Julia land are the PL and systems people though? This includes type theorists [1], database folks [2], distributed systems people ([3] to name just one). There are also a fair number of compiler nuts, hence the existence of multiple projects [4][5] in this space. And this is before getting into things that bridge more than one of the domains above, e.g. [7] or [8].

FTR, I think it's fair to question whether numerical computing should have an outsized influence on the direction of the language. I also think it's a pretty fair comparison to point out how standardized and consistent the Rust governance process is compared to Julia's (the Rust RFC system is an exemplar here). That doesn't mean there is a dearth of PL and systems knowledge in the Julia community though.

[1] https://github.com/AlgebraicJulia/Catlab.jl [2] https://www.youtube.com/watch?v=tRBl-6uEJJE [3] https://github.com/JuliaParallel/Dagger.jl/ [4] https://github.com/FluxML/IRTools.jl, https://github.com/FluxML/MacroTools.jl [5] https://github.com/JuliaCompilerPlugins [6] https://github.com/0x0f0f0f/Metatheory.jl [7] https://2020.splashcon.org/details/splash-2020-rebase/13/Non... [8] https://github.com/JuliaSymbolics/Symbolics.jl

Why is using string replacement to, well, replace spaces with dashes if one wants a non-standard string format an outrageous request then? Personally, I've been bitten time and time again by non-standard, hard-coded strftime formats. Either show a localized time and let my system decide the format, or use ISO 8601/RFC 3339. If one must have full control over the format, the Date object exposes getters for each component.

Prior to FHIR, there was actually an XML-based HL7 v3 as well. Mercifully, it collapsed under the weight of its own spec and rarely shows up in the wild these days. CDA still survives, but it's much easier to work with and being slowly made obsolete by FHIR resources.

IME the billing-centric view is mostly a US-centric view. If you talk to folks who've done EHR deployments in other countries (my dataset is mostly Canada/UK), a not insignificant amount of work is put into tweaking Epic/Cerner/etc. _away_ from being so billing focused. Your other points still resonate, though anecdotally I've seen less private sector interest in doing analysis over providing infrastructure or other COTS software here.

This kind of collusion is driven far more by perverse incentives than some alleged cultural phenomenon of half-assery people like to attach an incorrect but exotic-sounding foreign phrase to. I can't speak for Jugaad, but 差不多 ("Chabuduo") is not at all appropriate here [1]. Just call it what it is: cheating, collusion and conspiracy.

[1] https://news.ycombinator.com/item?id=27052249. This reminds me of the Japanese buzzword bingo of earlier decades.

As GP mentioned, AOE4 will be a good litmus test of the "commercial sense". Microsoft arguably squandered one of their most iconic franchises for the better part of 2 decades, and yet here we are (in large part thanks to strong sustained grassroots support from the community).

> Let's assume hospitals are severely overloaded, and are simply unable to treat COVID patients. The pedantic meaning of what I said will certainly be true: non-covid excess deaths will be less.

Even the pedantic interpretation does not necessarily hold. Though healthcare resources for life-threatening conditions are not strictly zero-sum, many of them would effectively be once covid overwhelms existing ICU and ED capacity. There are plenty of examples of personnel being pulled from e.g. cancer care or cardiology teams to help in covid wards. This directly translates to increased wait times for patients in those categories, much like would happen if people were putting off getting checked out themselves.

Moveover, hospitals and healthcare systems to not just "bounce back" after being severely overloaded. Staffing is already strained, and unless you ban clinicians from taking leave you would see cascading reductions in capacity after a couple months of being overloaded. This is to say nothing of the equipment shortages we had in the early days of the pandemic. Ultimately, patients who would require care for non-covid reasons would still suffer because of a massive backlog. Determining whether this backlog would be larger or more/less harmful when amortized compared to what we have now requires health economics analysis that I am certainly not qualified to perform.

> Frankly, I suspect that problem is made worse by a long, dragged out, pandemic. People can often handle a short period of extreme stress better than they can handle a much longer period of high stress.

This feels right to me too, though I've not the literature to verify it. However, it's an equally valid argument for strict short-term lockdowns a la New Zealand, Australia, Vietnam, Taiwan, etc. That is to say, it does not follow that not mitigating is the only reasonable strategy to prevent a dragged out pandemic.

A better (if grim) post-hoc analysis of Canada would be to compare the Atlantic provinces (less densely populated, strictly enforced interventions), the other smaller provinces (less densely populated, few interventions until recently) and the large provinces (densely populated, moderate but very poorly enforced interventions). My guess is that all three approaches will not be found to be equally effective.

This analysis presumes that hospital emergency and critical care capacity is flexible (it's not), that we can expect medical professionals to keep on performing at 100% in the face of overwhelming stress (they will not), and that Canada would somehow succeed at what Italy did not back in the first half of 2020 by doing even less mitigation. An argument in favour of no mitigation would have to demonstrate:

1. covid-related mortality and morbidity would not make up for any drop in other excess deaths

2. short-term stops on all non-critical care would, on balance, result in a significant drop in excess deaths over longer-term stops on a smaller percentage of non-critical care

3. hospital systems and their staff would still be intact after such a large wave. This may sound crazy, but while we're trading anecdotes you may be surprised at how many ICU nurses considered quitting because of how hard the latest surge hit. These are the people who dictate how many "ICU beds" we have, not the physical beds themselves!

4. that we can make any kind of meaningful analytical statement on covid mortality vs excess mortality for a specific age group given the lack of reporting data on both. In particular, data from coroner's offices on covid deaths has a huge lag time at present. Looking at case counts only is a poor proxy given you have to model infection -> death/recovery/discharge lag times, geographical variations and healthcare capacity as well. The HMD link merely provides total counts and proportions with no additional commentary. You can find more specific discussions on the subject [1], but they don't cover demographic breakdowns over time and necessarily maintain a high degree of uncertainty.

I don't think it's controversial to say governmental policy here has been sub-optimal at best. But to say that one extreme approach or the other is what we ought to have done based on woefully incomplete data is a stretch too.

[1] https://health-infobase.canada.ca/covid-19/epidemiological-s...

I'm not sure that's necessarily the domain of a low-level package like CUDA.jl though (which I assume you're referring to). That kind of interface is more the domain of higher-level packages like https://github.com/JuliaGPU/DaggerGPU.jl and to a lesser extent https://juliagpu.github.io/KernelAbstractions.jl/stable/. Moreover, the jury is still out on whether the built-in Distributed module is an ideal abstraction for every use-case (clusters, heterogeneous compute, etc.)

WRT Nx, my biggest question is how they'll crack the problem of still needing big balls of C++ and the shims everywhere to get acceleration. Creating a compiler that generates efficient GPU or other accelerator code is a massive research project with no clear winners, never mind the challenge of reconciling the very mutation-heavy needs of GPU compute with a mostly immutable language model.

I'm skeptical it's even good at that intended purpose. Perhaps one could argue it prevents blatant, direct corruption, but it does little to control for large company influence and other forms of soft power.

The biggest companies in this space maintain an active revolving door, which ensures that procurement policy is moulded (either consciously or unconsciously) to their process and needs over time. Even more insidiously, they've convinced governments to gut their own IT workforce, removing the people most qualified to critically analyze software vendors. This appeals to your average bureaucrat because it appears to strike a good balance between effort and risk minimization (e.g. why bother managing multiple smaller vendors or timelines?), while in practice it does exactly the opposite.

Name and shame: https://www.cbc.ca/news/canada/ottawa/phoenix-costs-137-mill...

Is there a clear consensus that this is the case? I had much the same understanding as you after reading all the debates on rent control on HN, but was recently pointed to [1] which offers a very contrarian perspective (including an analysis of a study done on rent control in SF). As a non-economist, it feels like this topic deserves a great deal more empirical study so we're not stuck arguing with anecdotes and hypotheticals.

[1] https://jwmason.org/slackwire/considerations-on-rent-control...

In case you haven't seen it already, I found https://news.ycombinator.com/item?id=26779580 to be a pretty succinct list of the biggest stumbling points (latency, telemetry and documentation).

A couple of more specific points I'd like to add after experience writing non-trivial PS scripts:

- Tooling is still spotty. Last I used the VS Code extension, it was flaky and provided little in the way of formatting, autocomplete or linting. AIUI PowerShell scripts should be easier to statically analyze than an average bash script, so something as rigorous as ShellCheck would be nice to have too.

- Docs around .NET interop still appear to be few and far between. I recall having to do quite a bit of guesswork around type conversions, calling conventions and the like.

It's nice to see the docs have had a major overhaul since I last dug into them though :)

> Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries.

Not really? Most of these concepts can be linked back directly to earlier from CS theory and/or other languages. For example, Redux taking inspiration from FRP and functional lenses, or (most pertinent for this thread) hooks being a facsimile of algebraic effects in JS. As much as I like these concepts in general, I feel some go too far against the grain of what is idiomatic in the language and incur unnecessary friction/spooky action at a distance because of it. For example, here [1] are some well thought-out critiques of hooks and why people struggle with them from experienced JS framework authors.

[1] https://news.ycombinator.com/item?id=22903967

Though I agree on the cultural ignorance point (especially not choosing to localize terms so that they sound exotic), needless overtime and the 996 culture are absolutely a problem. It's not so much that the work is tiring as the hours are unnecessary and prohibit people from doing stuff outside of work. 20-30 years ago, bonding with peers after work was still pervasive in China/Japan/SK, but the hours were nowhere near as crazy as they are now.