Rebooting an EC2 instance never causes you to lose your data (no matter what type of storage you pick).
EC2 has two types of storage: local disk "ephemeral/instance storage" and network storage "EBS". Digital Ocean only provides local disk. In EC2 you can mix and match, but EBS is the most convenient.
If you do a stop and start on EC2 (very different to picking "reboot"). You will lose what's on local disk because stop/start is basically requested that you be moved to a different physical box. Data stored on EBS is not affected. On Digital Ocean if you "power off" you remain on the same host, but get billed at full rate whereas on EC2 you don't get billed for the time it's stopped. Rebooting on EC2 is the same as rebooting on DO.
If you use EBS for storing everything your data survives even if the hardware your instance is running on breaks. If the hardware breaks on Digital Ocean or on EC2 if you only use ephemeral (local) storage you lose your data. It's the same story on DO as it is on EC2. The only difference is that EC2 gives you the option of storage which can survive the physical box you are on dying (EBS).
> If the hardware breaks on Digital Ocean or on EC2 if you only use ephemeral (local) storage you lose your data.
Is that really the case - neither are using a SAN or RAID or other backup method to ensure data is preserved in (almost) all circumstances? Not so bothered about EC2 (due to EBS) but for Digital Ocean..? Poor show if that's the case.
A reboot doesn't cause you to lose data on your ephemeral storage. I think you mean "stopping" an instance and then "starting" it again (on another host), not rebooting it.
You are correct, that is what I meant, but I've taken to calling it 'rebooting' because all the intro-to-EC2 stuff I've seen listed their "how to reboot the instance" instructions as stopping and starting it, so I figured it's the appropriate vernacular, however incorrect it might otherwise be.
If you shut down your server you lose the data that was stored on the local drives, no different to DO. If you shut down your droplet on DO you lose the data stored on the local drives (in fact DO now scrubs the disks on shutdown after a recent security screw-up). The only difference is that most folk on AWS use EBS storage (something which DO still doesn't offer) which allows you to have drives which can continue to exist after your server is no more and allows you to attach more storage without getting a bigger server.
It's not rocket science:
instance = virtual server ("droplet" in DO speak)
terminate = shut down
ephemeral store = local disk
An EC2 instance is just a virtual server so anyone who knows Linux, Windows, BSD or even Solaris can "hit the ground running" there too.
When you say shutdown are talking about issuing commands from the command line like 'shutdown now' or 'reboot'? Because with Digital Ocean you DO NOT lose your data when you issue those commands. I know from experience.
Terminate in EC2 is basically the same as the Destroy call of DO. In both cases you will destroy the data stored locally. Rebooting an EC2 instance will not result in data loss, same as DO.
The post made the front page on HN a couple of months ago: https://news.ycombinator.com/item?id=7016735. DO staff seem to spend quite a bit of time responding to threads on HN in general, so that would be surprising.
> Also happened to be the guy who wrote the most Scala code on the planet
I love the way he assumes that. I think he may be surprised to learn the sheer scale of some production Scala systems which aren't part of the Scala class library or compiler.
Besides, he put together a list of obscure corner cases that no practicing Scala developer actually seems to care about.
I think the Paul Philips stuff is both overblown by people outside of the Scala community and dismissed too freely by those inside of it. Paul has a very pessimistic world view, a very high standard of perfection and he's spent tons of time in the guts of an extremely complicated system. Listening to some of his talks it is easy to make the assumption that he thinks Scala should be nuked from orbit.
On the other hand, while the ParSeqViewLike example is a bit of an inside joke (I think). It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour. I'm a practising Scala developer and I do it at least monthly. For people with experience with other better designed collections systems the Scala collections library feels heinous to use, and if you ever have to dig into the code, good luck.
If the Java stream api is implemented well and has a high take up rate, I expect lots of people to come to Paul's point of view with regards to the terribleness of the standard Scala library.
> It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour
I'm genuinely curious to see examples you've seen in production code. I've used the collections for years coding full-time and haven't encountered anything like that.
From MapLike.scala
def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }
From HashMap.scala
def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
That is to say that the default behaviour of a Scala hash map is to create a new object for every access (notice I say access, not for every insert) even when I ask it to pretty please give me the one that doesn't have the null safe Option code involved.
Doing an extra object allocation (which will likely be elided by escape analysis in the JVM) is hardly "weird and terrifying behaviour". It is an implementation detail which has absolutely no bearing on the behaviour or functionality of the map.
In my use cases escape analysis does not elide these accesses out (and I was unable to reason about why not). Further, I had an immutable map that had ~hundreds of items in it that was generating hundreds of millions of objects. I found that weird and terrifying especially given that I was specifically asking it not to give me Options back.
I frequently hear that memory/performance are "implementation" details and don't have bearing on functionality. For my use cases that isn't true.
Even if it was, the surprising upside down nature of that API (de reference the option, instead of wrap the reference) is of itself weird.
This is just the most terse example of oddities in the library I've encountered. Other's include streams being created (and not GC'd) when they weren't necessary, collections losing performance characteristics due to the monadic calls (IndexedSeq's passed into functions as Seq's use LinkedLists for builders instead of Vectors), etc.
Finally, I fundamentally disagree with the idea that eager evaluation should be the default in the collection library. Views mitigated this somewhat, but after working with more sane libraries, have to remember that every time is tedious (though I'll grant that is a debatable point).
If your software is not performance critical, or you aren't implementing your own collections libraries, maybe you don't encounter these problems. But for the standard library, it is a problem.
So to summarize the collections library has "weird and terrifying behaviour" because there are cases where the performance is not quite as good you expected?
Another way to summarize might be to say, "If you discount the many examples of incorrect behaviour that paulp mentions, and you don't care about performance, and you are comfortable enough looking through the extremely deep collections hierarchy code to diagnose the reasons for these problems, then the standard scala collections library is almost as good as collection libraries available in other languages".
The AnyRefMap may be a good solution to many of my issues with the default map implementation once it is widely available. It won't help with the more general lack of cohesion in the library though.
I encountered them on a daily basis when I was doing Scala, and you see these Scala collections WTFs pretty much on every other line when you are prototyping in the REPL. I've come to the conclusion that the only way the Scala collections library will give me confidence is when my head can reason more than 100 types at the same time while having distinct types for every value in the universe.
Scala's problems are real and structural. There's very little you can do about it now that all these innocent newcomers buying into the lies of the vested interests.
Speaking of lies, besides those Paul Phillips points out, you hear these nonsense about how great Scala's explicit type declarations are, that they make your function's signature clearer and etc. These are all lies, the truth is the type inference algorithm can't unify a type because of all these type variance, type bounds and type views. All these funny emoticon symbols are actually hints to tell the type inferencer to go up or down or sideways when looking for the most generic type that satisfies a type signature.
Another lie is that Odersky will keep showing you kiddy pictures and extolling how small Scala's grammar is while sweeping under the rug that Scala's many features are orthogonal, or halfway in-betweens GCDs or have surfaces of interaction with other features that are too large.
To list a few, these are my favorites:
1. implicits. Explicitness in function decl is good but when you call them it's better to hide all these unknown implicit params/type conversion from you so you can't reason your code.
2. _. There are 12 different ways you can use them. They are not shortcuts, they are conflation of concepts.
3. The interplay between classes, case classes and traits. It's very hard for me to put this one in word, there are just so many corner cases.
4. Java/Scala interop. There's no interop. There's only 1 way op from Scala to Java.
5. case classes are just ADTs. Nope, not letting me have a param-less case class or subclass a case class doesn't make them ADTs.
6. Companion objects are sold as singleton replacements. They are only singleton replacement as a side effect of having no other suitable place to put your implicit kludges.
7. Type safety. You can't guarantee type safety if you allow mutability. Period.
8. Java compat is simultaneously sold as an advantage and blamed when problems arise. Why can't Scala just use the damn bytecodes and avoid the entire Java standard lib?
It would actually be more convincing if it wouldn't sound exactly like the last dozen "I never used Scala, let's just point out some things I read on the internet about it" people.
Why not just try Scala for a while, instead of making things up?
> I encountered them on a daily basis when I was doing Scala.
Your assumption that my criticism over Scala is because I hadn't tried it is as valid as my assumption of your disagreement with me is because you haven't tried hard enough.
I had tried Scala on multiple occasions since 2.8 came out. Every time for about 1 month to 5 months. It's impossible to explain how messed up Scala is without writing a whole book about it so I admit it's hard for me to convince you. God I miss SML and Haskell.
I wouldn't bother. I'd just go ahead and use 2 distinct APIs directly, and then after a while, I'll realize my code look more and more Javaish, and then I'll switch back to Java.
It made perfect sense to me, perhaps because I code in Scala for a living (even though I don't use either Akka or Play (yet)). It reminds me of the old comment about how unreadable French is because it looks nothing like English.
I don't think the target audience of the blog post was experienced Scala developers (that would just be preaching to the choir!) so the use of unexplained jargon should be kept at minimum to actually reach the audience.
EC2 has two types of storage: local disk "ephemeral/instance storage" and network storage "EBS". Digital Ocean only provides local disk. In EC2 you can mix and match, but EBS is the most convenient.
If you do a stop and start on EC2 (very different to picking "reboot"). You will lose what's on local disk because stop/start is basically requested that you be moved to a different physical box. Data stored on EBS is not affected. On Digital Ocean if you "power off" you remain on the same host, but get billed at full rate whereas on EC2 you don't get billed for the time it's stopped. Rebooting on EC2 is the same as rebooting on DO.
If you use EBS for storing everything your data survives even if the hardware your instance is running on breaks. If the hardware breaks on Digital Ocean or on EC2 if you only use ephemeral (local) storage you lose your data. It's the same story on DO as it is on EC2. The only difference is that EC2 gives you the option of storage which can survive the physical box you are on dying (EBS).