Would you still pick Elixir in 2019? - <AUTHOR> https://github.com/dwyl/learn-elixir/issues/102 <comment><USER2> I've been programming in elixir for about 2 years now. I have to say it's hard to go back to something like Ruby or JavaScript.

In elixir you really get the full power of multi core and support for distributed computing out of the box.

Code that would have been beyond my pay grade or wouldn't even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code that is easy to read, is fast, able to take advantage of multiple cores, less error prone, which I can scale to multiple machines easily.

The erlang scheduler is so damn powerful and it feels amazing to be able to execute your code on multiple machines with a simple distributed task which is built in as a standard functionality of the language.

I'll end this note saying that, look at the problem you are trying to solve. If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend.

I can say without a shadow of a doubt the project I'm building right now would not be progressing as fast as it is if I picked anything other than Elixir. You get a lot of bang for your buck when it comes to productivity in the domain that elixir solves for.

<comment><USER3> > If you need multi core and distributed features (which is generally more > common than you think) elixir is truly your friend.

Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture- level and not language-level work; perhaps I'm missing something, however.

<comment><USER4> Because those features are accessible, you end-up using them a lot more frequently and find new and exciting ways to use them. For example, I am really happy that Elixir and its tooling does pretty much everything using all cores: compiling code, running tests, generating documentation, etc. and all of this has a direct impact on the developer experience.

The other part is that you can build more efficient systems by relying on this. If you have a machine with 8 cores, it is more efficient to start a single process that can leverage all 8 cores and multiplex on both IO and CPU accordingly. This impacts everything from database utilization, to metrics, third-party APIs, and so on.

The Phoenix web framework also has great examples of using distribution to provide features like distributed pubsub for messaging and presence without external dependencies.

However, when it comes building systems, then I agree with you and I would probably use a queue, because you get other properties from queues such as persistence and making the systems language agnostic.

I hope this clarifies it a bit!

<comment><USER2> Exactly right, just the pure fact that it's at your disposal makes you think about problems in a whole new way. For example, I recently just abstracted my solutions away from Redis. I have nothing against redis however removing a dependency makes things more simple, which is important for my setup.

For caching you have SO many options which are already built in, ets, agent, ets + gen_server, or even reaching out for a library like nebulex.

Another example is recurring jobs, you can create a gen_server that will run a job every x hours in roughly 50-100 lines of code depending on how complex your problem is.

I rarely feel the need to reach out for external dependencies. Not that there is anything wrong with that, it's just that you now have a wider array of tools to work with and some problems are just solvable with a couple of lines of code instead of having to reach out for external tooling.

I recently built a distributed work queue, generally in Ruby I would use something like sidekiq, however elixir made me feel like "hey you can write your own" which generally is not recommended since you don't want to re-invent the wheel, but if you are doing something that breaks away from the existing solution, having the ability to craft a custom solution that works for your specific set of problems is extremely powerful, you can get much more creative, and the important thing is it got done fast (I wrote a distributed job scheduler in 2 weeks + 1 week to clean it up and work out the kinks, it's already running stably in production)

</comment></comment></comment></comment><comment><USER5> This went past me as the post is filled with a lot of claims with no reasoning to back those up. It is not a critical evaluation of the language, but rather sounds like a "fanboy" piece, for the lack of a better term.

> Memory efficiency is much better than most other languages (with the > exception of Rust, but Elixir is miles better at Error handling than Rust, > which is a more practical feature IMO

How exactly are arbitrary runtime exceptions better? Any elixir function you call has the potential to crash. Meanwhile with Rust, your function returns a `Result` if it can error, and callers are then forced to handle those by the compiler, either via pattern matching or ergonomic error propagation.

Rust has runtime panics, but those are for rare unrecoverable errors and are not at all used for conventional error handling, reserved usually for C FFI, graphics code, etc.

<comment><USER6> @chmin thanks for the great feedback! ;-)

I did not write the post for _general_ consumption, more as a reply to the question from the person as indicated in the first paragraph of the thread ... I _really_ did not expect it to end up on HN. ¯\\_(ツ)_/¯

100% Agree that there is a lack of "critical evaluation" and it _borders_ on "fanboy" ... It's not a scientific or statistical analysis because I did not find any _data_ I could use to make a an argument either way.

My experience with Elixir, JavaScript, Ruby, Java, PHP, etc. is based on doing the work in several companies big and small and I don't consider myself an "expert" in any of these languages. I have felt the _pain_ of having to maintain/debug several large codebases with incomprehensible/impenetrable and untested code over the years and I find Elixir to be the most approachable of the languages I am fluent with.

I _wish_ there was an _objective_ way of assessing the day-to-day experience of _living_ with a language ... have you come across such a measure that isn't based on the opinions of, as you say, "fanboy" users?

