ffn

Agreed. One of the many things that makes Phoenix/Elixir great for us rails/ruby refugees is that it's built by other rails/ruby refugees. In many ways, we have all the good things that our old masters DHH trailblazed with rails, but at the same time, very little of the mess that also came with the trail-blazing.

That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.

This is awesome! I've been working with Phoenix for a bit now, and aside from the fact hex/phoenix doesn't yet have all the libraries that rubygems/rails have, Phoenix has blown my expectations out of the water. For such a big and complex framework, the entire functional plug system (functional is love, functional is life) makes the whole thing easy to grok in a way utterly unimaginable in a traditional rails framework.

By the way, in case core team is reading, what's the motivation behind removing infer_model_view from the render functions?

No, you can use phoenix without any javascript, it'll serve up regular html pages just fine. You only need the js if you plan on using sockets to connect to Phoenix's endpoints.

Why is this a bad thing designers must be "guilty of"? Most websites are built around providing some sort of commercial service / product, so the number 1 goal of design is to get out of the way of the user paying money and receiving service. If the design was radically different website to website for no other reason than artistic-special-snowflakia, then as a designer you're putting on extra cognitive load onto your users and forcing them to think about things that ultimately don't matter to either you or them.

Literally everything from cars (colorful sells with engine in front and some seats in the middle, brake is left of the accelerator) to desktops (mother board, 4 RAM slots, 1 CPU slot, USB slots, etc.) to stores (carts out front, role of checkout stands next, isle separated by content after) benefits tremendously from standardization, and are what makes modern life even remotely livable.

The same way you deal with getting older in any other profession, you learn to accept that there will always be people better, faster, and younger than you, embrace the fact that you suck, but still persevere in pushing forward at your own best pace. You strip away the pride (i.e. the feeling that you somehow deserve / need to win, to be the next big thing, to change the world, to be loved / respected by everyone, to do better than your old high school classmates, and to do it all in your teens and twenties) that covers the youthfully inexperienced. And you accept that the most you can do is put yourself on the path that you can enjoy and that you hope is right and commit to walking down it clad in nothing more than simple stupid faith that eventually you can get it to work.

Non-purple TL;DR: I deal with it by abandoning any sense of pride / shame I might've had.

>Erlang is not good for Glue-together style web application

Granted Elixir's Phoenix framework is not Rails level yet, it's system of plugs and heavy inspiration from rails actually makes it quite useable as a replacement for rails. Also immutability and the associated smaller memory footprint makes it more feasible to run cheaply on services like heroku or aws. Personally, I think elixir is a good boat to jump on to carry us over to the next world of web development.

Lying about your progress and metrics is extremely rampant in the startup world of SV... but IMO SV's biggest lie is that you need to be in SV and you need SV money to build a successful company. This flat out isn't true, especially if you're building a web service where your customers can be anywhere in the world and services / platforms that allow you to scale up incrementally exist. Most of what goes into building a startup is time-consuming trial-and-error grunt-work (e.g. reading documentation, editing boiler-plate code, answering emails / phone) that can be done much more cheaply and less stressful-ly from your mom's basement than hemorrhaging $10k to $100k / month in a downtown SF office while the scaffold of a 4 month deadline looms ominously before you. (There's a case to be made for the value of mentorship, but that value is always multiplicative and never additive - as in, if you don't have a business, your value of 0 is still 0 after multiplying it by the value of your mentor. So for mentors, the later the better.)

