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.
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.
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.
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.
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.
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.
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.
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.
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.
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 mean, yeah... but I bet if Zig gets really popular, it will attract similarly toxic weirdoes.
Also if we're only judging whole communities by their toxic minorities, then... I'm so sorry Americans reading this, I've got some bad news for you, lol
What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
> What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
Yes, that is the rational thing to do. I don't think anybody disagrees with that. But that's not how a lot of people go throughout their day. There are a gazillion languages to pick up nowadays, and I think many experienced devs only have a casual interest in picking up a new one. If you've been interested in picking up a system language, I can easily see why you would steer away from Rust towards Zig.
And just to clarify here. You shouldn't judge an entire community based on their toxic minority. But as a community, you can't also ignore your toxic minority. Like it or not, they do represent you. And they do scare away potential newcomers who aren't already sold on the language.
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.
I've always found juniors to be the most prone to being "clever". Writing complex things for the sake of it. And it's one of the things I think you need to get over if you want to be considered medior/senior. A senior that loves being clever in an actual product is dangerous. Keep that stuff for hobby projects.
At a web agency I used to work at this was definitely a thing we had to teach the juniors. Whatever you built now is going to end up in maintenance with a support team that doesn't have as deep of an understanding of the project. Being overly clever now is going to be a pain in the ass later.
"Keep It Simple, Stupid" is an important skill for a professional.
> 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.
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.
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.
From what I can see, it would be more accurate if they wrote "slopped by LLMs" :-)
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.
> Coherencey from LLMs decreases as the source increases in volume, waiting to see how this all turns out.
I wonder if feature velocity closely tracks LLM context management innovations.
May be this encourages more modular systems if those improvements can't come fast enough.
If the design was done with Claude Code/Design it would be a lot better than this imo. Bland, but better.
No, it is an advantage.
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.
"single binary, no dependencies besides crypto" would be an advantage, "written in Rust" tells nothing, except (successfully) trying to clickbait
There is no lie or misleading information about rust in the title so it’s clearly not clickbait.
> There is no lie or misleading information about rust in the title so it’s clearly not clickbait.
That’s not what clickbait means at all.
That’s exactly what clickbait means:
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.
https://en.wikipedia.org/wiki/Clickbait
It expresses the exact same thing you've just said and more with fewer words.
no, it's just clickbait.
- 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.
I've been writing Rust for over a decade. Yes, "written in rust" says something.
You can write git in any language, I don't see an advantage doing it in Rust besides the community and potential of promotion to that community.
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.
The benefit is the static compilation.
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.
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.
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.
This totally depends.
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.
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.
Is that even controversial?
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.
> Rust even doesnt do the static binary file by default.
Huh? It does. Only libc is dynamically linked, by default, which --iirc-- all programs will commonly need anyway. All the rest is statically linked.
In fact, it takes some hoop-jumping to build dynamically linked binaries with cargo.
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.
I really was just commenting on the "Only libc is dynamically linked" bit. But yeah, there are cons and pros of dynamic vs static. :)
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.
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.
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.
GitHub used to be great when the frontend too was in ruby, the react rework might've got somebody promoted but performance was never the same.
GitHub is so data heavy and there's so little reactivity that it should really be server side rendered.
The frontend was Ruby?? Are you sure?
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.
[1]: https://coffeescript.org/ [2]: https://opalrb.com/
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.
As in rendered server-side.
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).
>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
None of this makes Rust worse as a language
What? This doesn't make sense, how is it Rust's fault if people are being lazy and tribal?
It's not the fault of the language itself. But the behaviour gives people bad vibes, and they don't want to associate with the community anymore.
Keep in mind. Learning a language usually also means you interact with the people in the ecosystem at some point.
The community seems normal? Take this popular thread for example:
https://www.reddit.com/r/rust/comments/1tcrmjs/rewrite_bun_i...
Many seems to be very skeptical and concerned about Bun being vibecoded.
The rest of the subreddit is basically people showing off their work.
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 mean, yeah... but I bet if Zig gets really popular, it will attract similarly toxic weirdoes.
Also if we're only judging whole communities by their toxic minorities, then... I'm so sorry Americans reading this, I've got some bad news for you, lol
What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
> What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
Yes, that is the rational thing to do. I don't think anybody disagrees with that. But that's not how a lot of people go throughout their day. There are a gazillion languages to pick up nowadays, and I think many experienced devs only have a casual interest in picking up a new one. If you've been interested in picking up a system language, I can easily see why you would steer away from Rust towards Zig.
And just to clarify here. You shouldn't judge an entire community based on their toxic minority. But as a community, you can't also ignore your toxic minority. Like it or not, they do represent you. And they do scare away potential newcomers who aren't already sold on the language.
I don't think anyone's disagreeing with you that it's "best", but people are stubborn, irrational beings at heart.
> if people are being lazy and tribal?
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.
Rust is definitely a hotbed for the kind of smells/red flags I used to associate with C++ Template Demons. "I typed every line myself" ok and?
> I used to associate with C++ Template Demons.
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.
I've always found juniors to be the most prone to being "clever". Writing complex things for the sake of it. And it's one of the things I think you need to get over if you want to be considered medior/senior. A senior that loves being clever in an actual product is dangerous. Keep that stuff for hobby projects.
At a web agency I used to work at this was definitely a thing we had to teach the juniors. Whatever you built now is going to end up in maintenance with a support team that doesn't have as deep of an understanding of the project. Being overly clever now is going to be a pain in the ass later.
"Keep It Simple, Stupid" is an important skill for a professional.
> They claim it is better just because of the language
I mean, it clearly is better (in certain contexts), see e.g. https://blog.google/security/rust-in-android-move-fast-fix-t...
> 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.
I can imagine LLM can, or will be able to, write safe C too. At least safer than people can.
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.
"Written in Rust" signals some common attributes.
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.
I'm happy to label myself a Rust fanboy, but
> few/shallow dependencies
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".
Sadly I couldn't find an example at the moment. We're probably better off striking my parenthetical claim then :)
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.
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.
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.
The offering in question is "A better GitHub" so you are correct. That is an actual quote from the FAQ [0] by the way.
In comparison CodeBerg [1] and SourceHut [2] both offer Git hosting but don't merely describe themselves as "GitHub but X".
[0] https://gitdot.io/faq
[1] https://codeberg.org/
[2] https://sourcehut.org/
Or maybe your audience is developers who might want to contribute to the project, and would prefer to work in some languages more than others.
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.
Not necessarily. It isn't at all unusual to use something because it is useful and also want to be able to make improvements to it.
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 :\
But did you know Rust is memory safe?!
When I see that, my first thought is that there are a bunch of features missing from the original.
Well, it probably is an advantage over the same product written in say C++, all other variables held the same - just not a big one.
It is an advantage
Actually it almost serves like an anti-features to me.
You can only do so if it is "written in Zig"
/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.
Imagine if someone says, written in in plain and pure JavaScript. Is there a difference? What kind of promise it tells about the software?
It is a killer feature. It tells me I can easily compile and edit the code myself.
[dead]
[dead]
This.