You appear to have superior knowledge/experience of Rust. Have you written any tutorials or blog posts _sharing_ that knowledge? I would _love_ to read your work. Is this you: [https://github.com/chmln](https://github.com/chmln) ? If it is, [https://github.com/chmln/asciimath- rs](https://github.com/chmln/asciimath-rs) looks cool! (nice work! :-)

<comment><USER7> I _really_ think that you don't need to _utilize_ italics to make yourself _appear_ like you care.

<comment><USER8> I found the emphasis helpful

</comment></comment></comment></comment><comment><USER9> I've been working with Elixir in a single-developer production system for over a year now. I'm running it in Docker containers on Kubernetes, in the cloud.

It has been extremely stable, scaling has been a non-issue. Error reporting has become easier and easier, now that companies like Sentry and AppSignal have integrations for Elixir.

Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. Incredibly fast on static assets, still very fast for anything else.

I've had nothing but fun with the language and the platform. And the Phoenix Framework is just icing on the cake. I've been fortunate to have been to many community events, and meeting (among so many others) José and Chris at conferences has made me very confident that this piece of software has a bright future. The Elixir slack is also VERY helpful, with maintainers of most important libraries being super responsive.

I would not start another (side or production) project with anything else than Elixir.

<comment><USER10> > Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects > immediately, while still serving the static parts of the application. PDF > generation wonky? Same thing.

I still don't understand this.

I don't think I've ever built a web server in any language where this wasn't true unless I specifically wanted hard failure.

The amount of fault tolerance would be a per-app design goal rather than something that seems to be a language feature. I've worked in apps in all languages that range from any failure being a hard failure to being impossible to crash, and this is due to business requirement.

For example, regarding your examples, just about every web server I can think of will automatically turn uncaught exceptions into 500 responses unless you opt otherwise.

<comment><USER9> It's less about how it handles exceptions but rather how the BEAM makes sure that things that break don't crash the whole system.

The magic is in the supervisor pattern, explained here for erlang: [http://erlang.org/documentation/doc-4.9.1/doc/design_princip...](http://erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html)

It is hard to describe why this "feels different" in Elixir than it does in Express.js or a Tomcat running a Java application. It's all experiential for me, but maybe I can put the sentiment in words: I always KNOW that whatever part of my application may break, however much and for whatever duration, the scheduler and the supervisors will make sure that the rest of the system runs exactly as intended, and the broken part of the system will be back up eventually. I did not have this feeling (as strongly) prior to working with Elixir.

But I will admit this is a very subjective position. And I am not sure you'd experience it the same way were you in a similar situation.

<comment><USER11> But with Kubernetes what's the point of BEAM?

<comment><USER12> BEAM is a battle-tested, decades-old technology that most likely runs a critical part of your telephone network. You're pretending that K8s, the newcomer, is already the incumbent. Are you sure you've done a proper assessment?

<comment><USER11> The critical parts are run in C not Erlang. You think Erlang is fast enough to route packets? btw routing packets and running a backend are two different things.

<comment><USER12> When you said: 'With Kubernetes what's the point of BEAM?', what exactly were you talking about? How does Kubernetes make BEAM pointless?

<comment><USER13> It doesn't make BEAM pointless, but _fault-tolerance_ and _scalability_ (two of the core features of Elixir/BEAM) are also handled by k8s. If you use Elixir/BEAM for these features and deploy on k8s, it may seem redundant to use them both together. Maybe that's what parent is referring to.

<comment><USER12> K8s is great for service orchestration and _horizontal scaling,_ and lots of people in the Elixir community use it to deploy, while using Elixir itself to implement fine-grained fault-tolerance logic and _vertical scaling._

A dead BEAM process can be restarted in a few microseconds, load up some complex state, and keep going. I don't believe the same can be said of a dead K8s service.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The JavaScript Fatigue argument is not good. There's simply no data that backs it and nobody is forced to use new libraries only because they use JavaScript.

I've seen third party dependencies churn on Elixir as well (packages that are no longer maintained or alternatives that are better) - I think it's an inherent problem with using dependencies and has nothing to do with the programming language in which those dependencies are written.

> As a developer I just want to get on with my work, not have to read another > Hackernoon post on how everything from last week is obsolete because XYZ > framework

My recommendation is that you don't read Hackernoon. This seems like a very ineffective way to level up your developer skills.

Edit: I agree that Elixir is very nice and would pick it over JavaScript for backend heavy applications without thinking. I just don't think this argument makes any sense in that context.

<comment><USER15> > nobody is forced to use new libraries only because they use JavaScript.

It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force you to change modules/libs regularly. This is to be compared to the Java ecosystem for example, were more people are working together to build well supported/high quality libs (Apache libraries for example)

<comment><USER16> Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.

<comment><USER17> Uh, what?

It might've become the defacto standard for consuming them, but definitely not for creating them.

Almost no service I've ever administered used a nodejs backend.

<comment><USER18> He never said anything about node being prevalent, only that Express was within node.

</comment></comment></comment></comment></comment><comment><USER19> I've been fortunate to work with a CTO that sees the value in Elixir and also letting us push forward with it. It has been _excellent_. At this point we have about 20 engineers who have chosen to work in it close to full time for their services.

It's hard to pick one big draw, but I'd say the biggest for me is that everything I wanted to do in rails has been possible in Elixir and then additional functionality not easily possible in rails is trivial in Elixir. I often consider the distribution techniques as "enhancers" as you could work around them with global locks and data stores, but you don't need to.

I'm very bullish on Elixir and I'm curious to see where it will go. Looking forward to giving my talk about bringing Elixir into production (from a human and technical standpoint) at Lonestar Elixir conference.

<comment><USER20> > everything I wanted to do in rails has been possible in Elixir and then > additional functionality not easily possible in rails is trivial in Elixir

I also noticed that every functionality I write in both Ruby and Elixir is both more concise (less code) in Elixir as well as 5-10x faster :)

</comment></comment><comment><USER21> Elixir has great things "of his own":

* the syntax is well though-of (`with`, destructuring, `|>` are powerful

* message passing has great use-cases

And then it has problems that are not necessarily "elixir-y", but are there nonetheless:

* it's hard to model an application around the Actor model. It's very easy to abuse it.

* it's hard to maintain / refactor a large application without help from the compiler before run-time

* it's hard to maintain an application in a language with a young ecosystem and no "seamless" integration with a better established one (ports are _not_ seamless.)

Quite frankly, I'm looking forward to writing a backend in Rust, to have a point of comparison.

<comment><USER22> The fact that it's dynamically typed is also often overlooked, while it's at the top of my deal breaker list.

The programming world is strongly moving toward statically typed languages, because today, there's pretty much zero reasons to use a dynamically typed language.

<comment><USER12> I agree and believe that it's harder to maintain a dynamically-typed codebase, but Elixir has a well-thought-out gradual typing solution: typespecs ( [https://hexdocs.pm/elixir/typespecs.html#basic- types](https://hexdocs.pm/elixir/typespecs.html#basic-types) ). This builds on Erlang's Dialyzer tool and is supported by editor plugins like VSCode's ElixirLS extension. In practice, you do get instant typechecking while you code, _if_ you write down the typespecs properly.

<comment><USER23> Debatable in practice, given the lack of a type system that actually enforces checks -- Dialyzer's even less complete, not to mention its poor error messages.

Elchemy, Alpaca, and Gleam try bringing static typing to the BEAM, but they're still too immature, unfortunately.

<comment><USER12> Agreed, but even with the above issues, Dialyzer still gives you, let's say, more than 50% of what you'd be getting with an ML-like type system.

</comment></comment></comment></comment></comment><comment><USER24> Could someone give a more concise reason for using Elixir? I have a "rule of 3" for checking out things - the third time I hear it mentioned and it seems interesting, then I'll go check it out.

Elixir is past 3 times - so I will check it out for sure! - but this article didn't seem to actually say anything (seemed more like a PR piece that was trying not to be technical, and the main argument appeared to be "well, it's not javascript!").

The part that actually talked about Elixir listed some Pros that didn't seem that unique. What's the "killer feature" of Elixir - or is it just a combination of "good features"?

<comment><USER25> It's the synergy between the language, the runtime and the standard library to deliver the actor model.

Elixir "threads" are called "processes". It's a bit confusing at first, but there's a good reason for it. So from hereon in, when I say "process" think "thread".

Elixir processes, like OS processes, are fully isolated from each other. If Process A has data than Process B wants, Process A has to ask it (send it a message) and can only get a copy of the data (like real OS processes, hence why the name makes sense). The advantage to this is that data ownership is explicit, race conditions are eliminated, and code is less coupled (A can't have a reference to an object that points to B that points to C..., that anyone anywhere in the code can mutate).

At a high level, this allows you to get many of the benefits of microservices, without the high cost (deployment complexity, service discovery, lower performance).

We run an analytics on live sports which does various transformation on a stream of play by play data. There are very distinct features: boxscores, lineups, scores, time alignment, broadcast information...For each live game we start a process for each of these features. When a play by play event comes it, we pass that to each worker of the appropriate game, and each worker does its own thing.

The workers are isolated. Not just the physical code, but at runtime. This makes them easier to test, refactor and grasp.

There's some interaction between the workers. For example our boxscore worker needs to know the score at a given time. So it sends a message to the score worker for that game: {:get, time}. The score worker replies with the score. There's no need for explicit locking. A process handles a message at a time. There's no chance that the boxscore worker changes the score worker's data (it can change the copy of the data that it got, but that change is only on the copy).

Really, it's most of the benefits of microservices (and I mean, being able to have true MICROservices, not just rebranded SOA) with few of the downsides.

<comment><USER20> Spotted the BleacherReport guy (...I think!) ;)

<comment><USER25> Nope. I work at [https://www.secondspectrum.com/](https://www.secondspectrum.com/)

</comment></comment></comment></comment><comment><USER26> If the erratically emphasized text bothers anyone else, you can get rid of it by running the following JS in console:

        document.querySelectorAll('em').forEach(el => el.replaceWith(new Text(el.innerText)))

<comment><USER27> Great, thank you. I have no idea what the author was trying to achieve there, but it made the article really difficult to read

</comment></comment><comment><USER28> Sure.

I am building a quite involved video learning platform as we speak with Elixir and Phoenix. No regrets so far, and if anything as time goes on, I'm becoming more and more happy with the decision.

The community is really great and there's a lot of quality libraries available. Not just libraries, but entire production systems too. For example [https://changelog.com/](https://changelog.com/) is written with Elixir / Phoenix and their platform is open source'd at [https://github.com/thechangelog/changelog.com](https://github.com/thechangelog/changelog.com). There's so much good stuff in that repo to learn from.

Also the Elixir Slack channel has 20,000+ people in it and the official forums at [https://elixirforum.com/](https://elixirforum.com/) are very active.

</comment><comment><USER29> I've been using Elixir to build applications for production use for 3 years now my summary is I and my whole team can (in contrast to languages I've used in the past):

\- Ship faster

\- Write simple, readable, reliable and fast code

\- Scale easier and with less resources

\- Onboard and train new hires into the code base quicker

I know I'm making it out to be a panacea which to be clear it isn't as the deployment story still has some final pieces for the core team to work through but I will say I'll continue to use it to build in the future

</comment><comment><USER30> I use Elixir daily for the past 8 months, and I love it. For my personal projects, I use a great Heroku-like service called Gigalixir ([https://gigalixir.com/](https://gigalixir.com/)). No restarts or connection limits for the free tier, and it runs on your choice of Google Cloud or AWS behind the scenes. Elixir doesn't have as many easy cloud deployment options as, say, JS, so this service is really helpful.

</comment><comment><USER31> Yep. Would bet on it again. It's proven itself to me and my employer, and has increased developer productivity and joy dramatically. Bad code looks bad, good design emerges organically, and macros let you hide the plumbing where needed, and optimize things away at compile time. Not even mentioning the wonderful world of OTP.

</comment><comment><USER32> Yes! And most likely in 2020 as well.

I've been programming intensively in Elixir for the past two years and it's a wonderfully productive language, which allows one to write elegant systems that leverage the multi-core architecture of today's machines effectively.

In addition, the networking capabilities and fault tolerance of the VM make writing systems which spawn machines and services a breeze; not the mention the ecosystem only gets better by the day.

So yeah, Elixir is one of my main tools when I want to get things done elegantly and productively. And if for some reason I need to speed things up a bit here and there, I just add a little rust into the mix. [1]

[1] [https://github.com/hansihe/rustler](https://github.com/hansihe/rustler)

<comment><USER33> What sort of work have you been doing with it?

<comment><USER32> I've been writing a social collider for real life social interactions on demand. The backend is written in Elixir (which is a collection of services e.g chat subsystem, telemetry, authentication, rate limiting, etc) and the client is an iOS app, so Swift, which is also a nice language btw.

</comment></comment></comment><comment><USER34> Tangent: It's proposed that Elixir has better error handling than Rust... but this doesn't sit well with me, and I know the Rust community is in flux here as well. I personally like not having exceptions. It's very easy to trace where an error is coming from when it's a value like anything else. Yea it might be a bit more typing... this is the conflict. Rust does have an issue with the boilerplate involved with writing error types, but there are already attempts at fixing this as a crate: [https://github.com/rust-lang- nursery/failure](https://github.com/rust-lang-nursery/failure)

<comment><USER35> Different tools for different jobs. Rust is more of a systems language for close to metal performance and memory safety. Elixir is memory safe from a functional perspective utilizing the actor model. Elixir is good for real time concurrency and higher level systems.

</comment></comment><comment><USER36> Question : How does OTP work together with things like kubernetes in the real world ? Designing around actors with OTP spawning and respawning part of the actor tree, while at the same time provisionning / deprovisionning VMs if load is going up or down, sounds like either a dream if it works well, or a nightmare if there's just a single glitch somewhere.

<comment><USER37> Best question in this thread and I am looking fwd to an answer. I guess that just very few mastered Elixir and k8s.

</comment></comment><comment><USER38> This post is killing me. I've been really really loving Elixir and for a while was fighting the "everything looks like a nail" syndrome once I learned it.

But now I have a contract that would really benefit from the runtime. That being said the existing environment has a lot of python expertise and I don't have enough production Elixir experience to have confidence in myself to deliver something of the right caliber.

It's a damn shame. This system has to process hundreds of thousands of API calls for workloads against a half dozen third parties that all have different rate limits and failure modes. It's the perfect job for Elixir. It needs to be as fast as possible while isolating failures to the smallest unit possible.

<comment><USER39> Honestly? I'd still encourage you to do it. The thing that's nice about Elixir, is that it gives you the tools to screw up and make good on it.

This isn't to say you'll write great Elixir from the beginning. I'm on a codebase now that was from back before the semantics of good Elixir were really well known(2016). It's not uncommon for me every week or two to rewrite a portion of it to look cleaner, and be more performant.

The crazy thing though? Holy _shit_ did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers.

We're still on one box. We still have plenty of the old, harder-to-read, less- performant code. And it still takes under 10 minutes to understand the deepest inner workings of any one feature in the system.

I think you'd be pleasantly surprised.

<comment><USER40> > The crazy thing though? Holy shit did it scale. We're doing event processing > for an application that is processing nearly 100m events per week. At times, > it needs to process 1500 per second. These events need to check the DB > multiple times, fan out to multiple services, and make discreet HTTP calls > of their own to external servers.

Frameworks make a huge difference here rather than language. Phoenix and Ecto have done a really great job with performance.

Ruby will deliver the same performance on a similarly light framework like Sinatra/Roda + Sequel but definitely not Rails.

Once you get a high performance service running on Phoenix + Ecto or Sinatra + Sequel, the gains from moving to compiled languages are a lot smaller unless you invest a huge amount of time in optimisation.

</comment></comment></comment><comment><USER41> I love Elixir.

It's the first language I genuinely enjoy reading and writing even in my private life.

If I wonder about the internals of a library I use, I can just look into the code and kind of understand what's happening. Never had that with JS or anything.

I'm just a genuine fanboy.

Only drawback I feel is: Some libraries that would have been quite developed in JS are not that well developed in Elixir. Some libraries are quite dead and it's hard to find alternatives (mostly obscure stuff)

But on the other hand, it often seems manageable to just write it yourself, or fork it and move on.

</comment><comment><USER42> I have never used Elixir, so maybe it's a great language, maybe not. But I have to question the reasoning of the post simply going by the comments about other languages in the "Conclusions" sections — some of which I did use extensively.

Really, Go "is the choice if you need to 'sell it' to a 'Boss'" and the imperative programming style leads to more complexity? And Python/Django can only be used if you "don't need anything 'real time' and just want RESTful 'CRUD'".

I get it, you guys like Elixir, but painting the world using such broad strokes doesn't really sound like "kaizen learning culture" to me, but more like "Negative Nancy".

<comment><USER43> I really like Elixir. There are a lot of practical realities that can make Elixir not the best language to use in many situations, and the same is true for any language. Just ignore the hype train, because you'll find one for every language.

I'd say Elixir's killer feature in today's day & age is concurrency. I'd argue that using concurrency is appropriate in most programming situations IF your language's concurrency model isn't a pain in the ass to use. You can write completely non-blocking, async code in Elixir (and Erlang) without losing your mind. The preemptive scheduling is nice, too.

I love a lot of other stuff about Elixir, too. Pattern matching, process supervision, tooling, documentation, etc.

</comment></comment><comment><USER44> Elixir just really nice. I gave it a shot again and it is super smooth experience nowadays. Distillery, mix, iex <3 Also most of the libraries I care about are 2.0+ and now this:

[https://github.com/aws-samples/aws-lambda-elixir- runtime](https://github.com/aws-samples/aws-lambda-elixir-runtime)

The only downside is that the out of the box performance is subpar for http services but it is still acceptable.

<comment><USER31> Cowboy measures its latency in microseconds, what bottlenecks are you running into specifically?

<comment><USER44> Not really, you can't have a microsecond latency talking over a network. I understand localhost microbenchmarks are nice but real life scenarios are much better.

The setup for the test:

\- provision node A for being the server

\- provision node B for being the client

\- open X (16..16000) connections from node A and use http pipelining start to send requests to node B

I use wrk2 as the test client it is pretty amazing and looking at the latency distribution graphs.

Tools that clear winners of performance:

\- [https://github.com/valyala/fasthttp](https://github.com/valyala/fasthttp)

\- [https://www.rapidoid.org](https://www.rapidoid.org)

Elixir/Cowboy/Plug is in the middle range, kind of like what Techempower[1] guys saw during their tests.

[1] [https://www.techempower.com/blog/2018/10/30/framework- benchm...](https://www.techempower.com/blog/2018/10/30/framework-benchmarks- round-17/)

<comment><USER20> Wrk2 is not fast enough and will thus give spurious results since the bottleneck is the client.

The only measuring tool that is fast enough to accurately measure Phoenix performance is something like Tsung (which is also an Erlang app...)

<comment><USER44> I am not sure what you are talking about. wrk2 can put out 7M req/s on a 16 core box. That is way beyond Phoenix's performance on the same HW type. wrk2 is widely used and accepted performance measurement tool. Again, you mentioned microseconds latency which means you are talking about localhost microbenchmarking. That is irrelevant from the production workload point of view. I have saturated network links successfully with wrk2 which is the definition of fast enough.

Interestingly there was a thread on HN previously which tools are used for HTTP perf testing:

>>> \- Wrk: [https://github.com/wg/wrk](https://github.com/wg/wrk) \- Fastest tool in the universe. About 25x faster than Locust. 3x faster than Jmeter. Scriptable in Lua. Drawbacks are limited output options/reporting and a scripting API that is callback-based, so painful to use for scripting user scenario flows.

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

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

<comment><USER20> alright. this looks interesting. I'll have to dive back into this space and see what's changed, I'm probably out of the loop. What's the diff between "wrk" and "wrk2"?

</comment></comment></comment></comment></comment></comment><comment><USER45> Our team has had great success with Elixir over the last year and ported core node services to it over the last few months. We are very happy with the results. There are some things we haven't been able to do with it, like intensive data processing (for which Python is still used), but if those libraries existed we would switch our Python services ASAP and be an entirely elixir backend.

</comment><comment><USER46> Why does the "author" love "quotes" so much? Makes me "discount" the "article" when every other phrase is "quoted".

</comment><comment><USER47> Considering progress in statically typed languages with regard to programmer ergonomics, does it still make sense to go with dynamic languages?

<comment><USER48> Between pattern matching and typespecs you get a lot of the "hey you're doing something wrong" checks at compile time to avoid errors. Definitely not a complete solution; a language like OCaml or F# will be better if you're concerned about type safety.

The dynamic typing in Elixir/Erlang is a trade-off for Actor model message passing. You get a state of the art run-time for fault tolerance and concurrency, but the messaging aspect makes typing problem-prone. A co- dependency on a custom type is coupling you want to avoid when sending messages around. You don't want a long running process that knows about Type_v1 sent a message from a newer process messaging with Type_v2.

The Aeternity team is building blockchain systems with Erlang for nodes and infrastructure. However since smart-contracts necessitate so much type safety and formal verification - they're designing an ML flavor functional language just for that.

</comment></comment><comment><USER49> I keep wanting to be hyped about elixer but the performance benchmarks confuse me. If you look at the tech emperor benchmarks[1] phoenix makes the list at #46 registering 16% of the performance of the top framework. I'm willing to sacrifice performance for readable maintainable code but it just surprises me that its that slow.

Anyone know whats going on there?

1\. [https://www.techempower.com/benchmarks/#section=data-r17&hw=...](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&l=zg24jj-1)

<comment><USER50> Simply looking at its position in that list will tell you nothing without looking at what is above and below. I don't use Phoenix or Elixir but from what I understand Phoenix tries to be for Elixir what Rails is for Ruby. That is, it is a full web framework. The number one position on that list is a "Asynchronous PostgreSQL driver".

This would be a more apt comparison:

[https://www.techempower.com/benchmarks/#section=data-r17&hw=...](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&c=6&o=e&f=zik05z-zik073-zik0zj- zik0zj-zhxjwf-zdk8an-q2xtz3-qmx0qn-e3)

</comment></comment><comment><USER51> I have mixed feelings about using Elixir (or Erlang); as far as I understand the platform, it is about building fault tolerant systems/high availability, specially in the presence of hardware failure. I think those are handled well by cloud service providers; they didn't exist during the 80s.

I think performance is better compared to Ruby and Python, but then again my experience with web applications is that the domains are best modeled using classes.

For writing networking code and protocols, the binary pattern matching is amazing, though. The Plug libraries are a pleasure to use also.

</comment><comment><USER52> Does anyone have experience with Elixir as well as Scala/Akka. Afaik, these are the two largest Erlang inspired systems out there. I only have experience with Akka, and I'd love to hear a comparison.

<comment><USER53> I have experience with both. I have recently been working with Elixir. It's okay. I find the lack of static typing to be some thing I celebrate and curse. Elixir is VERY simple and beam is VERY slow at computation. I wouldn't recommend anyone working with scala/akka look at elixir unless you want to understand how BEAM works but I would recommend _everyone_ working with elixir learn different functional programming languages. Ultimately I'm much happier writing scala with akka. I get more done faster (except things like handling json sometimes because it's hard with types), can refactor the code more freely, and release less broken code to production.

<comment><USER53> Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala. You get rubyists that have some interest in working with elixir because there were some blog posts saying it's the new hotness. Scala seems to attract more comp-sci savvy people. And generally those people will refuse to work with elixir when there are Scala job out there that will pay. Startups should use scala for these reasons. Elixir may be a mistake for the resource pool alone.

One thing that's trecherous is that rubyists can bring whatever they believe to be the right way to do things and assume everything should be exactly the same, especially with regards to ecto vs active record. Elixir isn't ruby. Ecto isn't rails active record. Not anywhere close. It just happens to look like ruby and there are some influences in the design but Ecto tells you not too implement STI like rails does for example so don't assume you're going to do it like you would in rails. I'd argue ruby is more like scala than it is like elixir as it has multiple paradigms. Elixir is squarely functional, just a very very simple functional language. The skill ceiling is pretty low and it should take very little time for someone to get up to speed which is important because you won't find a big pool of rockstars using it in the job market so you'll have to hire good people without experience and hope they will be okay using elixir and not jump ship to go work with strong typed languages.

<comment><USER4> > Also, I have to say that elixir developers are generally not very > experienced with it and seem to be generally less desirable than the people > who are working with scala.

Scala has been around for 14 years and is built on top of a much more used VM compared to Elixir. Given Scala's growth, it is expected that Scala developers are more experienced as they have been around for longer. Scala also had more time to spread to comp-sci fields, especially as it is taught by many universities. All thanks to Scala's merits, of course!

So while I agree that experience is a factor, I wouldn't draw conclusions that those are intrinsic to Elixir or to its users. I also have heard of companies that had no trouble to hire Elixir developers (some have 80 Elixir devs and growing) and some that had many difficulties. As with any other technology, YMMV.

</comment></comment></comment></comment><comment><USER54> Very interesting language (and OTP platform), I wish I learned it earlier.

<comment><USER55> Thanks for your work on Milestone/Droid ;)

<comment><USER54> Haha, thank you!

</comment></comment></comment><comment><USER56> From a technology perspective, a thousand times yes. And the same for Ember JS (my other go-to).

But from a talent and recruiting perspective, I'm less enthusiastic. Elixir, yes, there's growing talent. But Ember, boy it seems like nobody is doing it, and I've had to convince potential candidates that it'll be worth their time for future employability to learn Ember.

</comment><comment><USER57> I started read Programming Elixir and Programming Phoenix. Elixir is amazing.

</comment><comment><USER58> Did this article claim Haskell was slower than Erlang/Elixir?! That's never been my experience and I've shipped both!

</comment><comment><USER59> > _No "native" type for JSON data. You always have to parse JSON into a Map > and there are excellent libraries for doing this._

I guess the better question would be why is there not an easy, standard lib for doing this in _any_ language in 2019?

<comment><USER60> I didn't read the article, but intuitively, from the quote you posted, I'd say it's about having JSON(or close to)-literals in the language and/or having Map/List types with semantics close to that of JS. For example, in Python dict and list literals are perfectly valid JSON if you remember not to use single quotes (' vs. "), and the semantics are also pretty close to JS. In Elixir this is not the case: the Map syntax could pass for JSON if you squint hard enough:

        %{key: "val", key2: [1, 2, 3]}

but the semantics here are actually something like this in JS:

        {Symbol("key"): new Int8Array(/*utf-8 encoded*/ "val"), Symbol("key2"): new LinkedList([1, 2, 3])}

you can get rid of the `Symbol()` part in the translation, but then the literal becomes:

        %{"key" => "val", ...}

so, basically, the gap between JSON and Elixir is wider, both syntactically and semantically, than it is in some other popular languages.

</comment></comment><comment><USER61> I would like it a lot more if it wasn't forced on me by my coworkers.

</comment><comment><USER62> I love Erlang's OTP, but I would never go back to a dynamically typed language.

Most of my current work is in Go, which is a fairly strict language, and I value perhaps more than anything the ability to verify my program at compile time -- for one, I can do large-scale refactoringest, safe in the knowledge that my program won't run until everything is again sound.

Go still leaves a lot to be desired, so I've been exploring options. I've started picking up Rust. I love the idea of zero-cost abstractions, though at the moment I find the mental overhead of a lot of the constructs (lifetime annotation, implicit operations that happen due to what traits you implement, the many baroque syntax choices, etc.) a little annoying. It brings to mind modern C++, which also has a lot of rules that you have to remember, from copy constructors to what the order of "const" in var/arg decls mean, to the awkward split between functional and imperative styles.

Modern C++ looks interesting, and I've used it for a few projects. What bugs me the most is the warts still not fixed by the "modern" iterations: Include files (leading to long compilation times), lack of modules, unsafe pointers, etc. While I appreciate and understand template mechanics, I'm not overly impressed with some developments -- Rust traits and Haskell typeclasses just seem so much less messy than the current situation with type traits and concepts. There's a tendency in "modern" C++ to offer multiple syntaxes for the same thing, none of which are very intuitive.

I've occasionally written small things in Haskell and OCaml, and I've considered doing a future project in OCaml now that multicore support is getting close. I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Same with C#. I've looked at Nim, but it's too niche -- for the projects I'm going to work on, I'd have to write libraries for functionality that just isn't there yet (e.g. gRPC).

Back to Elixir, though; the problem is of course that none of these other languages offer anything like OTP. The closest may be Haskell, with it's Distributed Haskell project. But I'm not sure it's anywhere close to being as mature. Maybe Pony is comparable, but that also seems quite niche at this point.

<comment><USER23> > I looked at F# for a bit, too, but it comes across as having too much > .NET/Microsoft flavour for me.

Mind elaborating? F# seems like a decent fit from what you've said. I'm hoping the language will grow less stagnant as .NET Core matures.

<comment><USER62> I'm a big fan F# the _language_. It comes across very as a modern, cleaned-up version of OCaml — F# started out as an implementation OCaml, after all — with some very interesting innovations.

However, it comes with the baggage of .NET Core, which is a rather big thing. And it's growing, as Microsoft is apparently porting over everything from the older, non-cross-platform .NET stuff. For one, .NET Core includes the CLR/CIL, i.e. the JIT VM and cross-language integration, which I'm not interested in at all; I just want an AOT compiler. The AOT support seems like a fairly recent addition, and it's unclear to me how optimized it is or how well-supported it is compared to the older CLR-based toolchain. As a standard library, CoreFX seems rather large, and contains things like GUI and SQL Server support, for some reason.

In short, .NET Core seems like something you'd love only if you were already heavily invested in Microsoft's tech stack. I'm not interested in it myself.

<comment><USER23> I see -- most complaints I've heard about .NET Core relate to F#'s status as a second-class citizen vis a vis compatibility problems, which have recently resolved.

I'm with you on AOT, but I think the language makes more sense if you understand it as a .NET port of OCaml. If you isolated F# from CLR, you'd lose libraries and tooling, arguably F#'s raison d'etre, pleasant design choices aside.

</comment></comment></comment></comment><comment><USER63> Depends on the project. I have a project that heavily relies on headless chrome for scraping dynamic pages I'd rather stick to Node and Puppeteer for this particular project. In general Elixir is a joy to use but some of the trade-offs BEAM(Erlang VM) makes might not match your requirements e.g. if you don't need live code upgrades but project could benefit from static typing you might want to consider something else.

</comment><comment><USER64> Elixir is a niche (that's the truth). Also in the article it is written 'Relatively difficult to "recruit" developers with existing experience in Elixir'.

Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.

<comment><USER65> The only times I see this argued is from suits looking to treat programmers as a fungible resource. This is never a problem for companies looking to retain people.

If your status quo is working programmers as long as you can without a raise until they switch jobs, a niche language is a threat. If you re-evaluate your staff based on their experience gained, you can head off the churn.

<comment><USER42> I think this is too harsh. A company can establish an enjoyable and empowering culture, that attracts and supports talented developers — and can still try to avoid hiring obstacles at the same time. It might not have been what therealmarv meant in his post, but your comment makes it sound mutually exclusive.

As a counter-argument: I've experienced several times that "niche tech" companies offered non-competitive salary packages and perks, because they offered the cool tech instead; "sure, we can't match that other offer, but we built our stack on that language/tech that is so hot right now".

Not arguing about the quality of Elixir, just about the gatekeeping that happens in this thread.

</comment></comment></comment><comment><USER66> Has anyone had experience of both Elixir and F#?

I've dabbled with both - but really fell in love with _both_ of them! I come from a C# background, so the static typing of F# is a big pull. OTOH, the simplicity of Elixir was an absolute delight - after just an afternoon, I felt like I had a decent grasp of it.

I'm conflicted, and would value some other opinions?

<comment><USER23> Depends on what you want to do, I think. The pros of the BEAM likely outweigh the cons of Elixir's dynamic types for distributed messaging systems, e.g., Discord. Otherwise, F# and the SAFE stack probably can serve other backend needs more safely with better library support from .NET. Elixir does seem more trendy than F#, which has lagged somewhat due to second-class support from Microsoft and lingering dislike for .NET -- hopefully things will improve as .NET Core matures.

</comment></comment><comment><USER67> can people give real world business use cases for where they are using elixir? What industries are you working in? what actually gets done in the real world at the end of the day with the system you're working on? e.g. are more ads served to web users? are you monitoring methane on IOT things strapped to cows in farm fields?

<comment><USER68> PagerDuty has standardized on Elixir as the backend language of choice after a couple of years of incremental adoption with new services. Developer happiness definitely helped get the word spread. [https://www.pagerduty.com/blog/elixir- at-pagerduty/](https://www.pagerduty.com/blog/elixir-at-pagerduty/)

<comment><USER67> Ok so they use Elixir there to make dashboards. cool.

<comment><USER68> Highly available critical services comprising the PagerDuty infrastructure, actually. Cool dismissal though.

<comment><USER67> what are some concrete examples?

</comment></comment></comment></comment></comment><comment><USER69> What kind of problems are people using Elixir to solve in production? My impression is it's mainly useful for highly networked applications with real- time features (i.e. chat), but it seems like for most applications you'd be better off picking rails or nodejs for the community/ecosystem.

<comment><USER70> I dislike coding in javascript for large project. The language was originally for small stuff.

NodeJS bought it to backend and the language itself weren't meant for it. Since then ECMA5 and stuff tried to fix these shortcomings. But you can't expect me to love javascript's weakly type versus elixir or python's strong type (strong not static, as in it doesn't implicitly type convert stuff like javascript). It's a nightmare and concurrency model in NodeJS in my opinion is subpar compare to Elixir's.

</comment></comment><comment><USER71> From someone that comes from Java/.NET land, I hardly see a benefit, specially given the wealth of programming language options on those platforms.

Now for someone starting new, maybe the Erlang eco-system might be a good bet, and Elixir an entry point.

Still, not everyone has Ericson scale problems to solve.

<comment><USER60> Erlang (and, by extension, Elixir) is still one of the very few systems which offer this exact (or even just close enough) mix of features AFAIK. Whether this set fits your use-case or not, and whether it would give you an advantage over your chosen technology, are both very important points, but there's also something to be said about how good and well-implemented it is for _some_ use- case(s). To be honest, I first learned Erlang along with Prolog, Forth, Lisp or J - out of curiosity about various paradigms and the most "pure" implementations of them. Erlang was at the time the oldest, actively developed, open-source system for concurrent and distributed programming. Today I think I'd go with Pony, which implements Actor-model on the language- level too, but also with support for it in the (static) type system.

Anyway, what I wanted to say is that Erlang is first and foremost a fault- tolerant language and system, of which both distribution and concurrency are by-products. As an example of a "fault" that the creators of Erlang had in mind, Joe Armstrong often cites "being hit by lightning": the only way to ensure the system will still function after that is to have its copy running somewhere else, hence distribution. Another type of fault I think explicitly mentioned in "Programming Erlang" is dealing with hardware failures, sensors and outputs getting disconnected and reconnected, etc. - hence concurrency and per-process error isolation. Finally, "programmer errors" are also a kind of a fault (as impossible to completely avoid as lightning or flood), hence immutability, versioned rolling upgrades and rollbacks and live introspection into any node from anywhere in the system (among other things).

That is not to say that the by-products aren't important or nice to have, just that many of the design decisions in Erlang start making a bit more sense if you look at them from this angle. It also helps to decide whether Erlang is the right tool for you: it's going to save you many, many years of effort if you need a nine-nines guarantee for a system you'd otherwise have to write a few million loc of C; it can still give you a bit of an edge if you are able to make use of its unique features like a built-in distributed data-store or if the Actor-model with preemptive scheduling fits your app very well. Outside of these pretty specific use-cases (although, to be fair, I'm just giving examples - Erlang/OTP is a large (in terms of built-in functionality) system and Elixir adds even more stuff, so there are many more good use-cases for it) you may struggle to realize any positive outcome with Erlang: unfamiliar everything, no libraries, a runtime system always ready for connecting to remote nodes even if you're writing command-line script, immutability has a performance cost and overall performance is not impressive and so on, each of this things could potentially bring down your project if not carefully considered.

</comment></comment><comment><USER72> Sees post recommends [https://nerves-project.org](https://nerves-project.org) for IoT Clicks thru Sees that Nerves is an excellent platform for IoT and only requires a base of 12MB and Linux. Quickly backs away.

<comment><USER20> Do you have an actual rational counterargument? It is a completely stripped- down Linux that boots directly into BEAM.

</comment></comment><comment><USER73> Yes. I prototype in Node, but then usually move all the important stuff to Elixir.

</comment><comment><USER74> Elixir is the best programming language I have ever worked with. I absolutely love it.

Elixir has totally spoiled me. The meta-programming ALONE is something I miss constantly when I have to use other languages.

</comment><comment><USER75> If you are coming to elixir from a rails background, how does it compare? I looked a year or two ago and the number of packages was far smaller with elixir, which turned me off of it.

<comment><USER25> I think Elixir is quick to learn, long to master. You start off building web apps in Phoenix, being relatively productive from the start, and thinking to yourself "well, there's definitely some magic I don't understand, but this feels a lot like Ruby." You'll immediately notice and learn the smaller differences (immutability and pattern matching).

Then one day, you'll need to store and mutate data in process. And then you'll learn about GenServers and Supervisors.

Then one day, you'll want to have some base functionality but for whatever reason, composition isn't a good fit, so you'll start to dig into macros.

Fundamentally, Go is much more Ruby-like than Elixir (Ruby and Go have shared heap, global GC, array-based data structures, same evaluation strategy, mutability, ...). Elixir is very different. But it's discoverable.

</comment></comment><comment><USER76> I wouldn't pick Elixir because:

Rails has revolutionized web application development on Ruby, with Sinatra as the minimalist version and a lot of "me too" frameworks have been developed, and somehow I like them all.

* On Python, Django and Flask * On Elixir, Phoenix * On Crystal, Amber * On Javascript Express js for Sinatra. But on JS we didn't get a successful Rails clone, but a storm of front end frameworks, finally Vue JS/React and endless others.

I wouldn't pick Elixir because The world is elsewhere: My choice is on JavaScript ES6, Vue, and a simple Express.js, Sinatra, Flask for most projects.

<comment><USER77> > The world is elsewhere

The world is everywhere. Other people have pointed out Elixir is very good at taking advantage of multiple cores and writing distributed applications which are easier to reason about, less error prone and very efficient. I wouldn't say the same things about javascript.

</comment></comment><comment><USER78> Interesting perspective on the JavaScript ecosystem.

I never had any debugging issues in particular, but the dependency hell drives me nuts, too.

</comment><comment><USER79> Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with:

\- Pipelines are hard to debug. You can't just throw a debugger just before the line with the issue.

\- Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.

<comment><USER80> Both of these points are False, point 2 I've been integrating a bootstrap framework and sass and it's super simple; I put the files in assets, add npm install —save sass and that's it!

Then debugging a pipeline is as simple as dropping in IO.inspect between statements as it returns the content as well as printing.

        thing
        |> stage1
        |> IO.inspect
        |> stage2

Not that difficult!

<comment><USER79> > I put the files in assets, add npm install —save sass and that's it!

It takes forever if your assets are large. Just serving random static files shouldn't take long.

> IO.inspect

It's nothing like a real debugger.

<comment><USER81> I agree about the inspect / pry not being a real debugger but could you expand on your problems with the debugger and pipelines?

Are you using the Erlang :debugger module?

The only "problem" I see is that we can't set a breakpoint on the first line of a Elixir pipeline, but to see the value of variable from that line we can set a breakpoint on the last line of the pipeline. To see why that happens we can try stepping through a pipeline with the debugger: First "executed" is the last line of the pipeline, then the second line, then third etc and it looks like for the debugger the first line of the pipeline never happened. I don't think this is a big problem to be honest.

</comment></comment></comment></comment><comment><USER82> This feels like an orchestrated upvoting and content marketing flash mob from the Elixir Slack channel. Google Trends shows that Elixir is declining. I love new languages but don't like to be fooled.

</comment><comment><USER37> no it's premature optimization, you won't find any devs, 99% of elixir can be done in node + k8s.

</comment><comment><USER83> Love Elixir.

But _every_ other _word_ being _emphasised_ in this _article_ was tiring to read.

<comment><USER30> I agree. If you emphasize too much, it feels like you're trying too hard to convince me, kind of like news headlines IN ALL CAPS.

</comment></comment><comment><USER84> Isn't Elixir the most efficient thing available?

<comment><USER53> no elixir/beam is very slow for any computation-heavy tasks.

<comment><USER84> But what about not so computation-heavy tasks like parsing HTTP requests, interacting with databases, generating and serving responses based on the input, templates, reasonably simple logic and the data? And if it's not fast then why even consider it when there are more well-established alternatives like Ruby for those who like the syntax, ASP.Net/Core, Python/Django, Node/Express, Scala/Play for the FP lovers etc? I've been previously told it's key features are it's super fast, functional and Ruby-like.

<comment><USER85> Super fast, no. At least not in the C++ way. Faster than Ruby or Python, yes.

Functional, yes.

Ruby-like, yes, as German is English like (mostly guessable vocabulary.) Then you discover that the two languages work in totally different ways and your Ruby skills don't really matter anything when working in Elixir.

</comment></comment></comment></comment><comment><USER86> >> Node is a single-threaded event loop, if the process crashes for one user, it crashes for all the requests being handled by that process. i.e. one user can crash the server for hundreds/thousands of people! This is a terrible design flaw

This is a design flaw on the part of the team who is using Node.js incorrectly and not a flaw of Node.js itself. There are many ways to implement error handling properly in Node.js so that a user cannot crash a whole server/process and there are a lot of frameworks which implement this by default.

Elixir is over-marketed and over-hyped. It's obvious that there is a big money machine behind it. The entire community is obsessed with evangelizing; they're not getting organic growth; they have very aggressive marketing but it's mostly founded on exaggerations and flat out lies.

In addition to what I've pointed out above, to say that someone can learn Elixir in just 1 week is another example of a lie. It takes years to fully understand the nuances of a language to the point that you can be good at it; there are always a lot of patterns to learn; especially for functional programming languages.

The Elixir ecosystem will never be as significant as that of Node.js because Elixir's ecosystem is founded on hype. Part of the greatness of Node.js is that reality tends to exceed expectations; so-called 'thought leaders' and 'bloggers' have been working very hard to discredit Node.js from the beginning but they failed (see [https://news.ycombinator.com/item?id=3062271](https://news.ycombinator.com/item?id=3062271)).

I'm not going to consider using Elixir while it's so clearly over-marketed and over-hyped.

<comment><USER37> Couldn't agree more. Just look at Google Tends. Because Elixir is dying they do more and more content marketing: [https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0pl...](https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0pl075p)

In their Slack channel they orchestrate organized upvotes of such post like this one, they collectively downvote people like the parent and post fanboism through several accounts.

Elixir is a solution without a problem.

</comment></comment><comment><USER87> I guess I feel like the annoying formatting is indicative of the community, immature.

Web developers seem to follow trends; Perl -> DJango|RoR -> Node.JS -> Scala -> GoLang -> Elixir -> Something. Or, something like that. To me, it's like buying a $500 pencil and expecting that you should be capable of writing a better book.

If you get in bed with that crowd, don't expect that your program and 3rd party dependencies are going to be stable in 2 years.

<comment><USER19> A lot of individuals I've seen in the community so far haven't been the type to quickly jump onto a trend. People have been thoughtful with their application design and have chosen Elixir instead of alternatives. Given how drastically different the BEAM is from these other languages, I have a hard time seeing some of the people I've met (and myself) jump to something else. My guess is that if it does happen to others, it is because they switched jobs and cannot get buy in.

Pretty unfounded comments regarding stability of packages long term. As with any community that makes it easy to publish packages, there will certainly be package churn over time. However, core libraries show 0 sign of this and Phoenix in particular has taken a very mature stance on new features.

<comment><USER87> Yes. And in 3 years (or so) when the hype-train moves on, and all that is left is the core users. It will be a much more viable choice for development, in my opinion.

I don't think anything negative of the language or core libraries.</comment></comment></comment>


How to test your own SDS based on custom linux distribution - <AUTHOR> http://www.goncharov.xyz/it/how-to-test-custom-os-distr.html <comment><AUTHOR> Let's imagine that you are developing software and hardware appliance. The appliance consists of custom OS distributive, upscale servers, a lot of business logic, as a result, it has to use real hardware. If you release broken appliance, your users will not be happy. How to do stable releases?</comment>


India to be under complete lockdown for 21 days starting midnight - <AUTHOR> https://m.economictimes.com/news/politics-and-nation/india-will-be-under-complete-lockdown-starting-midnight-narendra-modi/articleshow/74796908.cms <comment><USER2> Wow! I wonder how India as a democracy can enforce this.

Does india have enough testing kits now?</comment>


UML Out of the Box - <AUTHOR> http://michaelfeathers.typepad.com/michael_feathers_blog/2011/06/uml-out-of-the-box.html

<comment><USER2> I thought maybe User Mode Linux had been improved, but this just talks about boxes and lines.

</comment><comment><USER3> Does UML still exist?</comment>


Tesla hires Snap executive as engineering VP - <AUTHOR> https://in.reuters.com/article/tesla-executives/tesla-hires-snap-executive-as-engineering-vp-idINKCN1IN2RJ <comment><USER2> This has really horrible optics (ha! see what i did here ?)

From social media to self driving? Are Tesla that desperate? Is Musk that hard to work with ? What is going on ??

For the record, i am a renewable and EV supporter

<comment><USER3> It's a terrible article, more like. LinkedIn says his job before Snap was for Facebook, title "Lead Technical PM, Applied Machine Learning".</comment></comment>


The Day the Moon Blew Up - <AUTHOR> https://www.gatesnotes.com/Books/Seveneves <comment><USER2> Seveneves is one of my favorites, even though it gets mixed reactions from a lot of others who've read titles like Anathem. I can't compare it to Anathem (the only other Stephenson book I've read so far is Cryptonomicon; looking to change that), but I can say I love the technical depth. Perhaps it's because it helps me suspend disbelief much more easily, though Bill's point that "if you're the sort of reader who doesn't care how such a thing might work, you will find yourself skimming parts of Seveneves" is probably true for most lay readers.

The only thing that somewhat frustrated me about it, as I suspect is the case for most people, is the fact that the last third of the book feels like it could (should?) stand on its own. That being said, there's enough room for Stephenson to explore in more depth some of the events leading up to the third act in subsequent novels... so here's hoping. I figure explaining why I feel this way would be a bit of a spoiler. Bill does enough to allude to it.

Anyway, thumbs up from me. I enjoyed every bit of it, and Bill's review does a good job of selling the book without spoiling it.

<comment><USER3> > The only thing that somewhat frustrated me about it, as I suspect is the > case for most people, is the fact that the last third of the book feels like > it could (should?) stand on its own

For me that last third part feels... rushed? I can not really explain it but the first two thirds of the book were awesome and then when you reach the last part you feel like Stephenson had to meed a deadline for printing and that part is just tacked onto the main story. It is way too short for its content, I feel like Stephenson could spend a good two or three books exploring this new story arc.

<comment><USER4> Stephenson tends to rush his endings - Cryptonomicon basically wrapped up in about 30 pages. But what got me was the abrupt change in view on that last third of Seveneves. I needed more transition time, as he's introducing a whole new society.

<comment><USER5> Isn't it the case for most notable scifi books? Enders game wrapped up pretty quickly in the final few pages.

</comment></comment></comment></comment><comment><USER6> The first third of Seveneves is a real gut punch. The only other world-ending story that comes close in terms of emotional impact for me was Arthur C. Clarke's "Childhood's End".

Stephenson manages to show humanity in all its realistic messiness but still leave you proud -- on balance -- that humans mostly get our act together in a desperate attempt to preserve a seed of life and culture.

<comment><USER7> I found Childhood's End an extremely unpleasant read, and so that comparison makes it hard for me to even think about reading Seveneves. It was just so depressing, taking the concept of isolation to such an extreme it felt abusive. Or maybe I shouldn't have read it while isolated myself (literally living and working in the middle of nowhere without transportation and minimal contact with anyone I was close to).

Maybe if I'd read Seveneves without ever having heard this comparison, I would have made it through to the part that makes you proud, but at this point I doubt that's possible.

Going to skip this one, and I'd suggest everyone else skip Childhood's End.

<comment><USER8> I read Childhood's End over 20 years ago but from what I recall I felt it was just an awesome book. I do not recall it being particularly depressing.

<comment><USER9> It's an awesome book either way, but it can be read very much either in a hopeful vein, or a very depressing one:

(Spoiler warning; for various works for the rest of this comment - assume that if I mention a work, there'll be a spoiler later in the sentence...)

Humanity stagnates before ending as the last of humanity's children transforms and are isolated from their parents. The parents generation slowly or not so slowly die out and no more children are born. The transformed children become one single collective intelligence, and that too is subsumed into a greater mind. In the end, the last actual human stays on an earth that evaporates.

On one hand humanity has "ascended" to a higher stage. On the other hand what is left bears no resemblance to humanity.

It belongs to a peculiar and I think quite rare strand of scifi where humanity abandoned humanity and was in the end entirely gone (as opposed to e.g. post- apocalyptic settings where there are still humans left, and where most of the stories tend to end on a hopeful note for repopulation), set in the near-ish future (as opposed to e.g. books like Stapledons Last and First Men, which also describes the end of humanity, but where the end is set millions of years into the future). I don't think that strand is seen very often any more.

There's been plenty, both then and later, where Earth has been abandoned and forgotten by a human diaspora that lives on elsewhere (e.g. Asimov's Robots/Empire/Foundation universe goes there), but that tends to have a very different feel to the stories where humanity just "fades away" or transforms.

My other favourite equally definitive end would be Clifford D. Simak's "City" which is told in the form of legends told by talking dogs of how humans left to transform into something else and eventually disappear.

Another, of sorts, would be Clarke's "City and the Stars", where there are still humans, but only two cities left on Earth after everyone else left and likely ascended. That difference, though, gives it a very different, more hopeful feel (but the last few pages of City and the Stars is the only book to have ever given me the chills), similar to the post-apocalyptic stories of small groups that endures.

Many others have gone with the "humanity almost wiped out, but not quite, oh and here's redeeming factors" theme, such as the various incarnations of Hitchhikers Guide to the Galaxy, where one becomes increasingly callous about the repeated destructions of variations of earth as the series progresses to the point where it's more of a regular event to cheer on safe in the knowledge earth will pop back into existence somehow sooner or later (even Douglas Adams attempt at getting his publisher to shut up about another sequel by ending Mostly Harmless with the destruction of Earth in every reality in the entire multiverse and then going ahead and dying on us didn't stop another sequel from being written ("And another thing..." by Eoin Colfer; surprisingly good for falling in the "lets try to repeatedly murder this story with Vogon death rays" category)).

Titan A.E. is another of the modern dark-ish depictions that gets close to finality, where humanity for most of it is depicted as just a few scattered remnants, but there is hope and not a definitive line drawn under it that in the end makes it quite a hopeful story.

Battlestar Galactica (both incarnations) falls in a similar category where the impending doom starts, gets nasty, and then you reach a steady-state of sorts (though the regular updates on the dwindling number of colonists does help to keep it dark), but then is never drawn to its conclusion, and that fails to make it as solemn.

There are of course other "nearly but not quite the end" stories.

Iain M Banks last Culture novel - The Hydrogen Sonata - has a similar theme, but set on an alien planet where the civilization has decided to ascend. It's a great book, but it too doesn't feel as dark, I guess, because it isn't the end of _humanity_.

The solemn feeling that this is the _end_ , and not an end set in a very far distant future, but not that far from now is present in Childhoods End and City. The atmosphere in those are also aided by describing the aftermath, including descriptions of the pain of many of those who feel left behind.

I'm sure there are others that I should remember, but I'm too tired to think of any right now. And I'm sure there are some I'm entirely unaware of. I'd be very interested in similar stories, and especially if there are any modern ones that are as "final" (as in: conclusively end with the end of mankind in the near future, instead of copping out with the existence of some small remaining group, or dragging it out into the far future).

<comment><USER10> SPOILER ALERT

The second Battlestar Galactica series does reach a conclusion, sort of. It ends with a loop backward in time, through a black hole. Surviving humans and humanoid Cylons interbreed with protohumans. So history is cyclical.

<comment><USER9> I don't think that description is right. They never fall into the black hole - they jump away. Unless I'm badly misremembering, it's pretty clear that the Battlestar Galactica crew's ancestors "earth" is a different planet.

At least the characters believe it is, and the Baltar and Six that appears in the epilogue also talks about it as a different planet and a new cycle.

While the theme of cyclical history is recurring throughout the series, that is about recurrence of a similar set of events, as in hinduism [1], not an actual loop.

[1] [http://www.hinduwebsite.com/hinduism/h_time.asp](http://www.hinduwebsite.com/hinduism/h_time.asp)

<comment><USER10> Maybe so. But the city in the epilogue does look very 21st century. That might just have reflected budgetary constraints, however. As in Caprica.

<comment><USER9> That's because the epilogue takes place on our Earth in the 21st century. But the "real" Earth they found earlier and left again was not. In-universe "our" Earth is named Earth because they named it as a reference to "their" Earth (which had been reduced to rubble).

<comment><USER10> OK, I need to go back and watch the last few episodes. I know that they had found a destroyed Earth. But then they went to that Cylon base, in orbit around a black hole. And then they fell in, as they were fighting their way out. And _then_ they ended up back on the Earth, ~50 thousand years ago. Or at least, that's what my wife and I remember :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> A couple of fun things hidden (or not exactly) in this video:

There's no missing a couple of Neal's swordfighting buddies at 1:07.

Wondering where the camera stand is? Look for its reflection in the window behind Bill at 1:52.

What car did Bill drive to the meet-up? Probably not the Model X. My money is on the Porsche 959 shown at 2:17.

(It's also a safe bet that the meet-up actually began at the Burgermaster, since that's in Bill's neighborhood. That way Bill only has to make one round- trip to Seattle instead of two.)

I'm totally failing to get the joke with the shovels and pickaxes at the corner of Boyer & Howe at 2:40. (Surely not a macabre gag as they cross towards Lakeview cemetery...)

And of course the gaggle of kids in Madison Park at 2:54 are observing the moon through a telescope.

<comment><USER12> Why wouldn't gates drive a tesla x?

<comment><USER11> Bill might well drive a Model X and any number of other cars -- his daily was an armored mid-90's Lexus LS for many years -- but if there's a Porsche 959 parked at the south Kirkland Burgermaster, the odds are overwhelming that it belongs to Bill.

This because only 345 Porsche 959's were ever built, and none were eligible for import into the US. That is, until Bill made himself instrumental in the passage of the show and display importation exemption* so that he could buy one.

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

<comment><USER13> Gates owns a silver 959. This one:

[https://www.instagram.com/p/MgiOYcGyhI/](https://www.instagram.com/p/MgiOYcGyhI/)

<comment><USER11> The silver one was presumed his, but not confirmed as such.

But Bill being Bill, he might be collecting them. :)

</comment></comment></comment></comment></comment><comment><USER14> "If Stephenson wrote Huckleberry Finn it would be 4,000 pages long and mostly about paddlewheel design"

\-- [https://twitter.com/baconmeteor/status/663076130077802496](https://twitter.com/baconmeteor/status/663076130077802496)

I have heard good things about this book, but it has been a while since I could get into Neal Stephenson's work. My favorite is one of his earliest, Zodiac. It's the only book of his I've read that doesn't just...end.

<comment><USER3> > "If Stephenson wrote Huckleberry Finn it would be 4,000 pages long and > mostly about paddlewheel design"

And this is the exact reason why Stephenson is one of my favorite authors.

</comment></comment><comment><USER15> I greatly enjoyed some of Stephenson's other works, but I was actually a bit disappointed with Seveneves. The narrative is well crafted, but unfortunately I just got stuck on the whole space ark concept and couldn't suspend disbelief enough to continue.

Maybe someone else can explain why it made sense to focus on an orbiting refuge, right in the path of the Moon's fragments, rather than dig a bunch of underground cities that would have saved many times more people.

Midway through the first unit, I basically decided they should have dug tunnels ten miles long, one mile deep at bottom, lay tracks, and just go full steam carting rocks out while digging massive caverns. They could move entire hospitals, schools, factories, labs, etc. into these places, store tons of food and supplies, lay pipes to connect to underground water supplies, set up parks, farms, and animal preserves using artificial solar lighting. Makes so much more sense to me than this nutty space station idea. And with gravity, access to minerals, oxygen, etc.

I love space as much as the next geek, but if you want to save millions of humans, you've got to dig.

<comment><USER16> Well...... You'd clearly be right if you were looking at a timeframe of a few years, or a few decades, or maybe a century or two.

But if you successfully establish a long term presence in space, you've got access to a lot of resources. If you're stuck in a hole in the ground for 5,000 years, and the surface is considerably more hostile than space, I think there's at least a colorable argument that space is the way to go.

Spoilers for the end of the book follow.

As it happens, remnants of humanity survive in space, underground, and underwater. This was the part of the story that broke my suspension of disbelief. I just couldn't really buy the end-third societies. It's like Stephenson couldn't get his mind around how long 5,000 years actually is.

Just as a for-example, language: In 3,000 BC, there might have been an unknown language that we designate proto-Indo-European because we don't actually have any texts that reference it. Proto-Indo-European might have begat another language that is still so ancient that we can only guess at it that we designate proto-Germanic which begat a family of West-German languages that begat Old English that begat Middle English that begat modern English.

Meanwhile, in 7,000 AD, apparently they speak a light pidgin of modern English that's pretty understandable to modern English speakers.

I get Stephenson's argument for why his far-future cultures are so directly related to the action in the first two thirds of the book, I just can't quite buy it.

<comment><USER17> Humanity has little experience with the speed of language evolution in presence of audiovisual recording technology. The Quran did not prevent Arabic dialects from diverging, but it sure slowed down evolution compared to other languages that did not have their own religious texts or got translations only much later. I think it is quite reasonable to expect an even lower amount of change with a vast, well studied corpus of audiovisual material.

(My personal illusion breaker was thermal management of the off-screen survivors: I usually would not dare to nitpick on such a thing, but when the topic has been elaborated so deeply for the ark-dwellers, I just can't switch back to the default mode of happy ignorance that quickly, in the same book)

</comment></comment></comment><comment><USER18> The whole last third of the book makes waaay more sense when you think of it as an MMO backstory:

\- Two factions (literally, red and blue) with mostly the same but kinda different everything

\- Thirteen-plus subspecies of human, with their own unique racial bonuses and skills (chain whip thing!).

\- Pristine, empty, Earth-like local, ripe for building...

\- ...and with monsters! And treasure!

Right?!

<comment><USER17> Or a fanfic playground, where writers are free to reuse the same basic cast of predefined stereotypes without interfering with each other's characters.

I think it's typical Stephenson: start with a clearly identifiable grand idea, get wildly sidetracked working towards it until the digressions are something much better, leave a skeletal version of the original idea for the end.

</comment></comment><comment><USER19> Note to future VR directors:

Don't do edits, and God don't change the default orientation of the camera! I know that goes against against 127 years of cinematic history, but moving the camera's default focus seriously confused my spatial awareness. I've turned so I can see them both, but oh no now I'm outside on the street, and now I'm back inside, but suddenly I'm rotated 60 degrees.

If this wasn't VR, it would t matter but in VR, it's putting the audience on teacup ride.

</comment><comment><USER20> I believe I've read all of Stephenson's books (yes, even The Big U)

Seveneves is in the top 5, but only just -- the Baroque Cycle (though not sci- fi) takes up three of the first five spots.

In terms of can't-put-down-once-started, Reamde tops the list, but, again, not sci-fi.

People seem to want to compare the content to Anathem, even suggesting it may fit into the same universe - though I can't see it myself. For what it's worth, both his SF and non-SF works are enjoyed by my other half, who usually eschews anything SF - so despite the alleged 'science-heavy style', there's one data point that suggests it's not as problematic as some reviewers expect it would be.

<comment><USER10> I also loved _The Baroque Cycle_ , and _Mongoliad_ (which also, now that I think of it, features that immortal mystic). It's hard to explain the connection with _Anathem_ without too many spoilers. So I'll just note that Earth does explicitly exist in the _Anathem_ universe.

<comment><USER20> Oh, I've read both Anathem and Seveneves, and while I appreciate that Earth is referenced in the former, I don't recall anything that felt like it may connect (no hint of a multiverse in Seveneves, f.e.).

I think I read some interview with Neal a while back where he said he hadn't considered writing anything else in the same universe as Seveneves, but if there was interest, he may come up with something. Obviously there's quite a few ways such a follow-up could go.

Probably time, and a good excuse, to re-read Anathem.

<comment><USER10> It's the Purpose vibe. Plus all the mystery about the Agent. But then, I didn't get the _Hitchhikers ' Guide_ joke about that :(

<comment><USER21> Many of Stephenson's books have some hint of Purpose to them. Either the characters are working towards their own purpose a la Avi and HEAP + Crypt or are being guided by people with a purpose like Fraa Erasmas in Anathem or Hacksworth in Diamond Age.

</comment></comment></comment></comment></comment><comment><USER22> I was just getting into Kerbal Space Program at the same time I started reading this book, and it's amazing how well they tie together. I would learn something about orbital mechanics in KSP, and then see it applied in the book, and I really enjoyed that feeling.

</comment><comment><USER23> Seveneves is one of the best sci-fi books I've ever read. It was a hard emotional ride.

(small spoiler follows)

One of the interesting gems I remember: the surviving humans looked back at the recordings of their ancestors, in particular about how their behaviour was affected by social networks - and collectively decided not to pursue that aspect of the Internet.

(This may actually be a plausible in-universe answer for why there's no Facebook in Star Trek.)

<comment><USER24> Watching people fight on Facebook and Twitter, I frequently recall Stephenson's vision of the human race nearly destroying itself with flame wars.

</comment></comment><comment><USER25> Larry Niven was awesome at apocalypses. The short story Inconstant Moon is one of the greats, plus he did a couple of thick novels on the theme with Pournelle -- Lucifer's Hammer and Footfall.

</comment><comment><USER26> My theory about the book, and the reason why there's such a tone change at the end is that this book is the kickoff to a much larger cycle.

If it is, I think there's an authorial question -- when do you shift gears to the far future, and how? It makes some sense to me that readers might find the style transition jarring between volumes. Also, some of the cool stuff starts to happen later.

So, perhaps -- hopefully -- we can look forward to more. There's plenty teed up in the novel; it seems like every group of humans that went out on their own survived in some way, (making me think the Mars folks are going to be around at some point), and we still haven't found out just who blew up the moon.

Stephenson created the Hieroglyph project, trying to get sci fi authors to inspire more science, and I suppose more faith in humanity. I would be surprised if we don't get more of this story aimed at inspiring us in a variety of ways.

<comment><USER27> > it seems like every group of humans that went out on their own survived in > some way

The survival of both the other two groups seemed pretty far fetched to me.

<comment><USER26> Just wait for Mars.. :)

I had the same reaction at first. But, then I was thinking about dogs; dogs evolve really quickly under pressure. If that's not a high pressure evolution event, I don't know what is.

I'm curious to read more about everyone in any event. Here's hoping.

<comment><USER28> SPOILERSSSSSSS

It's not even about evolution. Imagine if the 7 eves weren't playing some weird genetic metagame, but instead had one over-arching problem to solve.

The main dilemma of the Pingers was how to survive underwater, and they had as much technology (if not more, there's more submarines in existence than ISS modules). They also had tons of food (think of how many whales died, and how long whale fall ecosystems last). And a nice natural shield consisting of the ocean.

If the Aidans could bring back the Neanderthal, then the Pingers probably started their experiments early and often.

</comment></comment></comment></comment><comment><USER18> I _devoured_ Seveness. The first third of the book - the consideration of what I might do if faced with such a reality - was perhaps the most I've ever felt reading a book. (The contender for that would be Wise Man's Fear)

I find that question waaay more effective than "what would you do with a billion dollars?". Everything you know and love will be gone, completely, with the barest chance that you can contribute to _something_ surviving... But you have time enough left to love it. Or contribute to _something_ surviving.

It's pretty intense.

</comment><comment><USER29> boy-being meets girl-being beneath silvery moon, which then explodes for no adequately explored reason.

<comment><USER27> What do you mean? They thoroughly explained it -- it was an agent!

<comment><USER30> It's a reference to Hitchhiker's Guide to the Galaxy. (In particular, what the band Disaster Area's songs are about.)

</comment></comment></comment><comment><USER31> Some not-so-hard science fiction on the same topic: [https://www.youtube.com/watch?v=Csj7vMKy4EI](https://www.youtube.com/watch?v=Csj7vMKy4EI)

</comment><comment><USER32> 360° video interview at the parent link (also works with mobile phone VR headsets - though didn't try it) is surprisingly pleasant, effective and amusing too. For example, when they are in the car, it's nice to be able to look elsewhere if you already get bored staring at the two of them.

The director was a bit quirky I guess: there is even a play sword battle between two anonymous dudes on the side of the road, early on in the video (!)

Edit: Someone did already post about the above.

</comment><comment><USER33> >Seveneves belongs in the subgenre of hard science fiction, which means it emphasizes scientific accuracy. Everything adheres to physical laws, so unlike Star Wars, no one travels anywhere near the speed of light.

A pity then that a little basic chemistry eluded both the writer and the critic - there's no carbon on the moon. Rather difficult to support humans, and carry out feats of biotechnology, without it...

<comment><AUTHOR> What do you mean? In the book, the moon explodes and destroys the world. Pretty much the exact opposite of supporting humans.

<comment><USER33> My understanding is that the surviving humans shelter in "the cleft", which is a fragment of the moon. They then use biotechnology techniques to repopulate. Even when limited to the biotech operations, they would need a lot of carbon based materials.

Keith Robison has some thoughts on it:

[http://omicsomics.blogspot.co.nz/2015/12/thoughts-on- synthet...](http://omicsomics.blogspot.co.nz/2015/12/thoughts-on-synthetic- biology-of.html)

</comment></comment></comment><comment><USER34> The meeting seemed a little content-free, I wonder if there was some other discussion happening off-camera? Like, "I'll fund the movie version" or something. Or maybe Gates is really just like "Hey I liked your book, let's get hamburgers in VR".

</comment><comment><USER35> Definitely one of my favorite books. I bought a hard copy and read through it immediately. Then I got the audio book and listened to it in my car while commuting. What a great piece of work.

</comment><comment><USER36> The character identification bit is interesting. I had assumed the president was meant to be Hillary Clinton until I read someone angrily complaining about his take-down of Sarah Palin...

<comment><USER37> Well, the book was written in the age of Palin more than Clinton, so the parallel is inviting - but isn't JBF a pretty well read big city liberal, generally well respected in Doobs circles? It's a _very_ subtle dig.

However, I read JBF as a catch-all figure for everything bad about politicians (generally useless, except to ferment conflict to serve their own path to power), so it's not surprising that people would project whatever politician they don't like onto her.

In other words, she's _both_ Palin and Hillary.

<comment><USER24> When asked about the Hillary comparison at a book signing, Stephenson said that he hadn't wanted the character to represent Hillary and thought it was unfortunate that many readers would make that assumption just because there were so few alternative public figures to map the character to. He gave no hint as to there being anyone in particular she was supposed to be.

</comment></comment></comment><comment><USER38> Was anybody else turned off by the author's approach to characterisation in this book? I feel like he's over-explaining their reasoning/motivation for doing the things they do to the point where it's irritating. It's like he's trying to tell you everything about a character in the shortest time possible. No subtlety.

Am I overreacting? I'm still within the first third but I don't think I'll be able to get through the book if it's entirely like this.

<comment><USER39> Characterization is not one of Stephenson's strong points.

Try an experiment: skip to 2/3 through the book, where it says "Five thousand years later..." and pick it up as though it were a new book. I think you might be happier.

</comment></comment><comment><USER40> I enjoyed Seveneves but thought it wasn't Stephenson's best work by far.

I'd rate Anathem and Snow Crash much higher than it.

<comment><USER41> Same here, plus The Diamond Age. I read them all as they came out, and the shorter earlier books (The Big U, Snowcrash) had much more impact _on me_ than the longer later ones.

Or course, it's impossible to read Snowcrash today and feel anything like the same impact because ideas that were pretty far out way back then are commonplace today.

<comment><USER40> +1 on Diamond Age - awesome book.

</comment></comment></comment><comment><USER42> I enjoyed Seveneves. I'd recommend Luna: New Moon by Ian McDonald as another recent moon-based book that's enjoyable sci-if. Mega corporations rule the moon and the government largely ignores what they do as long as raw materials are still delivered to Earth.

</comment><comment><USER43> I started reading Seveneves about 4 days ago. Been sitting on my nightstand for months. It's dry, but scary/sad as fuck.

</comment><comment><USER44> I love how the book manages to tell just 1/3 of the whole story ;)

<comment><USER10> Actually, it's more like a quarter, or a fifth ;)

<comment><USER44> Hard to discuss without spoilers but do you mean story-time-wise or story- line-wise?

<comment><USER10> I mean story-line-wise. Specifically, group-wise.

<comment><USER44> Ah, so true! Thanks for reminding me.

</comment></comment></comment></comment></comment><comment><USER45>
        $('#ArticleDropUpshareHolder').remove()

<comment><USER46> Thanks, that's handy. I wish there was a complement to adblock that removed useless things that cover text, like email harvesting popups and other things that have to be closed manually.

<comment><USER45> The problem is that most of these things are hand-rolled. It's not like ads, where you can just block iframes that point at blacklisted domains. The ids and classes of those annoying things will be specific to each site, so it's hard to target.

You could probably remove anything that had onscroll functionality defined, and just accept that it would break some websites.

</comment></comment></comment><comment><USER47> I love that Mr. Gates drives a Tesla :)

</comment><comment><USER48> Talk about misleading titles.

</comment><comment><USER49> > I should get back to reading sci-fi again.

Tsk. Old enough to know that you read SF, watch sci-fi. Card, please.

</comment><comment><USER5> Dude! this is 880 pages long.</comment>