1. 33
  1.  

  2. 6

    I think people are rediscovering the benefits of static typing for performance and correctness reasons. The latest generation of statically typed languages[0] all have some level of type inferencing which helps.

    If Python is fast enough for you, it’s a fantastic language. The problem is once performance or codebase demands scale, dynamic typing rears its ugly head and there are no simple solutions. At work we sidestep this issue by writing a plethora of tests, but now dynamic typing productivity gains are offset and we spin up a lot of AWS instances to scale performance.

    [0] Go, Rust, Scala. Haskell and OCaml have had it for a while.

    1. 2

      I think we’re over-emphasizing speed here. It’s true that for some kind of applications speed should be optimized for ground up. It’s a good with have choices, especially choices designed by Ken Thompson. That said, the reason people choose frameworks like Django and Rails is not because they need raw application speed. Developers need frameworks to write code quickly, avoiding mistakes. So it’s a nice thing that we have Rust and Go, but let’s not get over-excited. Both of these programming language have a serious lack of libraries and community support for professional development today. We’ll see how they evolve in the years to come.

      1. 1

        Speed is absolutely available in Python if one codes in a reduced subset as shown by Shedskin. Python is a wonderfully flexible language with rich metadata support than can enable programming in-the-large via decorators, macros and quickcheck. No reason to leave.

      2. [Comment removed by author]

        1. 9

          This is a good example of an unconstructive comment.

          Go authors and most Go users are perfectly aware of generics, sum types and pattern matching. Not including them in Go is a design tradeoff that is well documented, for example in the FAQ: http://golang.org/doc/faq#generics http://golang.org/doc/faq#variant_types

          Instead of suggesting that Go users are uneducated about modern programming languages, please discuss the design tradeoff.

          1. 4

            Indeed it is not a particularly constructive comment. However ignorance of things like generics, sum types and pattern matching is very real among developers, especially those coming from Python or similar, in my experience. In particular many people have been abused by Java and thing that is what a static type system looks like. So my tone is certainly flippant but the content is serious.

            On another note, the argument against variant types strikes me as odd. Unless I am missing something, I don’t see why a sum type where the value is an interface is particularly difficult.

            1. 1

              I agree that developers coming from Python, Ruby or similar often ignore the existence of generics, sum types and pattern matching. Because of this, they choose and use Go without understanding the tradeoffs, especially compared to languages like Rust, Scala, Haskell or OCaml, to just name a few.

              I also agree that programming in Java for a long time can leave the impression that static typing is a useless mess :)

              But I also repeat that Go authors and a large part of Go users are well aware of the “nicer” forms of static typing.

              About variant types, there are several interesting threads on golang-nuts about this, for example: https://groups.google.com/d/topic/golang-nuts/0bcyZaL3T8E/discussion https://groups.google.com/d/topic/golang-nuts/-94Fmnz9L6k/discussion

              Take the time to read them and you’ll have your answer about why it’s difficult to make variant types and Go interfaces play well together.

              Here is an excerpt from an answer from Russ Cox:

              What does

              type RW union {
                  io.Reader
                  io.Writer
              }
              

              mean? Or is it disallowed? (That would be pretty unfortunate.)

              What happens if you have

              var r io.Reader = os.Stdin  // an *os.File
              var rw RW = r
              

              Can you say rw.(io.Writer) and successfully pull out the *os.File (which is after all both).

              What is the zero value of a union? Why is that okay?

              1. 1

                I only skimmed the discussion but I still don’t see what the actual problem is. Simply have a constructor for union elements. The discussion seems mostly about untagged unions (a la C) which are terrible. But sum types/variant types can have constructors. They are tagged unions where the compiler is generating you the boiler plate for dealing with the tag. The cost semantics are fairly clear. In Ocaml this type would look like?

                type RW = Reader of io.Reader | Writer of io.Writer
                

                And you construct these things like:

                Reader reader
                

                But I don’t use Go so maybe this is rather difficult in the language. But this problem has been solved for quite awhile.

          2. 1

            Java added generics in v1.5. There’s still hope for Go yet.

            I doubt they’re going to go as far as algebraic data types and pattern matching though. The crowd that wants that stuff has already moved on to other languages.

            1. 3

              And that’s why generics are such a mess in Java. Also, if the reasons for not having generics in Go are honest, it’s unclear what will change, that hasn’t in the last 40 years, that would make generics something the authors would want to implement in Go.

              My sarcastic comment wasn’t meant to say Go would get these things necessarily, but the people moving to Go might discover them and hop to a new language. It’s not like Python got static typing, people are just realizing that their current tools have limitations and moving on.

              1. 1

                I agree. Java 8 is added option types but unfortunately that’s not going to get rid of NPE’s because of developer inertia and legacy code.

                1. 4

                  Well, it’s not going to solve NPE’s because that would require a complete overhauling of the type system…

        2. 1

          does spacemonkey https://www.spacemonkey.com/tour use some of “your” device to store data from other people? that’s the only way i can make sense of it, but they don’t seem to say so anywhere.

          does that mean it actually contains a 2TB disk? or is on average only half available to each user? or less (if there’s more redundancy)?

          1. 6

            Yeah, it looks like we don’t mention that anywhere obvious, but the device actually has a 2 or 3 TB drive in it. You get 1TB for your primary copy of data, and the remaining space is used for Reed Solomon-encoded and encrypted chunks of inode and block packs from others.

            1. 1

              oh cool! that’s great. i was really, really suspecting it was a 1TB disk. thanks for the clarification.