As the owner of a somewhat popular language, I checked to see if there's an extension available (there is!) as we publish a language server.
One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug.
I love the idea of a centralized wrapper for spawning various language servers.
As the maintainer of a language server which is primarily used in VSCode, we've relied on community contributions to add support for other editors (NeoVim, Atom, Rider for example). Information about how to do this is spread out, prone to breaking (depending on how well the implementor understood the domain), and also requires the IDE user to follow manual steps in some cases. I don't even know where I would go or who to speak to if (for example) we changed our download URL format, or added new process architectures.
Has anyone seen a technical explanation for how Nanite is implemented?
As someone technical but lacking domain knowledge in the gaming/graphics industry, I'm very curious about the way this is being explained as cheaper to render than high detail polygons.
There's a lot of techniques applied. It's not really "one new revolutionary thing" but a bunch of things and research over the past 20-30 years put together to make nanite possible. This video might shed some light https://youtu.be/eviSykqSUUw
Interested in programming language design and distributed systems with a strong focus on providing a positive developer experience? The Azure Deployments team is responsible for Project Bicep [0], ARM Templates [1], and various backend services for deploying and managing Cloud resources on Azure with Infrastructure-as-Code. We are at the center of the Azure control plane API with great opportunities for cross-team collaboration and impact, have a lot of autonomy to shape the direction of our own products, and enjoy having a hands-on approach with customers to help drive our feature design.
We're looking for a Senior Software Engineer (5+ years experience) and an SDE II (3+ years experience) to help grow our East Coast team. This position is open to full-time remote candidates, but can also be in-office or hybrid out of the new Microsoft campus in Atlanta, GA (relocation packages available).
Feel free to contact me directly (Anthony, Engineering Manager - antmarti@microsoft.com) if you'd like to chat before applying, or apply directly to the positions here:
Microsoft Azure Deployments Team | Senior Software Engineer | Atlanta, GA | ONSITE or REMOTE (US East Coast preferred), VISA
The Azure Deployments team aims to make deploying resources to Azure simple, safe, predictable, and reliable. We own the Template deployment [0] orchestration service, client-facing tools including our open source DSL - Bicep [1], and various other services aimed at bringing customers up to speed with Infrastructure as Code. We are at the heart of the Azure control plane with great opportunities for cross-team collaboration and impact, have a lot of autonomy to shape the direction of our own products, and enjoy having a hands-on approach with customers to help drive our feature design.
We're looking for a Senior Software Engineer (5+ years experience) to help grow our East Coast team, acting as a lead for new features, as well as providing mentorship to junior colleagues. We're not looking for any specific language experience, but are looking for demonstrable leadership, mentoring and collaboration skills.
If you're looking to be Atlanta-based, we offer relocation packages within the US.
One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug.
EDIT - commented on the tsserver thread here: https://github.com/zed-industries/zed/issues/18698#issuecomm...