The Unix Philosophy and Elixir as an Alternative to Go

Forgive my constant stream of edits. It started off as a short reply but I kept coming back feeling "It's a programming language discussion, ugh. I really should elaborate."

Lots of people contributed to the Unix philosophy, but ESR's contributions alone are 17 rules and people only tend to talk about 1-2 of them so that's why I referred to them as "oft-butchered."

I would say FP satisfies the Unix streams ideal due to how you transform data through functions and pass this data to other functions. Elixir's pipe macro just makes this read more naturally. The modularity comes from the Erlang concept of "applications" and Elixir takes this further with umbrella applications.

I've written quite a bit of Elixir and I can't say that I've ever really needed to interop with the kernel or POSIX APIs at all. One of the reasons I use Elixir is because BEAM handles all of the crap I used to write in other languages (Async I/O APIs) to make them "fast." Heck, a lot of people even think Erlang got microservices right nearly 30 years ago!

I did write some Go long before I ever wrote any Elixir so my experience is similar to OP. Go has a great niche in infrastructure tooling due to compiling to a binary, having a nice stdlib for tedious server-related things (TLS, crypto, etc). and supporting cross-compilation. That said, I'll never write servers or business application logic in Go again. Elixir is just the better tool for the job there.

" I know that and I'm a big fan of programming in it." Me too btw. :)

I see your point, yes that is absolutely true. I think one reason why Erlang is great because they realized that exposing the POSIX threading APIs to software developers is harmful. :) Why would you ever want to know how many cores you are running on? If you know it you have to keep track of it and adjust it on different systems and bunch of other issues. On the top of that POSIX threads are so expensive that it totally did not make any sense to implement a system that allows the developer to create a thread. I think Joe & team made an excellent decision there. On the other side, you can't really access these low level primitives so this is I guess what you are talking about. For the low level stuff you need a systems language (C,Go whatever).

Oh, yeah, JVM based actors are kind of interesting. I am not sure how can they meet any latency SLA. The GC is skewing the response time potentially, right? In Erlang/OTP it does not happen because of the GC implementation as you know.

The new FFI is on its way, but it might arrive only on Java 10.

The speed of the FFI really affects how a language ecosystem uses it; if it's a lot slower to call out to external libraries than to call code written in the same language, then there's a large incentive to rewrite all dependencies in the language as opposed to using what's already there. Sun's libraries are a bit of a special case in that Sun really tried to rewrite everything for strategic/political reasons, but look at Android; the heavy lifting in the Android stack is done by Skia, OpenGL, and Blink/WebKit (to name a few), a strategy which works because JNI is relatively fast. Python also heavily favors using C libraries where appropriate, again because Python C bindings are fast.

I don't understand the issue about cross-compilation. You don't need a cross-compiler to statically link against native libraries; you just need a binary library to link to and a cross-linker (which can be language-independent). And, of course, if you dynamically link, you don't even need that much.

I'm not really trying to ding Golang, in any case. M:N scheduling has benefits as well as drawbacks. FFI is one of the downsides. There are upsides, such as fast thread spawning. It's a tradeoff.

Mmm? https://cffi.readthedocs.org/en/latest/overview.html (basically a port of luajit's ffi) http://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.h... (ruby DSL to libffi)

Normally this occurs because you're running a large number of "green" threads on your own scheduler which schedules onto a thread pool underneath. This is good if all your threads are small/tiny since userspace thread creation is cheaper than creating an OS thread but if your jobs are long-lived then your userspace job scheduler is really just adding additional scheduling overhead on top of the overhead that the OS already has for thread scheduling and you would have been better with OS threads. If your M:N threading requires separate stack space for each job, there can be a sizeable overhead (this is why Rust abandoned M:N threading).

What you're describing are just simple data structures. Erlang has no user-definable data structures. I don't recall anything I've read explicitly stating this, but I've believed for a while that this was the case because it made moving terms across the network simpler. Thus, libraries aren't "exploiting" a few basic data types... they're stuck with a few basic data types. There's no alternative.

That really has nothing to do with 'homoiconicity'. Erlang code is not a data structure, and it is not spelled in Erlang terms. And that would generally not be a good thing! Erlang's already plenty verbose without also having to be expressed as legal Erlang data terms.

