6 ms·

Yeah this is basically why I keep trying and bouncing off Julia. I understand the real performance reasons why you'd choose to use Julia but the syntax is the p

Yeah this is basically why I keep trying and bouncing off Julia. I understand the real performance reasons why you'd choose to use Julia but the syntax is the perfect distance from python to make it extremely difficult to me. It's just close enough to get constantly confused. So if I really wanted to do much work in it I'd have swear off python - and I can't do that because for trivial stuff python is more convenient.

tombert 3y ago
I have not done anything even remotely significant in Julia, but the little I played with didn't seem to indicate to me that it would be bad for trivial stuff...what trivial stuff is hard in Julia but easy in Python?
- deleted 3y ago
  [deleted]
- Nanana909 3y ago
  I responded in detail him about, but honestly I can't think of many that answer your qiestion. It's amost always the opposite. A I like to present this as stereotypical example of the types of differences you find the two, IMO. Generating a 3x3 matrix of random booleans. >Julia A = rand(Bool,3,3) Python: No standard support for Matrices. I could really do it a disservsice and comapre the "core language", but that''s obivously stupid so we'll bring in some external libraries to make it easier. Of many ways to skin the cat here's one.. >Python import numpy.numpy as np gen = np.random.default.default_rng() B = gen.choice([True,False],(3,3)) I find myself just taking `rand(["Msg1",.....,"MsnN"])` to get a random string often. And small things like this are why you see people Julia is so nice to write and become so defendant of it.
- sundarurfriend 3y ago
  I think they just mean that with trivial projects, it's not worth trying them in a new language since the performance benefits are probably going to be minimal, and wouldn't really show off Julia's strengths.
  - tombert 3y ago
    That's fair; I have done my fair share of scripting in Node.js just because I'm familiar with it and it's fast enough to do most anything.
freilanzer 3y ago
I have done both complex and trivial stuff in both languages and Julia isn't more inconvenient for trivial things.
- cookieperson 3y ago
  Just make sure you find the appropriate documentation because the package changes it's syntax an awful lot over the past four years or so and there are lots of tutorials, videos, and blogs that don't apply anymore. Similarly make sure you research the ecosystem because everything in Julia is very fragmented, IE pandas.loadcsv will require two or more packages in it's Julia equivalent.
  - affinepplan 3y ago
    I notice you coming into every single thread about Julia to criticize the language and the community. Do you have a vendetta or something?
    - patrick451 3y ago
      The Rust Evangalism Strike force normalized the practice. This is what we do now.
      - cookieperson 3y ago
        ??? What's evangelical about pointing out that anyone interested in using dataframes jl should be aware that there is a lot of out dated content on how to use it and to be mindful of that??? It's honest and helpful.
    - hpcjoe 3y ago
      Back in my more perl-ish days, I recall pythonistas doing this. Sad to see little has changed.
      - cookieperson 3y ago
