Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Orion Project Termination

I'm only listed as a historical committer, so my vote doesn't count, but I agree that it makes sense to retire the Orion project.

Cloud runtime environments are complex, and this complexity makes it very difficult to have a single integrated tool for development, compilation/builds, and debugging.

Recent advances in generative AI may push development environments into the cloud, and away from locally installed tools, but I don't think this changes anything for Orion.

In any case, I enjoyed working on Orion with you!

Boris


On Fri, Sep 22, 2023 at 10:16 PM John Arthorne via orion-dev <orion-dev@xxxxxxxxxxx> wrote:
+1

It's fascinating to see echoes of Orion and its cloud IDE peers everywhere today, but I think in the end most potential users dropped the "I" from IDE because they are building software that can't be captured in a fully isolated environment. Browser-based code editors are more common than ever, but they are mostly used for browsing and simple edits. "Real" toolchains are networked, and once you've done that it's easy enough to attach a local editor to the end of it. Integrated debuggers have been split up between great observability tools against production environments, and rudimentary debuggers against unit tests or isolated service replicas.

I personally learned a lot from this project, and we built some great tech! My day job still involves building a browser-based plugin system using very similar technology to Orion. Assuming there are no objections, I'll take down http://planetorion.org/ when it next comes up for renewal. I miss working with you all! ✌

John

On Thu, Sep 21, 2023 at 5:41 PM Stephen Northover via orion-dev <orion-dev@xxxxxxxxxxx> wrote:

Hello all,

 

It's with a bit of a sad heart that I'd like to propose the termination of the Orion Project.

 

Eclipse Orion and the notion that an IDE should be in the Cloud was an idea that was ahead of its time.  For a start, developers love their desktops and their editors.  An IDE in the Cloud needs to be as customizable and flexible as on the desktop.  Ignoring the old IDE (or newer editor wars), the experience of using the IDE in the Cloud needs to be so compelling that developers would overlook the fact that it wasn't "XXX" and simply use it because, it was so productive.  Productivity comes from extensibility and plugins and these need to be there, but productivity also comes from an optimized development and debugging experience.  Setting up an IDE and debugger can be painful, and some developers simply don't do it.  That's where instant-on capability is needed.

 

There is also the question of where the IDE (editor, debugger) is running.  When you run an IDE on your desktop, your machine has everything you need to implement, test and debug as part of your inner loop.  You’ll need the same int the Cloud.  Next comes the thorny problem of where your micro-system is in the application stack.  If you are at the bottom of the stack, you can generally test and develop easily.  If you are at the top (ie. the UI), often you can play proxy games to insert your component in front.  If you are in the middle of the stack, you either need to insert your micro-service into a running application or run the entire application on your desktop.  The latter is generally not feasible for big projects.  The location of your development environment with respect to the application is always an issue.

 

Whether you are running in the Cloud or on the desktop, you face the same location issue when debugging.  If the IDE is running inside the target application in the Cloud, then everything is at your fingertips, but the application may be shared by others who will be affected by your debugger.  Further, micros-services are ephemeral.  If you are running a debugger in a sidecar beside a micro-service, it's ephemeral too.  An instant-on IDE solves this problem but does not take into account any state or tooling that is outside of the instant-on environment that you may have on your desktop (or in the Cloud, but not in the application).

 

What about remote debugging?  That is often painful.  It's fine for setting a breakpoint and inspecting values but making a code change often requires a rebuild.  Rebuild is part of your inner loop, you need all of your development tools handy.  You can rebuild locally and push out changes but that's not the same as being there.  This points out the obvious fact that development and debugging are not exactly the same thing, although they overlap.  You must debug to develop, but you also need to debug after you have shipped in live applications.

 

Technologies and IDE’s (editors) exist that address all the points I have discussed above and more.  Most IDE’s are full featured with tons of pluginsInstant-on is a very old concept and has been implemented in many different ways (container development, config files etc.).  IDE’s can be injected into running applications and strategies exist for hiding them from others in the running application.  It is possible to teleport your desktop into the cloud and have it behave like a micro-service.  There are multiple debugging strategies involving sidecar.

 

Unfortunately, Orion fell behind in the race to give programmers what they needed to be productive in the Cloud and did not address many of the issues and concepts I described above.  It’s time for the project to be officially retired.

 

Thanks,

Steve Northover

Orion Project Lead

 

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orion-dev

Back to the top