I guess it's a testament to how loved Rust is as a language that there are so many projects posted here with "...built in Rust".."written in Rust". I like Rust, but in some contexts I wonder how or why it matters that it was written in Rust (I know there are some projects where for security or other reasons it may actually matter) to me as an end user or at least why it's so important that posts introducing the project lead with that fact. Sometimes, it just seems like a low level implementation detail that is unimportant. Naming the entire project after Rust ("rustdesk") is a whole new level though :)
Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly.
As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker.
Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.
> Non-optimal solutions usually are visible/more cumbersome to write
How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.
Language choice is absolutely a powerful indicator of expected code quality. I don't want to start a language flame war, but I have some heuristics around P(I am satisfied with software|software is written in language X) that are very predictive.
Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.
It's a bit of a curse though, isn't it? If a language becomes popular enough rather than something used only by enthusiasts, then all sorts of crap will appear?
Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).
That's fair. Code quality may have been a stretch.
I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.
To push this argument further along, in numerous use cases the GC using languages have comparable memory safety and performance (thus equal mention by government agencies), but were easier to use or faster for production.
No language will save you from:
- A lack of knowledge about the domain, this includes the technical framework in which your program exists, behaves and interacts
- Code errors which result in valid code, but does the wrong thing, Rust isn't magic
- Bad choice of datastructures and algorithms
- Incomprihensible code documentation and bad development practices.
While I get that languages can eliminate a type of problem, they don't eliminate badly written software. Most of the time, the software development process itself, is more important, if you really want to examine what it means to build secure/safe software.
Having a team dedicated to developing software safely and using a language with stronger type safety guarantees vs. having a person just build something with the same language, does not magically imbue the end product with good qualities.
Take your example, if you don't have a good foundation in distributed systems, and try to build a distributed system in Erlang, you will only get so far, before you hit your head against the wall so hard, you start studying distributed systems instead.
This kind of thinking is strange. It's similar to saying no type of exercise can save you from death. While true, we are talking about probability bounds here, not certainties.
I totally understand what you are saying, in terms of probabilities, but what I'm arguing against, is thinking that safety, robustness etc. for a program is just a given, just because you happen to use Rust or whatever else is claiming X feature. In it's essence, it's like saying something is made of military grade materials, but then the materials are used all wrong in the actual design or not of importance at all. The fact that someone used Rust, does not really tell me much, other than certain types of errors are eliminated, and that is assuming they used Rust correctly, for the type system to work properly.
If you ask people explicitly about whether Rust just makes better products, they might say that they have doubts, or give a vague answer. But asking like this is just a leading question, and therefore the process itself of asking the question, will probably cast doubt over some automatic assumptions about what the type safetly of Rust really does for the end product.
But the reality is, "Made with Rust" is starting to look like a certificate/claim of validity, and its definitely not, just like any other language isn't either.
For one reason or another, those other languages didn't take off and Rust did.
Language adoption isn't just about technical merits (although those have to be there). The ecosystem, tooling, core team, learning resources, and overall community have to be there, too.
To your point - if I want to get started in another language that is 1) statically compiled, 2) non-garbage collected, and 3) memory-safe by design, as far as I can tell my only other mainstream options are Swift / Objective-C, Ada / SPARK, and Nim. I don't see nearly as much activity in those language's open source ecosystems, and "basic" libraries might not even exist due to the small communities.
Nim is garbage-collected, actually. It has an option to disable garbage-collection (though I thought there was talk of removing that at some point) but then it just leaks memory, it doesn't have a comprehensive system for GC-less memory management like Rust does.
Nim is also not the only language with the combination of optional GC and memory management. Dlang and Vlang are two others, where the GC is optional and are compiled languages. Golang appears to be more seriously experimenting with various forms of manual memory management, so at some point, we might see it offer a choice of memory management options too. In fact, Dlang even has an experimental borrow checker.
Care should be taken to not be in so much of a bubble, to not realize that other languages have viable solutions too or are developing alternatives to what's presently available. If our choice for one or the other, is more a matter of personal preference, it would arguably be better to acknowledge such.
Friend nim does have gc less memory management https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... and can also collect cycles similar to PHP. Imo the new system is more intuitive than rust's which will be a huge win when it comes out (soon).
> The false marketing claim that Rust somehow invented it is absolutely infuriating.
This is the second time I've seen someone say this in the last week or so, but I've never seen this claim in the wild, and certainly not by Rust's core team or organization. It's also not a secret that Rust's memory management is heavily influenced by Cyclone. Can you show an example of someone making this claim?
Remote desktop software is traditionally the source of many hacks - like exploiting the software itself, not just using it. So there is a relevant security angle here.
Aside from that though - there's a lot of comments on rust threads in general about how Rust isn't ready for this or that or the next thing, so these types of projects showcase that maybe the "not ready" info is outdated or over-exaggerated.
It's also one of those things that seems to occur "naturally" as a language becomes more widely adopted. A few years ago there were tons of projects linked here about "x - a tool for y written in go". And before that ruby or python, etc.
This comment is so common here I decided to do a quick search here on HN:
- written in go: 1331 results
- written in rust: 1043 results
- written in python: 763 results
- written in javascript: 525 results
Not intended to be scientific and there are false positives but you get my point. Personally I appreciate not having to visit the repository to find out. A tool being written in a language I know and enjoy is a benefit.
I enjoy tinkering and making my life unnecessarily difficult is a hobby. To give you an example i use:
- dwm as window manager
- neomutt for email
- newsboat for feeds
- notifications with inotifywait/watch and notify-send
- vim keybindings EVERYWHERE
Because of this the I've become very reliant on the ability to tweak and customize the tools I use. I know I'm a minority but I'm so deep down the rabbit hole I can never go back.
On neomutt, use a Maildir config and use isync (mbsync) and msmtp. It's godly fast. No IMAP(S) related hangs, no needs to be online 24h, no slowdown over GUI's. Write your mails and queue them, send them later.
I am, and the sync is a cronjob triggering inotifywait watching the directories I'm interested in. Only thing I wish I had is less hassle unlocking the password file but I'll get there.
Replying to my own post for posterity because edits are closed and I missed the obvious Go/Golang. This pushes Go to the top winning it a "major award".
"written|built in Go/Golang" 918 (792|17) / (102|7)
"written|built in Rust" 832 (790|42)
"written|built in Python": 390 (364|26)
"written|built in Javascript/JS" 269 (220|14) / (32|3)
"written|built in Java" 107 (101|6)
"written|built in TypeScript" 66 (61|5)
"written|built in C#" 41 (38|3)
"written|built in Stone" 10 (10|0)
One other item I noticed is on average "written in Rust" has about 3 times the number of comments as "written in Go/Golang" for the more popular posts. Clearly, Rust gets a major award too.
I assumed the "annoying" part comes from telling other people to rewrite stuff in ${LANG}. While a number of projects "writte in ${LANG}" could correlate with the annoyingness as defined above, in my experience Go evangelists are more aware that their language is not end-all be-all, but is actually useful in a certain niche of IO-heavy applications, so evangelism is much less pronounced.
> Naming the entire project after Rust ("rustdesk") is a whole new level though :)
That happens to most ecosystems that go through a "hype cycle" just like Rust is right now. So many Go projects have something "Go" in them, same with JavaScript, Ruby and all the others who've walked the path.
Back in 2011 or so, until forever, it felt like every day there was a mandatory "X made in Ruby" frontpage story as well. I'm sure this one will pass too, once a new language appears that everyone HAS to write everything in.
Yeah, I really think it's weird to include the language name in the package name unless it's a language-specific library (with no FFI... C libraries almost never include C in their names) or bindings to something. The language is (usually) an implementation detail for an "app"
And in this specific case, a rusty desk is probably not what most people want, so if you want any non-programmers to use it... it's not the best name.
Normally I see the name of the language included in libraries, not applications. In that context it makes a bit more sense because it actually does matter what language the library was written in/for. For a remote desktop application it's hard to see why it's relevant enough to be included in the name.
It's not that it's impossible to write secure code in C/C++ or that it's impossible to write insecure code in Rust, but Rust makes it much harder to write a particularly prevalent class of bug (memory safety).
These bugs are obviously particularly bad because of the security implications, but even for applications where you don't care about security having the app randomly segfault is no fun. All else being equal, I would choose an application written in Rust over C/C++.
That said, obviously the name of this project is just because the author likes Rust a lot. It happens in other languages too ("go" in Go projects, "py" in Python projects, etc).
No it's the new "I use go btw" (which itself is the new "just use python for that", which was the new "do it in java for portability". I wasn't old enough to witness C++'s initial rise, but it was famous for it's hype squad and people selling it as a silver bullet. As was C (that slow language will never be as good as a real programmer doing it all in assembly is the story there IIRC)).
Rust's security improvements the comment I'm replying to mentions come from the fact it is memory safe. C/C++ are just the obvious comparison for a very popular memory unsafe language.
It's a reliable way to get engagement on HN. You're guaranteed lots of comments from the Rust Evangelism Task Force as well as people inevitably asking why everyone mentions their projects are written in Rust.
It's worth noting that for a few years people suffixed all their stuff with "made in node" to get upvoted and then for a while with "made in go". I always tell my clients not to fall into the trap of treating personal preferences as the optimal solution to a problem.
I haven't used either AnyDesk or TeamViewer. Looking at the snapshot in the linked article, RustDesk looks like a web page. The window chrome looks like macOS, but the application does not look very Macintosh-y. I personally don't think it looks great, but if it works well enough, maybe that doesn't matter.
My biggest complaint about AnyDesk is that sometimes I have to walk people through downloading and installing it over the phone. When AnyDesk is installed, the tab with the connection ID is overlaid by a tab with an ad. At that point I have to give up because many people don't understand tabs and don't know how to close it or switch tabs so they can see the connection ID. Very user unfriendly. I was very glad to see RustDesk come along.
It starts off as a way of inviting other rust programmers to contribute. But then the project matures and becomes an end user product and we end up like this project. The fact that we see so many rust* project is a testament to the usability and power of the language.
A couple of years ago there was an avalanche of posts about projects written in Go. Today's hyped language is Rust. Give it another couple of years and some new language will have taken its place here.
My thought process is that Rust's memory model not only has a positive impact on security, but on program correctness all up. This means fewer lock ups, better performance, resource utilization etc. without so much effort from the developer. As such, while the 'built with Rust' label is no guarantee of a well-written program, it certainly avoids certain pitfalls that other languages are more susceptible to with a minimal performance tradeoff.
in my case being built in rust is a benefit. elixir is my daily driver and rust fills a niche for me (all the domains where elixir isn't great) and they pair well together thanks to rustler.
A project being written in rust communicates to me that if I ever wanted to join the community and start submitting patches, I could. I have little interest in devoting the next 10-15 years "mastering" c++ but I'm happy to dig into rust.
The Rust community seems to be obsessed with the idea of re-writing every prior piece of software in Rust, to such an extent that there is a specific word for it: RIIR. This is sometimes funny, since it demonstrates the incentive to be "approved", to be praised, for some reason unknown to me. And yet, I don't see much game-changing software written in Rust, such as Docker or Kubernetes.
Agree the underlying language is not to important.
On the other hand when I see built with Rust I have high confidence it’s going to be fast, bloat free, easy to install binary and not some slow website packaged in electron made to look/feel like an app or some NodeJs app with 1000s of random dependencies.
This gets posted again and again, and every time I look at it, the code quality is absolutely terrible. Remote access software is by design a complete internet-accessible backdoor to your system, I will never use one that is written as shoddily as this one.
Also note their persistent refusal to implement TLS for their web access.
This attitude alone tells me never to trust this project ever, even when they finally should use TLS.
Sadly there is no other FOSS out there that combines remote support with good NAT traversal.
Existing remote access tools such e.g. VNC all do not offer NAT traversal and are incredibly hard to setup.
All FOSS web/phone conference tools offering screen sharing refuse to implement transferring Cursor/Keyboard control.
Probably because it is not so easy, but mostly, I guess, out if fear for diffuse security problems.
Too bad people then will be compelled to use this absolute mess...
Most of the desktop access stuff is open source. (The only desktop related thing that's proprietary is our tool that allows for access to machines not connected to Active Directory). A sizeable chunk of the desktop access code is even Written In Rust™: https://github.com/gravitational/teleport/tree/master/lib/sr...!
Are you talking about their website, rustdesk.com? It looks like they have HTTPS version of "rustdesk.com" but don't redirect to it automatically.
Do you have any links to issues/interactions you find concerning? I've been evaluating different remote desktop tools recently and I'd certainly like to know about any other red flags.
Are there any other remote desktop services what work out of the box to access servers behind firewalls and has clients for mobile and all desktop devices?
not to criticize your answer, i just have not found any viable alternative that is free to use for all use cases.
This is particularly interesting, the commit modified the `WaylandEnable` option in the file "/etc/gdm3/custom.conf" to "false", disabling Wayland and enabling X11.
But even more interestingly so, the modification is performed with elevated privileges, via `pkexec` command.
Last time I checked, this application did a dirty thing to my /etc to force X sessions instead of Wayland. You can do these things, but please be upfront and ask me first - I certainly do before depositing bodily fluids in places I do not own.
Obvious question that I couldn't find any answer to: How does the latency compare to existing solutions?
I currently use RealVNC and Steam's own VNC thing to connect to a desktop computer in the same city as where I'm connecting from. RealVNC is much laggier than Steam, which seems optimized for latency. The ping latency is something around 10-15ms (at peak hours, otherwise less), but somehow RealVNC manage to still be kind of laggy, at least compared to whatever Steam is doing.
The use case is doing game development (in Unreal Engine) via a shitty laptop, connected to a proper desktop computer.
So how would RustDesk compare to RealVNC/Steam here?
When i play games on windows from my mac i used steam, rustDesk was a bit slower last time i checked (approx 1 year ago). However rustdesk is more flexible when it comes to remote access or number of plattforms the client is available (in my case iOS).
Thank you for this recommendation. I'm connecting to a Windows machine from Windows/Linux/macOS and Parsec works really well, low latency and good quality. Much better than RealVNC and access to the full desktop compared to Steam.
Looks interesting! I'm currently, and thankfully, not responsible for any infrastructure where this would be useful, but will definitely check it out the next time the need arises.
TeamViewer is (both technically and commercially) awful, and getting rid of it is always priority #1 when taking on a new environment. You always run into fun stuff like 'oh, yeah, this 4-years obsolete version is running on our main accounting server all the time, as that's the only thing the vendor supports, and they need to be able to get in at all times'... 'yes, indeed, using only a 4-digit PIN, why do you ask?'...
Being able to supply your own RustDesk rendezvous/relay server is especially interesting to me, as features like proper SSO-linked 2FA, a log of who accessed what from where (hopefully including file transfers), and alerts on large data flows becom a lot easier to implement that way.
Sadly TeamViewer is the only thing that works on old Android Point-of-Sale devices which are still numerous. And since Android requires the manufacturer signature to do screen sharing on older versions and those manufacturers are either dead or too big to care, it will remain to be so.
I can't wait though for the day the place I work for decides to drop support for them and stops paying for that... thing as it's not only extremely expensive and awful from a security perspective but also from a general quality one: some days their server just decides to not log you in, they have a nasty crashing bug that often happens when you resize your meeting window that has been there literally for years, among other things.
It seems to be getting a lot of hate here (where I found it) but I've been using it for over a year now. One of my developers used to drop into my mac from windows to do builds and diagnose ios issues plus spend non trivial time setting up other things, it was basically on for hours. Latency was good, no issues whatsoever in our time using it.
I use this to remote into my Mac Mini from my Windows machines and it is very good. VNC is awful on Macs for some reason, unless you're using it from another Mac.
I found this program last week and replaced AnyDesk with it, but after reading all the comments around the security issues and especially seeing that their relay servers are potentially hosted in Beijing, I'm feeling a bit sick to my stomach honestly. I'm going to uninstall it and do more research. I'm not comfortable with the ambiguity around something that is effectively an open door to my entire system.
Well it's technically not free - although you can still use it for free after the trial period, but they can disconnect you at any time - and I would lose connectivity sometimes. The main reason for switching to RustDesk is so I can build my own version and deploy it on the work laptop. I'm using PiKVM to VNC into the work laptop right now, but it's a poor alternative at the moment with the latency and resolution issues in TigerVNC.
this is the most active and impressive collaborative community of developers who are VERY VERY responsive to all questions and are helpful in improving the software.
between the comments pointing out numerous serious security issues and those who point out poor code quality or phoning home to china, the comment i am replying to feels strongly like astroturfing
Google analytics is not a requirement for remote desktop software either. That said, to answer yor question, I would absolutely prefer Google analytics over phoning home to China.
