I use both regularly, often together. A relevant question: what is more likely in the next 5 years, TV getting faster or DT code getting less esoteric and more intuitive?

Though it may cost you some $$$ github.com/Rdatatable/data.t… (I should borrow from that one for my matrixStats benchmark reports)

It's easy to read, if you know SQL. If not, you can crutch it with the tidyverse

Not really, if you know SQL it helps, if you don't, there's no need to learn it to use data.table. I have found data Table easier to use, and the speed just pushes it over the edge for me between the 2.

Do you use sqldf?

Relatively fair comparison. I think package number is a weird metric. Having date and reading funcs in data.table is good for simplicity, but tidyverse has been splitting out packages/functions for valid reasons too. Speed is clear. f-read is a f-reak. Readability favors tidy.

The tidyverse function can be written with a line of code less than the data.table function. However, still not faster.

Data.table is not that hard to read. I see no reason not using dtplyr at least. Data.table is fast! And I always teach data.table alongside tidyverse

Is the code buggy? in the comments you are aiming for 14 days and (as I read it & I may be wrong) you are getting 14 entries & there are days with multiple poll ends polls_2016 %>% group_by(end_date) %>% summarise(n_finish = n()) %>% filter(n_finish > 1) %>% arrange(-n_finish)

I felt there were alternatives to a database (join) approach that were optimised for slightly different situations, so I've done some response code here: github.com/thoughtfulbloke/t…