Amazon DocumentDB, with MongoDB compatibility - <AUTHOR> https://aws.amazon.com/documentdb/ <comment><USER3> My bet is that it is built on top of Aurora PostgreSQL. By looking at the "Limits" section ([https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/limits.html)), identifiers are limited to 63 characters and the same characters that PostgreSQL limits identifiers to; and a collection size limit of 32TB, coincidentally maximum PostgreSQL table size.

Edit: I can confirm: does not allow the UTF-8 null character in strings: [https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/functional- differences.html) ... It is written on top of PostgreSQL.

<comment><USER4> It would be nice if Amazon provided an API to access the data via SQL alongside the MongoDB API; I've seen quite a number of organizations migrate from mongo to Postgres once they get out of the rapid development phase. This would make that transition butter smooth.

<comment><USER5> Anecdote:

I led a C# project where we could seamlessly switch back and forth between Mongo and SQL Server without changing the underlying LINQ expressions.

We sent the expressions to the Mongo driver and they got translated to MongoQuery we sent the expressions to Entity Framework and they got translated to Sql Server.

<comment><USER6> C# is ahead of the game with LINQ, expression syntax, and the entire Rosyln platform. Passing an IQueryable<> around that can be interpreted and transformed for multiple backends is a incredibly productive. I wish more people knew about this, and .NET in general.

<comment><USER5> And I've seen a few Java and Javascript libraries that purport to "implement LINQ" and they don't get the power of LINQ is not the syntax, it's that LINQ translates your code to expressions that can be parsed and translated to any back end query - it's not just an ORM.

I've seen a LINQ to REST API provider.

</comment></comment></comment></comment></comment><comment><USER7> I was reading a post [0] by Brian Cantrill that predicted this would be the result of licences like the SSPL. I instinctively disagreed with him, but it turns out he was right: "The cloud services providers are currently reproprietarizing all of computing — they are making their own CPUs for crying out loud! — reimplementing the bits of your software that they need in the name of the service that their customers want (and will pay for!) won't even move the needle in terms of their effort."

[0] [http://dtrace.org/blogs/bmc/2018/12/14/open-source- confronts...](http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts- its-midlife-crisis/)

<comment><USER8> What is the way out? Would love to hear from people.

<comment><USER9> Ultimately, Cantrill put it well:

> ...for those open source companies that still harbor magical beliefs, let me > put this to you as directly as possible: cloud services providers are > emphatically not going to license your proprietary software. I mean, you > knew that, right?

MongoDB Inc cannot make Amazon pay commercial license fees. That is not a thing that will happen. They have a lever in front of them with two positions, one of which is "large cloud companies might use your software for free", and the other is "large cloud companies will not use your software at all". They didn't like the first option, so they gave the lever a yank, but they're not going to like the second option, and there is no third option.

The way out is not to try and build a business on the assumption that people who have no interest, requirement or reason to give you large amounts of money will inexplicably do so anyhow. :)

This thread already has people eyeing up DocumentDB's pricing and comparing it favourably to MongoDB's competing Atlas service, and it's almost unthinkable to suggest that Atlas can compete on price _with Amazon_. The way to win this game is not to play; the rules are not in your favour.

<comment><USER10> Could Mongo or other companies use the Oracle v. Google precedent regarding API copyright to extract money from competitive vultures like Amazon?

<comment><USER11> Oracle are the good guys in this scenario?

<comment><USER12> They always were the OK guys in that argument. Google invented a whole new VM and bastardized the language just to get out of a $1/device licensing fee for mobile uses. The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java.

On another note, anyone that doesn't think API design is a creative endeavor and worthy of protection probably has never made a great API before. It may be OK to accept that and also let other people use the API for free but I think ruling that it isn't is BS.

<comment><USER13> I also always found it amusing that people thought API design was not creative and protectable.

Like, "how many ways can you do a date api", and then turn around to look at the original java Date api, the Calendar api, JodaTime and JSR310.

<comment><USER14> An API is just a collection of facts of the form, "if the system gets input X, the system produces output Y". And facts shouldn't be copyrightable.

<comment><USER15> You could describe inventions as "facts" too, are you saying that inventions shouldn't be patentable as well?

Maybe the fundamental properties of the universe aren't copyrightable/trademarkable/patentable, but what you CHOOSE to do with those - what API you design or what widget you build out of it certainly is.

<comment><USER14> Patents and copyrights are two very different things, though. I don't know if APIs are patentable, but that's a very different question. Has anybody ever successfully patented an API?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Now I kinda hope Oracle decides to buy out MongoDB and integrate it into their own cloud. Then Oracle can decide to pull the same bullshit that they did with Google over the Java APIs with the MongoDB APIs but now against their current enemy Amazon (and Microsoft, too).

Then a combined Google + Amazon + Microsoft may finally be able to reverse the API Copyright insanity that is hovering ominously over the tech industry, and Oracle can continue to be a shining city upon a hill of shitty technologies you should never allow your business to adopt.

<comment><USER17> AWS is preemptively defensive about API licensing claims: "Amazon DocumentDB implements the Apache 2.0 open source MongoDB 3.6 API".

<comment><USER18> I think they are referencing the drivers which are licensed under Apache 2.0.

</comment></comment></comment><comment><USER19> I don't understand why people are reacting to it so aggressively. That's basically how AWS works, they did the same to Apach Kafka with Kinesis, Prestodb with Athena, PostgreSQL and MySQL with Aurora, Redis with ElastiCache and many others over the last 4 years so it's not new.

It took too long for the open-source community to figure out that the cloud providers are killing them, now it's too late. Well played, AWS.

<comment><USER20> > It took too long for the open-source community to figure out that the cloud > providers are killing them

How are service providers killing FOSS? That doesn't make sense. Permissive FOSS licensing allows anyone to use their software, regardless of how it's used, and that's how it should be.

<comment><USER21> Do you get to see AWS's source code for these services?

No...

That's how it's killing "FOSS". Extend and Extinguish. This is not a new playbook.

