cbkeller

On top of that, Julia's non-lispy surface syntax has a perfectly valid s-expression representation that can be displayed with `Meta.show_sexpr`, and for which you could hypothetically enable a repl in only a few lines (e.g. [1])

[1] https://gist.github.com/brenhinkeller/44051118c2f9d18b26dc76...

Earth's moon is freakishly large by moon standards, as it turns out!

> At about one-quarter the diameter of Earth (comparable to the width of Australia), it [the Moon] is the largest natural satellite in the Solar System relative to the size of its planet, the fifth largest satellite in the Solar System overall, and is larger than any dwarf planet.

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

I also started in Matlab + C, and didn't personally like Python very much, but wound up liking Julia after a bit of adjustment.

Still a work in progress, but I've written up a few of my lessons learned in the process [1] in case they're useful to anyone else. Properly figuring out type stability and dispatch-oriented programming took me way too long, but things started making a lot more sense after that.

I haven't used it a ton, but [2] also seems potentially useful for anyone else interested in making the same switch.

[1] https://github.com/brenhinkeller/JuliaAdviceForMatlabProgram...

[2] https://lakras.github.io/matlab-to-julia/

On that topic, I'll throw in a shoutout to Cormullion's excellent JuliaMono font [1,2]!

Typing certainly does add more friction between u and µ than a chalkboard would, though it is perhaps also notable that mathematicians seem to have felt that it's worth the effort, and have come up with a quite nice system for it in LaTeX -- and I would certainly not mind seeing more languages and editors add support for LaTeX completions the way the Julia ecosystem has.

[1] https://juliamono.netlify.app/

[2] https://github.com/cormullion/juliamono

If you need to run small scripts and can't switch to a persistent-REPL-based workflow, you might consider starting Julia with the `--compile=min` option. If you know which packages you're going to need, you can also reduce startup times dramatically by building a sysimg with PackageCompiler.jl

There is also technically an interpreter if you want to go that way [1], so in principle it might be possible to do the same trick javascript does, but someone would have to implement that.

[1] https://github.com/JuliaDebug/JuliaInterpreter.jl

I hope it'll get there! If anyone wants to help out, check out (e.g.) https://github.com/tshort/StaticCompiler.jl/pull/46

Honestly you were probably fine the first time, given that you can easily disable the GC, and that it's really not that hard to entirely avoid generating garbage (in which case the GC generally wouldn't have been triggered even if you'd left it on).

You can just turn off the GC with `Base.GC.enable(false)`

There are a few tricks to getting Julia to be actually fast, and while it's not hard per se if you know them all (at least for numerical work), it's definitely not trivial.

IMHO, you really have to embrace dispatch-oriented programming, and that includes being scrupulous about avoiding type instability. You also have to be a bit conscious about allocations, since it's easy to write Julia code (especially if you're trying to write in a "vectorized" style as is common in R, Python, Matlab) that generates absurd numbers of allocations, which must then be garbage-collected. But also easy to avoid those allocations if you know.

It took about two years, but after picking up more of this, I was eventually able to switch everything my group does from a two-language solution of matlab for scripts and plotting and C (with MPI) for HPC to all-Julia. This [1] was originally targeted at academics making the same switch, but much of it could be relevant to those with an R background as well.

[1] https://github.com/brenhinkeller/JuliaAdviceForMatlabProgram...

Ah yes, Python, the famously statically compiled general-purpose programming language :p

More seriously though, just because some language may be considered "general purpose" doesn't mean it's the best language for everything, or should replace other languages outside of whichever particular applications where it excels.

> Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable?

Look, everyone wants static compilation, and it's almost certainly going to happen eventually. It's not unreasonable at all to want that. The only thing that would be unreasonable is to (apparently repeatedly!) imply or assert that this lack of static compilation (and/or better caching) is due to some bizarre perversion on the part of the community.

If you want it to happen faster, then stop complaining about it on HN, get familiar with the current attempts at true static compilation in e.g. https://github.com/tshort/StaticCompiler.jl/pull/46 and start contributing yourself.

I think the main reason they stopped referencing that claim is that "two-language problem" means too many different things to different people. But yes, real static compilation would be great.

Hmm, good question. There is generally expected to be plenty of decomposition (or in biogeochemical speak "remineralization") happening any time you have enough organic carbon around (and enough of a chemical potential gradient between that and some oxidant) for somebody to make a living respiring that organic carbon. And just in terms of biogeochemical cycling the result is pretty similar whether the decomposition is being done by heterotrophic bacteria and archaea, or by fungi -- so to first order it wouldn't change that. Nonetheless, there might be some unexpected consequences if a significant proportion of the remineralization was being done by fungi.

As a geologist, we can definitely have an unusual idea of what counts as "fast" :)

That's a good question, I would say if anyone found fungi before the GOE that would be a big surprise. Finding them after the GOE makes sense, so doesn't necessarily change our understanding of the GOE -- but if they really were around this soon after (if this article is correct) that would definitely seem to have interesting implications for the evolutionary origin of fungi.

Distribution costs are negligible when you just make the PDFs free to everyone, but publishers spend a bunch of money on access control, security, and web interfaces that make you jump through hoops to download the actual PDF while doing everything possible to convince you to read the papers through their (possibly "social"/"collaborative") online platform instead.

Just tried it out -- super convenient! Seems to work fine with LibreOffice as well.

I don't think that's particularly what's going on. I think it's more just that Julia has a relatively small but incredibly zealous group of users.