(The generally loosy-goosy typing that results is one of the reasons I don't like Erlang and am moving away from it. But YMMV.)

Martini is very 'magical' and makes it hard to see exactly what's going on, making it quite unusual as a Go framework, so naturally it drew some criticisms. After some experience with the library, Jeremy realized that he actually needed a lot less to do what he wanted, so he wrote Negroni.

http://finance.yahoo.com/news/google-thinks-knock-one-oracle...

Pike said exactly the same thing(video is on youtube), another Go guy said exactly the same thing in a podcast ...

So yes, Go language is DONE, period.

> But why should they worry about ...

They don't, however people adopting Go and wanting generics shouldn't be tricked into thinking that Go developers are even considering generics , because they are not. If they invest in Go, they should know that they aren't going to get generics at all. As for what the Go team thinks, it doesn't really matter they are not betting their own startup on Go.

> they will start rolling out 2.0 and it will have new features

where did you get that idea? it is impossible to add significant new features without breaking backward compatibility, do you really think Go designers are ready to go that way? of course not. But i'm curious what led you to think that ?by all means, give me official sources like I just gave you.

Well, you could do this in any language that has 'eval' really, which includes most dynamic languages. Unless you're referring to something else?

I was really into Prolog back in the university days, to the point of being into logic programming competition between universities.

Got to understand Erlang at the first try, when reading about the language or watching web talks.

It pretty much depends from where one is coming from.

However, in terms of barrier to entry for developing in, I actually think Erlang's is lower. People tout Elixir for its syntax being similar to other languages, but that's a detriment, not a benefit. Erlang and Elixir, both, require you thinking in a way most other languages don't. With Elixir, and the language looking familiar, you're tempted to try and shoehorn your existing knowledge, practices, etc, into an Elixir shaped package, and that leads to less idiomatic code, more surprises in how things actually work, and sometimes even more brittle applications than how they ~should~ be (though having a decent supervision tree means they'll probably still be better than what you'd have had in those other languages). Using Erlang, though, you relearn from scratch. It's a small language and that syntax isn't really a huge barrier; being forced to code in a language that shares so little with what you're experienced with means you're likely open to new paradigms, and will pick them up instead of trying to reuse your existing ones.

At least, that was my experience with Erlang, compared with Scala/Akka (which I tried first, and ended up with a lot of OO, non-functional, non-parallel code).

I don't really want to belabor the point of Go and generics; it's one of the many simplicity vs. expressiveness design choices that language designers have to make. But the claim that parametric polymorphism in a statically typed language is (presumably inherently) an awkward mess is a peculiar one, given that there are so many successful examples.

And just about every other language (Haskell very much included) was designed with generics from the start.

Haskell is not an exception, Java is.

[0] the C# team knew all along the language would have generics, but generics were not ready for 1.0 so they were pushed back to 2.0

There are better ways of accomplishing the same thing though, one way is the Either monad in Haskell. Here's an example I post sometimes comparing error handling in Go to Haskell's either monad:

    func failureExample()(*http.Response) {
        // 1st get, do nothing if success else print exception and exit
        response, err := http.Get("http://httpbin.org/status/200")
        if err != nil {
            fmt.Printf("%s", err)
            os.Exit(1)
        } else {
            defer response.Body.Close()
        }
    
        // 2nd get, do nothing if success else print exception and exit
        response2, err := http.Get("http://httpbin.org/status/200")
        if err != nil {
            fmt.Printf("%s", err)
            os.Exit(1)
        } else {
            defer response2.Body.Close()
        }
    
    
        // 3rd get, do nothing if success else print exception and exit
        response3, err := http.Get("http://httpbin.org/status/200")
        if err != nil {
            fmt.Printf("%s", err)
            os.Exit(1)
        } else {
            defer response3.Body.Close()
        }
    
    
        // 4th get, return response if success else print exception and exit
        response4, err := http.Get("http://httpbin.org/status/404")
        if err != nil {
            fmt.Printf("%s", err)
            os.Exit(1)
        } else {
            defer response4.Body.Close()
        }
    
        return response4
    }
    
    func main() {
        fmt.Println("A failure.")
        failure := failureExample();
        fmt.Println(failure);
    }

    failureExample :: IO (Either SomeException (Response LBS.ByteString))
    failureExample = try $ do
      get "http://www.httpbin.org/status/200"
      get "http://www.httpbin.org/status/200"
      get "http://www.httpbin.org/status/200"
      get "http://www.httpbin.org/status/404"
    
    main = failureExample >>= \case
      Right r -> putStrLn $ "The successful pages status was (spoiler: it's 200!): " ++ show (r ^. responseStatus)
      Left e -> putStrLn ("error: " ++ show e)

Why? Seems to me that it's precisely equivalent to Golang's error handling story (assuming you mean something like Result). In fact, it's a lot easier to handle errors individually that way, both because it tends to make it harder to use a return value without checking for errors and because its generic nature means that you can handle different errors differently without having to deal with interfaces.

If you mean that it's more typing to write "return err" and it forces you to think about it more, I don't really buy that. "return err" is 10 characters; "map" (e.g. in Haskell) is 3 and "try!()" is 6. I really doubt that the difference between 3 and 10 characters has any practical outcome. For Golang programmers, "return err" is muscle memory.

  import List(partition)

  qs [] = []
  qs (pivot:rest) = qs smaller ++ pivot : qs larger
      where (smaller,larger) = partition (< pivot) rest

NB: By "Groovy (the scripting version)" I mean the component of Groovy which was Beanshell with closures and collections syntax added, but before the meta-object protocol was. So Groovy as used by Gradle rather than Groovy as used by Grails.