It’s not useless. I for one associate language with their run time properties..

Written in Python - easy to understand, but lacks performance. Probably cant use more than 1 CPU core. Needs a lot of memory.

Written in Go - fast enough for most cases, all CPU cores, but possibly high mem usage becUse of GC. I need to plan for it.

Written in Rust - possibly new and maturing, uses memory effectively, likely to use all cores. Easy to deploy (single binary)

Written in JS - probably not for me - personal taste and hate of npm ecosystem.

Written in C - probably the best performing, but less robust, no memory safety.

So, “written in” helps in judging whether to care for that project or not to some extent.

At least it's not Rust-this or that-4-Rust. The bundling of the language in the title of the app is a fad I hope I see the end of.

Yes, Python, we get that you wrote WhateverPy in Python.

This, for me, is due to lack of package namespacing in these languages. Someone took 'xyz' ? Well I guess I'm going to be 'xyz-rs'

Rust has its own -rs thing going on.

Mostly for bindings though.

Ah, that would make sense. I’ll have to take your word for it.

For me, I primarily think about stability:

Python/Go/JS/C -> runtime crashes due to type errors and/or data races

Rust -> no runtime crashes due to type errors/data races

Why would go and c which have static typing suffer from type errors ? Why would go that has a data race checker and quite good concurrency primitives be more prone that rust ?

Rust seems to have its merits but I find the parent post more level headed in that it tries to characterize language runtime, admittedly subjectively but not in a rust==good, rest==bad way.

You can easily cause a C/Go program to crash/abort due to runtime type errors. If you've written C, you've miscast something at some point. Go in particular relies extremely heavily on runtime reflection. Both languages have poor type systems.

Go's race detector is useful and we've caught bugs using it, but it's nicer when the compiler prevents you from having those bugs in the first place.

>quite good concurrency primitives

That's gonna be a "yikes" from me, dog: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s...

I'm not a Rust fanboy, I simply like languages where it's more difficult to represent invalid state (Haskell, Ocaml, Rust, etc.) than in the mainstream languages I suffer with in my job on a daily basis. Rust happens to have great tooling and is the most likely to make inroads on these issues I care about (runtime stability + code correctness via good type system).

Go doesn’t rely heavily on runtime reflection. Putting it in the same category as C or JS is disingenuous. Rust has a great static type system, but I’ve never seen a Go program fail on a runtime/reflection type error before.

I'm not sure what to say. Go code (stdlib, popular libraries, etc.) uses runtime reflection _everywhere_. I've been using Go since 1.2 and I've seen too many runtime crashes due to type errors to count.

It is used for things like printf and JSON marshaling. I’ve been using Go regularly since 2012 and this isn’t a real problem. The reflection in the standard lib and popular third party libs (and most unpopular third party libs for that matter) is rock solid. Moreover, reflection probably accounts for less than 1% of Go code—not sure where you’re getting “everywhere” from. So I guess I’m calling your bluff.

Even if your claim of "probably ... less than 1% of Go code" is accurate, appearing somewhat less often than 1 out of every 100 lines of code is _everywhere_ to me...

To be clear, I didn't say "less than 1 out of every 100 lines", but in any case I don't consider yours to be a reasonable definition of "everywhere". Especially since such a low frequency doesn't support your claim that "you see runtime type errors too many times to count". Perhaps you're using libraries that are far, far below the ecosystem's average quality?

Gosh, Rust evangelists did a really good job brainwashing the community. Take a look at big Rust projects that do anything useful, like Tokyo. You'll find dozens of unsafe blocks everywhere, so much for static analysis. True, in the most simple cases linear types will slap you on the wrist, but most bugs happen in the complex parts of code anyways.

You're talking about a library that is forming the base of multithreaded applications. 99% of other libraries don't have nearly as much unsafe

I'm not part of the Rust "community" and don't participate in any of its fora, I just like a lot of the ideas it's pushing forward (see sibling comment). "unsafe" doesn't dIsAbLe AlL pRoTeCtIoNs like the anti-Rust crowd likes to say. I've written a few small (5,000+ LOC) programs in Rust over the last five years or so and I've only personally had to dip into unsafe once in my own code. I didn't claim that Rust prevents all bugs, I pointed out that Rust programs are more stable in the case of _runtime type errors and data races_ (which they are).

where is Java in the list :D

Sorry, but by and large that's "red goes faster" type of reasoning.

Red is a property of a car totally unrelated to its performance characteristics. The language software is implemented in absolutely has an impact on the performance and behavior of the software.

This is more like "Carbon is faster than aluminum." Yeah, it's a generalization, but it's a useful one.

I don't know what you people get out of pretending you can't derive much from being told what language something is written in.

As someone writing software in Rust myself I am always interested in knowing about projects using Rust for multiple reasons.

1) In the case of libraries (crates), it might be something I can make use of in the future.

2) I can look at how they solved the problem they are solving and compare that with how I'd do it and maybe learn something new that can be useful to me in my future projects.

3) I want Rust to thrive and I want people to be aware of projects using Rust because the more people that are aware of Rust the bigger is the probability that I can work for more companies in the future writing software for them in Rust.

Your 2) is by far the most important to me. Not only does it allow to learn about solutions I could repurpose and their used patterns; it can also give me that last missing piece I was looking for that blocked me from building something.

That said, I'm especially looking for software "written in Rust" because I know the build process is standardized. I may need some dependencies, but I know how the build will work (cargo build -> if at all, all build instructions are in build.rs). I compile all rust-based open projects myself, and I have yet to stumble over a non-binding-specific package that won't compile.