cookieperson 3y ago
Pretty sure dataframes jl isn't the fastest dataframes library out there. Think it's Polars, which has bindings in Rust and python. If I remember correctly the runner up is data.table. Similarly SQL/SQLite can often beat all of these So switching to Julia for speed in this context may not even make sense anyways...
- martinsmit 3y ago
  I agree with your conclusion but want to add that switching from Julia may not make sense either. According to these benchmarks: https://h2oai.github.io/db-benchmark/ https://h2oai.github.io/db-benchmark/, DF.jl is the fastest library for some things, data.table for others, polars for others. Which is fastest depends on the query and whether it takes advantage of the features/properties of each. For what it's worth, data.table is my favourite to use and I believe it has the nicest ergonomics of the three I spoke about.
  - nevereasonfroma 3y ago
    duckdb's fork, updated 2023.04 (h2oai is 2021.06): https://duckdblabs.github.io/db-benchmark/ https://duckdblabs.github.io/db-benchmark/ repo: https://github.com/duckdblabs/db-benchmark https://github.com/duckdblabs/db-benchmark
  - ChrisRackauckas 3y ago
    Indeed DataFrames.jl isn't and won't be the fastest way to do many things. It makes a lot of trade offs in performance for flexibility. The columns of the dataframe can be any indexable array, so while most examples use 64-bit floating point numbers, strings, and categorical arrays, the nice thing about DataFrames.jl is that using arbitrary precision floats, pointers to binaries, etc. are all fine inside of a DataFrame without any modification. This is compared to things like the Pandas allowed datatypes (https://pbpython.com/pandas_dtypes.html https://pbpython.com/pandas_dtypes.html). I'm quite impressed by the DataFrames.jl developers given how they've kept it dynamic yet seem to have achieved pretty good performance. Most of it is smart use of function barriers to avoid the dynamism in the core algorithms. But from that knowledge it's very clear that systems should be able to exist that outperform it even with the same algorithms, in some cases just by tens of nanoseconds but in theory that bump is always there. In the Julia world the one which optimizes to be fully non-dynamic is TypedTables (https://github.com/JuliaData/TypedTables.jl https://github.com/JuliaData/TypedTables.jl) where all column types are known at compile time, removing the dynamic dispatch overhead. But in Julia the minor performance gain of using TypedTables vs the major flexibility loss is the reason why you pretty much never hear about it. Probably not even worth mentioning but it's a fun tidbit. > For what it's worth, data.table is my favourite to use and I believe it has the nicest ergonomics of the three I spoke about. I would be interested to hear what about the ergonomics of data.table you find useful. if there are some ideas that would be helpful for DataFrames.jl to learn from data.table directly I'd be happy to share it with the devs. Generally when I hear about R people talk about tidyverse. Tidier (https://github.com/TidierOrg/Tidier.jl https://github.com/TidierOrg/Tidier.jl) is making some big strides in bringing a tidy syntax to Julia and I hear that it has had some rapid adoption and happy users, so there are some ongoing efforts to use the learnings of R API's but I'm not sure if someone is looking directly at the data.table parts.

tombert 3y ago

I have not done anything even remotely significant in Julia, but the little I played with didn't seem to indicate to me that it would be bad for trivial stuff...what trivial stuff is hard in Julia but easy in Python?

deleted 3y ago
[deleted]
Nanana909 3y ago
I responded in detail him about, but honestly I can't think of many that answer your qiestion. It's amost always the opposite. A I like to present this as stereotypical example of the types of differences you find the two, IMO. Generating a 3x3 matrix of random booleans. >Julia A = rand(Bool,3,3) Python: No standard support for Matrices. I could really do it a disservsice and comapre the "core language", but that''s obivously stupid so we'll bring in some external libraries to make it easier. Of many ways to skin the cat here's one.. >Python import numpy.numpy as np gen = np.random.default.default_rng() B = gen.choice([True,False],(3,3)) I find myself just taking `rand(["Msg1",.....,"MsnN"])` to get a random string often. And small things like this are why you see people Julia is so nice to write and become so defendant of it.
sundarurfriend 3y ago
I think they just mean that with trivial projects, it's not worth trying them in a new language since the performance benefits are probably going to be minimal, and wouldn't really show off Julia's strengths.
- tombert 3y ago
  That's fair; I have done my fair share of scripting in Node.js just because I'm familiar with it and it's fast enough to do most anything.

freilanzer 3y ago

I have done both complex and trivial stuff in both languages and Julia isn't more inconvenient for trivial things.

cookieperson 3y ago
Just make sure you find the appropriate documentation because the package changes it's syntax an awful lot over the past four years or so and there are lots of tutorials, videos, and blogs that don't apply anymore. Similarly make sure you research the ecosystem because everything in Julia is very fragmented, IE pandas.loadcsv will require two or more packages in it's Julia equivalent.
- affinepplan 3y ago
  I notice you coming into every single thread about Julia to criticize the language and the community. Do you have a vendetta or something?
  - patrick451 3y ago
    The Rust Evangalism Strike force normalized the practice. This is what we do now.
    - cookieperson 3y ago
      ??? What's evangelical about pointing out that anyone interested in using dataframes jl should be aware that there is a lot of out dated content on how to use it and to be mindful of that??? It's honest and helpful.
  - hpcjoe 3y ago
    Back in my more perl-ish days, I recall pythonistas doing this. Sad to see little has changed.
    - cookieperson 3y ago

cookieperson 3y ago

Pretty sure dataframes jl isn't the fastest dataframes library out there. Think it's Polars, which has bindings in Rust and python. If I remember correctly the runner up is data.table. Similarly SQL/SQLite can often beat all of these So switching to Julia for speed in this context may not even make sense anyways...

martinsmit 3y ago
I agree with your conclusion but want to add that switching from Julia may not make sense either. According to these benchmarks: https://h2oai.github.io/db-benchmark/ https://h2oai.github.io/db-benchmark/, DF.jl is the fastest library for some things, data.table for others, polars for others. Which is fastest depends on the query and whether it takes advantage of the features/properties of each. For what it's worth, data.table is my favourite to use and I believe it has the nicest ergonomics of the three I spoke about.
- nevereasonfroma 3y ago
  duckdb's fork, updated 2023.04 (h2oai is 2021.06): https://duckdblabs.github.io/db-benchmark/ https://duckdblabs.github.io/db-benchmark/ repo: https://github.com/duckdblabs/db-benchmark https://github.com/duckdblabs/db-benchmark
- ChrisRackauckas 3y ago
  Indeed DataFrames.jl isn't and won't be the fastest way to do many things. It makes a lot of trade offs in performance for flexibility. The columns of the dataframe can be any indexable array, so while most examples use 64-bit floating point numbers, strings, and categorical arrays, the nice thing about DataFrames.jl is that using arbitrary precision floats, pointers to binaries, etc. are all fine inside of a DataFrame without any modification. This is compared to things like the Pandas allowed datatypes (https://pbpython.com/pandas_dtypes.html https://pbpython.com/pandas_dtypes.html). I'm quite impressed by the DataFrames.jl developers given how they've kept it dynamic yet seem to have achieved pretty good performance. Most of it is smart use of function barriers to avoid the dynamism in the core algorithms. But from that knowledge it's very clear that systems should be able to exist that outperform it even with the same algorithms, in some cases just by tens of nanoseconds but in theory that bump is always there. In the Julia world the one which optimizes to be fully non-dynamic is TypedTables (https://github.com/JuliaData/TypedTables.jl https://github.com/JuliaData/TypedTables.jl) where all column types are known at compile time, removing the dynamic dispatch overhead. But in Julia the minor performance gain of using TypedTables vs the major flexibility loss is the reason why you pretty much never hear about it. Probably not even worth mentioning but it's a fun tidbit. > For what it's worth, data.table is my favourite to use and I believe it has the nicest ergonomics of the three I spoke about. I would be interested to hear what about the ergonomics of data.table you find useful. if there are some ideas that would be helpful for DataFrames.jl to learn from data.table directly I'd be happy to share it with the devs. Generally when I hear about R people talk about tidyverse. Tidier (https://github.com/TidierOrg/Tidier.jl https://github.com/TidierOrg/Tidier.jl) is making some big strides in bringing a tidy syntax to Julia and I hear that it has had some rapid adoption and happy users, so there are some ongoing efforts to use the learnings of R API's but I'm not sure if someone is looking directly at the data.table parts.