On SQS - <AUTHOR> https://www.tbray.org/ongoing/When/201x/2019/05/26/SQS <comment><USER3> I've worked with SQS at volumes in thousands of messages per second with varied (non-tiny) payload sizes.

SQS is a very simple service, which makes it fairly reliable, though part of the reason for the reliability is that the API's guarantees are weak. And it can be economical, but I've had to build a lot of non-trivial logic in order to interact with SQS robustly, performantly, and efficiently, especially around using the {Send,Receive,Delete}MessageBatch operations to reduce costs.

With the caveat that I think my use case has been quite different from what's discussed in this article, here are some of the problems I've encountered:

\- Message sizes are limited, but in a convoluted way: SendMessageBatch has a 256KiB limit on the _request_ size. Message values have a limited character set allowed, so you need to base64-encode any binary data. This also means that there's not exactly a max message size; you can batch up to 10 messages per SendMessageBatch but not in excess of 256KiB for the whole request.

\- If you want to send more than 256KiBx3/4-(some padding) or around 180KiB of data for any single message, you need to put that data somewhere else and pass a pointer to it in the actual SQS message.

\- SQS does routinely have temporary (edit: _partial_ ) failures that generally last for a few hours at a time. ReceiveMessageBatch may return no messages (or less than the max of 10) even if the queue has millions of messages waiting to be delivered; SQS knows it has them somewhere but it can't find them when you ask. And DeleteMessageBatch may fail for _some_ of the messages passed while succeeding for others; it will sometimes fail repeatedly to delete _those_ messages for an extended period.

\- The SDKs provided by AWS (for either Java or Go) don't help you handle any of these things well; they just provide a window into the SQS API, and leave it to the user to figure all the details out.

<comment><USER4> Um, I've been at AWS since late 2014, and AFAIK the only extended SQS hiccup correlated with the DynamoDB issue in 2016. SQS isn't perfect but I'm pretty sure "does routinely have temporary failures that generally last for a few ours at a time" is just wrong.

<comment><USER5> I believe GP was talking about particular messages failing, not a total system outage. In my use of AWS, the status page almost never reports an outage even though that AWS service is down for me-as in the most I've ever seen is some hand wavey message that there's elevated error rates. So you could be right, SQS hasn't failed entirely, but that probably means there's a good number of failed requests that are below the margin where AWS would consider it down.

<comment><USER3> Yes, this is correct, thank you. I updated my comment to indicate that I meant partial failure, though the failure conditions persist from 20 minutes to a few hours. Those partial failures have happened once every two months or so in my experience.

Technically, it's not even really a failure of SQS because the guarantees SQS makes are so weak that those partial failures are really "operating normally."

</comment></comment></comment></comment><comment><USER6> I think this is a decent response - they really nail what @rbranson misses, that the failures he mentions are actually features we're after.

An example,

> Convert something to an async operation and your system will always return a > success response. But there's no guarantee that the request will actually > ever be processed successfully.

