5 ms·
This looks like a great resource! https://rust-exercises.com/03_ticket_v1/07_setters https://rust-exercises.com/03_ticket_v1/07_setters This shows why I wouldn
by sergiotapia 2y ago
This looks like a great resource! https://rust-exercises.com/03_ticket_v1/07_setters https://rust-exercises.com/03_ticket_v1/07_setters
This shows why I wouldn't use Rust for anything. Seems like a lot of verbosity for gains that don't really apply whatsoever for the kind of work I do (web apps and APIs). You have to remember let/mut fine, but then ownership/borrowing, and finally this `into()` thing - yuck! Like washing your face with sandpaper.
- jamil7 2y agoThere’s a world outside of web development.
- sergiotapia 2y agointeresting!
- steveklabnik 2y agoAlso, just because these examples are verbose doesn't mean that all Rust code is this way. Accessors/mutators aren't used super often in my experience, and the builder pattern is used occasionally, but isn't pervasive. (I have historically been very skeptical of Rust on the web, but by now, I find it pretty pleasant. I of course know Rust very well already though.)
- littlestymaar 2y ago> I of course know Rust very well already though Understatement of the week ;)
- LukeMathWalker 2y agoAgreed. There's also another aspect at play: to build knowledge one step at a time with this learn-by-doing approach, you have to get learners to write code that's not perfectly idiomatic along the way. You then correct and refine those first drafts as you progress along. In the case of setters, we get rid of them at the end of that chapter by using the newtype pattern thus guaranteeing that field invariants can't be broken even if you can access them directly.
- jimbob45 2y agoHe's right, though. Languages today shouldn't force you to jump through low-level hoops if you just want to write high-level logic. Likewise, the low-level devices should be easily and ergonomically accessible. Rust is phenomenal at the latter but weak at the former.
- jamil7 2y agoWhat languages scale better in that regard? Genuinely interested in recommendations.
- jimbob45 2y agoC# and C++. In C#, you can use pointers but most people don't even know because they so gracefully become invisible. Also ref/in/out keywords are there when you need them and invisible when you don't. Likewise, you don't even need to know about move semantics in C++ to make a simple web server. That said, C# and C++ most certainly have their fair share of issues.
- pkolaczk 2y agoCompared to most popular high level languages like Java or Go, Rust is seriously at the more expressive end (read: can be higher level).
- amne 2y agoBut who's forcing you? Oh .. the companies jumping on the latest "in Rust" hype. I see. Just do your thing and be good at it. PS: There was this VSCode extension to do BI stuff in the IDE (quarylabs/quary) showed here on HN and once I saw the CLI core having "Rust-based" as a feature I just closed the tab. What does "Rust-based" even mean? The tool may have been good but Rust is not a feature.
- mrkeen 2y agoIt seems like Rust is doing a pretty good job of applying to web apps and APIs: https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks
- devjab 2y agoYou get ridiculous performance gains with Rust a web backend. Even Microsoft is rewriting part of their C# backend to Rust on the 365 application side of things. Which is where you get to deal with the hefty ms-graph api which handles literal fucktons of data. Anyway. It is more verbose than something like Go or Python. I’m not sure it’s really so bad compared to most languages, but some of the benefits you get from the verbosity is that you gain a lot of control over how you use mutability and the borrow checker or how you work with memory in general. Things which are foreign to many developers today, but you shouldn’t compare a Rust implementation to a C#/Java/Python/Ruby/Node/Go api, you should compare it to a c/c++ api… which is where Rust is just so much “safer” for production. We have Node APIs in Typescript, we have Python APIs with FastAPI, we have C# web APIs and we have a few Go APIs. We’re perfectly happy with those, well maybe not the fact that we use so many languages, but we’re happy with them. Where we use Rust is where we used to use C, and the benefits are massive. You get the same sort of performance, but you also get an environment where programmers with less experience working without garbage collection can do work we just couldn’t have them do with C.
- pjmlp 2y agoOffice team never was a big .NET fan, and they were partially responsible for Longhorn's failure, see also Hilo C++ tutorial made by the team as part of Vista SDK tutorials, or their love for Webwidgets to C++ code, so that isn't that surprising. It isn't as if C# vlatest wouldn't be able to take up the task, Bing, XBox game servers, and other large scale services are fully on .NET.
- deleted 2y ago[deleted]
- tialaramex 2y agoBut like the Office services, these are all significantly older than Rust. Bing the branding is like 15 years old, the underlying service is older still (as "Live Search") So when this stuff was built the high performance option was C++ and there is an obvious reason to avoid that if you can. Rust means you can have the excellent performance without the absurd foot guns. Whether you chase that depends on other strategic priorities.
- simonask 2y ago`into()` just converts something from one type to another, like an integer to a floating point number. Would you have liked for such conversions to happen implicitly? Because let me tell you, that is one of the most painful features of C++, and modern well-written C++ typically disables implicit conversions in one way or another. (Note: For the specific example of integer-to-float, Rust has an alternative built-in syntax, but `.into()` is the canonical way that also works in generic code.)
- vrnvu 2y agoWell, nobody forces you to use the setters/getters pattern. For internal implementation, you could access everything directly. For example, Zig encourages this style of programming. In my experience in Rust, the use of getters and setters is less common compared to some other languages like Java.