4 ms·

I'm curious to know what you think of Go in general as well as Go vs Erlang.

rebeccaskinner 10y ago
Go vs. Erlang feels like a pretty difficult comparison to make because they feel entirely different. Erlang isn't a bad language, but it never felt like more than a very flexible DSL to me. If you look at OTP with a critical eye, it's actually not much more than a lot of tooling on top of a state monad; and my limited experience with using the language professional makes me feel like you're buying a lot of code complexity and you need a very strong group of people with a lot of erlang experience to make that complexity pay off. Some of the process management and hot code updates and such that used to be really beneficial are less beneficial now that we have so many other solutions to managing containers and microservices, and the language itself, while functional, never really felt to me like it was achieving the power and expressiveness of other functional languages I've used. A lot of that seems cultural; I wrote a little toy monadic library in Erlang when I was trying to help teach some coworkers about ideas from other functional languages and how we could use them in our codebase (https://github.com/rebeccaskinner/erl_m https://github.com/rebeccaskinner/erl_m) but I don't see a lot of libraries like that coming out of the wider Erlang community- there seems to be a much stronger focus on solving a single concrete problem than on making development in the language better overall. As for Go, I do like the language- well enough that I took another job where I'll be mostly using it. I can't quite shake the feeling that some of the syntactical and stylistic choices were made more to be different than because they are better, but I can move past them. I think goroutines and channels have a lot of potential as atoms of concurrency for building models going forward, and I think it's nice to see a language gaining popularity that is focused on being small (in the sense of the size of the spec) and simple (in terms of feature interactions). I don't think a lot of it's potential has been realized yet, and I hope that we can take some of the lessons learned from other languages, e.g. Conduits and FRP from Haskell. For right now I've seen enough cases of people introducing threading errors and problems introduced by the user of pointers that I think it pays to be wary of third party libraries.

Go vs. Erlang feels like a pretty difficult comparison to make because they feel entirely different. Erlang isn't a bad language, but it never felt like more than a very flexible DSL to me. If you look at OTP with a critical eye, it's actually not much more than a lot of tooling on top of a state monad; and my limited experience with using the language professional makes me feel like you're buying a lot of code complexity and you need a very strong group of people with a lot of erlang experience to make that complexity pay off. Some of the process management and hot code updates and such that used to be really beneficial are less beneficial now that we have so many other solutions to managing containers and microservices, and the language itself, while functional, never really felt to me like it was achieving the power and expressiveness of other functional languages I've used. A lot of that seems cultural; I wrote a little toy monadic library in Erlang when I was trying to help teach some coworkers about ideas from other functional languages and how we could use them in our codebase (https://github.com/rebeccaskinner/erl_m https://github.com/rebeccaskinner/erl_m) but I don't see a lot of libraries like that coming out of the wider Erlang community- there seems to be a much stronger focus on solving a single concrete problem than on making development in the language better overall. As for Go, I do like the language- well enough that I took another job where I'll be mostly using it. I can't quite shake the feeling that some of the syntactical and stylistic choices were made more to be different than because they are better, but I can move past them. I think goroutines and channels have a lot of potential as atoms of concurrency for building models going forward, and I think it's nice to see a language gaining popularity that is focused on being small (in the sense of the size of the spec) and simple (in terms of feature interactions). I don't think a lot of it's potential has been realized yet, and I hope that we can take some of the lessons learned from other languages, e.g. Conduits and FRP from Haskell. For right now I've seen enough cases of people introducing threading errors and problems introduced by the user of pointers that I think it pays to be wary of third party libraries.