I have an ‘old’ model (iPhone 14 pro max) and text frequently misses characters due to the lag/input delay. It’s most pronounced when using safari for some reason.
In any case, it’s odd that hardware is multiples better yet it doesn’t always nail something as basic as typing
In my experience, iOS only misses keys during the time the keyboard is loading (which can be over a second- crazy!)
But I often have input lags where I will press several keys, and then a period of time (which can be multiple seconds) will pass before my taps are registered.
The 14 Pro Max launched less than four years ago, and should not be slower than an Android which launched a decade prior.
The article makes out like auto completion and help on hover are new things, but RStudio IDE has had them for years and years.
R/RStudio was my first language/IDE. I was horribly shocked when moving into other languages to discover they didn't have things you got out of the box with R/RStudio. "You mean I have to look up documentation for a function/method!?! - that's supposed to be automatic!".
R has a bunch of features which other languages lack to the degree that it's a rude shock to learn that other ecosystems lack them. One is the REPL with extremely convenient RStudio keyboard shortcuts to run lines of code (to achieve similar with ruby, I have an elaborate neovim/slime setup that took hours to configure and still isn't as good as RStudio gives out of the box).
A sign of a brilliant tool is when an idiot can get more done with it than an expert can with alternatives.
Maybe that explains why I was confused about this article. I kept wondering what exactly on offer, and that it couldn't be as simple as help on hover and auto-complete, because those seemed pretty basic and prevalent. It took me a few years to move to RStudio, but at this point, I literally don't know anyone who doesn't use it. To the point that I once had to explain to a labmate that R and RStudio were, in fact, not the same thing.
So either this is not that exciting, or else the additional things that are on offer are not very clearly explained to the point that I missed them.
I suspect the main benefits are portability (since tree-sitter uses wasm and javascript it can run in any webpage - compared to the previous way of parsing R code which needed an R runtime, so not just any old website could do it; e.g. a shiny app probably could because it has an R runtime available but a standard HTML page couldn't). And the other is tree-sitter is a widely used tool so now anything that uses tree-sitter can now work with R, since the R grammar is available.
Looks like R's tree-sitter grammar has been in use for GitHub search for a while (since 2024), so it's a nice improvement due to R/tree-sitter, although we've probably been benefitting from it for a while already, perhaps without knowing exactly how it worked!
In my opinion, RStudio is still the best data science IDE and it's not even close. I've been using Positron a bit more lately just for Claude Code reasons, as I prefer having the pane itself rather than using the terminal, but man it's really tough to shake RStudio. Even with the work put into configuring VSCode to get it kind of close to it, it still just always feels a bit janky.
Emacs + ESS is superior IMO. RStudio has a bunch of frills I don't care about and doesn't let me configure files as I'd like. ESS showing the function signature in the minibuffer to me is the killer feature. Wish I could get that for EVERYTHING.
What if you want to share something outside of your precious IDE?
- Merge request on GitHub
- Presentation with reveal.js (kind of like PowerPoint)
You'd be stuck with either bland, uncoloured, text-only characters, OR with a fuzzy PNG screenshot where you can't zoom or copy. Or maybe you "parse R" with Regex.
tree-sitter integrates into any web-based technology, allowing you to _share_ code.
Yes, your comment really should be the focus of article, i.e. genuinely new capabilities and improvements, not existing capabilities done a slightly different way. In any case it’s a minor nitpick and it’s awesome progress for the language and tooling
The ESS package in Emacs has also had several of these features for R for a long time. The difference here is portability and generality. Tree-sitter is a partial solution to the n×m problem, and now R has been invited to participate in that solution. That's something to be celebrated, even if it doesn't have immediate impact on our day-to-day, because it means future innovations in tooling for programming languages get automatically shared to R, instead of having to be reimplemented.
(The n×m problem is that for n languages and m tools like autoformatting, etc., we need an implementation for each tool specific to each language. With tree-sitter, we get n+m implementations instead: generic tools that work across multiple languages.)
> Its best-known use is in certain orders of Classical columns that diminish in a very gentle curve, rather than in a straight line as they narrow going upward. The human eye would allegedly perceive that the middle of the column was diminishing in a concave curve halfway up the column, and entasis corrects this.
Good analogy because they compete for patronage and talent to an degree, but (just like vim and emacs) the user can choose which tool is best for the job, including learning and using both at the appropriate times, so in a way they're perfectly complementary.
Thanks. Until you pointed out it's Earth at night, I had no clue what was supposed to be special about this photo (it appeared suspiciously pixelated for something 'high res', and neighbouring pixels seemed to contrast in colour rather than smoothly complementing as most photos do - but I guess that's random patches of city lights being captured by the camera). Cool stuff!
Something I haven't figured out is: what is that yellow/whitish smudge toward the center of the earth? It looks like camera glare or a reflection?
Why don't companies with chronic outages mimic their stack from top to bottom (i.e. starting with a new domain), then before making a change, make the change on the duplicate stack and blast it with mock requests.
Might catch 90% of problems before they make it into the real stack?
E.g. every step of GitHub's migration to Azure could be mimicked on the duplicate stack before it's implemented on the primary stack. Is this just considered too much work? (I doubt cost would be the issue, because even if it costs millions, it would pay for itself in reduced reputational damage from outages).
EDIT: downvotes - why? - I think this is a good idea (I'd do it for my sites if outages were an issue).
Downvotes are probably because that is what companies without chronic outages do.
If you'd ever worked on a codebase as terrible as I imagine GH's internals are and looked at the git history, you'd find two things:
1) fixing it would require rolling back 100's-1000's of engineer-years of idiocy that make things like testing or refactoring untenable
2) many prior engineers got part of the way through such improvements before leaving or being kicked out. Their efforts mostly just made it worse, because now you never know what sort of terribleness to expect when you open an unfamiliar file.
> EDIT: downvotes - why? - I think this is a good idea (I'd do it for my sites if outages were an issue).
Because that's a monumental amount of work, and extraordinarily difficult to retrofit into a system that wasn't initially designed that way. Not to mention the unstated requirement of mirroring traffic to actually exercise that system (given the tendency of bugs to not show up until something actually uses the system).
Agree, but look at the alternative; GitHub is constantly being savaged by users who (quite reasonably) expect uptime. Ignoring impacts on morale and reputation, damage to their bottom line alone might tens (hundreds?) of millions per year.
> mirroring traffic
yeah, I agree that's difficult, but it need to not be exact to still be useful.
reply