Why Did So Many Startups Choose MongoDB? - <AUTHOR> https://www.nemil.com/mongo/1.html <comment><USER2> The misplaced hype cycle is real.

10gen is _not_ a company dedicated to databases, at least not if the initial code quality of MongoDB is a signal (and it should be, since if you know a thing or two about storage you wouldn't take the compromises it initially did)

Unfortunately, many fresh graduates with no experience in storage decided to evaluate the technology based on its very visible merits, without considering that scalability is not really a top priority even in companies that have to "scale", and that reliability trumps every other metric.

Mongo has failed spectacularly in being a reliable data store, and its scalability is mediocre, given that it's a lot more about query planning, analytics and optimization than having out-of-the-box sharding.

This is one of those areas having some seniority does wonders. Storage concepts are not easy to grasp, and evaluating a database's reliability takes much longer than most product cycles.

<comment><USER3> Why wouldn't you always use something that is tried-and-true? MongoDB is relatively new compared to something like postgresql or even mysql.

<comment> squeaky-clean If you actually need certain features like a document store, then Postgres is less mature than MongoDB in that regard.

<comment><USER4> I'll take "less mature" over "data loss" _every day_ and twice on Sunday.

Whatever else you might say about Postgres, that community cares about the integrity of its users data, over pretty much every other consideration. I don't think the same can be said of Mongo, or any other "NoSQL" anything.

<comment><USER5> > I don't think the same can be said of Mongo, or any other "NoSQL" anything.

I feel pretty good about DynamoDB, but the development model WRT to indexes and throughput is what keeps me away.

</comment></comment></comment></comment></comment><comment><USER6> This post makes the assumption that MongoDB isn't doing well based on Hacker News. MongoDB the company, and product, are doing extremely well (outside of anecdotal Hacker News posts), based on objective metrics like downloads, skills, jobs, and company revenue (and the company is nearing 900 employees on linkedin).

To put it another way, RethinkDB did extremely well on Hacker News. Twitter didn't, if you remember all the negative posts (and still went public). There is little relation between success on Hacker News and company success.

<comment><USER7> MongoDB is like the PHP of databases. I started programming PHP and currently I bash it every time I can, because it is a terrible language. But it is easy to start and do cool stuff, just like mongodb. Initial traction is more important than initial architecture, I guess.

<comment><USER8> Right; Facebook, Wikipedia, OpenStreetMap - all serious tech stacks that started and (in the case of the last two) continue to use PHP.

Reminds me of: [https://slack.engineering/taking-php-seriously- cf7a60065329](https://slack.engineering/taking-php-seriously-cf7a60065329)

<comment><USER9> Facebook does not "normal" PHP that much, they use host of languages, including Hack, erlang and lots of Python.

<comment><USER10> Most of their code is Hack, and Hack is a superset of PHP (last time I checked all it really adds is static typing and async)

[https://news.ycombinator.com/item?id=14659729](https://news.ycombinator.com/item?id=14659729)

<comment><USER9> > all it really adds is static typing and async

You make that sound like its not a big deal vs vanilla php.

<comment><USER10> It's really not. All the sadness and broken-ness of PHP is still there.

<comment><USER11> A lot broken-ness is still left for the sake of compatibility (especially since HHVM's open-source), but Collections and type hinting make a huge difference.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Back in 2012 I worked at a startup and we had a few backend data stores (Vertica, Postgres, Redis, Big Table, MySQL, Cassandra, ElasticSearch, Hadoop).

When 10gen came along, they sold us an amazing vision. We were processing 500 million to billion social media messages a day and they sold us on this dream that we would have very fast writes, a cluster of 9 machines in master-slave- slave config for fail over. We wouldn't have to write SQL anymore (which was actually funny to watch one of our engineers try to unlearn table denormalization).

At the end of the day, it was hype. I had to stay up during multiple 2012 debates for 5 hours and flip the Mongo databases because they kept crashing. The shard key they set up for us was slightly out of balance so the data distribution was 30-30-40 and every so often, that server processing 40% of our data would jump to 50% and then knock that server offline leaving the other 2 to split 50% of the work... knocking them offline. There were also tons of replication problems all traced to write locking. At the end of the day 10gen solved one problem, but our company traded that solution for other problems.

That experience taught me that you really need to understand what you're trying to solve before picking a database. Mongo is great for some things and terrible for others. Knowing what I know now, I would have probably chosen Kafka.

<comment><USER13> You do realize it's 2017 now, right? Many things have changed in MongoDB (and in the IT world in general) during the last 5 years. MongoDB is a mature, established, full-featured database - recognized by Gartner as a "challenger" to more established RDBMS vendors like Oracle and Microsoft.

[http://bit.ly/2uP3Obi](http://bit.ly/2uP3Obi)

<comment><USER12> I'm sure it's better today. I'm talking about my experience back then. It may be a challenger, but it still has tradeoffs that system architects need to factor in when making database decisions.

</comment></comment></comment><comment><USER14> I have been paid by two companies to remove Mongo. One that was hosted at the Mongo HQ. (The mongo HQ guys are really nice). At small startups, things are on fire and people need answers quick. "How many users tried this, how many times was feature x used," on and on. If it is in mysql, well i just setup a vpn and a read mysql access, done -- they can query away.

If it is all in mongo? Welp. How is your python? "See there is this key, and you need to sum this -- OH and remember that this does.. Hmm, "

</comment><comment><USER15> I wrote this series over several months and am happy to answer questions.

Part 2 will dive into the benefits of Mongo along with the mistakes that some teams made with Mongo. Part 3 will dig into Mongo's marketing strategy and how it influenced uptake. Sign up here to be notified: [http://eepurl.com/cxs5Zr](http://eepurl.com/cxs5Zr)

As any reflective engineer, it's important for me to provide a thoughtful perspective backed by evidence. This can be a fraught discussion and I personally know teams that truly value Mongo, and other teams that had tremendous issues. I want to provide color about the early years of Mongo (not today). My key point is that as engineers, we have to get beyond hype, thinking critically and choosing the right tool for the job.

</comment><comment><USER16> I think Enterprise folks do not appreciate the flexibility afforded by NoSQL . For my startup I started off on PostGres SQL with Hibernate and it worked great ... until we first met our paying customers. They needed data elements that I had not envisioned and so we ended up doing Schema updates.. again and again . Since we used ORM (hibernate), that also meant new hibernate code generation . After a while this became very tedious.

I have a background in enterprise s/w development; we always lock down on most of our requirements before we start writing code. RDBMS is fantastic in this scenarios. In my startup, we build something light and show it to bunch of prospects and iterate. MongoDB fits this mode of s/w development for us. Sure there are gotchas and other issues but they have not affected us yet.

<comment><USER17> Database migrations are a thing. Many languages' database libraries have built-in or bolt-on schema migration tools for this very purpose.

<comment><USER18> Django's ORM and migration tools are amazing.

</comment></comment></comment><comment><USER19> You guys are discussing MongoDB from 2009. The database has evolved since then.

\- There is a new replication protocol for replica sets, improving the election process.

\- WiredTiger has been introduced and became the default storage engine.

\- Journaling guarantees durability.

\- Sharding architecture has changed. Config Servers are now deployed as Replica Sets and some of the tasks that used to be managed by mongos now are managed by the config servers.

\- Storage efficiency has been added through compression.

\- Security has been improved with encryption at rest.

\- The aggregation framework has more options for BI.

\- There are a variety of different indexes that can be created to improve query performance.

\- and finally, stop saying MongoDB is schemaless because it is not. There is a schema in place and this schema is flexible enough to be polyform.

These are features available today in 3.4. You might have issues in the past, but if you really understand the newest architecture, you are capable of seeing how much MongoDB has grown since 2.4.

<comment><USER2> But at this point that's all pretty much moot because competitors have caught up and there's hardly an advantage over Postgres' JSONB fields, which builds up on top of all the features Mongo will likely never have (transactions I'm looking at you).

</comment></comment><comment><USER20> I use Mongo & its been working great. Our data is not relational (imagine you were tasked with building "Powerpoint" on the web).

Compared to mysql I like that it has automatic failover out of the box. I can also just add new replica set members without having to stop the master or bring a slave offline to rsync it over.

With something like mysql I have to learn about & choose between row based replication or statement based replication. I have to choose between binary logging or global transaction ID logging. With Mongo I just call rs.init() and rs.add() and it "just works".

Perhaps I'm just not hitting the level of traffic where the problems begin to surface, or maybe postgres would be better... but its been great so far. No complaints. The only issue was de-normalized data getting out of sync due to bad coding in our app, which i do not blame Mongo for (and was simple to fix).

<comment><USER21> Of course I don't know your product, but when I imagine Powerpoint-as-a service, do users not relate to decks which relate to slides which relate to the content on those slides? Content itself of course would probably be a pretty flexible tree structure.

An app full of queries like "Get me all the content of slide Y of deck XXXX... or don't if the current user YYY doesn't have access to that" would make me itching for indices and foreign constraints across what definitely feel like relations to me.

And for the non-relational content blobs, Postgres's partial indices + indexes on expressions would make some fairly intricate reports like "since we launched the image embedding feature, per week, what percent of created or modified slides contain images", "who are the top 10 users in terms of edits to content tree items, and what subscription level do they have" pretty neat and fast.

If you're in early stages such that you don't want to hire or acquire DBA skills, you're probably well served by offloading replication/backup/verification (which are all very possible with RDBMS) to e.g. AWS's RDS product.

HA is important, is covered by replication+failover. Periodic backups are important, are covered by a export+rotate schedule. Point-in-time restores are important, are covered by storing replication logs. All are covered by a managed RDBMS, so you need to know what they are and how they work, but not implement or manage them. Most of the NoSQL deployments I've seen just rely on the out-of-the-box replication, and get HA but that's it. The engineers I've seen that don't want to understand the simple high-level ramifications-to- developers of RDBMS replication don't want to understand ramifications-to- developers about their NoSQL replication either, and they take a risk of encountering those ramifications needlessly unforeseen.

As the data grows, yeah, maybe you'll eventually hit technical or economical limits that mean you'll want to manage your own RDBMS with an application- tuned replication and sharding scheme, so you'll want to hire or train at that point -- but there's huge huge room to play within the economic and technical characteristics of modern managed cloud RDBMS-as-a-service for any app that has a hint of a business model, given that we measure the cost of such services in cents per billion unit-hours.

<comment><USER20> > Get me all the content of slide Y of deck XXXX

But that's not a query I ever need. I load the user's document, which contains an array of slide (embedded documents). There is no relation between documents & slides, slides are part of the document.

But take it one step further & imagine you have a variety of widgets that can be placed on slides, with no common schema between them. Your choice is model out 100s of tables, use EAV, or go noSQL. We did the latter.

> would make me itching for indices and foreign constraints

Mongo has indexes. Regarding foreign keys it does not have that, but usually you can just embed the document in all the places you need it (de- normalization). Which can be a problem, so if you don't want de-normalization you should definitely use a SQL DB, not mongo.

> Postgres's partial indices + indexes on expressions would make some fairly > intricate reports like "since we launched the image embedding feature, per > week, what percent of created or modified slides contain images"

Mongo has aggregation which has fortunately been able to perform all the reporting I've needed so far. I'm sure postgres is nice as well.

</comment></comment></comment><comment> nevi-me Interesting article, and I look forward to the other 2 parts. This was well- researched and balanced.

MongoDB feels like a different product to what it was when the hype was high. The company, leadership and engineering quality certainly have changed.

Someone else commented about the HN bias, which we can't deny exists.

I've been running an 1-member replica for as long as I could figure out how replicas work. So I've had my Mongo database running for the last 5 years. It's met the sweet spot that I was looking for when I knew less than what I do today.

Even if one were to rubbish the product, it still has value as the company seems to be doing well (even with the negative sentiment and press). Mongo sometimes feels like how "corporates" (at least in the recent past) feel about open-source. Dealing with our SAS account at work, the sentiment used to be that open-source was a waste of our time. Open-source is brittle and slow, rather use Oracle, etc. SAP HANA will change your life, in-memory is hard, our "appliances" run on unsecular hardware ...

Those sentiments have changed over time, so we shouldn't eternally write things off if they're healthily maintained.

I look forward to mixing SQL and NoSQL well into my future. DocumentDB wouldn't be what it is today if there was no Mongo . The SQL vs NoSQL flame wars get us nowhere to be frank.

</comment><comment><USER22> I think the short answer is the same today as it was back in those days. A person once put it to me simply: "programmers are afraid of databases."

It was a perfect mixture of this unfounded fear with an advertised simple solution. Add the idea that there is no need for a DBA, encourage developers to see Mongo as a magic data storage and nothing more, and you have the perfect product for those who don't feel the need to look deeper.

Startups seem more optimized to fast iteration and quick development. It seems to me that they chose Mongo because they prioritized iteration and ease-of- development over the hard-nosed style needed to use a relational database well.

<comment><USER5> > programmers are afraid of databases.

Maybe it's an age thing (or the product of "bootcamps"), but I don't think that's true. I'm 40, and when I was learning, you connected to and wrote SQL against the database. These days I still spend a significant amount of time writing SQL, both for ad hoc queries and for complex queries / performance optimization.

> Add the idea that there is no need for a DBA

With many cloud database offerings this is essentially true. As for things like indexes, etc... developers targeting Mongo need these as well.

> encourage developers to see Mongo as a magic data storage and nothing more

In modern frameworks, this tends to be true no matter what the data store is.

</comment></comment><comment><USER23> Mongo succeeded for three reasons:

1\. Architecturally is was very familiar to traditional relational systems like MySQL. Meaning classical master/slave, sharding and absolute consistency via locks.

2\. Mongo's rise coincided with the rise of NodeJS and continued on the success of Ruby on Rails.

3\. Mongo has done a phenomenally fantastic job attracting developers with exceptional documentation and getting started materials.

These all combined into a perfect storm attracting legions of developers. Note that these things have absolutely nothing to do with the technical capabilities of Mongo as an actual database.

<comment><USER24> Not so different in some ways from the rise of MySQL itself.

In point #2 substitute PHP for Node and RoR.

In point #3 just change the name from Mongo to MySQL. MySQL AB was brilliant at getting MySQL into Linux distros. When you came to need a DBMS to go along with PHP chances were you could just type 'mysql' and you would connect to a live DBMS instance on the host.

The 10gen team also imitated the MySQL playbook explicitly with built-in replication and an early lack of focus on ACID properties.

</comment></comment><comment><USER25> MongoDB is an interesting database for sure. It seems that they made a deliberate product decision to optimize developer experience and ease of use over things like consistency and database joins. Frankly, I think it's working pretty well for their business.

I don't think there's anything that should immediately preclude the use of MongoDB in a production environment. I personally wouldn't use older versions of it as a single source of truth, but there are definitely some great use cases for it, such as allowing developers who only know JavaScript to write non-critical backend services.

People seem to forget that database consistency is not binary, but residing on a spectrum. Like any other trade-offs, you should carefully measure the costs and benefits for your particular situation before making a decision.

</comment><comment><USER26> We chose it because the lead developer liked it, and when I did my research I didn't find any glaring issues because it was too new.

The lead dev had never actually used it, but liked the idea of not having to come up with a schema and he really liked JSON as he was very familiar with it.

By the time we were done, we were easily one of the top 5 users of MongoDB at scale and it was responsible for 9 out of 10 of our outages due to various bugs or optimization issues.

</comment><comment><USER27> I'm not a back-end dev strictly. I played with mongo on some side projects back when it was all hyped up. One thing that appealed to me was the on- boarding process for a non "database guy". I got lots of small side projects up and running very quickly and the concepts made sense. Similar to jQuery being easy to understand and popular to newcomers but you later learn it isn't always the best tool for the job.

</comment><comment><USER28> Any criticism of MongoDB that does not acknowledge WiredTiger and the plethora of positive changes that made MongoDB much, much better in the 3.0, 3.2 and 3.4 releases is criticism that is not fully thought out.

It's like complaining getting graphic cards working because of drivers is difficult on Ubuntu, based on experience with linux in 2005.

<comment> nevi-me In the end it doesn't really matter. I feel the article is an educational one, but as it's the chance for us to take our sides of the fence in praising and criticising, we'll still do it anyway.

I wouldn't be surprised if half of the commenters haven't used Mongo, or stopped in the 2.0-2.2 days.

A lot of software fails, companies close, while some succeed. Some software that has been hyped up ended up not succeeding, but it doesn't matter. One learns from others' mistakes and keeps growing.

<comment><USER29> > I wouldn't be surprised if half of the commenters haven't used Mongo, or > stopped in the 2.0-2.2 days.

You would be correct, as the mountain of ignorance about MongoDB on display in this and all HN threads on MongoDB attest to.

</comment></comment></comment><comment><USER30> It's not just because of hype that teams choose Mongo. The flexibility of a schemaless db is pretty helpful in a startup scenario, where the requirements drastically change all the time.

Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations.

The option of having documents with embedded objects/lists makes it a pretty natural mapping to Domain Driven Design concepts, like aggregate roots + aggregates. One might even argue that while following DDD, it's preferable to handle most rules at the application layer and use the database simply as a performant, low-maintenance storage service. I know some folks here might view this approach as a sin, but it works pretty well too, especially for smaller teams without a dedicated DBA.

Maybe it's just me that haven't ran large enough systems to find the kind of issues with mongo that people always rant about, idk. Honest question: considering all these advantages above (from a developer's point of view), are there good reasons for choosing something like PostgreSQL over Mongo for typical business apps?

<comment><USER31> I'm not entirely convinced that MongoDB is better suited or a natural mapping to DDD concepts in practice, it's just more convenient for developers who want to build things fast.

My thoughts on this pattern are to still use a robust, reliable db (Postgres) behind a message queue for the event store. Postgres does almost all of the things I need with the reliability that I need while letting me sleep at night.

An event store absolutely must be the most reliable part of the infrastructure, IMO.

<comment><USER30> "just more convenient for developers who want to build things fast" \- that's a compelling advantage for Mongo, isn't it?

I agree a robust, reliable db is super important - but isn't Mongo too, at this point? Even if it wasn't back in 2012? I thought most of the reliability issues and bad defaults were fixed by now...

<comment><USER31> My (in)experience with Mongo leaves me with a certain existential dread that I just can't shake. Also for that sort of thing these days I'd be more likely to use ElasticSearch than anything (this absolutely terrifies me actually, but I'm seeing companies do this) and eat the extra infrastructure expense. Serves the same function and gives me insanely powerful tools to process the data without having to write any code.

In my planning for problem domain changing, personally I'm going to be writing a (relational) schema for the new data model anyway, which will be Postgres, and playing my event store over it and doing one-way writes to it going forward anyway. I'd rather reduce the mental maintenance overhead of two different databases to one.

<comment><USER30> Interesting. I've always thought event store was an interesting pattern, but not something as a default architecture for typical business apps, probably because of the added complexity in maintenance.

If you're building your relational db based on the event store, I'd imagine even something simpler like Mongo would do it, but I agree that having a single db to maintain is an important advantage.

</comment></comment></comment></comment></comment><comment><USER32> I still think MongoDB is a good database. Conceptually, It's not as good as RethinkDB but it's not too far off. It's good to not have to deal with SQL and horrible ORMs anymore.

TBH, I'd rather write SQL directly rather than use an ORM though. I never want to use an ORM ever again. At least that's one problem that MongoDB solved.

<comment><USER33> I don't understand what you're saying MongoDB solved. Mongo has ORMs too like Mongoose.

Why did you think you can only use SQL with an ORM? And if you didn't think that, then what was your point?

<comment><USER32> Mongoose is a lot simpler and less brittle than other ORMs in SQL land. That said, for most use cases, you don't need to use Mongoose.

When it comes to Mongo, I think it's nice to have the DB schema documented somewhere but you don't really need to have it enforced with Mongoose... It introduces more problems than solutions.

With Mongoose, you have to run migrations on your data more often which slows you down. Though it might make sense for bigger companies.

</comment></comment></comment><comment><USER34> Looking at the table from 10th Gen, I believe it is misleading, at least in relation to Edmunds. I worked there, and Oracle (which was the source of truth) was replaced by PostgreSQL.

Mongo did replace Oracle product but it was Oracle's Coherence[1]. There wasn't a concern of Mongo loosing data, because the data could be reloaded again from Postgres if it got lost.

I also heard that they were considering replacing Mongo with Postgres as well, but I do not know where this went.

I think 10th Gen is just good at generating hype. The migration was not because Mongo was better but because Oracle was expensive and not that much better from Open Source alternatives.

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

</comment><comment><USER35> We are also one of those companies that bought into the promise (or hype) in 2011 and gave MongoDB a spin. After some very successful tests, I had long conversations with my CTO on why we should deploy MongoDB in prod and make it our primary OLTP store. Yes, MongoDB had it's challenges in 1.6 and it required some "faith". But it's 2017 now and MongoDB totally delivered on it's vision, at least for us. Since 2012, that's when we upgraded to 2.0, we had 10 min of total downtime. That's 99.999% uptime in 5 years. Year after year, 99.999% uptime. And that 10 min is the total for scheduled (btw, we don't have scheduled downtime for our MongoDB clusters since there is no need for that) and un-scheduled downtime. We never take the service down. We perform all maintenance operations during regular business hours with no impact to end- users at all. So much about reliability! MongoDB as a product has bugs. What a surprise, what software product doesn't. But it's about you community (we are running the community edition) supports the product. We recently discovered an issue as well causing the primary to crash. As designed, another member in the repl set took over and there was no downtime at all. Even though we don't have a support contract, the issue was acknowledged by MongoDB in hours and fixed in a couple of days. I wish we had that type of support for products where we do have a support contract! And last but not least, if you can't figure out how to successfully use MongoDB, for god sake, take some free training classes on MongoDB University. MongoDB might not be a good fit for every use-case, but it's already an awesome platform for an incredible number of applications. Polyglot environments is the keyword here. SQL has it's advantages and disadvantages and so does NoSQL. Use the best tool for the problem. One size fits all doesn't work anymore and MongoDB is clearly the best and most popular document store on the market. And even better, other platforms like postgres have acknowledged that the idea of storing JSON has its merits and have implemented its own version of that idea. However, IMO, if your use-case is a good fit for a document store, use MongoDB. We have done so and couldn't be happier with that decision.

</comment><comment><USER36> What NoSQL databases are people using today when they need something ACID compliant? CouchDB?

<comment><USER37> NoSQL originally meany to not use SQL as the query language

However, most people think NoSQL as NotRelational - when there is no ACID guarantee. They are choosing availability over consistency.

<comment><USER24> ACID and relational are orthogonal. You can have ACID properties without a relational model. Much of the early literature on the subject merely discusses databases in general rather than any particular type. Here's an example from Jim Grey:

[http://jimgray.azurewebsites.net/papers/thetransactionconcep...](http://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf)

</comment></comment></comment><comment><USER38> For us, the reason to run with MongoDB in 2009 were twofold: a) for one of our products which was consuming the Twitter gardenhose, unverified writes were a blessing. We got away with a single dedicated server running mongodb (and it was not a particularly expensive server). I would need to do serious research again whether there's a better solution for this today. It was using Stanford NLP to highlight breaking news before anyone realized. We never got a single subscriber because every newsdesk that saw it wanted to acquire us immediately LOL. Eventually one did. b) For another, the ability to store and index complex documents which in SQL would've needed JOINs and you couldn't index across JOINs at least in MySQL and our previous experience in PostgreSQL vs MySQL support didn't favor PostgreSQL at the time at all. It worked -- although it didn't have a journal back then. We were ready for a failure but the failure never came. The landscape today is much different with PostgreSQL and MySQL and SQLite all embracing JSON storage and indexing on expressions are there for all three.

</comment><comment><USER13> I find it difficult to seriously address comments to this thread. People still referencing 10gen and talking about data points from 5-10 years ago (2009, 2012, 2013).

You do realize it's 2017 now, right? Many things have changed in MongoDB (and in the IT world in general) during the last 5 years. MongoDB is a mature, established, full-featured database - recognized by Gartner as a "challenger" to more established RDBMS vendors like Oracle and Microsoft.

[http://bit.ly/2uP3Obi](http://bit.ly/2uP3Obi)

MongoDB has many built in features that are extremely attractive for building modern applications. Built in HA & DR, horizontal scalability, multiple storage engines, rich indexing and query capabilities, enhanced BI features in aggregation framework, and many more...

</comment><comment><USER39> Not to sound flippant but the reason why so many startups choose mongodb is because the problems they are working on are better suited to be addressed with a document-oriented database than relational database.

And at the time, most of the mindshare is/was with mongodb for document- oriented technology.

<comment><USER2> What are those problems exactly?

</comment></comment><comment><USER40> Come on, we all know why: [https://www.youtube.com/watch?v=b2F-DItXtZs&list=PLmGAf2A36C...](https://www.youtube.com/watch?v=b2F-DItXtZs&list=PLmGAf2A36COcfSrQfNkeocctpfmG1glwT)

<comment><USER41> That made me lol!

This reminds me of every single javascript coder I have worked with. Just because they can get something running within a day, makes them look down on other coders and gives them some sort of complex.

No wonder the whole javascript stack is a complete and utter mess!

</comment></comment><comment><USER42> Hype and lack of critical thinking abolutely had their role, but mostly because it's so much easier than a relational db.

Relational db's are hard. You have schemas and query planners and the truth is, you have to take care of every single query. Every query counts.

The same query can take 30 seconds, or 30 milliseconds to run, depending on it using an index or not. You think it's ok for it to take 2 or 3 seconds, until it hits production and halts the server.

Mongo doesn't have any of that. Just load and dump json back and forth, which is perfect for fast prototyping.

Who cares about data integrity or technical debt?

<comment> nevi-me It has most of that. It's not that RDBMS are hard and schemaless convolutions are easier.

Mongo has query planners, the same thinking you do in SQL applies to Mongo, the edge cases are different. For example, you can't have composite indices on multiple arrays. The same principles we consider when tuning our RDB apply to Mongo, normalisation comes at different forms/levels. The same applies to denormalisation. Just because there are/were "no joins" didn't mean that everything goes into a single collection.

I run some Mongo deployments, and I take as much care in understanding performance, as I do with our SQL deployments. Databases are hard to those who are unwilling to open up the manual and read. It's not only SQL.

</comment></comment><comment><USER43> I've assessed a fair number of companies who use Mongo in some way or another and the I always ask the rationale for the decision. Surprise surprise, it's usually "we chose it because it was easy to start with".

My favorite recent one was a company that had to persist their Mongo database into AzureSQL (nightly job) so they could then push it to Good Data for analytics. They could have very easily used SQL Server and pushed directly from there to Good Data. And yes the company admitted that was the case.

<comment><USER34> In case of Edmunds, the rationale was that their contractors previously used Mongo and were more familiar with, and upcoming 2.6 version will have some "new cool features".

Also the table is misleading, PostgreSQL replaced Oracle, Mongo replaced Oracle Coherence[1].

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

</comment></comment><comment><USER44> Obligatory read when talking MongoDB [https://aphyr.com/posts/322-jepsen- mongodb-stale-reads](https://aphyr.com/posts/322-jepsen-mongodb-stale-reads) and follow-up [https://jepsen.io/analyses/mongodb-3-4-0-rc3](https://jepsen.io/analyses/mongodb-3-4-0-rc3).

Ensured me to never use this for production scenarios. No matter how 'hyped' or 'convenient' it is. Yaiks.

</comment><comment><USER45> As a person who just recently turned down an offer to write an ArangoDB book, Mongo is not worth it. I think most needs are met between Arango and PostgreSQL. Arango provides a scalable NoSQL option over PostgreSQL (let's see what version 10 holds). PostgreSQL provides a solid, efficient SQL solution.

Mongo provides no benefits of transactions or solid design. If you want either, look to Arango or PostgreSQL.

</comment><comment><USER46> There were so many blog posts about how MongoDB was the future and SQL/relational dbs were the past.

I wish someone would collect all the hyped up tech blog posts so that we always have a reference to be able to say, "see what hype does?" Sadly, I think it would only increase the number of devs saying, "Not this time, it's different."

</comment><comment><USER47> Our team had little experience with backends in 2013 and a fear that it will be hard to scale game servers in case of success (players hate lags and downtimes).

So we followed the hype of Node.js and MongoDB because everybody was saying how it's easy to scale them compared to the established tech.

</comment><comment><USER48> Similar questions can be asked

> Why do so many developers use map/reduce instead of the database for select, > pluck, math?

> Why do so many developers use length instead of counting sql?

The learning curve was easy, it was very compatible with javascript, it was very easy to install, it had similar features to sql lite.

</comment><comment><USER49> Because they have great docs. At least that's why I chose them for my (now defunct) startup back in 2013. I wasn't familiar with databases and their docs were extremely approachable and easy to understand and navigate, with lots of useful examples.

</comment><comment><USER50> Reminds me of the keynote DHH gave at RailsConf this year. Despite the stories that we like to tell ourselves about picking the right tool for the job, we're just as prone to chasing the shiny new thing as all the other humans.

<comment><USER17> Who's "we"? I have yet to see a high quality _technical_ argument for using a number of technologies that have come along the last 5-8 years or so in most cases. Too often "scalability" and "modern stack" are used as an excuse to tinker with the new shiny far out of bounds of their proper use. I have a reputation as being the opposition any time adoption of something new comes up. It's rarely necessary.

</comment></comment><comment><USER51> I've seen a few comments mention RethinkDB ... what are the advantages over MongoDB?

I can read their feature page but as someone who isn't an expert, I'm not sure what's marketing hype and what's genuine advantage.

<comment><USER52> The company got bankrupted and they set up an org to fund its development. (Sagemath moved to Postgresql from RethinkDB after the company got sold. The guy behind sage said it was better in his blog about the switch)

<comment><USER53> Thanks; here's my blog post: [http://blog.sagemath.com/2017/02/09/rethinkdb- vs-postgres.ht...](http://blog.sagemath.com/2017/02/09/rethinkdb-vs- postgres.html)

Incidentally, [http://www.lmfdb.org](http://www.lmfdb.org) uses MongoDB (since maybe 2011) pretty heavily, as a result of me convincing them to do so after I read too much about MongoDB back then. It's been painful for them, but it does still work well...

</comment></comment></comment><comment><USER54> Marketing aside, MongoDB is just really easy to pick up and use. In a small project, its weaknesses don't really show up (at least in my limited experience), if it gets big you often end up rebuilding anyway.

</comment><comment><USER55> Anyone with average to more DB experience knows there is no one-stop shop. DBs are about trade-offs and we need to choose the right ones for our application(s)

</comment><comment><USER56> Knowledge does not equal wisdom. Perhaps it was young folks with lots of knowledge didn't see the wisdom in using battle-hardened, boring technology.

<comment><USER17> It isn't an age thing. There are mid-life engineers where I work who are constantly trying to force the latest fad in tech into our engineering organization.

</comment></comment><comment><USER55> Anyone with proper unbiased DB knowledge knows without trying or reading anything that it is hype. DBs are all about trade-offs you can't have it all

</comment><comment><USER57> Marketing & ease of use (for example, if you try to insert into a collection that does not exist, it's automatically created for you).

</comment><comment><USER58> Because it's _not_ MySql. "We can't use our _dad 's_ database!"

</comment><comment><USER59> Really good marketing, mongo's pitch was "use this if you want to be Innovative"

</comment><comment><USER60> to avoid schema migrations

<comment><USER34> And in turn put the schema (actually multiple versions of it) in your application making it more complex.

Since Relational Algebra was invented in 1970 we were unable to find a better representation of a relational data, there were many attempts but so far they failed (except for very specialized uses). So I'm inclined to believe it's here to stay.

JSON is basically just step backwards back to the XML Database[1] and Object Oriented Database[2]. It starts falling apart as soon as your data becomes more complex (you have relations, or need to query it by something else than primary key). Having said that, I'm glad that relational databases added support to it, it perhaps might be useful in early stages when things are in flux.

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

[2] [https://en.wikipedia.org/wiki/Database_model#Object- oriented...](https://en.wikipedia.org/wiki/Database_model#Object- oriented_database_models)

<comment><USER60> I'd rather keep the logic in my app than have planned downtime for schematic migrations

</comment></comment></comment><comment><USER61> I'd wanted to lift the burden of writing ORM layers and dealing with relational algebra and focus on persisting my intrinsic application models. I'd studied XML and other semi-structured web data at the graduate level, but was frustrated there wasn't a technology that was meeting that need. Companies like Microsoft and Oracle were adding XML functionality to their databases, but because it was bolted on an already constrained structure, it failed to address the mangling that relational structures impose.

I saw a demo of MongoDB in 2010 and was thoroughly impressed. The developer experience out of the box was exquisite. During a 1 hour presentation, I was able to download the binary, connect to the shell, create records in a familiar form (JSON), query the data from my preferred language, and all within a often second-class platform, Windows.

There was a certain _joy_ to using MongoDB, but I had my doubts, too. If this form of database interaction was so easy and fun to use, what was the catch?

Well, the catch was that MongoDB was re-thinking the issue from the ground up, re-envisioning the way we work with data, in an attempt to transcend the inertia that held back existing offerings.

When I started working with MongoDB, it felt like the same transcendence I experienced moving from C++ to Python in 1998--the approach was simpler, more intuitive, and powerful.

Sure, there were some growing pains. The concept came first without acknowledged writes or even journaling. Replication came in stages. Sharding came later.

But our operation was able to go from startup-scale to a global enterprise- scale operation backed by MongoDB, performing admirably, and giving developers the ability to rapidly innovate in a low-impedance environment. We've since developed dozens of applications against MongoDB.

I've considered emergent competing offerings like PostgreSQL with its JSON store, but when I did a few years ago, they were still dramatically behind in replication and sharding support, requiring extensive administration for aspects that MongoDB handled out of the box.

And in the meantime, MongoDB has continued to innovate, bringing in pluggable storage backends, advancing the query engine and aggregation framework, adding native geo-location support, and formalizing the concept of shard zones (a key feature for global scalability). And with Atlas, they've made server administration a near zero-cost proposition.

I'm a fan because when it comes to boots-on-the-ground experience, I see nothing else in the industry that even comes close. The most pressing deficiencies have been addressed and without compromising the key innovations. As a developer and technology leader, I choose MongoDB as my default database and would only consider a traditional database if the use case was intrinsically highly constrained and tabular in nature.</comment>


Obama orders Guantanamo kept open and indefinite detention for prisoners - <AUTHOR> http://www.washingtonpost.com/wp-dyn/content/article/2011/03/07/AR2011030704871.html?hpid=topnews

<comment><USER2> To the rest of the world, this pretty much spells the end of "hope" in Obama.

<comment><AUTHOR> I'm exhausted of defending him and refuse to do it anymore (barely did in the first place) but the lesser known facts are these:

1\. Congress purposely yanked all funding for other alternatives to force it to be kept open.

2\. The remaining prisoners are supposedly the worst of the worst or do not have countries that can take and watch them (ie. Yemen)

Doesn't make this right and there are most likely innocent people mixed in there, held for a decade now who were turned in by people who simply didn't like them and wanted the bounty that was offered.

<comment><USER3> Grandparent is not stating that it's actually Obama's fault. He might me a great person, with the best of intentions, but he's powerless against the wants of the rest of the regime. The overall result is still a loss of 'hope'.

<comment><AUTHOR> I have a little saying that "Senator Obama would be very disappointed with President Obama". For me it sums up these 4 years in a nutshell.

</comment></comment></comment></comment><comment><USER4> Think of all the first person shooters you have ever played. Now imagine the groups in those games that had secret prisons.

<comment><USER5> Your point is?

<comment><USER6> Eat your broccoli.</comment></comment></comment>


Why the Oil Price and the US Dollar Are Negatively Correlated - <AUTHOR> http://beta.finimize.com/us-dollar-going-up-makes-commodities-goes-down-why/ <comment><USER2> The title is missing a key bit. A better title might be, "Why the oil price _in US dollars_ and the US dollar are negatively correlated."

But then the answer to that is too obvious to bother writing about, so I guess the article tries to obfuscate it.

Naturally, for anything where the US is not the dominant producer, its price in dollars will correlate negatively with the value of dollars. Oil isn't special.

<comment><AUTHOR> The point is definitely true of all US-dollar commodities (which is basically every commodity price out there). I wrote the article, actually, in response to a question from a reader of our email who was confused when I wrote: "commodities are priced in US dollars, so their price goes down as the US dollar goes up." I had initially thought perhaps that this concept was, as you say, more obvious than it actually appears to be for many people.

Original article & question is here: [http://beta.finimize.com/general/too- much-oil-copper-too-lit...](http://beta.finimize.com/general/too-much-oil- copper-too-little-demand/)

<comment><USER2> Well, it's clearly not fair to accuse you of being deliberately obtuse when it was prompted by a question like that!

Anyway, thanks for the context.

<comment><AUTHOR> :) To be fair to the person, we bill ourselves as a simple email-based daily read of the financial news (hence the Q&A function for when we're not as simple as we'd like)

</comment></comment></comment></comment><comment><USER3> The US Dollar is positively correlated with the price of things the US exports. And negatively correlated with oil prices because the US is still a net importer, though importing only about a third as much as it did a decade ago.

So you will see the dollar go up when world markets are robust for American products like software, jumbo jets, cereals, Wall Street scams, and Hollywood.

<comment><USER4> That's highly context dependent. The US Dollar soared starting in Summer 2014 due to the end of QE. It had absolutely nothing to do with US exports. The USD returned to where it otherwise would have been without the Fed debasing it so heavily. If the Fed raises interest rates, it'll go up further - again, while having absolutely nothing to do with US exports in that case.

The USD and oil trade inversely because oil is priced in dollars globally. If the value of the dollar rises, oil inherently must drop in price. It has nothing to do with the amount of oil the US imports or not. What matters is the currency that oil mostly trades in globally, and that is US dollars. The dollar doesn't go down because oil goes up, that confuses the relationship entirely. It's oil that trades in dollars, not dollars that trade in oil.

</comment></comment><comment><USER5> Didn't made sense to me. Will love if you add some comments below the blog to explain why oil exporters are forced to lower their prices? If US dollar goes up, then going by all capitalist laws, they should look to make more profit because the demand is constant in each economy. Oil isn't like electricity which is wasted if not supplied.

<comment><USER6> You are assuming that demand is constant, but oil can be replaced by other sources of energy. Whith a high price of the oil there are electricity generatora that do not profit, so they don't generate energy, leaving space for other cheaper sources.

Also, it is arguable that other costs, such as car gas rises, some people will use public transportation. This sustitution effect can be applied to many other examples.

<comment><AUTHOR> The example assumes that all other factors (like demand) remain constant. You are correct in saying that a higher oil price will lead some users to switch to a different energy source in some scenarios. The point is to explain why financial commentators say (especially recently) that "the strong US dollar is causing commodities to sell off."

</comment></comment></comment><comment><USER7> In other words when your money is worth more (compared to other currencies) you can buy more with it.

<comment><USER8> Yeah, but the rest of the countries will afford less of what you produce, so the demand for your products will decrease. That's why China kept its currency artificially low for several years - to be able to sell more of its products to the rest of the world.

<comment><USER9> >Yeah, but the rest of the countries will afford less of what you produce, so the demand for your products will decrease.

Except for financial products that generate returns USD.

</comment></comment></comment><comment><USER10> On the other hand in countries exporting oil - currency is positively correlated with the oil price.

I think it's because they try to maintain the earnings expressed in domestic currency from smaller amount expressed in international currency (because oil prices went down).

See Russia: [http://assets.bwbx.io/images/iaPrrgKBoRbc/v1/-1x-1.jpg](http://assets.bwbx.io/images/iaPrrgKBoRbc/v1/-1x-1.jpg)

<comment><AUTHOR> I think it's mainly because a high oil price is good for the economies of oil- exporting countries, like Russia, Canada and Norway (to name a few). More exports = more economic growth. More economic growth (all things equal) should equal higher interest rates which leads to a more valuable currency.

<comment><USER10> > More economic growth (all things equal) should equal higher interest rates > which leads to a more valuable currency.

In fact it works the other way - if you have high interest rates - it means people expect your currency to lose value. It's one of the less intuitive facts about currency, and the reason I'm happy I took economy course even though I dropped out of it on 4th year :)

The reason is - in "perfect knowledge world" it shouldn't matter if you keep your money for a year on bank account in country X, or if you instead change them into currency Y today, and keep it in country Y for a year (different interest rates), and then change them back to currency X.

If these 2 scenarios produce different outcomes - it means one of the banks is paying people more than it has to - contradiction in terms if I've ever seen one :)

So:

       moneyInX * (1+interestRateX) = moneyInX * exchangeRateXToYToday * (1+interestRateY) / (exchangeRateXToYAfterAYear)

       exchangeRateXToYAfterAYear = exchangeRateXToYToday*(1+interestRateY)/(1+interestRateX)

In real world people don't predict correctly 100% of the time, but in stable einvironment it's close (it's modified by the risk factor).

BTW that's what's happening in Russia now - high interest rates, recession, and currency losing value.

EDIT: but you're right that it could be caused by low growth, just the low- high interest rates mediation isn't there.

</comment></comment></comment><comment><USER11> Related Read: Paper Money (1981) by 'Adam Smith' George J. W. Goodman.

</comment><comment><USER12> Americans can PRINT dollars to buy OPEC Oil;

Rest have to EARN dollars to buy OPEC Oil;

[https://en.wikipedia.org/wiki/Petrocurrency#Currencies_used_...](https://en.wikipedia.org/wiki/Petrocurrency#Currencies_used_to_trade_oil)

<comment><USER13> I agree. The concept of petrodollars explains everything in the OP and more.</comment></comment>


Show HN: Appliku.com Cost-Effecient and Pretty Python Digital Ocean Deployments - <AUTHOR> https://appliku.com/ <comment><USER2> So my website is running Django 1.11 on Digitalocean.

I'm potentially interested in using your software but I'll need some convincing.

Right now updating the site is very easy. I use FileZilla to upload the new files and I would simply type `sudo systemctl restart gunicorn` once the new updates are uploaded. Also perform a `migrate` or `collectstatic` if needed.

The workflow I got right now works and is very simple, and does not rely on any middle-software.

Is there any good reason for me to use your app to deploy changes?

<comment><AUTHOR> hey, hi! Thanks for asking!

Let's say to deploy change I do "git push" and that's it. Everything else is done for me.

In the case with the app you described – you have already done major part of heavy lifting with the initial setup.

In your case you are not using git, it means you might have problems adding anyone else to help you coding.

Side note: if you are not using git you can easily lose your code if you don't have any other backups if the server goes down and something happens with your computer at the same time.

Now, variables, credentials: something tells me you have them in your code, which is bad. If you just add git, it is even worse – you will have them in a repo and again it is bad.

Now imagine the situation when you need to move to another server. You have all your code in the system, no containers or dockers. My gut tells me that you don't have scripts to automatically install everything on a new server. It will be a nightmare to install everything and try not to forget how they were set up(judging from the Django version it was a very long time ago).

What you have it works now, but such setup makes you absolutely unprepared for any change(new people, migration to another server, etc).

So, those were bad things I pointed out.

Let's see what (in)direct benefits of using a "middle-software":

\- you will use git. It gives you a chance to add new people to the team, code history, code backup \- Your task as a developer is to git push the code. DEPLOYMENT is not exactly the concern for a developer. \- You are forced to have more up-to-date workflow. App should be tested before going out or at least should have ability to be tested. Tests are exectured by CI/CD of some sort. So you have to work in the way to be ready for that.

So, what I am trying to articulate here is that having benifits of modern tools to work in team, test the app, check code quality to eventually have better application requires certain approach to storing your code and deploying it in automated fashion. By doing it manually over ftp/sftp and manually running commands to update/restart it – you are not letting yourself to use other modern teachnologies and tools. And they are middle-software in their niche/for their task. So, if you want better quality software of yours – you shoudl use many other things that you can called "middle-software".

When we work alone and we are not used to work with all modern tools we choose workflow that is super fast and convenient for us at that point. I too back in a day was running production server running in "screen" and cmd/ctrl+s applied my changes and it felt logical and very easy.

What I realized that this setup is impossible to control and especially replicate. And everything falls apart when you have somebody else who needs to make changes.

Fast forward, 2020 – I don't want to think about two things: server configuration and app deployments. I want to push my code and see changes. I want to be able to invite others to my git repo and nothing in workflow should change.

When you do things manually it just doesn't happen without pain.

I hope I gave you a good enough answer, and examples and metaphors to articulate my ideas in this very huge topic.

Wish you a great day!

</comment></comment><comment><USER3> A typo - cost-efficient! But glad to see more out-of-the-box solutions coming out. It can get pretty time-consuming to deploy after your app is already done. What was the trickiest part of developing that product, I wonder?

<comment><AUTHOR> Hey! Thanks, I have fixed it on the landing page, evidently, I can't fix it here.

What was hard, you ask? Short answer: the complexity of the product.

(Very) Long answer: Yesterday I found a note in my OneNote dated Sep 2, 2016. It had a draft on what such deployment automation can be.

I was thinking about it since that time.

The first hard thing was to decide what tech I should use and what approach to use.

At first, I wanted to use "supervisord" and build everything on bare metal.

Then I understood that I should put more time into learning about docker. Everyone was saying "containers, containers, containers [balmer.gif]"

After I got familiar with docker, I've started to write bash scripts to build app, read about how Heroku works and a lot of other materials.

Then came the long part of trying to make apps build with a bunch of bash- scripts and eventually I was able to build all of my apps. I was happy and thought that I was almost ready with the app, I just need to build a frontend for that. Oh, I was so wrong.

Every new achievement that I had, every new door I was able to open led me to hundreds of new doors to open (including those I shouldn't touch). What I mean by that is after solving a problem, I found other things to solve and options to pursue.

Eventually, I got so deep in this never-ending-doors fight, that I lost my focus. My initial idea was to help deploy/run python and Django apps in the best way possible.

When I lost my focus and got overwhelmed by constant building and mountains of things I can/should build I had a slight depression.

I stepped back and given that I had some noticeable personal problems to solve I was able to switch from thinking about the app.

When I got back with a fresh head I realized that I should get back to the original focus and start to compare all new ideas and options (those doors from metaphor) to it. Is a new feature/option/idea fits for the original purpose of the app or not?

Then it all started to get easier.

Then I was able to plan ahead knowing what I should do and discarding what I shouldn't. I realized that the backlog was huge. But every single task wasn't super hard.

All this gave me peace of mind. And I started to work on it, persistently. I understood that I will not be able to ship it super fast and there are still technical decisions I will have to think thru and they also will take time. I found my pace. Every day I produced a little bit of work.

What helped was some well-known people say phrases like "it is not the matter who starts, it is a matter who keeps going". I knew that project is complex and there are so many edge cases that I should take care of. It will take time.

So, 14 months after buying the domain appliku.com (roughly the beginning of the coding) I still have the stuff to do. And always will.

So to sum this up: \- For such a complex app, I set out to build I had to figure out boundaries. \- I had to find my pace \- I had to remember that I am building exactly the app I always needed and never found elsewhere.

told you, it will be a long answer :)

Hope I have answered your question!

<comment><USER3> Tells a lot about how prioritization is important when approaching complex tasks. Were you implementing this whole product yourself?

<comment><AUTHOR> Yes. It is not based on any existing tool(except Django) and I didn't hire anyone(yet?)

</comment></comment></comment></comment><comment><USER4> What are the advantages of this instead of using a CI/CD pipeline?

<comment><AUTHOR> Generic CI/CD pipeline is a way to execute your automation. But you have to code everything yourself at least initially.

With Appliku you have your web server installed, databases provisioned and settings applied.

With CI/CD pipeline you have to write all that yourself.

You may think that one of the core features of Appliku is a niche CI/CD that has a pipeline written for you for the task of deploying and running your Python app.

Could you build it yourself? yes. Question is, should you?

Additionally, you have servers provisioning and setup, DNS records, SSL certificates issued, and many more things taken care of.</comment></comment>


Big banks need IT reform almost as badly as regulatory change  - <AUTHOR> http://www.economist.com/node/16646044

<comment><AUTHOR> I was... "fascinated" by this quote: "That is good news for start-ups such as Metro Bank, which wants to open more than 200 branches in Britain by 2020. With such grand designs, isn't Vernon Hill, one of the bank's founders, tempted to build an IT system of his own? "I hate programmers," replies this dyed-in-the-wool entrepreneur. "They only cause trouble.""

<comment><USER2> It's a good thing that bank doesn't use any software.

<comment><USER3> You have to go with the lesser evil.

</comment></comment></comment><comment><AUTHOR> META: Why did the title change? I cannot edit the title of my own submission anymore... Was it merged with a duplicate submission? If so, then there's also <http://news.ycombinator.com/item?id=1541336> (which was created just a few minutes after my submission)

<comment><USER4> I believe sometimes mods change titles to be more accurate or neutral. I've had it happen to me before, too.

</comment></comment><comment><USER5> Having worked in operations for two major banks, I can confirm the article. We used software in DOS emulation and old fashioned command prompts to process trades, which were essentially done by hand. This was during the wave of consolidation leading up to the financial crash. Why improve when you can buy the competition?

</comment><comment><USER6> It's not just big banks, small community banks (and credit unions) are at the mercy of convoluted system vendors as well.

A system I know of includes many barely-integrated parts, most of which are from different vendors: \- A core processing system

\- An online banking system

\- An add-on to the online banking system to provide "enhanced" logon security to comply with an FFIEC mandate

\- An add-on to online banking that provides online statements

\- An email-alerting system (think "your account is overdrawn")

\- A loan origination system

\- A loan servicing system

\- A CRM system

\- A document archiving system

\- A mobile banking "solution"

The WTFs you find in these systems will boggle the mind, and seamless integration is maddening.

<comment><USER7> Here in Germany, I haven't found a bank that has _any_ email functionality or a post-2001 web interface.

Maybe the reason why it takes 3 days to transfer funds to another account really is incompetence rather than greed.

</comment></comment><comment><USER8> If you want to gain some domain knowledge in this area, especially for smaller community banks, be sure and check out the excellent 5th comment.

</comment><comment><USER9> One of my previous jobs involved applications used by some banks, and I got to see how archaic some of the hardware still in use was. In one bank - to remain anonymous but is a well known name - they were still using a 25 year old computer system, which was older than I was at the time.

<comment><USER10> I know of one dearly-departed bank that used a mainframe system so ancient that there was only one company left that supported it. Since the early 90's, that company had had just one customer.

</comment></comment><comment><USER11> What is wrong with mainframes?

The problems banks solve are the reason mainframes exist. Billions of data points that must be processed 100% correct 100% percent of the time. It seems wrong to demonize mainframes as old and outmoded.

<comment><USER12> It's not the idea of a mainframe in and of itself. It's that the longer you have such a system in place, the more difficult it becomes to update it.

The State of California still runs all its payroll processing via an ancient mainframe running COBOL. Making changes is difficult, fewer and fewer programmers are available to perform the work (and so it costs more) and the problem just keeps getting worse. Apparently they have been trying to replace it since 2004, but the legislature doesn't want to provide the $100 million that is supposedly required.

</comment></comment><comment><USER13> When it takes 2 banks of mine about a week to decrement a number in one bank's database and increment a number by the same amount in the other bank's database, there's something _horribly wrong_ somewhere.

</comment><comment><USER14> Banks fear the complexity of IT. Now they are pushed to get into the challenge of offering new services that require a complex setting, so they smell problems in the near future.

</comment><comment><USER15> I agree with this article, but I admit that the Little Britain reference in the title is what made it for me.

<http://en.wikipedia.org/wiki/Carol_Beer></comment>


Show HN: Personal Storage System with a PI - <AUTHOR> https://github.com/timgrossmann/StorageSystem <comment><USER2> Why do so many projects go straight into a technical description of their solution without posing what the problem actually is. Here is the only justification of why they are doing this project- "I want to build an application, with which i can manage the items in my basement (preferably groceries)".

What does this even mean? This trend frequently happens especially on HN and it denies the reader a chance at weighing up the solution within context of the problem.

<comment><USER3> He definitely could do a better job explaining what he is trying to accomplish, but I pity the person who has to use the barcode scanner he suggested, when you go below the $100 price point and are looking for a new in box handheld scanner, there is just crap for options and you will get to sit there and try to scan the same item repeatedly, until you give up and key every 8th item in by hand.

I would highly recommend buying a used Metrologic or Datalogic handheld scanner at or above $50, it'll work a lot better and (if programmed) can usually handle 2D barcodes. This is the major reason you see Fred Meyers spending $5k a pop on new Datalogic 9800i's, and why Walmart had the NCR 7878 custom built for them, scanning performance is a make it or break it deal.

On the Pi side, I'd sub in a OrangePi Plus 2E since it has 16GB of eMMC and has a fully libre stack now at a lower cost, and would likely nab a used monitor for $10 locally rather than pay for a low res 7" at a premium price.

<comment><AUTHOR> Thank you! I definitely will explain it better/in more detail.

Thank you for the advice with the hardware, I'm not yet too familiar with the hardware side, but I'm learning and your feedback is really important to me, thank you.

I tested the barcode scanner with quite a few products and thought it to be pretty good for the money. I mean, for me it's a personal thing, so no need for super high performance. If the item is already in the system, you can scan 2-3 times per second, which is pretty good i think.

I'll definitely look up the PI and monitor part thank you !

</comment></comment></comment><comment><USER4> This seems like an over-engineered solution to a non-problem. Formal stock control is only useful if you have serious issues (eg. theft, very large inventory, unidentifiable packages). The author could solve his problem by simply keeping ketchup in the kitchen like sane people.

So in summary there is a barcode scanner, a Raspberry Pi and a screen. Where's the label printer? Not quoted: still more cost! It would have been far cheaper and more practical to install a new shelf.

<comment><AUTHOR> Hey, you're right. But since I'm a CS student who likes to try out and learn stuff, over engineering is not a bad thing for me.

For a little home, we have an unnecessarily large inventory and it is really comfortable to just look it up on the smartphone than take the staircase to the basement and search through the stock :D

It's not just ketchup btw ;)

I'm still searching for an over engineered use case for my new label printer... The printing with this system is simply done with a Wifi printer nearly anyone (at least here in Germany) has at home. You can simply print a list of all the stock and if you want even a simple groceries list of which items are empty ;)

We installed a new shelf but once this one is full, you still got the problem. I mean, you could add even more, but at one point the room is full and you're back where you started :D

<comment><USER5> Now you just need a little robot to fetch the things from your basement and put them into a vacuum-tube delivery system.. :)

</comment></comment></comment><comment><USER6> Useful project.

How are you getting the product information ? Is there a public barcode database ?

<comment><AUTHOR> Like already written, the information comes from Outpan... If the product isn't already on outpan you're asked to enter the name of the product and a new entry is created.

<comment><USER6> It is a crowdsourced model.

I did check online for other API services [0..2] and GT1 [3] information.

[0] [http://www.ean-search.org/](http://www.ean-search.org/)

[1] [https://www.barcodelookup.com/api](https://www.barcodelookup.com/api)

[2] [http://eandata.com/](http://eandata.com/)

[3] [http://www.gs1.org/barcodes/ean-upc](http://www.gs1.org/barcodes/ean-upc)

</comment></comment></comment><comment><USER7> Finally, a use for my CueCat!

<comment><USER8> I thought nobody remembered that!

<comment> TD-Linux I used to have a couple I would attach to coworker's computers randomly to confuse them. Doesn't work anymore because no one uses desktops with PS/2 ports...

<comment><USER9> Time for an USB-to-PS/2 adapter!

<comment><USER10> Those only work if the PS/2 device can 'switch' to USB mode. I very much doubt the CueCat could ever do this.

</comment></comment></comment></comment></comment><comment><USER11> > which led to me having 10 bottles of ketchup in my basement

I went through this problem for a while, the same with salad cream and toilet paper :)

Could also be useful to add:

* an attribute that indicates how much of a thing has been used

* an item's age or purchase date

* the expiry date or best before date (yes, yes...I know these things aren't precise, and I decide if something is still good on the basis of does it look ok? does it smell ok? and common sense when it comes to fish/meat)

For example...when I occasionally make hummus, my part-used jar of tahini paste ends up at the back of the cupboard where it gets forgotten about but is still within its use-by date.

On the next trip to the supermarket, where I include ingredients to make hummus, I end up buying another jar of tahini paste because a) I can't remember if I still have tahini paste and b) if I do remember about that jar, was it opened? how much is left? and is it still good?

Knowing the state of perishables, whether unopened or part used would help save on waste and save money on unnecessary purchases.

Also I think a better name would be "Personal Stock Control", "Storage System" makes me think of disks and data storage.

Just a thought or two.

<comment><AUTHOR> Haha, thank you for all the ideas. They are pretty cool! I knew I'm not the only one with this kind of problem :D

Thank you for the idea with the new name. You're right, it sounds a bit more suitable.

<comment><USER11> Now, just imagine if you could get it to order all the things you need and have them delivered :)

</comment></comment></comment><comment><USER12> Cool. Looks like the housing/case is 3d printed, but it looked odd and I didn't know what the "washing station" thing was. Now I learned about Polyjet 3D Printing.

<comment><AUTHOR> Thanks, the printer is an Objet30 3D Printer. The washing station is, like you probably already know by now, to get rid of the support material.

</comment></comment><comment><USER13> It might just be me, but I don't actually understand what the project is. The readme says since things about storage but I didn't get anything more.

<comment><AUTHOR> I'm sorry, i didn't explain it very well, i'll definitely fix that. Basically the problem was, that we had a lot of groceries in large amounts while the ones we needed weren't there at all. If we went shopping we mostly forgot to check what we already have and bought even more of the things we already had, forgetting the stuff we needed.

The Project therefore is a simple tool to scan your products and keep a list of the things you have (with the amount). If you're on your way to the grocery store and you realise, that you don't really know if you need this or that product, you can simply VPN into your home network and check the stuff you have at home.

Did this make it any clearer ?

<comment><USER14> This is a problem I solved with a piece of paper and pencil (or a note keeping app on my phone) :)

"I'm low on ketchup, better write that down."

I like the project, don't get me wrong, but for me personally it would just add a layer of complexity.

<comment><AUTHOR> Haha, yeah I absolutely understand that.

</comment></comment></comment></comment><comment><USER15> Interesting project. Though first thing I'd say would be that this seems like something that would be a natural for a touch screen. Given you're going to be pulling most of the info from bar codes, you're not going to be typing very long/often, and a keyboard would be added clutter for the majority of the time.

<comment><AUTHOR> Yes, i thought about that in the beginning too. The problem i had was, that if a product isn't already in the database (outpan), you have to enter the name to add it.

I really dislike capacitive displays, especially writing on them and i think a onscreen keyboard is also really annoying.

Right now i have a keyboard which has a little touchpad, to get rid of the separate mouse.

But i also would prefer a touchscreen. Being spoiled from the nice keyboards on smartphones and tablets, i couldn't live with a PC onscreen keyboard.

</comment></comment><comment><USER16> Wow, that is one expensive case. The cost of the material to print that on default settings on that printer is 150 EUR.

<comment><AUTHOR> Well, good point. Forgot to add that, good thing i hadn't to pay that :D

Where did you look that up?

<comment><USER16> The Objet software tells you how much material will be used, then just multiply with material price.

<comment><AUTHOR> Yes ok, thought you looked that up online.

</comment></comment></comment></comment><comment><USER17> This reminded me of HomeMirror [0].

[0] [https://github.com/HannahMitt/HomeMirror](https://github.com/HannahMitt/HomeMirror)

<comment><AUTHOR> Awesome project, would be interesting to add something like a leap motion to make it controllable without smearing the mirror :D

</comment></comment><comment><USER18> This is a cool project, but I guess it could be a phone app that your entire family could use collaboratively to scan, tag as used and add to a shopping list.

<comment><AUTHOR> Thanks, these are some pretty nice ideas right there!

</comment></comment><comment><USER19> Looks like a cool project. But do I see this correctly that every time you're adding AND removing something from your inventory, you need to scan it? :(

<comment><AUTHOR> Yes, that's the idea behind it. If you have an idea how to improve that, i would love to hear it

</comment></comment><comment><USER20> no finished picture?

<comment><USER21> A video wouldn't be out of order either.

<comment><AUTHOR> Good idea, will record one and add it to the project, Thanks

<comment><USER21> Thanks to you my sir.

</comment></comment></comment></comment><comment><USER22> Great project. Marking this as something to explore for our managing our office storage.

<comment><AUTHOR> Haha, thank you. Let me know if you come across problems or bugs.</comment></comment>


Ask HN: Who's using Clojure in production? - <AUTHOR> Who's using Clojure in production today and what are you using it for? I'm curious about the state of the ecosystem and its adoption today.<p>There are a lot of old threads (on HN[1] or Quora[2]) that ask this - but none of them seem to reflect latest on who's using Clojure in production in late 2014. The recent State of Clojure data [3] doesn't capture this either.<p>[1] https://hn.algolia.com/#!/story/forever/0/whos%20using%20clojure<p>[2] https://www.quora.com/Whos-using-Clojure-in-production<p>[3] https://cognitect.wufoo.com/reports/state-of-clojure-2014-results/ <comment><USER2> We're using Clojure at the University Health Network ([http://www.uhn.ca/](http://www.uhn.ca/)). Our team primarily develops mobile and web applications for clinical use. We started using it about 4 years ago, and now have a number of applications and services written in it.

We're primarily a Java shop and Clojure was appealing because it allowed us to leverage the existing ecosystem, tools, and libraries that we were already using. With Clojure, we were able to develop applications much more rapidly than with Java and we found that the applications were easier to maintain. The latter primarily comes from pervasive immutability and vast overall reduction in code.

We're currently exploring ClojureScript for the client side and already deployed a small app in production using Reagent ([http://reagent- project.github.io/](http://reagent-project.github.io/)). It's worked extremely well for our needs to far.

I was also able to release a number of libraries I developed for work as open source:

\- clj-pdf PDF generation - [https://github.com/yogthos/clj- pdf](https://github.com/yogthos/clj-pdf)

\- instant-pdf service - [https://github.com/yogthos/instant- pdf](https://github.com/yogthos/instant-pdf)

\- Selmer templating library - [https://github.com/yogthos/Selmer](https://github.com/yogthos/Selmer)

\- markdown-clj - [https://github.com/yogthos/markdown- clj](https://github.com/yogthos/markdown-clj)

\- reagent-forms - data binding library for Reagent - [https://github.com/reagent-project/reagent-forms](https://github.com/reagent- project/reagent-forms)

<comment><AUTHOR> This is awesome! Curious if you guys also use Luminus? What was the genesis of that?

<comment><USER2> I'm actually the author of Luminus, and it's used as our default template for web apps right now.

<comment><AUTHOR> (Yes, I realized and hence the question hehe. I've been bugging the list/github issues on luminus for some time now. Excellent project!)

<comment><USER2> Thanks! :)

</comment></comment></comment></comment></comment><comment><USER3> Interesting and relevant comment from cbrozefsky, which is marked dead.

ThreatGRID, now part of Cisco, uses clojure in our malware analysis and threat intelligence platform. It's a core part of our analysis engine, which examines all the things malware does and how to detect it on the rest of your systems. We've built a 1980s "expert system" startup using core.logic.

It's also the core of our API service, and the UI built on top of that. We use clojurescript extensively in the UI, and have been moving large parts of it to Om.

It is a key technology for us, letting us build better analysis tools, faster and more performant than other languages. We have clojure code in production both in our SaaS offering, and shipped to many large finance, government, and corporate customers around the world.

</comment><comment><USER4> At Tide Pool Capital we've been using Clojure for a trading platform on peer- to-peer consumer credit. The system has been in production since the summer of last year. Clojure has been a pleasure to use and the ecosystem has supported all of our needs: Postgresql, redis, rest, soap, 0mq, AWS, client/server, producer-consumer channels, concurrency, etc. Our server is nginx with Pedestal.

</comment><comment><USER5> My new startup Clubhouse ([http://www.clubhousehq.com](http://www.clubhousehq.com)) uses Clojure for the entire backend. Also, the data team at my last company Intent Media ([http://www.intentmedia.com](http://www.intentmedia.com)) used Clojure for most of their data analysis.

</comment><comment><USER6> It's Artem from Wildbit ([http://wildbit.com](http://wildbit.com)). We've been using Clojure in production since 2012.

[http://dmarc.postmarkapp.com/](http://dmarc.postmarkapp.com/) — free DMARC weekly digests and API. Clojure back-end + Javascript front-end.

[http://dploy.io](http://dploy.io) — a Ruby on Rails app featuring internal Clojure RPC built on top of clj-jgit and subversion-clj libraries (both currently supported by Wildbit).

The usage of Clojure at Beanstalk ([http://beanstalkapp.com](http://beanstalkapp.com)) has also been growing since the blog post already mentioned in this thread. It now powers our indexing infrastructure, provides internal RPC and runs sophisticated reports in the background.

</comment><comment><USER7> Major startups I know that are using Clojure are CircleCi and Prismatic.

I also know Walmart Labs has a team that does Clojure.

</comment><comment><USER8> we are using it at event fabric and we love it: [http://eventfabric.com/](http://eventfabric.com/)

some libs we use:

* immutant [http://immutant.org/](http://immutant.org/)

* prismatic's plumbing [https://github.com/Prismatic/plumbing](https://github.com/Prismatic/plumbing)

* korma [http://www.sqlkorma.com/](http://www.sqlkorma.com/)

* friend [https://github.com/cemerick/friend](https://github.com/cemerick/friend)

* metrics clojure: [https://github.com/sjl/metrics-clojure/](https://github.com/sjl/metrics-clojure/)

<comment><USER8> feel free to ask anything :)

<comment><USER9> also, do you have any references or examples of how exactly you use immutant? I looked into it but it seemed to complicated for the webapp I wanted to write, so I went with Hoplon instead. But immutant looks really powerful... I just can't imagine how I would take advantage of it.

</comment></comment></comment><comment><USER10> We use Clojure (in production, or almost) at Red Pineapple Media in Berlin, mostly for basic web dev stuff (compojure, http-kit, org.clojure/java.jdbc, cassaforte) and data analysis (Apache Spark, using flambo ([https://github.com/yieldbot/flambo](https://github.com/yieldbot/flambo)). We're building new services with it, but we also rewrite performance-critical parts of our backend from PHP to Clojure.

</comment><comment><USER11> We (Xcoo, Inc.) are using Clojure since 2013.

[https://xcoo.jp](https://xcoo.jp)

Our products using Clojure are :

\- "Chrovis", which is a bio-informatics web application that analyzes and visualizes huge genome data sets [https://chrov.is](https://chrov.is)

\- "Hacker News Hack", which is a web application that shows HN with categories and popularity [http://newshack.io](http://newshack.io)

</comment><comment><USER12> Teradata is using it for Loom - [http://www.teradata.com/Teradata- Loom](http://www.teradata.com/Teradata-Loom)

</comment><comment><USER13> I have worked in Yousee IT Innovation labs through 3.5 years where we had both clojure and datomic running in production.. The main part of the applications was integration type components coupled via hypermedia REST APIs. One of the most flexible application layout's I ever been working on. Lein and GO deployment..: [http://yousee.dk](http://yousee.dk)

</comment><comment><USER14> Here's a few:

\- Walmart Labs - [http://jobs.walmart.com/san-bruno/ecommerce/mobile- instore-s...](http://jobs.walmart.com/san-bruno/ecommerce/mobile-instore- software-\(clojure\)-engineer-jobs)

\- Staples - [http://careers.staples.com/sanmateo/](http://careers.staples.com/sanmateo/)

\- Climate Corp (now owned by Monsanto) - [https://github.com/TheClimateCorporation](https://github.com/TheClimateCorporation)

\- RoomKey [http://www.colinsteele.org/post/27929539434/60-000-growth- in...](http://www.colinsteele.org/post/27929539434/60-000-growth-in-7-months- using-clojure-and-aws)

\- Puppet Labs - [http://puppetlabs.com/blog/new-era-application-services- pupp...](http://puppetlabs.com/blog/new-era-application-services-puppet-labs)

\- Soundcloud - [http://blog.josephwilk.net/clojure/building-clojure- services...](http://blog.josephwilk.net/clojure/building-clojure-services-at- scale.html)

\- Netflix - [https://speakerdeck.com/daveray/clojure-at- netflix](https://speakerdeck.com/daveray/clojure-at-netflix)

\- eBay - [https://www.linkedin.com/jobs2/view/26386571](https://www.linkedin.com/jobs2/view/26386571)

\- Two Sigma - [https://www.youtube.com/watch?v=YHctJMUG8bI](https://www.youtube.com/watch?v=YHctJMUG8bI)

\- Consumer Reports - [http://www.meetup.com/denofclojure/messages/boards/thread/47...](http://www.meetup.com/denofclojure/messages/boards/thread/47511532/)

\- LivingSocial - [https://www.linkedin.com/jobs2/view/19995533](https://www.linkedin.com/jobs2/view/19995533)

\- Factual

\- Thoughtworks - [http://thoughtworks.github.io/p2/issue09/two-months- early/](http://thoughtworks.github.io/p2/issue09/two-months-early/)

\- Daily Mail - [http://www.pitheringabout.com/?p=1018](http://www.pitheringabout.com/?p=1018)

\- MixRadio - [http://dev.mixrad.io/blog/2014/10/19/Clojure- libraries/](http://dev.mixrad.io/blog/2014/10/19/Clojure-libraries/)

\- Prismatic - [http://blog.getprismatic.com/blog/2013/1/14/bringing- functio...](http://blog.getprismatic.com/blog/2013/1/14/bringing-functional- to-the-frontend-clojure-clojurescript-for-the-web)

\- Pivotal Labs - [http://www.pivotaltracker.com/community/tracker- blog/generat...](http://www.pivotaltracker.com/community/tracker- blog/generative-testing)

\- Beanstalk - [http://blog.beanstalkapp.com/post/23998022427/beanstalk- cloj...](http://blog.beanstalkapp.com/post/23998022427/beanstalk-clojure-love- and-20x-better-performance)

\- uSwitch

\- CFPB (Credit Financial Protection Bureau) - [https://cfpb.github.io/articles/seeking-clojure- developers-t...](https://cfpb.github.io/articles/seeking-clojure-developers- to-work-on-qu/)

\- Braintree Payments - [https://speakerdeck.com/davidpick/building-a-data- pipeline-w...](https://speakerdeck.com/davidpick/building-a-data-pipeline- with-clojure-and-kafka)

\- Outpace

\- ViaSat / Lonocloud

\- 8th Light

\- Main Street Genome

\- FarmLogs

\- nilenso

\- BrickAlloy

\- Mastodon C

\- Nubank

\- Democracy Works

\- World Singles

\- Sonian

\- Vital Reactor - [https://www.youtube.com/watch?v=yroKdhAt8as](https://www.youtube.com/watch?v=yroKdhAt8as)

\- DiligenceEngine - [http://blog.diligenceengine.com/2014/08/12/were-hiring- for-t...](http://blog.diligenceengine.com/2014/08/12/were-hiring-for-two-new- clojure-jobs/)

\- IB5k - [https://groups.google.com/d/msg/clojure/XMKe4v7k5g8/Hao7TuFb...](https://groups.google.com/d/msg/clojure/XMKe4v7k5g8/Hao7TuFbCXIJ)

\- Listora - [https://github.com/listora](https://github.com/listora)

\- BUGS Bioscience - [https://www.linkedin.com/jobs2/view/11032601](https://www.linkedin.com/jobs2/view/11032601)

\- Cognitect and Datomic of course :)

<comment><USER15> Alex, there is also a small company called Helpshift that's using Clojure in production since 2009 :-)

<comment><USER14> Thanks! I didn't have any hope of getting them all!

</comment></comment></comment><comment><USER16> We use Clojure, ClojureScript and Datomic at [https://www.cognician.com](https://www.cognician.com).

I wrote recently about our newer generation efforts here: [http://www.stuttaford.me/2014/09/24/app-and-dev-services- wit...](http://www.stuttaford.me/2014/09/24/app-and-dev-services-with- trapperkeeper/)

</comment><comment><USER17> We use Clojure in production at Shareablee with Storm.

[http://www.shareablee.com/](http://www.shareablee.com/)

</comment><comment><USER18> Outpace is a Clojure/CLJS shop - [http://www.outpace.com/](http://www.outpace.com/)

</comment><comment><USER19> Buy Happy is using Clojure + ClojureScript in production.

[http://buyhappy.co/](http://buyhappy.co/)

Clojure web server backend (running on Heroku). ClojureScript/Om frontend, which connects to server with Sente.

We also have a browser extension (Chrome/Safari/Firefox) written in ClojureScript.

</comment><comment><USER20> We use Clojure in production to run Database Labs, [https://www.databaselabs.io](https://www.databaselabs.io) . The account management and billing web app is Clojure + Postgres, proxied through nginx. I couldn't be happier with Clojure for webapps.

</comment><comment> the-kenny We ([http://bevuta.com/](http://bevuta.com/)) use ClojureScript for a front- end project relying heavily on Om ([https://github.com/swannodette/om](https://github.com/swannodette/om))

</comment><comment><USER21> ThreatGRID, now part of Cisco, uses clojure in our malware analysis and threat intelligence platform. It's a core part of our analysis engine, which examines all the things malware does and how to detect it on the rest of your systems. We've built a 1980s "expert system" startup using core.logic.

It's also the core of our API service, and the UI built on top of that. We use clojurescript extensively in the UI, and have been moving large parts of it to Om.

It is a key technology for us, letting us build better analysis tools, faster and more performant than other languages. We have clojure code in production both in our SaaS offering, and shipped to many large finance, government, and corporate customers around the world.

</comment><comment><USER22> I work for ThoughtWorks and we have a number of client's who use Clojure in production. This is one example from Australia - [http://www.thoughtworks.com/clients/ioof](http://www.thoughtworks.com/clients/ioof)

</comment><comment><USER23> We're using Clojure in a couple small services behind [https://cardforcoin.com](https://cardforcoin.com) and [https://foldapp.com](https://foldapp.com)

</comment><comment><USER24> Silverline Mobile ([http://silverline.mobi/](http://silverline.mobi/)) uses Clojure in production - managing data from sensors installed in the homes of senior citizens in Singapore.

</comment><comment><USER24> We're using Clojure in production at Datacraft ([http://www.datacraft.sg](http://www.datacraft.sg)).

Main usage is on the server side: for web applications, APIs and data analytics back ends.

</comment><comment><USER25> At akvo.org we are using Clojure in production and hopefully soon also Clojurescript.

We are using Clojure on top of existing Java functionality, and we're moving our Ember based Dashboard over to Clojurescript/Om.

</comment><comment><USER26> [http://devartcodefactory.com](http://devartcodefactory.com) is 100% Clojure + Clojurescript (+ open source) and one of the few examples deployed on Google AppEngine

</comment><comment><USER27> SoundCloud has Clojure in production

</comment><comment><USER28> I wonder how much Clojure is being used at Twitter, given that they acquired Backtype and then open sourced Storm (as detailed by Nathan Marz)

</comment><comment><USER29> OpenSensors.io is a clojure & clojurescript shop

</comment><comment><USER30> The backend of Leancloud.cn is built with Clojure.

</comment><comment><USER31> paper.li is almost fully clojure. exoscale.ch runs critical infrastructure on clojure.

walmart labs has been mentioned, the climate corporation (recently bought by monsanto) is another well-known one.

Here in Switzerland I can count 4 others smaller companies and at least a very big telco.

If you start counting every company relying on riemann for production monitoring that adds quite a few :-)

</comment><comment><USER32> DataSnap.io [http://www.datasnap.io/](http://www.datasnap.io/)

</comment><comment><USER33> We have build a proprietary RTB bidder written in Clojure and powered by custom machine learning algorithms. We use it for mobile customer acquistition and retargeting services - [http://www.adgoji.com](http://www.adgoji.com)

</comment><comment><USER14> I've captured the companies listed here on a page at [http://clojure.org/Companies](http://clojure.org/Companies) \- ping me at the email address listed there if you'd like to be added/removed/changed.

</comment><comment><USER34> Deutsche Bank ([http://blog.malcolmsparks.com/?p=134](http://blog.malcolmsparks.com/?p=134))

CitiGroup as well, someone who worked there told at euroclojure they have 150 Clojure developers.

</comment><comment><USER35> In Amsterdam, [http://www.adgoji.com/](http://www.adgoji.com/) and [http://screen6.io](http://screen6.io) uses Clojure heavily.

<comment><USER36> Also in Amsterdam, we at [http://www.studyflow.nl/](http://www.studyflow.nl/) have been using Clojure & ClojureScript for most of our new development.

</comment></comment><comment><USER37> stylefruits uses Clojure almost exclusively these days. [https://www.youtube.com/watch?v=Hv4slaRydRM](https://www.youtube.com/watch?v=Hv4slaRydRM)

</comment><comment><USER38> We use it at Adaptly for data processing and to build http APIs

</comment><comment><USER39> The guys at MeeWee are using Clojure full stack. Clojure, ClojureScript and Datomic. [https://app.meewee.com](https://app.meewee.com)

</comment><comment><USER40> iPlant Collaborative - [http://www.iplantcollaborative.org](http://www.iplantcollaborative.org)

</comment><comment><USER41> Bittorrent uses both Clojure & ClojureScript in production. Has for over two years.</comment>


Love shell commands? See specifically how Xiki is a better way to run them. - <AUTHOR> https://www.youtube.com/watch?v=v79TmaDieaA

<comment><AUTHOR> After some pretty brutal feedback about my video last week, this is my Hacker News focused version. It gets right to the point.</comment>


The Problem with Linux Kernel Documentation, and How We're Fixing It - <AUTHOR> https://blogs.s-osg.org/problem-linux-kernel-documentation-fixing/ <comment><USER2> Related: Tomorrow [29-SEP-2016] afternoon at 15:00-15:40 CET, Jon Corbet of LWN, is giving a talk[1] at Linux Recipes conference in Paris on this subject.

URL[2] to live streaming.

[1] [https://kernel-recipes.org/en/2016/talks/kernel- documentatio...](https://kernel-recipes.org/en/2016/talks/kernel- documentation-what-we-have-and-where-its-going-2/)

[2] [https://air.mozilla.org/kernel-recipes-2016-09-29-PM- Session...](https://air.mozilla.org/kernel-recipes-2016-09-29-PM-Session/)

</comment><comment><USER3> The main problem is not the format of the documentation, but lack thereof. Many important functions and high level implementation tasks are not documented or the docs are inadequate.

<comment><USER4> Perhaps there's little documentation _because_ it has a poor format.

<comment><USER5> Not because of Programmers who think that the time spent writing documentation would be better spent programming some more? ;)

<comment><USER6> No reason it couldn't be both, I suppose.

<comment><USER7> Definitely the case in my office. A couple of opinionated and (relatively) senior devs that think the code is the documentation. No, I can't read this 40 yo fortran code and use it as the basis for a new program on a different architecture. It uses gotos and variables like "yxtgn" that mean nothing to the reader (turned out y meant it was an integer, weird). I spent a month on that because there was no documentation, which took up a page once I was done writing it after my reverse engineering effort.

And then documentation, where it exists, is often poorly CM'd word documents, and poorly OCR'd PDFs (or doc->pdf that somehow lost the ability to be searchable and selectable text, what option did they select?!?).

The offending systems are only maintainable because a few people haven't retired (< 1 year left for several of them) and sheer force of will for the rest of us.

<comment><USER8> > It uses gotos and variables like "yxtgn" that mean nothing to the reader > (turned out y meant it was an integer, weird)

It meant "ynteger". Elementary, my dear Watson.

</comment></comment></comment></comment></comment></comment><comment><USER9> They missed a format that's ubiquitous, has a lot of formatting options, and has search facilities. Manpages. When someone's looking for a piece of documentation, they are usually working on a system as they do it, and man -k <thing> is a lot easier to remember than some other search tool that requires its own set of packages, etc.

<comment><USER10> The problem with that approach is that you are limiting yourself to fundamentally primitive documentation (and by primitive I mean non- interactive). Granted, for a kernel it might be less important, but it's great when there is a good architecture diagram/image instead of 7 paragraphs.

<comment><USER9> Manpages can have a rather large amount of interactivity. Documents can be formatted as text, as HTML, with links, etc. The problem is that manpages are an afterthought in too much of the Linux ecosystem, so people have low expectations and low beliefs in what they can actually do. They can have tables, they can have equations, they can have graphics.

<comment><USER10> Out of genuine curiosity, could you link me to an existing guide from the Linux community that is based on manpages and features images and/or other interactive content?

<comment><USER11> Not exhaustive, but I've written code that processes 50,000 or so man pages and haven't hit one.

</comment></comment></comment></comment></comment><comment><USER12> Happy to see they pick ReST over MD. ReST is vastly superior for these purposes, in my experience.

<comment><USER13> Mind explaining why? I like Markdown but would like to know what ReST does better.

<comment><USER14> ReST can be better extended without creating a variant of the markup language [1]. Extension support is first class [2], and it is by that means that a good number of the core features are implemented.

[1] For example, github flavour, stackoverflow flavour, reddit flavour, ...

[2] Roles and directives.

</comment></comment></comment><comment><USER15> I find it surprising that Michael Kerrisk's Linux man-pages project isn't mentioned here [1]. He and other contributors done a major job documenting the Linux man pages. It's usually the first place I go to when I need to read up on the Kernel APIs or C libraries.

\- [1] [https://www.kernel.org/doc/man-pages/](https://www.kernel.org/doc/man- pages/)

</comment><comment><USER16> Are there any specification for ReST? With tests that confirm if a parser works?

Otherwise it will be harder to get more tools.

</comment><comment><USER17> They should contact the freebsd-doc@ folks.</comment>