oinksoft

According to the presentation, 9% of all HTTP on FF36 (for those who didn't disable this data collection) is HTTP/2. Surely there are people here using HTTP/2 in production: How are you serving HTTP/2 traffic?

The listing itself is somewhat muddled ... "Twitter" is an entry, linking to the Twitter homepage, presumably that's responsible for most of this traffic? I found https://github.com/twitter/netty-http2 and https://github.com/twitter/hpack on Twitter's GitHub.

This is just my experience, but "YAGNI" is often shorthand for "I don't want to think about it." I'm not talking about criticisms of wasteful design/features, but somebody actually saying "YAGNI" with little elaboration. It's imprecise and lazy.

That sounds terrible, is Rust that unstable in practice today? I remember hearing that the language had mostly stabilized at the end of 2014, but anecdotes like yours are discouraging.

> I think your statement "that earth is unusually dense" is incorrect [..] Mercury is much more dense than the Earth.

To be fair, Mercury's basically a ball of iron.

Was clipping the power cable a big problem? I've never done that with a laptop, but have found the brittle MagSafe connection to be an almost daily annoyance since it was introduced.

jQuery was far from the only popular cross-browser DOM library. We had a choice of jQuery, MooTools, YUI, Prototype, Dojo, Mochikit, and quite a few others, along with good presentation of standalone cross-browser techniques from sources like QuirksMode. jQuery mostly succeeded through its marketing to web designers which formed a critical mass of well-written extensions and hireable know-how, and a zeitgeist of jQuery as a baseline.

You're right that Sizzle was the class of selector engines, and if the story ended there (with jQuery as a DOM library) then jQuery wouldn't be listed on many resumes. By publishing `jQuery.prototype' to `$.fn', pushing the idea of "plugins", and by encouraging DOM operations as the main extension point in application design, jQuery made itself into something more. The brittleness of this approach is proven by how calling jQuery UI component methods requires an additional level of dispatch. This way of doing things has no legacy. It's considered an antipattern now, and a "mess of jQuery" is a known form of code debt. I don't think it's a matter of whether this style "fits your needs" anymore.

  > _I was there_ ... In 2007, at the beginning of my journey
  > I started this blog. I remember my first JavaScript
  > tutorial which gained a lot of readers, even though I 
  > wasn’t the expert in the field ... So when I recommended
  > jQuery, some people followed me in this opinion and tried
  > it.

This post was a fun read simply because my own career path is not unlike the author's. I spent this time in comp.lang.javascript (;^)) and ##javscript, where I learned pretty quickly that I was decidedly not hot shit and that even frontend JavaScript development already had a significant history. Today I wouldn't entertain the idea that I was present at the start of some turning point, it was just the start of another career.

Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took to jQuery like a fish to water, but more experienced folks correctly slapped my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I wasn't quite sure why it was so reviled in these circles, but given that I had arrived at these communities to learn and not teach, I went with it and just listened (and didn't write blog posts).

Over time I saw jQuery for the abomination it is. A very usable, imprecise API that has "fluent interface" and a selector engine as its chief selling points, where a single prototype is the God object to end all God objects. Given that all of the other libraries implemented a comparable selector engine, I never felt deprived when working with Prototype, or MooTools, or Ext.js, or ultimately Google Closure. I could see that designs written with these other libraries were far more comprehensible and cohesive than what was coming out of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand, so I just kept writing lots of software for my employers, and didn't write blog posts.

Maybe some day the history of how jQuery "made it" will be written. It seems like a shining example of "Worse is Better." Recommendations like the one from the author were just the blind leading the blind. Now we're stuck with it. Maybe more of us who felt this way should have written blog posts, but as the author hints, that's the paradox! You can spend so much time writing software, or spreading ideas, but seldom is there time to do both prolifically. I still don't feel qualified to write blog posts like this one...

Well, I've read and re-read this comment hoping to glean something useful, and all I can gather is that you find familiarity to Ruby/JavaScript programmers to be the chief selling point of a language, and that you expect Erlang to be effective in heavy data processing applications.

  > The build tool was not immediately apparent, and it
  > seemed like the community had still not settled on one.

Hm, there are a handful of projects that try to get by with essen's `erlang.mk', but the community has settled pretty well on Rebar. Even essen's projects include a rebar.config because that is standard for distribution and dependency specification.

  > The repl is pretty shit compared to every other repl
  > I've ever used: ruby, python, clojure, scala, etc.

That's a strong claim, could you elaborate? Because to me a REPL that includes the usual bells and whistles (code reloading, good autocomplete, fast startup) along with job control, the ability to connect to remote systems, and being uncrashable is a whole lot better than "shit," and in my experience is miles ahead of, say, `lein repl` or even the wonderful IPython.

  > I don't think the rest of the world goes out of their
  > way to find awesome uses.

