Why did Clojure gain so much popularity? - <AUTHOR> https://www.quora.com/Why-did-Clojure-gain-so-much-popularity/answer/Ag-Ibragimov <comment><USER3> I work at Walmart Labs. Clojure is super popular[1] in Walmart Labs. Clojure is fun and importantly it is a very productive language to work with. This gain in productivity comes from less state, thus easy to debug and fix, and functional approach, so the functions do what exactly what they are supposed to and there are no hidden surprises.

Less state or immutability means concurrency is easy. Easy concurrency means we can scale[2] applications with ease. I mean ease of development. It takes less work, less mental effort to take something that works for a single thread and make it work in a multithreaded and/or distributed manner over hundreds of thousands of cores. Debugging is easy too. P1 incidents for a microservices written in Clojure takes less time to debug compared to those written in other languages. So no wonder most of our mission critical services are written in Clojure.

For a complex environment where thousands of microservices are deployed on hundreds of thousands of computes, Clojure has been super successful.[3]

[1]: [https://github.com/walmartlabs?language=clojure](https://github.com/walmartlabs?language=clojure)

[2]: [http://blog.cognitect.com/blog/2015/6/30/walmart-runs- clojur...](http://blog.cognitect.com/blog/2015/6/30/walmart-runs-clojure-at- scale)

[3]: [https://clojure.org/community/success_stories](https://clojure.org/community/success_stories)

<comment><USER4> I love how you mentioned that Clojure is fun!

We use Clojure at my work as well, and ya, everything else you said afterwards is true as well. Clojure is a great productive language. It can scale, is very comparable to Java in performance, simple to maintain, has a complete ecosystem, is batteries included, etc.

But most convincing! It's just so much fun!!

Being fun is an undervalued quality of a language in my opinion. That joy you get from using it actually translates in the quality of the work you do. So it's not an intractable thing, the fun is good for you and for the product!

<comment><AUTHOR> This can't be said enough. At the end of the day programming is done by human beings, and it needs to be treated as a human endeavor. If I enjoy what I'm doing I'm going to do it better, it's really that simple. There is actual science to back up this idea as well [http://neverworkintheory.org/2014/05/01/happy-sw-devs- solve-...](http://neverworkintheory.org/2014/05/01/happy-sw-devs-solve- problems-better.html)

</comment></comment></comment><comment><USER5> Clojure is particularly well suited - at least Rich Hickey would claim - <USER2> real world applications with unsafe or unstructured inputs. I.e. complex programs that receive or pull data from external and loosely-typed sources. A lot of web programming falls into this category. Why is it well suited to these? Because it is dynamic, and offers rich runtime solutions to validation (Spec), has immutable data structures, safe and relatively simple concurrency primitives, and has the expressivity of a lisp. It also has access to the vast array of JVM libraries which helped early adoption (but possibly hindered it in the longer term?!).

<comment><USER6> Although I love working with Clojure more than any other language it's relationship with its host is somewhat schizophrenic. Calling Java classes from carefully-crafted functional code is like pouring tomato ketchup over a lemon sorbet. Thankfully there are about 23,000 pure Clojure libraries at clojars.org to help my Clojure code stay functional.

<comment><USER7> It depends on what your requirements are. Through the years, I found it easier to write reliable code by just skipping the Clojure wrapper libraries (e.g. using Kafka directly rather than a wrapper): it's easier to "escape" into functionality the wrapper doesn't offer, and it's typically more performant as well.

</comment></comment></comment><comment><USER8> To be perfectly honest, Clojure's biggest mistake, from my point of view, was to be so heavily JVM-dependent.

Yes, in certain environments Java is king and a ton of people use it, it's battle-proven, etc. But so are other stacks.

Clojure, as a programming language, sparks a lot of joy and is a lot of fun to use and reason about. Yet in reality, when working in a production environment, you're basically fighting the always-memory-hungry JVM.

Just give me Clojure running on BEAM and I'll take it over anything in this world.

<comment><USER9> I think it's the other way around: Clojure gained more exposure than past Lisps because it runs on the JVM.

But it's still definitely niche and hardly used anywhere.

<comment><USER10> I think this is accurate (in terms of exposure, not that it's hardly used). As soon as it was possible for other languages to run on the JVM, the huge amount of developers working around JVM infrastructure that didn't like the sometimes painful experience of working with Java, started looking at alternatives.

Groovy, Scala and Clojure were the early contenders that people were exploring and Clojure seems to have won a lot of mindshare.

The thing about Java isn't the language or the JVM it's the App Servers. Enterprises have invested heavily in the App Server infrastructure for deploying JVM based code from monitoring, training, etc.

Throwing all that away to use a non-JVM language is a REALLY hard sell. Those app servers are very well done.

Running on the JVM made using Clojure, Scala and Groovy possible in places where other languages wouldn't have been. In the early 2000s, it was Java and everything else.

The .NET ecosystem was awful at that time. The programming world was essentially, Java, Perl and PHP 4 in terms of enterprise usage. People said the words "Enterprise Java Beans" without a chuckle.

People were HUNGRY for better options.

Now you've got a solid C# ecosystem, Elixir, Go, a dominant Python ecosystem, significantly more polished PHP, K8's & Docker that make automating the infrastructure around all different languages consistent...it's just a different world.

<comment><USER11> >Groovy, Scala and Clojure were the early contenders that people were exploring and Clojure seems to have won.

I love Clojure and hope it gains more mindshare, but I don't think this is accurate. Scala currently enjoys quite a lot more industry use than Clojure does, for instance there are currently roughly 15x as many postings mentioning Scala as there are Clojure (source: Linkedin.ca).

<comment><USER6> Same in London. Search indeed.co.uk for "title:Clojure" and there are on average no more than 6 unique results. Outside London the rest of the UK shows next to nothing. About 6 years ago Clojure dojos and meetups were well- attended but even then the numbers were a fraction of the equivalent Scala events. Nowadays you're lucky to get a handful attendees at London Clojure events which is a real shame as it suggests Clojure is disappearing into a very small niche.

<comment><USER12> Yes, it's niche, but remove "title:".

</comment></comment></comment></comment></comment></comment><comment><USER13> Interestingly, Clojure is associated with the highest salaries worldwide[1], and is used by developers with the most years of professional coding experience[2], according to the StackOverflow Developer Survey 2019.

[1] [https://insights.stackoverflow.com/survey/2019#technology-_-...](https://insights.stackoverflow.com/survey/2019#technology- _-what-languages-are-associated-with-the-highest-salaries-worldwide)

[2] [https://insights.stackoverflow.com/survey/2019#developer- pro...](https://insights.stackoverflow.com/survey/2019#developer-profile-_- years-coding-professionally)

<comment> dan-robertson These surveys seem (increasingly) biased towards certain types of development. Specifically, web development. I couldn't find a single language I regularly or irregularly use on this page (the closest thing I could find is Emacs). Also the sample size for Clojure developers is smaller than other languages. It's not obvious to me why the bar should be raised at a certain point (e.g. letting in slightly niche Clojure programmers but not other more niche things).

I don't want to imply that these surveys are rubbish, just that I do not think they give the whole picture

<comment><USER14> The Quora article mentions that clojure took off in the fintech industry. People get paid a lot in this field, so if there is some way to control for this niche, the stats will be more accurate.

</comment></comment></comment><comment><USER15> Absence of syntax! I really wish every language were a lisp. Like, Rust, the lisp, Swift, the lisp. Who needs rules of precedence and associativity and statements vs expressions and all the other stuff that languages that aren't lisps impose on you? Just stick an expression in some parentheses! And then put that in another expression!

<comment><USER16> (find (most people) difficult (without (infix operations) (to expressions write)))

<comment><USER17> In 99% of programming languages, infix operations are only used for arithmetic -- and more than 99% of the programming I do doesn't involve that. Even the numerics software I've written is >90% non-numeric parts.

Arithmetic doesn't even look _right_ in programming languages with infix operators. Go to the "Chalk is still one of the primary tools of mathematicians" article here, and try typing the inequality in Java. Mathematicians aren't writing "Math.floor()" and "% 2" on their blackboards.

I think you're optimizing for the wrong thing. Arguing that we need infix operations for 1% of our programs, so that arithmetic looks like how we entered it on a TI-81 or Apple II, is a false economy. It was a good tradeoff 25 or 50 years ago, but the majority of programming has moved past writing programs in terms of arithmetic on registers.

That said, there is a nifty macro [1] which adds infix support to Clojure, if you really want that. It even supports symbols like "√", unlike any other language I can think of!

[1]: [https://github.com/rm-hull/infix](https://github.com/rm-hull/infix)

<comment><USER16> > In 99% of programming languages, infix operations are only used for > arithmetic

I've been spoiled by Scala, but certainly most languages allow a "subject.verb(object)" style for general-purpose code, and that reads a lot better (particularly for those looking from the business domain) than "(verb subject object)".

> It even supports symbols like "√", unlike any other language I can think of!

Heh, again I'm spoiled by Scala, where √ is just another method/operator (there's no distinction) name if you want it to be.

<comment><USER17> > most languages allow a "subject.verb(object)" style for general-purpose > code, and that reads a lot better

Why do you think this?

Programming isn't natural language, and I don't even know what the "subject" or "object" is in most cases.

<comment><USER16> > Programming isn't natural language

It's not, but it should be close; readability is important, and particularly when you want to express domain logic it's important to be able to hew closely to the actual language of the domain. Arithmetic is the most obvious example of this but it's just as true for other domains.

<comment><AUTHOR> You're right readability is important, and Scala fails terribly in that department. I worked with Scala for around 6 months or so at one point, and I was still constantly looking things up after months of using the language. There's simply too much syntax and weird quirks in the language that it becomes impossible to keep it all in your head.

<comment><USER16> Not my experience - I found Scala's syntax is a lot more consistent than most mainstream languages (though, yes, it certainly doesn't go as far as lisps). Operators are just normal methods. Rather than complex rules about which constructs require braces, everything permits an expression or you can put a braced block of statements anywhere you could put an expression. Rather than a bunch of different special case syntaxes for collections / async / possibly- absent values, you have a single lightweight syntactic sugar (for/yield) that translates directly into plain old method calls. There are some libraries out there that make poor choices of method name, but that's about all.

<comment><AUTHOR> My experience with Scala matches this pretty closely [https://www.reddit.com/r/scala/comments/4246qc/heres_why_sca...](https://www.reddit.com/r/scala/comments/4246qc/heres_why_scala_sucks/)

<comment><USER16> That's a strange set of complaints for a clojure advocate, since most of what they're complaining about is not too much syntax but too little - no mandatory braces, mandatory brackets, mandatory types. Indeed "a -> b" for "(a, b)" is not syntax or even a macro, but just a function.

_ is genuinely costly syntax, as are by-name parameters (though less costly in an age of IDEs). I consider _ to be worth its while (indeed I miss it a lot when writing lambdas in any other language); if you're going to have syntax in your language at all then it's one of the most general-purpose, effective constructs I've seen.

<comment><AUTHOR> The problem isn't whether there's too much or too little, it's that the syntax is incredibly inconsistent. There are a million ways to do anything, and you have to juggle it all in your head. Consider stuff like this:

[https://twitter.com/pembleton/status/1116343189437394944](https://twitter.com/pembleton/status/1116343189437394944)

A new line can be significant syntax in Scala!

With s-expressions, all of this mental overhead goes out of the window. I have regular boring syntax where pretty much everything works the same way. It's incredibly liberating. On top of that, s-expression syntax facilitates structural editing, where I'm manipulating the code tree semantically as opposed to thinking about moving lines of text around.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Did it though? Most of the time when I mention Clojure, people think I mean "closures".

Our whole stack is Clojure/Clojurescript. Clojure has helped reduce bugs and improve stability across the board.

I enjoy writing it everyday and wish more people would give it a shot.

<comment><AUTHOR> I don't think Clojure needs to boil the ocean to be successful. We already have a community of many thousands of developers with lots of very smart people in it. At this point there's enough mind share to keep it going indefinitely.

At the same time Clojure benefits from being a hosted language. We don't have to build everything from scratch, instead we leverage two of the biggest ecosystems and reap all the benefits for free.

It's still a very niche language to be sure, but from what I've seen there has been a lot of commercial adoption in the last couple of years. There are new a few consulting companies, such as JUXT and Metosin, that are focusing exclusively on Clojure consulting. A lot of the libraries in the ecosystem are now maintained by these companies as opposed to individuals. There are also efforts like Clojurists Together for funding Clojure projects sustainably. These efforts would not have been possible without growing commercial use with companies willing to donate money.

So more companies using Clojure directly leads to a better ecosystem, and that in turn makes the language more attractive. The state of tooling and libraries is dramatically better today than it was even a couple of years go. I'm excited to see how the ecosystem grows this year.

One of the projects I'm most excited about is [https://cljdoc.org/](https://cljdoc.org/) which aims to provide a one stop shop for polished Clojure library documentation. I just saw a presentation about it at Clojure North, and I was very impressed with where it's at already.

<comment><USER18> Thanks for your reply. I am very glad to hear this! Cljdoc looks great as well - much needed :)

Btw, thank you for all your open source projects and comments on various GitHub repos.

<comment><AUTHOR> Thanks, glad to hear it's coming in handy. :)

</comment></comment></comment></comment><comment><USER19> Clojure builds on Lisp that its creator wanted a modern functional programming language that runs on the JVM. Clojure also has immutable data structures Link to Githut programming language popularity on Github, compare the number of open issues per repository for different programming languages. Then you will find that Clojure, Lisp and Haskell has relatively fewer issues compared to other more popular languages. [https://githut.info/](https://githut.info/)

Lisp is used in AI. [https://medium.com/ai-society/the-lisp-approach-to-ai- part-1...](https://medium.com/ai-society/the-lisp-approach-to-ai- part-1-a48c7385a913) [https://ai.stackexchange.com/questions/2236/why-is-lisp- such...](https://ai.stackexchange.com/questions/2236/why-is-lisp-such-a-good- language-for-ai)

</comment><comment><USER20> > But that's not how programming being taught and mentored today - it's more > like "steal it from StackOverflow, adjust it to your needs. Do what everyone > is doing. It's okay to follow the hype".

Oof. So true, I hate this field. But I guess you could say similar of almost anything. Maybe I just hate humanity.

<comment><USER21> Soft-misanthropy is healthy enough, just as long as you don't go full- misanthrope. I hope.

You left out the immediately following bit, "Experienced software developers don't chase the hype". I cringed. But maybe if my interpretation of the overall point is correct, I can agree with a point that Clojure attracts grumpy programmers who have Seen Things and gives little lip service to beginning devs.

<comment><USER22> Why cringe? Hype creates burnout. The churn is absolutely untenable in the UI space right now and hasn't shown signs of slowing down anytime soon.

Where I work we have 3-4 different ways of accessing our monolithic backend, and on top of that 3-4 different ways of accessing and manipulating application state.

It drives me up the fucking wall.

I'm not sure I agree with the little lip service statement. I feel like the feelings are most likely mutual.

Stable systems that don't need constant heroism and don't diverge much from original choices made at the architecture level don't make for good places for juniors to make mistakes and learn from them.

<comment><USER21> I cringed because it's not my experience that experienced devs are immune to hype, it's an orthogonal characteristic. I also find it somewhat logically inconsistent for there to exist a push for teaching/mentoring The Way of the Hype if seniors haven't bought into it themselves.

</comment></comment></comment></comment><comment><USER23> For me it was the draw of Datomic and DataScript. Clojure is a neat language, but I feel like how we store, retrieve and transmit data is vastly more important.

<comment><USER12> Take a peek at Crux from Juxt. Really exciting times happening on the data front.

<comment><AUTHOR> link to the repo [https://github.com/juxt/crux](https://github.com/juxt/crux)

<comment><USER24> One day old, 4 comment HN discussion of it: [https://news.ycombinator.com/item?id=19714073](https://news.ycombinator.com/item?id=19714073)

</comment></comment></comment></comment><comment><USER25> I'm doing a series on concurrency models at the moment for personal professional development, and I recently reviewed Clojure and its native ability to separate identity from state. It's a very properties-based and specifications-based language, and the thing about properties and specifications of languages are that they're nigh impossible to retrofit at a later point in time. Other languages need to have external tooling or frameworks on top for things Clojure supports out of the box, and even then those frameworks may not be as reliable as something guaranteed on a language level.

It's actually a pretty sizable moat. Python broke encodings between 2 and 3 and split the community for at least a decade. Some companies will likely never be able to migrate from Python 2 to Python 3. Now imagine breaking now `dict` works.

[https://bytes.yingw787.com/posts/2019/01/26/concurrency_with...](https://bytes.yingw787.com/posts/2019/01/26/concurrency_with_python_identity_and_state/)

</comment><comment><USER26> I attribute it to two things. It's the least lisp-y of the lisps meaning it came with so much that you didn't have/want to make a (different) dsl on every project. The second is the jvm: partly from interoperability but even more so from being just another jvm language with packaging/deployment and some ops already paved.

</comment><comment><USER27> Rich Hickey gives the best talks. It's that simple.

<comment><USER28> Was that a pun? ;)

</comment></comment><comment><USER29> Add onto the very real facility for being a highly reliable and productive tool for doing data acquisition, transformation and distribution it makes programming FUN!

</comment><comment><USER6> Clojure suffers from a lack of ambition, at least as far as adoption is concerned, and I think that's why many leave the community. Rich Hickey is more than happy with Clojure's current reach which says everything when you look at Clojure's abysmal level of adoption. It could be argued that Matz and Rich are both similarly idealistic language designers but Matz recognises the danger of Ruby being left behind without improvements to the language and Ruby's community is already much bigger than Clojure's.

Although there's Luminus web frameworks are generally frowned upon in Clojure- land which concedes mindshare to other languages which recognise the importance of frameworks and killer apps. With so many languages competing for mindshare it is that much easier today for a language, however original and superior, to be sidelined by paying customers. For developers looking for a language which will also help pay the bills Clojure is unfortunately not an option.

<comment><USER4> Well, its got a chicken and egg problem here.

The chickens, experienced Clojure devs, don't need a framework, and are easily able to do whatever they want and use Clojure to pay their bills. Thus they're not motivated to build frameworks.

On the other hand, the eggs, devs unfamiliar to Clojure, find it difficult to get anything done in Clojure, and are looking for frameworks that abstract away some of the expertise needed to manage a full Clojure web app. They're hoping they can start using it to pay their bills before they become an expert in it, through the use of a framework.

I'm not sure how the future will unfold here.

<comment><AUTHOR> The way we build web apps is changing away from back-end frameworks in general. Things like micro-services are a good example of that.

Traditionally, web was all about serving static documents, and server side rendering model is a perfect fit for that. However, nowadays we also have web apps that are highly interactive.

This requires moving away from the thin client model. Server-side rendering approach is inherently at odds with that because HTTP is a stateless protocol.

So, the modern way to write web apps is to have a thick client that manages things like views, business logic, and state in one place. With this approach you no longer need a complex framework on the back-end because vast majority of the complexity moves to the client. The server is mostly responsible for things like data governance. The other driver here is horizontal scalability. It's much easier to scale small stateless services than a giant monolith.

Clojure started getting a lot of use in the wild right around the time when SPA model started taking off, and I think that the ecosystem reflects that. We tend to have fairly light weight back-end architecture coupled with a thick client on the front-end.

<comment><USER30> Moving business logic to a js client looks like a crazy gift to any ill intentioned actor.

<comment><AUTHOR> Not sure how that's the case since authentication and data governance is done by the server. This is just the difference between thin and thick client models. Any app on a phone is a thick client as well, and uses exactly the same model as SPA.

</comment></comment></comment></comment></comment><comment><USER31> I thought that Clojure was losing its buzz in recent times. Perhaps it is that even though the core language is elegant its ecosystem of leiningen, maven for dependencies, etc, and the whole brittle emacs-cider-nrepl chain is detracting from its core strengths.

And poor startup times, and unhelpful error messages (though I hear there has been some improvement in recent versions).

<comment><AUTHOR> You can use pretty much any popular editor, such as Atom, VS Code, IntelliJ, and even VIM, for Clojure development nowadays. I personally use IntelliJ and I've never touched Emacs for any serious projects.

I'm also not sure what the problem with Leiningen is, it's a hell of a lot better than most build tools I've used. If you want to see brittle, you should take a look at NPM clusterfuck. Yet, people happily use that mess all the time.

Poor start up time is typically not an issue for web applications, which is the primary domain Clojure is used in. Meanwhile, at dev time you're using the REPL, so you're not restarting your app all the time. I often have an instance of the app running for weeks on end as I work on it. For environments where start up time matters we now have ClojureScript on Node and GraalVM.

The error messages are indeed a huge improvement in Clojure 1.10.

<comment><USER31> Leiningen on Windows seemed like an after thought.

Even on Linux I have run into package management issues with lein1/lein2. I should say a build tool should largely be stable, not changing it behavior. On many functions like how you use local jars the features and methods have changed drastically at various points of time in Clojure/lein. This kind of churn has even effects like invalidating much documentation already written, and many stack overflow answers too. Why should an application developer be distracted by issues like these?

Most importantly if Clojure development is essentially depending upon lein, then I feel it should be distributed with Clojure itself. And emacs, cider, nrepl and lein chain has so many parts which are getting version upgrades independently, it breaks frequently for the user, functionality that was working suddenly stop working after an upgrade and you have to debug why it stopped working. Also I wonder how complicated it might be to set up the whole chain on a Windows machine.

<comment><USER32> The Windows experience with leiningen can be pretty good when kept up to date, which can be done easily using [https://scoop.sh/](https://scoop.sh/) to install it and update it once in a while

</comment></comment></comment></comment><comment><USER33> It didn't gain any popularity with me, since I had to debug it once. Most Clojure code is just a collection of overly clever recursive subroutines. In the end I rewrote the code in Java. It was shorter, easier to read and probably more performant than the same code in Clojure. Don't believe the hype. Clojure has some nice constructs for concurrent programming, but most of them are available also in Java since version 8, or are available as some external package. In the end programming in Clojure will just make your project more expensive, as good Clojure programmer are a rare species. The small advantages of smart Clojure constructs won't outweight the costs of maintaining Clojure code in the long run. The same is actually true for Scala.

<comment><AUTHOR> I'm sorry, but as somebody who's been working with Clojure professionally for nearly a decade I have to say that this is just utter nonsense.

</comment></comment><comment><USER34> Summary: The JVM made Clojure popular. The JVM made Clojure hated.

<comment><USER35> Yeah, haters gonna hate - it's human's nature. Give a man a powerful tool that solves lots of problems with two* most popular platforms today: Java and Javascript and they still will be complaining.

* actually three - if you include CLR

</comment></comment><comment><USER34> I love clojure. Would it be possible to get it running on a rust runtime? That would be awesome

</comment><comment><USER36> How much did it get?

</comment><comment><USER37> Clojure is a functional programming language based on relational database theory.

The Clojure system can be treated as a RMDB using the Lisp language, RMDB Schema (Clojure Spec) is a static type, and SQL (LISP) is a dynamic type.

It is an example of the best combination of dynamic and static types.

It's innovation, simple, practical and reliable.

[https://github.com/linpengcheng/PurefunctionPipelineDataflow...](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Clojure_is_FP_based_on_RMDB.md)

<comment><USER38> could you elaborate on that ? how is it based on relational DB ?

<comment><USER37>
                   Clojure -> DBMS, Super Foxpro

                       STM -> Transaction,MVCC

Persistent Collections -> db, table, col

                  hash-map -> indexed data

                     Watch -> trigger, log

                      Spec -> constraint

                  Core API -> SQL, Built-in function

                  function -> Stored Procedure

                 Meta Data -> System Table

In the latest spec2, spec is more like RMDB. see: [https://github.com/clojure/spec-alpha2/wiki/Schema-and- selec...](https://github.com/clojure/spec-alpha2/wiki/Schema-and-select)

The main development goal of clojure is to write the database. The development idea is actually from the database, not the FP.

With reference to the database, as long as I use spec to strictly define (standardization) the core data model, I can ensure the correctness of the system.

I've turned the traditional work of ensuring code correctness from in-code type system validation to data self-validation. Turn the work into verifying the core data model instead of validating the input and output data types of the function.

Similar to industry, verify that all finished products meet the standards before entering the warehouse. Also similar to databases, verify their compliance before data enters the database.

That is "Data as a service, Warehouse as the core, operates around it".

A system requires only a few core data models, and development is built around the core data model.

Persistent data structures ensure that the modification of the immutable big data model are high performance and memory efficient.

In addition, using my pure function pipeline data stream ([https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)) makes debugging, parallelism and extension very simple.

from: [https://github.com/linpengcheng/PurefunctionPipelineDataflow...](https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/Clojure_is_FP_based_on_RMDB.md)

<comment><USER39> _The main development goal of clojure is to write the database. The development idea is actually from the database, not the FP._

This seems a tenuous theory. Clojure has been described as a language for data processing, but this isn't the same as basing the design on relational databases. Clojure isn't even relational; its data is generally kept in standard collection types, rather than relations.

I'd describe Clojure as a dynamically typed, functional Lisp that emphisizes open data models and explicit time.

<comment><USER40> its data is generally kept in standard collection types, rather than relations.

Isn't that the same as relational databases once you dig a layer deeper?

<comment> cgrand-net No, it's hierarchical (because we nest collection types) vs relational.

<comment><USER37> In RMDB(For example postgresql), Database is hierarchical nest collection types. It is also consistent with Clojure.

```clojure

{:table01 {:row01 {:col-array [0 1 2]

                       :col-json  "{\"a\": \"Hello\"}"

                       :col-text  "abc"}

               :row02 {}}

      :table02 {:row01 {}

                :row02 {}}}

```

In addition, postgresql supports inheritance, which is also hierarchical nest collection types.

<comment><USER39> While Postgres supports hierarchical data in the form of JSON, that doesn't mean it's a form of relational data, it just means Postgres supports both.

Clojure doesn't have good tools in its core library for working with relational data. There's no core type that explicitly represents a relation, and Clojure lacks functions for many basic relational algebra operations. For example, how would you perform a natural join across your data structure?

<comment><USER37> In programming, data modeling is the most important.

Convert(or design) data to hash-map, join (or merge) by key.

it can write commonly used operations as functions, try to row (or col) operations as much as possible, and join all data only when necessary(reduce the row-join).

```clojure

(def a {:a-id-01 {:a-name "a1"}

            :a-id-02 {:a-name "a2"}})

(def b {:b-id-01 {:a-id :a-id-01 :b-name "b2"}

            :b-id-02 {:a-id :a-id-02 :b-name "b2"}})

(->> b

         :b-id-01

         :a-id

         a

         :a-name)

;=>

;"a1"

(let [x (b :b-id-01)]

       (->> x

            :a-id

            a

            (merge x ,)))

;=>

;{:a-id :a-id-01,

; :b-name "b2",

; :a-name "a1"}

```

<comment><USER39> You're describing a language whose data model is hierarchical, not relational. In your code you first convert a relation into a hierarchy of collections. Why would you need to do that if Clojure used a relational data model?

<comment><USER37> In RMDB, database data model (db,table, row, col, value[array,json, int, text, etc.] ) is hierarchical.

Relation is a logical model mapping of data structures, it is just a logical thinking that exists in the brain.

SQL, Prolog, clojure.core, minikanren can be used for relational operations.

<comment><USER39> The relational model isn't arbitrarily hierarchical. We can place a map inside a map, or a map inside a vector, and keep going indefinitely until we run out of memory. Conversely, in a relational database we can't place a database into a table, or a table into a row.

It's true that we can represent relations using collections. In Clojure we'd write:

        (def a
          #{{:a/id 1, :a/name "a1"}
            {:a/id 2, :a/name "a2"}}

        (def b
          #{{:b/id 1, :b/name "b1", :a/id 2}}

But these structures don't allow for efficient lookup or joins, and we lack inbuilt functions to easily deal with data modelled in this way.

Relational databases are based on relational algebra. If Clojure is based on relational databases, then we'd expect to be able to do relational algebra easily in Clojure. But we can't: the core library isn't designed for it, and the built-in data structures aren't designed for it.

<comment><USER37> In general, I think:

1\. arbitrary layering and deep nesting are not good engineering practices.

2\. refer to the data-model & code of my latest two posts. I prefer to use hash-map as the table with the primary key hash index, with key as the primary key and val(colname-colval-hashmap) as the row content.

I also don't think relational algebra operations must be implemented in the form of RMDB and SQL. It can also be implemented very elegantly with clojure.core. using hash-map operation is simpler, clearer, smoother and high performance.

There are many ways to implement relational algebra. The thinking is not limited by the "information structure" displayed by the traditional RMDB interface. In clojure, the hash-map(NoSQL) is the underlying physical model, and the relational model is the upper logical model.clojure core function acts as a data manipulation language, I named this architecture SuperSQL or SuperRMDB.

In fact, the original data manipulation language of posgresql and foxpro is not SQL. Clojure core function is closer to foxpro's commands (DML).

3\. set, vector, list is generally not a good default data container, only used when needed. you use the set as container, it's difficult to operate data (table, row, column, value).

4\. In summary, I think: programming is the process of designing a data model that is simple and fluent in manipulation. To have open thinking, not to be restricted by traditional thinking, to be flexible, adapt to local conditions, and design as needed.

<comment><USER39> _" arbitrary layering and deep nesting are not good engineering practices"_

Perhaps, but that's irrelevant; I'm describing the difference in how hierarchical and relational models are designed.

 _" I prefer to use hash-map as the table with the primary key hash index, with key as the primary key and val(colname-colval-hashmap) as the row content."_

And what if you need a second index? Your indexing should be separate from your data model, otherwise you can't write performant relational algebra operations that apply in the general case.

 _" It can also be implemented very elegantly with clojure.core. using hash- map operation is simpler, clearer, smoother and high performance."_

No it can't. Suppose I have a relation with keys: _a_ , _b_ , _c_ , _d_ and _e_. I want to index on _a_ , _b_ and the pair _(c, d)_. How would I do that in Clojure? What happens if I later decide I also want to index on _e_?

This is the sort of problem that's trivial to solve in a relational database, and extremely hard in Clojure, because Clojure doesn't have the functions or data structures to support data modelled in this way.

That's not to say that Clojure _can 't_ have these tools; just that they aren't built into clojure.core, because that's not what it's designed for.

 _" set, vector, list is generally not a good default data container, only used when needed"_

Yes they are. Sets are the basis of relational algebra.

You're complecting the ideas of data representation with data indexing. Sets are a good _representation_ of a relation, but a poor _index_.

We can get the best of both worlds by combining the two:

        (def a
          (let [r1 {:a/id 1, :a/name "a1", :b/id 1}
                r2 {:a/id 2, :a/name "a2", :b/id 1}]
            {:relation #{r1 r2}
             :index
             {:a/id   {1 #{r1}, 2 #{r2}}
              :a/name {"a1" #{r1}, "a2" #{r2}}
              :b/id   {1 #{r1 r2}}}}))

A data structure like this allows us to start writing efficient relational algebra. For example, with a natural join we can look for the smallest index two relations have in common.

So we _can_ begin to construct the infrastructure we need to perform relational algebra in Clojure, but it's not there to begin with, and therefore Clojure isn't designed around the relational model.

<comment><USER37> If you want to build an RMDB with Clojure, you are right, but this kind of project is very rare, including Datomic, which is built on top of RMDB, I don't think it needs to deal with such low-level and general operations.

Implementing an RMDB is not equivalent to relational algebraic operations. I think it should be to use simple, direct and lightweight the relational logic model to solve real-world problems. Don't over-optimize, over-generalize and over-complicate, keep it simple and direct.

Just like we design a Database in RMDB to solve real-world projects, This is the normal way to use relational algebra and models. After the database design is complete, we don't need care how the index is implemented, and we don't need care the underlying storage of the data. I mean, clojure is used as RMDB , is not used as tool of construct RMDB .

Therefore, my method is to design the application-level data model. The problem you said does not exist. When I get the data from the database (or elsewhere), I simply transform the data to the target model, you can think of this model as a table or view, you don't need to transform again, so you don't need multiple indexes.

<comment><USER39> I'm not talking about building a database; I'm talking about using a relational model for data.

Like most general-purpose programming languages, Clojure has a hierarchical data model. We have a number of collection types, and we can put any collection into any other collection.

A relational model takes a fundamentally different approach. Relational data is represented not by nesting collections, but by a flat set of tuples. Efficiency is achieved through indexing, not by rearranging collections.

There's some interesting research around on using the relational model outside of a database, but that's not a design goal of Clojure.

<comment><USER37> My method can also generate a "derived index" based on the "primary key hash index",it's Higher performance, not by rearranging collections.

```clojure

(def table01 {:t1-pk1 {:pk :t1-pk1

                           :name    "t1-r1"

                           :manager :m1}

                  :t1-pk2 {:pk      :t1-pk2

                           :name    "t1-r2"

                           :manager :m2}

                  :t1-pk3 {:pk      :t1-pk3

                           :name    "t1-r3"

                           :manager :m3}

                  :t1-pk4 {:pk      :t1-pk4

                           :name    "t1-r4"

                           :manager :m2}})

(def t1-manager-index {:m1 #{:t1-pk1}

                           :m2 #{:t1-pk2

                                 :t1-pk4}

                           :m3 #{:t1-pk3}})

(->> :m2

         t1-manager-index

         (select-keys table01 ,))

; =>

; {:t1-pk2 {:pk :t1-pk2, :name "t1-r2", :manager :m2},

; :t1-pk4 {:pk :t1-pk4, :name "t1-r4", :manager :m2}}

(->> [:m2 :m3]

         (select-keys t1-manager-index ,)

         vals

         (apply clojure.set/union ,)

         (select-keys table01 ,))

; =>

; {:t1-pk2 {:pk :t1-pk2, :name "t1-r2", :manager :m2},

; :t1-pk4 {:pk :t1-pk4, :name "t1-r4", :manager :m2},

; :t1-pk3 {:pk :t1-pk3, :name "t1-r3", :manager :m3}}

```

Your point of view is mainly to emphasize that Clojure is a multi-paradigm, general-purpose functional programming language.

The postgresql development team is also this view, so postgresql is not only RMDB (relational modeling), but also supports OO and json (NoSQL). But postgresql default data modeling is relational modeling

My point of view is mainly to emphasize the best practices of data modeling and programming.

Both views are correct and can exist in parallel.

<comment><USER39> _" Your point of view is mainly to emphasize that Clojure is a multi-paradigm, general-purpose functional programming language."_

No, that's not my point at all. I'm saying that Clojure's core library and data structures are built around a hierarchical data model and not a relational one.

If you want to model your data as a relation, then you need to build the tools and structures for it. Look at your code, then consider how it would look in a language designed around relational algebra:

        (def table01
          #rel [{name "t1-r1", manager :m1}
                {name "t1-r2", manager :m2}
                {name "t1-r3", manager :m3}
                {name "t1-r4", manager :m2}])

        (select table01 (= manager :m2))

        ; => #rel [{name "t1-r2", manager :m2}
        ;          {name "t1-r4", manager :m2}]

        (select table01 (or (= manager :m2) (= manager :m3)))

        ; => #rel [{name "t1-r2", manager :m2}
        ;          {name "t1-r3", manager :m3}
        ;          {name "t1-r4", manager :m2]

An indexed selection against a relation would just be a single function or macro. We wouldn't need to mess around with select-keys and set union to achieve such a simple operation, as you needed to do in your code. It would be built into the core library or the language.

I want to emphasize that I'm not saying you _shouldn 't_ model data the way you are. There are plenty of advantages to it. But the more you go down the relational rabbit hole, the less suitable clojure.core is to handle it.

Clojure _is_ about data modelling and processing, but it isn't based on a relational model, as you suggest:

 _" Clojure is a functional programming language based on relational database theory"_

Clojure is a functional programming language, but it's not based on relational database theory.

<comment><USER37> If Clojure is the sea, programming is to sail on the sea, I use the relational model as a lighthouse and route, as a reference model for simple programming, because the relationship theory is simple and scientific..

I had implemented a DataFrame with hash-map, which implements relational operations. A relational operation is just a function. The advantage of hash- map is that key-chain can be used as a pointer, and processing data elements is simple and efficient. Therefore, DataFrame has advantages of RMDB and NoSQL.

A strict relational model will lose the flexibility of data element operations.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER41> For me, Clojure was full of false promises and dead ends / false starts regarding concurrency[0]. Elixir delivers where Clojure failed.

[0] for example, nobody uses the STM implementation

<comment><USER39> Where did Clojure fail? People don't use Clojure's STM because it turned out not to be necessary most of the time, not because of any inherent issue with the implementation.

</comment></comment><comment><USER42> The thing that kills Clojure for a lot of teams I worked with is the JVM. It's too limiting and constrains the problems one can solve.

<comment><USER35> Whenever I ask to explain JVM criticism, people either really have nothing to say, or most of the time it turns out to be hatred of Java. JVM is a very solid piece of tech and it is hated for all the wrong reasons.

I'm baffled: give people a powerful tool that can simplify and bring enormous joy to work with two, most popular platforms of all time, even making it possible to share code between completely different worlds - they'd still be complaining about it.

</comment></comment><comment><USER43> Clojure is popular? It's at the bottom:

[https://insights.stackoverflow.com/survey/2019#technology](https://insights.stackoverflow.com/survey/2019#technology)

As much as I love Clojure, it's still a harrowing language for beginners to learn and use. The learning curve is just too high. If you have to learn category theory in other to handle basic programming flows, then there's just something wrong.

Elixir, for instance, has many functional primitives, but isn't dogmatic about it. It can "feel" like traditional OO-style programming without the cruft.

<comment><USER44> How the heck Clojure has any relation to category theory? Clojure explicitly does NOT require nor use any explicit CT. Maybe you confused Clojure with Haskell?

<comment><USER43> Perhaps my understanding is outdated! IIRC you needed CT because you couldn't do some basic conditional flow things, but I could be wrong. It's been a while.

<comment><USER45> With respect, I think you may be confusing Clojure with a different language.</comment></comment></comment></comment>


Vultr introduces $2.50/month plan - <AUTHOR> https://www.vultr.com/news/The-Vultr-Cloud-Is-More-Powerful-Than-Ever/ <comment><USER2> Today I published an article where I've benchmarked and reviewed most "simple" cloud hosting providers (Vultr, DO, Linode, Scaleway, OVH):

[https://www.webstack.de/blog/e/cloud-hosting-provider- compar...](https://www.webstack.de/blog/e/cloud-hosting-provider- comparison-2017/)

Edit: I've submitted it as well: [https://news.ycombinator.com/item?id=13798023](https://news.ycombinator.com/item?id=13798023)

<comment><USER3> Do you know why AMS is faster than FRA (ping- and speed-wise), although FRA is quite a lot closer to me physically?

What was your experience since you are in Germany too?

<comment><USER2> What's your ISP?

<comment><USER3> Vodafone Kabel

</comment></comment></comment></comment><comment><USER4> I'm happy Vultr customer and I can only be happier. I was looking for other providers recently for my personal needs, as I don't need that much resources and there were other providers with less that $5/month prices, but now I'm not looking anywhere.

Sweetest thing is hourly pricing. Sometimes I need Paris VPN for few hours. I have some scripts, so I can launch new instance with configured OpenVPN in 2-3 minutes, use it, then dispose and I would pay only few cents. Impressive, if you ask me. That's what cloud is for.

Network speeds are quite good, vultr has lots of features (want to install OpenBSD from your own ISO via web 2.0 KVM, no applet nonsense? Or Windows XP? No problem at all), and prices are just so low now. Also IPv6 works fine. I don't know about their support, I never had to contact them yet, but otherwise it's awesome service.

<comment><USER5> Do you have to recreate the entire system each time? That's one of the downsides to Digital Ocean for me, you need to pay even when you're not actually running your droplet.

<comment><USER6> There might be better ways to do this but each new instance on vultr takes a few minutes to set up (you can actually use their web VNC console to watch their install script run,a unique experience not offered by other VPS providers I have used) and then you can restore old config from a snapshot which takes a bit more time but it is pretty fast overall.

There are options to load your own distro image and init scripts but I have not tried them since most things I need in a transient instance can be installed by following a simple bash script calling apt.

</comment></comment></comment><comment><USER7> The Vultr plan looks like a nice option. For comparison, I recently started using Scaleway for my it's-so-cheap-why-not-try-it box.

My Scaleway box's specs:

\- €2.99/month (currently $3.17 USD/month)

\- 2 GB RAM

\- 50 GB SSD storage

\- 200 Mbits/sec of unmetered bandwidth

\- data centers in Amsterdam & Paris

When I need to take hosting more seriously, I'll reevaluate. Until then, Scaleway is a damn good deal :)

<comment><USER8> Yeah, 2 GB RAM for ~$3 is amazing, while the mentioned Vultr plan is 512MB for $2.5 and DigitalOcean offers 512MB for $5… Sure, these companies have other advantages (e.g. DigitalOcean has very fast storage) but RAM is so damn valuable if you want to run many services, run software builds, etc.

Unfortunately Scaleway is Linux-only, they use some networked block storage that's not yet supported on FreeBSD apparently. (Needs to be mounted from inside the VM I assume? Damn "cloud" stuff.) Scaleway also used to have no IPv6, I think this might have been resolved though (but one address only IIRC? no /64?)

prgmr is my current choice for personal stuff — 1.25 GB is not as good as 2 GB, but they offer normal Xen VMs with full access — install anything you want. Also the good feeling of supporting a small team of sysadmins instead of a big corporation (esp. vs Amazon/Google, not so much with the other small hosters). The only downside is that they only have US servers, nothing in Europe.

<comment><USER9> > they use some networked block storage that's not yet supported on FreeBSD > apparently

This may only apply to their physical offerings, not to the VM-based ones, and you may be able to get it to run using some nasty hacks (possibly involving loading your kernel after booting theirs). Either way, there are no official FreeBSD images so you'd be on your own.

Their IPv6 support is indeed lacking (one address, and you lose it if you stop the server).

<comment><USER8> No, they told me this about the VM offerings:

[https://github.com/scaleway/image- proposals/issues/11](https://github.com/scaleway/image-proposals/issues/11)

"FreeBSD on x86_64 (C2S, C2M, C2L, VC1S, VC1M, VC1L) needs an alternative way to store data or an NBD driver for FreeBSD, and more work on the boot system"

</comment></comment></comment></comment><comment><USER10> Big ups to Vultr for doing what DigitalOcean wouldn't do - supporting OpenBSD.

</comment><comment><USER11> I don't have any experience with Vultr, nor do I know anyone who has. Honestly, I haven't heard of them before.

Anyone have experience with them? I'd love to hear about it.

<comment><USER12> I ran [https://precursorapp.com](https://precursorapp.com) on Vultr in the early days. I had a setup with a few dedicated servers for the DB and load balancer, and then I would spin up and shut down application servers whenever I deployed new backend code. Infrastructure looked like: [https://precursor.precursorapp.com/document/Backend- Infrastr...](https://precursor.precursorapp.com/document/Backend- Infrastructure-17592197950857)

I used to recommend it to everybody, but don't any longer. I had two negative experiences that made me stop recommending it.

The first is frequent restarts. Very small sample size, but both me and a friend started experiencing restarts every month or so. I don't think I got any advance warning about the restarts, but I'm not positive.

The second is that networking between instances stopped working for me in the middle of the night shortly after Vultr did an upgrade. Support wasn't able to help (though they did try) and I couldn't figure out anything on my end. I had to switch everything to AWS to get the site back online before people woke up in the morning.

I was super happy with it before those two problems, though, and the people there seemed competent and professional. I was also using FreeBSD, so it may not be as well supported as Linux (which may have contributed to the networking problem).

<comment><USER13> Thanks for this comment. I was about tell my team to investigate Vultr as an option for our next website, but I guess we'll first do some more research into this.

We're still on AWS too. Currently spending about $50 / site which adds up quite quickly when you have 20+ sites. Our current breakup is something like (2 x t2.micro - one for website, one for cron created using Elastic Beanstalk, 1 x db.t2.micro for RDS + Elastic load balancer cost). I'm sure we can bring it down to $10 / site if we were to move to Vultr or Scaleway but it's a very small site to pay for the reliability AWS has provided to us all these years (apart the recent S3 outage). So guess we'll too just stick to AWS for now until.

<comment><USER14> Why not just get a couple of bigger instances and run all your sites on them?

<comment><USER13> There are many reasons but a few from the top of my head are:

1) The whole system is running on Amazon's Elastic Beanstalk (via Docker). Beanstalk provisions 3 instances for every site (1 Web, 1 Worker/cron, and 1 RDS) for every app with ELB on front.

2) It makes installing updates easy and automatic using deployment scripts which we have on every site.

3) Everything (web/cron/database) is configured to scale up and down automatically, i.e. new servers start as per demand. This may not be possible otherwise.

</comment></comment></comment></comment></comment><comment><USER15> There is a limit of 2 * $2.50 instances per account.

<comment><USER16> Is there a limit on the $5 plans? because they're still better than DO's.

<comment><USER17> I don't think so.

</comment></comment></comment><comment><USER18> Best thing about Vultr is that you can bring your own IP blocks and have their BGP servers announce them.

The bandwidth overage is also pretty okay. ($10/TB in NA/EU, $25/TB in AS, and $50/TB in AU.)

</comment><comment><USER19> I'm using similar plan from Ramnode as a sandbox for 2 years already and very happy about it. Ramnode is a highly underrated hosting provider but it has the outstanding support and great features/speed/reliability. I'm not using it for production though.

</comment><comment><USER20> Wow! That's the specs of the cheapest DO droplet for 1/2 the price..

</comment><comment><USER21> I've heard somewhere that Vultr retains your stored credit card indefinitely (even after you close your account). It sounds a bit weird, that's why I avoided their services. Can someone confirm this?

<comment><USER22> Believe it or not this is actually very common. In fact a lot of people who integrate Stripe recommend this pattern. They recommend to never delete customers and cards in Stripe, instead just remove the subscription from the customer.

The idea is, if the customer wants to come back and reactivate service they don't have to provide billing details again.

I don't do this though. When customers cancel my startup, I delete the card and cancel the subscription in Stripe but leave the customer.

<comment><USER23> This pattern can be recommended so long as there is no liability for financial information disclosure. When you're hacked and a customer who closed their account 2 years ago has their CC info used for fraudulent transactions, you just trollface and move on.

This is why I am baffled as to why the CC companies eliminated the transient number technology, which was pefect for e-commerce vendors like this. At least with those, after 3-6-12 months the number expires and no damage done when the vendor is hacked. I assume it was dropped because this technology complicated data mining.

<comment> vertex-four Note that in the case of Stripe, the site doesn't hold onto "financial information" per se - they hold onto tokens where Stripe is the holder of the information, and they can't access the card number or CVV after it's been sent to Stripe - so all fraudulent transactions would have to be requested through that Stripe account.

<comment><USER24> They shouldn't have access to card number and CVV either way because usually they are not PCI-DSS certified. Stripe handles that in an iframe (requirement of PCI). CVV cannot be stored at all even by Stripe.

</comment></comment></comment></comment></comment><comment><USER25> I was setting up a test vps there a couple of days ago and made plans to try out the $5 plan with $20 credit they were giving me on a $5 charge. So I had a runway of about 5 months but when I made payment, this $2.50 plan was right there, and it wasn't there before the payment. Now I have 10 month trial period. Never been happier.

The dashboard is nice, the ram is a bit low (but the price point is killer), I wasn't able to deploy a lets encrypt cert without pooled memory. The service seems to be excellenct in the few days I've used it. It doesn't seem to have a "don't ask for 2FA on this device for n months" option but it's a small complaint.

<comment><USER26> > I wasn't able to deploy a lets encrypt cert without pooled memory.

You mean you had to enable swap to run the Let's Encrypt client?

<comment><USER27> If you use certbot-auto to install the client, part of the installation process involves compiling some crypto library (IIRC) which tends to fail on low-memory systems, hence the need for swap.

Packaged versions of certbot (from your distribution's package manager) don't suffer from that problem and have fairly low memory requirements.

</comment></comment></comment><comment><USER28> Been a while since I've tried Vultr, but my experience with them wasn't good. I started one instance, and all went well, decided to get a second one going. The performance on the second instance was horrible, nothing like the first. I occasionally got e-mails stating they were rebooting hardware my instances were on. And after just a few months, the first instance I had refused to boot due to file system errors.

After the performance issue with my second instance, I wrote them off as not being good for anything serious. And after the file system issue, I decided they weren't useful even for anything casual. Hopefully things have changed, but don't assume that just because you've been up and running for a couple months with good performance that things won't fall apart soon.

</comment><comment><USER29> Great job on the website. Very thorough, beautiful and answered all my questions about the service.

</comment><comment><USER30> I recently switched to Vultr from a DigitalOcean and Compose.io setup.

Compose is nice for backups and replicas but they drop the connection like all the time and then the replicas start playing who wants to be master. Which brought downtime to my application at times. Also there expensive so I said f that and manage a Mongo instance myself. Since it was a small project that had to much overhead.

I moved from DO was primarily pricing and the lack of data centers.

Vultr's Miami DC is my jam since I'm in Tampa. Atlanta is nice too.

So far I really like Vultr. 2GB for $10!

<comment><USER31> I'd be curious to see the historical downtime of the Miami DC given that its in the direct path of a yearly hurricane season.

<comment><USER32> I had an instance in Miami with them during Hurricane Matthew and there were no outages.

That DC has great connectivity to South America, which is what I'm using it for.

</comment></comment></comment><comment><USER33> Just migrated from the old $5 plan to the new $2.50 plan which even has more SSD space. Unfortunately, that involved copying a snapshot to a new instance, because they don't support "downgrading", though in this particular case there was no technical reason to not support it directly.

<comment><USER34> I just "downgraded" a legacy $10 instance to a $5 instance, as it now has better specs than what I was using, so they do allow it. It seems the $2.50 plan is a special class (probably loss-leading) and doesn't fully integrate with the rest of their products.

</comment></comment><comment><USER35> I was running one of my projects on Vultr for a while and didn't appreciate the random restarts with no warning. Ended up using DO for my next project. I hope that DO reduces their prices, right now they're getting destroyed by Vultr and Linode.

</comment><comment><USER36> I use Vultr mainly because it has an AU presence, whereas Linode, DO, Scaleway, OVH, do not.

<comment><USER37> OVH is currently building a datacenter in AU. I guess (hope) I some point they will offer their vps/cloud there as well. But so far their pricing is higher there then EU/CA.

[https://www.ovh.com/us/discover/australia.xml](https://www.ovh.com/us/discover/australia.xml)

</comment></comment><comment><USER38> Uhm not cool, I've just registered an account following a promotion that claimed they'd match the credit I added, I've added $10 and boom, no promotional credit whatsoever. Just opened a support ticket to see what's going on...

<comment><USER39> Same here, I'll open a ticket and see what is going on too.

<comment><USER39> Just wanted to get back on this: I opened a support ticket on Vultr and they promptly solved the issue by manually matching the credit.

They customer support worked great!

</comment></comment></comment><comment><USER39> This is pretty nice!

Minor rant: for whatever reason, you can't spin up VMs using this $2.50/month plan through their API.

Does anyone from Vultr know why? This would be _very_ useful.

<comment><USER34> You can only have two active at a time so it seems like it's a loss-leading product just to get people through the door

</comment></comment><comment><USER40> It's nice to see all this competition ($5 Linode, now $2.5 Vultr) but don't they risk overallocaton?

Let's say they have physical machines with 96 GB mem that hold 200 1 GB VMs each, in the hope that no one uses more than half their ram. Same for CPU or disk I/O or whatever resource.

Now that the entry level prices are dropping but the offered resources remains the same, people will spin up more VMs. Doesn't it become dog slow for everyone?

<comment><USER2> No, it's not working like that. They use KVM, it's not like with OpenVZ/LXC where you can put unlimited VMs on a host system.

<comment><USER41> KVM has KSM, so there is definitely the possibility of having say, 150x 1GB VMs on a 128GB physical RAM server; possibly much more than that depending how much KVM/KSM has improved since I last looked at it.

</comment></comment></comment><comment><USER42> I use and like Vultr. Host reboots are common though.

As an aside; what does Vultr stand for? Is it "vulture"?

</comment><comment><USER43> They have really stepped up their game. Love the free upgrades.

</comment><comment><USER44> For those Australians using Vultr - are you charged in USD?

<comment><USER45> Yes.

<comment><USER44> Thanks, sticking with BinaryLane then...

</comment></comment></comment><comment><USER46> nice. this makes them the cheapest to offer IPv6 support with a proper /64\. I wish scaleway would follow suit.</comment>


Ask HN: Hackernews notification? - <AUTHOR>

Does hackernews have a notification setting? It would be awesome to be notified when comments are made to a post you made or upvoted. <comment><USER2> I use this: [http://hnnotify.com/](http://hnnotify.com/)

<comment><USER3> I hope they upgrade it to support the new API.

</comment></comment><comment><USER4> They do have an API which you can use to make such functionality.</comment>


Paul Graham and his "no asshole" rule (Interview) - <AUTHOR> http://www.youtube.com/watch?v=UacbJ72dluU&feature=channel <comment><USER2> It's actually Bob Sutton's rule.

<http://en.wikipedia.org/wiki/The_No_Asshole_Rule>

<comment><USER3> Incidentally, we don't call it a "no asshole rule." I think what I originally said to Robert was that we try not to accept jerks, and since he'd heard the phrase "no asshole rule" he used that to describe it.

Our criteria aren't the ones listed in this article, either. We're not trying to avoid people who make other people feel bad so much as those who are bogus, or dishonest. That's what we mean by a jerk: someone you can't trust.

<comment><USER4> > someone you can't trust.

Judging who you can trust, especially based on brief, early impressions, is quite a skill. Some have a natural intuition for it, others don't, but like many things I bet that intuition can be deconstructed into a series of learnable techniques. Would you consider writing an essay deconstructing how you and Robert judge who you can trust in business?

<comment><USER5> He's said in previous interviews that they all just ask Jessica, who is extremely good at judging character, because the rest of them aren't very good.

<comment><USER4> Ah, she's one of the intuitive ones. Some of it is probably due to women being more perceptive to body language and non-verbal communication than men are, on average. I wonder what else there is.

</comment></comment></comment></comment></comment><comment><USER6> A friend lived in a co-op at Oberlin, which had only one house rule: "don't be an asshole."

That one rule supplanted all the traditional ones for group living: don't leave dirty dishes, don't play obnoxiously loud music late at night, etc.

<comment><USER3> Like the domestic version of "Don't be evil."

<comment><USER7> It's also a more succinct variation of Caltech's honor code: "no member of the Caltech community shall take unfair advantage of any other member of the community."

</comment></comment></comment><comment><USER8> Having read all of his essays I have never heard Paul speak before. Seems like a pure gentleman.

<comment><USER9> Never heard him? Not to derive this into some "list of Paul Graham's speaks", but I really suggest to watch <http://www.youtube.com/watch?v=q7K0vRUKXKc>. A good speak, I think.

</comment></comment><comment><USER10> In regards to twitter...they should just give pg this guy's twitter account <http://twitter.com/paulg>

He only used it once, and that was back in 2007. I'm sure the twitter guys would pull some strings to get pg as a user. Especially since they have no problem securing unused accounts "We have a rough guideline of 9 months of non-use."

Other viable alternatives:

<http://twitter.com/realpg> \- only used 2 times a year ago.

I've also registered <http://twitter.com/pgyc> so you can use that if you want(registered so some asshole doesn't go and hold it hostage). I figure YC is something you'd be known for...and even if you stop doing the whole YC program...it'll still be part of your legacy. And it's a short username.

<comment><USER11> Why should twitter give anyone's account to anyone else?

Besides, you're assuming because they're not posting publicly that they're not DM'ing or anything else. I'd be pretty peeved if I had registered an account and when I finally decided to make use of it had discovered that it had been removed to give it to some other person of the same name.

Twitter should leave people's accounts alone unless there is a good reason (preferably legal) for interfering with it.

<comment><USER12> I guess the question is - why should someone (non-paying) be able to reserve an account name and not use it for nine months or more and expect to be able to keep the account? It doesn't serve any benefit to the community to have squatted accounts.

</comment></comment></comment><comment><USER13> On a related note, I've always thought a better title for "How to Win Friends and Influence People" would be, "How not to be an Asshole", or at least, "How to avoid acting like one."

[http://www.amazon.com/How-Win-Friends-Influence- People/dp/06...](http://www.amazon.com/How-Win-Friends-Influence- People/dp/0671723650)

<comment><USER14> "How to avoid acting like an asshole"

It has a nice ring to it.

</comment></comment><comment><USER15> relevant part: <http://www.youtube.com/watch?v=UacbJ72dluU#t=4m18s>

<comment><USER16> So, to save everyone the time, the 'no asshole' rule means they don't accept assholes and has the obvious benefit that there aren't many assholes in the 'alumni'. That's it.

<comment><USER17> How do they know who is an asshole and who is not?

<comment><USER3> We ask Jessica, who has near perfect judgment of character.

<comment><USER18> I can see how you could tell that most of the people she told you to hire ended up as non-assholes, but how do you know that the people she tells you not to hire would actually have been assholes?

<comment><USER19> That's an opportunity cost, and it turns out that the main thing to understand about opportunity costs is that nobody thinks about them the right way (including me, of course).

</comment></comment></comment></comment></comment></comment><comment><USER20> <http://electricpulp.com/guykawasaki/arse/>

</comment><comment><USER21> This is an interesting rule in the context of Hacker News. Now that it's not really about hacking any more, it seems like the common trait is that everyone is an asshole.

<comment><USER22> I'd love to see a No Assholes rule on HN. By that I mean if an admin saw a post that was asshole-ish, the poster account would be disabled. It would encourage polite discussion. The current point system mostly encourages point- baiting and groupthink/PC-ness. Internet posting seems to encourage rude behavior, and it's exacerbated when you have a bunch of geek personalities who often lack good social skills.

<comment><USER21> The problem with that approach is long, drawn out threads filled with phony politeness.

</comment></comment></comment><comment><USER23> I love how his name tag is partially peeled off. Very casual and some how nice.

</comment><comment><USER24> the_real_pg is available on twitter, just sayin'... _nudge nudge_

</comment><comment><USER25> Paul Graham uses the word 'right' where most people use periods...right?

</comment><comment><USER26> I am so sorry, but I have to say this because it is what came to my mind when I watched it: Robert 'Scobleizer' Scoble is, most likely, an asshole.

And that's what I can read all over PG's body language throughout the video.

And again, I'm sorry for this mini-rant.

<comment><USER27> I think whatever you saw is probably due to the fact that this was a very quick interview done outside in an impromptu way. PG's body language could have meant a million other things.

Scoble's one of the greatest advocates of startups and not just in Silicon Valley, so I'll strongly disagree with the "asshole" description.

<comment><USER28> I'm a great advocate of startups, but I'm also the first to admit I'm an asshole.</comment></comment></comment>


A new book on Renaissance mathematics makes a bold case - <AUTHOR> https://newrepublic.com/article/148150/math-kill-god <comment><USER2> To save people a click, the bold case being made is "math killed God", ie. mathematics was the key development which allowed us to build useful models of the world and explain natural phenomena without needing to invoke a deity.

<comment><USER3> Such a claim wouldn't be taken seriously by scientists who are also, say, deists or Christians though (there are, perhaps surprisingly to some, quite a few).

The claim makes a 'category error', supposing that science and religion are trying to answer the same questions. This is not necessarily the case for all faith systems.

For example, I think it was Oxford mathematician John Lennox who said that he didn't believe in a "God of the gaps" but a "God of the whole thing" - that he expects anything (within the limits of scientific explanation) can be explained by science and mathematics, but simultaneously believes the whole system was authored and is continually sustained by God.

For Christians and Jews at least, I wouldn't expect that many people ever believed in God just because science couldn't explain things (in comparison, I think a lot of polytheistic belief systems came out of trying to explain physical phenomena). It's more the idea of revelation (through prophets etc.) and later the historical person of Jesus that would be the basis.

<comment><USER4> > I think it was Oxford mathematician John Lennox who said that he didn't > believe in a "God of the gaps" but a "God of the whole thing"

It stands to reason that a being that created order from chaos and gave form to the unformed would plausibly enjoy creating a universe that was internally consistent.

I don't understand why the universe needs to be mysterious or inconsistent to be created. I don't understand why it can't be (or at least seem to be) billion of years old for that matter.

<comment><USER5> I think you nailed it. To me, God is about the question of "why" and science is the question of "how".

That being said, I think God has to be a programmer - it's the most efficient way to create something huge (the universe), while being predictable, and therefore knowing "everything". The universe is just a huge - ok, really, really huge - state machine. And the programmer who wrote it can predict it's state at any point of time.

</comment></comment></comment></comment><comment><USER6> This article begins with a false story about Galileo being locked up for promoting heliocentrism. That is not why he was locked up. Copernicus came before Galileo, promoted heliocentrism and was employed by the Catholic Church. Galileo was locked up for political reasons, and because he was pretty antagonizing to the pope of the time. If you want a quick cartoon describing the events Adam Ruins Everything did a section on it: [https://www.youtube.com/watch?v=vlRHbQEHdRU](https://www.youtube.com/watch?v=vlRHbQEHdRU).

Sources: [1] [https://en.wikipedia.org/wiki/Galileo_Galilei#Controversy_ov...](https://en.wikipedia.org/wiki/Galileo_Galilei#Controversy_over_heliocentrism) [2] [http://www.trutv.com/shows/adam-ruins- everything/blog/adams-...](http://www.trutv.com/shows/adam-ruins- everything/blog/adams-sources/adam-ruins-everything-the-copernican-ruin- aissance.html)

<comment><USER7> I beg to differ and so do your sources, "Galileo was found "vehemently suspect of heresy", namely of having held the opinions that the Sun lies motionless at the centre of the universe, that the Earth is not at its centre and moves, and that one may hold and defend an opinion as probable after it has been declared contrary to Holy Scripture."

Your just saying if he would have kept enough political clout he could have got a pardon? Because the axe was falling once they felt he 'advocated'.

<comment><USER6> I'm arguing that heliocentrism was a means to an end. The Catholic Church was being accused of not taking the Bible seriously by the Protestents which is what caused the whole "heliocentrism heresy", but it wasn't really about heliocentrism it was about the Catholic Church trying to protect themselves. See also this line from the wikipedia article:

"The decree of the Congregation of the Index banned Copernicus's De Revolutionibus and other heliocentric works until correction. Bellarmine's instructions did not prohibit Galileo from discussing heliocentrism as a mathematical and philosophic idea, so long as he did not advocate for its physical truth."

This was a political move, with heliocentrism being the vechicle.

<comment><USER8> But if he hadn't promoted heliocentrism would he have been locked up?

I'm not sure of the answer to that, but if he wouldn't have, then it's more than reasonable to say that he was locked up because of the heliocentrism, and that there were broader reasons for their crackdown on things like heliocentrism.

An analogy: if we imagined, for the sake of the argument, that in the modern world, there are political motivations for cracking down on certain drugs. A person gets jailed for possession of one of these drugs. It's fair to say that possession of the drug was the reason they were jailed, and that the law behind it was politically motivated.

<comment><USER9> He was given the way out of stating it as a Hypothesis. He simply did not want to AND insulted the other party.

I mean: it was not a problem with heliocentrism (the jesuit scientists supported it), it was a problem of politics.

You can be right but do not expect the other party to absolve you if you insult it.

<comment><USER10> > it was not a problem with heliocentrism

It surely was. Copernicus' book remained also banned by the Church for 202 years more after Galileo's sentence. That very sentence by the Inquisition directly banned Galileo's book and sentenced him to lifetime (house) imprisonment. It was so light because Galileo "abjured, cursed, and detested" his errors ("false opinion that the sun is the center"), and his Abjuration is also preserved (I quote parts of it):

"I, Galileo, son of the late Vincenzio Galilei of Florence, seventy years of age, arraigned personally for judgment, kneeling before you Most Eminent and Most Reverend Cardinals Inquisitors-General against heretical depravity in all of Christendom, having before my eyes and touching with my hands the Holy Gospels, swear that I have always believed, I believe now, and with God's help I will believe in the future all that the Holy Catholic and Apostolic Church holds, preaches, and teaches. However, whereas, after having been judicially instructed with injunction by the Holy Office to abandon completely _the false opinion that the sun is the center of the world and does not move and the earth is not the center of the world and moves_ , and not to hold defend, or teach this false doctrine in any way whatever, orally or in writing; and _after having been notified_ that this doctrine is contrary to Holy Scripture; _I wrote and published a book_ in which I treat of this already condemned doctrine and adduce very effective reasons in its favor, without refuting them in any way; therefore, _I have been judged vehemently suspected of heresy, namely of having held and believed that the sun is the center of the world and motionless and the earth is not the center and moves._

Therefore, desiring to removed from the minds of Your Eminences and every faithful Christian _this vehement suspicion, rightly conceived against me, with a sincere heart and unfeigned faith I abjure, curse, and detest the above-mentioned errors and heresies,_ and in general each and every other error, heresy, and sect contrary to the Holy Church"

</comment></comment></comment></comment></comment></comment><comment><USER11> There's a fairly amusing and apocryphal anecdote about Laplace that relates to this. You can read more about it here: [http://www.eoht.info/page/Napoleon+Laplace+anecdote](http://www.eoht.info/page/Napoleon+Laplace+anecdote)

"Laplace went in state to Napoleon to accept a copy of his work, and the following account of the interview is well authenticated, and so characteristic of all the parties concerned that I quote it in full. Someone had told Napoleon that the book contained no mention of the name of God; Napoleon, who was fond of putting embarrassing questions, received it with the remark, 'M. Laplace, they tell me you have written this large book on the system of the universe, and have never even mentioned its Creator.' Laplace, who, though the most supple of politicians, was as stiff as a martyr on every point of his philosophy, drew himself up and answered bluntly, 'Je n'avais pas besoin de cette hypothèse-là.' ['I had no need of that hypothesis.'] Napoleon, greatly amused, told this reply to Lagrange, who exclaimed, 'Ah! c'est une belle hypothèse; ça explique beaucoup de choses.' ['Ah, it is a fine hypothesis; it explains so many things.']"

</comment><comment><USER12> I was under the impression that few historians actually agree with the story of Galileo being imprisoned for pushing Heliocentricity. I recall reading that by that point heliocentrism wasn't controversial and Galileo's house arrest came as a result of a combination of errors in his own work and his personal conflicts with the pope.

What's more, I believe I've read that most of the "conflict" between religion and science has been overblown. The environment of opposition we sometimes see today didn't really begin to manifest itself until the 19th and 20th centuries.

</comment><comment><USER13> I will add that taking calculus in high school was the final stake in the heart of my belief in god.

Calculus shows you that complex outcomes can result from quite simple causes.

<comment><USER14> What caused the simple causes?

<comment><USER15> Who cares?

Just because I rolled a ball downhill, doesn't mean I was solely responsible for starting it, but worked in tandem with the laws of nature that exists. Nor am I the god of the effects, just because I was an instigator.</comment></comment></comment>


Linux 5.0-Ad1 Patch Lets You Build the Kernel with "-March=Native" - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.0-ad1-Optimize-CPU <comment><USER2> Bottom line from the article: Not much differences in the performance.

Interestingly, on the same blog in fact different optimization on a Linux distribution level are discussed (compared) more in detail:

[https://www.phoronix.com/scan.php?page=article&item=ubuntu18...](https://www.phoronix.com/scan.php?page=article&item=ubuntu1810-fast- clear&num=1)</comment>