3 ms·

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-ben

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.
- chaxor 3y ago
  I really hope people don't come from R to Julia. People who use R are not good programmers, and will degrade the core of the language and it's principles. It would be a shame to see the equivalent of tacking on 6 different object oriented systems to a base language and fragmenting the community completely.
  - ChrisRackauckas 3y ago
    I'm not sure I'd have the same take. Yes, R as a language is kind of wonky and people who use R tend to not be good programmers. However, the APIs of some packages are designed well enough that even with all of those barriers it can still be easy to use for many scientists. I wouldn't copy the language, 6 different object systems and non-standard evaluation is weird. But there is a lot to learn from the APIs of the tidyverse and how it has somehow been able to cover for all of those shortcomings. It would be great to see those aspects with the data science libraries of the Julia language.
  - freilanzer 3y ago
    R users in the form of statisticians should definitely come around to Julia. More high quality packages never hurt. But I agree with fragmentation and 'object systems', yet I don't think this is a huge danger for Julia.
  - cookieperson 3y ago
    It might surprise you to learn that Julia is actively relying on code written in/for R to perform computations. You might be surprised to find out that people who can write R can also write C++ C and other languages of their choosing. You also might be surprised to learn that some of the most vetted statistical code exists in the R ecosystem. If I were someone recruiting for a niche language that had a weak ecosystem, personally I'd take all the help I could get. Can learn Julia with a background in any other programming language in a few weeks... The same can't be said about martingales... But you get to choose your strategy here...
    - shele 3y ago

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.

chaxor 3y ago
I really hope people don't come from R to Julia. People who use R are not good programmers, and will degrade the core of the language and it's principles. It would be a shame to see the equivalent of tacking on 6 different object oriented systems to a base language and fragmenting the community completely.
- ChrisRackauckas 3y ago
  I'm not sure I'd have the same take. Yes, R as a language is kind of wonky and people who use R tend to not be good programmers. However, the APIs of some packages are designed well enough that even with all of those barriers it can still be easy to use for many scientists. I wouldn't copy the language, 6 different object systems and non-standard evaluation is weird. But there is a lot to learn from the APIs of the tidyverse and how it has somehow been able to cover for all of those shortcomings. It would be great to see those aspects with the data science libraries of the Julia language.
- freilanzer 3y ago
  R users in the form of statisticians should definitely come around to Julia. More high quality packages never hurt. But I agree with fragmentation and 'object systems', yet I don't think this is a huge danger for Julia.
- cookieperson 3y ago
  It might surprise you to learn that Julia is actively relying on code written in/for R to perform computations. You might be surprised to find out that people who can write R can also write C++ C and other languages of their choosing. You also might be surprised to learn that some of the most vetted statistical code exists in the R ecosystem. If I were someone recruiting for a niche language that had a weak ecosystem, personally I'd take all the help I could get. Can learn Julia with a background in any other programming language in a few weeks... The same can't be said about martingales... But you get to choose your strategy here...
  - shele 3y ago