Earlier quoted context omitted.
Is Rust harder than C++?
Yes.
That answer lacks some nuance
Yes, it is harder to get a Rust program to compile. But it also is easier to accomplish the desired task safely
Edit is now open source
41–50 of 191 posts
Re: Edit is now open source
#42Earlier quoted context omitted.
Did they cancel it because dosbox exists? If so, that's smart.
Most likely because Microsoft didn't consider it a valuable use of engineering time in general. AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps. AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V clie…
It looks like you can switch the processor back to true 32-bit protected mode (not just 32-bit "compatibility mode" within long mode) https://forum.osdev.org/viewtopic.php?t=43127 which in turn gives you access to the old virtual 16-bit mode - but this involves running kernel code too in 32-bit mode, which is kind of a no-go in a modern OS. Using the virtualization extensions will be a lot easier.
Re: Edit is now open source
#43Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without. They could just have packaged nano, but oh well.
I am truly behind the times. I didn't know you can ssh into a Windows system.
Re: Edit is now open source
#44Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without. They could just have packaged nano, but oh well.
This could be a great text-mode IDE with the addition of some LSP, tree-sitter and DAP support. There is already an open issue about possibly adding support for tree-sitter grammars for fast syntax highlighting, but they do mention that this requires some sort of optional plugin system to avoid bloating up the codebase severely (for example, the tree-sitter grammars within the Helix editor take up hundreds of megabytes, which is obviously unacceptable here).
Re: Edit is now open source
#45And again a case of bad naming from MS because it’s too basic to be distinguishable.
Re: Edit is now open source
#46Earlier quoted context omitted.
It seems like your first paragraph answers the question in the second. If it is harder to use and learn then that reduces the value of free software released using it as that software is then harder to modify, fix, contribute to, etc. The tradeoff for Rust being hard should be more security and fewer bugs. The additional cost here, and the one that the OP is probably annoyed with, is that it moves away from the langu…
Is Rust harder than C++?
If the OP already knows C++ then it would obviously be harder for them. Given the nature of their post, this was my interpretation.
Re: Edit is now open source
#47Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without. They could just have packaged nano, but oh well.
I wholeheartedly agreee. Nano is quite awesome, it is battle-tested and already has more features than needed for a basic text editor. Actually, Nano is too often frowned upon as too-basic, but is actually has a few advanced features that basic editors do not have (e.g., keyboard macros). I'd argue that Nano is simple rather than basic :).
I tried discussing it here a few months ago but it did not took off: https://news.ycombinator.com/item?id=41289773
Re: Edit is now open source
#48Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without. They could just have packaged nano, but oh well.
I am truly behind the times. I didn't know you can ssh into a Windows system.
Since windows 10/windows server 2019 afaik.
Re: Edit is now open source
#49Earlier quoted context omitted.
Most likely because Microsoft didn't consider it a valuable use of engineering time in general. AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps. AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V clie…
It looks like you can switch the processor back to true 32-bit protected mode (not just 32-bit "compatibility mode" within long mode) https://forum.osdev.org/viewtopic.php?t=43127 which in turn gives you access to the old virtual 16-bit mode - but this involves running kernel code too in 32-bit mode, which is kind of a no-go in a modern OS. Using the virtualization extensions will be a lot easier.
Interesting - though one other hurdle coming up for this sort of thing is that Intel was threatening to drop real/protected/v8086 entirely and release processors that boot to long mode and don't let you drop out of it. Dunno if they still plan to go through with it or backed down.
Re: Edit is now open source
#50It not only written in Rust, but they avoid basically any dependencies to third-party crates (beside the obligatory windows-sys/libc), optimizing probably for binary size. To achieve this, they seem to re-implement considerable parts of the rust ecosystem (own TUI library implementation, own unicode handling, own arena implementation, ...).
I’m guessing this isn’t just to optimize for binary size. If you have the resources to avoid third party dependencies you eliminate the burden of having to build a trust case for the third party supply chain. That is the number one reason we sometimes reimplement things instead of using third party packages where I work: the risk from dependencies along with the effort required to establish that we can trust them is sometimes (not always) greater than just replacing it in house.