cbkeller

Sure, just saying it's not that they haven't tried. If you have some specific ideas for low-hanging fruit that you think the Julia devs have missed though, I'm sure they'd welcome a PR!

edit: also, time-to-first-plot is a lot less than 30 seconds for me these days, even without PackageCompiler. (time-to-second-plot is, as usual, instantaneous)

Julia 1.5 and 1.6 are going to have some really nice features performance-wise (1.5beta has cut a lot of allocations from my code and feels noticeably snappier than some older version).

Once they come out it might be worth having a push to get your cluster updated. I'm sure folks in the Julia slack (check out #HPC and #distributed) would be happy to help if they can, even if it's just at the level of building a local install in your user directory.

Regardless of what is a subset of what, I certainly agree with the OP that OOP feels "anemic" in comparison to the dispatch-based paradigm of Julia.

I can't tell you how many times I've seen disparate packages written by different authors with no explicit effort towards interoperability "just work" together in Julia (e.g., [1]), something I have never seen to a comparable degree in any other language.

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

As someone coming from a physical science rather than CS background, I routinely find 0-based indexing to be "frustrating and a mental tax" compared to 1-based

Yeah, Julia has had some form of precompilation/caching for ages now, but sorting out all invalidations appears to be highly nontrivial [1] and devs have had more fundamental priorities pre-1.0. There have been some substantial improvements to latency in the meanwhile nonetheless, and PackageCompiler.jl is a viable option as well.

[1] https://github.com/JuliaLang/www.julialang.org/pull/794

OOP has become an antipattern (ok, partially kidding but...)

Chris deserves some sort of prize for that package. Delivered some factor of 2 or greater speedups for significant portions of my code with just an `@avx`

One of the main reasons I started looking into Julia was because someone smarter than me in the DOE CSGF program was using it (specifically Miles Lubin, who was working on JuMP[1] at the time). I don't know if that's a good way to choose programming languages, but one way or another I'm definitely a Julia convert now. Come for the community, stay for the multiple dispatch!

[1] https://github.com/JuliaOpt/JuMP.jl

Without having dug into the specifics of this particular package, I can say generally speaking that average package quality has in my view been improving a lot over the past few years; two years ago the language was pre-1.0 and people were still figuring a lot of things out. Some packages of course were excellent even then, but those tend to still be actively maintained.

I am very guilty of the "Over-constraining argument types" antipattern. Trying to get better at this.

Nice!

I think these folks are working on it: https://biojulia.net/

> The science of rocks, soil and weather will lead the study of planets.

Sounds great to me :)

Well, Julia's technical computing community - arguably the subset that matters here - was much larger than Swift's. The more significant justification IMO, is

> and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster.

In any case, both Julia and Swift seem to be making good progress here and I wish them both the best.

Chris Lattner is leading the project, of course they're using the language he designed. Personally I think they substantially underestimated the difficulty of setting up a full technical computing ecosystem in Swift relative to Julia. But, fair enough, if I'd designed Swift I'd probably be dogfooding it too.

Some previous discussions that mention the swift-vs-Julia decision: [1] https://news.ycombinator.com/item?id=19714622 [2] https://news.ycombinator.com/item?id=19884273

If I were to ever hire a developer, it'd probably be for work in Julia, but I don't have nearly enough grants for that yet :)

Coming from academia, I have no entrepreneurial sense -- but if you know enough math to make use of optimization packages like JuMP, where Julia excels, those skills would seem to me very transferable to commercial operations research.

For a definition of crystal that requires translational symmetry then no, but more colloquially speaking there are natural mineral "crystals" like Icosahedrite [1,2] (technically quasicrystals [3]) that have space-filling tilings with five-fold rotational symmetry.

The first discovery this type of symmetry (in synthetic Al-Mn alloys in 1982) led to the 2011 Nobel Prize in chemistry [4]

[1] https://en.wikipedia.org/wiki/Icosahedrite

[2] https://doi.org/10.2138/am.2011.3758

