3 ms·
When it comes down to it, everyone seems to have their pet abstraction. Everyone except the old grumpy programmers. And YAGNI always applies, to some degree, be
by chipsy 11y ago
When it comes down to it, everyone seems to have their pet abstraction. Everyone except the old grumpy programmers. And YAGNI always applies, to some degree, because you can always build back up to some approximation of the "gotta have" abstraction from cruder primitives.
So the benefit of the language design is to make it so that the abstractions you _do_ use play well with everyone's code instead of being a ball of duct-tape and easily broken conventions.
I think that is missed when people go looking for a language with power tools. You can already do things too powerful to comprehend in C if you add enough macros and pointer indirection. But if you sit down trying to solve a problem using fewer language features instead of more, you usually come out ahead - because then you're forced back towards first principles about what the project needs and see the abstractions in the proper light. Powerful languages lead to an ecosystem of correspondingly powerful libraries, which drags you into the mire no matter what.
While both Rust and Go are at a lifecycle stage where they're dogged by language window-shoppers, Go is actively resisting the people who didn't intend to make a purchase, leading to "Go not powerful" whinge blogs. We end up knowing less about Rust's productivity because most of the early adopters are going to be the kinds of people who seek innovative ways to break compilers - demanding customers, who don't give much back.
That doesn't mean that Rust is actually unproductive, as it's quite likely that if you try to write C-style code with few ornaments, you will have little difficulty doing so, and the technology will mostly break in your favor. But it does mean that it'll take longer to work up momentum for a production-ready ecosystem, since the conversation will continue to revolve around "ooh, we've never done that before's" with borrow checking and metaprogramming. And when it's all over, it's likely that simpler ways to do these things will come to light - either in Rust or in another language.
- pcwalton 11y ago> And YAGNI always applies, to some degree, because you can always build back up to some approximation of the "gotta have" abstraction from cruder primitives. What I was saying with point (2) is that this is explicitly not true for Rust.
- chipsy 11y agoYes and no - it's a tradeoff abstraction. The borrow checker is a whole-language design directive, and its strength comes from giving up something in other areas - in this case, having to use generics everywhere. A language, as I said, is mostly made up of these intentional tradeoffs to try to find an appropriate balance. You can still express the abstractions of Rust through another language, though it may take writing another compiler on top to actually do so - they just won't hold the same utility, because the utility of this abstraction is mainly tied to the "zero-cost" implementation method, not to whether it has expressive powers.
- deleted 11y ago[deleted]
- edgyswingset 11y agoMany of the abstractions Rust has have their nuances hashed out at compile-time rather than run-time, and that's the big benefit. Go programming eventually forces you to do primitive stuff like stuff print statements into your code and tinker with a compile-run-compile-run cycle that ends up wasting quite a bit of time. For something like microservices it's actually quite good because if you keep your scope as small as possible, you end up with dead-simple code for dead-simple tasks ... until you need a way to reign in all your microservices, where it starts to fall apart because you've got unavoidable complexity and a tool that isn't designed to handle complex things. Tools like Rust start to shine in these situations.