Brubeck – A statsd-compatible metrics aggregator - <AUTHOR> http://githubengineering.com/brubeck/ <comment><USER2> I was at Etsy when we made statsd, and I'm currently working on fixing the same problems at Stripe. This is super interesting and relevant to me personally, thanks for writing it all down!

There are some details of how Etsy uses statsd that are not well-communicated. Etsy samples metrics aggressively to limit the amount of total traffic. And they monitor the packet error rates on the statsd boxes like hawks to keep the loss rate in check. Back when I was working there, if you added a high-volume counter without sampling it, the alarms would sound and you'd have an ops person tapping your shoulder pretty quickly. If you use statsd and skip either of these steps, the 40% loss that github experienced is what you get.

AIUI Etsy's moved to a consistent hashing scheme that's at least vaguely similar to this.

Node was not then, nor is now Etsy's area of expertise. We were going through an adolescent "let's just use every language" phase when we built statsd. I think the problems outlined here are solid supporting evidence that you should use a smallish set of tools and master them (a point of view which is very on- brand for Etsy engineering as it exists today).

<comment><USER3> Have you considered pushing the aggregation into the applications, rather than doing it across the network?

Having whatever library is sending data to statsd, instead keep counters/gauges in memory and then expose that on a regular basis would greatly reduce the data volumes involved as it's O(timeseries*frequency) rather than O(events).

This is the approach we take with Prometheus, and based on the statsd setups of some people who've come talking to us there's scope for a reduction in network load of at least an order of magnitude without having to do any downsampling.

<comment><USER2> Yeah this has come up and it's reasonable, although it's a tricky/laborious migration in practice given a wide variety of things emitting stats.

The statsd design choices here are mostly explained by the fact that Etsy uses it to collect from PHP. PHP doesn't afford a great way to aggregate in the client. (These are design choices that serve PHP well systemically, although it's limiting here.)

<comment><USER3> I hadn't realised the PHP link, things make more sense now.

You're getting into IPC then, which is a fun topic alright e.g. [https://github.com/prometheus/client_ruby/issues/9](https://github.com/prometheus/client_ruby/issues/9) and [https://github.com/prometheus/client_python/issues/30](https://github.com/prometheus/client_python/issues/30)

</comment></comment></comment></comment><comment><USER4> This is awesome, and more choice is definitely good, but I'm curious if Github tried out statsite[1] at all in this process? My guess is that these two tools were built at the exact same time solving the same problems.

