Why AWS loves Rust, and how we’d like to help
aws.amazon.com
aws.amazon.com
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-...
Java is currently losing Android devs to Kotlin. That could cause a precipitous drop in direct usage in the coming years.
A Java developer will pick up Kotlin much faster than, say, a Postgres developer will pick up Mongo. It takes a lot longer for a Java programmer to learn the Android environment than the Kotlin language.
If there were a trend from Java towards Rust or Go or Python, that would be a significant change in the world. If Java were to vanish tomorrow and everybody had to pick up Kotlin, the world would be pretty much the same in a week. Kotlin is nice, benefitting from a clean-sheet implementation of lessons that Java takes on only with difficulty, but it's not a wholesale break.
Similarly, "web app" isn't a programming language, and neither is "server side". But they are toolkits that a developer must learn on top of their programming language, and it takes longer than the actual language itself.
That's very much not true. I've personally done contracts for developing PostgreSQL related code and/or PostgreSQL based projects.
P.S.: Also I say Java, but I mean JVM, I club all JVM languages together, since that's more what I care about, is the strength of the Java ecosystem.
Caution doesn't make money, it just prevents losing as much money. When it comes to technology if you're waiting for everyone else to validate an idea, you're too late.
AWS loves Rust in the same way than Facebook loved PHP.
That doesn't mean much because it is true for probably most serious technologies out there. Most of those organizations also have a perl script somewhere. Does that mean their core products are written in perl? Nope.
That being said, Rust is certainly successful and seeing growing adoption.
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
- You are hijacking a top comment to insert your off-topic opinion.
- You appear to be more territorial than presenting some sort of argument.
- You are overly negative and somewhat dismissive/disrespectful.
- You are commenting on downvotes, which is generally frowned upon
If by "you appear" you wanted to say "it appears to me" OK. It didnt appear to me.
OP is a little big negative, so that's great to temper the "a little too positive" comments.So it's a win in my book.
Yeah I agree with your last point, but I also consider the ones who downvote because that equally as petty, adding more noise to the site.
Rust isn't going to replace Java, but it may supplant Java in a lot of fields where one wants both memory safety and an OO language with high performance. No one is (rationally) suggesting that Rust will replace every language.
The tone of your post, however, makes it sound as though you have something against Rust, and that you're more interested in pointing out all the things it's not good at, or shouldn't be used for, rather than contributing to a constructive discussion.
> I also pointed out that Rust has to win the mindshare of C++ programmers first, before even reaching other ecosystems
Not entirely true; Rust is an alternative to C++, but it's vastly more accessible to people who've used other languages like Java, Python, Ruby, and so on, where you get types, OO, and memory safety. Instead of simply resulting in a 1:1 replacement of C++ with Rust, it may result in a minimal reduction in C++ programming and a notable increase in Rust programming which would have been done in another safe OO language instead, but at dramatically worse performance.
C++ is just a tool, as is Rust. Rust does not need to win the mindshare of C++ programmers first to become successful. It only needs to itself as a viable alternative in whatever fields people find it useful. I believe it has.
Between WASM, embedded, and even Web development, I see a lot of "mindshare" being attracted to Rust.
They're replying to a line about a Java comeback by saying there's a lot of big data libraries/systems used by Java developers that it'll be difficult to compete with.
I don't know the big data space well enough to judge.
Both are general purpose languages, so of course they overlap.
> Good luck rewritting all the big data tools from Java (Elasticsearch, Spark, Kafka, Hadoop, Neo4j, Deeplearning4j, Cassandra, Solr, Arrow, OrientDB)
Cassandra (https://scylladb.com) and Kafka (https://vectorized.io) have already been rewritten once in C++, with massive latency and throughput improvements. No reason why they couldn't get their superior Rust clones in the observable future.
Materialize (https://materialize.com), Noria (https://github.com/mit-pdos/noria), and Sled (https://github.com/spacejam/sled) are just some of the Rust database projects that are aiming at unseating the de facto standard implementations in the space. InfluxDB (https://www.influxdata.com) is now doing major Rust development as well.
The future is almost here. It's just not evenly distributed yet.
It is not a single dimension problem as they try to frame it. Performance is a single dimension of systems. Java with GC is a memory safe solution compare to C++ (hello segmentation faults). The reason why the C++ implementation is faster is not that it is written in C++ but it is written using a different approach. There are plenty of Java HFT systems that run circles around C++ systems yet we cannot draw a conclusion that Java is better suited than C++ for HFT. Implementation details matter, code quality matters and performance does not come purely because you pick a particular programming language. Btw. most of the systems which I was working on using Cassandra instead of ScyllaDB because the companies were not ok switch up for some performance gains (because Cassandra was performant enough for their business use case). I think what you receive as superiority is not as clear cut as you try to make it.
From a current perspective I may agree, but in the ‘90 a number of programmers like me was really excited to be able to develop at a much higher abstraction level than C using classes and, later, templates, preserving efficiency and performances.
Yes, Java applications and Rust mostly don't overlap, but there are exceptions in both ecosystems.
Rust might offer some advantages for Data Engineers (the same way as CUDA applications in C++), not all of them as with every language else, and yes you can write Data centric libraries in Rust for Python (easier than C/C++ IIRC).
And no, there's no need to rewrite existing services to Rust, it can interface with all the examples you cited.
To me Rust is just a simpler and safer C++, if you said you would program C++, you probably will want to program Rust, writing C++ bindings for Rust is basic stuff nowadays
That said, I don't think anyone was suggesting Rust would displace Java. The OP was pretty clear IMO that his firm had experienced exponential growth in interest in Rust skills while he had been hoping that interest in Java would grow instead. This doesn't mean that Rust will replace Java for data engineering or any other domain in particular.
Give it 20 years and I can see it doing to Python what Python did to R.
More or less because there is some overlap: for example, people write low-latency trading systems in both. But it's very hard to get Java to perform well at the kind of work where Rust shines naturally.
There is also very little overlap between Rust and Go. There's far more between Java and Go than Rust and either!
Yep, this is true. Java has an upper hand in data engineering. There are better languages for targeting the Java libraries and JVM than Java itself. I always use Clojure instead of Java when doing data crunching because it is much easier to create parallel programs with it. Kotlin is also coming up in this space.
Having said that. I like Rust for some reasons:
- targeting multiple libc (musl, no libc at all)
- targeting multiple platforms (ppc, mips, etc., even though some of those are tierN)
- having ML features
Why I do not like Rust:
- accidental complexity and convoluted syntax (maybe it is only me, but it is very hard to follow what is happening)
For me the ideal language would be something like F# with the good parts of Rust.
You mean one is already shipping Rust and another seems to be on track to shipping it soon?
> For now, Chrome investment in Rust will remain a background investigation (mostly directed towards prototyping these tools and techniques). If we become convinced this sort of interoperability is possible, we’ll revisit widespread use of Rust in Chrome
[0]: https://www.chromium.org/Home/chromium-security/memory-safet...
It would be unfair to blame rust. But that example doesn't provide confidence that switching from c would be a great idea.
I was mainly responding to this statement which came across quite aggressive. Java and C++ do not need comebacks and my comment was intended to be a wake-up call to reality. Yes, it is great to learn Rust on the side, but advocating something to be used everywhere is another story.
Where is that in the comment you replied to?
And as for browsers, you know Mozilla created Rust specifically for Firefox?
I agree that Rust is still early for most adopters.
There are a subset of people who need to solve problems that would normally be solved in C or C++, but they don't know or don't want to use those languages. Those people generally love Rust (I am in this camp).
Then there is everyone else, who either like Rust because it's a cool language, or don't for any number of reasons all of which are fine!
We are heading towards distributed high available SQL and NoSQL databases (with Redis, Postgres and MySQL compatibility for easier migration) designed to work exceptionally well in cloud environments like CockroachDB (Go), TiKV (Rust), Vitess (Go) to name a few.
That is because SRE teams want to be able to scale horizontally and make a node, rack or even region failure to be a normal thing, their company don't need to worry about.
> I always hoped Java would make a comeback, but Rust is looking like the real deal.
To me it seems like SoSoRoCoCo is hoping their preferred language would make a comeback in popularity while also acknowledging that Rust is gaining popularity and real-world demand.
Java is somewhat of a special case though, especially the Big Data ecosystem. Much of the fastest and most important Java tools are written in pure Java (or other JVM language) and as such can't be called from Rust in a reasonable way.
Writing Big Data code in Rust is certainly possible from a performance perspective but is an uphill battle of lack of libraries, integration, etc. Some of this might change in time but I don't see Rust ever displacing Java from Big Data. One of the big reasons for this is the main downside of Java is it's GC, which is mainly problematic for latency sensitive applications. In the Big Data field this is substantially reduced as a problem as the code is usually throughput bound and executed outside of interactive contexts, hiding the cost of the GC where it might be more apparent in other applications.
I love Rust and I think it has a lot of potential to replace some of the databases and networked services used in data infrastructure, just don't see it displacing Java as the top dog.
Rust isn't aiming to displace Java. They're two different levels of abstraction. It's the same with Python. Rust isn't aiming to displace Python just as Java isn't aiming to displace Python either.
Rust one day could displace C++, but the odds are low, because in response to Rust C++ has stepped up its game and has changed as a language drastically. Most modern C++ features are concepts from Rust.
To be fair, that doesn't put Rust in a worse position than any other language binding a C++ API. It's just that Rustaceans tend to have higher expectations in terms of safety.
I assume that this is meant to imply that Rust doesn't provide advantages in the data engineering space. So I'll add in here -- as a data engineer myself -- that Rust is definitely providing an advantage for me. Combining it with Python (using PyO3 bindings) lets me write performant, safe code that interops with Python in a project for which Scala+Spark isn't feasible. So while Rust may not provide an advantage for you, that doesn't mean it doesn't have a potential niche for data engineering.
As for the others, if it can be shown that porting them comes with a decrease in latency and infrastructure costs then they'll be ported. I've often wondered why they haven't been already.
To the contrary, a bunch of FAANG driven contributions tend to make projects focused too much on particular use cases. Go’s clusterfuck of package management is entirely because Google doesn’t do package management.
This is one of the challenges we have, as a project, in this next phase of its life: make sure that we are helping organizations achieve their goals, while not allowing it to be totally directed by them. Rust governance is set up to be resilient to takeovers by any one organization, but we're now playing with some of the most powerful organizations on the planet. We're glad to have them, but we do have to make sure that we make Rust what we want it to be, and not purely what various large tech companies want it to be. It's a delicate balance.
At the end of the day, I think it comes down to the actions of people directly involved in a community, and the culture that they collectively cultivate. I'm optimistic that being intentional in this makes for a very resilient project and community.
This is where I think mindful investments in building and maintaining a diverse community of developers and users is especially important for a system component like a programming language. From my perspective, this is an important feature of Rust that we should seek to maintain (as I've mentioned before elsewhere [1]).
Very happy to see this happening, for all the reasons you cite.
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.
(Also, these organizations are huge! The web standards folks and the Fuchsia folks are, as far as I know, basically disjoint, so even talking about companies like Google as a monolithic entity is fraught with issues.)
We work directly with Google folks. This has not been our experience in any way. Likewise for other large companies interested in specific Rust features or improvements.
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.
* Anyone may write a proposal
* Anyone may comment an open proposals
* The people on the Rust team decide to accept, reject, or postpone a proposal.
Those people on the team have the power to gate any major decision about the language itself. Some big company could hire 500 Rust developers (let's make it ridiculous on purpose), have them write 1000 proposals for new features, but that doesn't mean that those changes will happen: it requires that team of people to sign off on the decision. That group of people is added to only with the consent of all of the existing members. Additionally, making decisions is a consensus based process, so a single "no" vote will mean the proposal is not accepted.
Now, that doesn't mean the process is immune to companies suggesting things. For example, a company could try and hire literally every member of the team. That would be... aggressive. They can use their resources to give more people more time to do the work of making a great proposal, building consensus, and making changes they want to see happen. That is actually an ideal situation, and has been working pretty well historically. (Google employees were key in getting async/await to work out, for example. This is also basically what Mozilla's influence on Rust was for its entire history of working on things.) This is the way I'd personally love to see Amazon (and others) contribute.
> 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.
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.
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.
Rusoto is an awesome project though, huge thanks to those who've got it to where it is.
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
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.
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.
Who is "we", in this case, out of curiosity?
Anyways I really hope it will be successful!
Me too, and thanks :)
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.
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.
"Servo’s mission is to provide an independent, modular, embeddable web engine, which allows developers to deliver content and applications using web standards."
So maybe they're just not there yet?
But in my opinion, if you create popular software and no one uses it, it's not popular from its adoption, it's popular for some other reason. I can't point to any one using Servo and figure out how they use it, because I don't know of any companies or products actually using it besides Mozilla.
And I embed web tech, so I've spent a lot of time in that particular field. I just don't see it actually being used outside of Mozilla projects, like it was originally conceptually sold.
That's a very recent change, post spin-off from Mozilla.
Wait, you're working with web tech – probably the most archetypal field where preventing security vulnerabilities is the top priority – and you don't see the benefit of using Rust instead of C?
If Servo is any lighter than CEF, I absolutely want it to be the solution I use. So I’m very interested in its development.
- 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.
I agree that rust would be better with dynamic linking. It sucks that you have to build everything when you build one thing :(.
The issue I was specifically thinking of is how slow an untuned JVM can be for startup times and to get to peak performance (It HAS gotten better, but is nowhere near as fast as rust or even python). The default for these JITed languages is to pass everything through a non-optimized code path and only optimize later when the various methods are exercised enough.
Rust has an advantage here in that it doesn't do any sort of runtime analysis to improve performance. It simply is as fast as it always will be.
That being said, it is not simple to say, take a binary Rust Cargo project and say "please dynamically link all the crates it uses" or something like that. But if you want a dynamic library to be used by something else? First-class support for that use case exists.
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.
It's quite the opposite: the larger a C/C++ project gets, the more problem you are starting to have with safety. Securing and modifying millions of lines of C/C++ code (especially if it's multi-threaded) is a nightmare, and actually impossible, where people are afraid to refactor old code because all the ownership uncertanities.
Rust changes a global ownership tracking problem to a local one.
To clarify, I’m not arguing that Rust is bad or inferior (to the contrary!), just that the incentives for established projects to move on from C/C++, from a strategic perspective, might not look that massive if they’re only gaining in safety.
I think it's becoming increasingly clear that "addressing the problem" in C and C++ means fixing all the memory safety issues you know about. Sqlite is the posterchild of careful testing in a C codebase, and they had a serious CVE last year. Realistically, the vast majority of C and C++ projects have more bugs than that, even if they're staffed by experts who take security seriously.
But I agree with you about the cost-benefit analysis. It's not very often that security issues destroy an entire company, and trying to rewrite a large codebase might be existentially riskier more often than not.
You'd pretty much never make the move from Java -> C++ because of the lack of safety. But you may want to do it because of the other non-safety features.
That is where Rust is interesting and competitive. It's the performance and memory footprint of C++ with the memory safety of Java.
From other languages it’s definitely a stronger proposition in many respects.
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.
There are tons of tools in Rust to preprocess headers, and do even more fun things like https://github.com/Hywan/inline-c-rs (which is obviously not a general solution to this problem but is interesting)
* https://crates.io/crates/bindgen (generate Rust FFI from headers)
* https://crates.io/crates/cbindgen (the inverse of bindgen)
* https://cxx.rs/ (a similar tool to bindgen, newer)
Thanks again, Steve. And for all your patience, too.
* 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.
Rust? I haven't even made it to the Oracle yet and I've been writing it (granted, in my spare time) for the same amount of time.
I feel like C++ can get really out of hand, so not having a cppfmt is surely a thing of jealousy.
There are people who like gofmt and dislike rustfmt.
I live in JavaScript land mostly, which is the wild wild west when it comes to "the way to do things," so rustfmt is still many times better than, say, prettier and eslint. It exists AND it's part of the standard tooling!
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.
>It's just not a concern I have. Perhaps with enough time and coercion I'll find a reason to use it.
Or just don't? Its like the validity of Rust is dependent on wether you use it or not. Try a different tone, and change a mindset from where yourself have to acknowledge/use/like something for it to be valid. If a fact based discussion about this is to be had you need to stop shoving your anecdotes and personal likings in the way. Its impossible for people to know whether Rust is right for you, and thats a pretty boring discussion by itself.
I've never moved past reading the rust docs, but I understand why people react on your comments.
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).
All in all the frequency of use of generics is pretty similar to languages like C++ or Scala.
I think that's just a personal bias I need to get over.
To connect it back to your original questions, Rust relies heavily on generics because if you want runtime performance, but you also want safety, you pretty much need ways to evaluate safety at compile time, rather than runtime, so you don't have the overhead of runtime checks. This basically implies generics need to exist and be used heavily.
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.
For example, in my comment, I very much said "made it seem" and suggested that maybe people were misunderstanding the poster, not attacking their character.
Many people post many negative things about Rust, including those who are its most fervent advocates. But the gray areas mean there's places where people can post things and some people say "ugh any criticism is downvoted" and others can say "wow this is an absolutely off-topic, baseless criticism" and both will walk away feeling right.
Polite or not, using "soft" words or not, attacking the character of someone – "[you're not] interested in having a real discussion", "[you only want] a specific kind of description from a specific kind of person" – does Rust, and its community, absolutely no favors.
> Many people post many negative things about Rust
And I have no doubt that you'll continue to be there, "gently" correcting them.
I myself post negative things about Rust, including in this thread. Heck in the last week I've told the story about a team I was on not choosing Rust and how I thought that was a good decision in like, three different threads between here and Reddit.
I doubt we will ever agree though, so I'll leave it at that.
Replies are (or at least can be) "dogpile on them until they realize they're wrong".
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.
- factually wrong (revealing you don't know very basic info about Rust)
- anecdotal
- inflammatory (as you yourself admit when you say your comments were "crude")
It's not that people are being fanboys. I see lots of non-downvoted comments about not wanting to use Rust. Look at any HN thread about Zig, and you'll see a ton of non-grey comments that say Zig is better or that modern C/C++ don't need replacing.
If you want to sincerely debate Rust, you should learn the basics (for example, understanding how it's intended to reuse the C ecosystem, not "throw it away"); stop insulting other people in the thread (e.g. saying that using Rust is "playing with toys"); and acknowledging that it's not intended to appeal to anyone who thinks they're able to perfectly manage memory in C/C++ without any mistakes.
On that last point: no one with a lot of experience in C/C++ thinks it's possible to manage memory in those languages without dangerous bugs, and increasingly people think adopting a new language (Rust) is a good trade-off for avoiding whole classes of memory bugs.
The thing is that your tone doesn't seem to come across a genuinely interested. It seems like you're just throwing uninformed opinions at people without leaving an opening for discussion.
For example, you talk about not wanting to throw away the C ecosystem. Instead, you could say, "What about all the great C libraries that we're never going to rewrite in Rust? Are Rust users throwing all that work away?"
And then someone would correctly inform you that the Rust community doesn't want to throw all that work away and has spent a ton of time on interop.
There is a difference between facts and opinions, yah?
If there's a killer reason outside of memory safety and ownership, like compiler speed or something, I'd love to hear more about it from first hand accounts rather than someone's blog article about how great Rust is... and oh by the way we sell some product written in Rust, check it out! You know?
One interesting thing in this comment, and why I chose to respond to it though, is it seems like what you want isn't just a description, but a specific kind of description from a specific kind of person. That is, it has to be "first-hand" but also not from someone who "sell[s] some product written in Rust." How can you get first-hand knowledge without building something? How can you demonstrate that that knowledge is legitimate without also letting people know that you have done that work? It seems impossible to me.
Furthermore, you're lying. You've gotten tons of responses here as to why some people use Rust or like Rust, yet you then continue to spout that you want what you've already have gotten.
>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.
Sorry that's beneath you? Sorry I didn't discuss things the way you wanted? I mean, not really, but you have leverage on the forum, and you're making it a really undesirable place to reply in.
I agree the rust core folk could have done that and probably made a pretty penny. The issue is setting up a new consultancy business is more complex and inherently more risky than just taking a cushy job from the companies that will pay handsomely for their talents.
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/
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.
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?
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.