Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The world is a very heterogeneous place, and we're all immersed in our own bubbles -- each with its own assumptions and needs. "Data related" is a fairly vague description.

- It appears that there's substantial community effort invested in smoothing the pathway for scientific modeling and related ML. So that's one area where I expect anyone picking up Julia will see quick+substantial wins.

- Recent Julia versions (1.9, 1.10 on the way) have made tremendous progress in TTFX: https://julialang.org/blog/2023/04/julia-1.9-highlights/

- I happen to work on problems (with more of a computation/simulation flavor, rather than "data related") where Python is extremely painful and Julia happens to be the best fit by far (and rapidly getting even smoother!).

> I've had lots of intelligent people who use code as a tool instead of as a craft

Agreed -- so there's no point being fanatical about it. Folks can keep an eye out and periodically re-evaluate whether the ecosystem has reached maturity for their needs. For those who want to "use libraries", it will take a bit longer than those who want to "write libraries".

Julia aims to solve the two-language problem. If you live in Python and never have to touch another language like C or Fortran, then the value proposition of Julia is going to feel much more tenuous. But there are a set of people (library developers) who experience the ecosystem in the diametrically opposite way: https://twitter.com/dillonniederhut/status/16791406806799728...

> and generally not being a strategically adopted language by ML innovation groups.

I see the tremendous engineering effort being sunk to massage different (mutually incompatible) subsets of Python into some shape amenable for ML -- supporting new algorithms on top, and more efficient program execution at the bottom (translating from software to hardware).

I've heard the claim that it's sometimes better to delay a solution and let the users feel the pain before they open their minds to the solution. That is what I'm reminded of when I think of ML and Julia. If ML users don't see the value of Julia yet, that's okay -- they might once they dig themselves in deeper.

If they manage to solve all ML problems with Python (with C and what not), that's fine too! I think the world is a bigger place where there are also other interesting things going on, and Julia is helping a lot of people do things they couldn't accomplish otherwise :-)

--

There's no fundamental reasons for languages to "age", unless they happen to be tied to some unsuitable assumptions in how they model the world -- aspects that cannot be rearchitected without fundamentally changing the language. Barring that problem, languages only get more mature.

The problem with Python is not that it is three decades old, but that its revealed priorities (model of the world and software) is out of sync with many of today's needs. Even if we forget advanced things like ML, there's still a bunch of really basic stuff that make Python painful: https://twitter.com/dmimno/status/1679474354579488771

I think the design of Julia is much more robust in those aspects, but we also need to see how multiple dispatch plays out for very large codebases+teams. Meanwhile, I expect Julia will keep improving rapidly in the use cases it supports.



Excellent then that you agree that people who use Python as their coding language aren't necessarily Dunning-Kruger exhibits


Pro tip: you can identify who is posting by their username. If you are responding to me you left out the word 'only'. Even the guy you cited is calling you out. Time to slink away?


Parent comment here was not in response to you, but to ssivark's comment.

My point earlier was that people who solely use Python aren't DK exhibits in action simply because they know one language. Further, they may do so as a consequence of tech stack used in their roles or in their organizations. Given Python's adoption in the data domain, many people in the space use code simply as a tool to get things delivered.


And should not be relied on to suggest data formats that can be useful in other languages, as others in this thread have pointed out.

Python is useful for people who have no formal training, but they are leveraging off the work of others. I hope you can understand how experts do not attach much weight to people still trying to figure out how computers actually work.


And this point:

> experts do not attach much weight to people still trying to figure out how computers actually work

is a much weaker form of this point:

> It is impossible to have an intelligent discussion with someone who only knows Python, FSVO know. Dunning-Kruger in action.

The first point is true for anyone focused on a single language, outside of perhaps Assembly. The second is simply wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: