> folks coming from Python and Ruby, looking for something that has better perf and concurrency
Long-time Ruby developer here, relunctant Go developer. Absolutely.
I want performance, concurrency, efficient memory usage, and static typing. Ruby is lacking in all these areas. Go is mildly better, but is regressive in many other respects.
For me, Go is a step back in terms of productivity, but a step forward in creating stable, fault-tolerant code. It's a compromise. Go feels like a stopgap solution until something better comes along.
For example, I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Go doesn't support that style, not really. Go promotes simplicity, but a lot of stuff that should be simple in Go isn't "simple". Like mapping and reducing an array.
What's interesting is that working in Go reminds me a lot of using Borland's ObjectPascal back in the mid-1990s: A small, natively compiled (and super fast to compile), not-functional language with built-in reflection and a stupidly strict, cumbersome type system. Go makes very few innovations over ObjectPascal, and inherits many of its problems; Go's notorious lack of generics, for example, caused exactly the same issues back then. And nobody should be surprised about that.
Currently, the language that looks closest to my ideal is Nimrod. Unfortuantely, it has almost zero mind share, and has a surprising amount of odd, off-putting warts for such a young language (perhaps not too surprising when you realize that for many years it was just one guy hacking away at it, TempleOS-style), disappointing since many design choices just feel just right, like someone has read my mind. Currently I'm on the fence with Nimrod. Jonathan Blow's jai also looks promising.
Since you mentioned having experience with Ruby, have you looked at Crystal as a statically-typed alternative with a deliberate Ruby influence? From what I've seen of it so far it may fit your purpose precisely.
One consistent, niggling problem with all of these languages is that they are still obscure compared to everything else, with all that this entails: It's harder to find developers who already know the languages well enough to be true masters, let alone find juniors who are interested and capable of picking them up; the languages are often complicated and unfriendly, so junior developers will again struggle.
Something I've learned the last few years is that while having only wizards on your team is great, it's useful to have access to a less advanced contingent of developers who can still contribute productively.
In the end, if you buy into something that not every shop uses, there will be a lot of sunk cost into having brought everyone into the fold, and you end up being an "OCaml shop" or "Haskell shop" or whatever. Productivity will probably normalize, but I'm not sure I want to go down that route.
OCaml looks to me like the most promising functional language with the fewest warts, the most pragmatic approach to real-world apps, and possibly the best performance. But it's not a simple language, with a learning curve that's similar to Haskell. I also have to say that like Erlang, the toolset and syntax occasionally feels antiquated (for example, there's no excuse not to provide a modern readline-enabled REPL). OCaml still is not good at concurrency.
Scala has some good parts, but is overdesigned and way too complex, in my opinion. Last I checked, performance was worse Java. It also runs on the JVM, which means its memory usage is inherently inefficient.
F# is a language that I like a lot; in some ways it looks like a more pragmatic Haskell, or Ocaml with a cleaner syntax. I don't like the fact that it's tied to .NET, which (like Java) means it inherits all the issues from that platform. The performance on Mono looks unsatisfying.
Haskell is also a language I like a lot — at least in theory. I've been disappointed with performance and memory usage (and the ability to reason about those things). The tools for concurrency (and OTP-type distributed networking) also seem very much lacking. Whenever I see an example of parallel async code in Haskell, I feel like I'm reading an advanced physics paper. While I like and understand the approach to purity, I feel like the tools get in the way of programming; that I have to work at getting in and out of effectful code just so that I can stay pure, and for what reason? Bugs caused by side effects is something I encounter only a few times a year, if that; Haskell builds a huge wall to solve something that isn't a problem for me. Nor do I enjoy that laziness is the default. Finally, there are parts of the language that seem immature; the well-known data record namespacing issue (being fixed?), and the sheer awkwardness that comes with trying to implement certain things (like polymorphic collections and directed graphs) that should be simple, but aren't. Still, it's a beautiful language, but not one I would use for everything.
Clojure is the JVM, again. It's also not statically typed. From everything I've seen, performance is worse than Java.
Using a language that isn't already in every shop may limit hiring at first glance, but it will automatically select for folks who have an important sense of craft for the work they do and pay close attention to where there is a lack of return on investment in languages, platforms and applications. People who really care about FP will likely be easier to retain than those who use Blub and couldn't care less. Go is shiny right now. What will be shiny later? Lisp is not shiny but it is power like power has never known with Blub.
Aside: I've not found Clojure to be slower than Java and I've benched it. It is fast, fast, fast. As fast as Go even doing the concurrent thing: benched that too. I've even found that Clojure can edge out Java in many cases because of its inherent laziness: the fastest way to expedite a job is not to have to do it in the first place.
With OCaml, that depends what you mean by concurrency. There's good async IO, but the runtime is still single threaded (just like Node!). The overall library ecosystem is a disappointing though.
And it is a huge shame F# doesn't work well cross platform. Hopefully we'll see the runtime ported soon. Looks like it builds, but the tests are probably a mess:
Hopefully one day a big company will build us a modern language with a vibrant ecosystem. Microsoft has come the closest with F#. Rust is tentatively exciting, but who knows if Mozilla has the muscle to get it adopted.
Yes, I was referring to OCaml's single-core limitation. I was under the impression that some smart people working right now on removing the global lock, though?
Long-time Ruby developer here, relunctant Go developer. Absolutely.
I want performance, concurrency, efficient memory usage, and static typing. Ruby is lacking in all these areas. Go is mildly better, but is regressive in many other respects.
For me, Go is a step back in terms of productivity, but a step forward in creating stable, fault-tolerant code. It's a compromise. Go feels like a stopgap solution until something better comes along.
For example, I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Go doesn't support that style, not really. Go promotes simplicity, but a lot of stuff that should be simple in Go isn't "simple". Like mapping and reducing an array.
What's interesting is that working in Go reminds me a lot of using Borland's ObjectPascal back in the mid-1990s: A small, natively compiled (and super fast to compile), not-functional language with built-in reflection and a stupidly strict, cumbersome type system. Go makes very few innovations over ObjectPascal, and inherits many of its problems; Go's notorious lack of generics, for example, caused exactly the same issues back then. And nobody should be surprised about that.
Currently, the language that looks closest to my ideal is Nimrod. Unfortuantely, it has almost zero mind share, and has a surprising amount of odd, off-putting warts for such a young language (perhaps not too surprising when you realize that for many years it was just one guy hacking away at it, TempleOS-style), disappointing since many design choices just feel just right, like someone has read my mind. Currently I'm on the fence with Nimrod. Jonathan Blow's jai also looks promising.