Fast rewind/forward n years, and you could replace "Rust" in your post with the name of the language /du jour/.

My original comment was because as an old guy who saw hype around so many languages come and go, I am getting tired of those projects who try to sell themselves only because they are written in Rust.

I've seen many languages with mix and match syntax differences and feature sets that didn't bring anything significant to the table. Rust is not that. It has memory safety while having memory efficiency, high performance, good package management, easy interface with C FFI, and excellent support for parallelism. The list of things it gets "right" from my point of view dwarfs other languages-du-jour.

The biggest downside IMO is you have to get people past some conceptual hurdles before they can be productive with it. (e.g. the borrow checker) Despite how often you see it come up on HN, it doesn't have a powerful marketing force behind it. It also doesn't fit the trend of turning developers into commodities by being as easy as possible.

The excitement around Java existed for two reasons: many people were new to the ideas in Java, and many people were learning it for the first time. Now, every programmer knows about Java's ideas (with the possible exception of interfaces which aren't in Python) and the number of people learning Java is capped at the number of kids being born. If Rust is successful then eventually every programmer who wants to learn it will already know it, and every programmer will know how to use a borrow checker. The nobody will post "made in rust" stuff on HN, but that will be an indication of Rust's victory.

And those projects and posts will also be interesting, for people building their own projects with similar needs in that language du jour.

If you're just an end user, or the project isn't open source, then sure, language might not matter so much.

Rust is probably here to stay seeing as it was picked up by Firefox. I still think it could have been done better, but perfect is the enemy of good enough.

Rust wasn't just "picked up" by Firefox - it was developed by Mozilla for the very purpose of using it in the "next generation" of Firefox technologies.

(The original Rust project as designed by Graydon Hoare was even quite different from the Rust of today, e.g. the C/C++-like focus, with little ot no runtime, is something that only came about around the Rust 1.0 release.)

Note that Rust intentionally lacks some features that would be useful for Firefox development (e.g. developing for the DOM involves object inheritance which isn’t present in Rust), so it’s not like it’s designed to solve exactly their problems and nobody else’s.

Rust has inheritance and polymorphism.

Rust has trait inheritance, but not object inheritance. Servo uses code generation and macros to get around this. (I’m literally writing an operating system in Rust, I know what I’m talking about.)

Could you elaborate on how trait inheritance is different from object inheritance?

"Trait" inheritance is just interface inheritance, which is indistinguishable from composition+delegation. It doesn't have the pitfalls of actual implementation inheritance, which essentially involves an extra "trick" of dispatching on the actual type of your object even when calling base-class methods. It's not that Rust cannot do this - heck, people do it all the time in C. But it has to be done by writing things out explicitly, it's not automatic in any sense. And for good reason - letting base-class code access methods that have been redefined in a derived class can create all sorts of pitfalls when you're not very careful about what that implies.

So was said about Java 20 years ago... Yet no one dares today post a "X in Java" anymore on HN.

And was probably said about Fortran and C. Our tools are getting better. I can only hope Rust becomes so widely used that I can recommend big companies use it since they'll have a trillion developer hiring pool.

"In Rust" signals something very important to me, especially with the context of "full text search".

ES is the current free text search engine out there, and it's famously painful to manage. Resource consumption and GC pain can be really significant.

I see 'rust' and I know immediately that at least some pains I've experienced will be eliminated.

I like knowing what language something is coded in. It makes me more likely to look into the project. If it's written in something I'm not interested in I may click through, but not be as thorough, and some languages I save the link for later because I have no interest in them professionally or on my time off. I like looking at all projects eventually because some people come up with amazing pieces of software in all types of languages, but others might not care to look at a Ruby, PHP, NodeJS, Python, C, C++, Rust etc project.

So per your rationale, why not listing in the title other pertinent information about the project?

I am saying that because the programming language is not what defines a project. It could be a pile of junk even if it written in the greatest language ever made.

Sometimes people do, they say "Django" instead of "in Python using Django" which I think is fine. People who know Python will take the hint.

It can be a pile of junk because of the language it is written in.

> It can be a pile of junk because of the language it is written in.

So many wonderful things were written in assembly or PHP (assuming you rate PHP and assembly on the other end of the spectrum of awesomeness.)

The ratio of garbage to awesome is relevant not individual examples

I see this just as often for Python, C, JavaScript, etc.

The patters is more like "X written in Y", which is totally fine imo.

Rust is an interesting language both for its technical characteristics, which is a direct appeal as other commenters have noted, but it can also be worth noting because Rust interoperates almost as well as C. If I announce a cool Python module, someone who primarily uses Ruby is probably going to ignore it because the level of effort to use it would be more than it's worth. If I announce a cool Rust module, they might think “you know, it's pretty easy to build a wrapper…”.

What codetrotter and ccccc0 said, also Rust as a language and a community has a strong focus on correctness, which makes me more interested in actually using the project.

In general I think the title of a project on a news aggregator should basically be a 80 character sales pitch, " in rust" is 8 characters that signal a lot more than most 8 characters could (to me).

Rust is young enough that you can read this as an ad for the language, not the project. "Rust is a language in which people write full-text search and indexing"

I think it's relevant for open source projects because people might want to contribute to them or just read through the code to see how things work. And of course people will be more interested in doing those things with languages they have experience using.

The same developer also happens to have written a similar server in Python a while back: https://github.com/mosuka/cockatrice

Tell the mods that. I've seen mupltiple titles where they edited the original title to include "in X".

was about to comment the same before seeing your comment.

This.