Hacker News Reader

Comment by loup-vaillant | Hacker News Reader

> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem.

Dunno about Rust specifically, but I have written a little Haskell, and a significant amount of OCaml. I found that the type system reduces my cognitive overhead, compared to looser languages like Python or Lua. The compiler is disciplined, so I don't have to be.

In practice, with few exceptions, when the type system is refusing to compile something I just screwed up, and I'd better fix my mistake right away. I'd wager that with few exceptions, when Rust is refusing to compile something, you are making a mistake that in C++ would have bitten you down the line.

What you call "fighting the type system", I call "fixing bugs".

View on HN

> you are making a mistake that in C++ would have bitten you down the line.

Taking some C++ code from an explorative phase that "usually works kinda ok" to something seaworthy requires, in my experience, a huge amount of work (which usually neglects a few issues that will bite you later regardless). I'm not so sure the (probably) faster exploration in C++ compensates for this compared to more "strict" languages like Rust.

Of course, if the functional requirement is only "usually works kinda ok", then you don't really need something like Rust.

I found that strict compile time checks speed up my exploratory phase. That's because the type system provide an even tighter feedback loop than a REPL, and effectively cuts down the search space.

Other people seem to have experienced the opposite, though. I have no idea why.

It might depend on the problem space. I dunno. But I suspect it depends a lot on the type system and type inferencer of the language you use.

It is easier to write a true statement than it is to prove the statement is true, and getting a compiler to agree to compile quite literally requires proving a statement is true. This can be more or less difficult based on the language. I’ve read a lot of war stories, particularly in java, about having to do a lot of crazy convoluted code to get the compiler to realize that yes actually these 2 objects are interchangeable from an API/Interface point of view. I don’t know, but I suspect this may be a lot less common in languanges using hindley-milner type system, since that lends itself to very good type inferencing.

To me, the question is whether the time spent dealing with compiler errors is due to fixing real problems that the compiler is pointing out, or whether that work is mostly reworking a correct program to satisfy the compiler when it cannot yet see that the program is correct.

I don't think humans have anything major in their toolkit for reasoning about memory management / aliasing that the Rust compiler doesn't; when non-trivial code cannot be expressed in terms of single-ownership at any given point, code loses correctness-at-a-glance. There are cases where a safe Rust abstraction is built on unsafe code, including most of Rust's collections; the API contract of every stdlib collection is: the collection owns its elements. Interestingly, such a contract can generally be implemented safely, but would have different performance characteristics; e.g. doubly-linked List could use indexes into a Vec. This example mirrors a pattern seen in languages that discourage mutation: break the rules internally for performance optimizations, but maintain the invariants at API boundaries to contain the cognitive overhead. Even when Rust's rules need to be broken, they are useful to contain complexity.

Couldn't agree more. It was why my transition from Javascript (Node) to Go was very freeing - I had been so used to being constantly paranoid about my data types from Python and Javascript that even the most modest types of Go made a huge relief.

Likewise, with Rust it is a relief after Go. In Go interfaces are a massive part of the language and they can only be pointers, which means much of your programming experience holds mental overhead needed to frequently answer "is this variable safe? Can I access it, or might it be nil?".

There's definitely overhead in learning how to use the borrow checker, but I feel that's the same as any basic language features in any language. Once learned, I largely don't think of them, and I don't fear using variables or what is concurrently safe anymore.

I can definitely see where the author was coming from in terms of new code. I've been of the opinion that it's probably better to greenfield new systems alongside a GC'd runtime(which makes Go a pretty good fit, but also D, Nim, etc. - and for the very experimental stages where the type layout is minimally understood - Python, Lua, JS, etc.), and to take on external dependencies to get a result working - and then rewrite parts with manual memory and custom libraries where the spec needs tightening.

The main downside to this is that you're rewriting stuff, but the goal of the rewrite should be to express what is essentially the same functionality in more detail.

Where I think the author might have erred is in switching between three different manual memory languages in the hopes of faster development. The algorithms needed for a 3D tool have a pretty high base complexity, making it hard to bootstrap the codebase - and I suspect that C++ will ultimately frustrate him just as much as Rust and C did before.

Ah, but in this case you have already done the spec, otherwise the type system couldn't have checked it.

With a more loose way of going about things, you don't have to write the spec. Spec'ing is hard, sometimes harder than actually solving the problem.

I feel like someone is going to point out that spec'ing is a lifesaver in a certain situation, and I would agree. But perhaps not all situations.

I worked professionally in Haskell for a long time and I cannot disagree with you more. This is always the promise of strict functional languages but in a business setting where the very nature of what you build has to be arbitrarily mutable at the whim of competing interests between stakeholders, engineers, customers, etc., it just doesn’t work.

