struct Connected { peer_ip: u32 }
   struct Disconnected;
   struct Connection<State> { state: State }

"Look how easy it is to accidentally bypass the invariant of a rust newtype by transliterating the data shape into Haskell and deriving a new type". Uh, ok.

If comparing the "risk of accident" between a newtype wrapper whose only role is enforcing the the invariant versus manually reimplementing vector and iterator semantics to use a different layout... I'd say the newtype wins that.

It would be good advice to keep a newtype that enforces an invariant as a single purpose primitive type. A building block and not a place to add other features.

There might be times I'd prefer structural enforcement e.g. something serialisation related. Converting into a non-rust format is what they are doing in their "accident"!

DerefMut to [T] not Vec<T>.

You can use all the slice reference methods (that do not require ownership) with:

    impl<T> Deref for NonEmpty<T> {
        type Target = [T];

        fn deref(&self) -> &Self::Target {
            &self.v
        }
    }

    impl<T> DerefMut for NonEmpty<T> {
        fn deref_mut(&mut self) -> &mut [T] {
            &mut self.v
        }
    }

If you DerefMut to a Vec then you won't be able to preserve the invariant.

If you want control over methods to expose then you need wrapper methods for those you want. If you want to expose some of the traits the inner type implements then there are likely derive macros available e.g. with derive_more you could expose just indexing as:

    #[derive(Index, IndexMut)]
    struct MyVec(Vec<i32>);

Haskell's strong, static, non-reflective type system tends to make "parse, don't validate" produce code that also looks nicer. Which is great. So great that it steals a bit of the main message's valor.

In Python, though, it's really easy to just let your data be a dynamically typed list of dicts forever. So easy that parsing into something more strongly typed looks like a whole lot of extra effort. Upon looking at that sort of thing many a working Python programmer, myself included, hears the voice of GvR murmuring disparaging things about "academic" programmers down in the pit of their brain.

Which creates an opportunity to demonstrate all the ways the (arguably) more Pythonic way is actually a royal PITA when you try to make your code robust. Handling and reporting data validity errors gets scattered all over the code, which makes it annoying to maintain. Unit test suites get bloated because it's not obvious what inputs a function should be able to handle. Comments and docstrings to help keep track of this stuff begin to proliferate.