Looks to me like whatever Github authorizing is being sent back to an insecure non-https site. If a passive observer were to see this in transit, I think they could probably steal the authorization token a la Firesheep.
The FAQ says "you temporarily grant us access to your public repositories", so I'm thinking this probably means your Github repos become writable to an attacker.
- The first-class modules chapter is incomplete, pending some portability
improvements to the ocaml-plugins Core library.
- The binary serialization chapter is also incomplete, but has just enough
to teach you about the Async RPC library.
- The installation chapter will be revised in anticipation of the OCaml 4.1
release, and is currently quite source-based.
- The packaging and build systems chapter hasn't been started yet. We're
still deciding whether or not to make this an online pointer rather than
a print chapter, since it's likely to change quite fast.
- We are preparing exercises per chapter that are not included in this
particular beta release, but will be available online as soon as possible.
- The code examples will all be clonable as a separate repository in beta2."
If you are surprised about the access requests when authenticating on GitHub. It seems like they couldn't ask for less than "all your public repos".
(as amirmc mentioned, check out the FAQ : http://www.realworldocaml.org/#faq)
Yeah, that seems odd to people the first time. The experience is pretty nice though, since you get all the good stuff from the GitHub issue tracker when you join/create a thread (e.g. dealing with follow-ups by email).
Mercifully not. They want to get authorization to post under your name in one single public comments repository (so that when you comment it's all managed by them in their repository). But Github OAuth (they claim) doesn't have that level of fine grained permissions - they can only request permission to post to all repositories in your name.
I've loved using OCaml on some toy problems. OCaml (and so probably F#) feel suitable for anything you'd use Golang for (performance is similar; code can be terser due to typing-saving language features), except if you must have threads for concurrency.
Are other forms of concurrency still available? This has always seemed like a strange limitation. Most of the code that I write doesn't require me to spin up tons of threads (at least, not in my code), but sometimes it's really helpful to have them.
I haven't actually used it so I have no idea if it's ready for "real" use (whatever that means! everyone has a different definition) However, it's under active development which is more than you can say for ML. I only found it when I saw the above comment and thought "I wonder if there is an ML for the JVM" but I have put it on my own todo list to check it out.
And I know the pain of which you speak pjmlp, I have to use PHP for my day job...
Yes. Scala is a great language, but it devolves into line noise so quickly. ML's relative lack of brackets is so nice, and so is the automatic currying of multi-argument functions. I also really love discriminated unions, and it's really hard to simulate them in Scala.
The Dispatch periodic table is probably a discredited meme by now, but it's all too representative of many scala libraries. Akka uses ! and ? for its two most important methods (and a pet moan: the experimental typed channel proposal uses :+: for type-level lists despite their being functionally the same as shapeless' :: HList). Shapeless constraints can't even be typed on a normal keyboard - they're things like ->[A]#λ or <<:[B]#λ (real examples from my day job). Scalaz is only slightly better (pulling up a random example I see "@@" used as an operator). Sometimes these sigil operators have non-sigil aliases but that's the perl trap of "there is more than one way to do it" - one can't just ignore the sigils because one has to read code as well as write it (and given that even quite major libraries like scalaz come with no scaladoc, one is often forced to read someone else's code to figure out what a function does).
I love scala, but I do find myself wishing method names were required to be alphanumeric.
Documentation for the Jane Street's Core Library looks incomplete or damaged (E.g. Core.Core_list module https://ocaml.janestreet.com/ocaml-core/latest/doc/core/Core...). I think, this is very unfortunate, because the labrary is probably great. I have not tried it yet (I'm pretty happy using just the standard one most of the time), but I whould like to have Async, Sexplib and other new things from Jane Street. Is there a better documentation for this lib?
The documentation generation tools are a bit of a mess at the moment. We're working actively with OCaml Labs to improve the tools here, and we expect to have the documentation in a much cleaner and easier to use state (and prettier) by publication time.
When we're out of beta, we'll open the book up for people to read without any kind of login. For now, though, we're putting this out there largely to get feedback before publication. Unfortunately, github has fairly coarse-grained permissions, so we need to ask for rather a lot.
This book is one route in. It's intended for those who've programmed before but not necessarily with functional languages. I suspect intros to any of the functional languages would be fine (e.g Haskell, Scala, F#). There's even a Coursera course on Scala.