Hacker News Reader

"get passed over because companies decide to fund some new(er) shiny thing instead" is not a fair or reasonable assessment. Why would a startup that's racing against time and money decide to create a new language when something already exists that can meet their needs with just a little tweaking?

My post embeds my recent keynote at JuliaCon in which I lay out some of the shortcomings of the language, as I see it.

MLIR didn't even exist when Julia was created. A language that can really take advantage of MLIR, and is designed from the ground up for modern accelerators, is not something that can be readily created by tweaking Julia AFAICT.

> Why would a startup that's racing against time and money decide to create a new language when something already exists that can meet their needs with just a little tweaking?

Have you MET programmers? The idea that we/they would do this is not anywhere close to surprising.

Exactly. Lattner himself has been involved in some of this - Swift for Tensorflow comes to mind. I'm old enough to remember when Swift for Tensorflow was going to be the new ML language hotness: https://www.youtube.com/watch?v=drSpCwDFwnM and https://www.youtube.com/watch?v=s65BigoMV_I

> MLIR didn't even exist when Julia was created. A language that can really take advantage of MLIR, and is designed from the ground up for modern accelerators, is not something that can be readily created by tweaking Julia AFAICT.

MLIR is another level of intermediate representation that sits at a higher level than LLVM-IR. Should the Julia folks decide that MLIR would offer advantages for optimization it wouldn't be difficult for them to add in an MLIR intermediate stage - that's kind of the whole point of an IR. But again, that would take some development effort - if the kind of investment that Mojo was getting were available for Julia it would get done. Nothing about the language itself would need to be impacted, it's the mid and backend where MLIR can offer advantages.

Disagree that Julia solves the two-language problem, although it was a major step in that direction. It may currently solve it for specific roles (e.g. data scientists), but it does not solve it for general-purpose programming.

One specific example? Robotics and autonomous systems frequently use ahead-of-time (AOT) compiled binaries and libraries. You don't want your quadrotor / RC car / self-driving Tesla trying to perform JIT compilation while operating in time-sensitive scenarios. AOT compilation is a major Achilles heel for Julia--it's possible (with major limitations), but feels more like an afterthought than a core feature.

I can't see Julia scaling to general-purpose programming until its AOT compiling capabilities improve. JAX has some of the same drawbacks. I'm very interested to see if Mojo can fill the gap of AOT compilation with a reasonably simple syntax. (And yes, I am aware of Nim--I do wish its scientific ecosystem was more developed though).

This is a very good point. You must support AOT compilation if you are going to have a general purpose system. This was clear when Julia came out and I interacted with core developers communicating our experience with creating SciPy and the critical reliance on the AOT features of Fortran/C/C++ as well as the bindings to Python. I believe simpler spellings can be achieved (i.e. more unification between scripting, dynamic JIT, and foundational AOT use-case), but the ecosystem is not close to a one-language to rule them all scenario.

I've always felt that the choice to 1-index and favor mathematics over engineering has kept the engineers away.

You can build a fantastic language for mathematicians, but people outside that domain won't feel welcome or compelled to use the language to scratch their itches.

It'll just sit there. For math folks.

I don’t think “mathematicians” is the right category. More like scientists/engineers who would otherwise use Fortran and Matlab (both have 1 based indexing) to do number crunching. That’s actually a lot of people though writing quite a bit of code. It’s just they just don’t work in the software industry, and usually for them the code is not the work product.

I think the aspiration was to provide something that a Matlab user can immediately pick up, that is almost as fast natively as Fortran, that also provides features to do good modern software engineering if you want to. And it succeeds amazingly at this.

In my own view, adoption has not been wider because 1) most people don’t need speed so the trade offs with the compiler + using a weird language aren’t worth it, and more importantly 2) outside of some incredible software gems, the package ecosystem tends to be flaky and maintained by overworked academics in their spare time.

> outside of some incredible software gems, the package ecosystem tends to be flaky and maintained by overworked academics in their spare time.

That was the point I was trying to make.

This language is too esoteric and leafy for most hackers / engineers / enthusiasts to spend their spare time building support packages. They'll pick up something like Nim or Rust as a new language before they'll look at Julia.

By catering to mathematicians, scientists, and engineers, the broader population of software folks were excluded. Or, if "excluded" is too harsh, they at least weren't incentivized.

Because of this, the best parsers, serializers, protocol implementations, scrapers, web servers, and other assortment of important technologies get written in other languages instead.

I think you are right about this -- I just wanted to draw the distinction between mathematicians and the much larger population of scientists/engineers, who really do write a lot of code which is in its way "serious computing" even if it doesn't deal with any of the concerns and practices of "good software engineering".

(I also think Julia would be okay with the current level of support for the "computer sciencey" technologies you describe like parser and web servers and so on -- it's pretty good at calling out to C or C++ if needed. But even many of the scientific/numerical packages don't have the maintenance resources they really need, so are often "good but flaky". This situation does seem to be slowly improving though.)

"How do you xor two numbers in Julia?"

"a ⊻ b"

