How I went about learning Rust
221–230 of 303 posts
Re: How I went about learning Rust
#222Earlier quoted context omitted.
> Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. Can you explain? What do I set ‘score’ to when someone hasn’t sat the test yet?
The Billion Dollar Mistake refers to the fact that things that are not explicitly marked as "nullable" can be null/nil. In rust, you would annotate score as `Option ` (`u32` is one of Rust's integer types), and then you would set the score of someone who hasn't sat the test yet as `None`, and someone who got a 100 on the test as `Some(100)`.
Rust has NonZero versions of the unsigned types, so NonZeroU32 is the same size as a u32, four bytes with an unsigned integer in it, except it is never zero.
Option promises to be exactly the same size as u32 was. Rust calls the space left by the unused zero value a "niche" and that's the perfect size of niche for None.
As a result you get the same machine code you'd have for a "normal" 32-bit unsigned integer with zero used as a sentinel value, but because Rust knows None isn't an integer, when you mistakenly try to add None to sixteen in some code deep in the software having forgotten to check for the sentinel you get a compile error, not a mysterious bug report from a customer where somehow it got 16 which was supposed to be impossible.
When a maintenance programmer ten years later decides actually zero is a possible value for this parameter as well as "None", there's a NonZeroU32, they swap it for u32, and the program works just fine - but because there's no niche left in u32 the type is now bigger.
Re: How I went about learning Rust
#223I love rust. I didn’t find it difficult to learn and at this point several others I’ve introduced it to also haven’t. I’m baffled as to where that reputation comes from. I get that it makes you think about what you’re building a little more than something you can throw together like Python or Ruby but if the end goal is software that works correctly, getting there definitely isn’t harder with rust. It’s the complete…
Rust definitely requires a different thinking process than most other languages. If you're already doing that kind of thinking, you'll probably have a very gentle learning curve.
On the other hand, the concept of ownership and borrowing takes a bit of time getting used to. Once ARC is in the picture; the curve gets very steep if you're coming from a language with automatic memory management where all state is mutable.
Re: How I went about learning Rust
#224Earlier quoted context omitted.
I mean it depends . Many of aspects of Rust that are perceived as sharp edges are in fact the programmer bringing in their preferences and paradigms from other languages and trying to program that way in Rust. I was one of those and tried to do OOP in Rust. It was a pain. At some point I gave up and was like: "Okay Rust, I do it your way, I just want this to work". And it worked flawlessly and easy. I literally had t…
As someone who even structures their Python in OOP, I'd appreciate elaboration on how you organize your Rust code. I've been glancing at Rust for far too long, never finding a weekend to dive in. Save me some headaches, how should I approach e.g. Customer - Product - Order relations without OOP? What is the canonical "Rust Way"?
So, for my eCommerce app I have something like
struct Line {
order_id: usize,
product_name: String
}
struct Order {
order_id: usize,
customer: Customer,
lines: Vec
}
And this means instead of pointers, using ids (alike RDBMS) is much nicer overall (work wonders that the data is already like that in RDBMS!).You can avoid ids and just embed the data too.
Following the idea of think like in databases, when you need to find fast bring a HashMap/BtreeMap:
struct Line {
order_id: usize,
product_name: String
}
struct Order {
order_id: usize,
customer: Customer,
lines: BtreeMap Re: How I went about learning Rust
#225I have been thinking to myself whether I should pick up Go or Rust as a new language this year. Coming from a NodeJS background, Rust looks a tad more complicated but it looks cooler. There are also more job listings looking for Golang than Rust which makes me wonder if Golang might be a more rewarding investment? What would be a good use case of Rust than Golang cannot do given its extra complexity and potentially l…
I have no experience with Rust myself and a good 2-3 years with Go, so my opinion here is biased but: I think Go is more suitable for general all-purpose programming, whereas Rust is more specialized; I'd pick the latter if you need to do high-quality, close-to-the-metal software, and Go for more generic software, taking the same spot that NodeJS did for you. That said, Go isn't a very "convenient" language; there's…
Re: How I went about learning Rust
#226Earlier quoted context omitted.
Rust actually supports most OOP features, with the main exception of implementation inheritance. And implementation inheritance is a nasty footgun in large-scale software systems (search around for: "fragile base class problem"), in a way that just doesn't apply to simple composition and pure interfaces (traits). So it's hard to fault Rust for including the latter and not the former.
For me it was the web-of-pointers strategy I had to unlearn. A child object keeping a pointer to its parent is misery in Rust. It forces you to either make the child completely independent or really prove the parent will be around until the child disappears. 90% of the time this is dumb overhead, but 10% of the time it found a bug in some edge case, so I learned to appreciate it as a tough teacher, and my designs got…
Code here: https://github.com/prisma/prisma-engines/tree/main/libs%2Fda...
Re: How I went about learning Rust
#227I have been thinking to myself whether I should pick up Go or Rust as a new language this year. Coming from a NodeJS background, Rust looks a tad more complicated but it looks cooler. There are also more job listings looking for Golang than Rust which makes me wonder if Golang might be a more rewarding investment? What would be a good use case of Rust than Golang cannot do given its extra complexity and potentially l…
Beyond things like borrow-checking; the language introduces a LOT of concepts that are quite foreign. Exposing yourself to them is good; because I expect that future languages will borrow heavily from Rust.
Re: How I went about learning Rust
#228Earlier quoted context omitted.
What are you looking for in the 2 languages? Here are some of my thoughts: Golang * Development speed: Golang wins by far. It's closer to Python in that regard, but with strong typing. * Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side. * Large garbage collector penalty. Rust * Complete language with build system, cr…
> Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side. Except for all the times they are required and Go doesn’t tell you: https://eng.uber.com/data-race-patterns-in-go/ Go’s fundamental semantics are standard not-safe shared-memory multi threading. It provides an mpmc queue as a built-in out of necessity (since no gene…
You sound like you don't know why they explicitly refuse to add the ability to get a handle on the goroutine. If you do know, you are misleading people by omitting it.
Re: How I went about learning Rust
#229I tried to pick up Rust a few years ago, but there were too many sharp edges. I thought it was a nice language, but was too early for actual use. I played with some libraries (Apache Arrow, etc) and it was nice. About 2 months ago I wanted to use Arrow within Elixir, which required me to start using Rust again (Elixir uses Rustler to safely convert from Rust Elixir without theoretically crashing the beam). I am amaze…
However, if I'm not mistaken, the language still has no formal specification.
It was very valuable, say, twenty years ago, when there were most programs were written or compiled using multiple closed source implementations of languages coming from competing companies. There were real economic incentives for the implementations to diverge from each other in ways that harmed the larger ecosystem. A formal spec was a forcing function to make those implementations compatible.
Today, programmers simply won't use a language whose implementation isn't open source with a very permissive license. This makes it very hard for an organization to deliberately make the implementation incompatible with others because other organizations and users are able to either avoid the incompatibility by forking the implementation if they don't like it, or making it compatible by using the implementation if they do.
I still think it's very valuable to have a committee with members of all implementations that helps drive consensus for where the language should go. But the document itself I see as secondary to that human process.
Re: How I went about learning Rust
#230Earlier quoted context omitted.
Go is fun at first, and then it becomes soul sucking. It's all boiler plate. Many large scale projects have a lack of adequate unit testing, so large code bases are particularly painful to maintain. I attribute this lack of tests due to how the code needs to be structured, you have to needlessly add 'interfaces' throughout your code to accomplish things. Go has it's strengths, but IMO fun isn't one of them. It turns…
I'm in the same position as OP and was wondering the same thing; finding a job using Go. Is the bloat that you see the most related to error checking? If not what else is it?