[SaintSeiya84]

In what something is written is irrelevant, please stop with this "written in Rust" as it is not an automatic badge of quality. if you have to specify that something is written in any language (Rust the latest trend) then it has no merits on its own.

[badsectoracula]

> In what something is written is irrelevant, please stop with this "written in Rust" as it is not an automatic badge of quality.

It is not an automatic badge of quality for the program itself, but it is an indicator that someone, somewhere is using $LANGUAGE to make a program like that.

It isn't so much promotion for the program itself, but for $LANGUAGE both to attract like-minded programmers who like it as well as show other programmers that $LANGUAGE is using for making things - which perhaps will give them an incentive to check out the language too, if for no other reason than perhaps answering the curiosity some may have about how a program like that is written in that language.

Hacker News is a place full of programmers after all and programmers do tend to care about programming languages and their uses.

[gchamonlive]

Is it trying to pull merits from the fact that it is written in Rust, though? I think attributing quality claims by default from the language is something you are projecting on your own. The title just says it is "written in Rust", not "written in Rust, therefore better".

[eyko]

After trying out Hyper (electron), Warp (Rust) and iTerm (Objective-C, Swift), I'm not as much interested in the language itself, but at least the fact that it's not an Electron terminal. So I guess I do subconsciously project the "therefore better", not because it's Rust, but because I'm assuming it won't grab a couple GB of memory.

[bakugo]

> The title just says it is "written in Rust", not "written in Rust, therefore better".

Why does the title say "written in rust" then, if not because the author believes it's inherently worthy of merit? It's largely irrelevant to users of the software.

[timeon]

For those who may be interested? Why does it bother you when it is not relevant to you?

I follow HN mostly through RSS with various filters. Rust is one of the keywords that I follow.

[eredengrin]

Not sure if you are referring to the title specifically or the trend in general, but the title is taken almost directly from the one sentence blurb on the wezterm site. As a general description, I can see why as an open source project it would be useful to include the implementation language as one of the first descriptors of the project, and this seems to be fairly common practice. For example, look through just about any This Week In Matrix [0] blog post and you'll see various projects described as "x written in C" or "y written in C++17" or "z written in kotlin" etc. Programmers/sysadmins are curious so for a tool aimed primarily at that demographic, I don't see why a project shouldn't include that it's written in rust just to avoid grouping itself with the other trendy rust projects (as you likely wouldn't have complained if it were written in eg c++ and advertising that fact in its one sentence description).

[0] https://matrix.org/blog/posts

[Strom]

It's not irrelevant for open source. As a Rust programmer I find these projects much more interesting than say COBOL, which I don't use. The ability to fix something myself is a big factor in my choice of what software I use.

[flykespice]

> In what something is written is irrelevant

Would you say the same if something was written in FORTRAN, COBOL or assembly?

[crispinb]

Much as it can be irritating for a hype/hate-intolerant person (I am one too), you cannot possibly contend it's irrelevant here, so you'll just have to put up with it.

[kvark]

Is it really? If I see a game written in, say, Haskell, this grabs my interest. What’s wrong with looking at Rust written software?

[cstrahan]

Knowing something is written Rust does tell me that it will be relatively easy to add my own features (possibly upstreaming those changes if others so desire) and fix any bugs I find.

Why? Because a project written in Rust will certainly be using Cargo for package management, which is absolutely delightful relative to just about any other language’s package manager.

I can git clone and start hacking on just about any Rust project almost immediately. If I’m using 100 tools throughout the day (that’s a conservative estimate) I’d much prefer each of those were written in Rust than C or C++, for instance. Otherwise that’s 100 opportunities for me to find a missing feature or bug and end up futzing with autotools and cmake and ninja and distro-packaged but-not-quite-the-right-version dynamic libraries and broken pkg-config files and and and…

As an example, I recently needed to add support to probe-rs for debugging embedded devices via JTAG with a CMSIS-DAP probe. One git clone and I immediately have all of my dependencies resolved, my editor immediately has go to definition and autocomplete working, and I have a host of debug target definitions for debugging probe-rs itself.

OpenOCD doesn’t support the chip I’m targeting, so if I wanted to use that instead of probe-rs I’d have to first set up a dev env for it and add that support myself. That consists of using a tool like bear to trace the build execution so it can spit out a compile_commands.json file so the C and/or C++ language server can make sense of the project. Oh, and I need to repeat that step if I realize later that I missed a couple defines, otherwise the lang server will think huge swathes of code are preprocessed-out. And this is all after I’ve chased down the myriad of build and runtime dependencies.

I find missing functionality and/or critical show stopping bugs regularly in the tools I use, and it doesn’t matter if the tools are commercially funded or super popular or whatever: I opened an issue for a critical miss-linking problem in Google’s bazel build rules for the Go language, and that’s still open something like 6 years later. And ironically, I discovered the bug while working on a project that uses Go, C++ and C++ protobufs — two of those things are Google inventions, and the other is a predominant language in the Google stack! Their own stuff doesn’t even work together.

So no, it’s not a matter of me choosing bad tools, to be clear. I’m just often put in a position that the best course of action is rolling up my sleeves and fixing whatever issue I’ve discovered.

For someone like me, knowing something is written Rust gives me some peace of mind, knowing that it’ll be (comparatively) easy to work on when I inevitably discover a deficiency. Not because the language is great (though that’s also true), but because the package management simply doesn’t suck.

So please, please stop with the fallacy that “it has no merits on its own”. It does have merits, though maybe you don’t personally appreciate them. And that’s okay. But some of us do appreciate those merits — and they very much unequivocally, objectively are there.

[DannyBee]

It is also unlikely, being a GPU based terminal, that it is written without lots of unsafe memory munging and other fun things, since the underlying API's are still C/C++, and even if they aren't, interacting with GPUs and other hardware is just hard sometimes if they haven't been built thinking of your programming of language. There is of course, a difference between wrapping C apis and them being automatically unsafe, and using lots of unsafe rust like memory transmutation/etc.

In the case of wezterm, a quick glance shows that not only is this correct (lots of unsafe rust, even beyond the normal use of wrapped functions), there is also not a lot of documentation about what the safety conditions of the various unsafe code is.

(which is the usual good practice in handling this sort of thing).

So to your point, saying it's "written in rust" doesn't matter here.

[einpoklum]

> since the underlying API's are still C/C++,

If the use of GPUs is via CUDA, there are my wrappers [1] which are RAII/CADRe, and therefore less unsafe. And on the Rust side - don't you need a bunch of unsafe code in the library enabling GPU support?

[1] : https://github.com/eyalroz/cuda-api-wrappers/

[DannyBee]

You do, but people here really don't like to admit the rust ecosystem is like that. There is plenty of code that is infinitely better and safer than the equivalent C++ would ever be.

There is lots of "bad" unsafe code that is much worse, and over time, they will have just as much trouble trying to handle this overall as C++ does.

(and no the ability to say you don't want unsafe transitive crates doesn't fix anything)

[rickette]

A few years back lots of posts included "written in Go". I don't we'll ever get rid of it...