1. 12
  1.  

  2. 3

    The ‘three laws of informatics’ formulation is fantastic, & since it’s widely applicable, probably justifies tagging with ‘practices’.

    I’m not convinced (in general or by this article) that either rust or java are especially well-suited to catering to this formulation of priorities, but I stand by the priorities & their order. (In particular, I find explicit typing to encourage fragile & difficult-to-generalize code: type names litter the code even when they’re used for temporary & ultimately irrelevant to the logic, and attempts to hide these irrelevancies produce superfluous abstraction layers that do little but convert types & end up also hiding meaningful detals. The result is maintenance difficulties. I would prefer this kind of thing to be mostly out of band, deferred to a type checker, as in scala.)

    1. 3

      The ‘three laws of informatics’ formulation is fantastic, & since it’s widely applicable, probably justifies tagging with ‘practices’.

      Author here. Thanks for giving ‘the three laws of informatics’ some appreciation ;-). I also really liked the formulation, and considered splitting the article in two – one part 3 laws, one part Rust.

      You are right to say that Java is not particularly strong at any of the Three Laws, but it’s also not particularly bad either. However, it has a huge community – and many talented folks, interesting ideas to escape the limitations of the language, etc.

      I started my professional career before Ocaml or Haskell got trendy (but I was using them as a student). When they got (relatively) more attention, I considered switching gears but the benefits were not strong enough to justify it. Sure, they’re far better languages than Java. But that’s not enough.

      Scala is different. I actually went to Scala from OCaml, before getting aboard the Java train. I was very enthusiastic about Scala but I think it shot itself in the foot several times (community issues, compatibility problems, refusal to hear valid criticisms). I also think Scala is too much in between OO and FP, it was its goal in the first place and was an interesting experiment, but I don’t think it provides a solid foundation. Finally, there is in my opinion too much freedom (syntactically), code tends to become messy and unmaintainable, with a lot of implicit costs.

      I also don’t see why you think more things are deferred to a type checker in Scala than in Rust. They are pretty similar in that regard except for implicit conversions (local inference, mandatory typed signatures and explicit generics). Scala also inherits subtyping and object-oriented polymorphism from Java, while Rust has none (and thus helps not hiding meaningful details). Haskell or OCaml, on the other hand, give that freedom of writing very few types (though people often still write them as comments for documentation). It is a comfortable experience, but I’m ok with having only local inference (and good refactoring tooling!)

      1. 2

        I also really liked the formulation, and considered splitting the article in two – one part 3 laws, one part Rust

        This is a really good idea. The three laws could hold a whole article on its own (or even multiple) if you expanded it.

        I was very enthusiastic about Scala but I think it shot itself in the foot several times (community issues, compatibility problems, refusal to hear valid criticisms). I also think Scala is too much in between OO and FP, it was its goal in the first place and was an interesting experiment, but I don’t think it provides a solid foundation. Finally, there is in my opinion too much freedom (syntactically), code tends to become messy and unmaintainable, with a lot of implicit costs.

        My experience of scala mostly aligns with that – scala has the same kinds of design problems I see across the JVM world. The ability to rely upon type inference across a large codebase (and therefore, to have generics become their type-specific variants at compile time) was particularly useful to me, though: it made iterative development (both at a REPL and in vim) comfortable.

        1. 1

          This is a really good idea. The three laws could hold a whole article on its own (or even multiple) if you expanded it.

          Thanks, I’ll consider it. I am particularly glad that you liked them while not being infatuated with Rust (yet!) :-).

          1. 2

            I work with some Asimov fans who are wayyy too willing to sacrifice both correctness and maintainability (in addition to literal man-months of dev time) for dubious performance improvements in corner cases, & maybe this formulation will get them to think about the subject differently :)

    2. 4

      Rust is the first popular language to propose an alternative — automatic memory management and safety without garbage collection 

      This statement is inaccurate. C++ has automatic memory management without garbage collection, thanks to RAII. But C++ comes with a lot of baggage from the past, unsafe default behaviors, and subtle pitfalls. Whereas Rust is a clean start that takes the good parts of C++ and none of the bad parts.

      But overall, a well-written, information-packed article.

      1. 1

        This statement is inaccurate. C++ has automatic memory management without garbage collection, thanks to RAII.

        I knew about RAII in C++, but (please correct me if I’m mistaken) it is not enforced by the compiler. By the same metric, C with Boehm’s GC has automatic memory collection. Sure, in Rust a developer can use unsafe and escape the compiler, but it is an explicit act and, when using an open-source 3rd party lib, pretty easy to grep.

        1. 1

          RAII in C++ is basically an add-on.

          After fighting with random SIGSEGVs on some large C++ codebase I was asked to maintain, I disciplined myself to either use RAII and pass-by-reference, or having a mandatory public ok() function returning false if something went wrong in the constructor. Years later, I found Rust compiler enforced what to me was the best practice.