As far as I know, there's no legal ebook of G.E.B.
I've this vague memory of hearing that the author regards it as a physical work of art; plus maybe the "ambigrams" were only licensed for the print edition, and the book won't be legally distributed without them.
Self-hosted means you own a computer and you install their software on it. Hosted means they own the computer and run their software on it, but they allow you to have an account and store your code there.
If you don't know what you want, you probably want hosted.
This is not what you asked, but if you’re looking to host a static website by pushing to Git in particular, you might be interested in Netlify. They’re essentially a build step + static host. If you like Github pages, this might be up your alley.
Designed to replace and address flaws of an older language but ends up being huge and unmaintainable, with very questionable design decisions and a tool chain that's simply not up to standards in the 21st century (slow compiler, poor IDE integration that keeps breaking version after version, etc...).
In C++, some of these design decisions were driven by legacy pressure but in Scala, a lot of design decisions were driven by the pressure on the team to write research papers. Either way, both languages end up being monsters that implement all known programming language features known on Earth.
Quite the opposite. Scala is a language designed around a very small core of very powerful, and sometimes hard-to-grasp features like implicits or higher-kinded types. It is a different language than Java and was not designed to replace Java or to be a better-Java.
Your C++ to C analogy doesn't hold, because C++ is an (almost) superset of C, while Scala is not a superset of Java at all. Modern C++ compiler can compile most of C code with at most minor, cosmetic changes.
As for the toolchain - I'm working in it daily and so far it has been great. Ok, compiler is not as fast as Java (point taken), but this doesn't matter as long as I can compile my code fast enough. IDE support is stellar compared to most other popular languages, particularly dynamic ones like Python or PHP.
It's not just too complex (we're talking more complex than C++ and Ada) but also poorly designed overall, with so many features that they interact with each other in ways that are pretty much unpredictable.
Odersky himself gave up on scalac and he's writing a compiler and a new language from scratch.
* C++ language specification: 1374 pages (and still includes plenty of "unspecified behavior" / "undefined behavior")
* Java language specification: 788 pages
* Scala language specification: 191 pages
> Odersky himself gave up on scalac and he's writing a compiler and a new language from scratch.
Odersky created a new language to be able to do research without sacrificing Scala stability, which is already mainstream and should not undergo any more major revolutions. So Dotty is for research / incubating language features, while Scala stays on the stable side of things, letting companies like Twitter or LinkedIn develop without fear that 2.13 will not compile their 2.12 code.
> also poorly designed overall
This is an opinion, not a fact.
> With so many features that they interact with each other in ways that are pretty much unpredictable.
Name three. I'm coding in it for several years, and didn't notice a single one issue. I heard this complaint about Scala being too hard a few times very long time ago (when Scala was at version 2.6, and its tooling was in fact terrible), but it was always from programmers, who had also major problems coding in Java, so I never treated this seriously.
As someone who loves typed functional programming and has used both Scala and Java, I oddly prefer Java; it's much easier to reason about. I find Scala almost impossible to make sense of due to the language's complexity.
That's really the main issue per the original question. It's not that functional somehow fails on its merits to deliver, it's just that "at scale" means having enough developers who know it. The reality is that imperative/OO languages have the greatest mindshare, and thus it's far easier to find developers, and far less wind-up time, if you're using such a language.
Also, there's enough different about Scala that can't be expressed on a simple OO vs FP axis that it's hard to learn that much from Scala vs Java. (On this axis)
Scala is very powerful. Too powerful.
There are too many ways to do the same thing and no idiomatic way. Some people also abuse Scala to create DSLs with horrific syntax that is very hard to comprehend.
I love and use Scala, but I can totally see why it can
be a hard language to use for collaboration.
That's an excellent question - especially given that you can essentially use it as a "functionally enhanced java" as it's not a hard-FP language like Haskell. I'd love to know - maybe it's a question of staffing? More skilled Java programmers around than Scala programmers probably. Also might be easier to work with lower level DB libraries and such, but I don't see why a company that large couldn't develop and maintain their own abstractions.
"especially given that you can essentially use it as a "functionally enhanced java" as it's not a hard-FP language like Haskell"
I'm not sure if I can call this "the Haskell community consensus", but a lot of the Haskell community finds Scala too complex to be worthwhile. They find it introduces a lot of complexity above and beyond Haskell, but at the same time, fails to take proper advantage of it and the result is quite dirty, full of special cases, and consequently hard to reason about. So you get a lot of the costs, perhaps even more costs for compliance than a Haskell code base, but you get fewer benefits.
So far the only real instance of a big company abandoning Scala has been Yammer, so this is a mistaken impression. LinkedIn and Twitter are heavily invested in Scala.
Not really, but there's certainly an off-by-one joke in there somewhere.
Since ES2015 the official nomenclature is ES<year>, to convey that a new version of the standard is cut yearly. While this may result in somewhat underwhelming releases, like ES2016, at least it's much easier to reason about and target than previously. Case in point, it took ten years or so to get from ES3 to ES5, and another five-six years I believe to get to ES2015.
These were substantial releases to be sure, but for a long time the uncertainty about when a spec draft was considered done was anything but fun, and I for one applaud the new nomenclature and process for being much, much easier to reason about and target.
We must stop using names like ES8 etc. right now, otherwise there'll be a lot of confusion in 4024 about which version of ES your customers' IE supports.
