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

Two Years of Rust

borretti.me

Post reply on HN
Print view View original

11–20 of 69 posts

Re: Two Years of Rust

#11

Post by ninetyninenine »

The mock example looked pointless.

IO can’t be unit tested hence why you mock it. But his code didn’t do anything but confirm his mock worked. He’s writing mocks and testing mocks.

The functionality he referenced is just inherently not unit testable. Again, If you try to mock it and test things you end up testing your mocked code. That’s it.

I’ve seen this strange testing philosophy pop up time and time again where test code misses a shit load of errors because it’s just confirming that the mocks work.

For this area you need to move to integration tests if you want to confirm it works. This comes with the pain of rewriting tests should the implementations change but testing just mocks isn’t solving this problem.

Your unit tests only really matter if you’re doing a lot of big algorithm stuff and not much IO. Mocking helps if you have some IO sprinkled into a unit computation. In the example he gave every operation was IO and every operation had to be mocked so wtf was he thinking to want to place that in a unit test?

Re: Two Years of Rust

#12

Post by apitman »

> The way I would summarize Rust is: it’s a better Go, or a faster Python

That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety.

> It’s not hard to learn

I agree Rust is easy to learn. I've done it 4 or 5 times now.

Re: Two Years of Rust

#13

Post by Dowwie »

Use dependency injection and mock behaviors. This technique works in several programming languages, including Rust.

Rust has modules, crates and workspaces. To optimize builds, you'll eventually move shared resources to their own crate(s).

Re: Two Years of Rust

#14

Post by ratmice »

rcxdude wrote: post #7
ratmice wrote: post #2

> with cargo you praise the absences: there’s no gotchas, no footguns, no lore you have to learn in anger, no weirdness, no environment variables Suppose the author doesn't use build.rs, which appears to have been composed of the listed things almost entirely.

build.rs is a useful escape hatch for if you need to do something more complicated, but the nice thing about cargo is that for the most part the defaults work. Generally build.rs only comes in if you have to deal with C, C++ or some other external ecosystem. A pure rust crate basically never needs to touch it, across multiple platforms and build configurations.

Generally yes, but there are things like lalrpop which are pure rust, I personally fall within the pure rust build.rs user purview...

Re: Two Years of Rust

#15

Post by q3k »

> Error Handling

I've yet to see anyone demonstrate the elegance Rust error handling for anything but the simplest of cases. It's all fun and games and question marks... until you hit this:

    $ ./app
    called `Result::unwrap()` on an `Err` value: no such file or directory
And then you start investigating and it turns out that the error value comes from somewhere deep in an unknown callstack that got discard by the authors using '?' everywhere.

Yes, I know about anyhow and thiserror and eyre and ... ; point is none of this is ever shown in these 'look how elegant error handling is' posts. Come on, let's be a bit more honest with ourselves about Result and '?' - it's not a full solution to error handling. After two years I'm sure you've hit this.

Re: Two Years of Rust

#16

Post by Joker_vD »

ninetyninenine wrote: post #11

The mock example looked pointless. IO can’t be unit tested hence why you mock it. But his code didn’t do anything but confirm his mock worked. He’s writing mocks and testing mocks. The functionality he referenced is just inherently not unit testable. Again, If you try to mock it and test things you end up testing your mocked code. That’s it. I’ve seen this strange testing philosophy pop up time and time again where t…

> IO can’t be unit tested hence why you mock it.

Say, I have this module that uses a private MongoDB as a cache. Its unit tests spin up a standard MongoDB container and use it (and then tear it down). Are they still unit tests or should I start calling them "integration tests"?

Re: Two Years of Rust

#17

Post by ninetyninenine »

Joker_vD wrote: post #16
ninetyninenine wrote: post #11

The mock example looked pointless. IO can’t be unit tested hence why you mock it. But his code didn’t do anything but confirm his mock worked. He’s writing mocks and testing mocks. The functionality he referenced is just inherently not unit testable. Again, If you try to mock it and test things you end up testing your mocked code. That’s it. I’ve seen this strange testing philosophy pop up time and time again where t…

> IO can’t be unit tested hence why you mock it. Say, I have this module that uses a private MongoDB as a cache. Its unit tests spin up a standard MongoDB container and use it (and then tear it down). Are they still unit tests or should I start calling them "integration tests"?

Integration.

Unit tests should just test code units. All the external stuff should be mocked or not tested.

The example in the post is a unit test.

It’s good to keep it separate as unit tests are really easy to run and less complicated and much faster. Integration tests are much more complicated and often sort of freeze your code as it locks in the implementation.

Re: Two Years of Rust

#18

Post by kelafoja »

apitman wrote: post #12

> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…

I agree, there are only superficial similarities. Like they're all 3 C-based. And Go and Rust both compile to machine code. I believe once one of the creators of Go mentioned that it felt to some users "like a faster Python". But I have no clue how Python relates to Rust in any sense, I fail to see any similarities. In fact, I would almost be inclined to say that Python and Rust have more differences than similarities.

Re: Two Years of Rust

#19

Post by dhruvrajvanshi »

ratmice wrote: post #14
rcxdude wrote: post #7

Earlier quoted context omitted.

build.rs is a useful escape hatch for if you need to do something more complicated, but the nice thing about cargo is that for the most part the defaults work. Generally build.rs only comes in if you have to deal with C, C++ or some other external ecosystem. A pure rust crate basically never needs to touch it, across multiple platforms and build configurations.

Generally yes, but there are things like lalrpop which are pure rust, I personally fall within the pure rust build.rs user purview...

Well I wouldn't call lalrpop "Pure rust". It's a separate language that gets compiled to rust.

It's within the rust ecosystem though. Perhaps cargo could expose a simpler way to use code generators.

Re: Two Years of Rust

#20

Post by woadwarrior01 »

kelafoja wrote: post #18
apitman wrote: post #12

> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…

I agree, there are only superficial similarities. Like they're all 3 C-based. And Go and Rust both compile to machine code. I believe once one of the creators of Go mentioned that it felt to some users "like a faster Python". But I have no clue how Python relates to Rust in any sense, I fail to see any similarities. In fact, I would almost be inclined to say that Python and Rust have more differences than similaritie…

> I would almost be inclined to say that Python and Rust have more differences than similarities.

This is somewhat of a stretch: dyn Traits in Rust are sort of like compile time duck typing. OTOH, interfaces in Go and virtual functions in C++ are the same thing.

Post reply on HN