Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

aws.amazon.com

Post reply on HN
Print view View original

251–260 of 338 posts

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

#251

Post by ngrilly »

dhagz wrote: post #241
ngrilly wrote: post #130

Earlier quoted context omitted.

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 q…

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…

Thanks! Why is it worth it, in your opinion?

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

#252

Post by LukeEF »

_greim_ wrote: post #101
LukeEF wrote: post #32

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…

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

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

#253

Post by db48x »

autarch wrote: post #168
mattgreg wrote: post #136

Want to work with Rust? Ockam.io loves Rust, and we are hiring! https://www.ockam.io/team#open-roles

The read more button on https://www.ockam.io/team is a 404 (to https://www.ockam.io/learn/guides/team/values_and_virtues_on... ). 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.

All I see is blue with a header and footer, probably because my ad blocker blocks google tag manager.

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

#254

Post by JoshTriplett »

mjasay wrote: post #113
ufmace wrote: post #43

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.

I'd love to see this as well.

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.

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

#255

Post by __s »

itwy wrote: post #233
jfengel wrote: post #170

Earlier quoted context omitted.

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…

There's no such thing as Postgres or Mongo developer. They are not programming languages.

PL/pgSQL says otherwise

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

#256

Post by xiphias2 »

toyg wrote: post #191
xiphias2 wrote: post #135

Earlier quoted context omitted.

> 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 re…

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…

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.

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

#257

Post by JoshTriplett »

bjohnso5 wrote: post #121
steveklabnik wrote: post #79

Earlier quoted context omitted.

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.

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.

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

#258

Post by steveklabnik »

andrewmcwatters wrote: post #239
steveklabnik wrote: post #205

Earlier quoted context omitted.

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 sa…

I haven't spent any time in C++20, so it's interesting to hear that. I'll try and read more about both. Thanks for your thoughts on this.

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.

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

#259

Post by bsaul »

masklinn wrote: post #76
bsaul wrote: 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.

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

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.

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

#260

Post by germansm »

qppo wrote: post #183
germansm wrote: post #157

Earlier quoted context omitted.

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.

Post reply on HN