Maybe it's just because I haven't worked long enough with C or C++ to complain about them (only about a decade or so), but I don't have any issues with those languages. And I find it wholly unappealing to abandon the existing corpus of literal decades of knowledge having been poured into those language ecosystems all in the name of whatever it is that Rust delivers on. I just have too much experience in the industry to throw away my time and experiment with something I can't take off the shelf and be productive with from day one.
I've also mentioned I just can't stand the way the language looks. It's ugly as sin, and I know I'm not alone in that opinion.
I made some crude comments in a previous thread here on HN about Servo, but still came away with the feeling there was literally no one using Servo, the site didn't tell you how to actually use it, and no one cared, but the hype was unreal because it was web tech written in Rust.
Edit: The points on this post are fluctuating wildly. If you're interested in Rust, could you share your knowledge with some of us who are on the fence like me instead of downvoting? It doesn't actually help me understand anything about the language or community other than I shouldn't criticize Rust because its users will downvote you.
Code from Servo is in every single copy of Firefox, so it's pretty popular as code goes.
> And I find it wholly unappealing to abandon the existing corpus of literal decades of knowledge having been poured into those language ecosystems all in the name of whatever it is that Rust delivers on. I just have too much experience in the industry to throw away my time and play with toys.
Rust doesn't throw away that corpus. Rust draws heavily on that corpus. It leverages LLVM (used to compile C/C++), integrates with C libraries, integrates with GDB, draws a ton of design decisions from actual experience using C++, and so on.
It's a tool that runs inside Firefox, AWS, Microsoft, and a lot of other high-reliability, high-performance areas. It may be young, but it's quickly building (IMO compelling) evidence that it's very much not a "toy." ;)
This is akin to saying the DWM is in every copy of Windows so it's the most popular graphical compositor of all time.
- Instant boot time. Because rust is statically compiled, there's no runtime startup or anything involved with it. From dead to alive is pretty much instant.
- Low memory footprint. Because rust does not use a GC, it doesn't need all the bits and pieces of memory storage that modern GCs require. The memory allocated is (close to) the minimal memory needed to run the application. Further, due to it's low level nature, it's a lot easier to avoid heap allocations all together and instead focus on stack allocations.
- It's safe to deploy and expose to the internet. You'd be a fool to setup a public facing C++/or C application. That memory model is simply too expensive to safely do even if you did want all the benefits of using a system language. Not so with rust. Client facing rust services or even just backends that may see client data are safe to push out.
- It's fast. Rust has no startup or warmup time. From boot it is running just as fast as it ever will be. This means you don't have to have a warmup period or periods of slow runtime as you scale out rust applications. That consistent performance is easy to plan for. That speed and low memory usage have the added bonus of making rust really good if you are trying to optimize operation costs. You can use smaller or less instances to get the same amount of work done.
- The model model not only makes memory safe, it prevents different types of concurrency bugs. While rust won't prevent ALL classes of concurrency issues, it will prevent several of them. That makes it easier to write parallel applications.
Bringing data to this discussion, many of the big tech companies have found that ~70% of CVEs are due to memory bugs (free after use, double free, etc.)[0], and these are prevented by Rust's model.
[0] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
Dynamic linkage is not the slow part of application startup. The slow part (for applications which are slow) is almost always the gathering of non-compiled assets from disk.
IMO, the lack of dynamic linkage is Rust's #2 weak point, second only to slow build times.
For greenfield, though, my feeling is that one should justify why not using Rust, at this point (when building stuff that was previously the realm of C/C++, of course). If it’s just because of unfamiliarity and initial slow speed of development (as people learn it), it becomes an issue of institutional laziness more than a technical choice.
Rust is not a toy. It's possible that your prejudice stops you from seeing Rust's benefits. It's also possible that you're working in a niche where Rust's advantage compared to C or C++ isn't as great as for most other areas of software development. And that's okay, Rust isn't quite there yet. For some very small niches, it might never be.
> [...] existing corpus of literal decades of knowledge having been poured into those language ecosystems [...]
Frankly, even with those "decades of knowledge", C programs and libraries are still full of security vulnerabilities caused by C's limitations and memory handling. How many more decades will it take? How many more thousands of vulnerabilities?
This may be part of the reason. Rust improves on those languages in many ways including better safety, package and build setups as well as doc setups. It's genuinely a breath of fresh air setting up and maintaining rust projects versus C++ or even Python.
> I find it wholly unappealing to abandon the existing corpus of literal decades of knowledge having been poured into those language ecosystems
Rust builds on these ecosystems. It uses LLVM as its backend compiler, much like clang does for C++.
Additionally it has great support for CFFI so it can integrate very well into existing codebases with other languages.
> I just have too much experience in the industry to throw away my time and play with toys.
I read this as prejudice. Rust isn't a toy as can be seen by the large number of companies and projects that are putting significant efforts into it.
Conversely, perhaps having entrenched experience in the industry means you're predisposed to approaching new paradigms in the field with higher cynicism than may be warranted?
> It's ugly as sin, and I know I'm not alone in that opinion.
I think that's very much subjective. I do know many programmers who find it ugly, but many like myself who find it write clean to read.
Certainly I find it significantly easier to grok than C++ or Objective C for example. It's possible to write very elegant rust code that can verge on being Pythonic in nature. It's also possible to write very ugly code too.
> there was literally no one using Servo, the site didn't tell you how to actually use it
Servo is a research project from which portions have been taken and integrated into Firefox. That means a lot of people are using servo whether directly or indirectly.
I do definitely wish there was an easier way to go about Rust's C FFI, though. LuaJIT has spoiled me. All you do is preprocess headers and then you have access to all of the exports without having to do any work whatsoever.
* Real pattern matching and sum types. std::variant doesn't cut the mustard
* Traits and derivable impls, rather than obscure operator overloads with fussy cv-qualified signatures
* No iterator invalidation bugs (among the worst C++ issues to debug, IME); no inheritance or need to care about "virtual destructors"; no "object slicing"; no crazy interactions between overloads and templates which require an IDE to determine which function you are actually calling
* Way better compiler error messages than clang or gcc
Each of those "no"s is something I've spent days if not weeks of my C++ career debugging.
The welcoming community is another great reason, but I'll let community leaders speak to that point.
In terms of how the language looks... the important thing is that `rustfmt` standardizes this, so you only have to learn how to read one style, and not a different style for every developer you work with.
It offers me so many of the joys of Go with more power. Some negatives too of course, but a big boon for me in learning Rust was realizing i didn't always have to reach for the biggest tool. Sometimes a simple Clone or [A]rc was perfectly okay, especially when comparing it to Go - my benchmark.
Rust became as developer efficient for me as Go was, and then more so when i leveraged the huge surplus of code locality tools like Iterators and various functional patterns (.map, etc).
Plus, now i get to play with new toys like WASM without a GC or game engines! I miss almost nothing from Go and gained so much power when i want to reach for things. Most of which, like Iterators, are power with little to no cost.
I've been a Rust fanatic for a couple years now, and C/C++ were not even in my toolbox. I think Rust can hit a lot of sweet spots for a very very wide range of people, eg non-C/C++ domains. Which isn't an argument for its usage, but an explanation for its popularity.
I feel like C++ can get really out of hand, so not having a cppfmt is surely a thing of jealousy.
I work with codebases and projects where the expense of time is far too high to justify its usage, especially in existing designs where there is no meaningful way to extend the codebase with Rust. Believe it or not, but there really are a lot of us out there who just do not have memory (safety, ownership, or otherwise) problems with C or C++.
It sort of feels like the argument people make with static typing vs dynamic typing. It's just not a concern I have.
Perhaps with enough time and coercion I'll find a reason to use it.
> I just have too much experience in the industry to throw away my time and play with toys.
Implication: Rust is just a toy, people who use it have too much time on their hands, and they're not experienced enough to have good judgement.
IMO if you're interested in a productive conversation you'd probably have better luck if you simply omitted content like the above: it doesn't add to the conversation, and is inevitably going to raise hackles among those who disagree with you.
Cargo as a standard build system, package manager, and test runner. This makes for a much more coherent development environment than the tire fire that is C and C++'s build, test, and package management story.
Developing tests is much easier than in C and C++, which means many of the packages are actually reasonably well tested (maybe not perfect, but better than the average C or C++ package you might want to incorporate into a project).
Rust has a pretty good module system. C has nothing of the sort, and C++ has a mix of things that can be used similarly (classes, namespaces) and only recently got modules proper in C++20. This helps a lot with organizing your code into a modular structure and then sharing that code with other projects.
Rust can call and be called from C, so there is no tossing anything out. You can integrate Rust into an existing project one file at a time. Move your more critical code into it, and let other code call it. Going back to concurrency, put the part that generates and manages workers (as an example of one model) in Rust and leave the rest of the logic in C or C++. Gradually migrate the worker logic into Rust, or not. Perhaps it's a library that you don't control or don't want to change.
Some things aren't pretty or aren't clear. For instance, str and String are pretty confusing for new users. But the compiler will catch these for you. Speaking of, actually decent compiler warnings and errors. Often with potential fixes included, which usually do what you want.
In summary: Fewer footguns, better quality of life components, better language features in some areas (type system, modules, in particular), no performance hit (or no major performance hit) compared to other options for languages attempting to offer improved safety (where safety could be along many dimensions).
The communities of statically typed programming languages were especially elitist and gatekeeping.
The Rust community is welcoming.
The Rust community has proven itself, outside of the Rust specific forums, to be exceptionally elitist.
And, as shown in a sibling thread, the founders of Rust are right there on the dogpile attacking the character and dissecting the comments of any dissenters.
Some one here in a separate thread said, "I don't understand your hate," and I'm like, what hate? It's a programming language. I don't hate it, I just don't yet find a reason to use it, but maybe I'm missing something really big.
It's not really welcoming at all in my opinion. It carries all of the familiar facets of being a hyped product that people love, and if you question it you're not only wrong, you should be torn down because of your opinion.
>all in the name of whatever it is that Rust delivers on
If you haven't bothered to groc the purported benefits and you have not decided to reject them on their own merits then yeah, I'd say you're just being a grump.
Feel free to not like Rust but your complaints don't show a lot of effort in trying to understand it.
As far as what you lose when you try new languages, you really shouldn't worry so much. A vast majority of your skills as a programmer are portable.
But I think back many years, when I was put on a project written in Perl. At first I balked at the syntax.
I can see $foo on the right of the equals sign, but on the left? And $_ and @_ and regular expressions everywhere like line noise.
But working with it for a bit... and all of that just disappeared as I became fluent. They just started becoming idioms in my head. And after a while, I found Perl the most expressive language I've ever worked with.
So, maybe you just have to get over the hump?
(But yeah, I thought python was too ordered, but I switched and it's pretty much my favorite language presently)
The world isn't made up of people who either love or are threatened by things. Could you not use this language?
People who care about such things are really hyped because it's a truly new idea in a mainstream(ish) language.
That program has been running in production without any issues since then. We use PHP for most other projects at work. I can assure you that this kind of thing is not possible with PHP.
So in short, Rust forces me to think about every edge case and error path, so I can feel confident that my code really works, even in the face of obscure situations.
In fact, this is also the first line in the AWS article in question:
> One of the most exciting things about the Rust programming language is that it makes infrastructure incredibly boring. That’s not a bad thing, in this case.
The only language I've had a similar experience from is Typescript.
That it's fast or uses only a little memory is just a bonus for me.
In an effort to be transparent, I will downvote your comment because I like novelty and interesting new things, not the nth version of a BSD is dead or Vim v Emacs discussion, which is what you're spawning.
This is an opportunity to educate/advocate. Someone who wants to do that might link to a good article, rather than just attempt to shut down the discussion.
This isn't a facetious statement. I'm trying to keep this on topic: AWS loves Rust, so maybe I should, too. Could we have a discussion about why?
The mechanism you're using is probably one of the most irritating features on HN and Reddit to me.
In order to make a comeback, Java first needs to fall from the TOP 3 languages used by professional programmers in the world.
https://insights.stackoverflow.com/survey/2020#most-popular-...
We love it and wouldn’t trade it for a different language at this point.
P.S. we’re hiring remote and sf Bay Area. If you are interested in working on digital cash for use in messaging applications, drop me at line!
It has a nice niche where it's less chaotic than JS and has better threading support and uses less cpu/ram than JS and python. But it's still high level enough to not be inconvenient to work with. These traits make it a great fit for beefy back end machines at big companies.
Rust will always be targeted at low level work unless they add a GC. Even with lifetimes etc a GC is just way more convenient
EDIT: may the downvotes come from the idealists that hammer down pragmatists, like our opinion doesn't even count
Having maybe kicked off a small flamewar with my above comment, I will admit to being curious to contribute to deferring the eternal september of rusts community and how welcoming it is with all the influx of new developers, myself incuded in em.
Theres probably a netiquette equivalent somewhere, but beyond "don't act like the rust evangelism strike force" of n-gate fame, I'm fuzzy as to its details.
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Apple-Fr...
(Well, Firefox adding more Rust is correct, but the rest is not.)
So I have mixed feelings about too many clever people doing too many clever things to an awesome language.
On the Rust language team, we are extremely mindful of managing complexity, and we typically err on the side of not including a feature (even if it's desired) if it feels like it adds too much complexity or surface area to the language. We've also paid attention to other language design processes and learned from them.
That being said, we (that is, the Rust team broadly, I am not on the language team) do weigh companies' desires fairly heavily, because we want Rust to be used for real, important things by companies. But it's always a balance. Famously, the lang team even resisted some proposals by the Servo team way back in the day, even though most people involved on all sides were Mozilla employees at the time.
> Let’s be clear: We understand that we are net beneficiaries of the exceptional work that others have done to make Rust thrive. AWS didn’t start Rust or make it the success that it is today, but we’d like to contribute to its future success.
I hope Amazon will keep the open source nature of Rust. This post is obviously from an engineer, but i fear the day business people will start looking into ways to leverage the contribution Amazon made to Rust.
And, I should add, the real contributors are the engineers who do the code. AWS is committing credits/cash/other, but when it comes to the engineering, we are hiring committers so that they have time/resources to continue to do so. But it's those engineers (and engineers from other companies) who are doing the work.
I'm very, very grateful that Facebook and others have also been hiring Rust committers. It's better as a community, not as one company's programming language, even a great company/org like Mozilla.
So, no, don't worry about AWS taking over Rust. We couldn't and don't want to. Rust has done so, so much right as a community-led project: welcoming, inclusive, kind. We hope to contribute to that, not commandeer anything.
Not really. The post is by Matt Asay who's title is Head of Open Source Strategy and Marketing. The post reads like an attempt at improving upon the negative image AWS has garnered in open source by making money on open source projects without paying, or sometimes without even crediting, the authors. Most recent examples include Headless Recorder[1] and before that Kafka, Elasticsearch etc.
As for Headless Recorder, we're working with Tim now. That was a miss on our part, one that I (and the team involved) regret. But I don't regret you and others calling us out when you feel we've done wrong. AWS is not a perfect company, but I've been gratified that people here (in my experience) want to do the right thing. Sometimes we need help figuring out what's right in a given situation (or, rather, what's the right way to help customers. Increasingly you'll see teams understanding that more upstream contributions might be the best way to help customers in the medium- and long-term, even when it's not necessarily the obvious way to help them in the short-term). So please keep helping us do better.
Apple and Google both use Rust too. Amazon also uses other languages.
The languages you mentioned were developed in house by those companies, rust is independent
No? Project sponsorship, either direct or by hiring prominent contributors, have a long history in OSS support and have little to do with "owning" languages.
Did Google or Dropbox take ownership of Python when they hired GvR?
> I hope Amazon will keep the open source nature of Rust.
What are you talking about? It's literally not their decision to make.
We're still very far from that point, but i've seen worst things happened in the history of big megacorps.
From a compiler perspective, Rusoto takes a long time to compile. Some of that is just the sheer volume of code, but also, it wouldn't surprise me if it's hitting bottlenecks in the compiler (e.g. a recently fixed issue in the performance of #[derive(...)] on a huge number of structs). Getting appropriate bits of Rusoto put into the compiler's performance testsuite could help, and profiling the compiler on it would likely turn up some areas for improvement.
I would also love to see support for using Rusoto on non-Tokio runtimes. Given the amount of code generation used for Rusoto, abstracting over the remainder (such as the choice of async traits) based on a feature flag would hopefully be feasible.
Is it really? Seems to me like that would easily be seen as self-serving, while putting efforts into the ecosystem as a whole means even people who don't care a whit for AWS benefit.
Now someone needs to take over MDN . By far the best JavaScript documentation
Case in point: Both the MDN Github repos and the MDN docs (or at least all the pages I bothered to look at) show very recent activity:
https://developer.mozilla.org/en-US/docs/Web (scroll all the way down to "Last modified")
https://developer.mozilla.org/en-US/docs/Web/CSS
https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re...
I'm happy to see community involvement, but it's such a vital resource that deserves funding
Barring surges in demand at month-scale timelines, this isn't a zero sum game. Competition for Rust talent will result in an increase in the amount of Rust talent. Even better if you're open source; a growing population of Rust devs roaming the planet can only help you.
It looks like Rust gains bigcorp support, all we need now is a killer product written in it to kick off explosive growth.
All the phones that support it feel like throwbacks from 2003. (It's KaiOS, btw)
> Servo was incubated inside Mozilla, and served as the proof that important web components such as CSS and rendering could be implemented in Rust, with all its safety, concurrency and speed. Now it’s time for Servo to leave the nest!
Is there any chance they do the same with the Rust language? Either way, Mozilla has done a huge amount of work to improve the systems programming field, and created an incredible language ecosystem in Rust.
Ockam.io loves Rust, and we are hiring!
Also, there's an "Ockam Values" header right below with no content under it. Edit: but not if I go directly to the page. Maybe it was a transient Chrome bug.
You may want to note that there's a pretty damn big difference between the two: the rust project needs to be interoperable with itself and that's about the extent of it.
The web needs to be interoperable period, so if there isn't some sort of buy-in or the ability to push your weight around, spec-ing or implementing something is just a waste of time.
Putting resources into the language doesn't mean you control it, and volunteer-driven projects go where they will. Python or Ruby are not owned by their sponsors.
Getting funding and support is great, but the needs of the many are very different than the needs of AWS and Facebook.
In my opinion we see this a lot in Linux as well. What Google wants has almost nothing to do with what I need. (I said almost).
I think it should gestate a while in a less FAANGy environment.
AWS is paying developers to primarily work on it's needs for Linux (as that is how Linux is generally maintained, you upstream a module, you maintain it).
In Rust on the other hand (like most/all languages) new features tend to benefit everybody, AWS simply might be able to prioritize development of certain aspects, but they certainly don't get to make work almost exclusively for them.
The Rust community seems quite desperate for corporate money and support. Amazon's not paying you out of love fellas, even if it says so in the blog post's title.
[1] https://www.tbray.org/ongoing/When/202x/2020/04/29/Leaving-A...
Nobody believes they are doing it solely out of love, but luckily, that’s not required for it to be a productive relationship.
If there is an opencollective somewhere, I am not than happy to give you the money directly. I support Mozilla and Wikipedia and other projects to my best effort, and I would love it if others can do that too.
All Amazon has ever done is lip service to open source. There is a multibillionaire at the top with no need for that money who every day costs not to do something good for the planet and is instead enabling commoditizing the general populace.
Large codebases will be able to transcode to language X at some point in the future and I am waiting for the day when it can be done for Rust with projects like https://github.com/facebookresearch/TransCoder/
I really like AWS products and Rust is the first system programming language I'm really interested in.
Because it's cool and they want a spot on that poster?