You end up with the same spaghetti code messes, unexpected runtime errors, indecipherable crashes, etc. no matter what degree of strict verification tooling you use. The introduction of lazy evaluation, difficult to debug tail recursion implications on memory consumption, elevating IO into the type system, burying details deep in type class patterns, relying on dozens of special case compiler directives to enhance Haskell... it becomes the same shit code mess as any other paradigm.

Interesting. I would be interested to know more details about what you worked on and with whom. This hasn't been my experience in any of the four jobs I've used Haskell at.

I don't deny that Haskell leads to spaghetti code messes, unexpected runtime errors, and indecipherable crashes, but the Java that I've previously worked with and the Python I currently work with suffer from those to a degree greater by an order of magnitude.

It was first for a bank, later for a data analytics start-up, and then also for an education technology company. I had many skilled functional programmers on my team too, including a few people who had done work on GHC itself.

I’ve also see code messes in many languages. It’s a business culture problem, has nothing to do with the language or paradigm.

I’ll greatly dispute with about Python though. It has been a language that facilitates notably cleaner and more extensible implementations in my experience. Seen messes in Python too, but absolutely no way it’s “an order of magnitude” worse. That’s simply ridiculous. The only way that’s happening is if the programmers are exceptionally bad to the extent that it would not matter which language they used.

Very interesting. I suspect we may even have worked for the same bank! I'd love to discover how we came to such opposing conclusions.

To give you a Python example, it encourages stuff like:

    def send_email(recipients, contents):
        if type(recipients) == str:
            send_one_email(recipients, contents)
        else:
            for recipient in recipients:
                send_one_email(recipient, contents)

That is a flavour of convenience that people commonly implement in Python. People like it because it allows both

    send_email("tome", contents)

and

    send_email(["tome", "mlthoughts2018"], contents)

and saves them from typing two square brackets. The problem is when you call

    send_email(u"tome", contents)

It tries to email "t", "o", "m", and "e". This kind of stuff is endemic in Python. Yes, this did happen in practice in a company I worked for (a company that was responsible for trading hundreds of millions of dollars of securities every day). Call the programmers exceptionally bad if you like, but they were among the brightest minds graduating in my country. It was Python that allowed them to be sloppy.

I disagree very much. The Pythonic way would be to do something like map(send_email, list_of_addresses), and have send_email raise an exception if not passed precisely a single string, and presumable raise exceptions when you validate that the email address is of an acceptable format, etc.

It would not be Pythonic to make the function superficially handle different arities of argument through explicit handling on the list type with isinstance, precisely because you’d need to handle different meanings of different types that implement the Iterator Protocol. That’s not something Python generally encourages, it’s just a mistaken implementation. And particularly not making careless assumptions when basing branches on isinstance behavior (for example, you could always encounter custom classes that have overridden __instancecheck__ or __subclasshook__ special methods.

It's certainly a poor use of Python's flexibility, but I've seen that kind of thing written at two completely different companies by completely different, yet smart, people so I suspect it's prevalent. Haskell does a much better job of nudging smart people to write good code. Gabriel Gonzalez explained it better than I could: http://www.haskellforall.com/2016/04/worst-practices-should-...

This isn't really spaghetti code, though, it's a syntactic sugar optimization gone wrong due to the Python 2 str/unicode split.

It's in the same league as people overloading operators in C++ to do silly things.

While some people like to harp on that, I don't think those instances are prevalent enough to actually cause that many bugs. YMMV.

> in a business setting where the very nature of what you build has to be arbitrarily mutable—

I just don't use Haskell there. I personally use OCaml for my data in, data out problems (compilers, generators…), but for inherently interactive and mutable stuff I just do imperative programming. Of course the type system (and the performance characteristics of the runtime!) must be suited to the problem domain.

> burying details deep in type class patterns, relying on dozens of special case compiler directives to enhance Haskell...

Looks like someone went overboard. I think you (your team?) should have been more conservative with the compiler directives, and less abstraction loving with the type classes.

> “Looks like someone went overboard.”

All these things are basically bare minimum table stakes to do anything in the language at all, particularly enabling dozens of compiler directives for language feature extensions. That is Haskell 101 practically, which is actually one of the hugest problems with the language.

Saying this is “overboard” in Haskell is out of touch with the practical realities of using the language.

That is an oversimplification, very often you know something that cannot be expressed in the types, so escape hatch (cast/unsafe) are useful. That said, if you can wrap around these 'hack' in a 'sane' API, then it's OK if you canno/didn't the result is quite ugly..

Reply on news.ycombinator.com