Great! I don't want service A to be coupled to service B's ability to work. I want A to send off a message and leave it to B to succeed or fail. This separation of state (service A and B can't even talk to each other directly) is part of what makes queues so powerful - it's also the foundation of the actor model, which is known for its powerful resiliency and scalability properties.

The author's suggestion of using synchronous communication with backpressure and sync failures is my last ditch approach. I have to set up circuit breakers just to make something like this anything less than a total disaster with full system failure due to a single service outage.

Like the author, the "good use cases for queues" is very nearly 100% for me. I believe you should reach for queues first, and it's worth remodeling a system to be queue based if you can help it.

Sometimes modeling as synchronous control is easiest, but I'm happy that I can avoid that in almost every case.

<comment><USER7> > Convert something to an async operation and your system will always return a > success response.

It's funny reading this after using Erlang/Elixir over the last few years. The default is always async with the assumption it will fail - as async processes failing is a core part of the OTP application architecture.

It's not something to be feared but a key part of how your application data- flow works.

<comment><USER8> I've been planning on giving Erlang/Elixir a try, but we are very reliant on serverless and managed cloud services (like SQS) and I get the impression that managing a cluster of worker nodes for Erlang/Elixir would be too much work for us, since we would have to manage the servers, security patches, plan its scaling, etc.

Maybe I'm wrong and it's not so much work in the end. Hoping for some feedback.

<comment><USER9> I'd love to know how this isn't true as well, but I was in an environment where cross-az network costs were something we were continuously mitigating against. Using stuff like sqs let us build cross-az availability with 0-metered network costs, serverless can come into play because it's network connections usually come through 0-cost aws services as well. It seems to me like from a cost basis, getting into something with clustered erlang would kill you in many of these cloud environments (or at least you would be on the hook for engineering workarounds to keep traffic within an az w/ failover to other azs)

<comment><USER7> That's a good question. I'm sure there are people who could answer that. WhatsApp famously scaled an erlang app to a billion users around the world. Quite a few people have done it on a large scale. RabbitMQ is also built in Erlang and used in large deployments.

The zero cost stuff is always going to be a big draw with cloud deployments and the various demands from the company. Although a lot of this stuff like messaging and clustering/failover is within the application/Beam VM itself rather than something scaled or managed externally to the software. But that level of server and infrastructure stuff is out of my league of understanding.

</comment></comment></comment></comment></comment><comment><USER10> I use Postgres SKIP LOCKED as a queue.

I used to use SQS but Postgres gives me everything I want. I can also do priority queueing and sorting.

I gave up on SQS when it couldn't be accessed from a VPC. AWS might have fixed that now.

All the other queueing mechanisms I investigated were dramatically more complex and heavyweight than Postgres SKIP LOCKED.

<comment><USER11> I _LOVE_ this idea. I usually hear other Sr. engineers denigrate it as "hacky," but I think they aren't really looking at the big picture.

1\. By combining services, 1 less service to manage in your stack (e.g. do your demo/local/qa envs all connect to Sqs?)

2\. Postgres preserves your data if it goes down

3\. You already have the tools on each machine and everybody knows the querying language to examine the stack

4\. All your existing DB tools (e.g. backup solutions) automatically now cover your queue too, for free.

5\. Performance is a non-issue for any company doing < 10m queue items a day.

<comment><USER10> I don't think it's hacky - it's using documented Postgres functionality in the way it's intended. Engineers tend to react that way to anything unfamiliar, until they decide it's a good idea then they evangelise.

What does "hacky" even mean? If it means using side effects for a primary purpose then no, SKIP LOCKED is not a side effect.

I researched alot of alternative queues to SQS and tried several of them but all of them were complex, heavyweight, with questionable library support and more trouble than they were worth.

The good thing about using a database as a queue is that you get to easily customise queue behaviour to implement things like ordering and priority and whatever other stuff you want and its all as easy as SQL.

As you say, using Postgres as a queue cut out alot of complexity associated with using a standalone queueing system.

I think MySQL/Oracle/SQL server might also support SKIP LOCKED.

<comment><USER12> Thanks for posting that code!

Definitely similar experience here. We handle ~10 million messages a day in a pubsub system quite similar in spirit to the above, running on AWS Aurora MySQL.

Our system isn't a queue. We track a little bit of short-lived state for groups of clients, and do low-latency, in-order message delivery between clients. But a lot of the architecture concerns are the same as with your queue implementation.

We switched over to our own pubsub code, implemented the simplest way we could think of, on top of vanilla SQL, after running for several months on a well- regarded SaaS NoSQL provider. After it became clear that both reliability and scaling were issues, we built several prototypes on top of other infrastructure offerings that looked promising.

We didn't _want_ to run any infrastructure ourselves, and didn't want to write this "low-level" message delivery code. But, in the end, we felt that we could achieve better system observability, benchmarking, and modeling, with much less work, using SQL to solve our problems.

For us, the arguments are pretty much Dan McKinley's from the Choose Boring Technology paper.[0]

It's definitely been the right decision. We've had very few issues with this part of our codebase. Far, far fewer than we had before, when we were trying to trace down failures in code we didn't write ourselves on hardware that we had no visibility into at all. This has turned out to be a counter-data point to my learned aversion to writing any code if somebody else has already written and debugged code that I can use.

One caveat is that I've built three or four pubsub-ish systems over the course of my career, and built lots and lots of stuff on top of SQL databases. If I had 20 years of experience using specific NoSQL systems to solve similar problems, those would probably qualify as "boring" technology, to me, and SQL would probably seem exotic and full of weird corner cases. :-)

[0] - [https://mcfunley.com/choose-boring- technology](https://mcfunley.com/choose-boring-technology)

</comment></comment></comment></comment><comment><USER13> A long time ago, as new-ish developer, I was building a system that needed to take inputs, then run "pass/fail/wait and try again later" until timeout or completion. This wasn't mission-critical stuff, mind you, so a lost message would annoy someone but not cause any actual harm.

As I was figuring out how to setup a datastore, query it for running workflows and all that jazz, I happened upon an interesting SQS feature: Post with Delay.

And so, the system has no database. Instead, when new work arrives it posts the details of the work to be done to SQS. All hosts in the fleet are polling SQS for messages. When they receive one, they do the checks and if the process isn't complete they repost the message again with a 5-minute delay. In 5 minutes, a host in the fleet will receive the message and try again. The process continues as long as it needs to.

Looking back, part of me now is horrified at this design. But: that system now has thousands of users and continues to scale really well. Data loss is very rare. Costs are low. No datastore to manage. SQS is just really darned neat because it can do things like that.

<comment><USER14> The biggest gotcha in a design like this IMHO is that you can't post and delete atomically. You may post the new work into the queue and then a failure to delete could occur and the work will stack.

Depending on the workload this could be not a big deal or very expensive. Treating a queue as a database, particularly queues that can't participate in XA transactions, can get you in trouble quick.

<comment><USER15> With a realistic, that is, not 100% reliable, queue you can have either "at most once" or "at least once" delivery anyway. "Exactly once" can't be guaranteed.

So a duplicate message should be processed as normal anyway, e.g. by deduplication within a reasonable window, and/or by having idempotent operations.

<comment><USER14> Yes, it depends on the workload. Idempotency is typically always a good idea, but sometimes the operation itself is very expensive in terms of time, resources, and/or money. I have also seen people try to update the message when writing it back(with checkpoint information and etc) for long running processes. A slew of issues, including at least once delivery, can cause workflow bifurcation. Deduplication via FIFO _can_ help mitigate this, but it has a time window that needs to be accounted for. Once you start managing your own deduplication I'd say it has moved past trying to go databaseless.

</comment></comment></comment></comment><comment><USER16> Has anyone ever measured the latency of the sending message to SQS? I was using with ELB in t2.medium instances, and my API (handle => send message to queue => return {status: true}) response times were around 150 - 300 ms and replaced SQS with RabbitMQ, and it went down to around 75-100 ms.

Does anyone think that sending message to SQS is slow?

Edit: With this update, I was able to process almost 3 x requests with the same resources, and it lowered my bills quite a lot.

For example my SQS bill for last month

Amazon Simple Queue Service EUC1-Requests-Tier1 $0.40 per 1,000,000 Amazon SQS Requests per month thereafter 290,659,096 Requests $116.26

it went to 0, and ec2 cost went down as well because ELB spun up fewer instances that I could handle more quest with the same resources.

This was my experience with SQS. I just wanted to share it.

<comment><USER17> Were you running RabbitMQ clustered with persistent queues?

I don't think SQS is primarily for low-latency messaging, but rather a provided high available MQ with very little hassle.

<comment><USER16> I wasn't, single instance in the same subnet with persistent work queues.

</comment></comment></comment><comment><USER18> WE are heavy users of AWS. SQS is the only service where we have had zero downtime. The only downside we have about SQS is you can pull out only 10 messages at a time (without batching). You can have parallel readers but they result in some duplicates. There is SQS FIFO but it is throttled.

<comment><USER19> It went down on us once for extended period in 2015. It was chaotic as you don't expect it to fail. If memory serves me right, even S3 suffered that day.

<comment><USER20> A whole slew of AWS services went down that day. Tim's not wrong when he indicates that almost every service in AWS has a dependency on it (Amazon has services split up in to tiers based on how much they can rely on other services for critical components, SQS is pretty high up in the tiering.)

I was on-call that day for an AWS service. There wasn't much I could do but sit muted on the conference call and watch some TV, waiting for the outage to be over.

</comment></comment></comment><comment><USER21> One downside of SQS is that it doesn't support fan-out, for eg. S3->SQS->multiple consumers. The recommendation instead seems to be to first push to SNS, and then hookup SQS/other consumers to it. Kinesis/Kafka would appear to be better suited for this (since they support fan-out like SNS and are pull-based like SQS), but aren't as well supported as SNS/SQS (you can't push S3 events directly to Kinesis for eg.) Can someone from AWS comment on why that is? Also, related: when can we expect GA for Kafka (MSK)?

<comment><USER6> I do S3 -> SNS -> SQS. I don't see why I would use Kinesis instead. The SNS bit is totally invisible to the consumers (you can even tell SNS not to wrap the inner message with the SNS boilerplate), downstream consumers just know they have to listen to a queue.

I don't see a downside to this approach. Perhaps some increased latency?

<comment><USER21> If you wanted multiple pull-based consumers for the stream, wouldn't you need a separate SQS queue per consumer, with each queue hooked up to SNS? Perhaps I'm mistaken, but that seems brittle to me. With Kinesis/Kafka, you only need to register a new appName/consumer group on the single queue for fan-out. Plus, both are FIFO by default, at least within a partition.

<comment><USER6> That's exactly how you do it. To me, it's the opposite of brittle - <USER2> consumer owns a queue, and is isolated from all other consumers. Clients are totally unaware of other systems, and there's no shared resource under contention.

<comment><USER22> I feel like the create/delete queue semantics hint that a queue should be a long-lived thing that consumers are configured to connect to. When I saw suggestions to have one queue per consumer and have that consumer create/delete the queue during its execution lifecycle, the idea of one-queue- per-consumer started making more sense to me.

<comment><USER6> I think the word "Consumer" here is "Consumer Group".

For example, an AWS Lambda triggered from SQS will lead to thousands of executions, each lambda pulling a new message from SQS.

But another consumer group, maybe a group of load balanced EC2 instances, will have a separate queue.

In general, I don't know of cases where you want a single message duplicated across a variable number of consumer groups - services are not ephemeral things, even if their underlying processes are. You don't build a service, deploy it, and then tear it down the next day and throw away the code.

</comment></comment></comment></comment></comment></comment><comment><USER23> I really wish SQS had reliably lower latency, like Redis, and also supported priority levels. (Also like redis, now, with sorted sets and the [https://redis.io/commands/bzpopmax](https://redis.io/commands/bzpopmax) command.)

Has anyone measured the performance of Redis on large sorted sets, say millions of items? Hoping that it's still in single digit milliseconds at that size... And can sustain say 1000QPS...

<comment><USER24> We use Redis as a job queue and its great; the only limitation is being sometimes concerned about job queue size due to memory limits of the Redis server itself.

<comment><USER25> Also, when you don't want to lose a message, the Redis persistence story requires careful thought. It requires setting up RDB + AOF + appendfsync=always + backups.

<comment><USER26> You don't need to fsync on every write, that's what the replica is for. At lower/mid-tier hardware, network is faster than storage and your message is on multiple machines before it's even written to disk so fsync of 1 second is usually fine.

</comment></comment></comment></comment><comment><USER27> Author of [https://node-ts.github.io/bus/](https://node-ts.github.io/bus/) here. SQS is definitely one of my most favourite message queues. The ability to have a HA managed solution without having to worry about persistence, scaling or connections is huge.

Most of the complaints are native to message based systems in general. At least once message receives, out of order receives, pretty standard faire that can be handled by applying well established patterns.

My only request would be to please increase the limits of message visibility timeouts! Often I want to delay send a message for receipt in 30 days. SQS forces me to cook some weird delete and resend recipe, or make this a responsibility of a data store. It's be really nice to do away with batch/Cron jobs and deal more with delayed queue events.

<comment><USER24> RE: visibility timeout beyond 30 days, you may be more after a "saga" that has state and is long running (hours/days/months/years).

You can imagine building a saga system on top of a queue system.

<comment><USER27> You're absolutely right, in fact I have a whole package that is just that [https://node-ts.github.io/bus/packages/bus-workflow/](https://node- ts.github.io/bus/packages/bus-workflow/).

The problem is this. Let's say that I want to trigger a step in a "free trial" saga that sends an email to the customer 10 days after they sign up nudging them to get a paid account. If I can delay send this message for 10 days then it's easy.

However because SQS has a much shorter visibility timeout, I have to find a much more roundabout way of triggering that action.

<comment><USER24> Yeah, that makes total sense. For some of our saga's (we don't use SQS -- we use a custom redis queue), we have the saga potentially wake up and immediately sleep again ("Nothing to do right now, defer again in a few days").

But yes, a quirk.

</comment></comment></comment></comment><comment><USER28> We love SQS, but one of the problems we're running into lately is the 256kb per message limitation. We do tens of millions of messages per day, with a small percentage of those reaching the 256kb limit. We're approaching the point where most of our messages will hit that limit.

What are our options for keeping SQS but somehow sending large payloads? Only thing I can think of is throwing them into another datastore and using the SQS just as a pointer to, say, a key in a Redis instance.

(Kafka is probably off the table for this, but I could be convinced. I'd like to hear other solutions first, though.

<comment><USER29> We point to an s3 object for any large payloads

<comment><USER28> Wouldn't sending and later retrieving millions of S3 objects be expensive?

</comment></comment></comment><comment><USER30> Does anyone know a good, low overhead out-of-process message queue, that's lightweight enough that it can be useful for communicating between processes on the same machine, but if necessary it can scale beyond it? In case of a single-machine product that comprises of several services, a message queue can sometimes be useful for pull model, but adding RabbitMQ to the stack makes installation and ops much more complex than customers deem acceptable.

I know some people use Akka with Persistence module, but I would welcome other alternatives.

<comment><USER31> Guess it depends on the definition of "queue". Potentials:

      - https://nsq.io/
      - https://nats.io/

<comment><USER30> Seems like NATS streaming would fit my case - have you heard of any real world deployments that use it ? Are there any larger issues that don't make it a good choice ?

<comment><USER26> NATS Streaming is not as well tested and has some design issues that make scaling hard. NATS itself has a new version 2 that has a protocol update and NATS Streaming should follow with a new design as well, but I would recommend other options if you want persistence.

<comment><USER30> What are the design flaws that you have in mind? Is it ok for a couple of nodes or even then it would have trouble to keep up with a medium load? Or maybe the design flaws are to do with providing durability and other guarantees?

What other options would you recommend, that can provide at least once delivery and are lighweight enough not to require zookeeper etc?

<comment><USER26> Nats streaming isn't just a persistence layer to NATS. It's an entirely different system that basically acts as a client to NATS and then records messages it sees. Basically think of how you would design a persistent queue on top of the ephemeral NATS pub/sub and that's what NATS streaming is.

Here's a good post (and series) about distributed logs and NATS design issues: [https://bravenewgeek.com/building-a-distributed-log-from- scr...](https://bravenewgeek.com/building-a-distributed-log-from-scratch- part-5-sketching-a-new-system/)

</comment></comment></comment></comment></comment></comment><comment><USER32> Nowhere is cost mentioned. Using S3 as an ad-hoc queue is a cheaper solution, which should throw some red flags. You can easily do what SQS does for so much cheaper (this includes horizontal scaling and failure planning), that I'm consistently surprised anyone uses it. Either you are running at a volume where you need high throughput and it's pricey, or you're at such a low throughput you could use any MQ (even redis).

> Oh but what about ORDERED queues? The only way to get ordered application of > writes is to perform them one after the other.

This is another WTF. Talking about ordered queues is like talking about databases, because it's data that's structured. If you can feed data from concurrent sources of unordered data to a system where access can be ordered, you have access to a sorted data. You deal with out-of-order data either in the insertions or a window in the processing or in the consumers. "Write in order" is not a requirement, but an option. Talking about technical subjects on twitter always results in some mind-numbingly idiotic statements for the sake of 144 characters.

<comment><USER33> > Using S3 as an ad-hoc queue is a cheaper solution, which should throw some > red flags.

Interesting. Can you expand on this? How do you ensure that only one worker takes a message from s3? Or do you only use this setup when you have only one worker?

<comment><USER32> You encode messages with timestamp and origin (eg 1558945545-1), you write directly to S3 into a (create if not exists) folder for a specific windowing (let's say minute). Every agent writing, you end up with a new folder in the next minute. You have a window with an ordered set of messages by window by sort algorithm...optimally determined by the naming encoding.

<comment><USER34> You reminded me of a post on Dropbox announcement in 2007, that you can do it "yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem".

Just because you can, doesn't mean you should.

<comment><USER32> Cost is the motivating factor here.

<comment><USER35> Dropbox is more expensive than an FTP server, so the two scenarios are comparable.

</comment></comment></comment></comment></comment></comment><comment><USER36> From the operations side, I feel like SQS is a very sharp pair of scissors. In the hands of a good tailor, they'll make amazing things. On the other hand, most people use them to cut things they probably shouldn't, or just flat out Sprint around with them on a wet pool deck with their shoes untied.

A non-comprehensive list of ways I've seen my developers shoot themselves in the foot:

* Giant try-catch block around the message handling code to requeue messages that threw an exception. They neglected to add any accounting, so some messages would just never process. No one noticed until they saw the queue size never dropped below a certain amount during debugging.

* Queue behavior is highly dependant on configuration. Bad queue configurations result in dropped messages. Queueing systems provide few features to detect and alert on these failures (it's rally not their job), but building a system to track the integrity of the business process across queues is deemed to onerous.

* The built-in observability is generally not enough to be complete. I haven't seen a lot of great instrumentation libraries for SQS like there are for HTTP, meaning that observability is pushed on to the developer. They typically ignore that requirement because PMs rarely care until they realize we're unable to respond to incidents effectively.

* Most people vastly overestimate their scale. The number of applications I've seen built on SQS "because scale" that end up taking less than 100 QPS globally is significant. Anecdotally, I would say the majority of queue-based apps I have seen could have solved their scaling issues within HTTP.

* Many people want to treat queued messages like time-delayed HTTP requests. They are not, the semantics and design are totally different. I have seen people marshal requests to Protobuf, use it as the body of a message, and had another service read and process the request, and write another message to a queue that the first app reads back. It's basically gRPC over queues. Except that it solves none of the problems gRPC does, and creates a lot of problems. Just an example, how do you canary when you can't guarantee that the version of the app that sends the request will get the response to that request?

I think SQS is an amazing tool in the hands of people that know when to use it, and how to use it. But my experience has been that most people don't, and the ecosystem to make it available to people who aren't experts just doesn't exist yet.

<comment><USER37> I agree with most of this. If you have non-trivial message handling logic in a production system, you probably shouldn't use SQS directly to drive your work. Your SQS handling logic should be simple and reliable. In most cases, if the handling logic is complex, long-running, or needs operational visibility (logging, monitoring, etc.), I'd write the message handler itself to just kick off a workflow via Step Functions or some other workflow system. You'll pay for that in initial development costs, because it _is_ more complicated (you need to write lambda handlers, wire them up with CloudFormation, etc.), but the tradeoff is that it gives you a central place to look at each unit of work, instead of having your artifacts scattered around various logs (if at all).

The takeaway for me is: distributed systems are hard. If you have distributed workers, you have entered into a vastly more complex realm. SQS gives you _some_ tools to work successfully in that environment, but it doesn't (and can't) get rid of that complexity. Most of the problems I've seen relate to engineers not understanding the fundamental complexity of coordinating distributed work. Your choice of tech stack for your queues isn't going to make a big difference if you don't understand what you're fundamentally dealing with.

</comment></comment><comment><USER38> One important drawback of SQS is that it's eventually consistent, you can read the same message twice from different workers. Nevertheless we keep using it with additional checks when it's critical, it's still the cheapest solution by maintenance.

<comment><USER39> Making the processing of a message idempotent is the ideal way to handle that limitation

<comment><USER40> That's not always possible. Thus a big no-no for SQS if that's what you need. Concluding: SQS cannot replace RabbitMQ in all usecases.

<comment><USER41> If you're message consumer isn't idempotent then no MQ can help you. Exactly once delivery is impossible other than with at least once delivery and an idempotent consumer.

[https://bravenewgeek.com/tag/amazon- sqs/](https://bravenewgeek.com/tag/amazon-sqs/)

<comment><USER42> > Exactly once delivery is impossible other than with at least once delivery

Can you explain this? Don't many applications deliver once and only once via locking? It's obviously easier as an application developer to say "I will only get this once" and accept losing messages than dealing with idempotence particularly in distributed services.

<comment><USER43> Locking is no longer 100% reliable as soon as you have horizontal distribution of the same data over multiple nodes (for redundancy, so you can guarantee delivery) instead of sourcing from e.g. a monolithic rdbms. Eventual consistency is the model for a whole lot of distributed systems, e.g. S3 or Mongo. The CAP theorem applies to more than just databases, so MQs tend to use eventual consistency as well, which looks like at-least-once and not guaranteed exactly-once delivery.

While dealing with at-most-once delivery is easier in isolation as an application developer on the consumer side, dealing with lost messages is in practice MUCH MUCH harder on the producer side than idempotent handling where required on the consumer side. You end up building elaborate mechanisms for locking and retries and receipt validation which can all fail.

Just think about emails, there are a lot of situations where you can't be 100% certain whether the other side received the message or not. For something low- priority it may be better to ignore partial failures, but if it's important it may be better to send a second message to guarantee delivery. If you're modeled on never sending the same message twice AND the messages matter, you're in trouble.

</comment></comment></comment></comment></comment></comment><comment><USER44> After reading some comments in this thread im concerned about how many misconceptions people have about AWS services. Most of the stuff from "correcting comments" is plain available for anyone.

</comment><comment><USER24> Anyone run a multi-tenant SaaS and handle fairness with jobs "fairly"?

Occasionally we use to have all workers tied up on a single customers long running tasks, we mitigated by using a throttler we wrote that can defer a job if too many resources are in use by the customer, but it's not ideal.

I'd love a priority based, customer throttled (eg max concurrent tasks) queue.

We can prioritize by low/medium/high using separate queues, and could make a set of queues per customer; but that is starting to explode how many queues we have and feels unmanageable.

<comment><USER45> Using a database lets you make much better decisions on this space

Tbh purpose-built queues are taken way too eagerly by programmers who later end up needing the flexibility offered by a more general data store.

<comment><USER46> Yes. I've seen it in all kinds of teams. Anything that allows a developer to retrieve some data after a local server restart essentially gets treated by devs as a system of record, regardless of the intricacies or guarantees involved.

My personal experience is that abuse of queuing/messaging systems along this axis is rampant. Engineering leaders must keep a close eye on how these types of mechanisms are utilized to ensure things don't go off the rails.

I've seen far too many serious data loss events that boil down to "we lost our AMQP queue". It's critical that developers understand the limitations of the systems that run their code rather than just jumping aboard that "SQL is for old people" hype train.

</comment></comment></comment><comment><USER47> We've used SQS with great results (and reliability) for many years now, but I am interested to hear the author talking about 'replaying queues' to replicate faults. I never realised you could do this with SQS. Or can you? I thought once a queue item was processed and deleted, that was it, it was gone forever, but perhaps you can see historical queue data somewhere? (without having to store it yourself)

<comment><USER21> Possibly this: [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQS...](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs- dead-letter-queues.html)

<comment><USER47> We actually already use the DeadLetterQueues in our service at the moment, but these are when _failed_ SQS deliveries happen, then they get replicated to the DLQ.

I am more interested in diagnosing _successful_ SQS deliveries after the fact, to see what the payloads were in case there was a downstream problem.

It seems that SQS deliveries that don't get a 200 response from our service go to the DLQ, but those that get a successful 200 disappear into the ether.

</comment></comment></comment><comment><USER48> > Those messages will age out and vanish after a little while (14 days is > currently the max); but before they go, they're stored carefully and are > very unlikely to go missing

can somebody expand on this? I know about the 14 days limitation but this makes it sound like you can store messages for a long time and still recover them somehow?

<comment><USER19> I think what he meant was, Once you successfully put a message to SQS, it is kept till the 'message retention period' unless you explicitly call delete on it. Right now you can configure the period to be upto 14 days. AFAIK, there is no way to recover messages older than their retention period.

<comment><USER48> You are right, thank you! I misinterpreted that.

</comment></comment></comment><comment><USER49> > So what to do? In almost all cases it's better to propagate failure and > backpressure. This gives a chance for the upstream to decide if it wants to > retry or fail itself. It keeps things simple and easy-to-understand. It > doesn't build up huge backlogs that become disasters.

What does this actually mean in practical terms?

<comment><USER50> [https://ferd.ca/queues-don-t-fix-overload.html](https://ferd.ca/queues-don-t- fix-overload.html) explains it better than pretty much anything I've read on the topic.

</comment></comment><comment><USER51> I see lots of engineers who argue that queues are bad and cause more problems than they solve. "Queues don't have backpressure" is a common complaint. It wouldn't be a difficult thing to add to a queue interface, but people don't do it despite the relative ease of the task. It is pretty easy to get a cardinality estimate on the queue size of any given queue even as it's rapidly increasing and decreasing in value.

The reason why is that it's probably a bad idea in the first place to mix your control and data interfaces into an inextricable knot. Since you're not going to be able to institute rate limiting at a sub-millisecond latency in a distributed system anyways, why isn't your control plane separate and instrumented?

Once you have a separate control plane, you can introduce back-pressure in many different ways and do so with a better understanding of the dissemination of those throttling values throughout your system.

So what I see are engineers who are actually ignoring the the architectural decision with at least as many implications as "queue vs diffuse interface," namely "control and data or just one monolithic system."

</comment><comment><USER52> I recreated an SQS style service on AWS for sole purpose of avoiding being locked into Amazon. It used their autoscale system and was about the dumbest simplest api you can imagine, just depositing messages into a geographically replicated db table for later processing. We also used it as sort of a backup system, where the messages were never truly deleted and everything could be reprocessed as needed since the front end db that held processed records was an absolute amateur disaster just waiting for some malicious sql injection wipes. It was solid as a rock and extremely low maintenance. I think things have become relatively standardized since then (aka lots of duplicate SQS compatible api/services), so unless there was a serious requirement to stay off SQS I'm not sure I'd do it again.

</comment><comment><USER53> With 4-5 concurrent processes reading from my (FIFO?) SQS queue, I have a hard time seeing the contents of the queue from the console. SQS really doesn't handle the concurrent readers well in my experience.

</comment><comment><USER54> is SNS + SQS a reasonable solution for realtime irc style topic chatrooms?

<comment><USER47> There is also a size limit on the messages sent via SQS - 256Kb IIRC. Might be OK for small text based messaging, but if you want to talk attachments and other payloads then you have to hook it up to other services like S3 etc. and then it becomes complicated.

Also, as another respondent replied - there is no real deliverability guarantee, although there are certain ways to handle that within SQS.

</comment></comment><comment><USER55> I clicked the link. Laptop set to loud by mistake. The cat asleep on the keyboard nearly died.

</comment><comment><USER56> Way to go Rick! You know you've made it when people write blog posts about your hot takes on Twitter</comment>


Using wireless network signals to see through walls - <AUTHOR> http://www.wired.com/threatlevel/2009/10/see-through-walls/

<comment><USER2> Bruce Schneier linked to this article, the comments are here [http://www.schneier.com/blog/archives/2009/10/using_wi- fi_to...](http://www.schneier.com/blog/archives/2009/10/using_wi- fi_to.html#comments) .

This is pretty obviously an outgrowth of the old body capacitance sensors used in monitoring secure areas. It would be pretty easy to spoof since it would also detect moving pieces of any conductors or electronic devices. For SAR they would only detect a person (or electronic device) that was moving; if you are pinned down, tough luck.

</comment><comment><USER3> Honestly, it is not as useful as ultrawideband handheld radar under prototyping. Surrounding antenna array is just too excessive.

</comment><comment><USER4> Cool technology, thought the editorialization is a little lame. Really? SWAT? Because anything that can track movement will be immediately useful to SWAT? Wouldn't the base-station have to be _inside_ the building? The author could have tried just a little bit harder to envision a use.

<comment><AUTHOR> I don't see why the base station needs to be inside the building. Radio waves go _everywhere_.

That is, as long as the building isn't a Faraday cage.

<comment><USER4> Seems to me though that the radiowaves would have to go in the general direction of the person moving, right? I suppose you could surround the entire building and go from there...

</comment></comment></comment><comment><USER5> It would be awesome if you could use the wifi on the iPhone to do this and sell it as an app. I'm guessing you don't get that low level of control over the iPhone's wifi though?</comment>


Dart 1.0 Is Out - <AUTHOR> http://news.dartlang.org/2013/11/dart-10-stable-sdk-for-structured-web.html <comment><USER2> This is really awesome! Congrats to the team!

We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess.

I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.

<comment><USER3> If you are looking for a structured language (for front end dev), Typescript is a better alternative imho. Javascript devs can still read it and it's compatible with any JS library out there.

Dart not so much since the semantics are different.You can still interact with JS libs but it's not as straight foward as TS.

I tested a number of options (GWT,Haxe,CS,Dart,Opal,Jsx,...),while i'm not a Microsoft fan(by a long shot),Typescript is the solution that allows the best integration with legacy code and pure JS libraries,while making easy to port old java/C#/as3 code to JS.

<comment><USER4> I agree with this very much. Dart is a new language; JS is an existing language, improved.

Dart actually has horrible semantics in places. Only if x === true will if(x) run.

<comment><USER5> That's very different from Javascript (and from the untyped-language mainstream) but is it really "horrible"?

The type-checker will give a very clear warning if it catches you putting a non-bool in a conditional context. And make no mistake: the type checker is an important part of the Dart development process.

(One downside of this is that it does push you to working in the -- Eclipse- derived -- DartEditor, which isn't always a wonderful experience. However, the type checker is exposed and available, and there's nothing to prevent it being tightly integrated into other editors or IDEs.)

</comment></comment></comment></comment><comment><USER6> _Going forward, the Dart team will focus on improving Dartium, increasing Dart performance, and ensuring the platform remains rock solid. In particular, changes to core technologies will be backward-compatible for the foreseeable future._

 _Today's release marks the first time Dart is officially production-ready, and we're seeing teams like Blossom, Montage, Soundtrap, Mandrill, Google 's internal CRM app and Google Elections, already successfully using Dart in production. In addition, companies like Adobe, drone.io, and JetBrains have started to add Dart support to their products._

Congrats to the team on releasing 1. Now to find a project to try it out in...

</comment><comment><USER7> This is speculation: but JetBrains work on dart IDE, android releasing ART, I'm tempted to say we're 2 years out from seeing DART running on android. It makes sense from a business sense, have the option of running dart apps on android would free the platform from its java dependance.

<comment><USER8> The VM already works on Android (x86 and ARM - not sure about MIPS).

<comment><USER9> The VM works on MIPS too.

</comment></comment></comment><comment><USER10> I think Dart has the potential to become a target for other languages [1]. The already-high-level code has a performant VM and it takes advantage of optional typing (unlike any other VMs I am aware of). In order to do so though, they should at least make a spawnString (like isolate's spawnUri) or even better, have the ability to JIT dart code by string but not execute it right away.

1 - [https://www.dartlang.org/articles/why-not- bytecode/](https://www.dartlang.org/articles/why-not-bytecode/)

<comment><USER11> Adobe's AVM2 (ActionScript 3 VM) took advantage of optional typing.

Once upon a time this was going to be the basis of ECMAScript4 via tamarin, but that never panned out for lots of reasons, most of them political.

<comment><USER3> Funny how things would be different today.

ES4 failed mainly because some people thought ES3 was good enough.

Adobe,harshly critized for Flash was the one pushing for a better javascript.

I will never understand why Microsoft basically killed ES4. They had their own implementation on .net ( JScript.net ) so it's not like it was going to be a huge effort. The only reason would be Microsoft pushing Silverlight at that time which was a huge flop. We basically lost a decade because of it, as i predict javascript will eventually look like ES4,that's inevitable.

<comment><USER12> Javascript lost a decade because of that.

People without an investment in Javascript have lost _over_ a decade because of Javascript's monopoly on clients being maintained. If we had not been forcibly locked into Javascript all this time, then competition would have produced a better alternative or whipped the process designing Javascript into shape. Now we are stuck with this ridiculously tall, messy stack which uses an application scripting language as a compile target, still lacks basic features like a standard package system, and pushes trivial language features like iteration into third-party libraries like jQuery. So now we are constantly pushing megs of JS, using insanely complicated build systems to get anything done, and for all this trouble our code runs at a speed roughly equivalent to C in 1998.

(Now that Flash and Silverlight are dead I think it is safe for me to complain about Javascript without being an enemy of the open internet or whatever.)

I don't really care about Dart, but it's way past due that there was something serious to challenge Javascript. All the triumphalism about how Javascript is already a perfect language to use for eternity is explicitly counterproductive. Making the whole internet depend on the fortunes of one language just sucks.

<comment><USER13> > So now we are constantly pushing megs of JS, using insanely complicated > build systems to get anything done, and for all this trouble our code runs > at a speed roughly equivalent to C in 1998.

Those who care, just keep happily using plain native applications.

</comment></comment></comment></comment></comment><comment><USER14> So if i get it right, the way "Google" sees the future, there is Go at the server side and Dart at client side (which is in fact JS). Am I wrong?

I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs. JS can be complied into go binaries after all, so why not letting people write apps using the same language.

Let alone I see no effort on their side bringing any of those language into the native world of Android, instead we got this cluttering Java thing as almost the only options for most projects.

<comment><USER15> Dart is a better Java (that can run in a browser if you want).

Go is a better C++.

<comment><USER16> Actually I wouldn't say Go is a better C++.

Rust is a better C++. Go is.. weird. I would even say it is a better Java.

<comment><USER17> A better Python?

<comment><USER18> Not really....

</comment></comment></comment></comment></comment><comment><USER19> I am a newbie in field of Web Development, and recently I felt in love with JavaScript, especially because of the sheer capability to write Client side and Server side code in same language. Thanks to Meteor.js, it made my bond with JavaScript even more stronger.

But now with the buzz of Google Dart going around, I am afraid that, am I betting on the wrong horse? Is it the right to jump on Google Dart bandwagon? To be honest, it do looks promising.

Please guide me, what should I do, since I am a newbie, I want to take advantage of the fact that, since I don't know anything, I better learn something that have much promising future, and have an edge over technology.

<comment><USER20> Learn Javascript. Dart is a dead end technology.

ALL the committers are from Google and it is not an open standard which basically eliminates any chance that Mozilla/Apple will ever consider adopting it. And frankly with Apple dominating the mobile web without them any solution will never eventuate to anything.

<comment><USER8> > _[Dart] is not an open standard_

It will get standardized in the not too distant future. [1]

> _Apple dominating the mobile web_

Huh? Android's market share is over 80%. iOS got about 13%. [2]

[1] [http://www.ecma- international.org/news/Dart%20workshop.htm](http://www.ecma- international.org/news/Dart%20workshop.htm)

[2] [http://thenextweb.com/insider/2013/11/12/idc-android- hit-81-...](http://thenextweb.com/insider/2013/11/12/idc-android- hit-81-0-smartphone-share-q3-2013-ios-fell-12-9-windows-phone- took-3-6-blackberry-1-7/)

<comment><USER20> Android's market share maybe 80% but it is about 50/50 in terms of web usage.

And don't forget that Apple customers are acknowledged as the more valuable (higher net worth, disposable income, tastemakers etc)

<comment><USER21> Wait until developing word get their smart phones.

</comment></comment></comment></comment></comment><comment><USER22> Sad to throw away the brilliance of prototypes to go back to single- inheritance classes. uck

<comment><USER23> JS prototypes provide a _single_ parent lookup delegation, which is not that different from single inheritance and is mostly used to emulate single inheritance class systems in the wild.

Furthermore Dart supports mixins, so it's not exactly single inheritance classes.

</comment></comment><comment><USER24> Psyched! See our HN post about our Dart app (Dart rocks) and our team's disappointment with not being included in the 1.0 announcement. [https://news.ycombinator.com/item?id=6735044](https://news.ycombinator.com/item?id=6735044)

<comment><USER25> I don't know anything about what went into deciding which companies were mentioned in the announcement, but I know for certain I and others on the team have a ton of respect and gratitude for all of the help you and Kai have given us. Thanks!

<comment><USER24> Thank you! And congrats!

</comment></comment></comment><comment><USER26> Some people wanted to build optional-typing language for real world for decades, and finally made it. That is a great achievement.

From product point of view, Google would be much better to port Android Dalvik to Chrome. You can run GWT Java code in browser years ago. Running the same code using JVM would be much faster with much less code change. 5-10 man-year would be enough to do the porting, and it will share work between Android and Chrome for years to come. Of course, it would be much boring research work though.

From performance point of view, asm.js gets much better performance with way less work. No matter how good Dart performs, it would never make sense to port high performance C/C++ game code to Dart, so you end up having to use both Dart + pNaCl, which is an awful solution. Technically, TypeScript is more interesting if Microsoft can keep it simple and fast, but I doubt Microsoft would make anything simple.

</comment><comment><USER27> Would someone who knows HTML/CSS/RoR better of learning Dart or JS next?

<comment><USER3> Even if you use language X that compiles to javascript ,you still need to learn javascript, Or it's a bit like learning rails without understanding ruby.

<comment><USER28> I don't need to learn assembly to use C. I don't need to learn the JVM bytecode to use Java.

Sure for special cases knowing those things can help get the very best out of your code, but for the other 99% of the time, it is not necessary.

(Edit: Not that I recommend Dart over JS necessarily, but I don't agree with your argument.)

<comment><USER29> > _I don 't need to learn assembly to use C. I don't need to learn the JVM > bytecode to use Java._

But you DO need to learn Javascript to use Dart on web apps, so the comparison is irrelevant.

<comment><USER30> Why do you need to learn JavaScript to use Dart? You need to understand the DOM and the browser APIs (presented through Dart libraries), and HTML, CSS, but you very much don't need to know a jot of JavaScript to build and deploy Dart or dart2js applications. Even the Dart2js output has sourcemaps letting you view source in the original Dart.

</comment></comment></comment></comment></comment><comment><AUTHOR> List of companies using it in production (from the blog post):

* Blossom

* Montage

* Soundtrap

* Mandrill

* Google's internal CRM app

* Google Elections

Companies that started to add support for it: Adobe, drone.io, and JetBrains

</comment><comment><USER31> Dart seems interesting, but its sponsorship by Google creates a major problem - what incentive does Microsoft, Mozilla, or Apple have to implement Dart support in their browsers? What about JavaScript devs who choose not to support Dart (especially since many still have to support even as far back as IE8 due to enterprise/companies/organizations/schools that opt for long-term support solutions for software)? I don't think good answers are available to these questions, which makes me hesitant to jump in as quickly.

<comment><USER32> Dart also compiles to JavaScript, and was designed to do so from the very beginning.

<comment><USER31> It adds complexity to the dev process, and I'm not sure of the benefits of said complexity. The devs still at the core need to understand JavaScript it seems like.

<comment><USER30> > The devs still at the core need to understand JavaScript it seems like.

No, that's not the case. You need to understand the browser DOM, and the various APIs available to you, but these are presented by Dart libraries. If you have knowledge of Java or C#, then that knowledge will be useful, and if you have knowledge of JavaScript's functional elements, then that is also useful, but none of that is mandatory to be effective with Dart.

<comment><USER31> But if you're using third party JS libraries and want to integrate with a Dart app? Seems necessary to still have to understand JS to integrate properly since you still have to know how those libraries' API works.

</comment></comment></comment></comment></comment><comment><USER33> I almost finished the Language Tour when I went to the faq and was dissapointed to see that the dart2js compiler supports only ie9+ ([https://www.dartlang.org/support/faq.html#what-browsers- supp...](https://www.dartlang.org/support/faq.html#what-browsers-supported)). Too bad, honestly.

<comment><USER34> Opinion: nobody should be shipping _any_ JS to oldIE, period.

Their JS engines are woeful. Even if you can get something app-like (the kind of thing you would use dart for) to _work_ , your app won't scale w.r.t. perf so you're painting yourself into a corner.

<comment><USER35> That's your opinion and you're entitled to it but people do still have to ship things for IE6-8.

<comment><USER34> Understood. I'd just question if it needed JS - if JS actually added to the UX and outweighed the considerable dev cost.

<comment><USER20> How on earth do you propose to implement client side functionality without JS ?

The fact is that MANY people need to support IE6-8.

<comment><USER34> Sample size of 1 etc, this is just my experience.

I personally built a single page application about 2 years ago that _worked_ in IE8, thanks to jQuery and the ecosystem of the time. jQuery, jQuery UI, various plugins incl. jsTree & DataTables.

It flew in Chrome, Firefox and Opera, even then. In IE8 it was slow as hell. Event listeners were slow, ajax and parsing JSON was slow. Everything was crazy slow. The app felt lumpy and awful. And when I hit bugs, the developer tools just were not there.

I would never do this again.

I'd wager that for IE < 8, for any non-trivial app, round-tripping to the server will give you a better UX than using JavaScript.

Deliver something _usable_ for oldIE. There are many people that share this view. I suggest watching this talk on how the BBC deals with legacy browsers (9m 20s): [http://www.youtube.com/watch?v=YfvMQ316hMU&t=00h09m20s](http://www.youtube.com/watch?v=YfvMQ316hMU&t=00h09m20s)

</comment></comment></comment></comment></comment></comment><comment><USER36> How's the Emacs mode?

<comment><AUTHOR> The one I am using (and I don't even remember which one it is or if there are multiple ones) does basic highlighting. There is no re-factoring support that I could find yet.

</comment></comment><comment><USER37> Why doesn't Google include the native Dart VM in Chrome? I think it would boost it's usage significantly. Maybe I'm missing a bigger picture.

<comment><USER21> They need make some changes in Chrome for doing this right. They aim to make DOM nodes garbage collectible with project oilpan [1] AFAIK. Both Dart and V8 VM will benefit from this. So this will take some time. But Dart is already very useful with Dartium for development and Dart2Js for deployment.

[1] [https://groups.google.com/a/chromium.org/forum/#!topic/blink...](https://groups.google.com/a/chromium.org/forum/#!topic/blink- dev/V1vJmirHUGE/discussion)

<comment><USER38> This is exactly the issue.

They are working on an experimental solution to let garbage collection happen for DOM nodes that are created from Dart or V8. This basically requires a rewrite of the memory management of DOM nodes. This is still very much a work in progress and not ready for prime time.

The solution the team uses for Dartium is not the same as what they want to do for the shipping version of Chrome, so it'll be a bit before that's ready.

</comment></comment></comment><comment><USER39> Is there a downloadable reference manual for the language? I see book excerpts, but not a complete language reference.

<comment><USER9> [https://www.dartlang.org/docs/spec/](https://www.dartlang.org/docs/spec/)

<comment><USER21> This is Language spec. not useful for developers. I would suggest downloading 5 links as HTML from here:

[https://www.dartlang.org/docs/dart-up-and- running/](https://www.dartlang.org/docs/dart-up-and-running/)

</comment></comment></comment><comment><USER40> Just waiting for "Works best on Chrome"

Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.

No thanks.

<comment><USER41> What exactly is proprietary about it?

Browser vendors are free to integrate the VM into their products, and if they don't want to there is dart2js which is acceptable.

This isn't even close to the situation presented by Silverlight, ActiveX and I feel like you're being duplicitous by comparing them.

<comment><USER42> > Browser vendors are free to integrate the VM into their products, and if > they don't want to there is dart2js which is acceptable.

That's a tremendous amount of effort and it is likely to reduce the performance of JavaScript. Cross-language GC, in particular, is really hard. See Filip Pizlo's message to webkit-dev on this subject (citing two recent papers), which is part of the reason that Dart support was shot down when Google proposed adding it to WebKit: [https://lists.webkit.org/pipermail/webkit- dev/2011-December/...](https://lists.webkit.org/pipermail/webkit- dev/2011-December/018811.html)

<comment><USER43> As of today, dart2js is the only way to deploy Dart to users' browsers, Chrome included. It already performs well enough for most apps.

The Dart VM is nice but its primary purpose right now is running the Dart compiler and in Dartium which is only used by developers. (You can use it for other things but the ecosystem isn't there yet.)</comment></comment></comment></comment>


No Time to Think: the information overload environmental problem (videolecture) - <AUTHOR> http://www.youtube.com/watch?v=KHGcvj3JiGA <comment><USER2> Ironic that a video on information overload is an hour long, eh?</comment>


Ask HN: Which VPS provider do you use for personal and professional use? - <AUTHOR>

I have been searching for a good VPS provider for my personal use and one for my startup.
Currently I user Digital Ocean, but it lacks a lot of features needed to setup a proper system.
What are some good cheap vps providers for personal use?
For startups, I know people have been suggesting AWS and Azure, but are there any good alternatives available? <comment><USER2> I second the suggestion of Ramnode. I've used them for both small openvz 'personal projects' as well as much larger multi-node setups. They're all pro as far as i'm concerned....also reliable, fast & i've never had a problem reaching their tech support (and god knows i've had to reach out to them at the worst times of the night in the past when something wasn't working as planned). There's another VPS service that is also fast + reliable though they're more for people who already know what they're doing that shares a similar name - ramhost.us. I currently have two small vps accounts on ramhost.us for various scripts/apps that help make my life easier. I couldn't recommend either service enough to be honest.

Linode.com is also pretty reliable + fast (though I do realize they are right now experiencing a datacenter being down).

I use to have lots of small vps's going (I was a regular on lowendbox.com) back a few years ago (some were dev, some were for clients, some were just all the open source projects I was working on. It all boils down to exactly what you want to get out of it (also where in the world you want to host it). For instance right now i just need two low-end openvz nodes that don't pull in much traffic, hence my choice with continuing with ramhost.us rather than Ramnode or linode (they've got small packages + frequent discounts for new accounts). Another option i would have easily chosen would be hostigation.com. These aren't for big production sites though (although i'm sure they'd handle them without a glitch).

My biggest suggestion is stay away from any service that has hosting as a secondary option (i.e. all the domain registrars and hosts who have shared hosting as their primary source of business).

</comment><comment><USER3> For personal use, I use BigV[0] and for a pet project which deals with reasonably large datasets I picked up a Hetzner dedicated for $cheap in their Server Auction[1] with 32Gb RAM which is fine for playing around on :)

[0] [https://bigv.io/](https://bigv.io/) [1] [https://robot.your- server.de/order/market/country/GB](https://robot.your- server.de/order/market/country/GB)

</comment><comment><USER4> I don't use DO but what features is it missing?

IMO aws/etc aren't "VPS providers".

If you just want a virtualised machine, they're worse in many ways because you have to work around the "features" of the platform.

If you want an actual VPS provider (or even dedicated hardware or a mix of both), I recommend RimuHosting.

If you want to buy into the platform lock in of AWS/etc I recommend you re- think your options and goals.

<comment><USER5> RimuHosting, as well as good products, has outstanding service: a very personable and highly capable organisation.

</comment></comment><comment><USER6> I switched from Hostgator to Linode and I have been a lot happier with my Linode VPS. They have more OS choices (the only I've found so far that has Ubuntu) and recently they came out with a $10/month plan which I want to switch to so I don't have to keep paying $20. Their customer support is great as well. They have step-by-step articles on how to set everything up in a secure way and the DNS can be managed through their website which is so much better than having to do all that myself.

</comment><comment><USER7> Linode has always been the go-to for my small and large scale projects.

</comment><comment><USER8> This is the cheapest I've found, ~$15- never used it though. [https://contabo.com/?show=configurator&vserver_id=145](https://contabo.com/?show=configurator&vserver_id=145)

</comment><comment><USER9> By good i read between your lines "cheap". Use cheap for early testing, prototyping. Use AWS,Azure,Heroku for production. Simple as that.

</comment><comment><USER10> I use OVH kimsufi's dedicated server as it can be pretty cheap and VPS in general doesn't serve 100% of my needs.

</comment><comment><USER11> [http://ramnode.com](http://ramnode.com)

</comment><comment><USER12> > but it lacks a lot of features needed to setup a proper system.

...such as?</comment>


A progressive migration from Backbone to Vue.js - <AUTHOR> https://snipcart.com/blog/progressive-migration-backbone-vuejs-refactoring <comment><USER2> This is a really good illustration of why Vue.js is such a big deal. It's very easy to pull in incrementally into an existing codebase. I'm working on a very large Rails installation right now that has an old-school front-end basically cobbled together with jQuery, and rather than throw out several years of effort just to get the "new shiny", we're adding Vue.js in as needed in parts of the app undergoing new development. Eventually we'd like to go back and start rewriting older features as well.

Long story short, getting Vue.js, jQuery, and even Turbolinks to play together nicely was actually not hard, and the rapid pace of development now and the ease at which Vue.js can be used without throwing away all existing domain knowledge in the front-end is impressive. As both a Ruby and a Javascript developer, I've always had a love-hate relationship with the latter, but programming JS using Vue has made doing front-end code way more fun. :)</comment>


Annoying Function Notation (in math) - <AUTHOR> http://mathmisery.com/wp/2016/07/01/annoying-function-notation/ <comment><USER2> Personally I've adopted Wolfram Language (formerly Mathematica) 's convention of indicating the application of function f to variable x as f[x] rather than f(x) precisely to avoid ambiguities such as those indicated towards the bottom of the article. I've also seen and adopted the convention of using a very clear -1 exponent to indicate reciprocals and -I (vertical unadorned bar) to indicate an inverse function. It kind of works to lessen the confusion, though of course clarity is in the eyes of the beholder.</comment>


The Obscure Economist Silicon Valley Billionaires Should Dump Ayn Rand For - <AUTHOR> https://www.vanityfair.com/news/2017/09/the-obscure-economist-henry-george-ayn-rand <comment><USER2> The book is available here: [http://www.henrygeorge.org/pcontents.htm](http://www.henrygeorge.org/pcontents.htm)

Previous HN Discussions: "Land-value tax: Why Henry George had a point" \- [https://news.ycombinator.com/item?id=10442929](https://news.ycombinator.com/item?id=10442929)

How I Used Eve Online to Predict the Great Recession - [https://news.ycombinator.com/item?id=9158868](https://news.ycombinator.com/item?id=9158868)

</comment><comment><USER3> > When you work for an hour, you increase society's wealth (and your own) by > an hour's worth of wages.

true.

> When you save a dollar rather than spending it, you increase society's (and > your own) wealth by a dollar

um no. spending only transfers the dollars, and normally you trade the dollar for something worth more to you than the dollar & vice versa, and society's wealth increases due to trade.

<comment><USER4> Yeah, this is total bs. The economy needs the money to circulate, then everybody gets richer. Money has no value but as a share of the economies' production. When money flows, production goes up. The problem is when some people who are so rich that they can barely spend a few per cents of their income. Instead of getting spent, the money gets invested. But that's not really circulation, it's the opposite: Stuck money used to stick more money.

Edit: This is not to say that there isn't any merit in Georges' other ideas.

<comment><USER5> Money not spent/deferred means that the person producing basically volunteered their time.

Money invested is spent - it's spent by people who it's given to.

There is no such thing as "stuck" money.

<comment><USER3> depends on how that money is "produced".

Is it obtained by labor or by extracting rent.

When labor is added (get paid for building a house) real value is generated. In comparison having a piece of land go up in price, no real value is created for society.

In a society with 100 dollars, having zero velocity of money means trade using money is stopped. That's "stuck".

[https://en.wikipedia.org/wiki/Velocity_of_money](https://en.wikipedia.org/wiki/Velocity_of_money)

<comment><USER6> The purpose of money isnt' wholly to create value for society; its also to serve as a medium with which to measure the allocation of scarce resources.

If land prices go up, the resources associated with them then get allocated to those who find the greatest utility, and the money goes to other who will then _spend_ it on other things.

If you force prices to stay static, you just get the Bay Area where whoever plopped themselves on the land first gets to keep it, like some kind of landed aristocracy.

<comment><USER3> tokyo is ahead of bay area in the process. Prices go up but then will go down as people decide its not worth it, and other places become "cooler".

Also tech (autonomous cars, hyperloop, flying cars , VR/AR ) or econ (UBI) disruption is coming in the next decade or two...

</comment></comment></comment></comment></comment></comment><comment><USER7> > You've got to think of "land" as a metaphor for all unproductive forms of > capitalism... Goldman...

Banking existed in George's day too and when he said land I think he meant land. Land issues are still relevant today - in SF/silicon valley much of the value created by the tech industry has ended up with landlords who did nothing to produce it. You could make an argument for taxing that and spending it on social stuff. Also places like Monaco and Hong Kong have been successful in having low / zero taxes on wages etc by the government keeping ownership of much of the land and getting income from that.

</comment><comment><USER8> I have a lot of respect for Georgists and geolibertarians, unlike the much more common Randroids and propertarians (which one geolibertarian author quite rightly calls "royal libertarians" both because of where their wealth came from and the role they aspire to). The central Georgist/geolib idea of a land value tax has been tried quite a few times, generally with quite positive economic effects even before factoring in the moral effect of taxing rents instead of productive enterprise. The author's right that these ideas deserve more exposure than the melange of crappy fiction and crappier ideology that is Ayn Rand.

</comment><comment><USER9> The author of the piece says Rand "rationalizes greed," which is false, as there are many forms of greed, not just financial. My understanding is that she says that society is most moral when people are able to trade without coercion, and therefore the wealth generated from free trade cannot be classified as "greed".

</comment><comment><USER10> "Chances are that will be Ayn Rand and her extreme form of capitalism, which she called objectivism."

Rand's views on capitalism are only a small part of her philosophy and not at all the most interesting or compelling by far. By reducing objectivism to a form of capitalism, the author and most contemporary Rand proponents show they know little to nothing about objectivism and understand little to nothing of Rand's philosophy. It's sad that this aspect of her writings is so emphasized over everything else when it's the least interesting and least compelling of her writings about the human condition and the self. Most people using Rand's philosophy as a justification for their exploits of others would be considered looters by Rand, the exact opposite of what she espouses.

<comment><USER11> Rand failed by her own metrics: a little old lady requiring social help... Not a philosopher, or much of a novelist.

<comment><USER10> What kind of an asshole would not help a little old lady who requires help? Rand would and so would anyone who understands her philosophy.

<comment><USER11> Well, no. She was at first trying to refuse social help until the reality that she was actually poor was forced upon her.

</comment></comment></comment></comment><comment><USER12> The author of the piece, Michael Kinsley, is a flat out genius. That is and has been apparent going back to his both incisive and funny comments on Crossfire.

I started reading the article and was blown away within the first paragraph by the quality of the writing and I scrolled up to see the author and.... Michael Kinsley.

</comment><comment><USER13> "According to James Stewart (the prominent business journalist, not the even more prominent actor), writing in The New York Times, President Trump says Ayn Rand is his favorite writer and that The Fountainhead, her pulmonary embolism of a book, is his favorite novel. Travis Kalanick, the onetime Übermensch of Uber, is on board, as is (liberal foodies, please note) John Mackey, co- founder and C.E.O. of Whole Foods."

Or the actual reason why the author thinks Ayn Rand should be "dumped", in case you are wondering.

President Trump is a fan of Ayn Rand. Travis Kalanick likes her books. John Mackey likes her books aswell. This proofs that Ayn Rand is evil and therefore her ideas are evil. Guilty by association.

Someone who somehow survived the atrocities of communism and dedicated the rest of her life to make sure nobody would face the same atrocities like she did again. And this person is considered to be evil.

Well, you know what, author over at Vanity Fair? Maybe Ayn Rand had some points which are debatable but YOU have unmasked yourself as a far left "liberal" ideologue. So fuck off, and take your ideological bullshit with you.

<comment><USER14> > _YOU have unmasked yourself as a far left "liberal" ideologue. So fuck off, > and take your ideological bullshit with you._

Please don't post ideological rants to HN. Regardless of how lousy an article or a comment may be, all this does is poison the commons and degrade the discourse further. We're trying to avoid those things here.

Please see [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html) and [https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html).

</comment></comment><comment><USER15> on the other hand, nobody built a world-changing global repository of information based on Henry George's principles, so as much I dislike her, empirically speaking Ayn Rand has that going for her.

<comment><USER16> Ayn Rand's principles invented the internet? Someone should write the history of how all those government-funded research institutes weren't really involved.

<comment><USER17> From government research to the Great Depression, the only way libertarian economics escapes unscathed is by ignorance of history.

<comment><USER15> if you didn't know that wikipedia was created after Randian principles, then it is you who is ignorant.</comment></comment></comment></comment>


Horses for courses: choosing Scala or Clojure - <AUTHOR> http://rrees.me/2013/03/19/horses-for-courses-choosing-scala-or-clojure <comment><USER2> I like compile time / IDE type checking, so I'm a Scala user.

But Rich Hickey is such an amazing guy, steering Clojure, with pragmatic solutions catering to developers while Scala often feels like an exercise in academic language development.

<comment><USER3> As long as you are hero worshiping, Martin Odersky is an amazing guy also who is quite focused on pragmatic Scala. Ya, scala has lots of features and it does attract more academics, but there is nothing really flimsy ivory tower about it.

<comment><USER2> After 5yrs of Scala usage, I'm sorry to disagree. Martin might be a very clever guy, but Scala is not catered towards developers but language enthusiasts. From my personal point of view, and everyone else might disagree, it's very slow to compile, has complicated error messages, the API is implemented to be powerful not towards easiness of use etc.

<comment><USER3> I know Martin, I worked for him 5 years ago. He is like a "hacker's hacker" who deeply understands "programming." Perhaps this doesn't translate very well into "developing," and Scala is a great language for "programmers."

We can argue about the trade offs he made, I think Scala represents a reasonable point in the language design space: its not for everyone, but a lot of people like it a lot; it is probably more popular than Clojure (though LISP'ers tend to be more vocal in general).

It is definitely not a programming language for language enthusiasts, who tend to be more picky than programmers and developers and usually have their personal esoteric favorites.

<comment><USER2> He might be understanding programming, but from an academic background not from managing large business development projects with issues like compilers, tool chains, on-boarding of new team members, turn over, business pressure to cut corners etc. Scala has very different priorities. The top priority of Scala is "power", language features and the holy grail of marrying FP and OO. The priority of Clojure is solve problems.

Case in point: The lacking Scala API with a high percentage of method calls not described, not explained and rarely any descriptions of classes. Second case in point: In 2013 Scala is still abysmal slow (several seconds for some classes) when compiling (with SBT compile/JRebel reload or with Play compile/reload).

PS: Side note: Not to sound arrogant, but for the perception and spread of the language it is not important what Martin thinks, but in customer development style what my perception as the CTO of a company thinks that might decide between Scala and Clojure.

<comment><USER3> And you think Eich, Matz, Guido, Gosling, Pike, Ritchie, Wall, Kay, Wadler, Steele, Gabriel, Anders, Syme, Roberto, Stroustrup all understood the role of programming language in business development projects, whereas Martin didn't? All successful programming languages are designed by people passionate about programming, not software development! The people passionate about software development give us crap like UML. Maybe there is something special and different about Rich Hickey's background that he gave you a language that you prefer, but I'm guess its just a different background driving him to make different trade offs that suit you better than other trade offs that could have been made.

Part of the problem you are probably hitting is Scala's attempt to be statically typed while also being flexible, not really its attempt at marrying OO and FP; this tends to require lots of advanced typing concepts that many people are not yet comfortable with, and perhaps they never will be. Dynamic languages save a lot by pooing away the static type system; but of course there is then a lot they can't provide. I am a big critique of this also, we've had our disagreements, but really...at the end of the day it was a design decision made that is no less valid than other design decisions that could have been made.

So don't use Scala if it doesn't suit you, this is reasonable, your criticisms are reasonable, but I don't think it is fair at all to say that the designer was stupid or somehow misguided. There are more CTOs who are misguided than successful language designers.

</comment></comment></comment></comment></comment></comment><comment><USER4> I think the major error in this piece is assuming that Clojure is really geared towards any one type of problem. Instead, Clojure is designed to give you a set of tools that you can freely combine for the problem at hand. It achieves this by separating concepts that are commingled in other languages, like identity, value, and type.

By splitting out those concepts, you get a very solid foundation on which you can build pretty much any other paradigm.

</comment><comment><USER5> _If you are going to work with concurrency ... I think you definitely want to be using Clojure._

Is it widely accepted that Clojure is better for concurrency? [1] I haven't used Clojure much, so I can't comment on their relative merits. But, I've played with actors in Scala some, and done a bit with STM, and they make concurrency relatively straightforward. It's plausible that Clojure has a better concurrency story (and this blog post has inspired me to try it out) but, concurrency is easy enough in Scala that I don't think of it as a weakness of the language, the way I would with something like C.

[1] This is not a rhetorical question.

<comment><USER6> Clojure uses STM and has persistant datastructures by default. This makes it pretty safe when it comes to concurrency. Clojure also has good support for paralellism through pmap and reducers. Making something run in paralell is often just changing the name of a function or importing a diffrent namespace.

I don't know Scala that well, but actors in scala still shares state, and doesn't give the same level of protection when it comes to changing state. Actors also introduce some overhead in case you just want to read a single variable from a datastructure safely. You have to send a command and receive a message, wheras in clojure you just retrieve the value you want. Actors however are, to my knowledge, easier to scale across machines as actors doesn't necessarily have to be in the same process, or even on the same machine.

<comment><USER7> Over the years Scala has adopted some of the concurrency primitives from clojure, now I think if you compare the two there isn't much of a difference between them, however when you start to add in third party libraries I think Scala is actually pulling ahead of clojure. With Akka not only does it do single node concurrency well it also does multinode concurrency with two or three extra lines of code.

<comment><USER6> Well, when you add in third-party libraries, Clojure can use these too.

I wasn't aware Scala had incorporated Clojuires STM, I thought Scala was married to Actors/Akka?

<comment><USER7> Akka has implementations of STM, and a few other niceties from Clojure land.

Also your right Clojure can use Akka just like scala so neither is any better for it, but scala can call native clojure code too. What I have found Awesome is that I can work on a scala project or library and hand it off to my co worker who is a clojure guy and he can incorporate it.

</comment></comment></comment></comment></comment><comment><USER8> For those of you who don't know of Robert, he works for Guardian, writes a lot of Scala and is one of founders of the London Clojure group. Indeed, he's talking about Riemann on Tuesday @ SkillsMatter.

</comment><comment><USER9> I didn't find that comparison very useful/accurate (having used clojure heavily for a year or two and scala full-time for the past month). The main differences I find are:

When evaluating language tradeoffs the scala community values power more and the clojure community values simplicity more.

Scala wants to provide you with the most powerful language possible. Clojure wants to make it easy for you to mold your own language.

Scala language tooling works at compile-time and analyses the language statically. Clojure language tooling connects to a running environment and uses introspection. Scala has much better static checking and clojure has much better introspection. While both languages have a repl, the clojure community puts much more emphasis on live, interactive programming.

Clojures syntactic extension mechanisms are much simpler, being based on sexps. Scalas are powerful (eg can access the lexical environment) but much more heavy-weight.

Clojure has run-time eval. This makes it possible to do eg domain-specific jit (eg compiling DSLs -> clojure code -> java bytecode on the fly). Scala has a run-time interpreter which I haven't used but is reputed to be slow.

I haven't yet explored non-jvm backends for scala but I suspect that clojure will eventually dominate on that front for two reasons: 1) when clojure-in- clojure is finished porting clojure to a new platform will be far easier than scala and 2) clojure was designed from the beginning to be a parasitic language and delegates many features to the underlying platform.

Scala breaks backwards compatibility much more often than clojure. Whether this is a pro or con is up for debate. There are lots of small niggling things in clojure I would like to change but on the other hand maintaining scala code across compiler updates is a pain in the ass.

Personally, I believe that the number one problem a language needs to address is managing complexity. The clojure community largely seems to get that and is driving for simple, orthogonal language features and libraries to an extent that I've not seen in any other community (eg [http://blog.getprismatic.com/blog/2012/10/1/prismatics- graph...](http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at- strange-loop.html)). In addition, the most exciting research I've seen on that front (eg [http://www.vpri.org/pdf/tr2011004_steps11.pdf](http://www.vpri.org/pdf/tr2011004_steps11.pdf) [http://boom.cs.berkeley.edu/](http://boom.cs.berkeley.edu/) ) and most of my favorite tools rely on powerful introspection and runtime code generation. I think Yegge describes this better than I can - [http://steve- yegge.blogspot.co.uk/2007/01/pinocchio-problem....](http://steve- yegge.blogspot.co.uk/2007/01/pinocchio-problem.html)

<comment><USER2> After 5yrs of Scala usage, "but on the other hand maintaining scala code across compiler updates is a pain in the ass." this is really a pain, especially if you come from Java where probably 15yrs old code still runs. I would no longer go with Scala for a new project but give Clojure a try.

<comment><USER10>
        Q: What does java.lang.NoSuchMethodError:
           clojure.lang.RestFn.<init>(I)V mean?
        A: It means you have some code that was AOT
           (ahead-of-time) compiled with a different
           version of Clojure than the one you're
           currently using. If it persists after
           running lein clean then it is a problem
           with your dependencies. Note that for
           your own project that AOT compilation in
           Clojure is much less important than it
           is in other languages. There are a few
           language-level features that must be
           AOT-compiled to work, generally for
           Java interop. If you are not using any
           of these features, you should not
           AOT-compile your project if other
           projects may depend upon it.

[https://github.com/technomancy/leiningen/blob/stable/doc/FAQ...](https://github.com/technomancy/leiningen/blob/stable/doc/FAQ.mdhttps://github.com/technomancy/leiningen/blob/stable/doc/FAQ.md)

<comment><USER9> I've never even seen AOT compiled code. If it becomes common (maybe in proprietary projects?) then I would argee that its important to maintain binary compatability.

<comment><USER10> I just wanted to highlight how bizarre this discussion has become in general (nothing against you, it seems to be a common theme):

        """
        I'm unhappy with Scala's compatibility guarantees,
        therefore I'll pick a language which

        a) does not provide any binary compatibility guarantees
           at all,
        b) has no tool to figure out whether incompatible
           changes have actually happened,
        c) lacks any sort of guidance to figure out if library
           A is compatible with library B short of downloading
           and executing them together,
        d) provides no clean way to cross-compile libraries
           against multiple versions.

        But hey, let's bash Scala for caring about these issues
        and deride them for shipping actual, working
        solutions addressing those issues.
        """

Scala guarantees:

        - Source compatibility between major versions
        - Source and binary compatibility (both backward and
          forward) for all minor and update releases of that
          major version

People will have a hard time to find another modern language which gives them these guarantees.

Hypocrisy and cognitive dissonance FTW, I guess.

<comment><USER9> I was not 'bashing' scala. I discussed the tradeoff between removing old cruft from the language and breaking old crufty code. I was careful throughout that entire comment to only discuss differences between the languages and communites and not make or imply any value judgement. I'm trying to provide useful information for people deciding between scala and clojure, not start a fight.

With regards to binary compatibility, what I think you are missing is that clojure libraries are almost always distributed as source code. The clojure compiler is fast enough to just compile everything at runtime (during development at least) and clojure has not broken source / api compatibility since the first major version. Where AOT compilation is useful is:

a) Improving _application_ startup time

b) Shipping libraries which generate java classes at compile-time (usually to

c) Shipping proprietary libraries without source code

I would definitely like to see the community figure out binary compatibility between libraries to improve cases b and c but it's really not a pressing concern.

EDIT: On AOT compilation [http://dev.clojure.org/pages/viewpage.action?pageId=1572898](http://dev.clojure.org/pages/viewpage.action?pageId=1572898)

<comment><USER10> Fair enough, as mentioned, it was not targeted at you. Sorry if I didn't make that clear enough. I was mainly summarizing my impression of the (sad) current standard of debate in interested circles.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Whilst I understand that you can have good reasons for want to integrate to the libraries he mentions, I can't help feeling that Hibernate is a library that solves a problem caused by the type system, so just using a dynamic language and forgetting Hibernate strikes me as a good approach. Indeed, all the libraries listed look avoidable.

<comment><USER11> > Indeed, all the libraries listed look avoidable.

Not on an enterprise context, like it or not, most consulting projects on the enterprise world require interaction with them.

<comment><USER12> Is that the IT equivalent of legally requiring a man with a red flag to run sixty yards ahead of the car?

</comment></comment></comment><comment><USER13> what is meant by "multi-core concurrency"? Isn't that just paralellism?

<comment><USER6> Paralellism is about using multiple cores to speed up a certain operation. Cuncurrency is about doing many things at once.

Multi-core concurrency means that your concurrent operations can happen at the same time and thus corrupt shared state.

<comment><USER12> I think the notion of operation serializability is important in this context. From what I understand, in the broadest possible strokes, "concurrency" means "it doesn't matter in what order the sequence of operations happens and how their execution is reshuffled as long as the dependency invariants are maintained".

</comment></comment></comment><comment><USER14> When it comes to more or less large and real world systems - I really can't imagine how one can work with dynamically typed languages.

<comment><USER6> Why? Static languages ensure type safety (which are uncovered in unit tests anyway) and to ensure this type safety, they need more information from you, the developer. Clojure allows you to write less code which, depending on who you talk to, equals faster development time.

Static languages are also usually faster, so I guess the tradeoff stands between raw performance and code size.

There are numerous succesfull projects using dynamic languages. Github, as far as I know, uses Ruby.

<comment><USER14> Yes, but when it comes to reading/understanding and refactoring/modifying code - this is where things get complicated.

<comment><USER6> Never really had any problems reading/understanding dynamic code, actually I (and this is highly subjective) think it's easier to read dynamic code because you don't need to read a lot of extra code written to satisfy a compiler.

I agree completely when it comes to refactoring/modifying code though. This can become cumbersome, especially if you don't have unit tests.

<comment><USER14> Well, what you call an extra code to help to satisfy a compile, I call a part of a documentation which helps understanding the code, in addition with some static integrity checking :)

<comment><USER6> I understand the argument. In my experience though, documentation and/or tests usually always makes type info redundant. But I'm well aware that people have different views on this. Each to his own.

</comment></comment></comment></comment></comment></comment><comment><USER10> I'm no Clojure expert, but listening to the Scala parts was like "Ok, I might disagree, but one can claim that ... WOW, that's factually wrong ... _nod_ ... this is pretty misleading the way it is described ... ok, this sounds reasonable ... no, that's just wrong".

Can a Clojure expert comment on whether the Clojure part is as wrong/inaccurate as the Scala part?</comment>


NASA unveils new spacesuit for next Moon landing - <AUTHOR> https://www.bbc.com/news/science-environment-50070615 <comment><USER2> > Mr Gohmert explained: "We can take safe haven in this suit, we'll seek > refuge in here, we'll keep the body at 8 psi (pound force per square inch) > for a certain period of time, then we'll drop down to 4.3 psi and we can > remain there for six days."

> "That's no small feat to be able to live in a volume that's only a couple of > inches bigger than your body for six whole days."

This means one can expect to expel solids and fluids while in this suit, and perhaps take in nutrients, if one is "stuck" in this suit due to emergencies?

Why don't they show the insides of the suit? How long does it take to put on? What technology is inside of it?

It's kind of pointless just to show the colors of the suit and someone bending down to pick up rock (albeit I realize this is an accomplishment from prior suits... but I cannot appreciate the work to make that happen).

<comment><USER3> The idea of not being able to scratch my nose for six days is horrifying.

<comment><USER4> I remember hearing a story about some fluid getting in the eye of an astronaut working on the exterior of the ISS, and them not being able to wipe it away due to the helmet, so just continuing while in pain / discomfort.

Perhaps spacesuits could do with some kind of manipulable swab within the helmet to deal with situations like this.

<comment><USER2> Chris Hadfield [0] seek to ~ 11m30

[0] [https://www.ted.com/talks/chris_hadfield_what_i_learned_from...](https://www.ted.com/talks/chris_hadfield_what_i_learned_from_going_blind_in_space)

</comment></comment></comment></comment><comment><USER5> > The suit has a 100% oxygen environment

That can't be right, can it?

[edit] Ok - I guess under low pressure it's not toxic. But if the pressure is adjusted so that 100% has the effect of 21% O2 on the system, wouldn't the volume of gas be much less, making it a larger effort to breath?

<comment><USER5> On an related personal anecdote -- if you ever want to feel what's it's like to open your mouth in a vacuum and get a taste of what it would be like to do so in space (save the lack of any heat) you can always do what I did by accident as a kid: Swim in a pool that has a flexible plastic (in this case, a thin-bubble wrap sort of material) sheet floating over half of the pool, swim under part of the covered area, and then stand up out of the water. The sheet will lift up, but there will be no air whatsoever. Open your mouth, and find all of the air in your lungs immediately sucked out with no way to take a breath -- pretty horrifying if you're not expecting it...

</comment></comment><comment><USER6> this looks even more ridiculous than the 60s version</comment>