[1] [https://github.com/armon/statsite](https://github.com/armon/statsite)

<comment><USER5> statsite is also based on a event-loop and is limited to a single core (no smp).

<comment><USER6> To clarify, statsite does spawn threads to do some of the aggregation and flushing at the end of the collection interval, but yes it is possible to saturate the main loop at a very high ingest rate.

</comment></comment></comment><comment><USER7> I once built a web framework named Brubeck ([https://github.com/j2labs/brubeck](https://github.com/j2labs/brubeck)). I stopped developing it a while ago, though.

I am really happy to see another project, one that will probably reach more people than my web framework, honor the same wonderful musician I was trying to honor.

<comment><USER8> Funny i think i remember going to a brubeck meetup here in NY once. My old co- woker Patrick mentioned it and we ended up seeing a talk on it.

<comment><USER7> That was me. BrubeckNYC. :)

</comment></comment></comment><comment><USER9> Can't help but plug our MIT-licensed port of Graphite/StatsD to .NET: [1].

[1]: [https://bitbucket.org/aeroclub- it/statsify](https://bitbucket.org/aeroclub-it/statsify)

</comment><comment><USER10> There already exist many statsd implementations from which two in C and four in golang. Why the need for another one?

[https://github.com/etsy/statsd/wiki#server- implementations](https://github.com/etsy/statsd/wiki#server-implementations)

<comment><USER11> Presumably because they didn't exist (or weren't production-ready) three years ago:

"After three years running in our production servers (with very good results both in performance and reliability), today we're finally releasing Brubeck as open-source."

</comment></comment><comment><USER12> Perchance named after Dave Brubeck?

<comment><USER13> Indeed!

<comment><USER14> Complete with a subtle joke about odd meter!

</comment></comment></comment><comment><USER15> >A Turing-complete computing device running a modern version of the Linux kernel... I liked that!

Any plans for pluggable backends in addition to BRUBECK_BACKEND_CARBON? Pls consider making it agnostic, i.e. using a wire protocol.

</comment><comment><USER16> I don't really "know" golang but this seems like an area where it would have been useful.

Am I think about this the right way? Would channels have helped handle some of the load effectively?

Any gophers care to comment? :D

<comment><USER17> Choosing C for this project is definitely... strange. Keith Rarick calls it "downright irresponsible" [1] — I'm not sure I disagree.

[1] [https://twitter.com/krarick/status/610502413007503360](https://twitter.com/krarick/status/610502413007503360)

<comment><USER18> What is the alternative? Rust isn't there yet when it comes to IO and there are certainly no other languages that qualify and allow a similar level of control.

<comment><USER19> What about nim ? There are facilities to run an evented loop, to listen on an udp socket, can be tuned for more realtime capabilities, is compiled to C...

<comment><USER18> Nim doesn't have the same popularity. There aren't a lot of people that know the language, that makes hiring people that do difficult, it means there may be nobody at Github that does either and due to it's lack of popularity people will probably be less willing to learn it than Rust or Go.

</comment></comment></comment></comment></comment><comment><USER20> Looks great! Question for the author(s) of Brubeck: are you planning to add an InfluxDB backend, or is that something you'd want the community to pick up?

</comment><comment><USER21> Is there a reason why you didn't just use collectd, which is written in C and has lots of plugins, including statsd, InfluxDB, Graphite, etc.?

<comment><USER13> We use collectd extensively and it is wonderful software. Brubeck and collectd do very different jobs.

<comment><USER21> What does Brubeck do that the collectd statsd plugin can't?

[https://collectd.org/wiki/index.php/Plugin:StatsD](https://collectd.org/wiki/index.php/Plugin:StatsD)</comment></comment></comment>


Ask HN: What are some ways to structure APIs other than REST and GraphQL? - <AUTHOR> I am a self-taught noob trying to plan the API for my first non-trivial project. The general consensus appears to be like that REST and graphQL are the only ways to structure APIs and GraphQL is better than Rest whenever you may need to make data intensive requests. How true is that? <comment><USER2> The first paradigm of APIs was "Remote Procedure Call". In this case, the API call represents some specific action that you would like to take. This could involve modifying multiple linked or unlinked data records in a single transaction.

As for GraphQL, I'd say OData, SPARQL and other Linked Data protocols are competitors</comment>


If 3D Printing Wins, Shapeways Loses - <AUTHOR> http://www.hackthings.com/if-3d-printing-wins-shapeways-loses/

<comment><USER2> You can buy a traditional printer for peanuts these days and yet Walmart, Costco, etc still make tons of money printing photos.

For 3D (where the printers will be bigger and smellier and require more technical chops to operate even as they fall to mass market prices) this will hold even more so.

<comment><USER3> But really most people just stopped printing photos altogether as smartphones took over photography.</comment></comment>


Iacocca's Nine Cs of Leadership - <AUTHOR> http://www.chiefexecutive.net/ME2/dirmod.asp?sid=&nm=&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=2B3850FCCEF64A4FB6F73620F779231B

<comment><USER2> I expected the list not to be very good because of the cheesy same-initial- letter aspect, but it turned out to be good.</comment>


John Gruber being deliberately obtuse - <AUTHOR> http://theorangeview.net/2011/09/john-gruber-being-deliberately-obtuse/ <comment><USER2> iPhone users tend to be heavy data users. So what Gruber implies is that the relative lower volume of data usage on Android phones means the phone company earns less on a per unit basis.

</comment><comment><USER3> Spot on. Of course a provider is at a competitive advantage if they don't have an iPhone. But it isn't an either/or proposition; I mean, you don't see Sprint offering to go Apple exclusive and ditch Android...</comment>


Ask HN: Is the current cryptocurrency scenario a bubble like the dotcom one? - <AUTHOR> Apologies if this has been beaten to death and sounds cliche, but I'm still not able to wrap my head around how the current hype about cryptocurrencies is not just plain speculation and hype.
I was too young when the dotcom bubble happened, but from what I read on Wikipedia, the following were the reasons for the dotcom bubble and its eventual crash:
- Investors were eager to invest in any company with a ".com" suffix. Isn't this very similar to people just looking to invest in new ICOs (I still have no idea what those are)?
- There was a real sense of fear of missing out - investors just couldn't afford to not invest in a company because the entire market was investing in dotcom companies. Isn't this akin to how people invest in coins just because others are buying in? In fact, isn't the entire Bitcoin climate running on this?
- The market was confident that the companies would turn future profits. Isn't this too similar to "I'll cash out later when the exchange rate rises further"?
- An unprecedented amount of personal stock market investment occurred during the boom. Again, there are so many people blindly (not all, but some) buying coins without fully understanding the risk, purely based on speculation.
- Companies went public through IPOs so frequently. Now currencies offer an ICO so often.
Just reading through https://en.wikipedia.org/wiki/Dot-com_bubble#Bubble_growth I find so much similarity between the two scenarios.
I have heard some arguments denying a bubble - it mostly comes down to the statement that most new and brilliant things appear to go through a bubble. But isn't there too much of a similarity?
Again, I know this is a very beaten-to-death topic, so apologies if you're tired of hearing this (and I searched before asking HN). <comment><USER2> The main thing I see is complete ignorance about distributed systems, currency, business, etc.

Funny enough, last year I went to a conference in NYC where people talked about using blockchains to do "back-office" functionality in financial services. For instance, if you own 45 shares in Caterpillar, somewhere they keep track of how many you own, where to send the dividends, what to do in case of splits, mergers, etc.

Existing solutions are not so satisfactory, also it is a good fit for blockchains because it is a pure ledger without any need for money to be in two different places at once (as does any kind of debt instrument)

Today the ICO is all the rage because it can easily keep track of the fact that you own 31 shares of this or that. It doesn't guarantee that those 31 shares are worth anything, but it does keep track of it.

What amazes me is that there is so little interest in small permissioned blockchains. I mean, really, if I just want to lend books between me and 10 friends, why do I want to get thousands of computers on the Ethereum network working on it when we could just run our own small blockchain?

</comment><comment><USER3> I think it's somewhat comparable to Tulip mania[0] which happened in the 1600s.

If you want to read up on bubbles, you won't be disappointed with that story. The TL;DR is people were selling their homes to buy tulip bulbs because they were certain they were going to flip them for massive profit.

[0]: [https://en.wikipedia.org/wiki/Tulip_mania](https://en.wikipedia.org/wiki/Tulip_mania)</comment>


Microsoft Open Sources Roslyn (C# Compiler) - <AUTHOR> https://roslyn.codeplex.com/SourceControl/latest

<comment><AUTHOR> It looks like it's Apache 2 licensed, so that includes a patent grant. No MS- PL or worse, Microsoft Research License.

</comment><comment><USER2> another (more active) discussion: [https://news.ycombinator.com/item?id=7524082](https://news.ycombinator.com/item?id=7524082)</comment>


Physics Paper of the week: Collective Motion of Moshers at Heavy Metal Concerts - <AUTHOR> http://arxiv.org/abs/1302.1886

<comment><AUTHOR> Quoting from the end of the paper:

"Source code and a phase diagram generating Python script are available under the M.I.T. license on github.com at <https://github.com/mattbierbaum/moshpits> . An interactive Javascript version of the simulation is available at <http://mattbierbaum.github.com/moshpits.js> ."</comment>


Ask HN: How to learn a new programming language coming from another? - <AUTHOR> The question is kinda self-explanatory. I'm on my way to try to become a career developer and get some context in other languages (for instance, Javascript in general and probably NodeJS), but every tutorial I come with is about learning the basics from scratch.
Considering I'd like to get a side project while learning the new language, how could I possibly be able to boost my knowledge process without going though basic tutorial all over again?
Thanks :) <comment><USER2> You could try to read a github project and look up syntax when you get stuck. But for languages, I just like to suck it up and go through the text version of the basic tutorial extremely fast. Or watch boiled down video tutorials at 2x. Take simple notes to remember syntax differences. It will be boring but over in 2 hours. That's not much time.

Then you can find new interesting features that weren't present or similar in languages you used before and take a bit more time to broaden your understanding why they were chosen, and how this creates new constraints, opportunities, or room for errors.

For platforms like node.js the architecture is highly variable and sometimes finding and walking through an example close to your eventual project will be most useful.

Cheers!

</comment><comment><USER3> I think it is best to start from the basics but you just have to find a "basics" book that is not aimed at beginners. Let's say you come from any OOP language and read up on JavaScript - you might just skip the chapter on Functions because heck - I know what function are. But you would miss out a lot of the interesting aspects of the language. See [https://eloquentjavascript.net/05_higher_order.html](https://eloquentjavascript.net/05_higher_order.html)

</comment><comment><USER4> I have had to learn nearly a dozen languages in my career. You are on a useful track coupling your study with a side project. I found carefully reading a language manual cover to cover while trying to see how to complete a project was powerful and surprisingly easy. The best manual includes a little example material with the specs. It does depend some on how different the philosophies are. The more different they are the more a tutorial is useful.</comment>


The Libertarian Utopia That's Just a Bunch of White Guys on a Tiny Island - <AUTHOR> http://www.gq.com/story/the-libertarian-utopia-thats-just-a-bunch-of-white-guys-on-a-tiny-island <comment><USER2> > [Liberland...] might one day become the Libertarian utopia for disaffected > white men.

I'm a supporter of the libertarian movement and I have never come across anyone or anything that equates libertarianism with oppression. Just the opposite, actually. It's about, as the name implies, individual liberty.

So what on earth is it about Liberland that has to do with being a heaven for 'disaffected white men' and an implied oppression of women? I admit I skimmed through some sections, but I could not find any substantiation. I did find: "Monika Chlumská, Liberland's Foreign Minister, also serves as its secretary and general coordinator."

I could not tell you what on earth is it that is going on with the themes in this article. It focuses heavy emphasis on a negatively-connotated theme of _white_ males without any substantiation.

<comment><USER3> Sounds political. Maybe you should flag it.

Just as Paul Graham talks of submarine pieces which are adverts in disguise, the same thing happens with political messages dressed up as something else.

This severely annoys me when it is in the world of fiction.

The recent Sherlock Holmes (BBC) is an extraordinary example of this. Sherlock is no longer interested in solving crimes (!!!!) when a proto-feminist movement may be behind them. Another one is readings from the Koran in Eastenders, a daytime TV soap in the UK. This sort of stuff is designed to sway the minds of the less intelligent. That is plain and simple what is going on.

I do not like it when fictional characters are telling me what to think politically. It is beyond farcical. It makes me think the message must not have any substance to it, that it would sound stupid to anybody if it were declared out loud what it was.</comment></comment>


Elasticsearch's DMCA Takedown on Search Guard - <AUTHOR> https://github.com/github/dmca/blob/master/2019/09/2019-09-10-elasticsearch.md <comment><USER2> It would be helpful, if GitHub made it clear that repositories without an explicit open source license grant fall under the full scope of Copyright restriction. It seems there is a common misconception that any code simply shared on GitHub is free to use.

However, it seems the case for this DMCA takedown is probably not clouded by the "publicly available means free use" misconception.

</comment><comment><AUTHOR> Related: [https://news.ycombinator.com/item?id=20881739](https://news.ycombinator.com/item?id=20881739)</comment>


Why isn't this news? - <AUTHOR> http://caps.fool.com/Blogs/ViewPost.aspx?bpid=92143&t=01007173441069183815 <comment><USER2> Reddit is at <http://www.reddit.com> and Digg is at <http://digg.com> \- they love this sort of post there.</comment>


Le Corbusier's Algerian Fantasy: Blocking the Casbah - <AUTHOR> https://assets.bidoun.org/articles/le-corbusier-s-algerian-fantasy <comment><USER2> I find that 95% of the material I read that touches on urban design takes a particular viewpoint: small-scale, accretive, "human", heterogeneous, walkable, urban spaces are good; large-scale, top-down, "inhuman", car or transit-focused, urban spaces are bad. Le Corbusier is a villain, Jane Jacobs a hero.

Does anyone know a good source for the counterargument? It seems like there must be another side to the story. Moscow is full of concrete superblocks and it's actually pretty nice. San Francisco is all eclectic little urban micro- neighborhoods and it has very serious problems with public nuisances and crime. Maligned modernist projects like Pruitt-Igoe were often used to house the very poor, and it seems like sometimes the architecture is blamed for what may be just an association between poverty and crime. According to at least some studies, tearing down project housing relocated a lot of crime to the suburbs, only modestly decreasing overall crime rates [http://www.chicagomag.com/Chicago- Magazine/The-312/April-201...](http://www.chicagomag.com/Chicago- Magazine/The-312/April-2012/Did-the-Destruction-of-Chicagos-Public-Housing- Decrease-Violent-Crime-Or-Just-Move-It-Elsewhere/)

<comment><USER3> > large-scale, top-down, "inhuman", car or transit-focused, urban spaces are > bad

You are combining a few different strands there. There are people who think brutalist megastructures are dehumanizing but who are generally pro-car. Likewise you shouldn't conflate car-friendly and transit-friendly approaches to planning: they are very different. Top-down planning is ever-present to varying degrees.

Jacobs' nemesis Robert Moses wanted to do extremely serious surgery on Manhattan, with the assistance of the architect Paul Rudolph. Luckily it didn't happen, though other major projects went ahead. It was part of the whole post-war prioritization of the car (in Europe and America) which is now seen a mistake, and you will not find serious theorists defending it.

You ask for a counterargument to Jacobs' ideas, but I think that invites a dualistic framing of the problems. See e.g. this article: [https://archpaper.com/2016/05/best-use-abuse-criticize- jane-...](https://archpaper.com/2016/05/best-use-abuse-criticize-jane-jacobs/)

In terms of examples of successful modernist planning which are seen as a desirable model today, Neave Brown's Alexandra Road estate in London might be of interest. It's a megastructure, concrete, alongside a major railway line, with uncompromising modernist aesthetics.

There is parkland, but not an ocean of space which isolates blocks from circulation routes. (This is a common criticism of the Zeilenbau/Corbusian approach to planning, which has to be weighed against the benefits of having greenery between blocks).

It is an immense "gesture" of structure which follows the curve of the railway, but faces away from it to control noise levels.

I'm mentioning all this because it is the particular architectural decisions and strategies that make the difference. It's not a result of picking one side or the other in the Moses/Jacobs debate. You could perhaps argue that it represents a third way, but there are many possibilities.

If there is a meaningful countercurrent to Jacobs' ideas, it's the idea of pursuing architecture/planning itself rather than an ad-hoc folksy urbanism.

<comment><USER4> The Riverwalk in San Antonio is a decent example of successful modernist planning. It's a bit touristy, but in a way that I wouldn't mind seeing repeated in other urban centers.

</comment></comment></comment><comment><USER5> I fail to see Feminine in a concrete curtain so bit it would obscure the Sun. But then I may just be biased by this article I recently read: [https://www.city-journal.org/html/architect- totalitarian-132...](https://www.city-journal.org/html/architect- totalitarian-13246.html)

<comment><USER6> Brutalism is a cancer of architecture. So many of these buildings are anti- human on so many levels, reducing people to nothing but unthinking, uncaring agents in a machine.

<comment><USER7> Brutalism is about truth in architecture -- buildings look like what they're made of, and what they do. People are agents in the machine everywhere. Brutalism just exposes it.

<comment><USER5> Well, there's also truth and material exposure in beautiful brickwork... imho, brutalism is more about wwii ptsd (and general postwar rebuilding effort and no money to waste on frills

</comment></comment></comment></comment><comment><USER8> " _...a general disillusionment with technology in the face of the market crash of 1929 and the rise of Fascism and Nazism (all frightful by-products of a collective faith in progress)._ "

No. Just no. Progress, or even a "collective faith in progress", had nothing to do with the market crash of 1929, the subsequent depression, or the rise of Fascism and Nazism (although they get bonus points for recognizing a difference between the two).

<comment><USER9> Both fascism and communism are Industrial Age ideologies that had faith in certain aspects of progress (modern efficiency and order, economic modernization, shiny steel war machines, etc.). Certainly fascism and Nazism had a lot of Romantic, anti-modern reactionary ideals, but it was synthesized with a lot of the trappings of progress. The Italian Futurists were compatible with Italian Fascism, after all.

Not sure how the market crash applies to progress, unless the Roaring Twenties were supposed to be an unprecedented time of irrational economic exuberance that foreshadowed our modern credit-driven economy.

</comment></comment><comment><USER10> > the market crash of 1929 and the rise of Fascism and Nazism (all frightful > by-products of a collective faith in progress)

Oh come _on_.</comment>


Schools Can Now Get Facial Recognition Tech for Free. Should They? - <AUTHOR> https://www.wired.com/story/realnetworks-facial-recognition-technology-schools/ <comment><USER2> In think this can be summed up in one word _NO_</comment>


Storj Labs will discontinue support for the transfer.sh service - <AUTHOR> https://transfer.sh/ <comment><AUTHOR> Really sad to see transfer.sh go. It was an extremely useful service for sending files to people, like Firefox Send but with fewer limitations, and didn't require signing up for an account.

Obviously it's extremely difficult to keep a service like this running indefinitely, but it's obviously of great value to many people. Maybe one day we'll be able to work out a successful method for community funding of services like this.

</comment><comment><USER2> Firefox send died, too. Any replacements?

<comment><AUTHOR> Only one I can think of is [https://0x0.st](https://0x0.st), but it is more limited than either of these, including file size (512 MB vs 10 GB for transfer.sh), file types (executable types banned), blocks TOR exit nodes, etc etc. The person running it seems to want to take an active moderation approach to prevent it from being abused, which could be good or bad depending on your point of view.

Another option (if Bittorrent or Wormhole aren't usable) is to host the file yourself with IPFS, and take advantage of Cloudflare's free gateway with caching to limit the bandwidth needed to send the file to multiple people. There are also pinning services for IPFS that you can pay for with Bitcoin (or usually, non-anonymous methods as well).

For casual stuff, I imagine most people on HN have a personal server that they can just sftp files to. I certainly do that, but there are some contexts in which that's not workable.

Edit: someone in the Firefox Send thread shared [https://femto.pw](https://femto.pw)</comment></comment>


Steve Wozniak and wife may have been Covid-19 Patient Zero in US - <AUTHOR> https://twitter.com/stevewoz/status/1234575727678435328 <comment><USER2> Jan 9th: Recovering from serious illness caught during cruise

[https://twitter.com/stevewoz/status/1215331944604536835](https://twitter.com/stevewoz/status/1215331944604536835)

Jan 22nd: Janet and I recovering room virus we got over 2 weeks ago in Asia. I doubt it's coronavirus since we haven't been in Mexico (Corona)

[https://twitter.com/stevewoz/status/1220214582733688832](https://twitter.com/stevewoz/status/1220214582733688832)

March 2nd: Checking out Janet's bad cough. Started Jan. 4. We had just returned from China and may have both been patient zero in U.S

[https://twitter.com/stevewoz/status/1234575727678435328](https://twitter.com/stevewoz/status/1234575727678435328)

</comment><comment><USER3> His off the cuff tweet has no real meaning, Steve was no doubt in part joking, but to the HN title -

> Steve Wozniak and wife may have been Covid-19 Patient Zero in US

The US will have no patient Zero. This fundamental lack of understanding is the problem.

</comment><comment><USER4> Or not. It becomes news when their results are positive. Right now it's just another speculation.</comment>


How to implement strings - <AUTHOR> http://beza1e1.tuxen.de/strings.html <comment><USER2> Another idea is the OCaml string representation which is a sort of cross between C and Pascal. I wrote about it in [1]. It allows O(1) length, can store \0 in the string, while being backwards compatible with existing C-string-consuming functions.

It's applicable to C because most realistic implementations of malloc(3) store the size of the malloc'd area to the nearest word[2] and so the Pascal size part does not need to be stored explicitly. (Note this would require minor changes to the C runtime to allow malloc to make explicit the currently implicit size).

[1] [https://rwmj.wordpress.com/2009/08/05/ocaml-internals- part-2...](https://rwmj.wordpress.com/2009/08/05/ocaml-internals- part-2-strings-and-other-types/)

[2] [https://rwmj.wordpress.com/2016/01/08/half-baked-ideas-c- str...](https://rwmj.wordpress.com/2016/01/08/half-baked-ideas-c-strings-with- implicit-length-field/)

<comment><USER3> You can get the size of a malloc'd block with malloc_usable_size. Can't say if it's actually O(1) though.

<comment><USER4> You had my hopes up for a minute there, until I checked portability…

malloc_usable_size() is a GNU extension, so usable on Linux. MacOS has malloc_size().

One web page [1] says the GNU one is about 10 cpu cycles and the MacOS one is about 50 cpu cycles, so not the end of the world, but maybe a little long for string length checking.

I didn't check any BSDs and I have to wonder what the effect of changing allocators in Linux has. Certainly they could have a performance impact and possible a 'does not implement' problem.

[1] [https://lemire.me/blog/2017/09/15/how-fast-are- malloc_size-a...](https://lemire.me/blog/2017/09/15/how-fast-are-malloc_size- and-malloc_usable_size-in-c/)

</comment></comment></comment><comment><USER5> > The character \0 marks the end so we call this zero-termination. [...] The > only advantage of this representation is space efficency.

Sort of a tangent, but zero termination (aka null termination) can make parsing from a string slightly simpler.

Without a null terminator, in addition to processing each character, you need to check if you've hit the end of the string. With a null terminator, the end- of-input checking is elegantly part of the "processing each character" step.

You can always add a null terminator character to the end of your string in the length+data representations as well, but if your strings don't come that way you end up having to make a full copy.

<comment><USER6> Sds is somewhat nice in that you can work both ways. [https://github.com/antirez/sds](https://github.com/antirez/sds)

<comment><USER5> That's similar to C++11 std::string, which has a length indicator and a null terminator.

(I believe this was often true for std::string implementations before C++11, but apparently C++11 made it a requirement.)

<comment><USER7> C++11 mandatory null termination has the advantage that a call to data() or c_str() need not store the null byte. On the other hand, mandatory termination costs one additional store in some of the constructors, and burns one byte of the capacity for inline data.

<comment><USER8> How does it burn one byte of capacity for inline data? Are you saying there is a zero-byte way to encode the length that could instead be used, avoiding that one byte overhead?

<comment><USER7> What I meant was the standard requires the null byte at the end of the string, which reduces by one the possible length of the string when stored inline. If the null byte wasn't mandatory, it would be possible to store slightly longer strings inline, but then the implementation would have to conditionally materialize the contents to the heap in case of a call to c_str or data.

<comment><USER9> Only since C++11. In C++03 no guarantees were given on the time complexity on c_str, and std::strings could lay their contents our however they wished (and cause a heap allocation in the process of materializing a C string, if necessary).

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Unicode is indeed insanely complex. There is almost no query or transform of a Unicode string you can do beyond asking its length in bytes that is at all straightforward. I suspect that very few pieces of software that 'support' Unicode and do anything non trivial with text actually do so fully correctly. It would be nice if there was a well defined 'simple' subset that handled the 80% case that could be a reasonable target for the average app to support fully.

<comment><USER11> > It would be nice if there was a well defined 'simple' subset that handled > the 80% case that could be a reasonable target for the average app to > support fully.

Isn't that ASCII?

<comment><USER10> Well it ends up that if you don't want to go down the Unicode rabbit hole too far then yeah, your best bet is probably to stick with ASCII. As an example from my industry though, it would be nice if I could implement user name entry and display for a high score table in a simple game and support names in common European languages without needing to handle all the edge cases of e.g. mixed left to right and right to left text, combining characters, surrogates, etc.

I'm far from a Unicode or a languages expert but I'm familiar with one language with right to left non Latin characters and aware of just enough Unicode madness to know I don't know enough to handle many edge cases properly. It would be nice if a regular developer like me could support something more than plain ASCII but less than the full insanity of Unicode to accommodate at least some non English users.

<comment><USER9> You're basically throwing people with "inconvenient" character sets (i.e. everything that doesn't use something strongly resembling Latin characters) under the bus. Sure, you might be able to support Spanish, French, and German, but you're basically disregarding Japanese, Chinese, and Hindi when doing so (and possibly even ASCII, since you'd trade some symbols for accents).

<comment><USER10> That's not at all what I'm advocating. My point is that the extreme difficulty of fully supporting Unicode with all of its complex edge cases (like my examples of mixing left to right and right to left languages) means that the two most common outcomes are throwing up your hands and giving up supporting anything but English and just using ASCII or having broken, partial Unicode support.

I'm suggesting it would be nice to have another option where you could provide some level of support for non English languages with something you have some hope of implementing correctly. Applications that correctly handle editing of mixed left to right and right to left text are rare for example but you could support Farsi speakers reasonably well in many applications without handling that scenario.

</comment></comment></comment></comment></comment><comment><USER12> _"However, none of them are suitable for general strings where we might have many small ones"_

That's where I expected to see the Short String Optimization mentioned.

For short strings, it stores the string's characters in the same memory where, for longer strings, it stores a pointer to the characters (with 'short' dependent on the implementation)

It also tweaks how either get stored to make it possible (and fast) to determine what is stored in that space. See [https://shaharmike.com/cpp/std- string/](https://shaharmike.com/cpp/std-string/)

<comment><USER13> We decided against SSO for Rust, incidentally. I'm on my phone and it's late so I won't elaborate too much but it's not always clear it's a win, depending on language semantics.

<comment><USER14> I imagine I'd be more concerned with performance and locality than memory savings if every string required a heap allocation and an additional dereferencing for access.

However, rust is very well-engineered, and I'd be interested in knowing what factors made its decision a win.

<comment><USER15> IIRC, there are a variety of factors:

1\. Conventions and prevailing idioms. In C++ copying strings is common, both unintentionally due to the implicit copy constructor and intentionally as a means of defensive programming. In Rust, copying strings is relatively uncommon: Rust has no copy constructors (copying must be done explicitly with the `.clone()` method), and the borrow checker obviates the need for defensive copies and therefore passing string slices is overwhelmingly preferred (and recall that string slices in Rust (`&str`) are 16 bytes, in comparison to 24 bytes for C++'s `std::string`).

2\. Alternative optimizations. For example, in Rust, initializing a `Vec` (and by extension `String`) does not perform a heap allocation for zero-length values. IOW, you can call `String::new()` (or even `String::from("")`) in a hot loop without worrying about incurring allocator traffic. Any hypothesis that short strings are more common than long strings will likely also hypothesize that the most common short string length is zero (and this appears to be borne out in practice; this optimization is _really_ important for `Vec`, so important that, for Servo, it often makes `Vec` faster in practice than their own custom `SmallVec` type which strictly exists only on the stack), so this optimization goes a fair ways towards satisfying the "I actually do have many short strings and I'm not just copying around the same string a lot" use case.

3\. Weighing trade-offs. The pros of SSO are better locality and less memory usage, with the cons of larger code size and additional branches on various operations.

Putting it all together, this gives the Rust devs reasonable incentive to take the conservative path of not implementing SSO for the default string type. That's not to say that we'd be incapable of finding Rust code that would benefit from SSO, or that C++ chose their default incorrectly (different contexts allow different conclusions), or that the Rust devs will always have this stance (if performance benefits of SSO were to be clearly demonstrated on Rust code in the wild in such a definitive way as to justify changing the default behavior, then I don't think they couldn't find a way to make it happen).

<comment><USER16> String implementations are low enough level that they get influenced quite a bit by memory management behavior, sometimes in surprising ways.

G++ used to have CoW strings, but I believe they dropped them because for common cases the atomic reference counting was more expensive than potential copying.

Inlining strings save space and allocator traffic at the expense of a more complex string implementation and (depending on the platform/implementation) strings that do not start word aligned.

There are other flags you might want to put on an underlying text sequence:

\- that the text is exclusively ASCII in UTF-8 strings. This means the character count and indexing can be optimized to constant-time operations

\- latin-1 in UTF-16 strings. This means you can do an alternate 8-bit encoding for space savings, as well as constant-time count/indexing.

\- mark that the string represent a single grapheme cluster (aka a printable character). This may allow you to combine unicode text processing to a single data structure.

\- mark that the representation is a slice. In this case, you'd typically store an offset rather than a capacity. This again helps you combine higher level types on top of a single data structure and text processing libraries.

These features (and especially combinations of them) impact the hot path for text processing. If your language is already doing custom allocation (such as using a copy constructor), the allocator savings are nil, so it becomes a space vs code trade-off.

<comment><USER17> FWIW the C++ standard actually prohibits CoW strings, and any C++ standard library that implements CoW strings is doing so in defiance of the standard. AIUI this prohibition was completely accidental, and I believe it's due to the rules around which string operations do and do not invalidate iterators.

<comment><USER14> GCC updated their implementation to become compliant, probably for these reasons.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I personally think we should make a plentyfold of datastructures respresenting strings. Sure, I want a geenric fits-all structure to represent text as provided in many libraries and frameworks, such as .NET's String class. However, I have many situations where using that same String class is pure overkill and prone to security bugs. For instance, I want a DigitsOnlyString, representing only the numbers [0-9]. But I also want a NumbersOnlyString, representing the digits [0-9] but also all other number characters there are in Unicode. The same for e.g. emoji's, latin characters ([azAZ]), extended latin ([azAZ], plus a subset of diacritics) Chinese characters, and I can go on for quite some more examples (Password anyone? Don't allow a lot of Unicode edgecases). These classes will have the benefit of really efficient encoding in bits, being more secure, more clarity to programmers and most important of all clear reasoning. I bet 80% of String uses can be moved to a more constrained type.

<comment><USER19> All those are is a set of verification functions tied to strings ... we really dont need native data types representing this. Im not sure why you are not able to find a lib/function that easily verifies such things. Programing languges are the basic foundation which should be concerned with performance , organization and making sure freedom is given to the programmer. These are all specific edge cases for the programmer to define not for the programing language to worry about.

Would you rather they speed up the compiler/interperter or add edge case string classes? Its not like there isnt a trade off. This is a bottom of the barrel concern.

<comment><USER20> > Programing languges are the basic foundation which should be concerned with > performance , organization and making sure freedom is given to the > programmer.

This is one view, but there are others. For example, instead of focusing on performance and freedom, the programming language could focus on safety or formal properties.

E.g. there should never be code that compiles but is unsafe, or which can have certain classes of common bugs.

</comment></comment></comment><comment><USER8> > The only advantage of this representation is space efficency.

Ignorant nonsense. There are other advantages.

Advantage: If _s_ is a non-empty string, then s + 1 is the rest of that string. s + 1 is an extremely cheap operation: incrementing a pointer.

This allows recursion on strings. For instance, strchr can be coded like this:

       char *strchr(const char *s, int ch)
       {
          if (*s == ch) /* including ch == 0 case */
            return s;
          if (*s)
            return strchr(s + 1, ch); /* tail call */
          return NULL;
       }

A variety of useful algorithms can be implemented in this simultaneously elegant and efficient manner.

Advantage: null terminated strings can use exactly the same external representation as internal. They can be sent over the network as-is or written to files. There is no question of what format is this header, how wide is this length field and so on. Strings of wide characters just have a simple issue: how wide (16 or 32), and what endian.

<comment><USER9> Of course, most _actual_ strchr implementations tend to be heavily vectorized hand-tuned assembly with macros to select the correct streaming extension supported by the hardware. Or, for less powerful systems, something like

      char *strchr(const char *s, int ch) {
      	char *p = s;
      	while (*p && *p != chr);
      	return p;
      }

<comment><USER8>
      s/less powerful systems/systems with lesser compilers/

With TCO, I'd expect the same code from the recursive version.

The recursive version has the benefit of being pure; it doesn't mutate anything. Speaking of which, HN ate your ++.

</comment></comment></comment><comment><USER21> The first sentence:

"The C programming language defines a string as char* ."

No, it doesn't. A string is by definition "a contiguous sequence of characters terminated by and including the first null character". A char* value may or may not be a pointer to a string.

(Confusing arrays and pointers is perhaps the most common mistake people make when talking about C.)

<comment><USER22> A string in C is an implicit type; it's a specialization[1] of an array of characters. Another example of implicit type are Lists in Lisp (specialization of nested pairs).

[1] [https://en.wikipedia.org/wiki/Specialization_(logic)](https://en.wikipedia.org/wiki/Specialization_\(logic\))

<comment><USER8> A string in C is entirely built upon convention; it exists in the words of a document only.

Common Lisp has a _list_ class that you can specialize a CLOS method on.

Also:

      [1]> (typep nil 'list)
      T
      [2]> (typep '(a) 'list)
      T
      [3]> (typep 3 'list)
      NIL

And:

      [4]> (subtypep 'cons 'list)
      T ;
      T
      [5]> (subtypep 'null 'list)
      T ;
      T

So, kind of apples and oranges.

<comment><USER22> I was referring to John McCarthy's definition of a list. IIRC, Common lisp's list type includes both proper and unproper lists. (typep (cons 1 2) 'list) evaluates to true but (length (cons 1 2)) throws a type error (not a list).

</comment></comment></comment></comment><comment><USER23> > There are two relevant lengths of Unicode strings: memory size in bytes and > number of grapheme clusters.

There is also the number of codepoints, which is relevant when you implement Unicode-related algorithms.

And then there is display length (which counts full-width characters as two characters, even in monospace fonts, and zero-width characters as zero).

Finally, if you think grapheme clusters are the right way to count characters in a string (and it often is), then you should also allow string indexing on grapheme cluster level.

</comment><comment><USER24> I lowkey wonder how much memory is consumed, on average, by the extra string info in map-heavy languages like JS and Python, and how much CPU time is spent on strings there. While C doesn't need too many strings and mostly throws around numbers, a Node.js app may easily be dealing with thousands of them, not even counting HTML and templates.

(And now I also wonder if any compilers and VMs precompute hashes for map and object keys.)

<comment><USER25> Slightly related: Lua will intern every string ever created, that is two strings are equal if and only if their pointers (as represented internally) are identical. This results in slow string creation, but very fast equality checking and lookups, as it converts the problem to comparing integers.

</comment></comment><comment><USER26> Out of all the string types I have used, I think Go has the best of them. Since it's a GC'd language, you don't have to pay the refcount atomic overhead. The representation is two only words long. Strings are immutable, making them suitable map keys. Strings don't carry any encoding information; they are plain byte-arrays.

</comment><comment><USER27> This looks like good information about the memory representation, but we would be better off without string as a data type at all, at least not as a concrete type.

Strings as they commonly work are leaky abstractions which for decades have bred confusion among programmers over how to handle text properly.

 _Text /character encoding bugs are a matter of type safety._ I believe most of the text encoding bugs in the history of software could have been avoided if we used our type systems to handle text encodings explicitly.

UTF-8, UTF-16, UTF-32, Windows-1252, ISO-8859-1, US-ASCII, et al.; these should be our essential concrete data types. The concept of a string should just be an abstraction over them for polymorphism.

At no point in the lifecycle of a piece of textual data should there ever be any question over how it is encoded. So why don't we let our type systems do this bookkeeping for us?

<comment><USER28> I have written some programs dealing with Indic scripts, and when working with strings I prefer to see them only as a sequence of Unicode codepoints; it's a clean abstraction compared to the encodings which are messy (and half of them don't even support the scripts I care about).

While text is in memory inside your programming-language runtime, you don't care about the encoding; for all I know it may not even be one of those encodings. You only have to deal with encodings when dealing with the "external world": when you fetch (or send) bytes from (or to) disk / network / the user. These are anyway out of the scope of the type system, so the type system wouldn't help you: the encoding needs to be communicated to you out-of- band.

(See [https://nedbatchelder.com/text/unipain.html](https://nedbatchelder.com/text/unipain.html) for the "Unicode sandwich" approach: convert to bytes at the boundaries of your system.) So using a type system to specify encodings isn't really helpful; what a type system _can_ help you with is clearly distinguishing between bytes and text (separate types), and forcing you to specify an encoding when converting between them.

<comment><USER27> > _I prefer to see them only as a sequence of Unicode codepoints_

You can still have this with encodings as data types.

Encoding is definitely a concern at the boundary, but to say that it is a concern _only_ at the boundary is too simplistic. What if you want to save the cost of converting encodings from that which was input at the boundary? And at some point data will have to leave your application, and this often requires munging text in a number of encodings.

> _So using a type system to specify encodings isn 't really helpful_

Imagine an error at compile time when you accidentally try to append an ISO-8859-1 string to a UTF-8 string.

</comment></comment></comment><comment><USER29> > he only advantage of this representation is space efficency.

Not even close to true. Simplicity, future proofing are two more at least.

Reference to PDP-11 assembler is a furphy.

You only have two ways to store _anything_ at the lowest level: 1. length + data or 2. data with sentinel value.

If K&R chose option 1 we would have versions of strings with 8 bitlengths, 16 bit lengths, ..... all the while incurring a base load of inefficiency within any program. (In fact I'd warrant programs would use data+sentinel internally anyway.)

There are now many many "safe string" libraries for C. Use them if you like. The fact there are so many and get so little use tells you something.

Is length+data safer? It's easy to lie on the wire, so I don't think so. If much.

BTW, one way to provide future proof (length, data) format is to encode the length with UTF-style encoding. So the length field would have enormous range.

</comment><comment><USER30> This could be a good question for interviews. A good candidate should be able to come up with several solutions for implementing strings, and explain the pros and cons of each solution.

<comment><USER31> A good candidate for what?

I've been through enough interviews on both sides. The only thing that will tell you anything of importance is paying candidates to perform real tasks.

If doing algorithms on a whiteboard is part of the job; then sure, go for it. But I suspect very few of the really good coders out there would make much of an impression in that setting.

<comment><USER32> I think if you modify it to simply state that having a candidate think out loud about mechanisms for storing strings is a useful exercise in evaluating their problem solving ability, it's a pretty good idea.

I'm rarely concerned about the right answer in an interview, because those are generally searchable.

<comment><USER31> But it's still pretending, solving canned problems with right/wrong answers is not the same as doing the real thing. You'll get completely different behaviors out of most people. I wouldn't be surprised if plenty of whiteboard surfers and sweet talkers turn out to be less than ideal under pressure when there are no clear answers and no authority to back them up.

<comment><USER32> Thankfully I'm rarely hiring for positions where someone is developing software with a gun to their head.

</comment></comment></comment></comment></comment><comment><USER33> Perhaps you could include a comparison with BSTR implementation used extensively in Windows COM interfaces?

<comment><USER34> HSTRING (from WinRT) is probably more interesting at this point.

</comment></comment><comment><USER35> How do I store \0 in a C string?

<comment><USER36> And work with the standard library's string functions? You can't.

</comment></comment><comment><USER37> Go slices sound similar, though they are always mutable.</comment>


Why plan pricing is better than per user(unit) pricing - <AUTHOR> http://www.terlici.com/2013/02/28/plan-pricing-vs-per-unit-pricing.html

<comment><USER2> Not sure that makes sense as plan pricing would always cater for the higher expected number of users, so a company with 500 users would do well using a plan priced for 400 users but a company of 5 would face a higher cost.

Maybe a better model is for users over a set period rather than installs at any one time. So if for 3 months you had 50 installs, then the following you only had 40 you'd be billed for those numbers for each period.</comment>


iPhone XS – A12 Bionic - <AUTHOR> https://www.apple.com/iphone-xs/a12-bionic/ <comment><USER2> It was interesting to hear apple state that one of their goals for building products was to make them last longer in order to minimize waste. People often accuse hardware manufacturers, including apple, of intentional obsolescence. I am interested to see if they actually change anything about their process, software and hardware, to put any weight behind this claim, or if it is just marketing doublespeak.

<comment><USER3> Apple are already pretty good in this regard - their devices are expensive but made to last, and they directly support them for 4 or 5 years. The upcoming iOS release is supposed to be focused on getting better performance on old devices as well.

<comment><USER4> > their devices are expensive but made to last, and they directly support them > for 4 or 5 years

Do you think a $1,000+ phone lasting only "4 or 5 years" is really that good?

<comment><USER5> There's a big difference between how long a device is directly supported for, and how long it lasts.

Additionally many people would consider a laptop being directly supported for 5 years pretty good.

<comment><USER6> High Sierra supported 2009 Macs, but it looks like Mojave is going to be cut off at 2012.

</comment></comment></comment></comment></comment><comment><USER7> I wonder if Apple/ARM has now peaked in performance too (same as what happened with intel 4-5 years ago). "Up to 15% faster" is not noticeable outside the realm of benchmarks.

<comment><USER8> Unlikely

Apple/ARM is developing their processors for a very narrow power budget (mobile). While they have shown promise in benchmarks designed to compare their peek performance while mitigating thermal issues [1]. The long term consistent heat mitigation, and power draw limits consistent behavior.

Secondary performance gains from multi-tier caching (Apple does 2, Intel does 3, IBM does 4) and multiple channels of ddr which can greatly accelerate application throughput.

In short. Apple's processors are designed for mobile first, and ARM can still gain _a lot_ in terms of performance. While it is approaching compute/cycle of Intel's processors it isn't there yet.

[1] What I'm trying to say is don't link GeekBenchmark that what ever mobile process has >= the same number of BogoMIPS as a server class CPU. Geek Benchmark throttles hard on mobile doing burst testing to avoid thermal throttling, this effects the benchmark results negatively on server class computers (as the test doesn't generate enough load to kick up the core clock) and positively effects mobile (by avoiding dropping the core clock).

</comment></comment><comment><USER9> So, 80% of the ad is about augmented reality and applications?

I've never used any of that, we should have consoles for that.

The most thing I use my phone is for calling, sms, WhatsApp, Google maps and Chromecast.

I don't see me as an augmented reality user

<comment><USER10> There's not much point trying to sell on things everyone knows about and uses already.

<comment><USER9> It is the origin of iPhone..

Everyone knew how to call and use a smartphone browser ( eg. Nokia ngage )

</comment></comment></comment><comment><USER11> Say what you will about hardware and chipsets...the website is downright amazing.

</comment><comment><USER12> Wherefore art thou iPhone SE? :(

<comment><USER13> It's called the Xr now. Given the niceness of the phone with that small of a price tag (relatively small, of course), Apple's gonna leave the Xr alone for 3 years before they replace it with the next "flagship downgrade."

<comment><USER14> > It's called the Xr now.

The XR is bigger than the XS. The price point is not why the SE was so beloved (though it was probably a factor for many).

The XR is the new C, not the new SE.

<comment><USER13> That small size was certainly beloved by a subset, but I don't think Apple would have made the Xr so large if the SE's sales were good.

</comment></comment></comment></comment><comment><USER15> This looks like an interesting processor and 7nm sounds great, however since the process size became mostly a marketing term, is there a comparison of Apple's process sizes to that of GlobalFoundries and Intel?

<comment><USER16> > The Apple A11 Bionic is a 64-bit ARM-based system on a chip (SoC), designed > by Apple Inc. and manufactured by TSMC.

(source: [https://en.wikipedia.org/wiki/Apple_A11](https://en.wikipedia.org/wiki/Apple_A11))

So really you're asking for a technology comparison between TSMC, GF, and Intel.

Related to that, one should note that GF stopped pursuing 7nm. [https://semiengineering.com/gf-puts-7nm-on- hold/](https://semiengineering.com/gf-puts-7nm-on-hold/).

</comment></comment><comment><USER17> Remember a year ago when the notch was going to be Apple's downfall? I don't think I've seen a single person mention it being on the phones announced today.

<comment><USER18> It doesn't hurt that many flagship Android phones have similar notches now. The new phones have similar sizes to the prior years models, but larger displays overall. Consequently, the notches don't have much impact. The notches (in practice) are less annoying than most detractors had anticipated.

<comment><USER19> All Android phones (with notches) have notches _in addition to_ an ugly chin. The lack of other bezels is what made the notch on iPhone X acceptable (to me, at least). The thought of a notch _with_ a chin (or worse, a forehead, or both) is frankly irritating. Xiaomi probably did the best job building a near bezel less phone with their Mix lineup — except for the front camera. If Android phone vendors can't work an iPhone X like display (no chin), why not just build phones with a narrow forehead and no chin? The forehead could be used for display connections and camera, sensors, speaker etc. Even a Galaxy Note 8 like design (narrow chin and forehead) would be preferable to this madness. Alternatively, they could do what Xiaomi did with Mix lineup.

<comment><USER20> Some have notches and a chin some do not, just as some are completely edge to edge with no chin with a pop out camera and in screen fingerprint sensors.

</comment></comment></comment></comment><comment><USER21> I guess that if the current pricing trend holds, in 2030 the top iPhone will cost like a small hatchback.

<comment><USER22> If the rumors are to believed, in 2030 the top iPhone might _be_ a small hatchback.

</comment></comment><comment><USER23> Did they consider that some people might call this iPhone Excess?

</comment><comment><USER24> Really, they went with "XS" for the biggest phone yet?

<comment><USER14> It's actually XS Max. Like pepsi.

XS is the smallest of the three phones announced today.

<comment><USER25> No, it is the same size as the XR.

<comment><USER14> It really is not. The XR is quite a bit bigger (150.9x75.7x8.3mm versus 143.6x70.9x7.7mm) and with a bigger (6.1" versus 5.8") but lower-quality screen (326 DPI LED w/o 3D touch versus 458 DPI OLED w/ 3D touch).

</comment></comment></comment></comment><comment><USER26> as designs shrink to 7/5nm and beyond, quantum effects are emerging as a more widespread and significant problem, and one that ultimately will affect everyone working at those nodes. [https://semiengineering.com/quantum-effects- at-7-5nm/](https://semiengineering.com/quantum-effects-at-7-5nm/)

</comment><comment><USER27> I find it fascinating how Apple delivers 7nm processors, while reportedly Intel is struggling with 14nm and delaying 10nm.

<comment><USER28> TSMC

</comment></comment><comment><USER29> "Apple-designed GPU" eh, this'll be interesting.

<comment><USER10> That started with the A11.

</comment></comment><comment><USER30> can anyone do a brain dump on the ML part of the chip?</comment>


Why SurveyMonkey is holding off on an IPO - <AUTHOR> http://tech.fortune.cnn.com/2013/01/17/surveymonkey-ipo/

<comment><USER2> "And yet, SurveyMonkey [...] has two reasons for raising capital. One is to reward the investment firms, Spectrum Equity and Bain Capital, that bought the company just over four years ago, when it was about a fourth its current size. The other is the perennial tech-industry rationale for an IPO: so SurveyMonkey's employees can sell some of the stock that is a significant portion of their compensation."

Honestly, for me as an occasional stock investor that sounds like a serious warning signal. Why should I invest in a company that does IPO only for some people to do exits? (which was exactly the reason FB did IPO) Stock investors are looking for growth potential. It's just a conflict of interest.

<comment><USER3> Every time you buy stock someone else is selling it. That does not mean it's a bad buy, just that the seller has different priorities.

<comment><USER4> For example: "I've got 100% of my wealth locked into one investment, my SurveyMonkey equity, and I'd like to have a more balanced portfolio, so I'll sell half, no matter how much I believe in this company." Seems pretty rational to me.

</comment></comment></comment><comment><USER5> I am amazed they did so well. Good execution. I like the new building they are constructing in Palo Alto as well.

<comment><USER6> I'm also amazed how well they are doing. Do they have some kinda online survey patent or do competitors just suck that much?

<comment><USER7> Chalk me up as dumbfounded as well. How you build a business model upon something so simple, easy to replicate, and (to me) value-less is a mystery.

<comment><USER8> Why do you see user survey's as value-less? Being able to gather and analyze information from a group of people is a great value.

<comment><USER9> Not the person you asked, but I am always consistently surprised at the success of survey monkey. I was a paying customer for two years though, mostly for reasons of replicibility. Many, many, social scientists use it, even though it doesn't really support useful things like randomisation to entirely different surveys.

The interface is nice, and they appear to have sewn up the marketing world, so well done to them. I still want to build a much better version, but I'm not sure if there's a market for it.

<comment><USER10> I know this might seem kind of silly but isn't the success of survey monkey a sign that there is a market for what they offer? Unless there is something I'm missing, kind of like there are markets for medicine and the system could use improvement but there are major roadblocks to overcome (in this case I don't know what it is which is why I ask).

<comment><USER9> Well yes and no. My idea is a little different, but I'd need the SM crowd to be able to have enough revenue to build it, so my worry would be that I wouldn't be able to get enough people to allow me to work more on developing the part that I'm _sure_ there's a market for.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> maybe all these lenders/investors are interested in buying access to Facebook. Survey Monkey CEO is married to Facebook COO.</comment>


X Without Y - <AUTHOR> https://medium.com/@futurist/x-without-y-bbae9964c890 <comment><USER2> Dupe: [https://news.ycombinator.com/item?id=12116727](https://news.ycombinator.com/item?id=12116727)

<comment><AUTHOR> oops didn't realize someone posted my story before me, please merge or delete this post

</comment></comment><comment><USER3> > X Without Y

X = software, Y = human programmers = "software without programmers" AI?</comment>


B-Heap vs. Binary Heap (2010) - <AUTHOR> https://queue.acm.org/detail.cfm?id=1814327 <comment><USER2> A great reminder that spatial locality can be critical to performance. But that's actually quite well-known, and maybe a more important lesson would be: don't take performance for granted, even in standard libraries of well stablished languages or algorithms, there might be much room for improvement for your use case (if you need it).

This said, the article feels quite arrogant. As other commenters say, the idea behind the optimization is nothing new, just some basic concepts well applied. Which is a job well done, but probably doesn't justify the tone (that at least I perceive) from the article.

<comment><USER3> I find it interesting that he is really concerned with page-faults as opposed to cache misses. Most of the recent stuff I've read on performance focuses much more on the cache.

Usually, I've seen using swap-space met with derision. I'd only expect page- faults to really happen when using a memory-mapped file. Again on the note of caches, I'd expect more fanfare be made regarding the TLB when accessing a different page than actual page-misses.

<comment><USER4> The internal caches of the CPU are orders of magnitude faster than handling a page fault (which means: CPU traps, switch to kernel, VM lookup, issue I/O request, block for completion, switch to user).

TFA's context is a larger-than-memory data structure mapped from disk, where heap block size = page size.

</comment></comment></comment><comment><USER5> It's pretty much the same reason why databases use B-trees and not binary trees --- when you have to consider the nonuniform latency of storage access, traditional algorithmic analysis that assumes every memory address is accessible in the same time as any other becomes extremely misleading.

<comment><USER6> Every memory access could be limited with some big enough number (just assume that there's no cache in your CPU), so traditional analysis is fine. People usually don't like that memory access is so slow, it's another matter. O(N^2) might be faster than O(NlnN) if multiplier for the latter algorithm is bad enough.

</comment></comment><comment><USER7> I agree with his rant about "CS departments' algorithmic analysis" failing to cover these real-world hardware issue. That was certainly true of my ~1997 undergrad CS course at the University of St Andrews, that was otherwise exemplary.

The only thing I don't understand is why his data structure for finding the least-recently-used item wasn't just a linked list - where each time you touch an object you move it to one end of the list, and when you want to discard an object you remove from the other end. That'd be o(1) and would cause, at most, one page fault per update and none for the add and remove cases (since the two ends would surely be paged "in"). And it'd be a lot easier than his fancy thing. I guess I missed something.

It might be worth pointing out that NVMe or Intel Optane would solve his problem (1) without his fancy data structure too. Some might go as far as to say that while his fancy data structure is out dated now, the stuff that the CS departments teach became correct again. Maybe St Andrews had the right idea all along.

1) Or huge-pages or NUMA node pinning, to some extent.

<comment><USER8> > I agree with his rant about "CS departments' algorithmic analysis" failing > to cover these real-world hardware issue.

I disagree. CS algorithms is about the logical/mathematical understanding of algorithms. If you want to understand hardware implications, you are generally taught that in an comp architecture class. Blaming algorithms class for the lack of consideration for real world hardware issues is like blaming the computational class because the turing machine doesn't factor in hardware issues. You abstract it out to make general logical observations.

<comment><USER9> I disagree. It should at least cover what aspects should be considered when designing an algorithm for use in the real world. You dismiss the entire field of experimental algorithmics as if it were nothing more than a bunch of algorithmicists who know some computer architecture things, but there's a lot more to it.

I'm not arguing against teaching classical algorithm design and analysis, they're both incredibly important imho. But we should stop ignoring the shortcomings of the models used, hand-waving them away with "the rest is just a bit of engineering". It's not.

</comment></comment></comment><comment><USER10> A similar but more sophisticated use of this was Intel Research's seminal paper on FAST tree (index). Also from 2010.

[http://www.webislands.net/pubs/FAST__SIGMOD10.pdf](http://www.webislands.net/pubs/FAST__SIGMOD10.pdf)

</comment><comment><USER11> Past discussions:

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

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

</comment><comment><USER12> If anyone wants to read more, there are (pre this article) papers on cache friendly/oblivious priority queues, e.g.

[http://erikdemaine.org/papers/BufferTrees_STOC2002/paper.pdf](http://erikdemaine.org/papers/BufferTrees_STOC2002/paper.pdf)

The rough gist is that if the only thing you need to be able to do is insert and pop-min, then you can buffer up roughly a page's worth of incomplete work for each page, getting amortized performance that tracks the optimal number of cache transfers at each level of the cache.

Further, in the paper above you are introduced (in the related work) to the citation:

"A. LaMarca and R. E. Ladner. The influence of caches on the performance of heaps. Journal of Experimental Algorithmics, 1, 1996."

which describes the author's "B-Heap" (at least, it describes a b-ary heap where you pick b to match your cache line/page size).

I'm guessing the problem isn't that academics don't understand these things so much that practicing programmers don't always read very much.

</comment><comment><USER13> > ..., not to mention wasting enormous amounts of hardware and electricity.

I wonder how legitimate this concern is from an environmental angle. On one hand a lot of code in the world probably has much worse performance ratios than than the one described in the article -- using python is sufficient to cause an order of performance loss. On the other hand data centers are using more renewable energy sources and reducing their carbon output.

Is this only a wasted money problem? How worth while is it to write "green code"? Back of the envelope calculations on how much developer comfort costs would be interesting.

</comment><comment><USER14> I had a quick question about this part: """ Two details are worth noting:

* Once we leave a VM page through the bottom, it is important for performance that both child nodes live in the same VM page, because we are going to compare them both with their parent.

* Because of this, the tree fails to expand for one generation every time it enters a new VM page in order to use the first two elements in the page productively. """

Is the point just that you want to pack 8 elements into each page, but if the tree expands the first generation of a page, then you end up only being able to pack in 6?

</comment><comment><USER15> Binary Heap was always my favorite data structure because of how it would improve my A* pathfinding performance. Guess I should have used B-Heap.

</comment><comment><USER16> Despite the arrogance, I would be more interested if there were some more mathematical oriented explanation and/or a self-contained code sample like for example the TinyQueue javascript implementation (any language is welcome though.

</comment><comment><USER17> Do I understand this correctly: to optimise for virtual memory, do the things you'd do to optimise for the CPU cache except on a larger scale?

<comment><USER4> Yes. Because virtual memory is backed by a cache (the page cache); so optimizing algorithms to be "more cache friendly" works.

</comment></comment><comment><USER18> There is a joke inthere about economics but i cant think of it right now

<comment><USER19> Care to explain further? I am genuinely interested in the reference.</comment></comment>


Experiment - living below the poverty line in India - <AUTHOR> http://www.thehindu.com/opinion/columns/Harsh_Mander/article2882340.ece

<comment><USER2> Interesting, I wish we could read more about their experiment - there doesn't seem to be much content really.

For those who are wondering: The conversion rate is ~45 rupees per dollar. So when they tried to live at the poverty line, 26 rupees a day, that is roughly $.50 per day. Pretty nuts.

<comment><AUTHOR> Yup, I wish they had been able to journal/tweet/blog their experience. This is groundbreaking work in India. I have heard of people "experimenting" with being homeless or poor in the USA but it's much more daunting in a third world country.

</comment></comment><comment><USER3> Amazing story! one has to experience this to know what it really means. Hats off to these 2 guys!</comment>


mJS – A new approach to embedded scripting - <AUTHOR> https://mongoose-iot.com/blog/mjs-a-new-approach-to-embedded-scripting/ <comment><USER2> 25k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language's compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM.

How's the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through FFI, what's the benefit vs. e.g. C++11? The latter has nice language features too but compiles to much smaller native code!

<comment><USER3> Ideally none of the flash space is spent on a parser/compiler, that's quite wasteful if you could compile bytecode offline.

I don't know if you can do that with mJS, alas.

<comment><USER4> If you want to support eval, then the whole parser/compiler needs to be on the device.

But do you really need eval?

</comment></comment></comment><comment><USER5> That FFI interface looks _way_ nicer than the node-ffi interface.

        let f = ffi('int gpio_write(int, int)');

vs.

        var current = ffi.Library(null, {
          'atoi': [ 'int', [ 'string' ] ]
        });

<comment><USER6> You could probably write a wrapper to go from the node way to their style.

</comment></comment><comment><USER7> This looks a lot like Lua's FFI interface[0], which is a compliment (but contradicts the statement that this sort of FFI is "the feature that no other engine implemented so far"). Nicely done.

[0] [http://csl.sublevel3.org/post/luajit- cpp/](http://csl.sublevel3.org/post/luajit-cpp/)

<comment><USER8> Nice! I wasn't aware of lua ffi api, thank you!

</comment></comment><comment><USER9> Is this a re-packaged v7 [0] (it's from Cesanta as well)? mjs.c is 477K. It looks like it as v7.c is 475K [1]. It shaves whole entire 1MB from my staticly linked builds (v7 1.9MB vs. mjs 998K), and almost 2MB from dynamically linked builds (v7 1.9MB vs. mjs 99K) on amd64. If it shares the same underlying architecture and api [2] then this is a pretty great achievement.

In their docs, they claim 25K storage and 10K RAM. Blog post claims 25K storage and 1K RAM.

[0] [https://github.com/cesanta/mjs/blob/master/mjs.c](https://github.com/cesanta/mjs/blob/master/mjs.c)

[1] [https://github.com/cesanta/v7/blob/master/v7.c](https://github.com/cesanta/v7/blob/master/v7.c)

[2] [https://docs.cesanta.com/v7/master/#/v7-internals/](https://docs.cesanta.com/v7/master/#/v7-internals/)

<comment><USER10> i wonder if the size could be reduced by replacing the yacc code with a hand- written parser.

<comment><USER8> There is no yacc code in either V7 or mJS.

V7 uses hand-written recursive-descent parser. Initially, it was using ordinary C functions, and that created a problem on systems with low stack size. E.g. each '(' starts statement parsing from the top, so 1 + (2 + (3 + (4 + 5))) consumed stack, and sometimes resulted in stack overflow in e.g. interrupt handlers or network callbacks.

Therefore we have rewritten recursive descent using C coroutines, and that is extremely sophisticated piece of work. See [https://raw.githubusercontent.com/cesanta/v7/master/v7.c](https://raw.githubusercontent.com/cesanta/v7/master/v7.c) , search for #line 1 "v7/src/parser.c"

mJS on the other hand uses lemon parser generator - the one from sqlite project. It generates a LALR parser which is quite efficient in terms of memory.

<comment><USER9> So it is API compatible with V7?

<comment><USER8> Nope. It's similar though, cause some of the concepts, and the code, were reused. mJS does not need an embedding API, really. The intent is that FFI is used.

</comment></comment></comment></comment></comment><comment><USER11> I've never worked with embedded systems, so forgive my ignorance. Why is this any more useful than just writing c code, if all the code that actually interacts with the hardware has to be written in c anyway?

<comment><USER8> The ability to script without the need of rebuilding/reflashing the whole firmware is often fairly useful. The most value is not in JS per se, but in the ability to script.

<comment><USER11> Ah, I can see how that is useful. Way up in the web dev world I don't often have to think of things like that :)

</comment></comment></comment><comment><USER12> > One common thing these projects share is an attempt to implement the whole > language specification, together with the more or less complete standard > library

Not in the case of Lua. Well, the "whole language" part is correct, but Lua is a very tiny language spec. It's "standard library", however, is the opposite of "complete".

<comment><USER12> > none of the popular scripting languages have been designed for the embedded > environment in the first place

Also false for Lua. It is designed to be embedded.

<comment><USER8> Embedded environment in this context means hardware low on resources, e.g. microcontrollers. Your perception of that word is "embedded into the C/C++ program". These are two different things. I agree that Lua (like some other languages) were designed to be embedded into C/C++ apps.

<comment><USER13> Something like this? [http://www.nodemcu.com/index_en.html](http://www.nodemcu.com/index_en.html)

</comment></comment></comment></comment><comment><USER14> So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support?

Why is there so much stigma against _learning_ to code in something other than $favlang these days? Most hard core developers I know appreciate the importance of using the right tool for the job, I don't see embedded/desktop developers shying away from using whatever the native toolkit/language is for their chosen platform and instead shoehorning $x to fit as much as we see this constant trend to try to use "web tech" everywhere. (Scripting in embedded systems has long been a solved problem: use lua.)

<comment><USER15> For example, I'm working on a dashboard for wifi routers that displays information beyond what is provided by OpenWRT's ubus system. We're get this information from the kernel, but it needs to be converted to JSON to be consumed by the dashboard frontend. Right now, I'm converting the information to JSON using Go, but there are some platforms that Go can have problems compiling binaries for. We have also written a lot of C for these routers, but doing this kind of thing in C would just be overly cumbersome. Shell could be an option, but it is also cumbersome. Lua could be an option, but I don't know much about it and I don't know how well it supports JSON. Most other developers that will work on this don't know much Lua either.

mJS might also be an option. I don't really see what's wrong with that if we have the space for it.

This can probably get types from Flow, since it is valid es6. Flow has no compilation step or runtime component.

You may have a point about the debugging, but JS is pretty easy to debug by printing to stdout.

<comment><USER16> Lua is the easiest language to learn I ever saw. It has a fantastic json support with the cjson library ([https://luarocks.org/modules/luarocks/lua- cjson](https://luarocks.org/modules/luarocks/lua-cjson)). It's there by default on many firmwares. Do check the docs for nodemcu, for example: [https://nodemcu.readthedocs.io/en/master/](https://nodemcu.readthedocs.io/en/master/) (a firmware for the ESP microcontrollers)

Not to mention Lua itself can be used as a data / configuration language, their tables syntax is made especially for that. Normally when I work with Lua I don't feel the need to embed any other parsers for configuration, but cjson is there if you want.

</comment></comment></comment><comment><USER17> Neat. Although languages which are "almost, but not quite <x>" are, I would say, harder for people who know <x> to learn than languages that are entirely different from <x>.

</comment><comment><USER18> As light weight, easily embeddable JS engines go, I'd like to mention Duktape[0]. But the FFI of mJS does look quite a bit nicer.

<comment><USER8> Duktape is nice, and I've mentioned it in the article. However it's quite fat, and can't be used on some boards like ESP8266. It's flash footprint is Megabytes, whereas mJS flash footprint is ~25k.

<comment><USER19> Duktape website:

"Embeddable, portable, compact: can run on platforms with 192kB flash and 64kB system RAM"

<comment><USER20> Also [http://www.esp32.com/viewtopic.php?t=497](http://www.esp32.com/viewtopic.php?t=497)

<comment><USER8> Ah, thanks, wrong about flash footprint. Neil has done a great job adopting Duktape on ESP32.

</comment></comment></comment></comment></comment><comment><USER21> Taking this example:

        let malloc = ffi('void *malloc(int)');
        let mem = malloc(10);

How do you manipulate that memory?

How can you do the following in mJS?

        int* mem = malloc(10);
        mem[0] = 3;
        mem[1] = 7;
        mem[2] = 12;
        int *rest = mem + 3;

There are some things you can do in C without functions. How does mJS achieve this?

<comment><USER8> Currently, mJS FFI is limited to functions only. And, to simple enough functions.

On how to access memory from mJS: write an accessor function!

        // C
        void setmem(uint8_t *ptr, int index, int value) {
          ptr[index] = value;
        }

        // mJS
        let setmem = ffi('void setmem(void *, int, int)');
        let malloc = ffi('void *malloc(int)');
        let mem = malloc(10);
        setmem(mem, 3, 5);

</comment></comment><comment><USER22> This is neat. This isnt quite javascript (which is neither good nor bad) but I think has a lot of potential

</comment><comment><USER23> Espruino's had an FFI interface for the last 3 years! Nice to see they did their research :)

<comment><USER8> Hi Gordon! Nice to meet you :) I am the author of the article, and I am quite fond of Espruino, it's a great project. Wasn't aware that Espruino has FFI API!

<comment><USER23> Hi! Thanks, v7 looked great too. mJS looks like a good idea - IMO it'd be nice to standardise a sane, minimal subset of JS that can be easily implemented - it'd be a huge help for all the developers of embedded JS interpreters, and could potentially be targeted by transpilers too.

</comment></comment></comment><comment><USER16> Worth mentioning: [https://github.com/elua](https://github.com/elua)

Allows to run Lua on bare metal, no OS involved. It's what the nodemcu firmware for the ESP cards is based on.

</comment><comment><USER24> Seems a little crazy that there's no support for closures.

<comment><USER8> Yes. Closures add quite a bit of complexity and footprint. Anticipated use case was a short script that orchestrates the device logic, calling existing SDK functions.</comment></comment>


Periscope Is Secretly Building an Apple TV App - <AUTHOR> http://techcrunch.com/2015/09/08/periscope-apple-tv/ <comment><USER2> "Apple wants the Apple TV to do things that other set-top boxes from Amazon and Roku can't. That means getting developers to take advantage of potential hand-off or multi-screen options afforded by iPhones and iPads also running on iOS."

I'm not certain about Roku, but I remember reading when Amazon launched their TV box they had first party launch titles that had Kindle Fire companion apps, although those aren't technically "iPads."</comment>


SF Sends Cease-And-Desist To Apps Selling Public Parking Spots - <AUTHOR> http://techcrunch.com/2014/06/23/parking-apps/?ncid=fb&utm_source=feedburner&utm_medium=feed&utm_campaign=fb&utm_content=FaceBook

<comment><USER2> I would love to have this go to court. If I have just parked my car and am standing there and someone says "Hey, here is $10 if you move your car and let me part there." I would be tempted to take it. This is what the App automates. So how do you get from incentivizing someone to move their car, to a 'lease of public parking spots' ? That is the legal theory I'd love to hear presented by the City Attorney.</comment>


True Fakes on Location: World-Building, Hollywood-Style - <AUTHOR> http://thebaffler.com/salvos/true-fakes-carson <comment><USER2> _Intolerance_ (1916) is in the public domain the in USA.

The first appearance of the "Babylon" set: [https://youtu.be/SoaF8_dlqQA?t=18m8s](https://youtu.be/SoaF8_dlqQA?t=18m8s)

"Belshazzar's Court": [https://youtu.be/SoaF8_dlqQA?t=1h41m51s](https://youtu.be/SoaF8_dlqQA?t=1h41m51s)

</comment><comment><USER3> Hollywood has gone too far with CGI. Most action films and especially comic films are unwatchable to me. Perhaps my eye for detail is above the average moviegoer. But that's why I especially enjoy Chris Nolan's films, he abhors CGI and you see it in the results.</comment>


Google Messages trick enables RCS on any Android phone and carrier - <AUTHOR> https://9to5google.com/2019/10/26/enable-rcs-android-messages/ <comment><USER2> There's a public RCS chat Group with people from over 20 different countries!</comment>


Fear and Loathing in Lock-Free Programming - <AUTHOR> https://medium.com/@tylerneely/fear-and-loathing-in-lock-free-programming-7158b1cdd50c <comment><USER2> I agree with this, mostly.

Sometimes the lock free version of a Java program is simpler than the version with locks. For example, I've often written classes where all the state was easy to fit into a single atomicreference.

The real danger comes from writing a lock free program without knowing they type of problems that are hard to solve without locks. Just like cryptography, the greatest danger comes from engineers who know just enough to be dangerous.

</comment><comment><USER3> Lock free systems are often worth the effort. A classic example is the operating system thesis done by Henry Masslin. [http://web.cecs.pdx.edu/~walpole/class/cs510/papers/06.pdf](http://web.cecs.pdx.edu/~walpole/class/cs510/papers/06.pdf)

</comment><comment><USER4> What is the state of the art in building high assurance lock free components? Are there type systems or proof assistants that are workable?

<comment><USER5> SPIN is a nice tool for modeling them. You can extract code from a coq model. You can go into the world of dynamic instrumentation to try to verify invariants in implementations.

</comment></comment><comment><USER6> we were somewhere around a race condition, at the edge of frustration, when the drugs began to take hold...</comment>


Show HN: Tool for pinpointing circular imports in Python - <AUTHOR> https://github.com/bndr/pycycle <comment><AUTHOR> Hey guys, author here.

This is my weekend project, I just decided to fix a pain point that new python developers usually have. This utility helps identify where the ciruclar import is.

issues/pull requests welcome!</comment>


10 things your IT guy wants you to know. - <AUTHOR> http://www.javameblog.com/2007/08/10-things-your-it-guy-wants-you-to-know.html

<comment><USER2> I've seen this around before - but basically this article is a good example of how _not_ to communicate to users... The tone is wrong, it's condescending and it's elitist...

If you take that blog entry, and instead of being the IT guy - imagine this is a Doctor... You'd be appalled if this was "10 things your Medical guy wants you to know".

<comment><USER3> It's frustrated comedy. I'm sure doctors have a "10 things we want our patients to know" inside joke about us, too.

<comment><USER4> But they probably do a better job of saving it for when they're talking with other doctors, rather than posting it on the internet where _everyone_ can see it.

Also: Spending most of your time complaining about how stupid users are, etc., makes it a lot harder to empathize with them and not sound like a standoffish IT guy. (Most people are probably not as good at compartmentalizing as they believe.)

If memory serves, _Time Management for System Administrators_ (<http://oreilly.com/catalog/9780596007836/>) has a good chapter about how to be helpful and reasonably polite with non-technical people when you're being constantly interrupted and the server closet is on fire (with an emphasis on little things that _show_ you're actually trying to fix things and not just blowing people off, since many people won't necessarily recognize e.g. scowling at firewall logs as working on their problem).

"Frustration comedy" is a good term, by the way.

<comment><USER5> Quality of the article aside...."But they probably do a better job of saving it for when they're talking with other doctors, rather than posting it on the internet where everyone can see it." Huh. Thing is, they didn't put it up where "everyone" could see it. Not even YCNews can do that. They put it up where "anyone" that found it could see it. Which is kinda part of the idea of an internet, isn't it? Otherwise how would they share it with other "techies"? (Or doctors or whoever) Well, some subsets of everyone won't find my post worthwhile so... I shouldn't allow it to exist? Seems like that would rule out all content ever, more or less.

Of course, beyond that, I suspect we need to have more inter-discipline discussion where techies and doctors can come to understand one anothers gripes in the search for a "better way"... but I don't know how well that could ever really work given human nature.

<comment><USER4> > They put it up where "anyone" that found it could see it. Which is kinda > part of the idea of an internet, isn't it? Otherwise how would they share it > with other "techies"?

Agreed. "Anyone", rather than "everyone". (I tried different phrasings about how, unlike doctors, "techies" are likely to communicate semi-publicly on the internet, but I stumbled with words and decided the other aspect was a more important point to make.)

And about inter-discipline discussion, absolutely. It's often difficult, but very necessary.

</comment></comment></comment></comment></comment><comment><USER6> By the author's admission, this was apparently reposted without permission. As he doesn't mention any license permitting his posting, I get the uncomfortable vibe of content theft.

</comment><comment><USER3> Now why won't my boss let me put this on the support page? :)</comment>


Indoor ax-throwing / beer-drinking range to open in Greater Boston - <AUTHOR> http://www.bostonglobe.com/business/2018/01/11/you-soon-able-throw-axes-while-drinking-beer-somerville/YKMYdJVsoWBw5IqPsG5OdN/story.html <comment><AUTHOR> When asked for comment, a rep for Vikings' Local 12th denounced the move as "wreckless, even by our standards."</comment>


Fedora 25 Released - <AUTHOR> https://fedoramagazine.org/fedora-25-released/ <comment><USER2> This will unlikely work with NVidia's native drivers straight out of the box.</comment>


Ask HN: How many applications do you get when you post in whoishiring? - <AUTHOR> <comment><USER2> It's probably very variable, but I'm also curious how many responses the people posting to get hired are getting.

</comment><comment><USER3> We get a handful when we first post, and a couple trickle throughout the month afterward.

</comment><comment><USER4> Last time we posed something (freelance dev deposition) we got about 4 applications . 1 with no qualifications , 2 with unrealistic hourly rate , ... And one who we hired and working with since.

</comment><comment><USER5> Posted for a unicorn specialist-generalist in NYC, was pleasantly surprised to get one applicant (who didn't pan out).

</comment><comment><USER6> We got 8 for a remote-friendly frontend dev position.</comment>


Why I Quit Ordering from Uber-For-Food Startups - <AUTHOR> http://www.theatlantic.com/technology/archive/2015/11/the-food-delivery-start-up-you-havent-heard-of/414540/?single_page=true <comment><USER2> The author's condescending tone is not sufficient to disguise this long advertisement for Josephine, another app whose business model asks us to pretend that laws don't exist.

<comment><USER3> Yeah, I'm baffled as to how this is legal. Surely there's no way to ensure food safety.

<comment><USER4> Yep plus it involves lots of customer traffic into neighborhoods not zoned for that, and neighbors will start to notice.</comment></comment></comment>