If Julia solves your personal version of the two language problem, and especially if dispatch-oriented programming happens to be a good fit for the problems you solve and the way you like to program, you're probably going to think it's the best thing since sliced bread. If not, on the other hand, you may not think it's anything particularly special.

What is fascinating to me about this is the regions including [1] in North Dakota or [2] in northern Russia (~300 km southwest of Norilsk) that have incredibly large and bright zones of light pollution -- more than many large cities -- almost entirely disconnected from population, apparently as a result of temporary natural gas extraction infrastructure.

The pollution at [1] is larger/brighter than Denver, and [2] is about equivalent to Moscow!

[1] https://www.lightpollutionmap.info/#zoom=7.67&lat=47.9667&lo... [2] https://www.lightpollutionmap.info/#zoom=7.43&lat=67.7473&lo...

The Anopheles mosquitos [1] which spread human malaria are present at some level across about half of the US, but are just not especially abundant here compared to other mosquitos that do not spread malaria.

In fact, of the ~200 mosquito species which occur in the United States, only 12 are known spread any sort of human disease [2].

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

[2] https://www.cdc.gov/mosquitoes/about/mosquitoes-in-the-us.ht...

According to one of the researchers who co-signed a letter of concern over the issue, the Minnesota group also only received IRB approval retroactively, after said letter of concern [1].

[1] https://twitter.com/SarahJamieLewis/status/13848713855379087...

This looks awesome! I might try to incorporate this as an extra resource in an intro (Julia) class in the future.

Deciding that your pain is well managed without opiates has always been a perfectly reasonable and medically-accepted option, and unsurprisingly there has never been any sort of social stigma against people who decline painkillers.

Most to the point, declining to take painkillers does not adversely impact other people's health.

This is not a good analogy.

eta: ironically, the problem with the opioid crisis was not too much regulation and oversight by "the authorities", but too little; too much freedom for doctors to prescribe stronger painkillers, and for patients to request them.

I think that video may have legitimately improved my understanding of the potential pitfalls of microservices

This earlier post seems to provide some useful context: https://writings.stephenwolfram.com/2020/12/combinators-and-...

I did this too, it was great. I’m sometimes surprised by how few of the people around me in academia seem to have done anything similar.

While the underfunding and collapse of the observatory is a tragedy, I think it is perhaps less surprising in the context that much of the original political will behind the observatory was motivated by potential military applications, which became somewhat passé after the fall of the Soviet Union. This "dual use" origin is mentioned briefly in the article here, but expanded in more length in some other sources [1,2]:

The origins of the observatory trace to late 1950s efforts to develop anti-ballistic missile (ABM) defenses as part of the newly formed United States Department of Defense (DoD) Advanced Research Projects Agency (ARPA) ABM umbrella-effort, Project Defender. [...] It was known that hot, high-speed objects caused ionization of the atmosphere that reflects radar waves, and it appeared that a warhead's signature would be different enough from decoys that a detector could pick out the warhead directly, or alternately, provide added information that would allow operators to focus a conventional tracking radar on the single return from the warhead.

Although the concept appeared to offer a solution to the tracking problem, there was almost no information on either the physics of re-entry or a strong understanding of the normal composition of the upper layers of the ionosphere. ARPA began to address both simultaneously. To better understand the radar returns from a warhead, several radars were built on Kwajalein Atoll, while Arecibo started with the dual purpose of understanding the ionosphere's F-layer while also producing a general-purpose scientific radio observatory.

Some folks here may also be familiar with the US project to locate Soviet radar installations via signals reflected off the moon (as discussed in Steve Blank's excellent Secret history of Silicon Valley [3]), and it seems that Arecibo participated in this as well [4]:

The CIA employed a 150-foot dish antenna at Stanford University in Palo Alto, California to monitor Soviet radar signals reflected off the moon, while the National Security Agency used the Arecibo Ionospheric Observatory in Puerto Rico to intercept signals that had originally been transmitted from a Soviet Arctic Coast radar.

[1] https://en.wikipedia.org/wiki/Arecibo_Telescope#Design_and_c...

[2] https://www.thedrive.com/the-war-zone/37898/collapsed-arecib...

[3] https://steveblank.com/secret-history/

[4] https://nsarchive2.gwu.edu/NSAEBB/NSAEBB479/

Thanks, this actually explains the "turning" component of the bank effect much more intuitively (to me anyways).

I think Dylan would be (perhaps ironically) the Newton in this analogy. (or maybe General Magic?)

Pioneering and ahead of its time in many ways, but for whatever reason it seems that the use of multiple dispatch in Dylan seems to have not (yet?) led to the same level of ecosystem-wide composability.

In this context, I think there might be an argument to be made that Julia is to multiple dispatch (or multiple dispatch + JAOT) as the iPhone is to “touchscreen computers that can make phone calls”.

It’s not that it’s the first, but it seems to be the first where the use of multiple dispatch throughout the community was sufficiently pervasive to kick-start the emergence of the strong network effects we’re now seeing w/r/t composability.

I would not be surprised to see more languages working to emulate this kind of combination of multiple dispatch and JAOT compilation in the future.

Currently you can make a relocatable “bundle” / “app” with PackageCompiler.jl, but the bundle itself includes a Julia runtime.

Making a nice small static binary is technically possible using an approach similar to what GPUCompiler.jl does, but the CPU equivalent of that isn’t quite ready for primetime.