SV's second biggest lie is that you need the so-called "hockey-stick" growth curve to be competitive in order to be successful. This lie is clever because you're so caught on hockey-stick that you forget to question the premise of competitive. In the beginning of founding your startup, knowing about your competition might help you build your own product, but worrying about your competition is worthless because the world is more than big enough for the both of you (especially considering you don't exist yet). And if you don't have overhead (i.e. you didn't take SV money and hire a ton of SV's cleverest and most paid engineers), the world will always be biggest enough for you to survive.

SV's third biggest lie is coffee can replace sleep. That's not true, and one of your organs (usually your liver, but I've heard stories of kidneys, lymph nodes, beards, and even ovaries) will let you know after a bit.

Thanks for writing it out, but you've actually illustrated exactly my complaint. When you call oldMethod console.warn will spit out the line number of the wherever in your framework you have the

    var deprecated = function(fn) {
       console.warn("Deprecated!");
       fn.apply(this, arguments);
    };

declared... but you (as the user of a framework) still have no real idea where the actual function you shouldn't be calling (the fn) lives in your code (especially since the function can be anonymous)... you just know that the framework is telling you you're using a deprecated function somewhere in the code you wrote.

What I really want, and what can't be achieved with your purely in-language solution (and it really is a great solution considering the constraints), is a special form for things like @deprecated such that it straight-up can capture not only the function it's decorating, but also meta-data about the function (e.g. where it's declared, the caller / callee, etc.)

Not gonna lie, classes, destructing, TCO, and all these "engineering optimizations" are great... but what JS really, really, really needs is some sort of way to declare decorator macros. A great use case for these macros (especially in the browser) is in dealing with those god-awful deprecation warnings any given big-enough framework will eventually start spitting out after enough usage.

Right now, framework developers use console.warn which, as a function, is usually buried in the framework, and so gives stack-traces that are entirely useless to a developer using said framework (especially if the framework wraps console.warn in some way). A good clean way of declaring macros will allow JS frameworks to not be cancerous to maintain by making the stack-trace for deprecated user-code very easy to spot and correct.

And unlike features such as classes, generators, symbols, and even TCO that are reasonably achievable through clever engineering, macros flat-out have to be special-formed in. But their utility in making JS a much more maintainer-friendly language would go a long way to reducing the misery of us plebeian js users.

It's actually kind of amazing, the modern day media has lifted shamelessly the exact attitude of intolerance and hostility that used to be targeted strictly at people of color in the 60s, and now are targeting people of opinions today. Armed with their vocabulary of loaded words like "troll", "racist", "sexist", and "shitlord", they just as readily label, harass, and even destroy people (i.e. wreck their careers, get them fired, etc.) as those crazy mobs half a century ago in the south. There's no consideration for context, individuality, intention, or circumstance; you recognize a woman is different from a man = you're a sexist. You question diversity = you're a troll. You bring up crime statistics = you're a racist.

And the hilarious thing is, the "trolls" didn't even "win". Reddit's new CEO is implementing even stricter censorship measures, all of it most likely in the hopes of making reddit more appealing for advertisers. If you stand back and look at this whole fiasco from a distance, Reddit higher-ups want to make more money, and in order to do so, they decide they need to curb their more "unsightly" elements. But attacking free speech is a dicey proposition, so what do they do? They hire a woman and make her do it. If redditors are dumb sheep and take it quietly, great. If not, wrap the whole thing around her neck and throw her under the bus (reminds you of the Bourne Trilogy deson't it), then come riding in on a white horse to "save" reddit from "chairman Pao".

And so far, it's working perfectly. The "trolls" celebrate their victory by having the sensationalist media blast them on their sexism, Pao's reputation is utterly destroyed and she's essentially too toxic to employ anywhere, and Reddit still gets to wipe the floor with free speech.

At The Mountain View of Madness

Cool Airbnb

The Tweet of Cthulhu

We're supposedly starting to do this in LA, in particular, there is a lot of talk about tearing up the LA river so that whatever rain water we get can be restored to ground water.

>How slow is too slow?

That depends entirely on your financial structure, your product, and your own lifespan. If you never on-board investors and never depend on a loss-leader strategy for capturing market, you can small-business yourself from you mid-twenties to retirement and beyond. A lot of trade professions do exactly this sort of slow expansion; my neighbors is self-employed plumber and he's been routing tubs for the past two decades.

I usually believe emphasis on diversity is a bunch of PC shit that distracts from the core tenants of building a good business (i.e. shipping a product, having ethics, making sustainable profit, etc.), but you really should hire women. That is, you should have a balance of sexes on the team (so I guess hire men if you're in a predominately women field). This is because we're human and one of the most engaging things we can do is interact with the opposite sex.

Rather than having to spend money on extremely bs team-building exercises to get your employees to not hate coming to work, just hire a team of balanced sexes. A bit of flirting, imagined sexual tension, and does-she-like-me-what-do-i-feel-about-him goes a long way to creating an atmosphere where employees don't burn out. (Just make sure to hire non-toxic people and avoid the all-guys-are-rapists / all-girls-are-sluts ideological extremists)

Historically, didn't we use things like hippo fat and secretions of various flowering plants to ward off the mosquito? I wonder how those things compare with this mutant bacteria approach.

Love the language, I've been using it (phoenix) to build a more real-time version of my current rails app. But I have a concern with Elixir core's Enum. In particular, the Enumerable protocol has us implementing Enum.reduce for our own data-types, but Enum.map is written as

`reduce(collection, [], R.map(fun)) |> :lists.reverse`

is there any chance Elixir's enum core can take a page from Clojure's transducer idea and, instead of implementing map with reduce and [], implement it with transduce and some function that steps?

I've often had the need to map and filter over strings to achieve rails-like features such as #to_url, #classify, #underscore, and #humanize... but being forced to either rewrite Enum functions for strings or constantly peppering in String.split("") and Enum.join("") feels really bad.

Tax, immigration/emigration, and will/inheritance reasons. For one thing, the government gives you a tax break if you marry; this was particularly useful because, in the old days, women didn't work so it made sense to not tax the man (who did work) because he was effectively making money for two (and possibly more if they had children). Similarly, getting married changes your defaults if you die intestate (that is, you didn't draw up a will giving all your money to some slap-up blond or something), then your spouse (as oppose to your next-in-line) gets your $$. As for the immigration reason, if you're an US citizen but your wife (or hubby) is another nationality, you can get him or her over here and move onto getting him/her a resident alien card much more easily than through other methods of immigration (presumably this is so that families can be together, which is nice).

If you don't care about any of that and love another person, place, thing, or idea, you can just announce you're married to him/her/it without recognition from the government and just sort of be together.

Speaking of this, just how did Elixir's Jose Valim (who I assume is Polish) wind up working at the Brazilian Plataformatec? Last I checked, Brazil is a quite a bit more than a stone's throw away from Poland, and I would imagine even the tele-commute must be hell much less the physical commute.

Well, good design is obvious once you know it. But before you know it, it's as opaque and obtuse as anything else. It's just that design has this strange property with us humans in that, when done right, it feels so natural and emergent to us to the point we automatically take it for granted the instant we "get it".

In the realm of modern-day web-design, most bad design is because the website was built before a lot of these good design principles and conventions were invented (e.g. responsive grids, tons of padding, flex-direction(column), etc.). Next followed by prideful "designers" who steadfastly refuse to use a design framework because the site they're building must be a special snowflake. Next followed by the missing-the-point-followers of RMS (that is, they're not following RMS for the free software philosophy) who plainly look down on CSS and design as something that is beneath them. Finally, I'll give you laziness.

I don't know how much truth there is to this, but from the point of view of the several hundred Chinese netizens I know, a lot of China's current international policy decisions are arising out of desperation. For the past couple of decades, China has experience about 10% growth to its economy per year which has led to a wealth gap that makes ours look small. While the tide was rising, I suppose the average Chinese citizen had hope that perhaps he too can make it big... but with Xi's crack down on corruption (which, for good or evil, was just how business had worked in China), the economy slowed down considerably.

With that slow-down, the feeling of hope that the young unmarried men of China depended on to buoy up their spirits (it needed buoying up because there is tremendous societal pressure for them to find a good wife, but they outnumber girls their age by as many as 17 to 1 in certain cities) just vanished, leaving in its place restlessness and frustration. And if you get a bunch of young, restless, and frustrated men together, you have the historically tried and true recipe for destruction. I guess China's leadership, fearing for government stability, is looking to turn that sentiment outward via war, rather than take it inward via civil disobedience / revolution.

I, for one, am glad Ember is still going strong. And, as a heavy emberjs user, most of these changes feel like a step in the right direction. But after reading through the change log blog, I have several questions (not complaints) for the core team (in case Dale / Katz and cronies are reading this):

1. What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has that feature been scrapped / moved into a separate project altogether?

2. There was no mention of the deprecating changes to the initializer API (i.e. the splitting into instanceInitializer and vanilla initializer). Have we gone back to the old initializer API in 2.0?

3. With the removal of action bubbling, do we now have to manually bubble up actions that start in some nested controller but gets handled in application route? For example, say you have an AdminUserController and it has an action that generates an ephemeral flash message, but you handle flash rendering in your application route. Do you now have to laboriously put an actions: { handleFlash { ... } } on every route along the way?

Surprisingly enough, China still has a huge number of (as they put it) "left-over" women. This is likely because the population of there is well aware of the 60M+ fact going in their favor and, in truly amazing display of classical economics, heightened the standards and criterion the average girl uses to look for a man. The result (aside from the large majority who are one-to-one dating/engaged/married like it's always been) is that there are a ton of frustrated young men who (unless a miracle occurs) will remaining single until he dies, a small population of ultra-successful men who concurrently juggle multiple girlfriends (and possibly wives), and a large group girls who are annoyed that all the "good" men are taken.

Unfortunately, sex crimes have been on the rise in China.

So... top management at reddit literally allows loud and vocal groups to deny even the right to exist for other groups whose opinions they don't agree with. I don't condone hating on fat people (or any group of people), but all these fat-haters were doing was expressing their own opinions amongst themselves on a containment sub. And if top execs at reddit can express their hostility for a certain group of people (in this case fat-haters) by straight-up kicking them out for intolerance or harassment, I don't see how they're any more tolerant or less harassing than the very people they just banned.

Anything that's not a bad github profile would be a good profile. Ideally, I would want someone who has done a lot of open source pull requests, or has some interesting projects, or has contributed to some big-name existing project. But even if you don't have that, a profile showing you actively work on programming as a hobby / for fun is a great way to say something about your interest in this career.

On the other hand, I've hardly ever come across a profile that felt truly "bad" to me. The one exception would be that one guy whose history of pull requests is filled political-correctness-fueled changes to comments and function names.

If backend programming was epic fiction, then right now, the world is divided into the following countries: The Kingdom of Java, The United Languages of .Net, and the Confederacy of the Scripting Tongue (where racial tensions are crackle under the temporary truce between Ruby, Python, Javascript, Lua, etc.). For the past decade, these three kingdoms constantly struggled against each other for the most precious resource of all: developer mind-share.

But what they didn't know and couldn't prevent, was that their world would soon become (neigh, has already become) the battle ground of 3 ultra-advanced warring alien species: Go, Rust, and Elixir. Backed by unimaginably powerful forces (except Elixir, which is just open-source by Poland's own Jose Valim), the upstart alien languages threaten to herald in a terrifying future for the current 3 powerhouses.

OP's article, and the fact that lots of people are agreeing, is a sign that one of the invading aliens is weakening.

I don't know about you, but in the field of selecting new frameworks I tend to essentially just (mindless) follow celebrities. Some people call me a sheep, but so far, I've found following wycats (rails, emberjs) and his cronies around has paid off tremendously in terms of framework stability for frontend javascript.

On the other hand, the worst way to go about selecting a framework is, in my opinion, benchmark testing (or looking at some blogger's benchmark tests). Your framework might run a million hello world programs faster than mine as of last month, but you have no idea if the people working on the framework will even be around in the next 6 months when your MVP is actually complete. And if you wind up having to solo-support your own dead framework while concurrently trying to run a small business, good luck finding time to build new features, hiring qualified programmers, and not coming around to hate javascript.

>If one prefers A over B when comparing just A and B, then one should also prefer A over B when an additional option C is offered

That assumption seems fishy to me if in a real life application, in particular because we assume offering new choices can't fundamentally change the agent/voter's preferences isn't exactly true to life. I'll give a real life, but slightly historically oversimplified example:

Say I am a poor serf living in pre-revolution Russia about a century ago. I am usually offered the following two choices:

A. serve the bourgeois royal family and live off of their scraps

B. die like a dog

Then, one day, Lenin (or similar revolutionary) comes along and offers me:

C. fight for glorious USSR communism

In real life, I would think the offered choice of C would absolutely change my preferences for A and B.

Granted this doesn't invalidate the Arrow paradox in any way, I'm just saying the paradox isn't true to life because one of its core tenants doesn't quite hold.

I agree that it's fun to imagine, but the realities of longevity is probably a lot more prosaic. Granted Jeanna Clement can spoke for 100 years and be fine, but that doesn't mean the rest of us won't get lung cancer 10 years in if we try it. So, at present, the real secret to longevity is either superior genes (which isn't mass distributable except over a great many generations, and even then, it means giving up a portion of our genetic diversity on a societal level), disciplined lifestyles (30% less caloric intake according to the article, which means you can kiss your gains and muscular physique good-bye), and some very tricky and expensive combination of advance medicine (which, in a world where there are people who still starve to death, seems rather out of reach). In addition, you have to avoid all accidents, which is entirely out of your hands.

In a lot of ways, the concern over mass longevity squeezing the world to death is like the concern over AI robots who become intelligent enough to eradicate all of humanity or the gays mass-releasing gay gay-marriage-spores that make all the straight people fall out of love. It's fun to speculate, write country songs about, and produce post-apocalyptic movies around, but being seriously worried about it as a social issue is a little unrealistic.

Holy shit, tip number 5, "Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free.", is so absolutely true here in the world of software development (replace characters with features / bugs). They never taught me this in school, but from real life experience the best bugs / fix / solution you can come up with when you're trying to solve the problem is almost always inferior to the one you just sort of stumble across in the wild much later on.

Hey OP, have you tried the other "future" languages like go or Elixir? If so, how does it compare with your experiences in rust?