121–130 of 284 posts
It's a little concerning to see Huawei involved so closely in Rust, given the concerns about them silently including spyware in their products to give access to the Chinese government. I don't think I'm being a total conspiracy theorist; for example the UK, US and Sweden all ban Huawei equipment from their countries' mobile phone networks. Hopefully since this code is all open source there is sufficient scrutiny to a…
Earlier quoted context omitted.
don't get me wrong, I love rust and find it a great language for doing systems level stuff but it would be my last choice for a crudy type web application. Those are intrinsically IO bound. Sure, you might find a noticeable improvement if you're using something really slow like rails without any caching but there are plenty of garbage collected rapid development languages that will be fast enough that the visible per…
> Those are intrinsically IO bound. Rust has a great async story compared to other languages, which benefits IO-bound workloads even more so than CPU-busy ones.
Saying that it is "great" is really overselling it at this point, unless the languages you're comparing to are mainly C or C++. I would also toss Ruby in that category for now, but they seem to be working on making async better with Ruby 3+.
When compared to Python, JavaScript, or C#... Rust's language support for async isn't really that impressive to most developers, although the implementation has some technical characteristics that are nice for people who care about the low level details. The ecosystem is pretty lacking, even though it is much better than it was a few years ago.
Compared to the aforementioned languages (including Rust), Go and BEAM-based languages are just on another level.
I'm sure both Rust's language ergonomics and the ecosystem will improve over time, but Rust's goals also make it unlikely to ever be compatible with my definition of a great async system... which is the model Go and Erlang use where the developer can't tell that every single sequential process isn't running in a separate OS thread -- and, by extension, every function is automatically async with no distinction that I have to worry about.
In Go, I can spin up as many goroutines as I need, and I don't have to worry about any single goroutine blocking an executor like I have to worry about in Rust.
Yes, some async runtimes in Rust have worked on clever things like monitoring the executor threads and spawning a new executor to steal a blocked executor's work queue... maybe some day that will be a battle tested solution. Like most of the Rust async story, there are rough edges that could benefit from some more time.
(I have worked professionally with both Rust and Go for several years, and I think they're both great languages with different trade offs... I'm not trying to bash Rust here.)
I found parts of that announcement very difficult to follow. Can anyone tell me what the following means? « For too long, open source as both an industry and a community has done a poor audit of its expenses. Notably, ignoring the price of what I’d controversially argue is the core value proposition of open source software: the freedom to collaborate. »
Earlier quoted context omitted.
serious question : would you recommend Rust for CRUDdy type of web applications -- stuff where mostly you are firing off prepared statememts at a SQL db and then applying business logic to result set. This is what most J2EE apps do currently.
You're in a Rust thread, I think the general response is going to be, "Yes!" And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work. But, this is also a great opportunity, because it means that you could be responsible for building a…
Ok, so this is an 'opportunity' for some, but a 'big cost' for others.
So remember there are very few Rust devs out there, it is a little bit hard, and though a good chunk of devs might jump at the chance to learn, others, not so much.
It would be a really hard thing to rationally do a 'crud app in Rust' at this moment in time due to all the above reasons. There's a lot of added risk for really no benefits.
If you have a core team that has the skills, ability and is willing to commit to it, then maybe. But we have to think beyond that, when you need another 100 devs ... and people maintaining it ... one can see how other things factor into the equation.
If there is some specific reason and the conditions are right, and if that reasoning is not warped by our own natural tendencies to 'want to use Rust' then there might be an opportunity ... but generally not.
As team members get more excited about 'the problem they are solving' and less 'the tools they use' - you might see an inclination towards other tools, for the most part, at least today, for CRUD-ish kinds of things.
I found parts of that announcement very difficult to follow. Can anyone tell me what the following means? « For too long, open source as both an industry and a community has done a poor audit of its expenses. Notably, ignoring the price of what I’d controversially argue is the core value proposition of open source software: the freedom to collaborate. »
I found parts of that announcement very difficult to follow. Can anyone tell me what the following means? « For too long, open source as both an industry and a community has done a poor audit of its expenses. Notably, ignoring the price of what I’d controversially argue is the core value proposition of open source software: the freedom to collaborate. »
As someone who wants to use Rust for real world applications, what are some good use cases for Rust? Web development is not its strong suite, apparently. Or, better still, what have you personally built using Rust?
A win for Rust for sure, but it also seems like a loss for Mozilla.
This is a very good "partial exit" for Mozilla, actually. The original plan might be to do something like this to split the cost, while oxidized Firefox still reaps more benefits than the competition playing catch-up. Rust can't/shouldn't be directly monitized, so it makes sense to have something like this. Mozilla can still hire as many people as they want, but they never attempted to make it a company-managed proje…
I agree that the main implementation should not, but I could see something like a verified Rust compiler (maybe something like the "Sealed Rust" proposal) being commercialized.
This is worrying to me in that engineers are naively selling their souls to big corporations just to work on Rust.
I'm glad for the formation of the foundation, even though I hear that even Facebook (although not on the board yet) are looking for engineers to work on the Rust compiler.
Yikes.
Earlier quoted context omitted.
I have some extensive (self-assesment :) ) experience building this kind of application, and my answer would be "no, but maybe" (I was one of the first engineers & architect on our zero to ~500k codebase). Some of the arbitrary, random things I've learned: 1. Given how nice and powerful language is, Rust works relatively well with less experienced engineers. Potentially. You can build very nice APIs which are straigh…
> Turned out, strings are not that cheap to clone if all you have is a bunch of strings. Yeah, if you're doing a lot of cloning, you'll probably run into performance issues at some point. A common way to solve that problem is usually to use references instead of cloning. Of course, writing your code that way takes more work/thought/planning.
Right. I think, we ended up with having everything from the list:
1. String 2. &str 3. Cow 4. Arc, for interned strings (thin Arc would be even better & there is probably a crate for this) 5. Something like owning_ref::ArcRef 6. One-off tricks where you actually need to construct a new string, but don't want to really construct it (for example, for hash lookup).
#5 I think is undervalued, actually; it's amazing for "enterprise" kind of stuff where you have large trees of data you need to pass around & you don't want to use straight borrowing (like &'a Whatever) because lifetimes are too infectious. And you don't want to use Arc at every corner (like, say, Java would do, not quite, but in semantics).
My problem, though, was to explain all the nuances given that they usually have nothing to do with the "business" part of the problem somebody was solving.