Hacker News Reader

Comment by xwowsersx | Hacker News Reader

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 :)

View on HN

It's an actual selling point more than a "loved" situation.

If I see something built for massive concurrency and I see Erlang or Elixir, I'm immediately much more confident in the tooling.

If I see something written in Rust, I'm confident in it's memory safety at a minimum but it usually bodes well for quality code in general.

> bodes well for quality code in general

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.

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.

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...).

I think this especially true when someone is explicitly remaking something in Rust to make it more performant

"X but in Rust" IME almost always implies something with at best feature parity, but also debloated code

Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.

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.

It depends.

- Rust is a complicated language, so novice developers probably use something else.

- Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers).

- You get memory safety in safe Rust code and don't need a garbage collector.

- Non-optimal solutions usually are visible/more cumbersome to write.

In the end it's up to the individual developer, but Rust really helps to produce high-quality code.

And the community and philosophy/culture the languages come with seems to promote that as well.

> 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.

A few examples:

- Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible.

- Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible.

- Rust requires you to use Box for heap allocations, it's visible.

Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".

Yeah I think that's just called enforcing best practices, not optimal solutions.

One cannot enforce optimal solutions but one can prevent sub-optimal ones through proper checks.

You keep using that word, I don't think it means what you think it means.

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.

It's one of dozens if not hundreds of memory-safe languages. The false marketing claim that Rust somehow invented it is absolutely infuriating.

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.

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).

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.

> 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.

To be fair to Rust, Go evangelists can be just as annoying. I say this as a Go evangelist :)

According to the comment you replied to, you're statistically more annoying.

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.

> A tool being written in a language I know and enjoy is a benefit.

Sincere question: why? I 100% agree about libraries, but why does the implementation language of an application matter to you?

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.

Well, if the source is available you can do what you want with it.

I don't know a thing about Ruby and for awhile really felt out of it when stuff was being written in it a lot more.

Yup, a lot of false positives without quotes. Searching with quotes on Story gives the following. (Search is case insensitive.)

  "written|built in Rust"           832 (790|42)
  "written|built in Go"             809 (792|17)
  "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)

edited to include both "written in" and "built in".

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.

> 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.

Hah right. I'm surprised at how protracted this hype cycle is.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

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.

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.

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.

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).

Is this the new “I’m on Arch btw”? The comment you’re replying to doesn’t say anything about memory safety or C++

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 always tell my clients to fall into the trap of treating personal preferences as the optimal solution to a problem.

Are you missing a negation here? I might be missing the intended tone perhaps?

Yes, I do, thank you.

I have no problem with noting that it is written in Rust. But why name the app after the language?

Rust apps are in their "Nintendo 64" era

Maybe that's the most interesting or distinguishing feature of the app?

What I find most interesting is that it has better UI than AnyDesk. I haven't used TeamViewer in so long, I can't comment on it.

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.

Like others have already mentioned, _usually_ programs written in Rust are far more stable than their respective C/C++ implementation.

One impressive data point (for me) is this: https://youtu.be/GtRo-eF8-TE?t=671

> Total "crash" issues encountered: 2.

That part?

Exactly. Over the life span of ~3 years or what it was. That's pretty impressive if you ask me.

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.

"Rewrite it in" started with Node. Beginning at around 2010.

Then there was "in Go". Mid 10s.

And now it's Rust. 20s.

And Java before that.

System tools weren't written in Java that much.

People used Java, but mostly for GUI apps. Not command line tools.

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.

Rust projects are infinitely easier to contribute to.

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.

> or why it matters that it was written in Rust

Because it's an accomplishment to ship anything of complexity in Rust! /s

Maybe you can look at it as "wow, it's an entire application with no unsafe code and really good (perfect?) memory safety"?

As an exercise, think what the result would be if it was "written in PHP" instead.

Reply on news.ycombinator.com