I am not a rust evangelist, I am not a rust programmer or programmer at all;
however while evaluating tools to use, anything written in Rust and Go at-least gets me to look at the project in more detail, since they most likely are able to ship statically linked binaries, which has been one of the key criteria for my personal evaluation of tools to select and use.
So, you might not consider it as a valid signal, however it might be for other users. Even if it has a negative connotation for you. Which in itself, again might be a good filter in case you don’t want to use it.
Clickbait (also known as link bait or linkbait) is a text or a thumbnail link that is designed to attract attention and to entice users to follow ("click") that link and view, read, stream or listen to the linked piece of online content, being typically deceptive, sensationalized, or otherwise misleading.
- Rust is huge, many options, many programming styles
- typical Rust project has lots of transitive dependencies
- there is nothing in Rust that disallows using system libraries or linking to them
- it's not even true that the program is going to be mem-safe because there could still be unsafe {} either in the repo, or in any of the transitive deps. not to say that safety is broader than just mem-safety.
if you think "written in Rust" says anything, I'd argue that you might give it a try and find out yourself. I did that, and I am glad I am out. the reason why I am telling you is because I've been click-baited (into Rust) before, and it took me few years to realize all of this, and to make a move.
You can write any program in any language, but there are definitely benefits of using some languages for some programs. If you disagree with this statement, there's nothing else to discuss, we have irreconcilable differences.
You just responded to a comment giving a specific advantage that applies to Rust and a few other languages which doesn't apply to a large amount of other languages (single static binary).
How can you still not see any advantage? Or was the point of your comment to say that you think the only real motivation is self or Rust promotion, suggesting some dishonesty amongst the people you're responding to?
Sure, but we're talking about a git web UI with a little icing, not a git replacement (at least in most cases). Even so, Rust and Go web projects are much more lighterweight than projects in most other languages, with drastically less effort towards performance, and use less resources as a result, requiring less hardware to operate.
How is statically linked binaries an unique advantage of rust or go? you can do the same with C, C++, pascal, ada, zig, and more. Rust even doesnt do the static binary file by default.
You might have better devops experience as an end-user of the said software if its statically linked and its a good trend in software sure but it is not unique to go or rust.
Admitting you don't know how to code and still trying to argue rust is better is just wild sorry.
Zig and probably Pascal have the same advantage, can't speak for Ada as I've never built it.
C and C++? You've got to be joking. If the project provides static binaries, sure, but I don't want to have to worry about finding a necronomicon and summoning the correct kind of imp required to properly use whatever insane build system the project is using.
And thus, we all agree that Linux, Windows, and OS X are all bad software, because they're written in C and C++ and have insanely complicated build systems.
You are missing the point here. Single binary files are not what makes a programming language good or bad.
Its like saying "I want a red car because it goes fast" when people are actually disucssing how the engine works or how easy/difficult is it to drive etc.
You cannot base your like/dislike on that single criteria and expect that to actually make sense.
For some people, Linux package management is not solved. Static binaries at least work for deployment.
More useful for client software, but you can’t just dismiss someone for having this preference given the poor viability of running arbitrary binaries on Linux due to GNU’s userland style.
No, it does not depend. Your parent is correct with his analogy.
Linux package management is solved, if it depends on something, it depends on the specific Linux distribution, but "Linux" package management is definitely solved.
Off: I thought I am becoming dumb, but this really puts me in a new perspective. The odd thing is that even people who work in IT hold similar beliefs. I am not entirely sure what is going on. Favoring a language so blindly seems like a thing, apparently? For example they seem to have convinced themselves that Rust is "safe" if you use it for anything (without implementing the security features) because it is (memory) safe? I did not imagine beginners would make such a mistake either, but alas.
I noticed your comment is getting downvoted. I wish I knew why though. Is it because of your analogy? Is it because they think that somehow "single binary" has anything to do with the programming language? Would like to know. I am not going to assume that it is a confirmation of what I wrote earlier.
There's a pretty strong culture of "no static linking because I need to replace the .so to preserve my freedom hurr durr" in a lot of Linux spaces, so quite a few of these C/C++ FOSS libraries are a pain in the ass to statically link.
Literally last week I was porting something to Linux and had to rewrite the libwayland build scripts because they only expose a shared object.
There's also an expectation that you're going to install them via your system's package manager, not build them, so a lot of them use insane build systems (autotools, meson).
You are right that there are many of us who prefer the package manager, there are so many reasons why a package manager makes your life wonderful. Debian has always been a proponent of dynamic linking. When you create a Linux distribution that is a big plus.
For me install size matters and statically linked stuff are too big sometimes. Of course a 100MB go statically compiled binary has huge advantages now days.
If the binary still depends on libc.so.6 (glibc) at runtime, then it is not a fully static binary (read: not a static binary). It is a dynamically linked executable, albeit one where most non-libc dependencies have been statically linked.
I am not going to pretend I know Rust enough to comment (yes, would be a minute check), I was just commenting on the "Only libc is dynamically linked" bit.
That's the default. One can also statically bind that libc.so.6 quite easily. Though that's not the default.
edit: Ironically, that makes shipping the binary a tad harder, since this "linux" version won't "magically" run on about every Linux, or mac version on mac, etc. I guess that's why its not the default, though that's just me guessing.
It is not about being able to make static binaries or really anything that has to do with anything technical. It is more of a cultural thing - the culture in some languages is to link dependencies dynamically (C/C++) whereas the culture in others is to link dependencies statically (Go, not sure about Rust).
Personally i do not even write Go myself yet when i see some webapp made in Go i'm pretty much always sure that it'll be a self-contained static binary. Yes, there are probably exceptions (and i haven't surveyed all webapps made with Go) but it has been common enough to feel as the standard approach to me - and if i ever decide to make a binary webapp, i'll probably reach for Go to do it.
But the "Written in rust" stuff comes with so much falsehood baggage about automatic best-in-class performance, automatic perfect safety, automatic rigor, that it is detrimental to just say "written in rust" and not provide a more nuanced statement about why that's good (or just drop it as a headline item!). You might not agree because you can single out one automatic benefit of rust b/c of Cargo (not rust), but even that is suspect b/c Rust can ship with dynamic libraries if configured to do so.
In this case, the credibility and benefits are clearer if they said "Static binary". This is all just context. If you see a benefit to that headline, that's ok.
Was going to point that out, as it is irrelevant, but I have seen something far worse.
> 7. How does gitdot make money?
> We don't.
> We are fortunate enough to have raised a small pre-seed round from investors we are happy to call friends, and also to be at a point in our lives where we are financially independent and in good health.
The founders of Artifact said the same thing. They had no plan to make money and once they used their own capital they decided not to continue running it anymore (no-one else wanted to invest in Artifact).
So it is only a matter of time until they eventually need to make money, raise money or shut it down.
I suspect the fact that Github and Gitlab use ruby backends is a significant (although by no means the only) factor in the slowness of Github and Gitlab. So yes, being written in a language that is better suited for high performance at scale is, potentially, an advantage. Although if it is vibe coded, there's a decent chance there are architectural problems that offset the advantage gained from the choice in language.
Not literally. And I would hardly say it was a matter of language superiority. I love Ruby myself. But Github was a lot simpler when it was still just a Rails app.
But Rails was SSR by default, and most of the frontend was just Embedded Ruby (ERB) template files all over the place. And way back when, it was even relatively common to use Javascript supersets like CoffeeScript[1] and Opal[2]. The latter being Ruby that compiled to JS.
Yes, standard rails. Rails does not ship with components out of the box and the most prominent component system for rails was built and is maintained by GitHub. They have been moving to React for the last few years though, it seems to be more about hiring and ergonomics rather than capability.
Reports of Ruby slowness are often exaggerated. Around the time GH was built that was certainly true, but in the ways that matter Ruby is more than fast enough nowadays, even at scale. (Shopify is a rails monolith, as is intercom and a bunch of other massive services) Compute is/was pretty cheap and the economics of ROR mean that it's ultimately not that expensive to run. I think GH's slowness is a mixture of mismanagement and issues on the frontend.
But for sure a systems language is going to be far faster on paper and Rails is far from perfect and does have some performance foot guns you need to avoid. And yeah, architecture is everything.
Yeah, rust programmers are the new software vegans.
They claim it is better just because of the language, ignoring the features gap, the size of the team developing and supporting the software and not having solved any issue with the software they compete against.
And to be clear, this in not in favour of GH, it is against the mentality that the programming language makes better products and programmers.
I was very excited about Rust prior to the LLM-era. I never managed to dive deep into it due to the lack of time, but was really planning to.
Nowadays when everyone and their dog are either vibe-coding with Rust or constantly shouting about it's superiority, I've lost any interest in the language. I'm learning Zig.
Feel the same way about the intersection of Rust evangelists and vibe coders. The amount of undeserved arrogance by some hardcore believers is toxic to their culture. I am learning Rust, because there is merit to the language itself, and there are some useful and quality codebases written in it. But it's imperfect in various ways, most of all the evangelists attacking other languages as inferior and unsafe, and the increasingly common massive vibe-coded monstrosities. It's not that I'm against the use of LLMs, I'm against bad engineering practices and unmaintainable code.
Zig, on the other hand, is a breath of fresh air. There's so much to love about it, including language design that values clarity and simplicity, and the cross-compiler which is how I got started on it, by using Zig as a better build system for C projects. Their move away from GitHub and vibe-coded contributions is also commendable, it's more reason I trust their sensible judgement.
Interesting choice when LLMs remove one of the biggest barriers to entry for Rust which is you have to know almost all the rules to reliably make valid changes to Rust programs (which also helps LLMs at inference time when they make mistakes).
It's not about if the entire community is weird. But that a few vocal people doing something becomes the first impression of the ecosystem. Which is turning people off from exploring further, as you can see in this thread.
You can make the case that if something like this turns you off from diving deeper into the language you probably weren't that motivated to begin with. But it is a noticable effect. This post isn't the first time I see it either. Rust has become a meme amongst my colleagues because things keep popping up with "Build with Rust" before mentioning anything of substance of the project. The phrase "Did you know Rust is memory safe?" is also a running joke in my IRL dev surroundings now.
I have seen developers and managers having an attitude of arrogance just because they happen to code in a specific language. They also look down upon other developers just because they happen to code in some other language. Evangelism combined with arrogance is toxic.
Reminds me of a colleague who rewrote the entire standard template library from scratch to demonstrate his uber-templating knowledge. He was the only one who could debug problems in that. The rest of us were ordinary c++ coders.
> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.
Bugs are not only related to memory and a program cannot be considered safe Just because it got rid of pointers, malloc and free.
If you really think that switching language is the main driver to get safe programs, the you are on the list of people replaceable by LLMs.
Othewise you have to understand that architettural chioces, concurrency, (weak) cryptographic function and user stupidity have a significant impact, no matter what language you use. Memory management is just a part of the problem.
> If you really think that switching language is the main driver to get safe programs [...]
I didn't write that.
> [...] the you are on the list of people replaceable by LLMs.
lol, love a high quality discussion
> Memory management is just a part of the problem.
Sure, then using Rust is a step forward, because that's one less thing you have to worry about. Seat belts don't save all people, but a car equipped with seat belts is - on average - safer than a car without seat belts.
It would be nice if they mentioned anyhting at all they are doing to implement security features. instead of leaning onf Rust which does absolutely nothing in that regard. just look owasp top 10 and observe it has nothing to do with memory safety. and thats just a top 10 of things.
only for very few companies, memory safety issues are a thing. most of those dont use rust because it lacks tooling and certification paths -_-.
rust is like AI and cloud. heavily marketed, not bad, but not as good as whats on the box -_-. it makes life usually harder for a lot of aspects (ofc cleverly avoid in publications about it -_-)
Yeah, this is what the people who have parroted "Rust is safe" have achieved. Rust is not "safe" in the broader sense of the word, only "memory safe". You have to implement the security yourself!
You assume that its used to show advantage, but we are on a technical forum and for me, as an engineer, its always interesting what language or tech was used to create a project.
Fast, Safe, Lightweight, Statically linked (plop a precompiled binary in ~/.local/bin and run it), few/shallow dependencies, senior developers, "Done" software.
Now, certainly no guarantees, enough counter-examples, I know. And attributes that one can get with anything from PHP via Javascript to Lisp as well. Some attributes have stronger correlation than others too.
But, in general, "rust" has a (much) higher chance of meeting these attributes. I care about those attributes above anything else.
is just flat-out wrong. There's (sadly) a big culture of sprawling, deep dependencies in the Rust community. There are of course many counterexamples too, but it's definitely not correct that Rust signals the virtue you refer to.
(Incidentally, the misguided idea among some that as long as a dependency isn't through FFI, it doesn't count as a dependency, is one of the things I dislike the most about Rust culture. That, and pervasive bundling.)
> the misguided idea among some that as long as a dependency isn't through FFI, it doesn't count as a dependency, is one of the things I dislike the most about Rust culture
I have not heard that idea a single time. There's definitely the idea that FFI dependencies "count more" / add more baggage (because there's a bigger risk that the build fails, it's harder to investigate memory safety, ...). Absolutely not that a non-FFI dependency "does not count".
Probably my reference is tainting this then. I come from Perl, PHP (both of which, at that time, had nonexisting or terrible package managing - CPAN, PEAR), then Ruby, with gems and now Python, Typescript/Javascript. Starting with Ruby, I've developed in communities that heavily depend on deep dependency trees.
For me, the discipline of shallow dependencies, no-dependencies etc, was new when I came to rust.
Sure, if I pull in something like Rocket, it comes with dependencies, that have dependencies that have dependencies. But Rocket is one of the more extreme examples I know of, and even that is nowhere near the depth of a tree that common (not extreme) npm frameworks/libraries come with. Before yarn I sometimes had node-module trees that went over 50 levels deep.
The Python community doesn't have this extreme deep dependencies, but in Python it is far more common to "from foo import bar" in both libraries and in applications than to write a few hundred lines of code yourself. The Django and "lean" flask, or "simple" cli apps I worked with and on, quite commonly have hundreds of dependencies (many of which are dependencies of dependencies etc).
Within that context, rust community is far more conservative. Many of the dependencies that I use have one, maybe two of their own deps. Many none. And it's more common - IME - to see libraries that have just one level of deps - the libs a lib depends on, itself won't have deps.
Though, I guess, C or even C++ community, lacking OOTB, common and easy dependency management like cargo, will be far more conservative even.
Rather than being "flat out wrong", I'd say it very much depends (pun intended) on where you come from and compare rust with.
Oh stop being silly. Yes, the programming language is technically irrelevant in that they’re all Turing complete.
In reality, the programming language tells you all kinds of subtle things: probabilities about the way the software will feel to use, how stable it’s likely to be, how fast, what the author is likely to focus on.
I found one of the best jobs of my life in 2015 by asking “who’s doing interesting things in Atlanta in Go?” Not because I was uncompromisingly settled on Go, but because in 2015, using Go (often) connoted a certain approach, a certain type of engineering, a certain constellation of values.
So please stop pretending the whole gestalt of programming languages and their communities don’t deeply affect the resulting software.
(I say this with no unkindness intended, mostly to all of hackernews)
> but because in 2015, using Go (often) connoted a certain approach, a certain type of engineering, a certain constellation of values
So called "The vibe". And the vibe emanating from Rust is sometimes unbearable. Like claiming the main feature of the project is that it's written in Rust.
It’s one of the first questions people will ask so it’s probably worthwhile to mention it. I didn’t get the impression they did so just because they thought rust was some kind of flex.
If the first thing people ask about your offering is "what programming language did you use when you made this," your offering is probably not that interesting.
If your primary audience is people who want to contribute to it, then the fun of hacking on it is more impactful than the benefit of the offering itself. That's not bad at all! But it also does not suggest that the offering itself is particularly impactful.
This drives me nuts too and your comment is justified.
Recently encountered someone going 'full crab' with rust & vk trying to chase perf, they were not happy when some thoughtfully written modern JS beat the brakes off it even with the overhead of the browser (~2000fps vs 750)
This kind of thoughtless "its rust!!!" shit causes people who don't know better to waste time chasing their tails. Claude seems to encourage it :\
/s, I love zig, but I'm consistently surprised of how popular any post containing zig in the title makes it to the front page almost daily, doesn't happen with any other language.
I am indeed curious to see how an agent-coded project turns out in the long term.
Coherencey from LLMs decreases as the source increases in volume, waiting to see how this all turns out.