StefanKarpinski

This appears to be a set of benchmarks of how fast a brainfuck interpreter implemented in different programming languages is on a small set of brainfuck programs? What a bizarre thing to care about benchmarks for. Are you planning on using Julia by writing brainfuck code and then running it through an interpreter written in Julia?

Has been fixed since 1.5.

MIT doesn’t fund anything — that’s not how academic money works. The university doesn’t give out money, researchers apply for grants from the government, companies, or NGOs. The university then TAKES a huge cut of that money — it’s called “overhead” and it’s often more than 50%.

Initial Julia work at MIT was funded by some absolutely tiny grants for distributed linear algebra research. The total amount of funding that Julia has gotten via MIT is definitely orders of magnitude less than the salaries paid to Swift, Go and Rust developers by Apple, Google and Mozilla.

That’s a fair point. Something we’re very interested in is exposing libraries written in Julia without the full runtime, ditching the JIT or the GC if you don’t need them. It would be easy to write a libm replacement in Julia, for example, without using either of those.

Regarding talent, it depends on the kind of talent you’re talking about. Yes, systems programmers like Rust. On the other hand, needing to deal with a strict borrow checker excludes a very large number of people with numerical computing, data science and machine learning expertise (not all, but definitely most). So it cuts both ways.

Julia

It’s interesting to note and probably underappreciated how many of these safety issues are addressed simply by having a garbage collector — eliminating manual memory management prevents all of these kinds of bugs except for data races. Of course there are situations where you cannot afford a GC, but for how many programs is avoiding a GC worth all the additional language complexity? Preventing data races is no small thing, but this observation certainly suggests that the approach of GC + tasks & channels + a good race detector is more powerful than it is commonly given credit for — think about how much user-facing language complexity it replaces. This sounds like a pitch for Go, and to some extent it is, but Julia takes very much the same approach for the same reasons.

This seems too obvious to even comment, but timing the compilation of a no-op program doesn’t show much. The meaningful comparison would be compiling a C program that does the same thing as some Julia code with `gcc -O2`. Btw, you can also run Julia in `-O0` or even better `-O1` mode — Julia even uses these same flags at the command line. These low optimization modes are extremely snappy — time to first plot is no issue. Of course, if you want to run some compute intensive code, it’s much slower, which is why `-O1` isn’t the default.

This is not to dismiss the TTFP issue, just pointing out that your argument seems to be that gcc is faster than Julia, which is definitely not the case. Indeed, gcc is about the same speed as clang, which like Julia, uses LLVM. The way Julia uses LLVM is a bit different, but something would be very wrong if took Julia much longer to compile code with the same functionality as it takes gcc or clang. Julia spreads the compilation out over time, but when you do something complex, a lot of compilation happens all at once. However, a static compilation would not do this work any faster, static compilers just do the work in a separate phase rather than interleaved with execution.

Maybe you’re using the term loosely, but one definitely shouldn’t have to understand type inference to write working Julia programs. Unlike static type systems like Haskel or ML where inference is part of the spec, inference in Julia is just an optimization and doesn’t affect behavior at all.

Out of curiosity, what marketing material are you referring to? I.e. what is it that you find misleading, specifically?

If anything, I feel that the Julia website and manual focus more on technical computing than they ought to and could stand to spend more time on general computing matters for which the language is also well suited. I’ve been meaning to write a blog post entitled “Julia is a General Purpose Language” for a long time. Which I suspect you would take issue with, but that’s ok.

It also supports all kinds of HTTP requests and should be quite efficient and solid, being based on libcurl.

Yes, that is guaranteed.

Especially impressive that the first official version ships with such broad feature coverage! Really great work by Jacob.

That comparison makes no sense: fast_float parses floats whereas std::format and fmtlib print floats — they don't do the same thing.

Fails the "what is it?" test. I don't really care to dig around. Anyone want to enlighten me and all the others who read this who have no idea: what is a detection?

I’m kind of confused by your comment. What is it that you’re unhappy about?

Indeed, that is precisely the decision that must be made. Neither one is obviously correct. And once a decision is made and goes into a release, it cannot be unmade — we all have to live with it forever.

When things like this are left undefined, it's not to intentionally annoy you, as you seem to be taking it. It's generally because there are two or more reasonable possible behaviors and which one is correct hasn't yet been determined. In this particular case, there are subtleties because named tuples can be seen as ordered collections of values and as named associative structures. Deciding that kind of thing takes a lot of time and effort. If you feel that there is a preferred behavior that broadcasting over named tuples ought to have, it would be helpful to post that on GitHub.

And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.

As sibling posts have pointed out, you can do all of those things:

1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it.

2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideration, but the language lets you do this easily as well.

3. The https://github.com/JuliaArrays/PaddedViews.jl package implements exactly what you're saying Julia won't let you do.

If anything, Julia errs on the side of allowing you to do too many things! There are very few things the language really won't let you do.

