We will take your feedback and see what we can do.

You can view it here for nostalgia reasons: https://web.archive.org/web/20260828162646/https://coscreen....

I'm in Utah, and Till is in CA, so it's vital to our daily work.

Truly I don't understand how people do remote work or collaboration these days... maybe they don't? Or maybe Zoom/Meet are good enough (I really truly think they aren't, it's an abusive horrible experience every time I am forced to use Zoom or Meet for anything).

There just seems to be something sticky about them, but the people who try a CoScreen, Tuple, Pop, or other tool designed around collaboration I think become converted permanently, but getting people into that funnel is very very hard.

We can work on it. Obviously it's Till and I working on the copy, and unashamedly we are using Claude to help expedite it so we can focus on the fun stuff... but yes, I absolutely hate this crap too.

Maybe you can contribute some of your private innovations upstream to Petal ;)

It's on our product roadmap to have a mode to support this though.

Some of our engineers have discussed a totally p2p iroh based video transport and other ideas.

LiveKit was the fastest/easiest way to get it to market, and it was something Till and I volunteered to pay for at the moment so we have an off-the-shelf cloud offering that is free and usable.

From that perspective it has worked great.

Given CoScreen's very recent demise, we felt this space deserved some love still.

Hopefully you try it out some time, and provide feedback.

I’m Jason Thomas, one of the founders of CoScreen.

As some of you may know, Datadog sunset the CoScreen service on July 31st.

