Perhaps it worked better on your browser, but the content was so delayed that many times I scrolled past it before it decided to load. So I was constantly having to scroll back and forth to try to figure out whether a blank spot was truly blank (sometimes it was). Pretty frustrating. And the irony is almost too much...
A large project? I'm not sure what's particularly large about this. Perhaps it should be "how I organize a project I'm going to have running on a server at some point"?
The thing is, with current tooling, the current design means that I can write a function, type a key combination, and have the type signature printed in a buffer (where I can then copy it into place). And until I do that, there is warning highlighting on the function.
Now in some ways this may seem silly - are you really going to understand code without understanding types? But especially for people new to the language, _or_ when you're dealing with new libraries (if you've ever written a little wrapper around a function from a complicated library, you know what I mean), it's nice to choose whether you want to work from values or from types (where undefined is your friend).
Which isn't to say that think rust's decision is bad, just that having flexibility makes this kind of tooling easier (and I'm assuming here that in all cases, the end result will be all annotated top level functions). And, part of rust's choice was probably to make type checking easier, which is an important thing (especially given how sophisticated the borrow checker is).
The issue is that platform packages are in the global package database, which doesn't play well with the (amazingly useful) sandboxing that cabal provides. And may cause other problems too.
How can they mention Ceylon, Eiffel, Kotlin, and PPL (the latter two I've never heard of, and I've heard of a lot of programming languages) and not mention Haskell, ML, OCaml, etc? It's been mentioned in other comments, but essentially all of the supposed downsides of the Optional solution are implementation weaknesses in either the type system (allowing null anywhere, regardless of type) or runtime (there being overhead of Options) - which seems like a pretty weak argument for loving null.
I think that, having used both of them, Rust is going to feel a lot lower level than OCaml. The single biggest thing is that it's pretty hard (slash near impossible) to write Rust code without thinking about memory allocation, which adds non-trivial mental overhead to the work. That isn't to put down Rust - I think they are the first language that actually has a static, type-checkable story about memory allocation, and that's phenomenal, _but_, the reason for this is to be able to write soft-realtime code (for example, browser engines, games, etc). Web code, at least in the early stages, probably usually has lower performance requirements, and most people would probably trade some performance (and I don't mean to say that OCaml is slow, anymore than Go is slow, etc) for not having to even think about that stuff.
Also, unless things have changed significantly in the past year or so (since I've last really used Rust), there are significant differences between Rust traits and Haskell type classes. You can have collections of heterogeneous types that all share the same trait, which is not true with type classes. Most descriptions I've seen say that they are more of a hybrid of Java interfaces and Haskell type classes.
It is really bizarre to contrast Real World OCaml to Learn You a Haskell. The former is a serious book, the latter is a very beginner level tutorial. Now there may be real criticisms comparing Real World OCaml to Real World Haskell (which, if from the names alone, would seem like a much more appropriate comparison), but saying "this beginner tutorial doesn't explain how the runtime works" is a little silly.
I think it's a little bit of both. Yes, Haskell code is often quite terse, but the more important thing is that the type system allows abstraction to a much higher degree than in languages with weaker type systems. Abstraction always takes skill, but in Haskell usually once you come up with the abstractions, the type system allows you to (pretty easily and) safely use them.
They said they archived 10TB (and that covered everything with at least 10 views), and that the total including all videos would be 1.1PB, ie 1100 TB. So there is over 1000TB of videos with less than 10 views.
The problem is that often while regular users are not directly using those features, they are using libraries that do use them. As a concrete example, people writing webapps with Django probably (often) aren't using some of the crazier class metaprogramming, but they are using Django's models, which use lots of it.
This still has a flaw that it makes low wage jobs pretty unappealing. Why work fulltime for 50k a year when you can make 40k without working? Or even worse, who would ever work fulltime for 40k a year? Perhaps this means that there won't be low wage jobs, but this seems somewhat odd, as the taxation structure would be strange (need to tax enough for basic income, but companies would need to be paying probably 60k or greater on any job just to get someone to fill it).
Better to give a guaranteed income to everyone, and then let wages get as low as they want. The upside is that it changes the incentives so that work that is necessary (but undesirable) becomes more highly compensated, whereas work that is desirable becomes less compensated (and/or working for free becomes something that isn't just the domain of the wealthy).
That's a glaring error of selection. Because with basic income, the idea of removing the minimum wage makes complete sense. Without it, what he says sounds completely insane.
Take a look at the urls and do some calculation on how likely you are to actually get anything. It looks like 14 characters, alphanumeric with uppercase, which is about 10^25. Even if you can try a thousand urls per second, that would take you about 10^16 days to go through them all (that's a long time).
Or, if you want to calculate probabilities, assume that a billion urls are used (this is an astronomic overestimate). That's 10^9 urls. The chance of hitting one of those with a random guess is 0.00000000000014% (if I counted the 0s right). Not very likely.
Now if the url is observed in transit - that's a completely different thing. Just don't think that random guessing is going to reveal this. It's similar to people thinking you can guess your way to product keys for software (hint: you can't).
Obviously there are some differences, but type classes are pretty similar to the way python normally works - type classes specify methods that a type has to have. So in the case of 'print', the type specifies that print can be called on anything that implements the method that turns a value into a string. The neat thing, of course, is that if you try to call it on something that doesn't implement that method, you get a compile error (and with proper tooling, I actually see red squiggles in my editor if I make this mistake, which is about as good as it can get).
And then anyone who doesn't have extra resources is prevented from using your service... As if it is a trivial amount, spammers will pay it, and if it is non-trivial, then some people won't be able to afford it. Doesn't seem like a great idea.
Umm. Just leaving this here for anyone who doesn't know - the whole point of hashing things like emails or passwords is that reversing the hash is very difficult (read: near impossible). Indeed, once it becomes feasible to do, the hash is no longer considered useful (for this purpose).
So no, given a hash you can't get the email easily. If this were the case, there would be no point in hashing passwords - might as well store them as plain text.
They've always said they are aiming to target cheaper less powerful phones. Right now the bulk of the world is using cheap phones probably running Symbian or something similar. Whether they actually will be able to target that group is up for debate, but that's been their (stated) plan.
Just as a side note, the over $25 shipping is the slowest they can find. So if it is all books, it is media mail (which is _really_ slow), and otherwise it is whatever the slowest that UPS does (3-5 days), vs two day shipping on everything.