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.
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.
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.
That’s not what clickbait means at all.
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.
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?
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.
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.
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.
Linux package management is solved, if it depends on something, it depends on the specific Linux distribution, but "Linux" package management is definitely solved.
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.
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).
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.
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.
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.
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.
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.
> 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.
GitHub is so data heavy and there's so little reactivity that it should really be server side rendered.
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/
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.
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.
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.
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.
None of this makes Rust worse as a language
Keep in mind. Learning a language usually also means you interact with the people in the ecosystem at some point.
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.
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.
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.
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.
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.
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.
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.
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.
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 -_-)
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.
> 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.)
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".
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.
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)
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.
In comparison CodeBerg [1] and SourceHut [2] both offer Git hosting but don't merely describe themselves as "GitHub but X".
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.