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.
EDIT: may the downvotes come from the idealists that hammer down pragmatists, like our opinion doesn't even count
I was mainly responding to this statement which came across quite aggressive. Java and C++ do not need comebacks and my comment was intended to be a wake-up call to reality. Yes, it is great to learn Rust on the side, but advocating something to be used everywhere is another story.
Where is that in the comment you replied to?
Java is somewhat of a special case though, especially the Big Data ecosystem. Much of the fastest and most important Java tools are written in pure Java (or other JVM language) and as such can't be called from Rust in a reasonable way.
Writing Big Data code in Rust is certainly possible from a performance perspective but is an uphill battle of lack of libraries, integration, etc. Some of this might change in time but I don't see Rust ever displacing Java from Big Data. One of the big reasons for this is the main downside of Java is it's GC, which is mainly problematic for latency sensitive applications. In the Big Data field this is substantially reduced as a problem as the code is usually throughput bound and executed outside of interactive contexts, hiding the cost of the GC where it might be more apparent in other applications.
I love Rust and I think it has a lot of potential to replace some of the databases and networked services used in data infrastructure, just don't see it displacing Java as the top dog.
Rust isn't aiming to displace Java. They're two different levels of abstraction. It's the same with Python. Rust isn't aiming to displace Python just as Java isn't aiming to displace Python either.
Rust one day could displace C++, but the odds are low, because in response to Rust C++ has stepped up its game and has changed as a language drastically. Most modern C++ features are concepts from Rust.
To be fair, that doesn't put Rust in a worse position than any other language binding a C++ API. It's just that Rustaceans tend to have higher expectations in terms of safety.
- You are hijacking a top comment to insert your off-topic opinion.
- You appear to be more territorial than presenting some sort of argument.
- You are overly negative and somewhat dismissive/disrespectful.
- You are commenting on downvotes, which is generally frowned upon
Rust isn't going to replace Java, but it may supplant Java in a lot of fields where one wants both memory safety and an OO language with high performance. No one is (rationally) suggesting that Rust will replace every language.
The tone of your post, however, makes it sound as though you have something against Rust, and that you're more interested in pointing out all the things it's not good at, or shouldn't be used for, rather than contributing to a constructive discussion.
> I also pointed out that Rust has to win the mindshare of C++ programmers first, before even reaching other ecosystems
Not entirely true; Rust is an alternative to C++, but it's vastly more accessible to people who've used other languages like Java, Python, Ruby, and so on, where you get types, OO, and memory safety. Instead of simply resulting in a 1:1 replacement of C++ with Rust, it may result in a minimal reduction in C++ programming and a notable increase in Rust programming which would have been done in another safe OO language instead, but at dramatically worse performance.
C++ is just a tool, as is Rust. Rust does not need to win the mindshare of C++ programmers first to become successful. It only needs to itself as a viable alternative in whatever fields people find it useful. I believe it has.
Between WASM, embedded, and even Web development, I see a lot of "mindshare" being attracted to Rust.
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.
Meaning coming in Apple, Google, Microsoft, Nintendo, Sony, AMD, NVidia, random IoT OS vendor SDK, with bindings to all relevant OS libraries.
So far, Rust/WinRT seems to be the only thing into that direction, and given how C++/WinRT tooling support turned out, I rather wait and see.
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.
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.
You mean one is already shipping Rust and another seems to be on track to shipping it soon?
> For now, Chrome investment in Rust will remain a background investigation (mostly directed towards prototyping these tools and techniques). If we become convinced this sort of interoperability is possible, we’ll revisit widespread use of Rust in Chrome
[0]: https://www.chromium.org/Home/chromium-security/memory-safet...
It would be unfair to blame rust. But that example doesn't provide confidence that switching from c would be a great idea.
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.
Yes, Java applications and Rust mostly don't overlap, but there are exceptions in both ecosystems.
Rust might offer some advantages for Data Engineers (the same way as CUDA applications in C++), not all of them as with every language else, and yes you can write Data centric libraries in Rust for Python (easier than C/C++ IIRC).
And no, there's no need to rewrite existing services to Rust, it can interface with all the examples you cited.
To me Rust is just a simpler and safer C++, if you said you would program C++, you probably will want to program Rust, writing C++ bindings for Rust is basic stuff nowadays
That said, I don't think anyone was suggesting Rust would displace Java. The OP was pretty clear IMO that his firm had experienced exponential growth in interest in Rust skills while he had been hoping that interest in Java would grow instead. This doesn't mean that Rust will replace Java for data engineering or any other domain in particular.
Give it 20 years and I can see it doing to Python what Python did to R.
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.
> 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.
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!
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.
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.
We are heading towards distributed high available SQL and NoSQL databases (with Redis, Postgres and MySQL compatibility for easier migration) designed to work exceptionally well in cloud environments like CockroachDB (Go), TiKV (Rust), Vitess (Go) to name a few.
That is because SRE teams want to be able to scale horizontally and make a node, rack or even region failure to be a normal thing, their company don't need to worry about.
I 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!
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.
Both are general purpose languages, so of course they overlap.
> Good luck rewritting all the big data tools from Java (Elasticsearch, Spark, Kafka, Hadoop, Neo4j, Deeplearning4j, Cassandra, Solr, Arrow, OrientDB)
Cassandra (https://scylladb.com) and Kafka (https://vectorized.io) have already been rewritten once in C++, with massive latency and throughput improvements. No reason why they couldn't get their superior Rust clones in the observable future.
Materialize (https://materialize.com), Noria (https://github.com/mit-pdos/noria), and Sled (https://github.com/spacejam/sled) are just some of the Rust database projects that are aiming at unseating the de facto standard implementations in the space. InfluxDB (https://www.influxdata.com) is now doing major Rust development as well.
The future is almost here. It's just not evenly distributed yet.
It is not a single dimension problem as they try to frame it. Performance is a single dimension of systems. Java with GC is a memory safe solution compare to C++ (hello segmentation faults). The reason why the C++ implementation is faster is not that it is written in C++ but it is written using a different approach. There are plenty of Java HFT systems that run circles around C++ systems yet we cannot draw a conclusion that Java is better suited than C++ for HFT. Implementation details matter, code quality matters and performance does not come purely because you pick a particular programming language. Btw. most of the systems which I was working on using Cassandra instead of ScyllaDB because the companies were not ok switch up for some performance gains (because Cassandra was performant enough for their business use case). I think what you receive as superiority is not as clear cut as you try to make it.
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.
And as for browsers, you know Mozilla created Rust specifically for Firefox?
In order to make a comeback, Java first needs to fall from the TOP 3 languages used by professional programmers in the world.
https://insights.stackoverflow.com/survey/2020#most-popular-...
Java is currently losing Android devs to Kotlin. That could cause a precipitous drop in direct usage in the coming years.
It just wasn't available as free beer, so it tends to be ignored by the FOSS crowds.
A Java developer will pick up Kotlin much faster than, say, a Postgres developer will pick up Mongo. It takes a lot longer for a Java programmer to learn the Android environment than the Kotlin language.
If there were a trend from Java towards Rust or Go or Python, that would be a significant change in the world. If Java were to vanish tomorrow and everybody had to pick up Kotlin, the world would be pretty much the same in a week. Kotlin is nice, benefitting from a clean-sheet implementation of lessons that Java takes on only with difficulty, but it's not a wholesale break.
Similarly, "web app" isn't a programming language, and neither is "server side". But they are toolkits that a developer must learn on top of their programming language, and it takes longer than the actual language itself.
My point is - DSL and programming language can overlap. However they don't have to.
That's very much not true. I've personally done contracts for developing PostgreSQL related code and/or PostgreSQL based projects.
P.S.: Also I say Java, but I mean JVM, I club all JVM languages together, since that's more what I care about, is the strength of the Java ecosystem.
Caution doesn't make money, it just prevents losing as much money. When it comes to technology if you're waiting for everyone else to validate an idea, you're too late.
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.
AWS loves Rust in the same way than Facebook loved PHP.
We love it and wouldn’t trade it for a different language at this point.
P.S. we’re hiring remote and sf Bay Area. If you are interested in working on digital cash for use in messaging applications, drop me at line!
It has a nice niche where it's less chaotic than JS and has better threading support and uses less cpu/ram than JS and python. But it's still high level enough to not be inconvenient to work with. These traits make it a great fit for beefy back end machines at big companies.
Rust will always be targeted at low level work unless they add a GC. Even with lifetimes etc a GC is just way more convenient
Very happy to see this happening, for all the reasons you cite.
To the contrary, a bunch of FAANG driven contributions tend to make projects focused too much on particular use cases. Go’s clusterfuck of package management is entirely because Google doesn’t do package management.
This is one of the challenges we have, as a project, in this next phase of its life: make sure that we are helping organizations achieve their goals, while not allowing it to be totally directed by them. Rust governance is set up to be resilient to takeovers by any one organization, but we're now playing with some of the most powerful organizations on the planet. We're glad to have them, but we do have to make sure that we make Rust what we want it to be, and not purely what various large tech companies want it to be. It's a delicate balance.
At the end of the day, I think it comes down to the actions of people directly involved in a community, and the culture that they collectively cultivate. I'm optimistic that being intentional in this makes for a very resilient project and community.
This is where I think mindful investments in building and maintaining a diverse community of developers and users is especially important for a system component like a programming language. From my perspective, this is an important feature of Rust that we should seek to maintain (as I've mentioned before elsewhere [1]).
Having maybe kicked off a small flamewar with my above comment, I will admit to being curious to contribute to deferring the eternal september of rusts community and how welcoming it is with all the influx of new developers, myself incuded in em.
Theres probably a netiquette equivalent somewhere, but beyond "don't act like the rust evangelism strike force" of n-gate fame, I'm fuzzy as to its details.
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Apple-Fr...
(Well, Firefox adding more Rust is correct, but the rest is not.)
So I have mixed feelings about too many clever people doing too many clever things to an awesome language.
That being said, we (that is, the Rust team broadly, I am not on the language team) do weigh companies' desires fairly heavily, because we want Rust to be used for real, important things by companies. But it's always a balance. Famously, the lang team even resisted some proposals by the Servo team way back in the day, even though most people involved on all sides were Mozilla employees at the time.
* Anyone may write a proposal
* Anyone may comment an open proposals
* The people on the Rust team decide to accept, reject, or postpone a proposal.
Those people on the team have the power to gate any major decision about the language itself. Some big company could hire 500 Rust developers (let's make it ridiculous on purpose), have them write 1000 proposals for new features, but that doesn't mean that those changes will happen: it requires that team of people to sign off on the decision. That group of people is added to only with the consent of all of the existing members. Additionally, making decisions is a consensus based process, so a single "no" vote will mean the proposal is not accepted.
Now, that doesn't mean the process is immune to companies suggesting things. For example, a company could try and hire literally every member of the team. That would be... aggressive. They can use their resources to give more people more time to do the work of making a great proposal, building consensus, and making changes they want to see happen. That is actually an ideal situation, and has been working pretty well historically. (Google employees were key in getting async/await to work out, for example. This is also basically what Mozilla's influence on Rust was for its entire history of working on things.) This is the way I'd personally love to see Amazon (and others) contribute.
On the Rust language team, we are extremely mindful of managing complexity, and we typically err on the side of not including a feature (even if it's desired) if it feels like it adds too much complexity or surface area to the language. We've also paid attention to other language design processes and learned from them.
(Also, these organizations are huge! The web standards folks and the Fuchsia folks are, as far as I know, basically disjoint, so even talking about companies like Google as a monolithic entity is fraught with issues.)
We work directly with Google folks. This has not been our experience in any way. Likewise for other large companies interested in specific Rust features or improvements.
> 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.