I switched to Positron a few months ago and have mostly found it seamless.
I'm an academic bioinformatician/data scientist and I mostly use R to do my data visualization and table wrangling. I use quarto documents. Before positron I used RStudio as well as VSCode with lots of extensions to add R functionality there.
My main gripes with Positron are no inline plots underneath code chunks, and some bugs where sending code to the console from code chunks occasionally stops working until restarting the program, and View() occasionally stops working. But the better file explorer, integration with Claude Code, and access to most of my VSCode extensions make it worth it for me.
The common answer to "why do you fork instead of building an extension" is "these are not possible with VS Code extensions". Is this true? Or is it easier to monetize when it is a fork?
It is true. Some things you can't build in extensions for VS Code are:
- core services (Positron's core language system is an API, and R and Python are extensions)
- native panes (you can contribute webview panes but they're slow!)
- toolbars for other panels, or global toolbars
- modal dialogs or any UI other than notifications and quick-pick lists
- custom layouts
At a higher level, Positron is a platform that contains data science tools for _other_ extensions to use, and doesn't make sense as an extension itself. The R and Python extensions are the first two we built, but the platform is extensible to other languages.
Another one is custom CSS (though it doesn't look like positron does that.) You can change styling properties like spacing and weighting as well.
I have a love/hate relationship with the VScode webview panels, but the message handler is not my favorite implementation in the world. I would love a way to send binary data, and get semantic token colors.
The only issue is that when you have a custom build of VScode, you have to manage a fork of VScode, and potentially pull in updates as VScode updates. How do you manage that?
It's a higher-level construct. LSP and DAP are both used by Positron! But they're a pretty small subset of everything you actually want to do with a language. For example:
- discover all the interpreters on the system for the language (e.g. 'find me all the Pythons')
- start an interpreter session for the language
- run a fragment of code in the language and return the result
- get all the variables in the current interpreter session for the language
- view data defined in a particular variable
etc.
We generally try not to invent new protocols; in addition to LSP and DAP, we use Jupyter messages and kernels for most of the above. Positron only has custom protocols/APIs for the bits that are outside the purview of existing protocols.
Mmh, all of these examples were done with vscode jupyter extensions... So they're definitely doable without forking.
Not trying to discredit the need for a fork though.
While you can technically do all of your examples (with extensions), it would likely mean that you'd have to either redesign the UX to limit it to where the extensions are good, or live with a somewhat unpolished user flow at times (because they're possible, but maybe not in the way the person imagining the UX wants.
Basically R studio/Spyder + Cursor built on the Code - OSS behind VSCode.
Potentially very exciting. The early builds a year or two ago that I tried were too buggy to replace R Studio, but a tight integration of good data tools, a good IDE, and modern AI coding assistants is going to be very powerful if posit nails this.
I've been using for over 4 months and I think it's great - both Python and R. Plenty of DS features that make VS Code feel more competent as data exploration tool.
This moving the goal posts of open-source to exclude anyone making money off of it is annoying. I can get the project for FREE and I can see the source code and make changes to it. How is it not open source? Because I can't also turn around and sell it?
It is not open source simply because it does not conform to the OSI definition of open source [1], which is what everyone understands open source to be. This license particularly places restrictions on how the software and derivative works can be used in hosted services ([2], links from their site.) And to your latter point, both free/open licenses allow commercial use; in fact, restricting commercial use would make the license non-free.
What is annoying is companies redefining these terms for PR, especially when they end up confusing the newer generations among the crowd.
...which makes is a non-starter for many academic settings:
```
Limitations
You may not provide the software to third parties as a hosted or managed
service, where the service provides users with access to any substantial set of
the features or functionality of the software.
There is no moving goal post. The license isn't an open source license, which by definition means the code is not open source. When you have access to source code of a program, but don't necessarily have the legal rights to distribute original and/or modified programs, it's called "source available".
I fear that's just the reality we live in. The things that make Julia great tend to be more advanced programming language features that are exciting to software engineers.
For your average data scientist or data analyst, though, it tends to look like a solution in search of a problem at best, and possibly just straight-up inscrutable. e.g., forget multiple dispatch, most my colleagues are already grumpy if they see @singledispatch in my code.
The only thing from keeping me from transitioning from RStudio to Positron is the lack of inline plots in Quarto files.
Is there any plan or consideration for this to be implemented? It's a wildly important aspect of mine and many other RStudio user's analysis pipelines.
It is among our most upvoted feature requests! It is under consideration. Inline output has proven to be a pretty divisive feature; a sizable proportion of users don't like input output at all and consider it a misfeature in RStudio. See e.g. https://github.com/rstudio/rstudio/issues/5280
Out of curiosity, do you prefer source or visual mode when working with inline Quarto output?
I prefer source mode when building Quarto files in RStudio.
Thanks for listing this feature request... It's pretty shocking to me to see that so many people don't use inline plots! I am particularly fond of them for ensuring that plot dimensions are correct so that I don't need to resize everything once I render a report and add it to my Quarto website.
From curiosity on my end - are inline plots a technically challenging problem? I have no idea if VSCode would enable something like this out of the box. :)
Inline plots are pretty challenging, especially in source mode since (so far) Positron mostly lets the Monaco editor surface do its thing. In visual mode, we've already got our own custom webview so there's an easier onramp.
1. Position has been on hacker news 2 months ago.
2. I don't think there are features in position that is not possible through a vscode extension.
3. I want `ark` to be able to be used as a standard LSP.
4. Position has absurb experience when coming to ai. It has to use 2 difference system to do tab completion and edit/ask/agent. The experience is also not good --- I mean, even not good as copilot.
i wish they had a more exhaustive list of all the features they offer beyond vscode or cursor, otherwise it's hard to evaluate what exactly it brings to the table.
For those of us that use vs code for coding but don’t do data science, could u tell us a bit about core extensions or things you do with vs code that goes beyond what an average day webdev would be doing with vs code. Eg what extensions to add to replicate like what this tool does.
For R+RStudio users, any opinions on the switch? Assistant seems to be the big departure, trying to work out if worth losing keyboard shortcut muscle memory for
I have a feeling that hardcore data scientists will continue to use RStudio because of the huge ecosystem there, while data engineers will continue to use VSCode which is, at least for me, good enough with a few extensions that let me run notebooks and data visualizations when I need to do data work. In other words, I'm not sure if there's a niche here.
The ecosystem is just R packages, right? There's also RStudio integration with e.g. rmarkdown, knitr, quarto etc. but presumably all of that can also come in positron.
Yeah, I'm a huge fan of rmarkdown & knitr, not sure if that's Positron compatible—I know that I get RStudio menus/dropdowns that come with those integrations.
(FWIW, I'm the technical lead on the Quarto project)
RMarkdown isn't going anywhere! Quarto exists to bring the RMarkdown experience that folks love to a broader set of users and contexts. It is true that we try to keep the .qmd experience in Quarto pretty close to the .rmd experience in RMarkdown, and it is true that Quarto does things that RMarkdown never will. But it's not the case that "RMarkdown is being phased out and replaced with Quarto".
As an R user coming from RStudio and VSCode, Positron's file explorer and Claude integration are tempting. The lack of inline plots and occasional console bugs are concerning though. The core services API approach is smart for extensibility!
This has been in beta for over a year, and unfortunately R users mostly seem to hold onto RStudio with a religious conviction so I haven’t really seen much adoption among the target demographic in my circles.
I switched to Positron a few months ago and have mostly found it seamless.
I'm an academic bioinformatician/data scientist and I mostly use R to do my data visualization and table wrangling. I use quarto documents. Before positron I used RStudio as well as VSCode with lots of extensions to add R functionality there.
My main gripes with Positron are no inline plots underneath code chunks, and some bugs where sending code to the console from code chunks occasionally stops working until restarting the program, and View() occasionally stops working. But the better file explorer, integration with Claude Code, and access to most of my VSCode extensions make it worth it for me.
The common answer to "why do you fork instead of building an extension" is "these are not possible with VS Code extensions". Is this true? Or is it easier to monetize when it is a fork?
It is true. Some things you can't build in extensions for VS Code are:
- core services (Positron's core language system is an API, and R and Python are extensions) - native panes (you can contribute webview panes but they're slow!) - toolbars for other panels, or global toolbars - modal dialogs or any UI other than notifications and quick-pick lists - custom layouts
At a higher level, Positron is a platform that contains data science tools for _other_ extensions to use, and doesn't make sense as an extension itself. The R and Python extensions are the first two we built, but the platform is extensible to other languages.
Another one is custom CSS (though it doesn't look like positron does that.) You can change styling properties like spacing and weighting as well.
I have a love/hate relationship with the VScode webview panels, but the message handler is not my favorite implementation in the world. I would love a way to send binary data, and get semantic token colors.
The only issue is that when you have a custom build of VScode, you have to manage a fork of VScode, and potentially pull in updates as VScode updates. How do you manage that?
What's different between Postiron's core language system and language systems like LSP and DAP?
It's a higher-level construct. LSP and DAP are both used by Positron! But they're a pretty small subset of everything you actually want to do with a language. For example:
- discover all the interpreters on the system for the language (e.g. 'find me all the Pythons')
- start an interpreter session for the language
- run a fragment of code in the language and return the result
- get all the variables in the current interpreter session for the language
- view data defined in a particular variable
etc.
We generally try not to invent new protocols; in addition to LSP and DAP, we use Jupyter messages and kernels for most of the above. Positron only has custom protocols/APIs for the bits that are outside the purview of existing protocols.
Mmh, all of these examples were done with vscode jupyter extensions... So they're definitely doable without forking.
Not trying to discredit the need for a fork though.
While you can technically do all of your examples (with extensions), it would likely mean that you'd have to either redesign the UX to limit it to where the extensions are good, or live with a somewhat unpolished user flow at times (because they're possible, but maybe not in the way the person imagining the UX wants.
Basically R studio/Spyder + Cursor built on the Code - OSS behind VSCode.
Potentially very exciting. The early builds a year or two ago that I tried were too buggy to replace R Studio, but a tight integration of good data tools, a good IDE, and modern AI coding assistants is going to be very powerful if posit nails this.
I've been using for over 4 months and I think it's great - both Python and R. Plenty of DS features that make VS Code feel more competent as data exploration tool.
Behold, a free-as-in-beer, source-available program that brands itself as "free and open source".
These guys' PR is trying too hard.
https://github.com/posit-dev/positron
The source code looks very open.
This moving the goal posts of open-source to exclude anyone making money off of it is annoying. I can get the project for FREE and I can see the source code and make changes to it. How is it not open source? Because I can't also turn around and sell it?
It is not open source simply because it does not conform to the OSI definition of open source [1], which is what everyone understands open source to be. This license particularly places restrictions on how the software and derivative works can be used in hosted services ([2], links from their site.) And to your latter point, both free/open licenses allow commercial use; in fact, restricting commercial use would make the license non-free.
What is annoying is companies redefining these terms for PR, especially when they end up confusing the newer generations among the crowd.
[1] https://opensource.org/osd
[2] https://github.com/posit-dev/positron?tab=License-1-ov-file#...
Not everyone, only those more religious about FOSS matters.
Nonfree license. You may or may not like the Elastic license but it's definitely not OSD.
...which makes is a non-starter for many academic settings:
```
Limitations
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
```
There is no moving goal post. The license isn't an open source license, which by definition means the code is not open source. When you have access to source code of a program, but don't necessarily have the legal rights to distribute original and/or modified programs, it's called "source available".
This is Jupyter but without Julia :(
(reference: Ju in Jupyter is Julia)
I fear that's just the reality we live in. The things that make Julia great tend to be more advanced programming language features that are exciting to software engineers.
For your average data scientist or data analyst, though, it tends to look like a solution in search of a problem at best, and possibly just straight-up inscrutable. e.g., forget multiple dispatch, most my colleagues are already grumpy if they see @singledispatch in my code.
Yet outside HN circles, Julia's adoption keeps going on, one research institute at a time.
https://juliahub.com/industries/case-studies
The only thing from keeping me from transitioning from RStudio to Positron is the lack of inline plots in Quarto files.
Is there any plan or consideration for this to be implemented? It's a wildly important aspect of mine and many other RStudio user's analysis pipelines.
It is among our most upvoted feature requests! It is under consideration. Inline output has proven to be a pretty divisive feature; a sizable proportion of users don't like input output at all and consider it a misfeature in RStudio. See e.g. https://github.com/rstudio/rstudio/issues/5280
Out of curiosity, do you prefer source or visual mode when working with inline Quarto output?
You can follow the Positron feature request over here: https://github.com/posit-dev/positron/issues/5640
I prefer source mode when building Quarto files in RStudio.
Thanks for listing this feature request... It's pretty shocking to me to see that so many people don't use inline plots! I am particularly fond of them for ensuring that plot dimensions are correct so that I don't need to resize everything once I render a report and add it to my Quarto website.
From curiosity on my end - are inline plots a technically challenging problem? I have no idea if VSCode would enable something like this out of the box. :)
An adjacent feature we're considering for that is respecting Quarto's plot dimensions when rendering to our own Plots pane:
https://github.com/posit-dev/positron/issues/3676
Inline plots are pretty challenging, especially in source mode since (so far) Positron mostly lets the Monaco editor surface do its thing. In visual mode, we've already got our own custom webview so there's an easier onramp.
Not exactly new, but I do think it has promise as a MATLAB replacement for Python. Spyder already does quite a good job at that though.
I think PyCharm does a pretty good job as being a MATLAB-like IDE replacement for Python.
1. Position has been on hacker news 2 months ago. 2. I don't think there are features in position that is not possible through a vscode extension. 3. I want `ark` to be able to be used as a standard LSP. 4. Position has absurb experience when coming to ai. It has to use 2 difference system to do tab completion and edit/ask/agent. The experience is also not good --- I mean, even not good as copilot.
Being able to install Gemini Code Assist is a big plus over RStudio.
I was wondering for a while already why Posit had seemingly dropped the ball on AI support in RStudio...
i wish they had a more exhaustive list of all the features they offer beyond vscode or cursor, otherwise it's hard to evaluate what exactly it brings to the table.
Yep, ill give it a try, but i dont see myself switching away from VSCode.
For those of us that use vs code for coding but don’t do data science, could u tell us a bit about core extensions or things you do with vs code that goes beyond what an average day webdev would be doing with vs code. Eg what extensions to add to replicate like what this tool does.
Just curious.
For R+RStudio users, any opinions on the switch? Assistant seems to be the big departure, trying to work out if worth losing keyboard shortcut muscle memory for
Positron has a setting that restores (most) RStudio keybindings, so your muscle memory should (mostly) transfer:
https://positron.posit.co/migrate-rstudio-keybindings.html
I have a feeling that hardcore data scientists will continue to use RStudio because of the huge ecosystem there, while data engineers will continue to use VSCode which is, at least for me, good enough with a few extensions that let me run notebooks and data visualizations when I need to do data work. In other words, I'm not sure if there's a niche here.
The ecosystem is just R packages, right? There's also RStudio integration with e.g. rmarkdown, knitr, quarto etc. but presumably all of that can also come in positron.
Not completely—as far as ecosystems there are RStudio addins, but I wouldn’t bet addins are extensively used
Yeah, I'm a huge fan of rmarkdown & knitr, not sure if that's Positron compatible—I know that I get RStudio menus/dropdowns that come with those integrations.
They're being phased out and replaced with Quarto.
(FWIW, I'm the technical lead on the Quarto project)
RMarkdown isn't going anywhere! Quarto exists to bring the RMarkdown experience that folks love to a broader set of users and contexts. It is true that we try to keep the .qmd experience in Quarto pretty close to the .rmd experience in RMarkdown, and it is true that Quarto does things that RMarkdown never will. But it's not the case that "RMarkdown is being phased out and replaced with Quarto".
Thanks for the correction!
I might be conflating rmarkdown with knitr because the developer of knitr (who was employed on some capacity by Posit) was let go.
For how long do you think Posit will continue to support both platforms?
As a former R studio user and current VS code user, I downloaded this… then I realized there’s no WSL support and realized it’ll have to wait.
For reference I’m on a small Data Eng/analyst team.
There is a pretty widely-used extension [0] for using Positron with WSL, if that's helpful to you.
[0]: https://open-vsx.org/extension/kv9898/open-remote-wsl
I understand the strategy isn’t to find a niche in the sense of a specific set of users, but to broaden and cover more niches
The niches exist (overlapping niches aside), but agree with the skepticism since I also wonder whether the switching cost is worthwhile for many users
As an R user coming from RStudio and VSCode, Positron's file explorer and Claude integration are tempting. The lack of inline plots and occasional console bugs are concerning though. The core services API approach is smart for extensibility!
It's really a shame posit quadrupled the cost of rstudio server/workbench because these tools are really nice in an academic hpc environment
Is there any reason to use it for general Python development over just VSCode?
I'll stick with spyder
Cool. I use AI to cook up custom interfaces for each project.
This has been in beta for over a year, and unfortunately R users mostly seem to hold onto RStudio with a religious conviction so I haven’t really seen much adoption among the target demographic in my circles.
Meh. Another vscode reskin. And calling it IDE is a bit presumptuous.
Dataspell is IDE.
named positron, based on electron. could you have come up with a worse name