True, I'm obviously biased, but at least I can attest to the intention: Julia has always been intended for general purpose computing with the additional (and very challenging requirement) that it be a general purpose language that's also excellent at technical computing, which turns out to be a remarkably hard additional requirement.

Out of curiosity, have you tried using Plots.jl from VS Code? If so, what's missing from that experience?

Julia absolutely is a general purpose language and has been from the beginning. However, there are plenty of languages that are fine for building websites, whereas there are no other languages with the combination of speed and usability that Julia offers in technical computing. It's a lovely language for doing all kinds of work and I personally mostly use it for non-technical computing these days — specifically to implement package management client/server infrastructure, which is mostly web + file system wrangling.

This "Julia marketing conspiracy theory" that many people on HN seem to believe is so bizarre. What big tech company do you think is behind this incredible, shrewd and presumably well-funded marketing campaign? Julia is the only new major programming language of the last decade that doesn't have a major tech giant backing it. Adoption and development are pretty much entirely grass roots. If you see a lot of enthusiastic posts about Julia on HN, that's because there are a lot of actual people out there using Julia who love it and write posts about it.

Negative indexing in Python is a dangerous design that hides bugs and causes incorrect programs to return garbage instead of erroring. If you have an incorrect index computation, instead of getting a bounds error, you get different indexing behavior. This makes it dangerously easy to write code that appears to work but computes nonsense.

Given your user name, that's a fitting perspective. I have a very different view: programming language design is applied psychology, not mathematics. Programming languages are the ultimate human-computer interface. It may be tempting to ignore the human side of that interface: after all that side is messy, incomprehensible, impossible to write neat proofs about, and almost as hard to publish tidy convincing papers about. Without the human side of programming languages, however, PL design is a fairly pointless endeavor — without the humans, we wouldn't need programming languages in the first place.

I fear that, for these rather tempting reasons, academic programming language research has fallen into the trap of treating PL design as a form of mathematics, ignoring the human side of the field, and as a result has contributed far less to the practical practice of programming in the past several decades than one might naïvely expect and hope. Academic PL has, for example, almost completely disregarded the wild success and popularity of dynamic programming languages. Instead, prominent PL researchers glibly dismiss dynamic languages as "unityped", ignoring that there is, in fact, a rich life of types in every language if only you shift your notion of types to match what the users of those languages actually mean by the term. Shouldn't more academics be interested in how and why this approach is so successful to see what can be learned from that success, rather than just dismissing it out of hand because it doesn't fit neatly into the theory?

We have seen a recent cross-pollination of ideas between dynamic and static programming languages resulting in the likes of TypeScript, Go and Julia—and these hybrids have been wildly successful. But none of this is coming from academic PL circles. It's coming form the people who view languages as tools and want tools that fit the hands of their human users, rather than designing beautiful but alien tools that don't fit human hands. Even heavily static languages like Rust that have become very successful, have done so largely by going against the grain of static language research.

So yes, academic PL does seem to have largely become a subfield of mathematics, but to that extent it has, it has also become as detached from actual programming as modern literary theory is from the practice of writing books that people want to read.

Julia isn't derived from Matlab either and was influenced as much by Ruby as by Matlab.

> it’s just your grandpa’s same old static multiple dispatch.

This is very much not the case. People are often confused about this — probably because the difference between static and dynamic dispatch in general can be confusing, never mind multiple dispatch, but also because they look so similar syntactically. They are, however, very different beasts. It's particularly worth noting that statically overloading function on argument types is entirely equivalent to putting argument types in the function name — it can be done completely mechanically (that's actually how C++ does it internally) and adds no additional expressiveness over C, which has no built-in dispatch of any kind.

Here's a discussion where someone was convinced that Julia was not actually doing dynamic dispatch, which has many posts which may help clarify the issue for you (or anyone else): https://discourse.julialang.org/t/julia-isnt-multiple-dispat.... There's a lot of posts expressing and addressing various aspects of this confusion, so it's hard to know which specific one to point to, but the bottom line is that despite the superficial similarity, static overloading and dynamic multiple dispatch are very different: the former is a purely syntactic convenience, while the latter is an entirely different language paradigm.

There are many fine languages that have used `end` to delimit blocks, including: Pascal — an elegant, classic language (and my first, personally); Ruby — another gem (get it). And yes, also Matlab, which is hardly unique in this respect.

I suspect that the title of the Ars Technica article was a reference to the talk title, which was a reference to many other pieces with similar titles, which are all ultimately references to the original one.

What happens when it's an operation that doesn't have magic fallback methods like the arithmetic operators do? Say the code is `max(400, n)` instead. Now what? The `max` function doesn't know about your special type, so the code fails. Magic methods simply don't scale: they solve this problem in a few very specific cases and nowhere else. With multiple dispatch, you have a completely general solution to this entire class of problems: you just define a new method of `max` that knows how to handle your new number type and everything works.