starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 00:15:10 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Migrate most of the Terminal code to Rust #23325

New Issue
Closed
opened 2026-01-31 08:38:54 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 08:38:54 +00:00
Owner
Copy Link

Originally created by @ghost on GitHub (Jun 2, 2025).

Description of the new feature

Windows Terminal has had several major changes of code in the past, such as AtlasEngine.

What do you think of rewriting most of the Windows Terminal code in Rust language, keeping the C# only for the WinUI interface, since the Rust does not support GUI?

It can be something progressive, in a different branch, and only after testing, being transferred to the "main" branch.

Conhost can be kept in old language C/C ++, with minimal changes, as is currently happening for compatibility reasons.

Team members such as @DHowett, @lhecker and @zadjii-msft, seem to be familiar with Rust, due to their contributions in other repositories such as microsoft/edit and microsoft/sudo.

Motivation

All advantages of Rust language, such as lower memory use, higher speed, safe memory use, etc.

Unfortunately I only know JavaScript, otherwise I could make contributions myself.

Originally created by @ghost on GitHub (Jun 2, 2025). ### Description of the new feature Windows Terminal has had several major changes of code in the past, such as AtlasEngine. What do you think of rewriting most of the Windows Terminal code in Rust language, keeping the C# only for the WinUI interface, since the Rust does not support GUI? It can be something progressive, in a different branch, and only after testing, being transferred to the "main" branch. Conhost can be kept in old language C/C ++, with minimal changes, as is currently happening for compatibility reasons. Team members such as @DHowett, @lhecker and @zadjii-msft, seem to be familiar with Rust, due to their contributions in other repositories such as [microsoft/edit](https://github.com/microsoft/edit) and [microsoft/sudo](https://github.com/microsoft/sudo). ### Motivation All advantages of Rust language, such as lower memory use, higher speed, safe memory use, etc. Unfortunately I only know JavaScript, otherwise I could make contributions myself.
claunia added the Issue-FeatureNeeds-TriageNeeds-Tag-Fix labels 2026-01-31 08:38:54 +00:00
claunia commented 2026-01-31 08:38:55 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 2, 2025):

All advantages of Rust language, such as lower memory use, higher speed, safe memory use, etc.

FWIW I can assure you as someone who really likes Rust that the blazing fast Rust projects are often anything but. It is very unlikely that a rewrite will achieve further memory or speed improvements that are difficult to achieve in C++. The biggest benefit in Rust for us lies in its genuinely good support for slices, which we need a lot throughout the project.

Conhost can be kept in old language C/C ++, with minimal changes, as is currently happening for compatibility reasons.

IMO conhost may actually the one project that may benefit from this the most (at least initially), because it implements the PTY.

That said, I don't think we can do this due to lack of funding for the project. There's also the question whether this is worth doing. The project is in the magnitude of around 200k LOC and it would take around half a year to port it to Rust and C#, with no new features added to the product. I don't think a partial conversion of the project is worth it, because maintaining 3 languages is strictly worse than maintain 2. We can consider the thought in earnest for new libraries though...

@lhecker commented on GitHub (Jun 2, 2025): > All advantages of Rust language, such as lower memory use, higher speed, safe memory use, etc. FWIW I can assure you as someone who really likes Rust that the blazing fast Rust projects are often anything but. It is very unlikely that a rewrite will achieve further memory or speed improvements that are difficult to achieve in C++. The biggest benefit in Rust for us lies in its genuinely good support for slices, which we need *a lot* throughout the project. > Conhost can be kept in old language C/C ++, with minimal changes, as is currently happening for compatibility reasons. IMO conhost may actually the one project that may benefit from this the most (at least initially), because it implements the PTY. That said, I don't think we can do this due to lack of funding for the project. There's also the question whether this is worth doing. The project is in the magnitude of around 200k LOC and it would take around half a year to port it to Rust and C#, with no new features added to the product. I don't think a partial conversion of the project is worth it, because maintaining 3 languages is strictly worse than maintain 2. We can consider the thought in earnest for new libraries though...
claunia commented 2026-01-31 08:38:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 2, 2025):

It was nice of you to respond, but this person seems to have been a mirage.

They also seem to have thought that we used C# for our UI code.

Alas.

@DHowett commented on GitHub (Jun 2, 2025): It was nice of you to respond, but this person seems to have been a mirage. They also seem to have thought that we used C# for our UI code. Alas.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Feature Needs-Tag-Fix Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23325
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?