Superconsole: A Text-Based User Interface (TUI) Library Written in Rust(developers.facebook.com)
developers.facebook.com
Superconsole: A Text-Based User Interface (TUI) Library Written in Rust
https://developers.facebook.com/blog/post/2022/07/21/superconsole/
9 comments
As per recent comments here in other threads, I wonder if we could see less "written in Rust" in the titles?
I know it's verbatim from TFA's title, but honestly, at this point Rust evangelism feels like proselytising propaganda.
What exactly is going on? Is there a concerted effort in the Rust community to actively evangelise? Or is it just that blog posters are gaming SEO and riding the upward adoption curve? I'm aware that several key influences have praised Rust-related efforts, but there seems to be something far more deliberate going on. Is there?
I don't use Rust, and a few months ago it was on my list of languages to check out, but frankly the fan-boyism is a real turn-off.
I know it's verbatim from TFA's title, but honestly, at this point Rust evangelism feels like proselytising propaganda.
What exactly is going on? Is there a concerted effort in the Rust community to actively evangelise? Or is it just that blog posters are gaming SEO and riding the upward adoption curve? I'm aware that several key influences have praised Rust-related efforts, but there seems to be something far more deliberate going on. Is there?
I don't use Rust, and a few months ago it was on my list of languages to check out, but frankly the fan-boyism is a real turn-off.
I think it's a combination of evangelism and excitement but also of a fallacy, thinking that a Rust application ought to be faster and more efficient with system resources, so people "helpfully" inform of this.
As any developer knows, a low level programming language may help you get there, but ultimately this is mostly dependent on code quality. Rust applications can be absolutely riddled with bugs and use O(n^2) algorithms where they don't need to, or have awesome code but rely on third party libraries that don't. There's just so much surrounding the core aspects of the language that we just can't judge applications based on their programming language.
Rust does protect against buffer overflows and pointer misuse etc but so does many other languages nowadays, for example by directing the developer away from (or not even supporting) the use of low level unchecked pointers in the first place.
As any developer knows, a low level programming language may help you get there, but ultimately this is mostly dependent on code quality. Rust applications can be absolutely riddled with bugs and use O(n^2) algorithms where they don't need to, or have awesome code but rely on third party libraries that don't. There's just so much surrounding the core aspects of the language that we just can't judge applications based on their programming language.
Rust does protect against buffer overflows and pointer misuse etc but so does many other languages nowadays, for example by directing the developer away from (or not even supporting) the use of low level unchecked pointers in the first place.
Low-level languages enable speed, they don't guarantee it, high-level languages enable safety, but don't guarantee it either. Rust enables both, and I would also argue that it makes safety and speed more likely. Not guaranteed, but no other language really guarantees that either.
Rust seems to need way more code optimisation than other languages to run faster/ at same level. For example Go is way simpler to write and is just fast without even optimising code. Rust is faster for sure but from what I see only if you really know what you do and optimise the code. Therefore I also wonder where exactly all this hype is coming from and for what exact reason to be honest because most developers won’t write optimised code in Rust (at least this is my assumption) and take advantage of it being faster.
I assume folks who write optimised Rust have some experiences writing optimised C/C++... which means the domain is a bit narrow, usually microcontroller stuff, computer vision, OS kernel, etc.
On the other side, I agree perhaps we don't have to (re)write anything in Rust.
On the other side, I agree perhaps we don't have to (re)write anything in Rust.
I do have rss feed that pings me when there is Rust on HN as that is focus of my interest.
Under every article about Rust there is comment complaining about Rust in the title. Why do you have to do this? If you are not interested just move on.
Under every article about Rust there is comment complaining about Rust in the title. Why do you have to do this? If you are not interested just move on.
To you it's a useful flag. To me it's unnecessary noise. There's very little "written in Java", "written in C" or whatever. I'm sure C/Java programmers would find those eye-catching, but they seem to manage without.
The Rust community seems noisy compared to others.
And besides... Why do _you_ have to reply to the reply? Why don't _you_ just move on? :) Hopefully because we are curious people who want to develop our understanding of each other?
The Rust community seems noisy compared to others.
And besides... Why do _you_ have to reply to the reply? Why don't _you_ just move on? :) Hopefully because we are curious people who want to develop our understanding of each other?
It’s sort of like metadata, your right about less “in Java/C/etc” but there are other languages that are more vocal about indicating this, Python comes to mind, Go is a semi-frequent user of the “written in” addendum. I like rust and I like seeing the growth of the ecosystem and discovering new libraries like this. To me having this is a big help. For a language I don’t like like Perl or Go, its also nice to know I can ignore it, or alternatively check it out to see if anyone suggested similar libraries in other languages, something which happens often enough I got into the habit of quickly skimming such threads for links.
There’s value in the metadata of “written in $X” allowing you to know what to expect. If HN had tags or something like that we could filter it instead but it doesn’t and so we’re all just experimenting with alternative labeling schemes.
There’s value in the metadata of “written in $X” allowing you to know what to expect. If HN had tags or something like that we could filter it instead but it doesn’t and so we’re all just experimenting with alternative labeling schemes.
This library is layered on top of a package called CrossTerm, which (on terminal systems, at least, but not on console systems) in turn emits roughly ECMA48 standard control sequences to do the cursor motions and whatnot. So the bottom layer is a terminal/terminal emulator that supports/emulates a (subset of a) DEC VT520 terminal.
But VT520s can already do what the library does. This idea of a static region and a scrolling region on the screen has, after all, been around in the world of terminals since the 1970s. There are DEC VT control sequences for setting left, right, top, and bottom margins; which specify a scrolling region and also modify scrolling and automatic cursor movement behaviours outwith that region. They're widely supported in terminal emulators because a popular compatibility testing program, vttest, makes them applicable to many tests.
So what is actually going on here is that because CrossTerm does not produce anywhere near the full capabilities of an underlying DEC VT, an entire library has been built on top of it to replicate stuff that actually exists already in the code of the terminal emulators and terminal firmwares. It should be noted that the termcap and terminfo libraries provide a change_scroll_region capability that can set top and bottom margins, and are superior to CrossTerm in that regard.
The curious should see the DECSTBM and DECSLRM control sequences and the DECLRMM private mode.