"... am I supposed to type (or copy paste) that symbol every time I want to xor two numbers? There must be a better way right?"

"Sorry, no."

I immediately gave up the language after this. Too bad, I really loved it and was looking forward to progress in DL stack in Julia at that time. Too math-y.

You can always just use `xor(a,b)`. Julia makes sure that there aren't any unicode operators that don't have an ascii equivalent (in Base at least). Also, most editors will allow you to type ⊻ as `\xor` and tab complete to ⊻.

La mayoría de humans ist gewohnt avoir mehr letters que clés de toute façon.

So you gave up the language after someone gave you a flat out wrong answer to a single question? That's too bad.

Julia has built in support for special characters like that by typing \charname<tab>. You have to remember the name but it's not all that hard to type.

> "... am I supposed to type (or copy paste) that symbol every time I want to xor two numbers? There must be a better way right?" > "Sorry, no."

This just false. From https://stackoverflow.com/a/60173810/2990344

help?> ⊻ "⊻" can be typed by \xor<tab>

If this is why you stopped using the language then you can't have spent more than an hour on it. \symbol<tab>

I assume you mean specifically software engineers?

Most traditional engineers are quite familiar with Matlab and Fortran.

I've never understood why some people seem to care so much about 1- or 0-based indexing. Literally who cares? I cannot comprehend actually refusing to use an otherwise-perfectly-good language just because the indexes happen to start at 1.

People care about difference things. There are probably people who don't give a rat's behind about stuff you care passionately about or irks you in some significant way. Does that invalidate your caring?

Because it’s wrong. Combinatorics taught me that, and I’ll be damned before I ignore what the universe keeps screaming at me

Julia didn't really gain momentum because syntax is offputting . When we started our first ML project in 2013 , we tried R, Julia , Python , and even at python with rugged ML libaries , we choose it because none of us liked other language syntaxes , coming from C++/Javas background. Then we fully falled in love with python.

2013 was early days for Julia.

still have the same syntax.

Ergonomic wise what holds Julia back other than the deployment story is that they refuse to adopt nims universal call syntax approach f(a,b) = a.f(b)

Why is that better?

Familiarity and more importantly discoverability:

If you type a. in the REPL or IDE you should get a list of all functions applicable to the object

Julia is not an OO language, and its functions dispatch on all function arguments, not just the first one.

Familiarity changes rapidly in the world of software development. But I do agree about discoverability.

However, I think the issue is rather that we need to find new discoverability systems that work for multiple dispatch rather than limit our languages to single dispatch because we can't come up with better ways to achieve discoverability.

Maybe (a,b)f would be better syntax.. or we could start writing backwards ;) but now we're getting into seriously unfamiliar territory.

Multiple dispatch might actually be superior for discoverability when we get this right because you can filter the method list based on all arguments rather than just the first one.

I'm pretty sure Nim copied that from D language.

As they always said, imitation is the sincerest form of flattery.

You can use my fork of vscode julia extension for this https://github.com/xgdgsc/julia-vscode/releases/tag/v1.41.1_...

Do you mean D-lang universal call syntax approach?

julia's syntax is weird.

As if that poses any problem to R, C++, Perl,...

R -> dying, Perl -> dead, C++ -> also dying. Although C++'s existing size will make its death a long-drawn-out process.

A matter of opinion.

All the programmers are slowly dying too, so maybe it's a good fit.

i've been reading about the upcoming death of perl and C++ for 25+ years now.

python's syntax is whitespace-sensitive and doesn't have curly braces around blocks

they did finally add assignments in expressions and conditional expressions, but every time i show a list comprehension to a java programmer they glaze over

so i guess some weird syntax is okay

How are python list comprehension in any way more weird than Java streams?

java streams don't exist in java syntax

we were talking about weird syntax, not weird semantics

List compréhensions exist in so many languages. Are we talking those "Java" programmers who only ever coded in Java?

> python's syntax is whitespace-sensitive and doesn't have curly braces around blocks

That's a good thing.

Not if you want to try out a copy fragment by copying it from editor into REPL.

jupyter solves this, but also you can prefix it with

    if 1:

and remove all its internal blank lines and add a blank line after it

More tedious editing when I just want to quickly try out a short code fragment. Perfect solution! So pythonic and full of "zen".

i didn't say it was a bad thing

my comment makes no sense if you read it assuming i think it's a bad thing

what it is is a weird thing

i thought you were being ironic with your own unique english syntax

but then i checked all your comments and sure enough it is pythonic english

weird syntax is okay and some punctuation may be redundant but it sure makes life easier for the eye

who cares about what java programmers think lol whatever they like should be treated with extreme suspicion

> python's syntax is whitespace-sensitive and doesn't have curly braces around blocks

that's a plus. the proof is in the pudding. one language has exploded. others haven't. the end.

i didn't say it was a bad thing

my comment makes no sense if you read it assuming i think it's a bad thing

what it is is a weird thing

> they did finally add assignments in expressions and conditional expressions

Consitional expressions were added in Python 2.5 in 2006.

yes, after fifteen years

assignment in expressions took even longer