<comment><USER22> I don't think you get to see MongoDB's source code for the enterprise edition either (though I couldn't quickly verify on Google).

<comment><USER21> Of course they provide source! Source rpms and tgz are downloadable.

Enterprise isn't gpl, but source is provided.

(This could have been easily answered with a google search, as you pointed out)

<comment><USER22> No, I meant that I did search it on Google, and couldn't easily see from the results which case it is. Google "mongodb enterprise source code" \-- which one answers the question?

If it were so easy, you could have provided the citation yourself in that comment.

</comment></comment></comment></comment></comment></comment><comment><USER23> If I'm reading the pricing page correctly, DocumentDB would run a _minimum_ of $200/month. That's for the smallest instance and no storage or I/O. Kind of steep if you ask me.

<comment><USER24> Besides that AWS will charge per transaction (at 0.2 per million) outrageous given that you already pay per instance.

Correct pricing strategy needs to be per request or per instance, AWS is charging for both

<comment><USER25> The correct pricing strategy of any product is "whatever the customer is willing to pay for it". If you feel the price is too steep for your use-case, then don't buy it.

<comment><USER26> That's rarely actually true for anyone that wants to operate for more than a short time period. There are significant costs to gouging your customers. Anything from it being illegal, to it encouraging competition and your customers being motivated to actively flee you and shit on your reputation. The correct pricing strategy for people that don't have a long term enforceable monopoly is "whatever most customers are willing to reasonably happily pay"

<comment><USER27> I think you've hit on what always bothers me about this sentiment. It is obvious that at any point in time you can charge the maximum customers are willing to pay, but that allows for disruption through the channels like competition. The opposite where you charge the minimum to continue providing the goods or services seems optimal, though, leads to a company with zero profits that is unattractive to investment. Is there any literature on how to identify the optimal point of "whatever customers are willing to reasonably happily pay"? Businesses successfully exist on many points in the spectrum of zero profits to most profits the market will bear, but I'd be interested in anything discussing optimality.

[Edit] Amazon employee working in Physical Consumer (not AWS). Asking out of personal curiosity.

<comment><USER26> I'm not an economist, and can't point to to anything in particular, but I would be skeptical of anything that claimed a general approach to that. "Optimal" depends entirely on what you're optimizing for, which is basically an infinite possibility space. I could need a significant amount of revenue immediately to accomplish a desired business development, or I could have plenty of cash and want to build a large and loyal long term customer base at the cost of immediate profit. As you say, successful businesses exist doing pretty much everything. The only limiting factor is being a viable ongoing concern (and that can just mean having a rich backer). I'm sure there are things discussing optimizing based on small slices of the possibility space though (but all the normal caveats about economists making dumb assumptions that rarely apply to humans apply even to those).

</comment></comment></comment></comment></comment></comment><comment> vaer-k Finally an AWS service where the name makes sense and describes what it is. I hope this is the start of a trend.

<comment><USER28> I love Azure for this. The names are almost all extremely straightforward. There are a handful that have made the jump from confusing to straight forward, and a handful that have made the jump from straightforward to confusing (CosmosDB, formerly DocumentDB, chiefly comes to mind).

<comment><USER29> Agreed. Too bad the Azure portal is the polar opposite. AWS, for all its faults, is mostly just a boring HTML portal but it works.

Azure tried to get fancy, with side sliding panels all over the place, and it is barely useable. The nicest thing I can say is it is "quirky." It isn't really productive however, particularly not on my 1080p monitor at Windows 10's default 125% DPI.

I literally quit Azure's Application Insights and went back to Google Analytics simply because I hated the Azure UI with a burning passion of a thousand suns.

The concept of writing queries is good, but if that's the only way you can get at your data you better make it damn easy, and they didn't. I'm sure for full time data pros it is a dream however.

<comment><USER30> Azure Portal feels like if someone tried to make the Xbox 360 blade interface into an admin tool, without first asking the admins what they needed.

</comment></comment></comment></comment><comment><USER31> Looking through the supported APIs ([https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo- apis.html)), it appears DocumentDB has no support for Mongo's oplog ([https://docs.mongodb.com/manual/core/replica-set- oplog/](https://docs.mongodb.com/manual/core/replica-set-oplog/)), or change streams ([https://docs.mongodb.com/manual/changeStreams](https://docs.mongodb.com/manual/changeStreams)), which I guess is no surprise because change streams were introduced in Mongo 4, whereas DocumentDB copied the 3.6 API. So DocumentDB seems much less useful as a reactive data store than MongoDB.

In other words, DocumentDB is only a drop-in replacement for MongoDB if you weren't using any of the features Amazon decided not to support.

Happy to be corrected if I'm misreading the documentation!

<comment><USER32> Also the aggregation pipeline is seriously hobbled with way more No-s than Yes-es over here [https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo- apis-aggregation-pipeline.html)

</comment></comment><comment><USER33> Weird question: Could Microsoft sue Amazon here for infringing on the DocumentDB name? I mean Microsoft's DocumentDB was among the first to even have such a MongoDB layer also) and that was like 3 years ago.

Given that current Amazon leaders actually came from Microsoft's data platform group this leaves a bit of a bad taste behind.

I'm not working for either company.

<comment> jon-wood My assumption is that DocumentDB falls into a category of being so generic you can't trademark it, or otherwise claim exclusivity to it. Its literally just describing the fact this is a database for documents.

<comment><USER34> Bear in mind we're talking about the company that trademarked "Word" and "Excel" here.

</comment></comment></comment><comment><USER35> Sounds like this runs on the same storage service as Aurora.

<comment><USER35> Not sure why I'm getting downvoted. The characteristics sound exactly like Aurora.

\- "replicates six copies of your data across three AWS Availability Zones (AZs)" [0]

\- "Amazon DocumentDB uses a distributed, fault-tolerant, self-healing storage system that auto-scales up to 64 TB per database cluster." [0]

\- "When writing to storage, Amazon DocumentDB only persists a write-ahead logs, and does not need to write full buffer page syncs." [1]

[0] [https://aws.amazon.com/documentdb/](https://aws.amazon.com/documentdb/)

[1] [https://aws.amazon.com/documentdb/faqs/](https://aws.amazon.com/documentdb/faqs/)

<comment><USER36> Yeah, downvoting is totally broken on Hacker News. Seems like anything that isn't immediately agreed-with gets downvoted. I don't know where all the small-minded people come from, but they seem to have found their home here.

<comment><USER37> There is just some random noise. It might just have gotten one downvote. Now it's the top-comment.

</comment></comment></comment></comment><comment><USER38> I'm pretty sure this is going to kill Mongo as a company dead. With this in existence there's literally no reason to use Atlas.

If they wanted to twist the knife they should get to work implementing a pass through migration option.

<comment><USER39> Have you heard of Amazon Elasticsearch Service, launched in 2015? Elastic is doing fine.

<comment><USER5> Elastic Co isn't profitable by definition it isn't "doing fine".

From their SEC filing:

[https://www.sec.gov/Archives/edgar/data/1707753/000119312518...](https://www.sec.gov/Archives/edgar/data/1707753/000119312518266861/d588632ds1.htm)

 _We have a history of losses and may not be able to achieve profitability or positive cash flows on a consistent basis. If we cannot achieve profitability or positive cash flows, our business, financial condition, and results of operations may suffer._

<comment><USER39> You're right they're not profitable — and neither is MongoDB — but the point is that AWS launched an Elasticsearch service 3 years prior to Elastic having a very successful IPO supported by stellar metrics (also found in the SEC filing you linked). So the statements made at the beginning of this thread are probably a bit premature.

<comment><USER5> Only in tech do people think that a money losing company is "successful" because they were able to convince investors to buy stock instead of defining success as having a business model where income is greater than expenses.

In reality long term profitability is the only metric that matters for a corporation

<comment><USER40> And in contrast to these startups with their "success" AWS is printing cash for amazon which releases surprisingly few "metrics" beyond $ in and $ out.

<comment><USER5> And at the end of the day. What else matters when measuring whether a profit seeking corporation is successful?

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> Dj from MongoDB here. We have, obviously, been keeping up with this and other threads, but we've also been busy testing out Amazon DocumentDB's correctness and performance. While we're getting that together to bring you an official response in a few days, complete with test results and methodology, I'd like to pick up on a couple of points and some inaccuracies that have been repeated in various threads:

This move shows MongoDB's approach to document databases is compelling. We've thought so for a long time.

A cloud-hosted, truly global and managed MongoDB, MongoDB Atlas, has existed for the last two and a half years and has been serving more and more satisfied users every day with some massive workloads.

MongoDB Atlas runs the full implementation of MongoDB in the cloud.

Many features of MongoDB are documented as not being implemented by DocumentDB: these include change streams, many aggregation operators including $lookup and $graphlookup. But beyond that, well let's just say we've been staggered by how many tests DocumentDB has failed (no spoilers!).

The MongoDB API is not under an Apache license.

MongoDB drivers are still under the Apache license. The MongoDB server used to be licensed under AGPL and is now licensed under SSPL. The source code is open to all, as it has always been, at [https://github.com/mongodb/mongo](https://github.com/mongodb/mongo)

DocumentDB is not cheaper than MongoDB Atlas. Preliminary estimates show this to only be the case with very large collections and very, very high read/write workloads.

There'll be more next week over on the MongoDB blogs.

Dj

<comment><USER42> Any idea when Atlas will expand support for Sharding configurations and taggable zones? My impression is Atlas ONLY supports a 2 field shard, and the first shard MUST be location. Also it's impossible for clients to set write- concern to tags, because you don't support custom tags as MongoDB itself does.

</comment></comment><comment><USER21> The current biggest threat to Free and Open Source software is cloud computing. Plain and simple.[0]

I know this is a blunt and harsh statement to make, but when you sell a service, you have zero native incentives to Open Source the way your system works. It just opens up Competition. This is not unique to AWS/Amazon. But their success gives them the power to have wide OSS damage.

This is, to me, the biggest reason why cloud portability should be something that every customer of a cloud service should have in their plans. Amazon as a company has shown no timidness in both "embracing, extending, extinguishing" their competition.

OSS literally built the internet and opened up the wold wild communication age, let's not be so short sighted that we don't see proliferation of cloud services ( specifically one having so much dominance), for what it really is.

[0] [http://dtrace.org/blogs/bmc/2018/12/14/open-source- confronts...](http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts- its-midlife-crisis/)

<comment><USER22> Cloud computing was arguably an outgrowth of inability to prevent piracy and everyone being encouraged to open source everything.

<comment><USER21> No, it was an outgrowth of infrastructure work being a niche trade, and capacity management by startups ( and mature companies), being a hard task.

This point is well known, and pretty much in every cloud providers marketing material.

<comment><USER22> So, even though it's impossible to prevent piracy, effectively forcing you to hide the code behind an internet API, the real reason to do so is something else, as proven by marketing literature?

If I could re-engineer MongoDB so that a monkey could administer, you'd recommend I still use the cloud model rather than sell binaries?

</comment></comment></comment></comment><comment><USER43> Why is it so expensive? Not only is the entry point $200/m, the instances are twice the price of their EC2 equivalents. (At first I thought perhaps the price included multi-AZ, but it doesn't.)

</comment><comment><USER44> Seems like this is likely to be the real result of licenses like the SSPL. Not even a terrible outcome if the different implementations remain relatively compatible.

<comment><USER17> SSPL style licenses only work if the software can't be cloned but that's a difficult assumption.

<comment><USER45> Operating systems, compilers, and web browsers come to mind. There are currently:

* 4 independently-developed competitive compilers (gcc, clang, msvc, icc)

* 4 independently-developed competitive operating systems (windows, macos, linux, and bsd --I'm grouping the BSDs as one since their source code has a common ancestor)

* 3 independently-developed competitive browser engines, soon-to-be 2 (edgehtml, gecko, webkit)

And it's been that way for a few decades now; doesn't look like anyone is interested in taking the resources to make another one of those.

<comment><USER46> Throwing Chrome/Blink under WebKit is a pretty hard sell at this point. They've diverged enough that supporting one far from guarantees you'll support the other. You might as well replace WebKit with KHTML in your list.

<comment><USER45> For the purposes of licensing and simple inertia (what it takes to start a project from scratch) -- that work was done once, with khtml, sure.

</comment></comment></comment></comment></comment><comment><USER6> So now AWS DocumentDB, Azure CosmosDB, and even Apple's FoundationDB have a MongoDB compatible API. I expect other multimodal databases to offer the same soon enough.

Strange turn of events for MongoDB but I guess that's what happens when the interface is open and anyone can build a backend to it, especially a relatively simple document-store.

<comment><USER47> And when they have a restrictive license.

</comment></comment><comment><USER48> I really wish this were priced more along the lines of [https://www.compose.com/pricing](https://www.compose.com/pricing) \- a $200/m floor is a tough dB cost to absorb on smaller yet important projects. Suppose an app has a few mb of data and maybe one day hits 100mb of awesomeness I really have to pay $200/m here?

I get it, I love Aws, just wish this was priced differently.

<comment><USER49> If you need a cheap/free document store for a small app, just use DynamoDB. It's free (forever, not just the first year) up to 25GB of storage and enough read/write capacity units to handle up to 200M requests per month: [https://aws.amazon.com/free/?awsf.Free%20Tier%20Types=catego...](https://aws.amazon.com/free/?awsf.Free%20Tier%20Types=categories%23alwaysfree)

<comment><USER40> Exactly, this probably isn't targeting you. A few mb of data? Host an instance? Use sqlite? Atlas can run 3-5k/month as the minimum. This is going to be 10x cheaper (which amazon seems to try and shoot for).

</comment></comment></comment><comment><USER50> seems an obvious response to [https://www.mongodb.com/press/mongodb-issues- new-server-side...](https://www.mongodb.com/press/mongodb-issues-new-server- side-public-license-for-mongodb-community-server)

<comment><USER51> Azure has been running a Mongo-compliant DB under their Cosmos umbrella for quite a while. It's not clear to me that either Azure or AWS are actually running Mongo software under the hood or rather a proprietary DB that uses the Mongo wire protocol.

[https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb- int...](https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-introduction)

<comment><USER52> Doesn't Azure also have a not-Mongo service also called DocumentDB? Is this the same code? These cloud services are confusing enough when they don't borrow each other's names.

<comment><USER53> The Azure service formerly known as DocumentDB is now called Cosmos DB. Part of that switch was introducing multiple APIs, including a MongoDB API: [https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb- int...](https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-introduction)

</comment></comment></comment></comment><comment><USER54> I really wish this was serverless. Azure CosmosDB offers SQL and MariaDB interface against a serverless, pay for what you use database and DynamoDB is the only product of that class Amazon has. Even Aurora "serverless" appears to be little more than autoscale, and it requires an elastic IP which slows launch of lambdas since they have to connect to VPC.

<comment><USER55> > it requires an elastic IP which slows launch of lambdas since they have to > connect to VPC

Do you have any other info/links related to this?

<comment><USER56> There's an enlightening graph in this post:

[https://medium.freecodecamp.org/lambda-vpc-cold-starts-a- lat...](https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-latency- killer-5408323278dd)

I was surprised to learn this. When working in Lambda, you have to choose between a relational database & a responsive API. It seems inevitable that AWS will fix this soon, but apparently this is a significant architectural problem. As I understand it, RDS instances should (must?) be accessed from within a VPC, and anything inside of a VPC needs an IP address, so the Lambda function has to wait ~10 seconds on cold-start for the Elastic IP service.

The only workaround I've heard of is to setup a service, such as CloudWatch, to call your Lambda function every ~25 secs to keep it "warm", but this seems anti-thetical to the value proposition of serverless architecture in the first place.

Of course, you could "just" use DyanmoDB, but IMO the query language is really limited, and I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?)

<comment><USER57> > I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be > accessed from within a VPC?)

This is due to the fact that DynamoDB's query API is a standard AWS API which means granular internal/external access can be provided through IAM mechanisms (ie: roles, temporary tokens, federation, etc.).

On the contrary, to access RDS, Redshift or DocumentDB you would use standard ODBC/JDBC/Mongo facilities, which do not rely on IAM mechanisms, leaving VPC/Security Groups as the only isolation option.

<comment><USER58> Not quite. It's not the auth mechanism or even the wire protocol. The issue is to accesS traditional resources in a VPC you need to have an IP address within the VPV to route network traffic to/from it. It'd be the same if you ran a DB on and EC2 instance or even ran your own DynamoDB clone with no auth.

AWS services don't have that issue because they're accessible from anywhere on the network, even through an internet gateway / internal NAT.

<comment><USER57> I think that was my point.

Services with "native" AWS APIs use IAM for granular access management. Other services can only support access restrictions using the network so that means VPC/Security Groups.

</comment></comment></comment></comment></comment></comment><comment><USER59> This looks great for teams getting started in AWS, being able to reuse idioms, libraries and knowledge in managed services to remove some of the operational load.

A note this is also nothing new, Azure Cosmos DB has had this for a while.

</comment><comment><USER60> Serious question: is there any real reason to use Mongo over Elasticsearch?

<comment><USER61> ES grew out of Lucene, which provided an inverted index of all the text in a document, with a bunch of NLP related features bolted onto that. While ostensibly designed to be developer friendly, ES had and still has a horribly hacked together API with bugs and mis-documented misfeatures all over the place. In my experience it's anything but developer friendly. But if all you need is a text index on a document store with a static schema, it does its job reasonably well.

Mongo started as a very developer-friendly data store with lots of overstated claims to being a database. While earlier versions of Mongo were wildly dangerous to use as a business critical database, it has since matured and is now quite good at being a developer-friendly document-centric database. In my experience Mongo truly is developer-friendly as long as you don't try to use it as a full-blown transactional database with lots of complex data shapes and indexes.

I would not trust ES with anything but text search on a document store, and I would not trust Mongo with anything resembling multi-document transactions. With that said, they are both good at specific, different things.

MySQL and Postgres have their own baggage that makes them pretty terrible in some aspects. IMHO a JSON-over-HTTP API should really be table stakes for a database to be considered developer-friendly nowadays. (But please don't butcher HTTP like ES did and then claim to have that.)

<comment><USER62> > IMHO a JSON-over-HTTP API

No no no no, again no.

We don't need yet another shitty query language bolted onto one of the most error prone and annoying to type serialization formats while transmitting data on top of a by default stateless protocol that makes no sense for a database.

I'm sick of it.

SQL. The same queries will work in 95% of the case on any SQL db. There is a driver in almost every language that is robust. There are implementations great for every use case; embedded, scalable, transactional. _That 's_ friendly.

There is nothing wrong with SQL, it's freaking awesome.

<comment><USER61> Sure, keep the SQL. Just make it a field in a JSON POST payload, and send the results back as JSON.

The "drivers in almost every language" suck. They all suck. I've never seen a SQL driver and wire protocol that was not awful in some way. The statefulness is part of what makes them awful. We have better ways to keep track of state now.

<comment><USER63> > I've never seen a SQL driver and wire protocol that was not awful in some > way.

Have you seen the PostgreSQL wire protocol[1]? I recently built a logical replication client driver for a project and found the protocol to be excellent. After looking at the documentation, I'm no longer limited to languages that have drivers for Pg, because I know how easy it'd be for me to just write one.

Just because _some_ SQL drivers and wire protocols are awful (looking at you, Oracle[2]) shouldn't mean one should go running to the hills, let alone to JSON.

\----

1: [https://www.postgresql.org/docs/current/protocol.html](https://www.postgresql.org/docs/current/protocol.html)

2: [https://noss.github.io/2009/04/28/reverse-engineering- oracle...](https://noss.github.io/2009/04/28/reverse-engineering-oracle- protocol.html)

<comment><USER14> An HTTP/JSON protocol doesn't have to replace the standard one. But having such a standard protocol makes sense in the age of web apps, particularly when NoSQL offerings that are perceived by the market as competitors (leaving aside whether they really are - perception matters more here) do that already.

<comment><USER63> > An HTTP/JSON protocol doesn't have to replace the standard one.

So, two protocols? Two _standard_ protocols is rarely better than one.

> having such a standard protocol makes sense in the age of web apps

Only if the existing standard protocol cannot work with the "web", and we have plenty of history proving otherwise. _Replacing_ the existing standard with the loose JSON would be, strictly, a downgrade; and unnecessary, because we already do interoperate JSON and SQL. See: PostgREST and the many REST & GraphQL frontends on PostgreSQL.

> particularly when NoSQL offerings that are perceived by the market as > competitors (leaving aside whether they really are - perception matters more > here) do that already

This is really more of going into a pig's pen and wrestling with them. A database should do the job of a database. Competing for perception in a market that cannot make sane decisions for itself is how we get MongoDB.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> There is a serious amount of weasel words in that statement. Implementing the Apache 2.0 API I think is just weasel words for "Works more or less with the MongoDB drivers" which is the only thing Apache 2.0 licensed that I know off and is obviously not the API which is the combination of the MongoDB wireprotocol and the commands supported by the MongoDB server.

</comment><comment><USER64> Looks good. I used to use both MongoDB and CouchDB (for very different use cases) a lot but haven't touched them in a long while.

<comment><USER65> Out of curiosity, what use cases did you have for CouchDB that weren't feasible with MongoDB?

<comment><USER66> In my case, at least, PouchDB is still a lot handier of an offline-first mobile-capable DB than just about anything else, and because it speaks the CouchDB replication/sync API that still leaves a lot of use cases where CouchDB is more feasible. (It would be great to have more document DBs converge on a replication/sync API for offline-first applications. I've voted on the UserVoice suggestions to CosmosDB on the idea.)

<comment><USER67> Same here. We love how replication is built in to CouchDB from the ground up.

I wish MongoDB, which seems to still have more love for it in the world than CouchDB/Cloudant, would have that replication built-in.

<comment><USER68> Wait... do you mean something other than [https://docs.mongodb.com/manual/replication/](https://docs.mongodb.com/manual/replication/) ?

<comment><USER67> I'm thinking about the use case to have a native app be able to work nicely with no internet connection, but then once the internet connection resumes, it downloads new data from the server and sends its offline-modified data up to the server.

From a quick search online [0] [1], I see people doing offline MongoDB sync using SQLite, but nothing like using Mongo directly. With CouchDB, we can use either the old Couchbase native app SDK, or the Cloudant native app SDK, to sync up nicely with a CouchDB instance in the cloud. We've had this running for awhile, and it works quite well, and we do not have to shuffle information to and from a SQLite database... at least, we're not doing it, since the Cloudant or Couchbase SDKs for iOS and Android keep track of all the data and store it on the mobile device however they'd like.

If there is anything similar for Mongo, I'd be interested to know!

[0] [https://stackoverflow.com/questions/23623295/how-to-make- an-...](https://stackoverflow.com/questions/23623295/how-to-make-an-android- app-work-in-offline-mode-in-android) [1] [https://stackoverflow.com/questions/13295960/sqlite-on- andro...](https://stackoverflow.com/questions/13295960/sqlite-on-android-and- mongodb-with-synchronization)

<comment><USER68> Dunno if this thread is too cold for you to notice my reply, but there absolutely is... MongoDB Mobile was released last year, and along with Stitch, MognoDB's serverless application platform, you can get exactly what you want — mobile sync.

</comment></comment></comment></comment></comment></comment></comment><comment><USER58> Jeff Bezos continues his quest to eat all open lunch boxes.

<comment><USER33> Microsoft was first with a MongoDB layer, like some 3 years ago I think. Nothing novel here from Amazon.

</comment></comment><comment><USER69> While we are on the topic, are there cloud providers out there that provide "hosted FoundationDB as a service"?

And if you are curious, no I don't have any special need or use case for it, just wondering.

</comment><comment><USER65> AWS lacked something like this before, which is why I used MongoDB Atlas (MongoDB's own managed mongo service). How is this different than DynamoDB (other than the obvious API differences)?

<comment><USER70> DynamoDB has specific requirements on how data is partitioned. You have to do upfront planning on how you access your data based on keys.

Mongodb is more flexible in this regard.

I'm sure there's other big differences but this is the biggest to my experience with both.

<comment><USER65> I was asking about DocumentDB, not MongoDB, but maybe I missed something. From their site:

> Amazon DocumentDB implements the Apache 2.0 open source MongoDB 3.6 API by > emulating the responses that a MongoDB client expects from a MongoDB server, > allowing you to use your existing MongoDB drivers and tools with Amazon > DocumentDB

So, is this a "managed MongoDB" or is it a NOSQL AmazonDB that just implements the same API as MongoDB? If the latter, I don't think we can assume this is the same thing as MongoDB, because the internals might be completely different.

<comment><USER71> Sounds like the latter to me, they probably implemented it on top of one of their other DBs.

<comment><USER65> Lmao I was a bit afraid this might be some surface-level API wrapper around DynamoDB, in which case this is less cool than I thought. It doesn't seem to be the case at a first glance but I wish it was a bit more clear on the site exactly how this relates to DynamoDB, if at all.

Maybe I'll just have to read more about it. Hopefully the internal architecture gets away from DynamoDB-style partitioning.

<comment> jon-wood From other comments here it looks like its built on top of Aurora rather than DynamoDB.

<comment><USER71> On the other hand they used MySQL as DynamoDB base, so maybe they will switch DynamoDB to Aurora too?

</comment></comment></comment></comment></comment></comment></comment><comment><USER72> I am pretty frustrated that DB services like Aurora, and now DocumentDB are still limited to last-gen instance types like r4 instead of the latest instances like r5 and t3 which have marked improvements in terms of CPU and networking performance.

I wonder if it is that they just have a so much r4 inventory left that they are forcing us to use it or if they haven't fully integrated/validated the latest instance types with their custom storage backend.

</comment><comment><USER73> How is it better than buying a MongoDb subscription from the AWS marketplace? [https://aws.amazon.com/marketplace/search/results?x=0&y=0&se...](https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=mongodb)

</comment><comment><USER74> Wasn't DocumentDB the old name of Azure Cosmos DB? just marketing wise this seems like a bad choice for a name.

</comment><comment><USER75> I hope AWS realises that harming OSS authors, even indirectly, is counterproductive to AWS' interests.

If Mongo dies, so does its userbase, and so does DocumentDB.

How to fix it classily? Contribute back with code maintenance or whatever customizations were developed in-house.

Also you get to save face - you are not perceived as a leech anymore.

</comment><comment><USER76> I hope MongoDB's users are really keen on on-prem otherwise this might be a challenging moment for them.

<comment><USER77> Not sure what this means.

MongoDB has had Atlas which is a cloud hosted solution for a while now.

<comment><USER47> Poster means that their cloud business could be impacted, but on-prem (non aws) would not be.

</comment></comment></comment><comment><USER78> Is it really THAT hard to to run on prem/cloud because of the "complexity that comes with setting up and managing MongoDB clusters at scale"?

The documentation is strong, it was built with horizontal scalability in mind. I don't see the struggle.

<comment><USER79> Yes. Sharded mongo has many pitfalls that can challenge your devs, dbas and devops people. Mongo api without all the mongo scaling problems is pretty awesome.

<comment><USER80> I must have used a different API, then. Well, obviously not but it could happen because there are more than one ...

I agree with [https://www.linkedin.com/pulse/mongodb-frankenstein- monster-...](https://www.linkedin.com/pulse/mongodb-frankenstein-monster- nosql-databases-john-de-goes/) the contents of this article (and reserve critique for its author). Even the basic query language, in particular $elemMatch is atrocious which has a certain irony to it because Eliot added it when we asked for the functionality ([https://jira.mongodb.org/browse/SERVER-377](https://jira.mongodb.org/browse/SERVER-377)), so long ago. We have been one of their first commercial support clients, my boss needed to pressure them to accept money for support, they didn't want to...

</comment></comment></comment><comment><USER81> I would actually like to thank AWS for focusing on supporting Open APIs. Let the community design the standards and operations and let the vendors compete to implement them, open source included.

</comment><comment><USER82> Atlas is $0.03 per server hour, Amazon starts at $0.277

Do I have that right?

<comment><USER6> Starting prices maybe, but you have to compare hardware and performance capacity, not just flat numbers.

</comment></comment><comment><USER83> Shame there isn't a free tier equivalent. I'd like to try some projects using mongo but $200 a month minimum does not work for Indy projects.

<comment><USER68> Try the free tier on Atlas.

</comment></comment><comment><USER84> Can someone do a comparison on pricing vs Atlas and vs DynamoDB and Amazon's managed postgresql?

</comment><comment><USER85> > Text Index: No

as MS Cosmo DB prior, the compatibility list leaves quite a bit out.

</comment><comment><USER86> Of all possible names they managed to choose already obsolete name for a similar product from Azure?

Azure in 2017: forget DocumentDB, Cosmos DB is the new thing now!

AWS in 2019: We just released DocumentDB!

Are they so geniuses or so idiots?

<comment><USER33> I had the same observation (although I'd reconsider your wording, that's not very polite). It doesn't seem like a good choice in naming - <USER2> because many of the Data Platform folks at Amazon (like their VP) came from Microsoft's data platform group.

</comment></comment><comment><USER87> Is this serverless?

Pricing?

</comment><comment><USER88> I cant use this crap locally?

</comment><comment><USER89> How the heck was this approved by legal? AWS is linking to MongoDB's own documentation.

[https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo- apis.html)

Go to any operation, it links to docs.mongodb.com !

<comment><USER90> Is linking to documentation illegal?

<comment><USER89> The 'legal' department doesn't only vet things that are obviously illegal, they are there for other things too, like EULAs, contracts and intellectual property in general.

In any case, they are implementing the competitor's APIs and the documentation is already licensed as Creative Commons. Can't they at least host their own copy?</comment></comment></comment>


Facebook loses its VR case, has to pay $500M in damages - <AUTHOR> http://www.cnbc.com/2017/02/01/facebook-loses-vr-case.html <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=13544871](https://news.ycombinator.com/item?id=13544871).</comment>


Ask HN: What open source license is appropriate for my project? - <AUTHOR>

Hi guys, I'm thinking of open sourcing my project TextTeaser (http://www.textteaser.com/). What open source license is appropriate for it?<p>TextTeaser is an automatic summarization application and API. The algorithm used to summarize articles was formulated by me for my MS degree. It actually performs good enough. With open sourcing TextTeaser, I'll also release the research paper containing the algorithms implemented in it. <comment><USER2> It depends on what you want for your project:

GPL 2-3: If you want to create a comunity around your code. AGPL: Same as GPL but it can't be used remotely without releasing the source code. BSD: If you want to be flexible enought to let companies to use your code without releasing back the source.

Of course, these are simplifed explanations.

<comment><AUTHOR> Thanks. Really not well versed with those licenses. Right now, I'm leaning to choose MIT. What do you think of it?

<comment><USER2> MIT/BSD is a "safe" choice.

If you see that companies are using your work and not contributing back, you can shift your contributions to GPL in the future.

</comment></comment></comment><comment><USER3> I'm glad to see you're open-sourcing it. I saw your submission some time back and was quite interested in peeking in the source. Thanks!</comment>


Myths about ElementaryOS - <AUTHOR> http://elementaryos.org/journal/5-myths-about-elementary <comment><USER2> As one of the people behind elementary OS, this blog posts pretty much summarises how hard of a time I have when reading online criticism on elementary OS. Feedback is good, we love it and realize how important it is. However, for the most part the complaints are not about the OS itself but instead on some of these myths (or worse even, how we're "just a blatant copy of OS X" when we have our own ideas and identity).

We're working hard on the next release of elementary OS, called Isis, and we hope that it will bring a renewed interest in elementary.

<comment><USER3> First of all great work on Elementary. One thing that doesn't help with the "Copy of OSX" comments is the video on the front page where the desktop uses the Mountain Lion wallpaper.

<comment><USER4> > desktop uses the Mountain Lion wallpaper.

It's not exactly the same as far as I know. You can use another picture of the same Galaxy without it being the same picture. Plus it appears for 5 seconds on the video and not all the time. They are other wallpapers shown in the video.

<comment><USER5> The fact that it needs defending is kind of the point. It looks similar enough to evoke the reaction from most people that it is similar to OS X, which is more than like a goal and not an accident. It may not be the exact image, but it doesn't have to be.

</comment></comment></comment></comment><comment><USER6> It's very impressive that a relatively small team could rewrite huge swathes of userland applications from scratch, and end up with something more polished and lighter-weight than much of the competition.

It seems like the sort of thing which could happen as a matter of course if the money was there from the community to support developers working full-time over the long term on these sorts of projects.

One thing I'd like to see would be elementary experimenting with ways of encouraging people to support development. It really should be a matter of course to donate $20-30 in exchange for something which makes your computer function substantively better, especially when many of the users are IT professionals who earn good salaries. But it doesn't appear to happen, for one reason or another.

Perhaps, open up the books, and give people real-time, kickstarter-like information about the donations as they are ongoing, where the money will be spent, and how much more is needed. I'm sure there must be a way of nudging people to get out their chequebooks.

<comment><USER7> > something more polished

What do you mean by this? IMO the last time I used EOS it was lacking in a lot of areas. This was only a few months ago.

Installation was fast and everything was automated, the install window had a "drop-down" terminal to watch processes, but nothing was there. I expected to be asked to re-size my partitions but never was. When I rebooted I noticed grub was a little borked, showing EOS, EOS recovery, Windows 7, and then about 30 or so entries of old kernels (I know I need to clean these up). It should have showed two more ubuntu OSs installed. I can still boot into my other two installations fine, I just had to do some guess work on what to pick in grub.

So I get into EOS and things are pretty cool, the thing I like best is the speed. Everything seems instant, well except the applications menu, it was a few milliseconds slower than anything else on the DE and that was annoying as I would often end up clicking it a second time causing it to open twice, which was kind of hard on the eyes. Coming from a Gnome 3 environment, I decided to change some things on the interface around to make it more like the gnome shell. Moved the launcher to the left, assigned the top left hot corner to show all windows, things were looking pretty good.

I tried using midori but the font rendering was just not worth it so I installed chromium, and of course that came with a lot of dependencies (around 300mb), so I tried to find out exactly how much space I had left on the partition (I some how missed the partition editor in the install). I opened the file browser and really liked it. you could see how much space was being used by each partition with "progress bars", but not by the EOS partition. There was no way to right click and select "properties" on the EOS partition, so I opened up the applications menu (twice) to find the "system monitor", because on Ubuntu, the system monitor shows how much space you have. But the OS had no graphical system monitor. I'm sure top was installed, but it's not the same. I was able to right click my home folder and select properties and this showed how much space I had on my partition.

Next I opened the terminal. I forget the name of the default terminal, but it wasn't gnome-terminal. It was a very utilitarian terminal that had tabs and no menu bar. I couldn't figure out how to change the look of it or get the tabs to go away.

Overall I give EOS a 5.9/10 It's fast, but it lacks a lot of functionality I look for in an OS like this. Maybe I was expecting too much, but I feel it will be a long time before EOS is as robust and polished as Ubuntu. I realize that EOS is meant to be lighter than Ubuntu and use different programs, but at this point it's just not ready to be my work horse.

</comment></comment><comment><USER8> elementary OS is one of the most promising Linux distributions. This for several reasons, like having a good installer and an overall clean desktop experience. But also because of the applications they are making themselves like Noise or Files.

That being said, I don't agree with some of the design decisions, which stop me from fully supporting the project.

For example I don't like the idea of having a top panel. It is constantly there wasting space only to show some tray icons a clock and a link to a launcher menu. Personally I prefer a single panel on the bottom, think Windows 7, there is enough horizontal space to show everything in a single row. Top panels just look bad in my opinion, for a normal maximized window you have the panel layer, then the titlebar layer, then the window. If you insist on having the notification bar on top at least, please, use wingpanel-slim (with the application launcher disabled and autohide).

</comment><comment><USER9> The 'outdated' comment stems from the fact that we depend very much on the repos. Being based on an old release means we don't have access to lots of software.

I use Elementary on the desktop and laptop and like it. Can't wait for dock improvements.

</comment><comment><USER10> The first myth is a valid point, although it comes across as a little defensive. The person who wrote it is an elementary OS developer, I suspect, and I wonder if they are missing an important point: it would be _FUCKING AWESOME_ if Elementary OS were "just a theme on top of Ubuntu."

It would presumably mean more frequent releases, less dependency on any given version of Ubuntu, smaller workload on the developers, and so on. Reinventing _every_ part of the OS, including the bits that people hope to use as little as possible, might not be the best strategy at this stage. (I have no illusions as to whether they'll change their strategy)

</comment><comment><USER11> The problem I have with elementaryOS is that there is no defined release schedule (like e.g Ubuntu or Fedora). So there's no ETAs or anything.

<comment><USER12> It's kind of sad too, because the Elementary developers originally planned to release Isis (the next release) around April to prove that they can stick to schedules [0], but that now seems to have changed to the usual "It'll be done when it's done." Relevant quote below:

"Also, I think in general most of us think it would be the best idea to release Isis (see, I'm already going with it) as closely as possible to Ubuntu 14.04. We have a lot to prove about our ability to provide updates in a timely manner and we're getting some negative feedback from developers/nerds about our 12.04 base. So let's address that and make sure that elementary is the best open platform for both users and developers (and I guess nerds too)."

[0] [https://lists.launchpad.net/elementary-dev- community/msg0257...](https://lists.launchpad.net/elementary-dev- community/msg02577.html)

<comment><USER13> Which would be better though, a rush job, or something that has polish (which seems to be the whole goal of Elementary). I suppose it is kind of like the difference between Valve and so many other games publishers out there.

</comment></comment></comment><comment><USER14> eOS has too much eye candy. Someone suggested in the comment section to install alucryd's PKGBUILDs to gain access to updated packages on Arch. If you're already thinking of Arch because of that comment, this should be enough eye candy: lightdm, cinnamon + CoverflowAltTab, plank + plank-themer, nautilus or spaceFM, themes like Numix + cinnamon-chronumix [1], awesomeWM, and reEFInd and a minimal theme [2]. Not sure why people opt in for a visual representation of applications when they need to browse to install applications...there's the list of applications in the wiki and /r/unixporn if you need visuals..

[1] [https://raw.githubusercontent.com/serdotlinecho/cinnamon- chr...](https://raw.githubusercontent.com/serdotlinecho/cinnamon- chronumix/master/screenshot.png)

[2] [https://camo.githubusercontent.com/32729998da4401a2aef674308...](https://camo.githubusercontent.com/32729998da4401a2aef67430828c62a2270b7a50/687474703a2f2f692e696d6775722e636f6d2f51323676514a782e6a7067)

</comment><comment><USER15> When it comes to problems with Linux as a personal desktop OS, the appearance of the GUI is among my lowest concerns. What prevents me from considering Linux as a desktop or laptop OS includes: horrible battery life times (worse than half for a friend's thinkpad when compared to it running Windows), how difficult it is to get Bluetooth and Wifi working, really bad multi-touch for trackpads.

The problems with Linux as a replacement for Windows or Mac are that the fundamentals are not there. Recent hardware support is non-existent as volunteers have to write drivers so you're likely stuck with old hardware. You'll get anecdotes of people who are happy with what they have, but any such person that I've known long enough I've seen them gripe on IRC about things that are completely trivial or just not even issues on Windows or a Mac.

Linux needs a hero with deep pockets that builds their own hardware and drivers. I thought Dell might have been that hero once, but it never became a priority for them.

If you could get elementary OS working on a nice slim, powerful Samsung or Thinkpad laptop, with good battery life and driver support then I'd think you'd really have something.

<comment><USER16> This isn't 2004. The state of development of the various GNU/ Linux distributions has reached a point where everything "just works". I have yet to see an installation with driver problems. Not to mention that the battery life on my ThinkPad easily compares with, if not exceeds, that of a Windows installation.

<comment><USER17> Both my Windows and OSX machines know that if I connect my bluetooth speaker to them, to play the sound through the speaker. Likewise, they know that if I plug in a Logitech USB dongle into the machine, that the sound and mic should go through the dongle.

Elementary is better than most at having some sort of easy to use, functioning bluetooth setup, but every time I use one of these devices I have to go into sound settings and switch them to the device. It's a pain in the ass that other companies have figured out.

<comment><USER18> This can be fixed by editing your pulseaudio settings:

[https://wiki.archlinux.org/index.php/PulseAudio#Automaticall...](https://wiki.archlinux.org/index.php/PulseAudio#Automatically_switch_to_Bluetooth_or_USB_headset)

I do agree, though, that it is weird that this is not enabled by default.

</comment></comment></comment></comment><comment><USER19> I was honestly expecting a post about the accusations of being an "OSX clone/ripoff/etc."

</comment><comment><USER20> Quick question, does ElementaryOS handle hiDPI better than any DE out there? I found frustrating it on gnome 3.12.

<comment><USER21> Which OS? For some reason Arch's Gnome handles hiDPI terribly, but Gnome Ubuntu is very good. So I stopped fighting it and just installed Gnome Ubuntu.

<comment><USER20> Jeez, thanks I'm exactly on Arch -.-'

</comment></comment></comment><comment><USER22> I love eOS but I've been spoiled by Unity and Google Chrome, I hate having the title bar.

</comment><comment><USER23> Most important point: does ElementaryOS support EFL-based elementary apps ?

</comment><comment><USER24> I'm missing Myth #6: elementaryOS is a clone of OS X

<comment><USER25> And I'm missing fact #1: WTF is elementaryOS and why should I care?

<comment><USER26> It's a Linux distro, read here: [http://elementaryos.org/](http://elementaryos.org/)</comment></comment></comment>


How to build video games for Windows using Crystal - <AUTHOR> http://blaxpirit.com/blog/23/how-to-build-video-games-for-windows-using-crystal.html <comment><AUTHOR> Currently a fork of Crystal is needed to cross-compile Crystal applications for Windows. However, we are working on merging that work into the standard library, and extending the work to the whole stdlib. Currently not enough of the standard library is covered to cross-compile the Crystal compiler. We have implemented a `Crystal::System` namespace which we plan on using to hold platform-specific parts of Crystal's stdlib, so that merging windows support doesn't make the standard library "ifdef hell".

Questions welcome :)

<comment><USER2> This is a great article. However I'm curious how much work is actually needed to get a seamless / native Crystal experience on Windows?

<comment><AUTHOR> Two things:

1\. We need to get windows support to cover the entirety of the standard library (when it's possible of course). This will also allow us to cross- compile the Crystal compiler onto Windows, which bootstraps the whole Windows port and makes it truly usable.

2\. We then need to merge that windows support into the standard library. We have already identified the abstractions required to make sure we can isolate the platform-specific parts of the standard library and have started moving some platform specific code there (see [1]). It's early days but this work should continue and will allow us to slowly merge windows support as a series of small and reviewable PRs, instead of one massive unreviewable chunk. The first part of windows support is already merged and in the latest release here [2]. [1] [https://github.com/crystal- lang/crystal/tree/b3c8f87fbe43669...](https://github.com/crystal- lang/crystal/tree/b3c8f87fbe436691a7b695ba0de946dd92353d19/src/crystal/system) [2] [https://github.com/crystal- lang/crystal/pull/4491](https://github.com/crystal-lang/crystal/pull/4491)

</comment></comment></comment><comment><USER2> Crystal is a Ruby inspired compiled language, allowing it to run blazingly fast with a very low memory footprint. It relies on LLVM for emitting native code, thus making use of all the optimisations built into the toolchain.

Website: [https://crystal-lang.org/](https://crystal-lang.org/)

</comment><comment><USER3> When Crystal will be ready on Windows, could exist a nice Installer? Something like accept, next, next, next, finish.

:-)

<comment><AUTHOR> Should be easy enough to make the installation process as simple as possible. Even after we get windows support complete you'll need some libraries and the msvc toolchain to compile for windows, so it's likely that we'll make a nice and simple installer that automates the process.</comment></comment>


How JPG Works - <AUTHOR> https://medium.freecodecamp.com/how-jpg-works-a4dbd2316f35#.bulg3aijd <comment><USER2> > This example shows a commonly used matrix of quantization factors , one for > each basis image

Key point here that isn't spelled out in the text is that the low frequency stuff (top left) is weighted higher than high frequency stuff. After dividing by the quantization factora and rounding, most high frequency stuff rounds to zero (which is mentioned, it just wasn't spelled out). Higher quality levels don't have as large of factors there and preserve high frequency data.

(Edit: just got to where gets detailed later in the quality section, but still feel it should be mentioned where that matrix is first shown)</comment>


Parser combinator library in C - <AUTHOR> https://github.com/wbhart/Cesium3/tree/combinators

<comment><USER2> I don't know why it uses a garbage collector when simple reference counting would suffice. Also I hate libraries with global states/variables like this one ...

<comment><USER3> How would you implement refcounting in the presence of longjmp? I don't see a graceful way to do it.

<comment><USER4> I don't like C libraries that use longjmp for error handling. It's like killing a fly with a bazooka. There are some cases when longjmp is useful of course, but If you want proper exceptions, use a language that supports them.

<comment><USER5> The OP is doing awesome stuff and sharing it with the world, and you want to criticize an implementation detail?

Bikeshedding like this isn't useful to anyone.

<comment><USER2> I appreciate the OP's efforts, certainly sharing code is a good thing. And one of the benefits of the sharing is to get a lot of feedback. Criticizing implementation details is important to spot, discuss and hopefully fix potential problems.

<comment><USER3> But the only actionable advice you can take away from the criticism is "rewrite it in C++". I don't think that's in any way useful and I don't think it should be made.

<comment><USER6> Right - "Don't use longjmp, do X in C instead" would have been a useful comment (particularly with example code). "Don't use longjmp, use C++ instead" is much less useful.

<comment><USER4> I agree that my comment was a bit harsh, but that's not what I said. I said that if he wanted exceptions he shouldn't have used C.

As for the alternatives, well return values never killed anyone, did they? You can use gotos to simplify the control flow within the functions. Other than that, there really isn't much to explain.

I don't like longjmp because I never expect them in C. I never think "hey, the control flow might jump to some point 20 stack frames above at any moment when I enter this library". And then I use mutexes. Cue the drama. You can't even protect yourself from the stack unwinding with handler-case or try ... catch/except.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> could anyone explain the use for this library ?

<comment><AUTHOR> The major parser libraries that I could find don't allow adding syntax at runtime or to add operators to the expression hierarchy at runtime. Many (though not all) of them also make it difficult to do custom error reporting. These were my major motivations.

<comment><USER8> Ah right, interesting use-case. I usually think of combinator parsing's advantages versus table-driven parsing (e.g. LALR) being primarily its expressiveness (and amenability to a functional-programming style), but it has a nice runtime-modifiable aspect as well.

I wonder how hard it'd be to build a runtime-modifiable table-driven parser, though. Assuming table compilation is fast enough, the most straightforward approach might be to just link in the grammar-compilation code so it's available at runtime, and rebuild the table each time a modification is made. I don't think you'd want to be doing complex incremental surgery on a table- driven parser, but you might not need to.

</comment></comment></comment><comment><USER9> nice, but would be better to have something simpler that doesn't rely on various libraries and features that are typically forbidden in high performance environments.

incidentally almost every memory leak I deal with comes from not being allowed to allocate my own memory and having to fiddle around with gc and refcount rubbish.

I have written whole non-trivial games with no detectable leaks.

<comment><AUTHOR> Could you provide some more information about "features that are typically forbidden in high performance environments".

Probably you want a parser expression grammar with a packrat parser if you really want speed anyway.

At the moment I am not smart enough to see how to implement combinators in C in an elegant way without GC of some form. But I'll think about it. Maybe something will occur to me.

Patches are welcome of course.</comment></comment>


The Soviet History Primer (illustrated for children and diplomats) - <AUTHOR> http://redprimer.com/

<comment><USER2> A work of genius! Thank you for the link.

The tragedy is the Russia (as a nation) has never been punished for its crimes. I fear that, lacking some form of justice, history will always repeat itself. (Of course, one could argue that the Russian people are punishing themselves - by electing to be governed by the most autocratic, dictatorial regimes...)

I wonder when the USSR's former 'satellite states' will finally see the sense in forming a mutual pact and kicking Russia back to its borders?</comment>


Ask HN: Has Google released a public post-mortem for Oct. YouTube outage yet? - <AUTHOR> If they have not, maybe an insider could tell us if they are planning to release one?<p>I've tried googling for one, but all I find is youtube videos of dead guys being cut up (not my cup of tea, apparently). <comment><USER2> Most companies don't release outage postmortems for consumer-facing products.

<comment><USER3> At least, not usually for free products.

<comment><USER4> it's not free. people work for YouTube full time.

<comment><USER5> This argument make zero sense. Facebook has thousands of full time employees, but their platform is free. (Arguably, you are the product, but thats not the argument being made here.)

<comment><USER6> I think they're referring to YouTube content creators</comment></comment></comment></comment></comment>


GitHub will keep selling software to ICE [Leaked Email] - <AUTHOR> https://www.theverge.com/2019/10/9/20906213/github-ice-microsoft-software-email-contract-immigration-nonprofit-donation <comment><USER2> Good for ICE. Maybe they can start sharing some code with the rest of us?

>Friedman goes on to say that he personally, and the company generally, disagrees with Trump administration policies, like family separation and the Muslim travel ban, as does Microsoft.

To bad Nat Friedman is regurgitating MSM/DNC talking points. Same crap Obama did, but its Trumps fault _sigh_

>Friedman describes the $200,000 ICE contract as "not financially material" and says in the email that GitHub will donate $500,000 to nonprofits that support immigrant communities affected by Trump administration policies.

Sure would be nice to throw around this much money for donations!</comment>


Equality in Marriages Grows, and So Does Class Divide - <AUTHOR> http://www.nytimes.com/2016/02/23/upshot/rise-in-marriages-of-equals-and-in-division-by-class.html <comment><USER2> Welcome to "Metropoilis".</comment>


Building A Great Core Team - <AUTHOR> http://blog.zactownsend.com/five-lessons-from-building-a-great-core-team-at-standard-treasury <comment><USER2> "Once money is no longer your biggest problem, hiring is."

Very true. After moving to the investment side a little while ago, I've seen firsthand that when founders are not stressed out about fundraising, they're stressed out about hiring. If I was to categorize requests that our portfolio companies have made of us, the breakdown would be something like:

* 50% help with hiring

* 20% introduction requests

* 15% requests for product feedback

* 15% miscellaneous (technical reviews, sitting down and discussing long-term strategy, etc.)

<comment><USER3> Would be cool to know what kind of problems is in hiring? Salaries too high? Too few people? Not enough within 60 miles?

<comment><USER2> Mostly finding high quality candidates (read: engineers), and occasionally helping with reference checks and vetting of key hires.

</comment></comment></comment><comment><USER4> I feel like these people took a lot of wrong lessons from this process, effectively interpreting lessons in terms of their own confirmation bias. Every single one of their three great engineers was hired based on establishing relationships with skilled folks, talking with them, and getting to know them as people. Lessons 2, 3, & 4? Not bad. Yet lesson 5? Grind their bones to dust with the most awful of modern hiring concepts - which was used for exactly 0 of their initial "top-tier code ninja rockstar" hires. They talk about it being haphazard, but the quote about evaluating people based on your "full-of-shit-meter" is almost spot on.

Why do we keep insisting that hiring not be based on people?

If people are motivated, quality, self-learning staff, they'll pick up whatever language, or API, or widget you throw at them. And if they're crap, they're crap. All four hours of tech. grilling is going to tell you is that you won't have to spend a couple weeks at slightly lower efficiency while they code using a language reference, or looking on StackExchange, rather than doing it from memory. What it won't reveal is that they're lazy, they just memorized a bunch of common tests, they can't actually think, or can't solve fuzzy problems you don't know you'll have. If you want hammers, then go buy a hammer, but if we want people, then we should stop beating our heads against walls, and go hire people.

Paraphrasing of one of my favourite West Wing quotes:

There was a man that lived by the river. He heard a radio report that the river was going to rush up and flood the town. And that all the residents should evacuate their homes. But the man said, "I'm religious. I pray. God will save me."

The waters rose up. A guy in a row boat came along and he shouted, "Hey, hey you! You in there. The town is flooding. Let me take you to safety." But the man shouted back, "God will save me."

A helicopter was hovering overhead. And a guy with a megaphone shouted, "Hey you, you down there. The town is flooding. Let me drop this ladder and I'll take you to safety." But the man shouted back that he prayed, and that God will save him.

Well...the man drowned. And standing at the gates, he said "I'm religious, I pray, I thought you loved me. Why did this happen?"

The response? "I sent you a radio report, a helicopter, and a guy in a rowboat. What the hell are you doing here?"

<comment><USER5> > They talk about it being haphazard, but the quote about evaluating people > based on your "full-of-shit-meter" is almost spot on.

>

> Why do we keep insisting that hiring not be based on people?

You need to combine the best of both worlds. Hiring, especially for startups, is stressful for both parties. Having a process makes it less likely that things like reference checks will get dropped and gives everyone a checklist and timeframe for making a decision.

That being said, the process should incorporate the "full-of-shit-meter" to stop wasting everyone's time as early as possible in the case of a bad match.

</comment></comment><comment><USER6> I would argue that hiring is not the biggest problem: people are. Hiring, firing, and management are all critical. Early on, finding people is about finding trust, motivation, and (to some extent) skills. Firing is about identifying that something isn't working out and ending it -- you cannot keep people around that hurt the company, they are a cancer and should be removed. Managing people is often forgotten and really important. Happy employees are better employees, they are motivated, care, and create a better work product.

With all that said, I like some of these messages. Always be recruiting and create a process are both really important. The latter of these does not mean to create bureaucracy, it just means to be deliberate about who you bring on.</comment>


Heroku and SOA - <AUTHOR> http://www.rdegges.com/heroku-and-soa/ <comment><USER2> The article misses one important point about free dynos. After a period of inactivity, your dyno will be come idle. This simply means that the next request will have significantly higher latency as the dyno restarts. This latency becomes even worse if you're waiting for 10 different services to start.

Of course, this isn't a problem if your app gets a reasonable amount of traffic but at that point there's a good chance you're paying for multiple dynos anyway.

<comment><USER3> Author here -- this is correct. I think it's a pretty good tradeoff though!

At OpenCNAM we handled billions of API requests, and some of our internal services actually ran on a single dyno (async stuff, mainly) -- but still, it was pretty awesome.

<comment><USER2> Definitely if you have sync stuff running on the free tier, you can mostly stop caring about idling :)</comment></comment></comment>


Don't Use Terminal Emacs - <AUTHOR> https://blog.aaronbieber.com/2016/12/29/don-t-use-terminal-emacs.html <comment><USER2> Nope. GUI emacs is sensitive to the mouse/trackpad, for example. I often switch windows and most of those windows are running emacs on remote machines. Using the mouse to select a GUI emacs moves the point. Doing the same in a terminal window does not. That's only one of many things that keep me on a terminal emacs.

The only time I favored a GUI emacs-like interface was on my Symbolics machine where all the text was live.

\-- An Emacs Curmudgeon</comment>


The History of Velveeta - <AUTHOR> http://www.smithsonianmag.com/arts-culture/there-is-no-shortage-history-when-it-comes-velveeta-180949312/ <comment><USER2> The cynic in me can't help but think that this so called "velveeta shortage" just in time for the NFL Playoffs/Superbowl is in reality nothing more than a lame guerilla marketing tactic from the Kraft marketing team in an attempt to drum up sales. The last few times I've gone grocery shopping I've noticed an abundance of Velveeta on the shelves, I would have had no clue there was a so called "shortage" unless you told me so.

<comment><USER3> When I went shopping for Christmas party baking and cooking supplies, I noticed a metric ton of Velveeta wherever I went. I think the "shortage" is just "We have less from the holiday eating rush, let's make some news."

</comment></comment><comment><USER4> Clearly the author has never stepped foot inside a cheese factory. Here is what happens:

Milk arrives

Milk get pasteurised

Rennet gets added to milk

Milk separates to curds and whey

Salt gets added

Whey gets drained off

Whey gets compressed into moulds with remaining whey squeezed out

Moulded blocks of what was whey go into plastic bags, put in the cold storage 'fridge'

After a while the moulded blocks mature into cheese. Typically they weigh 25 Kg each. Over time they mature - mature cheese is a premium product, however, the cold storage facility is only so big. Therefore some cheese gets sold as 'mild'.

The price of milk comes into it. As does what cows eat. As does how much rain falls. Sometimes it is better to make coloured cheese or 'diet' cheese if the milk is not up to scratch.

The whey actually is a very salty 'byproduct'. You can put it into a big machine that looks like a washing machine and churn it into butter. It will be salted butter because it already has salt in it.

As for wastage of the 'curd', there is practically none in a modern cheese factory. So I have no idea what this author is on about. You may have a useless employee knock a corner off a cheese block due to poor handling, but other than that there is practically no waste. The idea of 'what shall we do with this waste' is a bit beyond a joke.

This 'Velveeta' stuff has nothing to do with cheese. It is disgusting. The ingredients say it all. It is a fake product, like what salad cream is to mayonnaise. There is no quaint charm about it, no matter what the spin is here.

However, in the days before refrigeration was commonplace there was good reason to adulterate products so that they could have some half-decent shelf life. So, even though the original product was honourable, today's monster, reformulated product is just plain evil. Avoid with a bargepole.

<comment><USER5> Theodores - do you make cheese / work in a cheese factory? Would be interesting to talk to you about it: email@example.com</comment></comment>


Ask HN: How does one figure out what one wants to work on? - Throwaway-4096

For about a year, I worked on a webapp that I wanted to turn into a startup in the education space. I stopped recently because I realized that I could do something without the challenges of working in EdTech.
Now, I don't know what I should do. I feel like I should work on something new. I've come up with a list of 100 ideas. But, as I look down the list, none of them excite me.
How does one figure out what they want to work on? <comment> bjelkeman-again I find areas which hold promise, i.e. big impact for society, environment, human happiness etc., where there aren't a lot of others working right now, and where I would like to work. Then I look for a place / market where a standard business model would give a decent to good return on investment. Then I recruit a team. Then we start raising money.

I have done the last three startups this way, since '99, and it is a fairly slow process for me.

Edit: added last sentence</comment>


A Visit to Amsterdam's Microbe Museum - <AUTHOR> http://www.newyorker.com/tech/elements/a-visit-to-micropia-amsterdams-microbe-museum

<comment><USER3> >> As Nick Lane, a biochemist from University College London, once wrote, "More than being the first to see this unimagined world of animalcules, he was the first even to think of looking."

I very much doubt that. To achieve what he did, Van Leeuwenhoek would have needed to: have technical skill; be literate and sufficiently educated; have connections to get published; have access to material resources; have lived in a time of exploration; have lived in a place of freedom of expression; be of the required gender and race; have sufficient free time; and surely a certain amount of luck.

How many others would likely have already considered - perhaps even tried - <USER2> look for tiny living things, yet lacked one or more prerequisites from the (incomplete) list above? Nick Lane cannot be refuted, yet this quotation almost certainly does a disservice to the truth. Good and bad ideas are everywhere all the time; Van Leeuwenhoek deserves credit, but only for his execution.

<comment> chestnut-tree Although Van Leeuwenhoek wasn't a scientist, the skill he deployed in developing his microscope was a considerable achievement at the time. As in so many scientific stories, his work spurned others into further discoveries.

Here's a BBC science documentary from 2009 called _The Cell_ that begins with the story of Van Leeuwenhoek. Unfortunately, this YouTube copy has been dimmed presumably to avoid a copyright takedown. It's a shame these documentaries languish in the BBC archives.

Narrator: _" My starting point is September 1674 and the Royal Society of London. A mysterious satchel arrived in this club for gentleman scientists. It had taken five days to get here from Holland, across the North Sea by ship and then by horseback rider. The package came from a man who built the world's most powerful microscope, a microscope that revealed a hidden kingdom no-one had seen before..."_

[https://youtu.be/nc9aSq22nmo?t=2m16s](https://youtu.be/nc9aSq22nmo?t=2m16s)

<comment><USER4> Nit: "spurred"</comment></comment></comment>


Announcing Arrington XRP Capital, a Crypto-Denominated Hedge Fund - <AUTHOR> http://arringtonxrpcapital.com/2017/11/28/announcing-arrington-xrp-capital-a-crypto-denominated-hedge-fund/ <comment><USER2> A very important question: what is the supply model of Ripple's XRP?

If the fund is denominated in XRP, you're essentially betting on the relative prices of all other cryptos expressed in XRP.

</comment><comment><USER3> I did my first XRP transaction last night and it was incredibly fast. Done in a couple seconds. And the cost was next to nothing.</comment>


Why are projects always behind schedule? - <AUTHOR> http://priceonomics.com/why-are-projects-always-behind-schedule/ <comment><USER2> Asymmetry. No project can finish in negative time.</comment>


How to become successful Rubyist - <AUTHOR> http://belitsky.info/freelance/successful-ruby-freelancer/ <comment><USER2> So many folks suggest "If you don't have anything you can show, start by contributing to OSS work!" that I sort of have the urge to be contrarian:

1) The professional degree for software engineers is a BS. You might not be great shakes when you get out of school, but you're still a professional. You know what professional means? That when you're the least experienced person in the room doing barely serviceable work, _you're still getting paid_.

2) Extended unpaid apprenticeships are a feature of the guild system and their modern analogues, used specifically because they make it harder to get into the field rather than easier, despite the outward appearance of offering a ladder into the field. Is that who we really want to be?

3) Every programmer you admire sucked once and almost all of them got paid back when they sucked. They often got paid in a variety of eccentric fashions, but they got paid.

You know that ubermench coding for a local company when he was 14 who, hah, had to have his mom cash his paychecks because he didn't have a checking account? _His code sucked, too._ It just did something that solved a problem for the business. You know what businesses do for people who solve them problems? That's right, pay them money.

I have nothing against OSS. By all means, write OSS. Get paid to do it, though. Can you FizzBuzz? Good, you're hireable by somebody. Get hired. Write code. Learn to write code better. Career path goes up and to the right from here.

<comment><USER3> _So many folks suggest "If you don't have anything you can show, start by contributing to OSS work!" that I sort of have the urge to be contrarian_

Many interesting companies prefer to hire (and in some cases hire only) people who have or have contributed to opensource projects.

 _By all means, write OSS. Get paid to do it, though._

Is it really that bad to work on opensource software solely because you want to? Do we really need to get paid for everything we do?

<comment><USER4> _Is it really that bad to work on opensource software solely because you want to?_

Of course not. But there's a difference between "I work on OSS because I want to" and "I work on OSS because someone said I should". I believe patio11 is speaking about the latter, mostly.

</comment></comment></comment><comment><USER5> It seems like he is asking the wrong people these questions since there is a lot of "I can't really answer that because I don't need to do that". I would rather know the answers to these questions from random folks on the Ruby mailing list that I haven't heard of since their experiences would probably be more fitting for me.

<comment><USER6> "I would rather know the answers to these questions from random folks on the Ruby mailing list that I haven't heard of since their experiences would probably be more fitting for me."

I'd want to hear from people who tried and failed and learn what didn't work for them. Did they do the same things as the successful people? What were the differences?

What things actually make a difference, and what things are largely coincidental.

</comment></comment><comment><USER7> I have not read all the articles fully so I cannot comment on the content, but I found that the way the articles were written was interesting. I mean this guy just emailed all these questions to all these people and they just replied?

<comment><USER8> Yes, i write down some questions, which was interesting and useful for me on that time, and send about 70 emails. You can read all comments i got, only one guy write that he can't publish any interviews cause his contract. Some of guys write me that they will answer later, but i think they forgot about this. Anyway, i'm happy that i was able to get answers from those "cool guys" ;)</comment></comment>


Using SMS Text Messaging to Monitor and Track Weight Loss - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2011/08/15/prweb8718864.DTL

<comment><USER2> I built textWeight in my basement on New Years Eve and planned to just have it as an experiment with a few friends to better understand usability of SMS and whether it could have an impact. I was inspired by Tim Ferriss's book 4 Hour Body on keeping it simple. We ended up getting picked up by Tech Crunch, and the reception was pretty phenomenal.

One of my ambitions in this version is to see if we can get people to stay more engaged with their health on weekends. We know people are more likely to eat unhealthy foods over the weekend. Excited to see if we can make a dent and help people out.

</comment><comment><USER3> It seems like they have a subset of the features that we have created in Lose It! and they are clearly going for simplicity.

Lose It! is a little more complex(?) in the sense we do full food and exercise tracking. But I do still have some insights into the observations they have written about.

We offer reminders to log your food if you have done so far today. Users can pick the time and then we use iOS notifications to remind them, similar to the way they remind users to log their weight. Tis feature is iOS only, no Android or web only version of it. If you compare users with reminders enabled to users without reminders enabled we see users with reminders enabled lose 1.8 more pounds. (8.4 vs 6.6lbs)

However there are two other observations that we see from the Lose it! base. First, weighing yourself daily is stressful. People get down on themselves all the time because they gained weight from one day to the next when they thought they were doing good. This is because people fluctuate weight so much day to day based on so many factors. Most users on the forums always recommend only weighing yourself once a week. We also had to build in a buffer range for users once they hit their goal weight because so many users complained that their weight moves around so much once they hit their goal weight they kept getting bumped back into a weight loss plan.

Another pattern we see is that users that have a Withings scale that automatically records their weight receive a lot of value (expressed in emails to us, posts on the forums, or written on their wall) from the device. We haven't had time to run stats (on how it effects weight) on this yet but we are starting to talk about the 'passive tracking' for users that have a Fitbit and a Withings connected to their Lose It!. Users cannot get over how much a better picture of their health they get after the values come in on their own. The Withings scale takes the textWeight idea to a new level. Sadly, both of these devices are pretty costly and out of the range of a lot of people. So textWeight might be a good way for people to track weight that are on a low cost budget.

All in all though, the most important feature that will improve your weight loss is accountability via social / friends both online or in real life. Studies have shown this in the past so we are not the first to notice or the first to say. In fact, this is the first thing out of the mouth of most health startup CEOs.

<comment><USER4> You bring up some relevant points -- we also have data from our first version, textWeight 1.0, and have used a number of the analyses and insights from our data, independent reports and surveys. Use of SMS texting is key here. To your point while some believe frequent weigh-ins are detrimental, there is published literature that supports improved outcomes with frequency of weigh ins, and textWeight 2.0 puts this totally in the hands of the user. As a user, you can configure number of days per week and time of day for text alerts. I have to agree, overindulgence is generally unappreciated, Self Tapper at 5-7 texts per day may be overboard but that remains to be seen. textWeight also has a weight maintenance option to message and encourage users appropriately. All users receive motivation, support and encouragement based upon their personally defined challenge and latest weight entry. This along with the behavioral information they contribute and our continuous bidirectional dialoguing enables us to provide such encouragement. This is unique to the healthcare space -- where well designed programs like Text4baby and Vaxtext push messages to survey and collect data to discover their impact. To your point about filling a low cost niche, we call it providing access in healthcare, we have intentionally used SMS texting to allow for use by feature phones (current smart phone penetration is under 30%) and since being overweight and/or obese strikes across demographics we want to enable broad access to all we can help. There is not a CEO of a start up or Fortune 500 company who would dispute this.

</comment></comment><comment><USER5> This seems pretty retarded. Firstly weight is not a measure of health and weight loss is not the goal (you can improve fitness without changing weight, just shifting weight from fat mass to muscle mass).

Secondly, Who can't remember how much they weighed last time they weighed themselves? It's such a pitifully simple piece of information where small variances are inconsequential. If you weigh about 110, and your ideal weight is about 85, you hardly need to know historically what your weight was.

Thirdly, the best measure of "weight loss" is how you feel, not how much you weigh.

I can see merit in recording something but I think weight is the wrong metric, or maybe weight isn't an appropriate metric when taken in isolation.

Perhaps if it were weight correlated with mood, diet, time (of month? day? year?) or various life events then it'd be worthwhile.

Perhaps sending a text: "110kg :S pizza" indicating you're 110kg, feeling stressed and the last thing you ate was pizza.

If the "request for information" SMS were sent out at some sort of "random sampling" time, then you could probably build some sort of useful statistical model based on mood and food consumption correlating to fluctuations in weight then use the feedback to reduce weight over time.

<comment><AUTHOR> To your first point -- some people do need to control their weight (or even lose weight), not everyone is in the same category with regards to health/weight/etc., And to be quite honest, I'm pretty sure last time I saw my doctor they told me "it'd be a good idea / healthy to lose X pounds..." -- that's fairly cut and dry to me, I need to lose some weight -- this service is just a method of tracking that progress while offering up helpful advice along the way.

</comment></comment><comment><USER6> I am using Google Docs with a simple form for daily input. Entries are automatically timestamped and the Google Docs trend chart works quite well for this kind of data.</comment>


If you've lost hope in American democracy, here's some good news - <AUTHOR> https://www.washingtonpost.com/news/monkey-cage/wp/2018/09/14/if-youve-lost-hope-in-american-democracy-heres-some-good-news/?noredirect=on&utm_campaign=Weekly%20Digest%20%28Oct%2014%29&utm_content=Why%20companies%20squander%20brilliant%20ideas%20%5BBest%20Reads%5D&utm_medium=email&utm_source=ActiveCampaign&utm_term=.ae44d8c23254 <comment><AUTHOR> The original title from WP is a little clickbaity, but it's an interesting article reporting on a series of experiments to support open democracy using technology, supported by the MacArthur Foundation Research Network on Opening Governance.</comment>


Can we stop AI outsmarting humanity? - <AUTHOR> https://www.theguardian.com/technology/2019/mar/28/can-we-stop-robots-outsmarting-humanity-artificial-intelligence-singularity <comment><USER2> I see two scenarios:

1\. We inadvertently turn the planet into gray goo.

2\. We create an entity with greater general intelligence than mankind.

I would argue we only need to be concerned about preventing (1). In the case of (2) I would just see that as man's legacy. Viewed in that light man is a stepping stone to an even greater entity. The end of mankind doesn't even have to be violent. Imagine robo caretakers watching our children who, unbeknownst to us, made them all infertile. Then they use social engineering to make people not desire to have children (though they'd still have sex). They would presumably be happy having sex and not having children and so it could take decades before anyone uncovered what had been going on all along. Heck, this sounds like a great start to a sci-fi story! :)</comment>


A Safer RuboCop, Part Deux - <AUTHOR> http://metaredux.com/posts/2020/07/07/a-safer-rubocop-part-deux.html <comment><USER2> I like the idea of RuboCop, but I don't use it because I think it simply wrong in so many cases (complaining about "if ... then" really gets my goat). I know I can build a set of exceptions, but life's too short.

I think it would benefit from the PEP8 approach of only going after the egregious stuff, to be sufficiently non-judgemental that I'm happy to have it as part of a project test-suite (i.e., where a violation is suite failure).</comment>


Show HN: Intergram – Free live chat widget linked to your Telegram messenger - <AUTHOR> https://github.com/idoco/intergram <comment><USER2> I was pretty surprised to find this had nothing to do with Instagram.

<comment><AUTHOR> Hmm... I get that :) Do you have a better name for it ?

<comment><USER3> Telegram + Widget = Telegidget

Short. Sounds like a real word, and from a quick googling doesn't seem to be being used by anything else (open source or commercial).

<comment><AUTHOR> Not bad, maybe I'll open an issue on GitHub and let people vote on the name.

</comment></comment></comment></comment><comment><USER4> Thanks! I've just implemented on this fairly new website [https://www.brainzilla.com/](https://www.brainzilla.com/)

I had a few ideas for widgets that sit there and are only loaded when the user interacts with it and your implementation will be perfect for me to understand how it's done. Thanks again!

<comment><AUTHOR> I've implemented a pretty naive solution, I guess there are better ways to do that.

You can it here [https://github.com/idoco/intergram/blob/master/src/widget/wi...](https://github.com/idoco/intergram/blob/master/src/widget/widget- index.js)

</comment></comment><comment><USER5> Does the Telegram API offer any way for direct ephemeral communication between users and Telegram's servers so as to not require an intermediary server?

<comment><USER6> Yeah.

[https://core.telegram.org/](https://core.telegram.org/)

<comment><USER5> My question asks if it is possible to use Telegram's API to communicate with someone in a way that does not require the user to create or authenticate with an account. But it may require a loosely permissive authorization token provided by the person with whom the user wishes to communicate.

Intergram achieves this (if I understand correctly) by using an intermediary server between the user and Telegram's API.

What I'm further asking is if the same behavior is possible without the intermediary server.

</comment></comment></comment><comment><USER7> Interesting. I wonder how this could be used to have multiple people read and reply to messages? Perhaps the Intergram bot could be linked to a group chat...

<comment><AUTHOR> Yeah, it should work in groups. I really like the idea of building another bot to do some auto replies, kinda like a "micro-bot" architecture.

</comment></comment><comment><USER8> I see you're using React on this - cool. If my site already uses React, will your widget import React again?

<comment><AUTHOR> I'm using preact, it's a very light version of react. The whole initial js bundle is less than 6kb (gziped)

[https://preactjs.com](https://preactjs.com)

<comment><USER5> It may make sense to publish a self-contained component in an npm package

</comment></comment></comment><comment><USER9> This is amazing!!! Thanks :-)

<comment><AUTHOR> Thanks :)

</comment></comment><comment><USER10> Came here for Instagram.</comment>