I believe that's Amazon, Microsoft and Facebook all looking to get involved in core Rust development (I think partially triggered by the Mozilla layoffs). If anybody was still harbouring doubts about Rust's future, now is the time to lay them aside.
Friends of mine that are contract programmers have been ramping on Rust for the past 2-3 years claiming the number of requests for it has been increasing exponentially. I installed it two weeks ago and have been getting a feel for it. It's like if C++, C#, and npm had an offspring. I always hoped Java would make a comeback, but Rust is looking like the real deal.
These insights are a snapshot, not a trend line. Java can be in rapid decline and still be at the top of the list. Changing acceleration, not position, is how you make a comeback.
Java is currently losing Android devs to Kotlin. That could cause a precipitous drop in direct usage in the coming years.
Despite some surface differences, Kotlin and Java are so similar that "losing" one to the other isn't really that big a change. They run on the same platforms and they use the same frameworks, dependencies, debuggers, and other tooling.
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.
They are tools used by programmers. They do, in fact, have languages of their own, but more to the point they have whole ecosystems of expected behaviors, idioms, best practices, etc etc etc. Those take longer to learn than a programming language.
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.
True, but I don't think Java is declining, I just think Python and JavaScript grew beyond Java. But I really doubt that the use of JavaScript and Python that took on replaced the use of Java, I think it's just new use cases. I haven't looked at the data, but ya, I'd doubt Java is declining.
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.
And in the cloud native world everything is on the Go track. Java were huge for big enterprise monoliths, but it seems like this is not what we are heading for in the future.
I certainly agree that language rankings don’t really matter. In very broad strokes, “used everywhere,” “used many places,” “used some places,” “pretty niche,” “academic only,” these kinds of things are more useful than arguing which is 5 vs 6.
Exactly. Sometimes it takes more developers to maintain code than to initially implement it, which means technology choices today may lead to bigger popularity trends down the road.
In the same way Rust appears in ... (5,1% - 4.8% Professional Developers). The big players are looking for commercial long term safety about the used tools, platforms, programming languages and their ecosystems. After that, the technical discussion will take place.
I'm not sure who "the big players" are in your book but the largest software engineering organizations in the world are already using Rust. The post is about one of them committing their resources to the project itself.
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.
"...the largest software engineering organizations in the world are already using Rust ...", and also for a long long time have been using Java, JavaScript, SQL, and much more programming languages. ¿It's only about new (and better) ways to develop software or can also be 'cool' to interfere in the evolution of the programming language that you plan to use for the next years ?
I 'm not against to use Rust or any other programming language, open source project or technology. I mean, the companies love open source projects because they can produce their self flavor as a product (search engine, linux distro, containers and orchestration technologies, etc.) when they wish that, without worries about uncomfortable dependencies.
AWS loves Rust in the same way than Facebook loved PHP.
No not at all but even if that we’re the case fb taking an interest spurred PHP from a legacy language back into a living language that’s growing in features.
> the largest software engineering organizations in the world are already using Rust.
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 use rust for everything at MobileCoin. I like to think of the compiler as fussy, but when you make the compiler happy your code just works. No buffer overflows as long as you don’t use unsafe code, multi-threading by default. The audits on our code have basically only turned up logic errors and out of date crates (yes it’s always possible stuff was missed, but it feels a lot different than the C/++ and functional audits I’ve been involved with in the past).
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!
I don't love Java like I love Clojure but I think Java may stage a comeback with GraalVM: it has cut down startup times to almost match with native C/C++ . I am taking all my java projects meant to run on AWS Lambda and am running it through GraalVM to cut startups time and also memory size.
I don't think Java ever left. It's still used everywhere I've worked in the past 15 years, usually quite extensively. Just because it's not the hot language to talk about on HN it's still out there and quite healthy. Personally I'd been hoping that c# and it's kin would take all of Java's core business, but it really hasn't
I don't think Java is going anywhere. It's more performant than JS and especially Python, the other 2 top 3 languages. And unlike Cxx/Rust, you have the convenience of GC. And the new GC's are VERY good.
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
Applications of Java and Rust do not overlap. As a big data engineer, Rust does not provide any advantage to me. Good luck rewritting all the big data tools from Java (Elasticsearch, Spark, Kafka, Hadoop, Neo4j, Deeplearning4j, Cassandra, Solr, Arrow, OrientDB) and all the scientific stuff from C++ (Eigen, Tensorflow, PyTorch, Jax, Halide, OpenCV and the multitude of resources for CUDA and OpenCL) and databases (MySQL, MongoDB). If I want to contribute to LLVM or JVM, they are C++, the browsers are all C++. Unreal Engine and Unity (IL2CPP and engine) are all C++. Are you doing microVMs or drivers? Then probably Rust is a good investment (discutable), otherwise, I would wait for better alternatives. I will stick to Java, Scala, Python and C++ for the foreseeable future.
EDIT: may the downvotes come from the idealists that hammer down pragmatists, like our opinion doesn't even count
If by "hijack" you mean offering a contrarian opinion then this site would be rendered useless. This is a puff marketing piece for AWS first and Rust second, you cannot expect 100% fawning adoration (dont worry, there will be plenty still).
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.
My comment in on point, not off-topic. I had no intention to "hijack" the top comment, didn't even think about that until I've seen your comment. I don't see Rust as a replacement for Java and I also pointed out that Rust has to win the mindshare of C++ programmers first, before even reaching other ecosystems. Rust is mainly a replacement for C++.
Your comment that Java and Rust don't overlap is valid, but going on to discuss how you're going to keep using C++ and Python, and how Unreal Engine uses C++, is wildly irrelevant.
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.
Small clarification — Rust very deliberately does not do OO. It has features that look sort of like OO from a syntactic standpoint, but being object oriented is not a design goal for Rust.
> I also pointed out that Rust has to win the mindshare of C++ programmers first, before even reaching other ecosystems
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.
Coffee Script is a transpiled language and it has become irrelevant when lot of the language features it offered is now natively available in ES6 and up (it has definitely inspired lot of ES6 features like fat arrow functions).
Rust on the other hand is not a thin layer on top of something like Coffee script. So it does not need to keep up with 'something' for decades. As long as it continues to do its current job of making systems programming safer and fun, it is going to be here for a long long time.
I don't think the transpilation was the issue for Coffee Script. After all, most usage of ES6 is through a transpiler anyways. Rather, I think ES6 is simply a superior language to Coffee Script. That's why it has lost marketshare. Likewise, something superior to Rust could arise, and then Rust's marketshare will be in trouble.
"Good luck with" is slightly negative, but overall I don't see the post as having the traits you describe.
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.
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.
Debatable. Java's dominance in the data engineering space rests a bit on clay feet: it's unsuitable for scientific computing in a number of ways: for example you can neither write fast nor clean numerical code in java and it does not interface naturally with the languages that people do write numerical code in. This is not an absolute deal breaker, but it adds friction. Also, serveral big data tools like cassandra (scylladb), kafka (redpanda) etc. have basically already been rewritten in C++ not least because they suffer from java-typical performance problems (even if those problems are not necessarily inherent in the choice of java). But C++ is not a very attractive language to write code in if there are viable alternatives, because it is objectively unpleasant and expensive to use (long compile times, terrible build and packaging eco-system, high cognitive load, difficulty of avoiding undefined behavior, etc.). Rust shares some of these defects and has some of its own, but it also offers substantial benefits for some types of problems that seem relevant to data engineering and crucially it interfaces more naturally with Fortran, C++ and Python than Java does. So I think it has a chance to gradually make inroads.
> C++ is not a very attractive language to write code in if there are viable alternatives, because it is objectively unpleasant and expensive to use
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
There are a lot of database-like services written Java (Kafka, Cassandra, ElasticSearch, Neo4J, HBase) that would likely be better in Rust. Yes the common denominator is Apache but they seem to have bought into Rust as well https://arrow.apache.org/blog/2019/02/04/datafusion-donation...
Your comment seems to assume that your use case “big data engineer” is the only use case or the only Java use case and that the only context in which Rust can grow is to rewrite the existing tools that you use today (as opposed to greenfield projects like firecracker or bottle rocket). Your edit also writes Rust off as “idealistic” and not “pragmatic” without support, which is very far from the impression I have (based on my usage and seeing it used in real applications). In general, your comment seems like generic programming language flamebait.
Firecracker and Bottlerocket are fine pieces of engineering. If Rust wants to get a share of the pie when it comes to data engineering, then it needs to have at least a killer app with an ecosystem around it. We can talk all day and all night for why some languages are more successful than others but it seems like ecosystems are giving them a boost. Hopefully, Rust will be the language for microVMs and kernel-level modules. I was strictly referring to people that think Rust would displace Java as idealists.
I generally agree--languages do better when they become the language of a particular ecosystem and that ecosystem becomes relevant. Go had this with containers and network software a bit more broadly.
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.
I can't absolutely say that this won't happen, but given Rust's focus on writing "correct" code, e.g. the borrow checker, etc, it's really unlikely given that one of the largest areas where Python and R shine is in exploratory data analysis. I can't imagine trying to play around with unstructured exploration of a data set in Rust's (totally reasonable) syntactic verbosity, correctness straitjackets, and compilation time.
Some of that complexity can be abstracted away with a good framework. I think it’s almost inevitable that a Pandas-like framework will eventually emerge for Rust (probably based on Arrow).
It’s also quite possible that Rust could underpin a product like Spark, with a scripting language on top.
The compilation time is a hurdle, but it’s not as if compiled languages are absent in numerical computing, for example Fortran.
Moreover, Logo-based and Lisp programming environments are more popular than other people think. Netlogo is heavily used in social sciences. Hard to think that even Python and R can displace those since they are so well suited for that kind of programming (agent manipulation).
I write Java and Rust at work, and i more or less agree.
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!
20 years ago, almost none of that stuff existed. It's entirely possible that whatever exists 20 years from now will all be Rust. I don't think that's likely, but I think it's more likely than the landscape you describe still existing in any recognizable form.
Being as experienced as you are, couldn't you just learn Rust like any other language if you need it in your work (or just to try it out). Your post has a weird negative vibe, like it would cost you greatly to try it.
> As a big data engineer, Rust does not provide any advantage to me. Good luck rewritting all the big data tools from Java (Elasticsearch, Spark, Kafka, Hadoop, Neo4j, Deeplearning4j, Cassandra, Solr, Arrow, OrientDB)
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.
Chrome is "on track"? Last I remember they had a document explaining why it's not a good idea for them. I disagree with it, and would very much wish for Chrome to ship Rust, but they don't seem to be interested for now.
They're referring to this[0] I believe, which is not glowing, but does seem mildly optimistic. Specifically:
> 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
Yes that's the same document I refer to as well. So nothing has changed. A "mildly optimistic" rejection is a rejection of Rust nonetheless. Rust is definitely not "on track" of being adopted in Chromium. For that you'd need more. Right now it's rather a "we are interested, maybe we'll add it". Also note that Chromium engineers also built some languages themselves that solve some of the same problems that Rust solves: https://github.com/google/wuffs
Right, and their issues there all pertain to interoperability, not to issues with the Rust language and its implementation. They seem to view Rust as production-ready, and a language that would bring relevant benefits to the Chromium project, were it not for the C++ interoperability difficulties.
I think it's weird to blame Rust for that. I don't want to rush to blame Windows 7, but do consider that Windows 7 is massively EOL (2015; extended support also ended early this year) and I would not fault Mozilla for not doing any testing on that platform anymore. I don't think this has much, or anything, to do with Rust.
Rust is new.. the os software is older than the language itself and eol. Not surprised it wouldn't be tested or supported
Because of that I have less confidence rust will work better or improve my experience. So rewriting everything in rust worries me. It is an anti-selling point.
If a language is living in the now and targeting the future it might not be the best for those living in the past.
> I always hoped Java would make a comeback, but Rust is looking like the real deal.
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.
I don't think rewrites should be the primary talking point, but rather using it for new applications, especially in memory safety critical environments like kernel modules.
In my opinion data processing / ML / database development is one of the best use case for rust.
You want stable memory management and performance . This is still something than often times is done in C/C++.
There are several promising technologies being developer in rust in that space; tikv (key-value store), materialize (steaming DB), arrow/parquet has a rust implementation, Toshi (Elasticsearch), Tantivy (Lucene), etc
A good point and a long list of tools. But imo this is not the industry to say “good luck rewriting X” in. It is inevitable someone will come along to rewrite or write a new and improved tool for everything on that list. And it might be in Rust.
Stuff written before Rust existed was not written in Rust? I’m shocked. That’s like going back to the 90’s and pointing to all the software not written in Java.
And as for browsers, you know Mozilla created Rust specifically for Firefox?
I am a major fan of Rust. I upvoted your comment because it is mostly factual, and correct!
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.
The part you seem to be replying to doesn't imply that Rust is or should replace Java, at least not to me.
> 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.
Why do you need to rewrite them? Rust can call C++ code, just like Java and Python can. (I note you list Python libraries like Tensorflow and PyTorch as C++, which is accurate because they're written in C++, but they're certainly heavily used from a non-C++ language.)
Rust definitely makes sense anywhere you are currently using C/C++ or Python/Ruby.
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.
You've got it backwards. Rust is lower level than Java, so Java would be calling Rust, not the other way around.
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.
It's easy to call C++ code from Rust but it's often not trivial to wrap a C++ library with a safe Rust interface. C++ APIs often have implicit ownership structures that are difficult to encode using Rust's lifetimes.
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.
> As a big data engineer, Rust does not provide any advantage to me
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.
Cassandra has already been ported to C++ with Scylla. We switched to Scylla a year or so ago, haven't looked back.
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.
Sure, but from my perspective (you probably had better insight into these companies involvement than me) there was always a question about how committed companies this large really are when they only have a few projects in the language. Hiring core developers puts all doubts to bed (and also the kind of investment that actually for counts for something).
As someone who has lived through hype cycles, big companies can pull the rug just as quickly on these investments as they’ve made them. While this does indicate a more serious interest, it’s not nearly the safety net you think.
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.
> a bunch of FAANG driven contributions tend to make projects focused too much on particular use cases
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.
From my perspective, the size of the companies has little to do with the relative risk of outcomes that are not the best for the common good. I've seen folks at small companies try to control or unduly influence open-source software, and I've seen folks that work at large companies do it too.
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.
Absolutely. And I am very happy to see Amazon and others contribute to Rust. I think everyone involved has good intentions, and for that I’m very greatful.
Disclosure: I work at Amazon where I build AWS infrastructure
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]).
It took them like a decade to get there though, all the while telling the entire non-Google world that they must be doing something wrong if they want versioning for their dependencies.
The problem was that there were no dependency solutions at the time that really nailed it. Most systems used something similar to Ruby's Bundler system, which was terrible to work with. Personally I like that the Go team is patient and takes the long view when adding features to the core tool set and language.
That was never the position and lots of third party tools sprung up to make things work once the vendor folder was added in Go 1.5. That was three years after the language was released.
The current version module system is built on a decade of anguish that finally toppled over and forced some serious interest. The problem is that it was a complete non-issue for Google because of the monorepo so the golang devs employed by Google severely downplayed the problem.
It definitely is a significant increase in support, all I'm saying is that it's a difference of intensity, not of kind, that is, it's not going from "no support" to "support" but from "support" to "lots of support."
Very happy to see this happening, for all the reasons you cite.
I think most of these companies have had a pretty large investment, they're just not really open about it in many cases. So yeah, it's a pretty visible signal, but the investments they had already were much larger ones. A team of core developers is a pretty small investment compared to having a ton of teams all over the place, which most of them had already.
This is excellent, frankly almost unbelievably good news. On the one hand, I'm still bummed at Mozilla's recent decisions re: layoffs. But with these 3 companies picking up the torch and increasing their investments, that is a ringing endorsement of Rust's viability for greenfield projects (and that compiler checks > coders conventions in improving software memory safety)
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.
There's no overriding document, and we aren't always successful at this, but it's just like anything else: have leadership model behaviors you want to see, gently nudge people in the right direction if they make mistakes, take action in truly egregious cases.
Always hard to know these things. It often doesn't follow what would be rational, but follows various accidents of history. Someone in domain X makes a superb library for it, inspiring ecosystem to grow in that domain, even if the language isn't fundamentally suited for it, etc.
This meme really needs to die. Mozilla never stopped working on Rust, many of the core developers are still Mozilla employees, and the Firefox team hasn't stopped adding Rust-based components.
Great thing but I feel these companies are just too clever for Rust. Rust is a developer’s delight and I don’t want it to become like C++, and I feel the C++ standard got worse especially after these so-called great companies became a part of the standards committee. Or take the example of Web, made worse after the Googles and the Apples of the world got in.
So I have mixed feelings about too many clever people doing too many clever things to an awesome language.
> Rust is a developer’s delight and I don’t want it to become like C++, and I feel the C++ standard got worse especially after these so-called great companies became a part of the standards committee.
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.
The biggest problem here, though, is that look at Google in web standards: the web is now what Google say it is, IE 6 style. If Googlers don't get their way with the Rust language team, they'll just attack the language team head-on, or bypass them. Google have zero interest in collaboration.
Google employees have actively gotten involved in collaborating within the Rust project rather than bypassing it. Of course, anything can change at any time, but this absolutist statement doesn't correlate with experiences so far.
(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.)
> If Googlers don't get their way with the Rust language team, they'll just attack the language team head-on, or bypass them.
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.
The language team is the sole group of people who decides how the language itself changes over time. Entry into that team is determined by the consensus of the team itself. Anyone can comment on proposals, and of course, a company could hire those individuals, but it's not possible to become a decision maker (or stay one) without the explict consent of the existing set of decision makers.
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.
I am genuinely curious to know more about this. Some of these companies dedicate multiple teams towards an OSS project, which I’ve seen first hand with projects like llvm. So isn’t it possible that the involvement of these companies could actually systemically turn things as most of the people working would be their employees and that the scales could be manipulated easily by these companies(need not be intentional). For example I remember “std::string_view” in c++ being one example which Google pushed and even got into the C++17 standards despite its bad design. Although I might be wrong, but my guess here is that Google had a use for it(which we know it had) and that lot of people on the standards committee being from Google led to a systemic bias. Couldn’t that happen with Rust?
In very broad strokes, changes to the language work like this:
* 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 anyone here from the rust community, please please please stay away from amazon. There is nothing stopping amazon and aws. Any thing they do is evil. https://news.ycombinator.com/item?id=25196521
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.
If they really want to help, the most obvious first step would seem to be to formally adopt and throw some full-time resources at the Rusoto AWS library set for Rust. It's pretty usable right now, but would certainly benefit from the level of testing, helper methods, and language-specific additions that the officially supported AWS libs have.
It's a good call out, and one that we're actively engaged with. Matthew has done fantastic work on Rusoto and we'd like to be helpful there. Stay tuned.
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.
And as a secondary thought around Rusoto (which is awesome, but could be even more so) - it would be great if we came up with some way of covering the non-HTTP/REST type services - for example, there are various streaming services (think speech to text, text to speech, etc.) which are simply not covered by Rusoto. So you can configure those services using Rusoto, but not use them. I've written a few medium-hacky clients for things like AWS Transcribe, but it would be great to... well, not have to.
Rusoto is an awesome project though, huge thanks to those who've got it to where it is.
> If they really want to help, the most obvious first step would seem to be to formally adopt and throw some full-time resources at the Rusoto AWS library set for Rust.
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.
If Amazon wanted to be really self-serving, they would encourage the use of high-CPU usage languages and discourage the usage of languages that are efficient. Because AWS gets paid for CPU hours, anything that increases CPU hours of their customers should be good for their business, and vice versa.
You ought to flip that around actually. Yes it is kind of self-serving. But if they won't do something kind of self-serving like make it much easier to use Rust on their main profit center systems, how committed are they really to making sure the language succeeds? It sounds like a good thing to me for a multi-billion dollar internet giant to have a real self-interest in the language and ecosystem succeeding, and to publicly demonstrate that by maintaining a set of interfaces to their massively profitable ecosystem in that language.
I work with AWS quite regularly and this is one of reasons I don't play with Rust more. If we had an "official" Rust AWS SDK I would probably be building things with it.
I don't think MDN is going to go anywhere anytime soon. I remember someone on Twitter saying that there are enough people from other organizations who had already been involved in the MDN docs before the lay-offs at Mozilla and that these people will likely stay involved.
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:
Mixed feelings, on one hand, I'm so excited about the investment since I'm a big fan of Rust, on the other, I don't want it to be a clusterfuck like IETF and web standards development where companies like Google, Apple, Cloudflare, Mozilla get to dictate what is and isn't allowed on the web. I just hope the Rust community is able to stand up for itself and resist inclusion of unnecessary things against these big players with infinite resources.
> I don't want it to be a clusterfuck like IETF and web standards development where companies like Google, Apple, Cloudflare, Mozilla get to dictate what is and isn't allowed on the web.
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.
Having developed and launched a database (TerminusDB) built on a Rust core, this makes me slightly nervous. Feels like the evil empire will bring both great riches and great peril to the fantastic Rust community (part of the reason we picked Rust). Guaranteed sponsors for conferences, but also a certain malignant cynicism (am I being too harsh?). AWS will also aggressively compete for the best talent, which is tricky when you are small and open source.
> AWS will also aggressively compete for the best talent, which is tricky when you are small and open source.
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.
that is probably fair, I suppose comparing to the python world the financial folk soak up a lot of talent, but the open source ecosystem is stronger and better than ever.
Yep, Rust is especially vulnerable to featureitis because it's already a big language. The more surface area, the more breeding ground for temptations for growing the language. And in its current users a survivorship bias for new feature appetite.
Twitter previously invested in Scala, which significantly contributed to it's adoption outside of relatively small community back then. Another part of success was Spark.
It looks like Rust gains bigcorp support, all we need now is a killer product written in it to kick off explosive growth.
I totally agree. If a large scale product is written primarily in Rust from the start, adoption in production environments and startups will increase dramatically.
Mozilla management is completely clueless. KaiOS (ex FirefoxOS) is making a killing right now and has become the third most popular mobile OS, just behind Android and IOS. They fired the dev docs team, fired most rust devs and are mismanaging Firefox. Well maybe the people in charge are the ones that are not fit for the company...
Is Mozilla going to continue sponsoring the Rust project for the forseeable future? After letting servo out [1]
> 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.
Hopefully it will be more open with showing where the sponsorship money goes (I hope most of it will go to developers and Rust contributors like you) than other foundations that I don't want to name here.
The foundation is being set up by the Rust team, to be clear. I think with "more open" you're suggesting that this is like, an offshoot of mofo or something.
Does this mean the "Media Guidelines" is going away? If we want to redistribute cargo or rust with some patched changes, I'd like to be able to do it without coming back and asking for trademark approval every time. Even if the resulting binary says "unofficial/unsupported build".
Reading the Media Guidelines, I don't see how you came to that conclusion:
> TL;DR: Most non-commercial uses of the Rust/Cargo names and logos are allowed and do not require permission; most commercial uses require permission. In either case, the most important rule is that uses of the trademarks cannot appear official or imply any endorsement by the Rust project.
> Distributing a modified version of the Rust programming language or the Cargo package manager and calling it Rust or Cargo requires explicit, written permission from the Rust core team. We will usually allow these uses as long as the modifications are (1) relatively small and (2) very clearly communicated to end-users.
Patching for a specific architecture, distro, OS, et. all is going to result in "a modified version". You can't expect users as far down as the Debian Source DVDs to be able to submit that back to Rust for approval. Us folks using MIPS patch all the time, and redistribute binaries to help others.
I don't understand your answer completely, but I guess you know that the Mozilla execs are not the most trusted people right now by HN folks, so ,,offshot of mofo'' doesn't sound as good as Rust foundation by Rust core contributors :)
It should be noted that programming languages are different from software.
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.
It feels like it was yesterday when HN was praising Tim Bray for quitting Amazon AWS [1] over the firing of whistleblowers. And on the other hand we have what appear to be several prominent Rust community members falling over each other to get hired by Amazon and the Rust HN community largely cheering Amazon.
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.
The real world is a complicated thing. It is very possible to be critical of one part of an organization while working with another. Or even be critical of an organization you’re a part of!
Nobody believes they are doing it solely out of love, but luckily, that’s not required for it to be a productive relationship.
Am I just not "with it?" I don't see the appeal of Rust, but it gets the hottest talk in HN-town.
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.
> but still came away with the feeling there was literally no one using Servo
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." ;)
It really isn't. The entire purpose of servo was to be a vehicle for r&d with the eventual goal of merging code back to firefox. It succeeded. No one used it because that really wasn't the point.
I think you're right in that that was the original sell, but it's not how they sell it today.
"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.
I guess that will take a few years then. Having only CEF and Webkit ports out there and is really hard for us out there looking at offscreen embedding.
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?
It’s definitely a major focus, but from where I operate I have to trust the embedded library to address a lot of those concerns. There’s usually very limited exposure offscreen embedders have to see to.
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.
Certainly, if none of those things are issues for you, then there's no reason to give rust a second glance. However, I personally see rust as super exciting because of all of those aspects.
> 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.
> 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.
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.
Sorry, that wasn't a dynamic linking dig, but more of a JIT dig.
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.
You can use dynamic linking with Rust. You just have to stick to the C ABI when interfacing w/ shared objects, because there is no stable Rust-specific ABI.
A Rust artifact being used as a dynamically loaded library within a Ruby process via a C ABI is one of the very first, if not maybe first ever, production uses of Rust. You've been able to do this for a long time.
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.
Realistically, three of those 5 points are non-issues for C/C++ devs. The last is only relevant for certain types of workload. So you’re left with one real killer-feature of Rust: the safety. It’s a massive feature that cascades very well into pretty much anything you do... but it’s also one feature really - the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago (in their own ad-hoc ways). So the cost-benefit analysis of moving an existing codebase from C/C++ to Rust is not exactly a slam-dunk.
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.
> the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago
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.
But if you can’t have a Big Rewrite, you’re looking at meshing Rust and C/C++ - a suboptimal situation for any language, regardless of ease of technical integration, because of the organizational overhead (now you need to hire developers proficient in both C and Rust, rather than just one of them, and have two sets of standards, two sets of onboarding procedures, etc).
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.
Big companies already use microservices to separate programs (and be sane with memory ownership), so the logical way to move to Rust is to write new microservices in Rust.
> addressed that problem a long time ago (in their own ad-hoc ways)
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.
I think the more interesting cost benefit isn't moving from C++ to rust. Rather it is moving from Java or Python or Ruby or Perl to Rust.
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.
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?
> 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
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've noticed that Rust uses LLVM as well, but aren't there some significant compile time differences or am I recalling that from Go?
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.
Go is the language with very fast compile times; Rust's aren't particularly good, and, depending on the exact details, maybe slower than C++'s. It's pretty variable. We've been working on it but it's non-trivial.
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)
That's it right there. You may have just won me over by pointing these out. It's just so hard to go back to writing bindings mostly by hand instead of the other way around. I've generated thousands of bindings for all sorts of things, so it's really critical to my work.
Thanks again, Steve. And for all your patience, too.
For what it's worth, I think it's great that you are willing to at least reconsider the pros/cons of Rust when presented to you, even if it's not enough to change your mind.
I believe your issue with the "Rust hype" is that your pain points are different from the pain points of many other Rust users, and when they tell you that Rust is great for reasons A, B, C, you say to yourself, "so what?" But maybe you'd find Rust useful for less often cited reasons X, Y, Z, and you'll like it once you use it in earnest. Maybe you won't, and Rust isn't for you. And that's okay, too.
Also, kudos to Steve. I sincerely admire your politeness and patience when confronted with less polite, less patient posts. You're probably the best ambassador the Rust community could have.
I think the biggest thing I'm worried about from my end is I just work with so much C and C++ I can't attempt to do programming that takes away from being productive. I don't have the hours for it. I don't recall the Rusts docs yelling out to me, "Don't forget! C FFI bindings can be generated!" But at least Steve was able to point out some libs to me that would help with my work.
I'm OK with a small productivity hit because learning something new will always entail that, but the long term benefits need to be there. I'm almost always more worried about shipping than I am about anything technical.
That being said I think I can see some benefits over the horizon. In C and C++ land, there are a lot of people who don't use std or boost for one reason or another, and I've worked in circles where I had exposure to that type of programming. Honestly, just the fact that I might be able to rely on Rust's libraries OOTB could be a productivity gain right there.
I have the "Hello, World!" rust app on my workstation, so I've given it a small try. I'd be curious to see how other powerful concepts like threading work in Rust, but that's reading I've got to do.
It's difficult trying to sort out threading concerns from Lua, another language I use frequently, since the most common distributions aren't thread-safe without some work. I'd be interested in seeing what a Rust + Lua software integration could look like, since that might be a successor to the C work I do now.
there’s a number of Lua bindings, but some of the semantics are indeed very tough. The game dev community is maintaining the most famous bindings https://github.com/amethyst/rlua/issues/174
Short, incomplete list of reasons I prefer Rust, speaking from about five years experience with C++:
* 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.
One of the reasons it's so enchanting is how it manages memory without the use of a garbage collector thanks to the magic of lifetimes. Couple that with performance that's on par with C/C++ and design choices that encourage testing and documentation... there are a lot of technical reasons to love Rust.
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.
Yup - it drew me in as a Go programmer, entirely replacing my Go stack with Rust.
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 mostly use Go. But I've been keeping an eye on Rust because I like the language expressiveness, the safety provided by the stronger type system, the smoother integration with C calling conventions, the generics, the error handling. But I'm hesitant to switch to it because it feels like the learning curve is steeper in Rust than Go, and that's important for my team where we want to be able to onboard new engineers quickly. What's your experience in that regard?
The learning curve is very, very steep. Worth it, in my opinion. I think, though, you can become productive in Rust after a week or two. Go is great because you can grok it after a couple of days - you'll have most of the main concepts of the language down pretty well. I feel like I'm able to "bend the spoon" every day when I sit down to write Go, and I've only just barely been writing it for a year.
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.
It has made me think more clearly about ownership than other languages have. I work primarily in GC'ed languages (Go), so I never really had to worry about it. But now, I find myself writing better code everywhere because I now think about lifetimes and ownership of values. Granted, this only works because I took the time to understand Go's GC.
It does exist, and importantly, existed earlier, and has effectively no configuration. This means its usage is significantly more, and more internally consistent. Frankly I am a bit jealous, but I only have myself to blame here :)
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!
To those taking the time to sell me on it, thank you. I really appreciate you all sharing why Rust is important. I value a lot of the mentioned benefits listed below, specifically wrt speed, but I'm not finding the trade-off there yet.
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.
FWIW I expect you're getting downvoted for tone. In particular:
> 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.
It has C and C++'s performance without a lot of the footguns. A better type system. The trait system is a nicer way to extend types than C++'s class system (IMO). Generics from the start, instead of absent (C) or added on and still not fully utilized by practitioners (C++, some practitioners get the value, other offices bar using them). The ownership model means that using the lower level concurrency primitives is less likely to have the subtle issues of C and C++. It also means they could avoid encoding a specific concurrency model into the language (like Go or Erlang) and let those be libraries.
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).
Depends what you mean I guess. You can certainly write code that doesn't create more generic structs, and needing to create more generic structs when writing simple application plumbing code is relatively rare. On the flip side you also certainly want to use stdlib (and third party) libraries and instantiate generic structs they define. For example a list of T objects is most commonly stored in a Vec<T> where T is a generic, or for a builtin example a fixed sized array is a `[T; N]` where both T and N are generic. There's also approximately no reason to avoid generics.
All in all the frequency of use of generics is pretty similar to languages like C++ or Scala.
Perhaps Rust can be the language where I force myself to get used to them. In C++ there are stilly plenty of alternatives to not having to use templates. The reason I ask is I've preferred not to use them because I find them slightly more demanding to read.
I think that's just a personal bias I need to get over.
Yeah you're not alone. Have you used concepts at all yet? Rust's generics are similar to, but different than, C++ templates generally; concepts is the closest thing C++ has to them. That being said, even when you understand them, you can create some monstrosities, just like C++.
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.
Any time. One last tiny bit of overview: templates can currently do a bunch of things that Rust generics can’t. Some of these are things that Rust will be adding in the future, some are not, and some are uncertain. So there’s a lot of parallels but some folks who are very invested in templates say they don’t want to move to Rust yet because we’re missing things they desire.
The meme of the Rust Evangalism Strikeforce exists for a reason - because a person can't say anything remotely uncomplementary about Rust without getting dogpiled and downvoted into oblivion.
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.
I've come to the conclusion that many people just project whatever they want onto these kinds of conversations, positive and negative.
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.
I appreciate your comments here for multiple reasons and will not forget them. Thanks for taking the time to talk, it really sets a great example, too.
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.
This is exactly what I mean. I don't see how saying "hey this statement came across a little insulting and that's probably why people got a bit aggro" is attacking someone's character. There's nothing to do with someone's character in there, at all.
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.
Rust has a lot of deficiencies, like any programming language, but in general what I've seen is that "the community" believes the ownership model/lifetimes and "unsafe" keyword effectively makes it flawless. I think it's dangerous, to be honest, and the community in this regard is not very good--it's filled with people who hype the power of the language well beyond its limits.
I've basically had nothing but downvotes from the Rust community because any time I point something out about my thoughts on the language, I'm wrong and can't have those thoughts.
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.
People are downvoting you because you're writing things that are:
- 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.
I'm not trying really hard to argue facts or even talking about performance numbers or anything of the sort. There are people who really, really love Rust, and I'd love to better understand how some developers arrived at their opinions of the software.
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?
I hear what you're saying in this sub-thread. I will say that your "toy" comment didn't make it seem like you were interested in having a real discussion, but mostly just throwing shade, as they say. The whole comment has this vague undertone of "I am above this whole thing." This is probably why you're running into some difficulty. There's not just the crew that loves Rust, but also a very, very dedicated set of Rust haters, and it's really easy to bucket someone, incorrectly, into one or the other, based on initial impression.
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.
Yeah, sorry about that Steve. That was crass. I appreciate you sharing some thoughts here.
With respect to people's experiences, there are a lot more developers than developer/salesmen. The latter are more passionate by necessity, so I think there's a healthy band of feedback from those consuming the language maybe for work or hobby projects.
It's cool! Commenting on the internet is hard! And not everyone will like Rust, and that's super okay. You may also end up trying it and deciding you don't like it. That is 100% fine, no matter what upvotes or downvotes say.
You're side stepping what I said. The point is people will downvote false facts, but rarely downvote opinions that do not have an underpinning of false facts.
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)
I haven't used it myself, but my understanding as an outsider is that a lot of the excitement around Rust is that it's bringing a new model of memory safety: with the borrow-checker, you can avoid the performance penalties of garbage collection, while also avoiding the bugs and security risks seen in C.
People who care about such things are really hyped because it's a truly new idea in a mainstream(ish) language.
The primary reason why I love Rust is that the compiler catches most of my bugs at compile time. For example, I recently spent three full days on writing code without running it at all — I just made sure it compiled as I went along. Afterwards when it was time to run it, there were a few mistakes not caught by the compiler, but I was able to fix all of them in 30 minutes.
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.
There's lots of articles for the advantages of Rust. Consider just searching for some of them on Google since they will, in general, be written in a more considered fashion than a response to your comment.
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.
In a post about Rust adoption, it seems on topic in a threaded forum that commonly discusses pros and cons to discuss pros and cons.
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.
Sorry, not interested in education/advocacy. Yields repetitive threads. Prefer novelty. Restricting my comments to level 1 in threads here to prevent derailing. Can discuss via email (in profile) should you so desire.
It really sucks on HN that users like you who get past a particular karma threshold hold down users who have legitimate curious questions. It incentivizes not having unpopular discussions, and really turns me off to the site entirely. So could you please not?
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, legitimate curiosity is too low a threshold for me. If you want to chat further about this POV, happy to discuss over email (in profile). Would rather not pollute this thread.
If discussions on a forum are pollution to you, then I don't know what to say. People discuss things. Communication is a part of learning.
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 think that could have worked. There were ideas to do such a thing, as well as consulting around wasm and other stuff. I'm not sure why none of them were actually tried.
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.
This is huge for Rust. I always had a love/hate relationship with Rust. Love for the language and runtime characteristics. The lack of stability of the ecosystem combined with the small standard lib and the enthusiats/hobbyist mindset (sorry, but that was my impression) was a show stopper for using it in business apps where Rust could be great but was not strictly necessary.
Rust's popularity really is an incredible phenomenon. Amazon positioning itself as a big user and supporter of Rust is just good business. They do not want someone to appear more of a friend to Rust than they are.
That's great news and will contribute further to Rusts' adoption.
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 think the parent commenter meant as a selectable runtime at deployment time (i.e. directly supported), rather than requiring the bring-your-own-runtime setup that is currently required.
I'm not sure how meaningful that would be. Selectable runtimes make a huge amount of sense for interpreted languages or languages with a runtime. Rust is compiled to a binary. There are libraries that make it easy to set up a Lambda runtime, and guides for deploying that runtime; beyond that, a Lambda runtime is "run this program, leave it running, answer requests", and I don't know how standardized that could easily become with a compiled language that doesn't need a runtime or interpreter.
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.
They should pay contributors few millions of dollars each. If they benefited from it they should give meaningful reward. Mouthful words won't suddenly change you from being simply a leech.
But that should be millions per developer. Maybe developers should lobby RIAA, so that companies like Amazon would have to pay royalties for every line of code used. You know they make billions of off that work and yet some developers can't afford even their own place to live. This exploitation must end!
This tweet is likely referring to the fact that you can place special constructs in the YAML/JSON files to add control flow, thereby making it a crude templating language.
So, Apple got swift, Google got Dart and Go, i guess Amazon is trying to "have" rust ?
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.
To be very clear, it's not Amazon's language to take. We are contributing (and I think you'll see us increase our contributions), but we are one of many contributors.
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.
Totally fair to critique me as a marketer (though that's not really what I do. The only time I've had a true marketing title was when I ran marketing at MongoDB), but I don't think some of the other criticism sticks. We've been contributing to Apache Lucene and Solr (which feed into Elasticsearch), as well as Elasticsearch, for a long time. See, eg, https://aws.amazon.com/blogs/opensource/amazon-giving-back-a....
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.
> So, Apple got swift, Google got Dart and Go, i guess Amazon is trying to "have" rust ?
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.
Imagine Amazon keep hiring all the main contributors of the language and mainstream libraries, then decide to fork the language to add their own custom flavor, under their own conditions.
We're still very far from that point, but i've seen worst things happened in the history of big megacorps.
I don't think that's what's going on here. Swift and Go were both projects that Apple and Google respectively dedicated a lot of engineering resources to growing into mainstream popularity. AWS would have to spend a decade stewarding Rust the same way to get the same "halo effect".