Four of us from the original CoScreen team have spent the last couple months building a free and open source pair programming tool inspired by those that came before us: It’s called Petal (https://github.com/kiruna-labs/petal)

Some history first, because when we started CoScreen we had hoped to break the sad and established pattern of this industry.

Screenhero was an exceptional tool that a lot of us loved for pairing. Multiple cursors, low latency, you could click your partner’s editor, and just start typing. It felt like magic while we had it. Then Slack bought it in 2015, and shut down the standalone app in December 2017.

When Till, Max, and I started CoScreen, we were aware of this history, and wanted to build an even more magical collaboration and screen sharing experience: the entire concept was “throw a window from your laptop up on someone else’s screen, and start collaborating with zero friction.”

Datadog acquired us in 2022, and thus began the great adventure of adapting our real-time technology into Datadog products, while also continue developing CoScreen as a standalone tool from the Datadog ecosystem. Datadog invested in the product for years and we’re thankful for that. But CoScreen itself proved, like so many other screen sharing tool acquisitions, to be too tangential from the customer base and core mission. We instead built other communication features in Datadog, the integrations with other video platforms, and also its wildly successful MCP server. We weren't the only ones. Around was bought by Miro and shut down in March 2025. Multi (formerly Remotion) was acqui-hired by OpenAI in 2024 and shut down about a month later. It's nearly always the same story: a small team builds something hard that people love, a platform buys it for the team or the feature, and the standalone product doesn't survive the integration. So we decided firmly to do things differently this time. Petal is completely free and open source and we aren't monetizing it. If we lose interest or get hit by a bus, you can self-host it or fork it, and nobody can sunset it on you. Honestly it's a love letter to everyone in this community that supported us, believed in us, and to liberate collaborative screen sharing from this vicious cycle.

We hope through this we can help foster a large and vibrant community around innovating in this product sector. What Petal does: shared windows show up as real windows on your desktop, movable and resizable, not tiles in a grid. Several people can share at once, everyone gets a labeled cursor, and you can click into any shared window to type and scroll. Rooms are persistent, so you click once to join "eng-sync" instead of passing links around. It runs on macOS and Windows (Linux is next, this time for real and you can help us!), plus a web app. Media goes over LiveKit. You can use our hosted instance with zero config, or point the app at your own LiveKit server with one docker-compose if you want the traffic to stay on your network or even use an entirely different video backend if you want to. The part that still feels strange to us: CoScreen took almost six years to build. The first version of Petal took under eight weeks, from scratch, with frontier models like Fable and Astra doing a lot of the work. Real-time video and window capture is some of the most unforgiving code we have ever written, so we didn't expect that. We will do a proper writeup on what worked and what didn't, and are happy to answer questions about it here. Till, Darren, Max and I will be in the thread.

Comments URL: https://news.ycombinator.com/item?id=50092470

Points: 227

# Comments: 41

Isn't the overhead for C++ exceptions quite significant, especially if an exception is thrown?

Exception handling can also increase the size of the binary because of the additional data needed to handle stack unwinding and exception dispatch.

I think a number of optimizations are made quite a bit more complex by exception handling as well.

Lies, damn lies, and benchmarks?

I can at least say, the performance difference between C, C++, and Rust, is splitting hairs.

If you want to write something performant, low level, with predictable timing, all three will work.

I'm spending a lot of time building projects with Rust & C++ these days. The issue/tradoff isn't performance with C++, but that C++ is better for writing unsafe code than Rust.

https://www.p99conf.io/2022/09/07/uninitialized-memory-unsaf...

Description:

My team @ Datadog is actively looking to hire a Senior Video Application Engineer, and a Backend Systems Engineer, to work closely with the CoScreen (www.coscreen.co) team on developing our next generation remote collaboration tool.

Anyone with experience with real-time media streaming, video conferencing, and WebRTC, particularly with low-level skills (If you’ve integrated with or ripped into the low-level details of libwebrtc, ffmpeg, gstreamer, pion, etc etc) we’d love to chat with you.

Also if you’re a low level developer with experience developing desktop applications, particularly with Rust, or C++ skills, we’d love to hear from you. We are looking for someone who can work on a diverse set of challenging and interesting problems, from remote application control on OSX and Windows, to maintaining Rust based backend infrastructure.

Senior Video Conferencing Engineer: https://careers.datadoghq.com/detail/5103763/?gh_jid=5103763

Backend Systems Engineer: https://careers.datadoghq.com/detail/5103658/?gh_jid=5103658

Tech stack: Rust, C++, Typescript, Electron, WebRTC, XMPP, Jitsi.

Compensation: $130000.00 - $300000.00, plus a competitive equity package, and may include variable compensation.

Contact: ben.papismedov@datadoghq.com, jason.thomas@datadoghq.com

We still aren't using hardware accelerated encoding. It's the last, and biggest contributor to CPU we see after profiling.

Moving to Rust was more of a decision for safety, than for performance, since most of the code we ported to Rust was in C++ already. The good news is we didn't see dramatic differences in performance between C++ and Rust.

Rust has a bunch of highly optimized, fantastic libraries, that helped with testing, profiling, and evaluating hardware acceleration/SIMD.

We will be putting together a blog about our experiences with Rust & C++, that goes into the nitty gritty of the good, the bad, and the ugly of our experiences here.

A great deal of the optimizations came from better profiling, better tooling, and a focus in that area. There is still a ways to go, and we are continuously working on improvements in this area.

Rust has been an incredible tool on reducing the work required to maintain, and change, core components, and we have even been able to have Rust target a static cylib library, and linked it in from a large C++ library.

The really great thing with Rust is it has a very minimal runtime, and integrates well with C++. It's not an all-or-nothing proposition to integrate it into a project. The maturity of the tooling, third party libraries, the build and package system, have been incredibly useful tools.

Here is a interview I did of Emil Ivov, the founder of the Jitsi project:

https://www.youtube.com/watch?v=7nODpF8JjHE

I am an avid Synergy user, and what they have accomplished in terms of direct mouse/keyboard input synchronization is very impressive, and I use it on a daily basis.

I can say however, it's very different than CoScreen and what CoScreen seeks to achieve, and is performed in a technically different manner.

CoScreen injects mouse interaction and keyboard presses directly into a window on OSX (if it isn't a weird type of window like an emulator, or something that captures and handles input on a very low level).

Synergy simulates mouse movements/events directly over windows, interfering with the position/location and current state of the remote cursor. It's much more like a remote mouse-driver for a lack of a better comparison.

In many ways this is more performant, simpler, and works on a wider variety of windows right out of the box.

On another level it interferes more with remote users, and prevents multi-player collaboration.

I definitely could see us producing a mode that is LAN focussed and which provides synergy like behavior, but the current remote collaboration is really geared from a UX perspective around multi-player in CoScreen.

We are working on a headless Linux client that will allow you to stream first pty/terminals, and then windows, into a CoScreen from Linux systems.

It's going to be a very small utility, and we hope to provide access to it by May/June.

This will eventually evolve into a full blown client.

In the meantime we will have a web client which will work on Linux released shortly, it's currently being privately tested within DataDog.

The Audio/Video are using VP9 SVC, and are a pretty typical configuration, using Jitsi as the backend.

The screen sharing is accomplished via a combination of libwebrtc and native Rust.

I think cutting through the hype-train is something every engineer learns with time, but some times there are diamonds to be picked out.

At least for my own anecdotal experience, Rust has lived up to a lot of the hype for the time-critical low-level projects I was formerly performing with C/C++.

Before having gigantic caches that would engulf nearly any sized contiguous list, linked lists were sort of vogue, frugal, and thought of as being fairly performant.

In the 2ks/10's, at least in my area, embedded jobs dried up. Mobile development produced a lot of very high performance SoCs that were cheap, and had high quality already developed middleware layers (Android for instance). They sort of conquered a lot of the embedded media processing space I was an expert in.

As a result I jumped ship to mobile, but it was much higher level programming far away from the SoC, and most of the lower level code was being written in China/South Korea.

This basically meant for the engineers that weren't able to shift, they basically weren't scouting around for, or finding other jobs (in general).

So even though there is a small pool of engineers with these skills, a lot of people left the embedded space at a time when some of those jobs are starting to shift back, leaving a shortfall, but also a pay gap.