"Handbook of Neuroevolution Through Erlang" disagrees. Indeed, that book's author claims that Erlang is the language for representing "thinking" systems.

  > its inability to market itself as letting you move
  > faster and break more things.

Huh? That's the core of Erlang's value proposition from what I've seen and any "marketing" efforts focus on Erlang's robustness (that said, nobody should be specifically championing "break more things"). Going way back into Erlang's history you can find "Erlang, the Movie," and writings by Armstrong that emphasize hot code reloading, the system's ability to recover from any error, and the VM's support for incremental improvements in software without downtime.

  > environments that get people "most of the way there"
  > without having to learn a totally alien ecosystem ...
  > Erlangers will argue that with Go or Scala you may get
  > some of the features of Erlang, you don't get the whole
  > package.

Systems you mention like Go and Scala have their own considerable strengths, but they're just not comparable for the applications at which Erlang excels: Highly reliable, low-latency (soft realtime) systems written at a high level. At the same time, Erlang is slow and provides none of the assurances a statically-typed language offers. I can't imagine an experienced engineer seriously considering Go for a project that requires Erlang's strengths, or vice-versa.

What I gather from all of this is that Erlang isn't a fit for your high-throughput data processing application(s), and that you've somehow conflated this with a "marketing" failure on Erlang's part or that Erlang's goals are not focused. But Armstrong's message about what Erlang is good for has remained consistent for decades now.

As an aside, if your Ruby/JS guys didn't take to Erlang, I'm not sure why you expect to get far with Scala. Go seems quite popular with the Ruby crowd and sounds like a strong fit for what you're doing.

  > validate the structure of tuples as parameters to
  > functions.

Dialyzer can definitely do that, you just need to specify a type that is a tuple:

    -type something() :: {Thing  :: thingtype(),
                          Thing2 :: thing2type()}.
    %% ...
    -spec foo(something()) -> thingtype().

But I agree that Dialyzer can feel incomplete. It's been a little while now but I recall having to use `term()' in specs (basically, untyped) to suppress false positives in some cases. It was also quite slow.

Still, a much better situation than Ruby.

  > Ruby uses green threads (meaning only one CPU will get
  > used) and they are no easy equivalent to Go channels.

Restriction to a single core is a consequence of the GIL. Also Ruby uses native threads, not green threads, since 1.9.

The author's `execute` method is dangerous because it doesn't escape its arguments.

  > programming on programming itself ... does seem a bit
  > 'meta' and removed from why we're all doing this in the
  > first place.

I heartily disagree, and think that tools vs. "actual problems" is a false dichotomy. Software design/engineering is very much its own discipline. A good API/framework/whatever can lower defect rates and generally make your software more coherent and maintainable. That saves time, money, and headaches. We should absolutely care about the tools we use, because nobody else is going to, hence "programming on programming." Attributing that to a quest for "celebrity" is cynical, and I don't see how you can blame programmers for seeking a good professional reputation by creating tools for their peers.

Having spent a day at Atlassian's office in SOMA when contracting for them recently, if this sort of setup is done right (with the additional caveat of having an energetic staff) the effect is positively electrifying. The "Costco purchases" jab is overly broad, because this office had very nice motorized standing desks for everybody. Also, the complex was large enough that you could escape into some personal space without feeling like you were hiding.

On the other hand, Gannett attempted a setup like this, except it was out of cheapness (they wanted to lease office space in their Tysons HQ) and was carried out mindlessly. They mixed developers with technical support, managers, etc. thoughtlessly. And they installed "white noise" machines which made matters worse. Working in that place was almost impossible and I quit after a month.

Closure Library is certainly written in a way that takes advantage of the compiler to keep compiled scripts compact. Code that makes heavy use of goog.dom could look like:

  goog.require('goog.dom');

  var dom = goog.dom;

But that defeats dead-code elimination and makes the compiler include goog.dom in its entirety (the Compiler only goes so far when determining if code is "dead"). So, any use of a goog.dom function will be fully qualified:

  var el = goog.dom.getElement(id);

Practically, you might use goog.dom.DomHelper instead to keep code compact, and because it stores a reference to the document object you're using.

