Ligatures in Programming Fonts: Hell No - <AUTHOR> https://practicaltypography.com/ligatures-in-programming-fonts-hell-no.html <comment> jake-low Used judiciously, ligatures can help make code more readable, not less. Consider JavaScript's == and ===, and their inverses != and !==. I personally find them difficult to visually distinguish on occasion (especially the negative forms). Fira Code [0] replaces them with two-bar and three-bar equals signs (something like =, ≠, ≡, and ≢, only wider; see the link for a screenshot). I personally find these easier to distinguish from one another at a glance. I'm sure it's not for everyone, but in my opinion at least these ligatures improve readability.

I'm generally a fan of Practical Typography, but this post is unnecessarily condescending. It's sort of laughable to claim that "this isn't a matter of taste" when users are making this choice in the privacy of their own editors.

[0]: [https://github.com/tonsky/FiraCode](https://github.com/tonsky/FiraCode)

<comment><USER2> I'd argue the inverse.

In my experience removing the gaps makes some symbols harder to read. Like distinguishing `==` and `===` without gaps is harder, though admittedly three- bar helps. Also, I find the ligatures I've tried a bit of an eye-sore, but that's just personal taste.

What's a more serious concern is the "dumbness" mentioned in the article and the handling of ambiguous cases. To give my own example, in addition to those in the article, I use a series of more than 3 equals signs as a delimiter in my notes. With programming ligatures it looks distractingly bad. Normally it's a continuous row of two-bars, but with them ligatured they look like morse code divided into short groups of long two-bars. Essentially, when I'm writing code or whatever, I don't want there to be someone guessing what I mean and how I want something to look. Unless he guesses always right, he's a nuisance. Sorry for the personification.

<comment><USER3> Well it is a matter of personal taste, isn't it? For me it is just the opposite, the visual appearance of the ligatures burned itself itnto my brain in away that it is easier to spot when it is not there. Sometimes something not converting to a ligature can also be a hint (e.g. for a wrong hyphen beeing used etc)

<comment><USER4> > Sometimes something not converting to a ligature can also be a hint (e.g. > for a wrong hyphen beeing used etc)

So what languages actually benefit from this? haskell, clojure but maybe not the usual C family ones?

<comment><USER3> No idea, I use rust and python with it.

</comment></comment></comment></comment></comment><comment><USER5> Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this:

> When we're using a serifed text font in ordinary body text, we don't have > the same considerations. An fi ligature always means f followed by i. In > that case, ligature substitution that ignores context doesn't change the > meaning.

Maybe this is different in English typography - I'm a bit more proficient in German - but ligatures do have semantic meaning. At least in German, they should never cross a word boundary in composite words, for example Kaufleute (merchants) is Kauf-leute (buy-people), so you would not use a "fl" ligature. There are actually words where this resolves an ambiguity, I think. Historically, this is the reason sometimes ss and sometimes ß is used. I always assumed there were similar subtle rules in English.

As to the "ligatures" in programming fonts - I would not call them such, problem solved. Rather, they are substitutions in the tradition of APL or vim conceal mode - to get mathematical notation with a standard keyboard.

<comment><USER6> Perhaps, but the automatic ligature substitution doesn't know that, and indeed in Times "Kauflete" is rendered with a ligature. Probably because native English speakers aren't used to accent or ligature rules.

Anyway, I too agree with the author; if you want ≥ to appear on your screen, it should be in the source text as the UTF-8 bytes for U+2265 and the tooling should understand it. Programming is too fragile to allow misunderstandings between the bytes that are interpreted by the machine and the glyphs that the programmer understands to be inserted.

Going much further back, there are the C trigraphs '??!' etc, for those whose character sets don't contain '|'. I've not seen editors attempt to automatically show those as the substitute characters either.

(Oh, and if you want to be unpopular, try entering unicode characters in your language variable identifiers or git commit messages and see how much tooling you can break...)

<comment><USER7> Why would using non-ASCII characters (I assume that is what you mean by Unicode characters) in a git commit message break anything sensible? It's meant to be human readable text, and defaults to UTF-8 (although you can use legacy encodings if you really must).

Any git hook processing stuff would just look for stuff it does understand (like '([Cc]lose(s)?|[Ff]ix(es)?) #[0-9]+' or something similar) and ignore the rest.

Scores of developers use non-ASCII characters as part of their native language every day in git commit messages, and even non-BMP Unicode characters like emoji work just fine.

<comment><USER8> Well, I dunno if you consider GitHub branch names circa 2015 sensible...

</comment></comment></comment></comment><comment><USER9> > The problem is that ligature substitution is "dumb" in the sense that it > only considers whether certain characters appear in a certain order. It's > not aware of the semantic context.

At least in Sublime Text this is not true. We tokenize the text according to the rules in the syntax definition and then pass characters to be shaped, but respecting token boundaries.

In fact, we've fielded a number of bug reports about ligatures not working, and it is almost always that the syntax definition was tokenizing the = and the > as separate tokens.

We also made the decision to only pass runs of symbols to the text shaping engine, as opposed to runs of alphanumeric characters. This prevents ligatures like fl that are usually not useful in a monospace layout such as a text editor. There are also options to control the OpenType features for ligature fine tuning.

<comment><USER10> Came here to say this ST handles ligatures very sensibly

</comment></comment><comment><USER11> > If you don't believe me, try it for 10 or 15 years

nope, I still haven't ever run into the described issues. but that's not even why I disagree with the author. if I _did_ run into an issue, it absolutely wouldn't be the font's problem. this is akin to blaming a crypto algorithm for a security flaw caused by a bad implementation. fonts are software and IDEs can simply provide an option to disable ligatures. and, often, they do:

in sublime: [https://www.sublimetext.com/docs/3/ligatures.html](https://www.sublimetext.com/docs/3/ligatures.html)

in vscode: [https://github.com/tonsky/FiraCode/wiki/VS-Code- Instructions](https://github.com/tonsky/FiraCode/wiki/VS-Code-Instructions)

in atom: use CSS

<comment><USER12> > fonts are software and IDEs can simply disable ligatures.

Yeah but the author is suggesting that using a particular font will increase the likelihood of a programmer introducing some syntactically correct but erroneous code. But then he doesn't actually give any examples. So I don't buy it either. Maybe certain languages are more susceptible?

</comment></comment><comment><USER13> The article would have been a lot better if there was at least one example of where a coding ligature was a problem, rather than talking about feet and inches

For instance it mentions the pairing => but provides no examples.

After reading I'm far from convinced that carefully curated language specific ligatures are a bad idea.

<comment><USER14> Here's an example: [https://github.com/tonsky/FiraCode/issues/751](https://github.com/tonsky/FiraCode/issues/751)

<comment><USER15> That's why e.g. Iosevka has language-specific ligations so you can chose between the standard, the slightly extended ML ligatures and the whole set of Coq craziness.

</comment></comment></comment><comment><USER16> > So what's the problem with programming ligatures? // They contradict > Unicode.

The Unicode ligatures in the Alphabetic Presentation Forms block (U+0FB00 - U+0FB4F) are only present for compatibility purposes, so that legacy texts in encodings which contain precomposed ligatures can be losslessly reencoded to/from Unicode. They aren't meant to represent the entirety of all ligatures.

<comment><USER17> Also, the author's follow on implication that Unicode only encodes one version of something that visibly looks the same is also false. It's exactly why we have things like punycode in browser URL bars, and even various "normalization standards" to compare multiple means of encoding similar characters.

Not to mention entire languages that build structure as complex combining sequences, including emoji and its complex ligatures combining the Zero Width Joiner and multiple emoji into single result emoji.

</comment></comment><comment><USER18> >Bottom line: this isn't a matter of taste.

It is, quite unequivocally, a matter of taste. Please don't pass your personal, unsubstantiated opinions as a matter of fact. :-)

<comment><USER19> 100% agree. No editor comes with such font used as default. If a user wants to add fancy ligatures, she has to set it up by herself. It is very unlikely for such person to forget she is using ligatures in the middle of coding. Also, text editors put the caret to a proper position if the selected text breaks a ligature in the middle.

I personally see no problem using Fira Code aside from 10 seconds long brain hiccups every once in while (once per year, maybe rarer). I've been using it since 2015, on multiple editors including Xcode, Android Studio, iTerm2, Sublime Text, Atom, VS Mac, VS Code and IntelliJ. I can't even remember which one of these still doesn't support the proper rendering of ligatures, and yet no issues for me so far.

</comment></comment><comment><USER20> Setting aside the article for one second, I just want to mention that the author is a hell of a font designer, and his Triplicate Code is my favorite programming font at the moment [0]. It has all the styles you would want (light strokes, heavy strokes, bold, italic, ...) as well as lovely serifs. Most serif programming fonts are slab serifs, but not Triplicate. These ones are lovely and light things. It's a real pleasure to work in. Well worth the cost if you care about such things.

[0]: [https://practicaltypography.com/triplicate.html](https://practicaltypography.com/triplicate.html)

</comment><comment><USER21> Fira Code's main problem is that it tries to be a font for all programming languages which results in some weird behaviours here and there. Unfortunately, there's no good way to have a font have sets of ligatures per <whatever you're working with right now>.

That said, however, the article fails to provide a compelling argument against ligatures.

1\. Fonts have nothing to do with Unicode. It's exactly the font's job to provide any glyphs or ligatures it wants on top of provided characters.

2\. Programming languages have been long stuck in ASCII-land trying to emulate symbols commonly used in other areas such as mathematics: -> and => _are_ arrows, == and === _are_ equality and congruence, >= and =< _are_ greater than/less than or equal to, and the list goes on. These will never be easy to type in their original form (unless you have APL's custom keyboard), so why not present them as such?

3\. Computers have all but destroyed typography, and it's a good thing some of it is coming back. Properly spaced numbers? Properly spaced and aligned punctuation? Contextually correct punctuation? Yes, please, more!

So, what's the beef with ligatures? I don't know :) And yes, I've been using Fira Code for several years now.

Ironically, the article says "well-intentioned amateur ligaturists are adding dozens of new & strange ligatures." and uses what appears a "° DEGREE SIGN U+00B0" that looks like a link to a footnote to denote external links.

 _Edit_ : minor corrections to readability

<comment><USER15> > Unfortunately, there's no good way to have a font have sets of ligatures per > <whatever you're working with right now>.

But there is, see Iosevkas ligature sets which switch different ligatures on and off. The editor can just opt-in which one to use.

There might not be sufficient editor support for it but you can work around it by generating different versions of it as default and then configure your editor to use that font. Not elegant but workable.

<comment><USER21> That's what I meant when I wrote that sentence: either the font doesn't have those sets, or the editors can't enable them, or there's no easy way to support different fonts for different languages, or...

It's not limited to just programming. Font fallbacks for multi-language texts (for example, English and Russian; that is, Latin and Cyrillic) in most (all?) mediums are usually horrible, and usually revert to whatever the OS provides.

</comment></comment></comment><comment><USER22> I've been using fonts w/ ligatures in my IDEs for many years now with many different languages. Not a single issue, ever.

I do get the point that author is making here, but it's only important for these kinds of discussions in a vacuum, detached from reality, as self- important typography and design blogs usually are.

</comment><comment><USER23> Fonts like Fira Code are attractive for the same reason animated cursors are attractive - they give people a way to add fun little baubles to their working environment. No, they don't benefit your productivity and in many cases make it worse (e.g. confusing ligatures or buggy editor plugins) but decorations are by definition not of utility.

<comment><USER24> Decorations can't add utility? Does color-coding (tools|parts|areas) count?

</comment></comment><comment><USER25> If anybody wants an example of where ligatures will cause problems, try playing a roguelike in a console using the Fira Code font with ligatures turned on. It demonstrates that accidental collisions end up with completely different glyphs. My first experience with this was with Dwarf Fortress in text mode.

But... I have to say that this is the only place I've actually come across it. I eventually decided that I don't like ligatures, personally, in my source code. However, the chance of problems occurring is pretty remote.

<comment><USER26> > try playing a roguelike in a console using the Fira Code font with ligatures > turned on

But... why? It's obviously not intended for that purpose. You would get awkward results trying to program with a regular serif, too, but that's not a fault of the entire category of serifs.

</comment></comment><comment><USER27> Why do folks that don't want to use them even care?

It's not that when they are used, different code is produced. As with the editors color scheme, it's just a personal choice everyone can live out within the privacy of his or her editor.

Personally I find it nice to represent single logical tokens like => or === with just a single character.

<comment><USER28> I'm on your side with ligatures. Pry them from my cold dead hands. But given that the author is a font designer he probably has had many heated discussions on the matter and that's probably why he cares so much.

</comment></comment><comment><USER29> Ligatures work well enough when selected properly for the target language, since the often substitute for what the language designer was using ASCII art to approximate.

Still, Perl 6 I think has the better solution: use Unicode well with ASCII fallbacks. Combine it with editor language modes that are aware of the equivalents and do Unicode substitution when the ASCII combo is used, and you get a situation all-around better than ligatures.

</comment><comment><USER30> I'm unconvinced, because as far as I'm concerned ligatures are a viewing enhancement and have nothing to do with writing the code. Maybe there are (extreme) edge cases where I might accidentally confuse a Unicode code point with a ligature, but since those symbols are (relatively) difficult to access on most keyboards to begin with, I don't think any practical difficulty would ever present itself.

I've often thought that smarter IDEs should be able to recognize the language and display code in the user's preferred style with better use of screen space. For instance, a Java class could be displayed with the class signature in a fixed header; enclosed methods could be displayed starting at the left, instead of indented; stacks of annotations could be replaced by a gutter icon with a hover/click to show/expand/close; methods could be grouped and ordered by particular criteria; etc., all while the underlying source file remains intact.

</comment><comment><USER26> I've been using Fira Code pretty much since its inception, currently trying out Hasklig.

I never want a programming font without ligatures ever again.

This article, to me, seems like a case where the authors' ire is proportional to a) their understanding of the subject b) how relevant the topic is.

Because really, a) ligatures won't cause catastrophic failures by rendering code illegible and b) it really, really doesn't matter all that much. Non- destructive personal preference.

</comment><comment><USER31> It also makes the lives of terminal emulator developers much more difficult. Won't someone think of the terminal emulator developers?

<comment><USER32> Luckly on many OS the terminal is just yet another graphical application, not something trying to emulate 40 years old hardware.

<comment><USER33> (You're talking to the developer of iTerm2, which is a graphical application. iTerm2 took a while to support ligatures: [https://gitlab.com/gnachman/iterm2/issues/3568](https://gitlab.com/gnachman/iterm2/issues/3568))

<comment><USER32> The nick was unknown to me.

From the ticket it seems to me that the root cause was not handling text as GUI applications are supposed to do(aka like Wordprocessors).

</comment></comment></comment></comment><comment><USER34> I wouldn't use these fonts in documentation or on a blog. But I love them in my editor, where only I need to understand the difference between the literal characters and those tasty ligatures.

</comment><comment><USER35> I've never used ligatures like this, and I have no horse in this race, but I don't find these arguments compelling.

1\. By this reasoning, Unicode contradicts itself. There's lots of codepoints that I can't visually distinguish from one another, even when printed without ligatures. If the quality of visual uniqueness is important, better stick to printable ASCII.

2\. Every syntax-highlighter I've ever used, for any language more complex than a Lisp, has been wrong, occasionally. Every IDE "find text" feature finds useless results, occasionally, from lack of context, too. Again, if perfection is your threshold for use, you're going to have to throw out half your editor.

If you want to go all Marie Kondo on your toolchain (like Chuck Moore has been doing for decades), that's neat, but that doesn't sound like what he's advocating here.

> If you don't believe me, try it for 10 or 15 years.

Every time a programmer tells me this, and I ask around, I find that the population is split. Seriously, you don't believe me that emacs is 1000 times better than vi? Try it for a few years.

</comment><comment><USER36> Is <= equivalent to ⇐ or ≤ ?

Personally, I'd love a keyboard that had a ≤ key and a programming language that recognized that symbol.

<comment><USER37> In Perl6 <= is equivalent to ≤

        say 4 ≤ 5; # True
        say 4 ≤ 4; # True
        say 4 ≤ 3; # False

        say 4 <= 5; # True
        say 4 <= 4; # True
        say 4 <= 3; # False

Specifically they are the exact same subroutine. (The normal operators are just subroutines with a special name.)

        say &infix:« ≤ »  =:=  &infix:« <= »; # True

(The =:= operator is basically the same as pointer equivalence.)

The line which creates this equivalence is the following:

        my constant &infix:<≤> := &infix:«<=»;

[https://github.com/rakudo/rakudo/blob/b0dd44b006dc44da5695b2...](https://github.com/rakudo/rakudo/blob/b0dd44b006dc44da5695b28c53be52a5772f08a4/src/core/Numeric.pm6#L320)

</comment></comment><comment><USER38> I use Fira Code constantly and consistently, with punctuation-rich language (Scala); haven't found any practical problems yet. Theoretically, there can be inconsistencies; practically, it doesn't happen.

If it is consistency and perfection everywhere you are looking to find, software engineering in general might not be the best job for you.

</comment><comment><USER39> I usually agree with the author, but not really here.

> They contradict Unicode

So what?

The ligatures are only supposed to look good in my editor, with my config, in the programming language I use and for my eyes only. Nothing else matters.

> They're guaranteed to be wrong sometimes

See previous point.

As long as it's good enough for my purposes in the context I use the font, it doesn't matter if it breaks some edge case that makes the author upset.

> Bottom line: this isn't a matter of taste.

It is a matter of context, which the author completely misses.

And yes, it's also a matter of taste. Everything design related is in parts taste.

</comment><comment><USER40> Once I got used to the look of the 0, I started to love Hack: [https://sourcefoundry.org/hack/](https://sourcefoundry.org/hack/)

Ligatures always confused me...

</comment><comment><USER41> I love my ligatures in Hasklig. Can't imagine my lambda arrows or equality comparisons without them

</comment><comment><USER42> I thought programming fonts are typically monospaced, which means collisions (which create the need for ligatures) aren't much of an issue. I agree that ligatures aren't good in programming, but it just seems the need wouldn't be that great. Or am I missing something?

<comment><USER43> Ligatures in programming fonts usually don't want to solve the problem of character collisions. Instead they transform rather weird symbol sequences used in programing to something closer to symbols used in maths or how you would write it by hand, e.g. != becomes ≠, =< becomes ≤, or === becomes ≡. More examples are in the repo readme: [https://github.com/tonsky/FiraCode](https://github.com/tonsky/FiraCode)

<comment><USER42> Ah, gotcha. Based on the examples given (e.g., Th), I got the sense he was talking about letters.

</comment></comment></comment><comment><USER44> I see font ligatures in the same light as tab characters. They are configurable in the editor and don't affect the source code, but enhance visual clarity while not forcing programming languages to now have to support custom operators such as "≥".

</comment><comment><USER45> I've always hated ligatures in general and consequently all webfonts, google fonts, etc are purged from my web browsing. But they also have no place in a monospaced font when two characters combine.

</comment><comment><USER46> Previously: [https://news.ycombinator.com/item?id=14830797](https://news.ycombinator.com/item?id=14830797)

</comment><comment><USER47> I love them. I even use Fira Code on the terminal. It's a matter of personal preference IMHO.

</comment><comment> rich-tea I suppose Adobe want to draw attention to ligatures because they want to draw attention to the fact that their software supports them. That "Th" ligature is pretty bad.</comment>


How ZIP codes nearly masked the lead problem in Flint - <AUTHOR> https://theconversation.com/how-zip-codes-nearly-masked-the-lead-problem-in-flint-65626 <comment><USER2> "But unlike postal codes in other countries which represent small areas suitable for in-depth geographic inquiry (Google "N6C 2B5" for a Canadian example), ZIP codes are woefully unqualified as units of analysis."

First of all, don't Canadian zip codes have the exact same limitation? Postal codes in general are designed for _the convenience of mail delivery_ and nothing else. (For that matter, mailing address often misidentifies the actual city of residence if one lives near a boundary and _always_ states a phony city if one is in unincorporated territory.)

There are two methods I can think of immediately to drill down into better detail. For one, zip codes are _nine_ digits now, and using all nine digits (Zip+4) yields extremely narrow detail (generally no larger than the destination's building; often, homes have their _own_ Zip+4. But that still leaves the problem of matching address to political boundary.

For _that_ , there are many datasets that match street address to the underlying _parcel_ , and knowing the parcel provides you with actual city (if in incorporated territory), state political district(s), city political district, Congressional district, etc. It's used by mailhouses for sending political mailers to the correct jurisdiction all the time.

<comment><AUTHOR> I don't know what the Canadian system is, but the example points to it being street/block level:

[https://www.google.com/search?num=20&q=postal+code+N6C+2B5](https://www.google.com/search?num=20&q=postal+code+N6C+2B5)

As far as I understand zip+4 is for a given sorting route, so it won't necessarily have nice spatial properties. The USPS anyway considers zip codes to be collections of addresses, so it's sketchy to use them as areas.

The problem with the parcel data sets is getting access to them in a coherent format without spending money. I actually came across this link on a the twitter feed of someone behind Openaddresses ([https://openaddresses.io/](https://openaddresses.io/) ). They often get addresses from parcel data, [https://usopendata.org/2016/06/07/parcels/](https://usopendata.org/2016/06/07/parcels/) but don't restrict themselves to it.</comment></comment>


Don't Do Multipart Requests on AWS Lambda - <AUTHOR> https://www.reddit.com/r/serverless/comments/a0nsin/dont_do_multipart_requests_on_aws_lambda/ <comment><USER2> Maybe we should instead link to the original post on medium at [https://medium.com/trust-bob-blog/serverless-quick- tip-1-don...](https://medium.com/trust-bob-blog/serverless-quick-tip-1-dont- do-multipart-requests-on-aws-lambda-ccc4709c28d3) ?

<comment><AUTHOR> Uh yeah, would've probably been wiser.</comment></comment>


Tell the Senate: Do Not Shut Down Debate on Mass Surveillance - <AUTHOR> https://act.eff.org/action/tell-the-senate-do-not-shut-down-debate-on-mass-surveillance <comment><USER2> I hate that they need a street.

Let me put in my zipcode and just pick the one that was on the ballot from the list. For US SENATORS it's even going to be a 50% chance per state.

<comment><USER3> From their "why," some Congressmembers require a full 9 digit zip code to submit forms.

</comment></comment><comment><USER4> Does this have any support on the corporate level? E.g, companies like Mozilla?

<comment> java-man Why would they (not only Mozilla) support this?

<comment><USER5> Some of them have privacy as a core part of their marketing strategy.</comment></comment></comment>


Suspended by Twitter for tweeting feminist academic research - <AUTHOR> https://civic.mit.edu/2018/09/29/twitter-suspended-me-for-tweeting-feminist-academic-research-heres-why-thats-a-problem/ <comment><USER2> The title, even if faithful to the original, is misleading. As the post states, he doesn't know and it is not clear why. He does take the liberty of guessing:

> I can also see how my tweet might have triggered a very, very naive rule > that saw "gender," "STEM," and "natural" in close proximity, or interpreted > the text on the screenshot (which now shows up as a grey box) as denigrating > women as a class, when the substance of the message was doing the opposite.

> any system that (apparently) flags feminist academic research about the > social construction of scientific privilege as being abusive of women as a > class

An interesting guess. However, the text on the screenshot contains facts. That the author feels the need to specify the facts are "doing the opposite [of denigrating women as a class]" as something of note, rather than just worry that facts are being policed, just smells bad. Were they the wrong facts, would it be ok to ban?

Furthermore, the ban has been lifted: [https://boingboing.net/2018/09/29/platform- censorship.html](https://boingboing.net/2018/09/29/platform-censorship.html)

</comment><comment><USER3> On a tangent here: The block quote in question is interesting and rightly highlights how strong gender imbalances in STEM might not have a historic/natural bias. However, I always think we are going down a dangerous road when we even argue this point. If we base our campaign for contemporary fairness and equal opportunity on the argument that in the past women have been important and respected contributors to science and tech, then we are making it contingent on this historical fact rather than, as it should be, an absolute right founded on the inherent equal rights of men and women.

<comment><AUTHOR> I think it's more an argument against the idea that they are incapable, if they were capable in the past then something must be argued to have changed in the essential nature of women since then.</comment></comment>


Give them an inch and they take $773 million - <AUTHOR> http://notes.unwieldy.net/post/50478689215/give-them-an-inch-and-they-take-773-074-040 <comment><USER2> In 2006, JetBlue removed an entire row of seats:

      JetBlue estimates a net savings of $30 million over five years by removing
      six seats from the A320 fleet, as a result of reducing the inflight crewmember
      team to three, and by reducing the weight of the aircraft by approximately 904
      pounds, which will lower the fuel burn. That figure includes lost revenue
      opportunities as a result of selling six fewer seats per A320 flight. The figure
      does not include any revenue improvement that may result from the enhanced
      JetBlue Experience.

[http://investor.jetblue.com/phoenix.zhtml?c=131045&p=iro...](http://investor.jetblue.com/phoenix.zhtml?c=131045&p=irol- newsArticle&ID=942110&highlight=)

<comment><USER3> coming next, Responsive Seating!

per-flight configurable seat modules, for exactly the number of people on board, and can be quickly loaded/unloaded to minimise excess weight. Installed seats adjust their clearance automatically based on available space and user's ticket price/options.

<comment><USER4> I can already see the logistics and engineering nightmare of a flight devoid of seats having to bump an entire group of passengers because the next leg doesn't have enough inventory.

Seats are fixed because bolts are easy. Once you get into the whole latches and levers business you compound your points of failure. Ever look under the last row of foldable seats in an SUV? A lot of engineering goes into securing 100kg bags of meat to an object hurtling along the ground at 80km/h. Now imagine having to do the same for a plane traveling 2-3x that.

<comment><USER5> Does speed really matter, though? I mean, the issue with cars is that they sometimes come to a very sudden stop, and in those situations the passengers need to be bolted to the ground. Planes don't often come to very sudden stops and when they do, bolts don't matter much.

The seats need to be secured, yes, but not in nearly the same fashion.

<comment><USER4> Yes. I would say even more so than cars. Even at its slowest a plane is traveling at 3x the speed of a car or 9x the kinetic energy. Then you have the problem of a compounding failure. If even one passenger gets lose the seat in front has to do 2x the work. A plane with 30-70 rows can have a domino effect if the bolts don't hold.

Also cars don't instantly stop. Most of the energy is dissipated by shedding the engine under the body and crumple zones. They have a dramatically shorter runway than planes.

</comment></comment></comment></comment></comment><comment><USER6> Not quite. The extra seats only provide additional revenue when the flights would have otherwise been full. From the article, the average flight is only 80% full, which means those six extra seats aren't providing any additional revenue.

To determine the actual revenue increase from those six extra seats, we would have to know how frequently flights have less than 6 empty seats.

<comment><AUTHOR> While these numbers will never be perfect, per se, RITA[1] shows that in 2011, Southwest's loadfactor was 80.8% while in 2012, loadfactor was 80.4%. So, the flights remained around 80% full on average.

I took this into account in my calculation and assumed roughly 4.8 more seats were filled on average per flight, not a full 6.

[1] <http://www.transtats.bts.gov/carriers.asp?pn=1>

<comment><USER7> I think the key question then is why it was that 4.8 more seats were filled on average per flight. If we had data the showed that the distribution of plane occupancy were the same year over year save for a few occasions where last year the plane had been at capacity but this year those extra 6 seats had been put to use then the conclusion could be valid. However with the data I've seen so far it seems spurious to conclude that the extra 4.8 filled seats were caused by the extra 6 physical seats.

<comment><USER8> Assume the pricing for seats is as follows:

$100 for first 50% of capacity

$120 for next 20%

$170 for next 20%

$300 for next 5%

$600 for final 5%

What is the revenue impact of expanding capacity? The solution is not obvious, but the author's approximation is more accuare than you suggest. You obviously can't solve this without a stochastic ticket demand model, but 4.8 is much closer to the right answer than 0.

<comment><USER9> Also if the airline wants to maintain an 80% capacity, having an extra x% of seats means they add to revenue if they can maintain that occupancy percentage. In this case we don't even need to factor in 100% occupancy, which if anything would help the numbers as I'm sure last seats on a fully booked flight aren't cheap.

<comment><USER10> They target around 100% full. That being said, having more seats allows them to adjust their pricing model so that they have more seats to attempt to maximize revenue.

Depending on the demand structure of routes, those 6 seats may have wildly different values and could potentially be worth more than the average ticket price, on average for the airline.

Since this is counter-intuitive, I'll explain why briefly:

Airlines attempt to price discriminate by selling low priced tickets to leisure travelers and high priced tickets to business customers.

The problem airlines face is that business travelers book at the last minute.

Since business travelers book at the last minute, they need to estimate the number of business travelers who will be flying.

If the average leisure passenger ticket sells for $100, and the average business ticket sells for $500, just having 1 extra seat can add 5 leisure tickets worth of revenue assuming they sell the same number of leisure tickets.

Realistically, their model will readjust the optimal pricing changes overtime to capture the most value. Because the additional seats give the model more flexibility, I would not be surprised if the additional seats added more than an average of 80% of 6 seats multiplied by the average ticket price.

</comment></comment></comment></comment></comment></comment><comment><USER11> In addition to the sketchy mathematical foundation, there's another reason to not draw too many conclusions from this observation: your company, product, and customers are probably quite unlike Southwest Airlines. For starters, airline customers care almost exclusively about price.

Joel Spolsky was wise to warn _against_ doing what this article suggests (<http://www.joelonsoftware.com/items/2007/09/11.html>):

        In one of Gerald Weinberg's books, probably The Secrets of Consulting,
        there's the apocryphal story of the giant multinational hamburger chain
        where some bright MBA figured out that eliminating just three sesame
        seeds from a sesame-seed bun would be completely unnoticeable by anyone
        yet would save the company $126,000 per year. So they do it, and time
        passes, and another bushy-tailed MBA comes along, and does another study,
        and concludes that removing another five sesame seeds wouldn't hurt
        either, and would save even more money, and so on and so forth, every
        year or two, the new management trainee looking for ways to save money
        proposes removing a sesame seed or two, until eventually, they're
        shipping hamburger buns with exactly three sesame seeds artfully arranged
        in a triangle, and nobody buys their hamburgers any more.

<comment><USER12> >> For starters, airline customers care almost exclusively about price.

I wish that wasn't the case. I'd gladly pay an extra £20 on an international flight for decent food, and I regularly do pay an extra £50 or so for more room or an exit row seat. I know there's a market of people like me, for whom business class is way to expensive just to make a few hours a bit more pleasant, but who aren't just counting every penny. The airlines seem to have started to cater for us with things like Delta's "Comfort Economy", but it needs to go further.

<comment><USER13> The trick for decent food on airlines is to specify a meal preference. I'm usually say I'm "Asian Vegetarian". On most flights I get a reasonable curry, or something a bit more interesting than the usual slop they hand out.

As a bonus, special meals are usually served first and in some cases are specially prepared.

As it happens, I am a vegetarian, so I don't "miss" the meat - YMMV.

<comment><USER12> I'm not going to miss airline meat, certainly!

Vege option may well be a good thing, will try that one in future.

</comment></comment></comment></comment><comment><USER14> >implying the flights stayed 80% full after new seats were added

>implying decreased customer satisfaction didn't hurt their revenue

>implying their systems didn't need to scale because of increased customers

>implying their R&D on smaller legroom didn't cost anything

>implying upgrading planes didn't cost anything

>implying more customers on planes didn't have an impact on maintenance costs

>implying revenue means anything when you don't know the profit margins

<comment><USER15> The prevailing theory among air carriers is that demand for flights is totally exogenous to the industry and allocation of flights between carriers in the industry is, for most customers (e.g. not frequent business travelers, who are price insensitive and care about mileage), dependent pretty much solely on price. Accordingly, minor decreases in comfort which add capacity are pretty much an auto-win.

Many people dislike this conclusion and dispute it's factual accuracy because they don't want to believe that they'll predictably increase their own agony to shave $5 off a ticket. But, well, non-experts opinion of their own behavior often does not have 1 to 1 correspondence with reality which is tractable to measurement with numbers.

<comment><USER16> For most customers, maybe, but I suspect there's a pretty sizable portion of the population (myself included) that will happily pay more for an airline that treats me extraordinarily well, considers my comfort while on board, and gives me reasons to shout their name down the street. For example, Virgin America is one of those airlines for me, and I will happily pay a premium to fly one of their tragically few routes (they're one of the few airlines I fly first on, as well). I blacklist Southwest entirely because of the complete disregard for my experience shown on the three miserable flights I've had with them. I don't think I fit in your business bucket, but that's a data point, at least.

In another industry where profit is the focus, domain registration, I'm absolutely _dying_ for a $100-$200/year registrar that knows what they're doing and isn't awful to deal with. I will happily pay that premium since my hosting bill far outweighs my domain registration, and handling support tickets expediently and providing features I want are far more important than the bottom line to me. If an extra $10/year from all customers means I get IPv6 glue or a ticket answered inside of 72 hours, _please_ , do it! (This is less relevant now, but was a concern for me in the past.) I'm willing to part cash to be treated better in almost all cases.

<comment><USER17> _For most customers, maybe, but I suspect there's a pretty sizable portion of the population_

Yup, and for those two things you mention that you are willing to pay more for, there are probably 98 other things you aren't. Each person will have the things they are willing to pay more for, and most will be different, so for most services, 98% of people are going to choose the cheaper option.

Hence most companies won't give a shit, and almost everyone has moments where they wonder why there isn't an option to pay more for higher quality of X product.

<comment><USER16> I wouldn't be so sure. I pay a rent premium for a view.

<comment><USER18> Yes, but presumably you looked at the apartment first.

Unless airline search sites start listing seat pitch, amenities, seat recline, in-flight entertainment quality, etc. next to the ticket price when selecting a fare, it's hard to see how these factors would play into a purchase decision.

Even if the data were there, I'm wagering that the lions share of customers would keep $20 in their pocket at the cost of some minor discomfort.

<comment><USER19> > Even if the data were there

Oh, but the data is there.

<http://www.bbc.co.uk/news/business-21227287>

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> If flights are at 80% capacity adding 6 extra seats just means an extra 6 empty seats on every flight. The $733 million number is meaningless - what is actually needed is to know how many post-reconfiguration flights had 5 or fewer free seats, since that is the only situation in which the extra capacity is being used.

<comment><USER9> Not if they maintained the same occupancy rates but with a higher total capacity.

80% of 100 is 80 80% of 106 is 84ish

<comment><USER21> Why would the average number of passengers suddenly change just because they installed six more free seats?

<comment><USER22> Look at the post right next to the one you're replying to. More seats makes it easier to get more people on board without risking filling up.

<comment><USER21> But if they _could_ get more people on board, they wouldn't be 80% full. Or are you referring to the times they're completely full, which would go up by 6 seats? Then 6 doesn't get added to the entire average.

<comment><USER22> It's probabilistic. You can't just sell 100% of tickets ahead of time and be done. Some people don't show up. Some people buy tickets at the last second. The more tickets you sell the more you risk running out of space and having angry customers that need to be compensated. Even if you assume every flight has the same demand, having more seats lets you sell more tickets which lets you get more people on board, without needing flights to be full.

On top of that, you have uneven demand causing completely full flights, and while it doesn't add 6 to the entire average it adds a notable fraction of 6. Note that nobody actually claimed they added a full 6 more passengers.

<comment><USER21> Josefresco above claimed that the 80% rate could be 80% of the new seating arrangement, which just adds +6 across the board. That's what I "took issue" with.

<comment><USER22> What? It adds +4.8 which seems to match what actually happened.

<https://news.ycombinator.com/item?id=5710359>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> I feel like saying "a single inch" like it's a pittance when we're talking about airplane legroom is a bit silly. Sure, it seems small compared to the other 31 inches, but that's not a fair comparison, because most of those 31 inches are non negotiable.

Realistically, we're talking about at least a 5% reduction in leg room, and that's nothing to sneeze at.

<comment><USER24> You obviously are not above average in terms of height. I'm 6'5" and planes are a nightmare of cramps and bruised knees. A single inch can mean the difference between being able to sleep comfortably on a long flight and staying awake while stiffening up for eight hours.

<comment><USER25> Ditto. I tried the near OD strategy for an Auckland-Rome series of flights. It turns out that you reach the point where they dont work anymore - at least not easily. At 4x the recommended dose I couldn't sleep that last 6 hours. I seem to max out at about 20ish hours of sleep. I almost got a DVT - swollen leg and very painful. I just avoid flights now.

Edit: premature post.

</comment></comment></comment><comment><USER26> > _That means, every year that single inch earns them $773,074,040 of > additional revenue. I guess every little bit really does count._

This does not. There are so many intangibles here, that the conclusion drawn is very ill-conceived. Here's a list of things that can affect this number:

1\. The amount of customers lost due to restrictive seats

2\. The negative PR which will result from the change

3\. The impact on flight price that the company may change after said PR

4\. Is the data from all of those references accurate?

The list goes on and on...

It's a nice thought, but there's much smarter people with access to more precise information that draw these conclusions _within_ the company. Enterprise businesses aren't as dumb as we all may think they are.

</comment><comment><USER27> I've been underestimating the size of the airline industry. I have a hard time reconciling the fact that the airlines always seem to be on the verge of bankruptcy with numbers this big -- $90+ billion a year in just passenger revenue.

<comment><USER28> The issue here is probably their margins, not their volume, though? It doesn't matter how much passenger revenue they bring in if the expenses (safety, security, regulation conformance, equipment maintenance, fuel, staff pay...) outweigh it.

<comment><USER29> It reminds me of the old quip "We lose money on every sale, but we make up for it in volume."

</comment></comment></comment><comment><USER30> My girlfriends father is a pilot for southwest. For my birthday we flew home with my pregnant sister, we of course flew standby. On the way back, my sister and I were separated in Phoenix, where she ended up getting stuck for the night because every flight after 11am was booked. What I'm saying is that although they were able to add more seats, they still can't give everyone a seat, and to southwest that's money lost, and to me, that's one frightened sister.

Although I enjoy my legroom, it was hell trying to get my sister home.

<comment><USER31> I love dark chocolate.

</comment></comment><comment><USER32> Being 6'5, my knees hate these numbers.

<comment><USER33> at 6'4" I'm sort of _just_ below that range of "get this man an exit row, stat!"

my buddy who is 6'8" has it given to him virtually every flight

<comment><USER25> I'm a bit under 6'5" and bit over 6'4". I know this situation well and have only rarely managed to get an exit seat, and yet have often seem people who are almost half my height in them. The only time we managed to get an exit seat was when my pregnant wife was literally crying from her legs being so sore that they gave them to us.

</comment></comment></comment><comment><USER34> I don't know the economics of airlines, nor travel that much, but I can't believe there isn't a niche for an airline that features a reasonable amount of legroom at a reasonably higher cost. Something above the "cattle pen with wings" that people seem to have to put up with.

</comment><comment><USER35> UKs Ryan Air was even proposing ideas of having people stand during flights (yep, its really that ridicolous) and letting people pay to use the lavatories...

Not that they would get through with that but still, they are searching for every inch to make more money.

<comment><USER36> Those crackpot schemes are just designed to get their brand in the Daily Mail and in turn, for people to talk about Ryanair. (their headquarters are in Ireland, not the UK)

<comment><USER25> Is it Ryan air that gets all its air hostesses to paint their faces with orangeish makeup? I have a recollection of a collection of air hostesses in skin-colour-inappropriate makeup from a trip a few years back.

<comment><USER37> If it's orange then it's likely to be EasyJet as everything they do is that colour

</comment></comment></comment></comment><comment><USER38> If they came up with a way to run at 90% capacity instead of 80%, I wonder how many seats they could remove and how many inches of leg room could be gained.

</comment><comment><USER39> Nice! When you account simple changes like this, it's amazing just due to the massive improvement. I could just imagine the saving for Walmart if they followed Ikea's model with doing away with plastic bags.

<comment><USER40> The Wal*Mart here doesn't have plastic bags but that is due to a city ordinance in Eugene. They charge five cents per paper bag but most people just bring in their own bags.

</comment></comment><comment><USER41> not all Southwest airplanes are 737's

<comment><USER42> Southwest is famous for maintaining an all-737 fleet (I don't know what they're doing with Airtran's 717 fleet, but Airtran hasn't been integrated with SWA yet.)</comment></comment>


I'm looking for a few cofounders to apply to YC. Working on something huge. - <AUTHOR>

I've spent the last 5 years working in the web and mobile industry building high quality software. Even though I don't have a degree and am largely self-taught, I doubled my salary at that job within 2 years, converted my workplace to Macs, and established the company's mobile development practice, becoming the lead mobile developer.
Our main product was a web CMS which we used to build custom sites and apps for people. In this process, there's a designer, and the designer must produce a design (which dictates aspects of the resultant software) according to his/her understanding of the client's needs as well as his/her amount of knowledge about computer systems. The developer then generally has to take this design and attempt to convert it into real software. Unless the designer is one of the rare people who is also an engineer, and unless this process is set up in such a way as to give the developer a high degree of input into the design, then the resultant software probably will never reach its full potential. The UI may not take full advantage of the tech, or the tech has to be redesigned or shoehorned into the client or designer spec. It's an altogether suboptimal approach to what should be a smooth and well understood process.
We've seen this kind of thing happen before. In the period of time before companies like Adobe and Apple ushered in the age of desktop publishing, the artist who designed something for print and those who produced/implemented it were entirely separate. The artist could of course produce copies of his work but usually it took lots of time and resources. When we got desktop publishing the game changed. Nowadays, instead of real canvases, paintbrushes, and pencils, we use tools like Photoshop, Illustrator, and printers to produce high quality work.
Right now we are experiencing a huge shift from print and web publishing to mobile and web publishing. And the problems in the process of producing mobile apps and publications indicate a huge missing piece in the puzzle.
There are some solutions to these problems. But where I worked, even in my position, nobody wanted to listen to me. I got fed up, and after using a few weeks to validate these solutions, despite my high paying job but lack of long term savings, I quit my job in November 2011. I began working to launch Blueprint (https://blueprint.io), an online tool for creating iPhone apps by yourself.
I built the MVP and was able to launch a private beta within a few months. Since then, it's received so much interest from the people to whom I've introduced it, and we've had quite a few signups. I even have a few customers that look like they'll be purchasing within a week or two.
I know that Blueprint could be huge. It's exactly what designers need, not to mention the droves of people who wish they could realize their mobile app ideas but find a huge barrier in learning to code – and I have so many exciting things planned for the near future. But right now my problems is that trying to juggle all of its aspects is too much work for just one person. I want to spend my time working on iOS and product development, where I'll be able to contribute the most value. But I have had to shoulder the additional burdens of marketing, design, server-side & web app development, PR, and more.
I completed my application to YC (for summer 2012) last month, but I know that single founders have a slimmer chance of being accepted or taken seriously.
That's why I started looking for one to three smart people to join me in my quest to change the face of mobile development into what it should be.
* A web programming wizard, preferably someone well versed in Node.JS, who could take over development of the web app and much of the server-side aspects
* A publicist with a strong background in design, or a designer with a passion for marketing
* A hustler/businessperson who could take us to the big leagues
Even if you don't match any of these roles exclusively but are a capable person interested in working on this problem, I want to talk to you. You can reach me at paul _at_ blueprint _dot_ io
I've been networking aggressively but it's been really difficult to find the right people. The deadline for YC apps is in a few days, so I'm appealing to the HN community in case there are some heroes out there who can save the day.
Come work with me on Blueprint, and revolutionize how we produce mobile applications. <comment><USER2> Please, don't do this. You don't need partners just to check off a box for yc. You should only partner with people that kick ass and who think you kick ass. Take as long as you need and don't worry about your yc application being incomplete. I bet they discount teams who have only been together long enough to fill out the application more than a single founder who's making it work.

<comment><AUTHOR> Thank you for the encouragement. :) I'll remember what you said.

</comment></comment><comment><USER3> So this is a native web app wrapper?

BTW, the viewport size for the page is in logical pixels, the page currently looks shrunken in retina iPad :)

<comment><AUTHOR> Thanks for the heads up! That bit should be now fixed (looks ok on my iPhone 4), but unfortunately I don't have a retina iPad to test it out. I do know I have to do a little work to fix up the site for mobile.

Blueprint is not a web app wrapper, it actually runs proprietary native code and apps you create are entirely native – unless you choose to incorporate a web view component into your app.

However, if you'd like (since you are probably a programmer) you could use a WYSIWYG view (which is really a UIWebView and for which I've exposed some advanced fields for Javascript, CSS, page begin/end etc) and input your web app code so that you can wrap it in a native app (sort of like people do with PhoneGap, just without having to put together an Xcode project and handle builds and so forth).

Thanks!

</comment></comment><comment><USER4> Oh really. You have the idea, you "just need" a developer and some biz guy?

<comment><AUTHOR> No, it is already a fully functional product, which I launched at MVP in late January; I wrote the native iOS code, the server-side & front-end code, did the design, produced business cards, flyers, etc. Once had a partner who did that to me though, so I understand your comment. Thanks for looking – accounts are free if you'd like to try it out.</comment></comment>


Benchmarking State-Of-the-Art Deep Learning Software Tools - <AUTHOR> http://arxiv.org/abs/1608.07249 <comment><USER2> It's not surprising that TF is the slowest in many cases. It has been widely, sometimes harshly, criticized in the past for that reason. On the other hand, despite its speed TF appears to be the only tool that doesn't have to sit out any of the tests due to incompatibilities or lack of features.

Other tools like MXNet deserve a shoutout as well, and it would be interesting to see how a wider group compares. MXNet also integrates seamlessly into R, something of a rarity in deep learning tools (excepting the also excellent h2o package).

<comment><USER3> Yes, unfortunate that MXNet wasn't covered. It's in the happy Venn place of (fully cross-platform) ∩ (easy to embed) ∩ (flexible) ∩ (hackable).

* Cross platform: Windows, MacOS, Linux; CPU and CUDA. Though their CMake needs work.

* Easy to embed: straightforward C FFI, JSON for metadata and parameter serialization, no weird runtime.

* Flexible: not too specialized to vision. Static unrolling of RNNs possible now (with mirroring this can still be very memory efficient [0]), basic support for the fast new cuDNN 5 RNN layers [1] (contributed by colleague of mine). Dynamic unrolling is on the horizon I hear.

* Hackable: once you're familiar with the codebase, custom elementwise unary or binary ops = few minutes, custom layers = 1+ hours (depending on complexity). And if you can leverage mshadow primitives for your layer implementation, you don't even have to touch CUDA. Also fairly active on github, responsive to PRs etc.

[0] [https://arxiv.org/pdf/1606.03401.pdf](https://arxiv.org/pdf/1606.03401.pdf)

[1] [https://devblogs.nvidia.com/parallelforall/optimizing- recurr...](https://devblogs.nvidia.com/parallelforall/optimizing-recurrent- neural-networks-cudnn-5/)

</comment></comment><comment><USER4> When properly configured, most of these libraries use NVidia's CuDNN package under the hood. The only thing you're really measuring here is overhead, not the actual computation.

</comment><comment><USER5> No Theano comparison?

</comment><comment><USER6> CNTK is great at scaling out beyond a simple machine. The paper didn't benchmark that but only tested one single box performance.

<comment><USER7> Realistically, most people barely get to multiple GPUs, let alone multiple machines. You're more likely to do hyperparameter tuning across machines before you do distributed training.

</comment></comment><comment><USER8> I wonder why Torch is so slow. But, the authors did not provide the configuration of each tool in the paper or on the web.

<comment><USER9> > I wonder why Torch is so slow.

What do you mean "so slow"? It's by far the fastest framework covered by the paper in scenarios where threads don't outnumber CPU cores.

Taken from the article itself:

"However, Torch still achieves the best performance in our experiments in which Torch has nearly 12x speed up compared with TensorFlow under 4-thread setting."

<comment><USER8> Why can't Torch utilize more threads in CPU cores? Taken from the article itself: "both of them cannot run normally when threads usage is set to be bigger than the number of CPU cores on desktop CPU." Do the authors set up the system correctly?

You're right that Torch is faster than TensorFlow in RNN. But Torch is slower than TesnorFlow in AlexNet and ResNet. There is a set of benchmarks for many DL approaches as found in [https://github.com/soumith/convnet- benchmarks](https://github.com/soumith/convnet-benchmarks)

<comment> T-A Context-switching is expensive. You have to swap out the data being worked on by thread #1 and swap in the data for thread #2. So you end up being bottlenecked by memory bandwidth and latency rather than by raw compute.</comment></comment></comment></comment>


Man in disguise boards international flight - <AUTHOR> http://www.theglobeandmail.com/news/national/disguised-man-boarded-air-canada-flight-report/article1786681/

<comment><AUTHOR> A decent photo at CNN: [http://www.cnn.com/2010/WORLD/americas/11/04/canada.disguise...](http://www.cnn.com/2010/WORLD/americas/11/04/canada.disguised.passenger/index.html?hpt=C1)</comment>


How to Design a Scalable Rate Limiting Algorithm - <AUTHOR> https://konghq.com/blog/how-to-design-a-scalable-rate-limiting-algorithm/#.WjlcxXHbXuU.hackernews <comment><USER2> For a different view on the topic watch "Stop Rate Limiting! Capacity Management Done Right" [https://www.youtube.com/watch?v=m64SWl9bfvk](https://www.youtube.com/watch?v=m64SWl9bfvk)

The basic premise is not do do req/s limiting but rather concurrency limiting which results in req/s limiting by itself.

Concurrency limiting is rather simple and doesn't require a lot of code complexity.

<comment><USER3> The problem here is, it depends on _WHY_ you are rate limiting. If it's just to balance so you don't overload your backends, then absolutely this is a great way to do it.

If however you are trying to limit client(s) because the service is an authentication gateway for instance, then you want to limit user/pass requests to X number then concurrency limiting isn't a good way to do that.

So you may need _both_ , depending on your use-cases, so it's not a one-size fits all solution.

<comment><USER4> What is the use case for your second example? I am not following.

Wouldn't that just be rate limiting by client IP though?

<comment><USER5> >Wouldn't that just be rate limiting by client IP though?

This won't defeat an adversary with a botnet.

<comment><USER6> But this is not something you deal with a rate-limiter. By your logic, then a sufficiently large botnet would dwarf any live traffic whatsoever, implying you'd probably want to filter them on network level instead.

</comment></comment></comment></comment></comment><comment><USER7> > A better approach is to use a "set-then-get" mindset, relying on atomic > operators that implement locks in a very performant fashion, allowing you to > quickly increment and check counter values without letting the atomic > operations get in the way.

In a highly distributed system you'd probably want to avoid a centralised data store altogether for fast moving data like rate limits. CRDTs and bucket weighting might be a more effective strategy.

The article states that tracking per-node could cause a problem with race conditions but that assumes it's the counter that's the problem. If the node cluster is aware of the other nodes and the relative load of the cluster, you can use this value to weight the isolated rate limiter and the only data that needs to be shared can be broadcast between the nodes using a pub/sub mechanism.

If some variance is permitted (+/\- a margin either side of the limit) then having the nodes synchronise their "token weight" based on the size of the cluster means that the nodes can then manage the rate limit in-memory without ever needing to track in a data store.

It does trade-off accuracy, but for accuracy you can then revert to the set- then-get centralised counter, the trade-off being performance because of increased round trip time to the day store.

In most rate limit scenarios, at least from what we've seen, extreme accuracy isn't usually that important vs. being able to scale amd rate limit without having to also scale a data layer to handle the counters.

</comment><comment><USER8> Disregarding the article completely, I'll share my opinion on Kong because we use quite a bit at my workplace. We use an old version (0.9.x as of right now). The things I shared below might not be true anymore in new versions but I can't tell and are regarding the plugin system.

IMO, the idea of taking things like authentication, rate limiting, etc in a proxy is a wonderful idea ([https://2tjosk2rxzc21medji3nfn1g-wpengine.netdna- ssl.com/wp-...](https://2tjosk2rxzc21medji3nfn1g-wpengine.netdna-ssl.com/wp- content/uploads/2017/12/illustration2.png)). So in theory, the approach Kong takes is wonderful, but I think the implementation is not so much.

Kong is layer over nginx and uses lua as a scripting language to add all sorts of stuff. Quickly, you reach the limit of the plugins capability so you think, well, I will write my own plugins. Well, to me it was a very unpleasing experience. I found that the thing was hard to test and hard to maintain. Maybe my criticism is more lua than Kong but since Kong relies heavily on lua, there is not much I can do.

There is also magic happening. You declare a schema.lua files to configure the store to hold your data. Then automatically you've got a DAO interface available with a bunch of method on it to work with the store. You don't know what methods are available or what arguments should be passed into these functions.

Anyway, this is my take after spending quite a few hours working on home made plugins in lua for Kong.

In the end, I'm glad Kong is open source and it's a great piece of software. It helped us reduce our applications complexity but make sure you don't start to shift to much logic into it because the plugin system can be hard to work with.

<comment><USER9> Have you found any viable alternatives to Kong?

<comment><USER10> Not OP, but we are using Tyk (tyk.io) at my workplace. It's definitely more user friendly than Kong, but we've had other issues with it. Having not used Kong extensively but knowing what it is, I'll go out on a limb and say Kong is likely more performant.

<comment><USER11> Actually it should be the opposite. Definitely do your own benchmark, but take a look at the latest numbers from Tyk and compare it with the latest numbers from Kong to get a general idea.

<comment><USER12> This analysis was done by BBVA comparing Tyk and Kong performance [https://www.bbva.com/en/api-gateways-kong-vs- tyk/](https://www.bbva.com/en/api-gateways-kong-vs-tyk/) \- disclosure: I work for Kong, but Kong (the company) had no involvement with the benchmarking in that article.

<comment><USER13> Those BBVA benchmarks look very very wrong. BBVA achieved 3822 requests per second with a 16Gb server running Tyk.

I used a 16Gb Digital Ocean box, and a separate box to run benchmarks from.

Tyk CE with keyless api.

docker run --rm williamyeh/wrk -t4 -c100 -d1m --latency --timeout 2s [http://10.131.45.89:8080/tykbench/get](http://10.131.45.89:8080/tykbench/get) Running 1m test @ [http://10.131.45.89:8080/tykbench/get](http://10.131.45.89:8080/tykbench/get) 4 threads and 100 connections Thread Stats Avg Stdev Max +/\- Stdev Latency 5.79ms 6.97ms 206.76ms 87.28% Req/Sec 6.35k 0.93k 10.89k 74.33% Latency Distribution 50% 3.19ms 75% 6.28ms 90% 15.93ms 99% 31.14ms 1516573 requests in 1.00m, 185.13MB read Requests/sec: 25244.99 Transfer/sec: 3.08MB

As per above results, I got 25,244 requests per second. 90% of requests were served with sub 15ms latency.

Another thing - you can freely scale with Tyk CE as much as you want at no- cost. I currently run 3 gateways in prod and it doesn't cost a penny. The BBVA article states that you need to pay Tyk to scale - simply not true:

>However, if we want to deploy a significantly larger number of microservices, or simply ensure high-tolerance to failure, we need to scale up the number of gateways. In the case of Kong, all it takes is adding a new node and connecting it to the database. With Tyk we can do the same, although it will require us to pay for the service. This could be a determining factor when choosing what API Gateway to use.

I went through process picking API gateway about 3 months ago. Tyk is not without it's warts, but has far more out-of-box features baked in (inc distributed rate limiting) than Kong. And if custom plugins are required, I can choose between lua, python, js or anything that supports gRPC. With Kong - stuck with Lua.... no thank you.

I guess my point here is that if Tyk not performant enough for you, just add another gateway. And if I need custom functionality - I don't need to learn Lua.

</comment></comment></comment></comment></comment></comment><comment><USER14> This may be how Kong does it but it's not really 'high performance'. The right way to do rate limiting is to limit by IP using a counting Bloom Filter or Cuckoo filter along with random samples. When you hit a false positive then you have a second normal rate limiter to 'mop up' IPs that are over the first limiter.

This doesn't give you a hard exact limit but gets the job done storing far less state. You also need to bucket by IP sub-ranges in IPV6 to stop people crap flooding you with tons of unique IP's

</comment><comment><USER15> I have been using Kong since 2016 on various APIs and I have been impressed by the continuous increase of performance after every release. I wish upgrades were easier but I know they are working on it (the "migrations" between each major version), but overall it's a fast and pluggable layer for any API inside or outside the firewall, especially if you are running containers.

On this note for those of you who haven't noticed it yet, they have released an Alpine version of their Docker image, but it's still not the default one. I would actually recommend using it to further reduce the size of Kong containers: [https://konghq.com/blog/kong-alpine- docker/](https://konghq.com/blog/kong-alpine-docker/)

</comment><comment><USER16> Nice article (although the illustrations aren't very... illustrative). Anybody knows how does Kong compare with WSO2 API Manager?

</comment><comment><USER17> Excellent article! One question though:

> A better approach is to use a "set-then-get" mindset, relying on atomic > operators that implement locks in a very performant fashion, allowing you to > quickly increment and check counter values without letting the atomic > operations get in the way.

Can you elaborate on this? Why is it more performant? And what are the trade- offs vs. get-then-set?

<comment><USER18> Was passing by and saw this, a better explanation and in-depth analysis can be found here:

> [https://blog.figma.com/an-alternative-approach-to-rate- > limit...](https://blog.figma.com/an-alternative-approach-to-rate- > limiting-f8a06cf7c94c)

</comment></comment><comment><USER19> The performance degradation of doing strict rate limit relying on Kong Cluster data store (Postgres or Cassandra) is amplified by the lake of database connection pool management. Each incoming http request induce the creation of a new database connection, this process is very expensive especially with Cassandra when authentication is enabled.

</comment><comment><USER19> I use Kong EE for a client, I have read Kong EE documentation carefully and made a lot of tests. The current implementation (0.29) have this behavior (that not meet our needs).

1) All incoming requests are take into account, including those which have been rejected (with 429 error). If the consumer exceed his limit during many consecutive time windows, all the requests of the consecutive time windows will be rejected (with 429 error).

2) For a windows size of 1 second, the computed weight of the previous windows is always 100%. If the limit was reach during the previous second, all requests made in the current windows will be rejected (with 429 errors).

</comment><comment><USER20> One thing that RateLim.it uses to its advantage is calculating the "nextPossiblePass" for each limit. This allows clients to cache forever that something is over the limit until time X and not have to make another request.

In the bursty case this let's clients effectively short circuit and protect the system.

Disclaimer: I work on [https://www.ratelim.it/documentation/basic_rate_limits](https://www.ratelim.it/documentation/basic_rate_limits)</comment>


Ask HN: Comments please on my beginner's introduction to JavaScript slides - <AUTHOR>

I am doing a presentation for complete beginners about JavaScript (and programming) basics, and would like some feedback on anything I might have gotten wrong. (their minds are fresh, I hate to plant incorrect things there).<p>http://slid.es/eranation/introduction-to-javascript <comment><USER2> First off it is short and concise, and I think it is very informative.

..,but thinking of Complete beginners? You need to make it more approachable.

"What is javascript good for?" might be a good - maybe cite some real-life basic examples of javascript in use.

Also having a slide at the end showing examples of what javascript is capable of doing. (with a lot of effort)

The "what does this do?" example is not very interesting.. I didn't want to know what it does. (this may be dependent on the audience) As an alternate you could make this interesting where you have an array of words (that could lead to some humorous results) and the code puts out some clever phrase. (Shakespearean insult generator comes to mind, that might be inappropriate though, maybe work up a surfer compliment generator or something.) besides being interesting to read it could then be modified by the students to create other generators, etc. - that give some quick positive feedback of working with live code.

</comment><comment><USER3> The content itself seems great. I have a few tips for the presentation, though.

\- The "enter," and "you get" slides are a bit hard to visualize. Put "enter" on the left and "you get" on the right

\- Try including some interactivity with the audience (After explaining something, show a small code snippet and ask the audience what will come of it - you can even give out prizes for right answers)

Anyway, the presentation looks great! Good luck with it!

</comment><comment><AUTHOR> Clickable: <http://slid.es/eranation/introduction-to-javascript></comment>


World Domination Using Arduinos and Websockets - <AUTHOR> http://kevinrohling.wordpress.com/2011/09/14/world-domination-using-arduinos-and-websockets/ <comment><USER2> I've done a lot of microchip pic programming but for equally simple(read beginners) and cheaper avr development I would recommend a teensy. Besides using a standard pinout spacing you can also program it with the arduino ide if you feel so inclined. Of course if you want to use the arduino shields, it's more convoluted, but if you just want to light a few leds, read some sensors, it should be enough.

Anyway, it's quite nice to have all these possibilities; some years ago the barrier to entry was much higher, now with 10 minutes of tutorial reading you can light a led or control a servo through your browser from the other side of the world, which is fantastic.

<comment><USER3> Another great thing about the Teensy++ is that it has a AT90USB1286 which offers 128 KB of flash and 8 KB of RAM. That is a big improvement over the Arduino Uno's ATmega328 that offers 32 KB of flash and 2 KB of RAM.

<comment><USER4> This is one of the two things that got me to order one last night. Being able to build with it on a breadboard makes a huge difference compared to the arduino. I've got a number of fun projects to do that the breadboard makes more fun to start. (Particularly things with model trains and monitoring window sensors).

</comment></comment></comment><comment><USER5> Anyone know the current status of browser support for websockets? My understanding is that FF 6 has them, but no other stable browsers do.

I've seen this Wikipedia chart: <http://en.wikipedia.org/wiki/WebSockets#Browser_support> but it's not clear to me what the different protocol versions mean in actual functionality.

<comment><USER6> Current story on WebSockets

There are two components to web sockets. The WebSocket API under development by the W3C/HTML5 groups (<http://dev.w3.org/html5/websockets/>) which defines the javascript/browser API and the WebSocket Protocol under development by the HyBi working group at the IETF (<http://datatracker.ietf.org/wg/hybi/charter/>) which defines the actual wire protocol.

The WebSocket API has been relatively stable for awhile, most of the changes recently have been hashing out how to handle binary messages in javascript.

The WebSocket wire protocol has been undergoing more substantial development in the past year and is presently in the Last Call phase of IETF standardization. The final wire protocol has _not_ been fixed yet.

Protocol version numbers were added sometime last year and each version stands for which draft version of the protocol the user agent is implementing. Not all drafts change the wire protocol so some version numbers aren't used. The purpose of the version numbers was to help folks who were writing test implementations of websocket to keep track of which implementations should work together for interoperability testing.

The draft/version number primarily indicates that the client can only talk to servers that speak the same version. Clients typically support only one draft, servers often support multiple drafts. The current draft ([http://tools.ietf.org/html/draft-ietf-hybi- thewebsocketproto...](http://tools.ietf.org/html/draft-ietf-hybi- thewebsocketprotocol-14)) uses protocol version 13. FireFox 6 ships with a prefixed (MozWebSocket) websocket object that implements draft 7. FireFox 7 and 8 and Chrome 14 and 15 (beta and dev channels respectively) currently implement draft 8, though this may change before they are shipped. Safari 5.0.1+ and Chrome 7-13 implement draft 0, an obsolete version from 2010.

Draft 7,8, and 13 are nearly identical, a server supporting one will likely support all three. Draft 0 is significantly different. There is a list on wikipedia of the major websocket implementations and which protocol versions they presently support ([http://en.wikipedia.org/wiki/Comparison_of_WebSocket_impleme...](http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations)).

The OP appears to be using a simplified version of a pre-draft 0 that Pusher implemented. I am not actually sure why it is using websocket at all since it doesn't appear to actually use the browser as the source of the connection. It just happens to be using an early draft of the websocket protocol as it's message framing mechanism.

<comment><USER5> Thanks for taking the time to write up the details. I appreciate it.

</comment></comment></comment><comment><USER7> Arduino? Pshhh... just wait until the raspberry pies are done!

<comment><USER8> In some senses this will be _harder_ on the raspberry pi. Certainly more complex. You'd have to worry about the whole stack from the kernel upwards. On arduino, you handcraft your protocol right on top of the TCP/IP lib and just squirt it straight into the bootloader. Done.

</comment></comment><comment><USER9> No talk about the network shields?

<comment><USER10> The subject of the post was more the software not the hardware. The Arduino in the post is using the WiFly shield: <http://www.sparkfun.com/products/9954>

<comment><USER9> Yeah, I know, however the author made it seem like all you need is an Arduino (no mention of shields) and you can connect to a network.</comment></comment></comment>


Ask HN: Choosing a Side Project - <AUTHOR> When the time and energy you have available to work on side projects is limited, the opportunity cost of working on the wrong one is enormous. How do you choose which of dozens of ideas to pursue? <comment><USER2> I blogged about coming up with an idea for my latest project last week: [https://www.indiehackers.com/blog/how-to-come-up-with-a- busi...](https://www.indiehackers.com/blog/how-to-come-up-with-a-business- idea)

At some point, I narrowed a list of 40+ idea down to 4, and then I picked one. I used a somewhat formal process to help me out, and that was to evaluate each idea based on a checklist of 7 requirements:

1\. Do people need this? (i.e. have I identified a niche that I'm very confident will love what I build)

2\. Can I personally do a good job marketing and distributing it? (i.e. do I know where the target customers hang out online and am I sure I can get the word out about my product there)

3\. How hard will it be to avoid churn and keep retention high? (i.e. is the product set-it-and-forget-it, or at least somewhat naturally re-engaging? or will it require lots of effort from users' to keep using)

4\. Is it meaningful and beneficial to the world? (i.e. will I enjoy working on it for years to come)

5\. How long will it take me to build an MVP? (i.e. do I have time for this now)

6\. What kind of effort will it take to keep it running long-term? (i.e. will I have time for this later)

7\. Can this idea actually generate revenue? (i.e. do I have a business model in mind that has been proven to work for this kind of idea in the past)

My advice to you is to come up with a similar checklist, run through your ideas, give each a score, and go with the highest one!

</comment><comment><USER3> An alternative approach: break side projects down into short-term projects. Basically minimum viable products. This shortens the time to feedback and minimizes the opportunity cost from picking the wrong one.

It's generally easier to optimize this path, then to "pick the right idea." Because it's basically impossible to know ahead of time. And, besides, you'll learn a lot through each iteration. Good luck!

<comment><AUTHOR> Yes, I'd love to do that. Trouble is, the last couple MVPs I did took 6-18 months each, due mostly to limited time available. (And no, they couldn't be pared back further - these were basically proofs of concept). Hence the question!

</comment></comment><comment><USER4> I've had several and they've all been great learning experiences. I started by customizing some php-mysql form generator and selling databases to small businesses. Next I learned ASP.NET and wrote web services to collect water treatment data remotely. After that, the biggest and most successful side project I did was Cupcake Wrapper Creator. I rewrote it once. Then I started a SaaS project in Django, but never finished.

Recently I gave up on a AVR emulator I was writing (in C, to learn C at the same time). The core controller structure and instructions were fun, but when it came time to implement the IO, I realized I just wasn't that interested. Plus I have older kids now who realize when I'm neglecting them, a bigger house to maintain and a more demanding job.

Now I just do a few algorithm exercises in Juypter or crypto challenges in Go each week. I'm still learning and I get a sense of accomplishment without the nagging unfinished project aftertaste.

</comment><comment><USER5> Depends on your goal. Are you looking to make money, learn something, have fun, or simply stretch your creative muscles?

<comment><AUTHOR> Great question! I'd like to make something that will eventually bring in a bit of (relatively passive) income and ideally accomplish at least one of the other three. TBH, just working on my own code rather than the legacy deathtrap we have at work feels like a nice change of pace.

</comment></comment><comment><USER6> I would approach this with two things in mind.

1\. Pick something you can do in a relatively short time, say less than one year. That way you do not run out of steam working on it.

2\. Pick something that you will learn a new skill or skills working on. Regardless of if what you choose succeeds or fails, you still come out ahead with a new skill.

</comment><comment><USER7> One compelling idea that I heard recently was looking around on odesk and similar sites for lots of similar requests and building a tool that solves those problems.

The upside is that you can find a probably that people are provably interested in paying money to solve. The downside is that most ideas you'll find are going to be a real grind to solve and are unlikely to be passion projects which is often helpful for success.

<comment><USER8> I've tried doing a little bit of that before but didn't seem work very well.

I could hardly spot a good "pattern" in the jobs posted.

Most of them seemed ad-hoc and custom enough that after looking at a 100 you will still struggle to find a common denominator.

<comment><USER7> [https://blog.parsehub.com/how-we-got-our-first-10-paying- saa...](https://blog.parsehub.com/how-we-got-our-first-10-paying-saas- customers/)

I believe this post was the genesis of the odesk idea.

SaaS tends to be inexpensive compared to paying a human to do something, even if that human is underpaid, since costs are amortized across many customers. You're paying for something more similar to (CPU time+profit margin) instead of human time. I'd also hasten to add that there are two sided marketplaces where average costs are higher.

</comment></comment></comment><comment><USER9> Do what inspires you! That likely implies you don't consider the opportunity costs; be ready to take risks and learn from your mistakes.

Try to reach milestones on any project. Personally, in this stage of my software engineering I almost always intend to ship projects with "production" quality to "production".

</comment><comment><USER10> Make something you need yourself, as it gives you insight into making a good product, and likely others will need it too. Worse case, you made something that makes/saves you money even if it doesn't scale.

</comment><comment><USER11> Write down as many ideas as you can. It helps improve an idea before wasting time on it.

<comment><USER12> And also to prioritize.</comment></comment>


Found a potentionally good partner, but cant come up with good idea - <AUTHOR>

Thoughts on how to proceed? <comment><USER2> What brought you two together? Why do you think you'd be good partners?

Maybe examining your cross-over of interests, abilities, knowledge, etc. will make something pop out.

Just start building SOMETHING. Give it a go, come up with a tiny idea and see what comes from it. Without knowing your abilities, etc. it's tough to know what your areas of interest may be.

<comment><AUTHOR> We knew each other from startup meetup groups ~2 years ago, kept short contact over the last 2 years, and this month reunited and have been talking about ideas since.

We'd be good, because we have complimentary skill sets, and personalities.

</comment></comment><comment> T-A [http://paulgraham.com/startupideas.html](http://paulgraham.com/startupideas.html)

[http://www.ycombinator.com/rfs/](http://www.ycombinator.com/rfs/)

</comment><comment><USER3> The most valuable idea you can work on, and the one most likely to succeed, is one you are scared of. An idea you won't admit to yourself.

So one approach to finding that idea is to try hard to _not_ come up with an idea. Make that a goal and you may notice that ideas start flowing in that way. Individually, write down these urges, and focus on summoning the courage to face them.

</comment><comment><USER4> Why don't you list your individual abilities and synergies as you see them here? Especially why you are good partners.

Maybe HN readers will see where you could apply these skills and make suggestions.

<comment><AUTHOR> Look at my other comment, but, he is primarily business end - sales/marketing, and i'm primarily engineering, with interest in business end

</comment></comment><comment><USER5> You could start doing contract/consulting work just to get a feel for how you work together.

</comment><comment><USER6> What kind of things/problems/domain would you like to work on ?

</comment><comment><USER7> Then don't start a business. All of my ideas came from my real-world experience and things I dealt with on a daily/monthly basis.</comment>