[CoreyFieldens]

Everytime Julia is mentioned on HN, I see a surprising amount of people who dislike the language for whatever reason. I understand a lot of their concerns (time to first plot, debugging sucks, IDE support isn't amazing yet). However, I don't see a lot of alternatives for the niche that Julia occupies. If you want to do high performance scientific computing, there aren't a lot of options in terms of languages.

Python is the de facto but it's so slow for anything that can't be well represented as vectorized NumPy operations. There are ways around that like Numba, Jax, Cython, etc. but their use cases are pretty limited, and they don't work well with other Python packages.

There is, of course, C and C++ which are commonly used to speed up Python or as standalone packages. However, C++ is such a complicated beast that writing performant and correct code takes forever. C is much more manageable, but I find that there are not a lot of scientific packages written in pure C. This isn't even touching on the horrendous build system that is CMake.

Fortran is a pretty simple looking language and would probably be the closest to Julia in terms of speed and expressiveness, but the writing is on the wall and Fortran's days are numbered. I am not aware of many new packages being developed using it.

Other than that, there's languages like Rust and Go but those have ecosystems that are so small, they make Julia's ecosystem look like Python's. I really don't want to spend my time as a grad student writing basic numerical libraries from scratch.

[quanto]

> Fortran is a pretty simple looking language and would probably be the closest to Julia in terms of speed and expressiveness, but the writing is on the wall and Fortran's days are numbered. I am not aware of many new packages being developed using it.

Nothing could be further from the truth. Fortran, both the language itself and the packages in the ecosystem, is continually developed. There are a few peer-reviewed studies that quantitatively tracked Fortran usages and concluded that Fortran is not just for legacy code -- people actually continue to write new packages precisely for the reasons you mentioned (expressivity, performance)

[CoreyFieldens]

Could you link to some of those papers? I would be interested in learning more about the frontier of Fortran development. I recently learned about the LFortran project and while I think it's an interesting project, I feared it would be too late for the language.

[pjmlp]

I guess one thing would be to catch up with all the ISO releases since late 90's.

"Modern Fortran" book would be one way of doing it,

https://www.manning.com/books/modern-fortran

[zorked]

Fortran is a case of a language that has grown below the trend of the industry. There are probably more active Fortran projects and developer now than at any point in history. But it became a smaller piece of the much larger pie so people think it's "dead".

Same goes with Perl - probably more Perl developers than at its heyday in the 90s but a smaller chunk of the overall picture. Measure by noise levels and anything that doesn't explode seems to be dying.

[QuadmasterXLII]

If Julia gets to where it wants to be, pretty soon there will be tasks for which there is no practical alternative to Julia. At this point, people will be in some sense forced to use it, and the floodgates of hate will open (see javascript, matlab, cmake, cpp). Maybe this is the warning trickle?

[culi]

You're describing the current state of Python. Julia is kind of a response to Python. Python's become the de facto for ML and dataviz. Two things it's kind of a terrible tool for

I'm sure people will become more critical of Julia if it successfully becomes the de facto for those things but there's a big difference in that Julia is very focused on those things whereas Python is trying to be as general purpose as possible

[culi]

Tangent, but tbh I really don't see what the future of Python is. I don't understand why we don't just teach JS or TS as a starting language. It has about as much baggage and is about as easy to understand as Python and is the only language with a comparable ecosystem. Plus you also get to learn the language of the web for free. And now that you have stuff like deno that can run typescript without any messy dependencies. You can just make a quick ts file and write your webscraper or proof of concept and run it in the terminal. At least personally, that replaces my primary use-case for Python and I get to take advantage of TS's amazing type system which really comes in handy when dealing with external APIs.

I really don't see a place for Python

  ml --> Julia, C++, R
  dataviz --> R, JS/TS
  beginner-friendly --> JS
  web --> JS
  want a backend framework but wanna choose a language that's easy to hire for --> TS, Ruby
  huge, stable community --> JS/TS
  quick scripts --> Deno
  systems --> Rust, C++, Java, Go

I'd say it still dominates in scripting/webscraping and creating shareable work (e.g. Jupyter), but I'm just pointing out that at this point it's replaceable in those areas

[veqq]

> I really don't see a place for Python

I agree. Around 2008, I was drunk on "the zen of Python", considering myself a Pythonista, writing elegant solutions, making unmaintainable one liners etc. But really Lisp was so much better for that power/speed of development. Eventually (for me) go was so much more powerful, easy to maintain etc. with actual industry usage (seemingly instantly) without any loss in productivity.

Python solutions seem no better than maligned JS solutions nowadays - but at least there's TS and efforts to improve it where they can. Indeed, most Python code doesn't seem to be in proper production, but just one of exploratory scripts and pieces strewn about in notebooks. It seems like it could easily lose market share quite quickly.

[aragilar]

The moat for JavaScript is web-frontend, otherwise it would not be used (note the current rewriting of most of its tooling into non-JS languages). I would not call it beginner-friendly, stable, or good for quick scripts (does node come with sqlite?). I've yet to see a stable equivalent to django/rails. Javascript's data visualisation comes from it being in the browser, which has severe limitations (e.g. the need for WASM), and it's usually much easier if you don't need to two languages to do analysis (as the JavaScript numerical and data format ecosystem is a mess).

Python's advantage is apart from web-frontend (I have no expectation PyScript will catch on), it is everywhere, even when you don't expect it to be (e.g. Bank Python, VFX, Postgres, build systems, scripting interfaces in apps). Are there better options for specific usecases? Yes, but it's when these usecases intersect that Python wins out.

[culi]

> I've yet to see a stable equivalent to django/rails

... express? Has better benchmarks than both those frameworks, is probably more commonly used today (more employable), and has the benefit of TypeScript which fixes the biggest issues with both Python and Ruby (lack of a good type system)

> Python's advantage is [...] it is everywhere

Yes, that's my point. That's it's only advantage. But JS is better setup to become the "just use it because everyone knows it" language imo.

[aragilar]

Having used express, and being shocked at how bad it is, no, express is nowhere near equivalent django/rails (flask, the go to microframework for Python, is more complete than express).

TypeScript has two major issues (which it shares with Python's type annotations): it has to interact with untyped code (so what you think it fine is not, especially when key libraries are not written in TypeScript), and it tends to increase barriers to modifying the code (unlike more functional languages, whose type system tends to be both complete and have less footguns).

As to JavaScript being more commonly used and known, that's dependent on where you're working (especially when it can be sandboxed off so that the majority of users don't need to deal with it, see plotly dash and R-shiny). I suspect having seen multiple examples of systems where JavaScript was used where it was entirely the wrong tool (and where for various reasons Python was the correct one, partially due to the difference in the library ecosystems), we'll see a slow retreat over time of JavaScript to its core areas (being front-end and server-side rendering of the front-end), as more people find that having two languages is a better choice, and rewrite/replace existing JavaScript services.

[kriro]

The key advantage of Python is that it's good enough at many things and that there is a giant infrastructure of libraries and a huge community (and thus tutorials, howtos, stackoverflow answers etc.).

You mention Julia/C++/R for ML. My counterargument would be that things like fast.ai exist, use Python and make the whole topic approachable. I also find it a bit hard to belive many people that don't come from a stats/other academic field background would readily pick R over Python for anything ML related. I personally never thought JS was very beginner friendly because setup was traditionally clunky. That has thankfully changed a lot.

You mention many things that are better in theory but in practice I need to get work done now. I'd probably rather write quick scripts in Python (or bash) than Deno for example.

It's probably also easier to hire for Python than Ruby at least I'm not convinced Ruby has a giant edge. Huge, stable community is also exactly what Python has.

Python also has mindshare in many niches for example in security many things are quickly scripted in Python (notoriously Python 2 in some cases). Go and Ruby are also used for a lot of tooling there.

At the end of the day, if someone from a non-programming background asks me what language to learn, I still recommend Python (because usually they either want to pivot into ML somehow or want to get some quick scripting done to automate something or want to scrape some data). If I were to teach my child, I'd probably pick what I consider the most fun and completely ignore employability (Elixir) and if I were to build a CS program from sratch I'd have to think long and hard. I might end on Rust or Go but JS would be in the running (depends if there's a big focus on embedded/osdev etc.).

At the end of the day, "pick whatever language gets the job done" is still the best recommendation in my opinion :)

[culi]

> The key advantage of Python is that it's good enough at many things and that there is a giant infrastructure of libraries and a huge community

Right that's exactly my point. But once that's gone there's not really anything left for it. JS is also good enough at everything and probably has a larger community and more stability given it's the language of the web. Def not there in terms of ML yet, but it can get there

> I'd probably rather write quick scripts in Python

Because you're used to it.

> It's probably also easier to hire for Python than Ruby

If we're talking backend, an even easier thing to higher for than both of them is JS/TS

> Python also has mindshare in many niches for example in security many things are quickly scripted in Python

Yup. Again, this is the momentum of its community, but not anything inherent to it

> "pick whatever language gets the job done"

I don't disagree that that language isn't usually Python today. I'm just saying all of its success is due to the community and ecosystem so I don't see any guarantee that this will still be the case many years from now

[disgruntledphd2]

> I also find it a bit hard to belive many people that don't come from a stats/other academic field background would readily pick R over Python for anything ML related

I agree with this, but actually suspect that it's a good thing. People without some experience of stats probably shouldn't be using ML, and if R use helps to identify these people, I'm all for it.

That being said, basically every company has standardised on Python, some for good reasons and others because of the PR Python has gotten through DL stuff.

[rtpg]

JS suffers way too much from a lack of a good comprehensive standard library and builtins. It doesn't even have list comprehensions!

I get thinking Python and JS are "kind of the same", but there are so many details that Python gets right and JS kinda falls apart on. Python's pervasive dunder methods means that you can look at objects in a REPL and get a good representation (try looking at any non-trivial Javascript object and it's a major pain). You can define equality. Operations _don't_ stringify by default (so dictionaries work like you think they should). And Python has blocking methods, which means that you can write code in a straightforward way.

There are a lot of things playing in JS's favor but especially as packaging stories get better it's hard to discount Python's ease of use relative to Javascript IMO. And all of this is kind of ignoring the fact that most people are _actually_ talking about Typescript when they talk about JS nowadays, because writing "raw" JS is so error prone that it would be very difficult to actually get serious work done in it without an extra lint phase (I say this as a huge TS proponent)

[culi]

> It doesn't even have list comprehensions!

JS actually did used to have list comprehension but it was deprecated because nobody used it. There's no need imo. .map, .filter, .reduce, and other array methods achieve the same thing with a nicer syntax imo

Also JS has undoubtedly one of the nicest anonymous function syntax with arrow functions. Something I constantly find myself missing when I'm in a python file.

> And Python has blocking methods

What does this mean? Isn't JS blocking by default? Both languages have async support that you don't have to use...

> it's hard to discount Python's ease of use relative to Javascript

Hmm I guess we just have different experiences with this. I can open up a quick text file anywhere on my computer, save it as a .ts file, import whatever library I want, use TS if I want it, etc and then just run it in the CLI with `deno run test_run.ts`

Feels pretty easy to me. And then you have _anything_ related to UI. Maybe it's just me but I never quite felt comfortable with GUI libraries in Python. With JS I can just make an HTML file and open it up in any browser and I have access to the most cross-platform UI API in the world: the WWW

> "raw" JS is so error prone that it would be very difficult to actually get serious work done in it

If you're trying to get "serious" work done you probably shouldn't be using either of these languages. Or if you are, you'd definitely have some linter set up for either one. Also, Python's typehints are nice, but it can't compare to TS. And if you don't wanna go all in on TS, you could always stick with JSDoc comments which get you 90% of the way there for small projects and have really great support in any modern IDE.

[rtpg]

> What does this mean? Isn't JS blocking by default? Both languages have async support that you don't have to use...

To be clear on this, because JS APIs prioritize non-blocking mechanism to the expense of everything else (related to it the original sin of how JS interacts with a browser IMO), everything has to become async, even though in practice a lot of this stuff is happening sequentially anyways.

See this example Playwright test [0]. awaits everywhere. Because of how await works as well (Rust got this one right with postfix await), suddenly fluent APIs become awkward. You no longer have foo.bar().baz() but (await foo.bar()).baz(). (await getResources()).map(f) is not beautiful in my eyes.

And the core thing is that almost no code actually relies on concurrency in practice! So much of this is a consequence of the problem of JS not having good yielding semantics, and its interaction with the DOM in general.

Is this the biggest issue in the world? I guess not, but I very much dislike the aesthetics of this fore smaller chunks of code. I would really like a model with implicit awaiting in ~all the places that it exists currently.

I do agree that JS's anonymous function syntax is nice, and I miss it dearly in Python. Though here as well, I think Python comes up on top with all of its argument/keyword argument strategies. I get the options dictionary pattern, but dislike it.

And UI stuff is of course ... well it's easier in Javascript (though it requires its own infrastructure). There's no ways around that.

Loads of serious work is done in both language, I just think that JS is missing a lot of table stakes features given that there's so much attention to it.

[0]: https://playwright.dev/docs/writing-tests#the-example-test

[poulpy123]

Except that you can use python in most of the use case you mention

  ml --> Python
  dataviz --> Python
  beginner-friendly --> Python
  web --> JS
  want a backend framework but wanna choose a language that's easy to hire for --> Python
  huge, stable community --> Python
  quick scripts --> Python
  high level system --> Python
  low level systems --> Rust, C/C++

[culi]

Yeah sorry if I wasn't clear. That was my point. These are all the areas where Python is currently used, but there are better options for all of them now

[klelatti]

I think the point of Python is that it covers so many of your use cases:

Beginner friendly -> Python

Then use for ml, dataviz, huge community, quick scripts, backend

Your migration doesn’t do that and I’d argue that JS isn’t as good as Python for a lot of those use cases anyway.

[xigoi]

You're calling the community that makes a new framework every nanosecond “stable”?

[mardifoufs]

More stable than python that's for sure. You could just go with react or node (depending on your use case) , pick a build tool, and be set for half a decade. That's absolutely not the case with Python, and I'm not just talking about the breaking changes that happen in some releases. You also don't get a mess of venv, conda environments, incompatible packages, having to use docker to deploy your app, etc. I use Python a lot, and I like it, but Javascript is much more stable as a platform for quite a lot of what python is generally used for.

[culi]

JS is more tightly bound as the "language of the web" than Python is bound as "the language of data science".

That's all I'm saying really. I would bet more money that JS is here 15 years from now than that Python is

[tomrod]

I think WASM will upend some of this.

[grahamas]

> I don't understand why we don't just teach JS or TS as a starting language.

IMO the main problem is pedagogical. JS is a vast sea of conveniences that contradict conventional programming practices. This is also the reason I hesitate to recommend R as a starting language, for all that it's the de facto language of statistical analysis. Both languages are hard to teach in a coherent way, because both have lots of gotchas and exceptions that aren't bad, per se, but in the aggregate impede understanding of fundamentals.

Just yesterday I was working with someone on fundamentals in R, distinguishing between literals, variables, and functions. He got the idea, and then we got to model specification (`lm(y ~ x)`) and I had to shrug and say, those "identifiers" are different. I shudder to think of trying to teach types with a beginning student in JS.

[lmm]

> I'm sure people will become more critical of Julia if it successfully becomes the de facto for those things but there's a big difference in that Julia is very focused on those things whereas Python is trying to be as general purpose as possible

I see that as more of a point in Python's favour than Julia's. IME languages that are designed as general-purpose languages tend to be better than languages that are designed for niche purposes, even within those niches. The things that make a language good require consistent, general thinking.

[culi]

Right but Julia is specifically built against the criticisms made about Python in those spaces. All I'm saying is within that space there's gonna be less to critique

[ska]

> but the writing is on the wall and Fortran's days are numbered.

They've been saying this since the late 1980s. Not that I think it's particularly lively, mind.

[eesmith]

For fun, I looked for even earlier examples. Here's a couple:

From "The Handbook of Computers and Computing", by Arthur H. Seidman and Ivan Flores, 1984, https://archive.org/details/handbookofcomput00seid/page/342/... :

> For many years, it has been popular to predict that FORTRAN soon will be a dead language, to be replaced by a "better" language. Despite the undeniable fact that there are more eloquent, rich and powerful languages available, FORTRAN continues to be used widely and, indeed, is still the most popular programming language for scientific and engineering applications.

From NASA Conference Publication 2055, Engineering and Scientific Data Management, 1978,https://archive.org/details/NASA_NTRS_Archive_19780025833/pa...

> Margaret White: ... I know FORTRAN is essentially a dead language, but there is a lot of FORTRAN around. Would you care to respond?

> Jim Browne: Is there anyone from IBM who would care to respond? The microphone is yours. Who is it? How many times has FORTRAN been buried?

[Moissanite]

> Everytime Julia is mentioned on HN, I see a surprising amount of people who dislike the language for whatever reason.

I am mostly indifferent to the language (love the Jupyter equivalent tool Pluto, dislike Pkg, love the simplicity of matrix operations, dislike being pushed towards the REPL...) - I am increasingly irked by the observation that in topics like this the Julia community comes out in force to downvote anyone who expresses a negative opinion.

[pavon]

I still prefer Matlab/Octave for numerical exploration, after initially being excited for Julia but later becoming disillusioned with it.

I’ve always found Matlab the language to be small and simple, with just a few oddities. The library is where most of the warts accumulated, but I’ve used it long enough to learn them. Performance is much better than python - very fast matrix operations and Java-like speeds for everything else, with comparable startup times.

[enriquto]

Octave is almost the perfect tool for numerical computing. Only problem is that loops are slow. Some millionaire out here should pay a "stallion" to write a good JIT octave interpreter and the world would be such a better place!

[martopix]

I always hear this "fast matrix operations" argument from Matlab users, but don't they both use BLAS? The difference can only be marginal

[JonChesterfield]

Re Fortran - it should be a really sensible choice for writing floating point themed python extensions. It has a usable standardised interface to C (as of... F2003? I think) so generating a stub that glues a fortran module onto python's C API would be straightforward. In ye olden days I wrote the numeric kernels and fortran and distributed them across machines in c++, wouldn't be averse to doing the same thing today.

Main argument against that is probably that it's possible to get the same sort of codegen out of C++ and fortran native programmers are somewhat scarce, though I'd bet on it being easier to teach to domain people than julia or c++.

[rgavuliak]

For me it's the fact that it's probably for over 10 years that I've been reading on how amazing Julia is and how it's going to become much bigger than Python in Data Science yet I've never seen any evidence of that. It gets tiring after some time and yet the Julia community keeps making these claims.

[gjadi]

What about nim for an alternative to Julia?

(disclaimer: I've used neither of them)

[Moissanite]

Nim is more of a Golang-Python hybrid; people like me who learned Python first find the Go syntax offensive and the focus on error handling to be very pessimistic and boring to write, but creating something with Python which you can just compile and distribute is a pain in the ass. Nim solves both problems nicely. Sadly it is too much of a minnow in terms of available packages, e.g. for things like mature cloud SDKs.

[planetis]

Nim has a scientific community https://github.com/SciNim which host many science related packages like plotting and nd arrays.

[stewbrew]

Java (or kotlin or scala) using arrow, spark, H2O etc.?

[prometheon1]

What about R?

[kaines]

And with that, what about data.table?

[EFreethought]

> Fortran's days are numbered.

I see what you did there.

[nigerianbrince]

It has one based indexing. That's because they're catering to matlab guys, not professional developers.

[syockit]

It's catering to Fortran developers. Matlab was also catering to Fortran developers (you can read up the history of Matlab). And I wouldn't discount HPC guys as non-developers.

[trenchgun]

That is a ridiculous argument.

[martopix]

It may be ridiculous, but I dislike it deeply and it's one of the reasons I don't want to switch.

[zorked]

I thought so too but it bothers a lot less now that the default style of iteration is "for x in y" instead of looping over indices. In fact I barely think about it.

And, yes, for math-y stuff that you are going to be reading off a book, it helps keep things more compatible.

[Moissanite]

I have confidence in Fortran continuing to exist in a useful state for my lifetime and beyond.

If Julia had evolved into a community-managed language in the same way that Python has, I would have a positive outlook on it - but I am nervous about the efforts to commercialise it (which mostly just seems to be a case of skimming value off of financial institutions). It is totally understandable why the creators went down this route, but I just wish they had been more idealistic rather than getting on the "everything is a VC-backed company" bandwagon. While I hope Julia continues to grow, I don't trust its longevity enough to put serious effort into using it for myself.

[adgjlsfhk1]

Julia is community managed. JuliaHub (previously known as JuliaComputing) does do a bunch of work on Julia, but doesn't "own" the language in the way Google does for Go. There are a number of Julia developers with exactly the same amount of control over Julia as anyone at JuliaHub has at a number of colleges and companies.

[Moissanite]

Sorry, not buying it. Entirely possible it is just a perception problem and not a real one, but the situation is just not comparable to a language like Fortran.

Google owning Go is a big downside, but I think people know that going in - also, Google makes no attempt to monetize the language.

[adgjlsfhk1]

The situation is very different from Fortran, but mostly in good ways. The Fortran standards committee's meetings aren't open to the public, and they publish a new version of the standard every 5 years that takes another 5 years for the compilers to catch up to (if they ever support the new version). In the Julia world, you just make a pull request on github, and if it's something that needs a discussion, it gets discussed in a meeting that happens every other week and is open to and takes input from anyone.