This surprisingly makes ClojureScript really nice for developing with the Closure Library (not that using any library that depends on mutable objects is particularly nice in Clojure), because you can write code like the following, and still benefit from dead code elimination:

  (ns whatever.ns
    (:require [goog.dom :as dom]))

  ;; ...

    (let [el (dom/getElement id])

The Closure Library is impractical without dead code elimination because it includes so much functionality, and is not meant to be used as a single script dependency.

Elements of Distributed by Computing by Vijay Garg is great: http://www.amazon.com/Elements-Distributed-Computing-Vijay-G...

This is called eDiscovery, and people have been working on it for a good while, certainly longer than two years (I worked at a startup in this space, 2009-2010).

Also disagree with

  > 6.2 Watching Functions
  >
  > Another common problem is the utilization of functions
  > in watchers or bindings. Never bind anything (ng-show,
  > ng-repeat, etc.) directly to a function. Never watch
  > a function result directly. This function will run on
  > every digest cycle, possibly slowing your application
  > to a crawl. 

A while ago this sort of advice was true (when you'd see people inlining stuff in `eval` to avoid this), but nowadays function execution itself is very fast.

You don't want to watch a slow function, but just watching a function will not "[slow] your application to a crawl."

Interesting post, but I'd take this author's advice with some salt.

Data appears to be persisted to disk via Basho's bitcask. You mentioned in another comment that ETS is being used, which it is, but that's not on disk (DETS is the disk-backed version); ETS is used here to communicate between processes via public, named tables.

The author and I don't agree, except that Angular is not suitable for high-performance frontends (like games). The author suggests that Angular is only suitable for prototyping and that simply using the framework is technical debt. I particularly disagree with this statement: "Accept the fact that you will suffer in the future. The lowered expectations will help you stay happy sometimes."

It seems like the author is simply unhappy to be working in a framework not of his own design: "Create a metaframework based on angular, tailored SPECIFICALLY for your project needs and your team experience!" That's the one thing you shouldn't do if you want to reuse code between projects.

I've not gotten the same impression and expect Angular 2 to be out sooner than later. Here's a code example: https://github.com/angular/angular/blob/master/modules/examp...

It looks like `master' is all Angular 2 and coming along well.

I've been using Angular on-and-off in professional settings since 2012. Angular is a framework obsessed with testability that treats usability as an afterthought. That said I've found Angular to be more than flexible enough to meet the needs of your typical CRUD apps, and generally enjoy working with it.

One thing I agree with the author about is the importance of expertise for a successful Angular project. Some specialized knowledge is needed to get a decent fit and finish, and the results can be horrible without that.

Strongly discouraging globals goes a long way towards improving code written by inexperienced engineers, but Angular's provider system is still not clearly documented with practical examples, which makes those engineers more likely to shove everything into the unavoidable Angular constructs (controllers, directives, $scope).

The middling quality and small availability of third-party Angular libraries is a problem. I believe that greater awareness/better tooling for ngDoc would be a tremendous help there. Best practices are not well-presented anywhere in the Angular world, particularly for designing reusable Angular libraries.

The other big problem is the project source code which I find poorly organized and documented. If you want to get into the guts of Angular for debugging purposes, good luck!

I agree and think don't understand why you'd want your dotfiles to depend on Make, Ruby/rake, etc. let alone something like Stow. Git and a shell are enough; you can eliminate the Git dependency by packaging from a post-receive hook too.

OK, but nothing in your comment implied that you were talking about the "Shellshock" vulnerability. I believe that a very recent OSX update patched this vulnerability, anyhow.

That should be #!/usr/bin/env bash, particularly for BSD which does not install bash in /bin. Nothing new about absolute executable paths being non-portable, #!/bin/bash is as bad as #!/usr/bin/python.

No, you change your user shell to the shell you want. You can do this in the "Accounts" preference pane by control-clicking a user, selecting "Advanced Options" from the context menu, and changing the "Login shell" setting to your preferred shell.

I would never suggest a programmer learn Clojure as their first language, because of the enormous Java stacktraces. Then there's the setup involved (Java, usually Leiningen) to get to "Hello, World" compared to Python or Ruby. Just too many places where the student can get seriously stuck. Clojure's strengths (immutable structures, expression freedom, macros, Java interop, JVM) are not relevant to the new programmer.

And then you hit control-C and resume editing. None of this is as dramatic as you describe, and syntax-highlight freezes aren't as common now with the improved highlighting algorithm in 7.4.

Don't hold your breath, the consensus reached in the few minutes the thread below was breathing seems to be that the domain name provides sufficient context.

https://news.ycombinator.com/item?id=8258117

See the context? "Navdy (navdy.com)"

Sorry, I can't even feign concern about the state of Vim's source code. I'm a Vim user and plugin developer, not a Vim developer.

A single-threaded UI means I can easily tell what Vim is doing at any time. It means the editor never feels clunky because indexing or some other background activity is hogging resources. It also means I never get a "process is running" prompt like in IntelliJ or Emacs when I want to exit.