Live data from Hacker News

Julia adoption keeps climbing

hpcwire.com

151–160 of 309 posts

Re: Julia adoption keeps climbing

#151
post #76

My gripes, feel free to disagree: 1. Julia uses base-1 indexing. 2. Julia uses an "end" keyword everywhere, which is imho too verbose (and the corresponding "begin" is missing so it's inconsistent).

Any ALGOL language user (or derived ones) will feel right at home with those issues.

Re: Julia adoption keeps climbing

#152
post #66
post #63

It’s extremely silly, but I don’t really like the name Julia for a programming language. It’s just a bit uncomfortable to have a programming language with a particular, kind of formal-sounding human name like Julia (or like Michael, Lauren, or Jonathan). It just feels weird to me. I know a number of people (family, friends, colleagues) named Julia. I honestly think it could have an effect on adoption. People have to…

What about "Ada", "Miranda" or "Haskell"? First names, too, albeit ones much less common these days. ("Linda" the language isn't even in that category, popularity-wise, although the source of the name seems to be a weirder story)

You forgot Pascal. :)

Re: Julia adoption keeps climbing

#153
post #105

Earlier quoted context omitted.

I said something similar in another thread, but for me it doesn't have to be better than Python, as that is largely going to be subjective, the package ecosystem just has to grow and have some offering, at all, for the things that I do. https://fluxml.ai/Flux.jl/stable/ Is still very barebones compared to Torch/TF/Flax and I would be hamstringing myself by switching to Julia even if I find the language otherwise attr…

Maybe keep an eye on this issue: https://github.com/FluxML/Flux.jl/issues/1431 They are going for feature parity with pytorch hopefully in the near term.

Thanks for this, I will definitely follow along there. Yeah if they can just check a few of those boxes I'm much more likely to at least try to more regularly work with Julia.

Re: Julia adoption keeps climbing

#154
post #137

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

Another big thing that R has an edge over python (and I guess Julia, but not sure) is making quick yet presentable plots of data that contain different factors that you want to show together. The matplotlib equivalent requires tracking different indices and manually adding layers for different indices.

Julia has plenty of plotting solutions that are better for stats than matplotlib:

https://github.com/JuliaPlots/AlgebraOfGraphics.jl https://github.com/queryverse/VegaLite.jl https://github.com/JuliaPlots/StatsPlots.jl

Re: Julia adoption keeps climbing

#155
post #33

Earlier quoted context omitted.

> and is overtaking the python/numpy combo in that niche No, it's isn't. Julia is growing but it's far from overtaking Python at this point. > For other areas, like web programming, there is no sign of Julia replacing Python in the forseable future. That's where Go comes in.

First Go needs to offer comparable stacks to .NET and Java offerings, not only their platforms languages, but also their guest ones. And yes, there are ways to AOT compile as well.

It's all about which "bubble" you're in. Many people posting here work for startups using micro services (for which Go is a decent fit) and for companies close to the whole Docker/Kubernetes ecosystem, which is based on Go. So naturally they assume Go is huge.

My anecdata kind of tells me that Go is reasonably big, but it's not yet near .NET and Java, worldwide. But it could get there in a few years, I've seen/heard about some enterprises adopting it.

Re: Julia adoption keeps climbing

#156
post #102
post #93

Earlier quoted context omitted.

It's not meant for web, it's meant for scientific computing. And it has already left a mark on that field.

Then Julia should stop describing itself as a general-purpose programming language.

I think its website makes it pretty clear that it's mostly targeting scientists...

https://julialang.org/, https://docs.julialang.org/en/v1/ (The first two words of the Introduction are literally "scientific computing".)

Re: Julia adoption keeps climbing

#157

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

If we removed dplyr, then R scripts would absolutely scream so I find the speed argument for 'why switch to X' unconvincing. If users cared so deeply about speed, almost no one would be using tidyverse instead we'd all be using base-R or data.table.

Multiple dispatch? Hmm is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some quick plots and perhaps building a model to test something out. If the goal of Julia is to replace R/Python then their priorities feel way off the mark

Re: Julia adoption keeps climbing

#158

Earlier quoted context omitted.

Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche. In addition to being considerably faster than python, it also has quite some innovative libraries in the area. This can also extend into machine learning, where python has been the go to language, despite its limitations. For other areas, like web programming, there is no sign of Julia replacing Python i…

It's not overtaking at all. It's seen growth in some areas. The issue with regards to web programming/other programming is important, because sometimes it's useful to make a website/build another tool as a scientist. Python can do both easily.

So can Julia:

https://github.com/plotly/Dash.jl https://www.youtube.com/watch?v=uLhXgt_gKJc https://github.com/GenieFramework/Genie.jl

Re: Julia adoption keeps climbing

#159
post #129

Earlier quoted context omitted.

I also like pipe syntax and I've found there is nice support for it in Julia. There are some nice packages to improve it over base [1]. Have you checked queryverse [2]? [1] https://github.com/jkrumbiegel/Chain.jl [2] https://www.queryverse.org

I haven't heard of queryverse, thank you for that. This also brings up a good point I wanted to highlight. I get that Julia is a young language with a growing ecosystem. But the lack of "one obvious way to do something" may scare new users away. "I want to quickly wrangle data. Do I use Query.jl, DataFramesMeta.jl, SplitApplyCombine.jl or something else?" "I need pipes to help me wrangle data more efficiently do I us…

I mean I get yout point. Julia has a bit of a Lisp's Curse http://winestockwebdesign.com/Essays/Lisp_Curse.html Writing a performant and easy to use data wrangling library for R is a bunch of work and means dealing with C/C++ etc. So few people are willing to do so, and just contribute to a small number of libraries like dplyr. (I feel like there are at least 2 other major compeditors to that in R?) Where as in julia it's really easy to write a new data wrangling library. Its just not that much work. So people: A) do it for just fun / student projects (None of those ones are though). B) do it because they have a nontrivially resolvable opinion (e.g. Queryverse has a marginally more performant but marginally harder to use system for missing data)

Nice thing about julia, especially for tabular data (thanks to Tables.jl), is everything works together. It's actually completely possible to mix and match all of those libraries in a single data processing pipeline. Which while is generally a weird thing to do, it does mean if you have a external package uses any of them it works into a pipeline of another. (One common case is that queryverse has CSVFiles.jl, but CSV.jl actually is generally faster, and you can just swap one for ther other, inside a Query.jl pipeline)

I absolutely argee this makes learning harder.

---

Also that particular example:

> "I need pipes to help me wrangle data more efficiently do I use Base Julia, Chain.jl, Pipe.jl, or Lazy.jl?"

It's piping. Something would have to massively be screwed up if any of those options were more or less efficient than the others. The only question is what semantics do you want. Each is pretty opinionated about how piping should look.

Re: Julia adoption keeps climbing

#160
post #105

Earlier quoted context omitted.

I said something similar in another thread, but for me it doesn't have to be better than Python, as that is largely going to be subjective, the package ecosystem just has to grow and have some offering, at all, for the things that I do. https://fluxml.ai/Flux.jl/stable/ Is still very barebones compared to Torch/TF/Flax and I would be hamstringing myself by switching to Julia even if I find the language otherwise attr…

But can Torch/TF/Flax do autodifferentiation on constants ordinary functions? No they cannot!

Flax/jax can :)
Post reply on HN