Live data from Hacker News

Why AWS loves Rust, and how we’d like to help

aws.amazon.com

121–130 of 338 posts

Re: Why AWS loves Rust, and how we’d like to help

#121
post #74

This is excellent; hopefully we get native Rust support on Lambda soon maybe? :)

In what sense? They released a runtime two years ago: https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws...

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.

Re: Why AWS loves Rust, and how we’d like to help

#122

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…

I can give you a few reason you might like rust. - 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 ap…

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.

Re: Why AWS loves Rust, and how we’d like to help

#123

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…

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.

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.

Re: Why AWS loves Rust, and how we’d like to help

#124

Earlier quoted context omitted.

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 (MySQ…

There will be people who downvote you because... - 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

"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.

Re: Why AWS loves Rust, and how we’d like to help

#125
post #54

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.

> This post is obviously from an engineer 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, Ela…

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.

Re: Why AWS loves Rust, and how we’d like to help

#126

Earlier quoted context omitted.

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.

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 (MySQ…

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.

Re: Why AWS loves Rust, and how we’d like to help

#127

Earlier quoted context omitted.

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…

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).…

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.

Re: Why AWS loves Rust, and how we’d like to help

#128
post #84

Earlier quoted context omitted.

> I always hoped Java would make a comeback 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-...

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.

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.

Re: Why AWS loves Rust, and how we’d like to help

#129
post #81

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…

I kind of think it's ugly too. 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,…

Perl was great. I miss Perl. v_v

Re: Why AWS loves Rust, and how we’d like to help

#130

Earlier quoted context omitted.

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…

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…

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?
Post reply on HN