I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory footprint.
But, I don't know of one, and maybe that's because the Go team is right, some tradeoffs need to be made, and they did, and so Go is what it is. You can't add all the other great features you want and eat the Go cake too.
Disclaimer: I'm no language design expert. Just thinking this from the fact that I've yet to hear of such a language.
Honestly, no. For starters, I don't want a functional language (at least not a purely functional one). Purely functional programming has some distinct downsides. My preferences are firmly on the multiparadigm side, and I'm perfectly happy with a reasonable imperative language (that still supports higher-order functions and closures).
What I'm not happy with is language designers seemingly ignoring the state of the art even when it comes to picking low-hanging fruit.
First, I'm not looking for a language. Programming languages are part of my field. I was making an observation rather than expressing a need. If there's a language that's not totally obscure or esoteric, I've probably written some serious code in it at some time.
Second, I know and use Scala (among other languages) and have done so since the 1.x versions, but the JVM dependency is too often a problem (and Scala Native is not yet mature).
Multicore OCaml is in the works and is looking amazing, but is indeed a ways away. They're taking their time and doing it properly so things are fast and safe.
The thing is, until it's shipped, it's still vaporware for most people, especially if they want to use it in a commercial setting.
KDE 4 was released in 2008 and it was supposed to be ported to Windows. We're in 2017 and KDE 5 is still far from being considered stable on Windows. And I'm sure you can also think of many examples of programs promised and never delivered or underdelivered.
It was ported to Windows. I cannot check the remarks about stability because I use Linux, but it sounds plausible. There's only a handful (maybe 2 or 3) developers working on Windows support in their spare-time AFAIK. I would guess that KDE had anticipated more Windows developers joining the project as it progressed towards maturity.
That's always the problem with open-source projects: It's very hard to do planning and forecasting with a bunch of volunteers. Even if they commit to a roadmap, there will always be someone who has to step down because of private issues (new job, new child, etc.). Go is in a much better position since Google has headcount assigned to it (again, AFAIK).
It isn't a great concurrency story, but the shortcomings are also overstated. OCaml does message-passing concurrency just fine and allows for shared memory for arrays and matrices of scalars, which is good enough for most scenarios.
(Technically, there's also Ocamlnet's multicore library, but that's too low-level for most people.)
F# is pretty good there, especially if one uses a library like Hopac. However I think it's still not on the level of Go, since concurrent operations are represented through monadic types (like Job<T>), and so everything has one level of indirection. F# workflow builders ("do notation") makes that somewhat more bearable, but I still think it's harder to work with than just using normal function calls on normal lightweight threads, like available in Go.
it's a bummer that the windows story for ocaml is so sketchy. i'd like to use it for work (various utilities and whatnot) but the ecosystem seems to make a lot of assumptions about the system it runs on. (for me there's still haskell and rust at least.)
Has algebraic data types (however variants can't have generic parameters not present on the data type itself, but you can use trait objects to do that).
Functions that don't take &mut parameters, & parameters with types with interior mutability and don't call functions that do I/O are pure (although they may not terminate and may abort).
> optional lazy constructs
"Automatic" lazy costructs are usually unnecessary and thus almost never used, but can be implemented as a library using macros.
Can also just use closures and call them explicitly.
> great polymorphism
Has trait/typeclass polymorphism with either monomorphization or dynamic dispatch.
Structures can't be inherited, but composition gives equivalent results and is the proper way to do it.
There have been several proposals for inheriting structures though, so maybe it will be available at some point, despite not being advisable.
> statically typed with inference
Yep.
> generics
Yup.
Not higher kinded, no constant integer parameters and not variadic yet, but those features should be available in the future.
> great concurrency story
Rust is the only popular language supporting safe concurrency without giving up the ability to share memory between threads.
> an efficient GC
It turns out that a GC is unnecessary, and that reference counting is enough, which is what Rust provides (although it's still relatively rarely used).
If you insist on a tracing GC, there are/have been several attempts to add it, and maybe there will be a mature one in the future.
In particular, there is a "rust-gc" crate, and Servo has a working integration with the SpiderMonkey GC, which I suppose should be possible for others to use with some work.
> compiles quickly
Work in progress (incremental compilation, more parallelization).
> self contained binaries
Yes (or optionally using shared libraries).
> simple and effective tooling which takes only seconds to setup
rustup can install the compiler and package manager in one line.
If you want an IDE, you'll have to install that too separately. Work in progress on improving IDE functionality and ease of use.
> giving you perfomance that equals java and can rival C
Performance is at least theoretically the same as C since the generated assembly code is conceptually the same (other than array bounds checking, which can be opted out from with unsafe code).
As my sibling commentor says, they're the default. There are some details though:
Rust uses glibc by default, which must be dynamically linked. It's usually the only thing that's dynamic about Rust binaries, but it does mean that compiling on on old CentOS box is a decent idea if you want a wide range of compatibility.
Alternatively, you can use MUSL, which works like this:
The default is that all Rust code is statically linked, but since you may link C code as well, that may or may not be statically linked. It's done by packages, so there's no real default. Many of them default to static and provide the option of dynamic.
That's why there's not really a guide, that's really all there is to it.
They're the default, even when you include 100+ packages via Cargo. The only issue I've faced is standard Linux cross-distro issues due to libc versions. Even most of the crates that handle bindings to C libraries link them statically by default.
But, I don't know of one, and maybe that's because the Go team is right, some tradeoffs need to be made, and they did, and so Go is what it is. You can't add all the other great features you want and eat the Go cake too.
Disclaimer: I'm no language design expert. Just thinking this from the fact that I've yet to hear of such a language.