[3] https://en.wikipedia.org/wiki/Quasicrystal

[4] https://www.nobelprize.org/prizes/chemistry/2011/summary/

It's also hilarious, considering that they're only in that business because they asked to be [1]:

> ICANN circulated a request for proposals in May 2002 for a new organization to manage the .org domain. The Internet Society (ISOC) teamed with Afilias to put forth one of eleven proposals ICANN received. ISOC won an endorsement within ICANN and was recommended to the selection committee

[1] https://en.wikipedia.org/wiki/Public_Interest_Registry

Yeah, and the fact that Ethos is run by a former CEO of ICANN is incredibly shady.

I think it's worth noting some of the timeline of this [1]:

> On May 13, 2019, ICANN announced that they would remove the price cap on .org registrations (despite 98% disapproval in public comments [2])

> On May 14, 2019, the private equity firm Ethos Capital was founded by former ICANN chief executive Fadi Chehadé and investor Erik Brooks.

> On November 13, 2019, it was announced that the Public Interest Registry (that manages .org) had agreed to be acquired by Ethos Capital, as its first investment.

> Subsequently, PIR announced it would abandon its non-profit status to become a B Corporation.

Is the author unaware of this, in on the deal, or just remarkably naive?

[1] https://en.wikipedia.org/wiki/Public_Interest_Registry [2] https://www.theregister.co.uk/2019/11/20/org_registry_sale_s...

PIR is abandoning its nonprofit status anyways, to become B corporation instead: https://en.wikipedia.org/wiki/Public_Interest_Registry

Julia seems to be making good progress on this front anyways :) https://github.com/FluxML/Zygote.jl

Sure, but if the journal publishes too many articles it'll lose prestige. Nature publishes what, 8% of submissions? And that's apparently what they consider financially optimal -- they're a for-profit corporation, they could publish more if they wanted to. I guess the question is just whether this applies equally to open-access and traditional subscription journals.

The article makes some fair points, but strangely seems to imply that open access is somehow opposed to rigorous peer review, which certainly leaves an odd taste in my mouth.

> Of course, scientific publication is subjected to a high degree of quality control through the peer-review process, which despite the political and societal factors that are ineradicable parts of human interaction, is one of the “crown jewels” of scientific objectivity. However, this is changing. The very laudable goal of “open access journals” is to make sure that the public has free access to the scientific data that its tax dollars are used to generate.

Leaving the tab open for a half hour turned up about five of those, a google oauth key, and what seemed to be an SSL certificate private key, among others.

Ok, thanks for clarifying! Is that part of why you got out of the field?

> and thus not inherited trans-generationally

I'm not sure what you're referring to here? There appears to be quite a significant body of literature on epigenetic inheritance -- just to pick a few: [1,2,3,4]. The term "Transgenerational epigenetic inheritance" even has its own wikipedia page: https://en.wikipedia.org/wiki/Transgenerational_epigenetic_i...

[1] https://www.nature.com/articles/ng1199_314

[2] https://www.nature.com/articles/nrg1834

[3] https://www.nature.com/articles/nature05917

[4] https://doi.org/10.1016/j.cell.2014.02.045

Things are still improving, but I already find it quite usable in practice. Yes, precompilation can take a while, but once you start using the language regularly you hardly notice it, since you only need to re-precompile after installing updates -- which ends up being a small proportion of the time. Same with "time to first plot", since I almost always have a session already running already these days.

Totally. As Mourou puts it in the talk, "we are boiling the vacuum!" Going of the figures in the talk, it looks like he would be counting on ultrashort pulses that are well into the realm of relativistic optics, and possibly approaching the QCD regime.

To be fair, it looks like what he's proposing is fundamentally different from inertial confinement fusion. Inertial confinement with lasers is so hard because it's so tricky to apply perfectly even, symmetric force on every side of the hohlraum. What's being proposed here seems to be more on the line of <attosecond laser pulses directly exciting the nucleus, so wouldn't be useful for fusion but would have very different yields and wouldn't have the same trouble with maintaining confinement.