It was specifically design to disallow smart-asses to write ninja-code, so no. Go is for monkey programmer factories which managers want to make sure they will only code a certain way because Go doesn't give the developer choices. It's the anti C++,scala,python,clojure... Go tells you to do this that way, and doesn't give you the constructs or features to make your own choice about coding.
Go would probably be the opposite of this, and I would argue that is a good thing. Hiring "smarter" people by picking a more esoteric language is likely to result in you having an esoteric or "clever" code base. That's just going to cost you in terms of maintenance in the long term, and it's not a requirement for productivity. You should be able to hire good people without this kind of filter, and use the tools that best fit your domain. That may or may not be Go, but at least it emphasizes consistency, simplicity, and readability, which is basically the opposite of what you get out of Scala.
I'd argue Scala emphasizes both simplicity and readability. Simplicity in the "simple, not easy" sense. I will grant that the language had a reputation for operator soup, due to many library authors being enamored with them. But I think this has long since fallen out of favor.
In Scala, you basically have to learn the constructs and their semantics. No way around that. But once you do, almost everything is just various compositions. For the most part, it's very predictable. The execution model is ultimately pretty simple.
Consistency -- I'll give you that. There are a lot of options for how to structure your code. And when you start composing libraries together, you have to be able to understand the paradigms the authors use.
Yeah. Seeing some Scala Build Tool stuff a while back really turned me off. Me: ooooh, look at all that overloaded operator stuff! Scala guy: those aren't overloaded operators, they are just function calls with funny names and optional parentheses. Me: it just gets better and better :-(
Operator stew, whether Scala or C/++, REALLY makes me appreciate the Lisp style of function calling. "Evaluate inner parentheses first. There is no step 2." Now you're trained in "operator" precedence, which, by the way, I have seen responsible for far more costly errors than runtime types. (I'm putting C's lack of any real type checking at all in a different level of problem - sometimes useful for systems stuff, but foolish for general biz apps)
I would say OCaml particularly with a potential killer app of MirageOs.
Stat usage wise it makes Haskell look mainstream... but serious real world code is written in OCaml (I would argue maybe even more serious than Haskell :P ).
The users of OCaml almost always know how to parse really hard things to parse which is a pretty descent filter.
The missing link in MirageOS is a BEAM-style distributed computing framework. If this were available, I'd be using Ocaml/Mirage almost exclusively. Imagine the beauty of supervisable, millisecond demand-scalable, ultra-lean, Ocaml-safe microkernels all messaging each other atomically and cross-node, without the dev having to build it from scratch.
Go is pretty much mainstream by now, I don't think it's a stronger filter than say python. Depending on subject area, I'd look at clojure, ocaml, haskell, lua, or rust.
I was considering mentioning erlang, but you probably don't want to write erlang. I've never touched elixir, but I would likely try it if I hit a problem that I would use erlang for in the olde days.
I think we live in different times now. Ecosystem matters much more. There are certain languages with features that I love (haskell's state isolation looks lovely, for instance), but I'm not willing to make the jump because the Haskell ecosystem isn't there and might not ever be there.
This mattered much less in the past as ecosystems were much smaller and people tended to build software much more from the ground up.
That said, I think it applies within ecosystems still. Scala programmers get to choose a better language without abandoning the Java ecosystem. F# programmers get to choose a better language without abandoning the C# ecosystem. The "paradox" is evident there.
Go is definitely not that language (generics? lack of package management for years? c'mon). Rust, maybe (for systems programmers).
Elixir is great in the sense of attracting people who are interested in functional programming, distributed systems, and scalability, but aren't willing to give up pragmatism/productivity/readability in exchange. In my experience, these are the best kinds of people to work with. Cs theory + get shit done = good engineering.
The only problem, in my opinion, is the lack of explicit types. From what I can see, the compiler provides some safety that doesn't exist in typical scripting languages. But I think we're pretty much at a point where so many of the commonly used scripting language idioms can be effectively described in a type system. TypeScript proves this. But it also proves that's it's still pretty difficult to add types to a programming language ecosystem after the fact, so it feels like that ship has likely sailed for Elixir.
> Note that Erlang/Elixir programmers don't care about most runtime errors as we use Supervisors to restart processes that may crash because of them.
That doesn't give me a whole lot of comfort. A program that handles crashes gracefully doesn't fix its own mistake. Supervision is great, but it's even better to not have the crash in the first place.
I would argue that enforcing, or at least favoring, immutability and the ability to trace data flow is more helpful that static types. You could have both, but I know which one I would rather give up first. (actually, in the best of all worlds, I would want optional [compile time] types as well as type inference)
Happy to report that I'm one of those people! I like how Elixir keeps itself very practical, but at the same time lets you extend it however you want if you feel something is missing in your project. For example, you'll never find monads in the standard library but people have made their own monads through macros.
So, you're saying that, by choosing other functional programming languages, I'm giving up pragmatism/productivity/readability? Can you give me an example of such languages?
What that person means is that Elixir is a "practical" functional programming language. Of course, that's because Erlang is too.
Note that "practical" functional programming is something I just made up, but in general to me it means a language that provides immutable data, first class functions/higher order functions, and provides ways to minimize side effects. Elixir/Erlang do these. The language is geared towards functional programming, but it's impure.
But compare it to Haskell, a "pure" language: Elixir has no strong types, monads/functors/burritos, you can do side effects whenever you want with no penalty, there aren't many restrictions or things the compiler will yell you at about that aren't obvious mistakes.
I'm not saying either choice is better, but the average developer with little experience in both Elixir and Haskell can probably build a product faster in the former.
It was specifically design to disallow smart-asses to write ninja-code, so no. Go is for monkey programmer factories which managers want to make sure they will only code a certain way because Go doesn't give the developer choices. It's the anti C++,scala,python,clojure... Go tells you to do this that way, and doesn't give you the constructs or features to make your own choice about coding.