Are techies really 57% more likely to apply for a job if they know the salary? - <AUTHOR> http://hackajob.co/blog/displayed-vs-competitive-salaries/ <comment><USER3> "Competitive" really means "market"

"Market" means "below market"

Thus "competitive" means "below market" :-)

Here are some reason's not to list salary:

(a) You're afraid of scaring off good people before they even hear your pitch.

(b) You aren't paying the rest of your team at true market and if they saw the ad they might ask for raises or get pissed and leave.

(c) You don't want to attract people who are in it for the money. (But it's OK for the company owners to be revenue driven of course.)

(d) You want to hire an "A" player who is more expensive than the "B" players you have and you don't want to explain it to your "B" players.

As they grow, companies tend to optimize for mediocrity - "We can't pay $X for someone really valuable because it would upset the (good but) less valuable team members."

<comment><AUTHOR> a-d are all valid points, and (c) is certainly one crux when it comes to listing a higher-paying jobs - is listing 'competitive' the only way of combatting this (what about the application process finding the most compatible skill-wise, person-firm fit-wise, etc)?

<comment><USER3> It's very easy for me to be critical when I haven't faced the very real problems that hiring companies face but I think there is some justification for being skeptical of an employers true motivations.

Just thinking out loud; what does it _really_ mean when a company doesn't want to attract someone who wants to get paid a lot?

Does it mean that they are afraid of getting "spammed" with applicants that they have to weed out in the interview processes?

Does it mean that they want to select for people who won't ask for what they are worth i.e. someone they can get at a bargain?

Something else?

<comment><AUTHOR> I think both followup questions are valid. As others have mentioned in addition to yourself, there is wariness of companies' intentions, which ties into getting someone for less/value/than what they're worth.

On the flip side, case may be they genuinely can't afford to pay as much - <USER2> potential applicants may be swayed if they trust in them, and choose to forgo a higher salary or accept other compensation methods or benefits.

<comment><USER3> Ah, I think I see the problem now.

Company "A" pays less but actually offers a higher total happiness level, lets call it "quality".

Company "B" pays more but is has a lower "quality", all things considered.

Applicants are going to tend to apply to Company B because salary is a simple metric that doesn't have to be explained. Company "A" needs to educate their applicants/"consumers" in order for the applicant to see their value proposition - and that is something that is hard to do in a job ad.

This sort of thing is very common in the retail market. For example, (in the U.S.) if you are under 30 you probably have never even seen a quality shovel. Good luck finding a shovel today that you can use without wearing gloves.

</comment></comment></comment></comment></comment><comment><USER4> Especially when "the first stage of our selection process is a 90 minute online coding test".

You expect me to do that when I know very little about the job and don't even know what I am going to be paid?

<comment><AUTHOR> That's a fair enough comment, job application processes are getting longer and more time consuming - sometimes out of need for getting the right people.

Any ideas as to why salaries might be left as something broad like 'competitive'?

</comment></comment><comment><USER5> Defining your salary as "competitive" is worthless since everyone does it (although I saw a job description with "salary: decent" once :) ).

Clearly, being open about the salary gives you a big advantage, applicants know what they can expect and are more willing to spend time going through your interview process. When dealing with recruiters, I only answer their cold email if the salary is listed (among location, company name, tech stack).

One note of caution: if you advertise a range (e.g. 90k to 120k) you should have clear criteria in mind to decided what to offer in your range. As a candidate, I would want to understand why I'm offered 95k instead of 110k for example.

<comment><AUTHOR> 'Decent' is brilliant haha! :) Not seen that one yet. Your modus operandi, and note of caution are also spot on IMO.

Transparency (not just on salary, but role/skill expectations too) would appear to build trust. What can firms that can't offer as much do, do you think?

<comment><USER6> Heh, "Decent" is more likely to make me apply than "Competitive" because it shows that they know what good developers cost and are acknowledging they're not paying top rate.

<comment><USER5> I don't think "decent" is any more meaningful than "competitive". Based on my experience, "competitive" has proven to be sometimes way below market value, I don't see why "decent" would be any different.

Some companies have no clue what "competitive"/"decent" really is, some do but are just trying to find someone to milk for cheap.

<comment><AUTHOR> 'Decent' could have a connotation of 'good' (though that depends on the source, and the location targeted) - it's in my vernacular, but would agree, it can certainly be offputting, and a case of your second point - milking for cheap.

How might companies tackle the issues some have listed here of displaying salaries, while not deterring people (assuming they're being fair, not exploitative).

</comment></comment></comment></comment></comment><comment><USER7> I take the term competitive as you will compete with the surrounding market for my particular skillset and what I bring to the table. Salary bands lead me to believe that you want to fit me into a box regardless of what I can do. For example, 115-125k for a job description asking for senior responsibilities means top talent at your org is at 125k. I would be naieve to think your internal employees never read your posted openings. So to save everyone feelings and make things "fair" you post a range. If you are looking for the best you should be willing to "bid to play" and post it as such.

<comment><AUTHOR> Great point re: salary bands, and existing employees reading listed job openings.

Each side of the bands/'competitive' debate has +/-s for sure. By 'bid to play' do you mean a 'race to the bottom' sort of thing re: salary/compensation?

<comment><USER7> I'm not clear on what "race to the bottom" is implying to in this particular sense so excuse me if I fail to properly answer your question. What I mean by "bid to play" is lets say Google and Apple are looking for the same developer and located within the same general vacinity of each other. After going through both interviews, one is willing to pay me $125k and other $130k. Their predeterminded budget number. My current skillset is greater than what the job description is asking for. With such both orgs should be open to discussing going above the 125 or 130 slighly so I can join the team because the ball is favorably in my favor. What I'm refering to is there should be an open door there for this to happen. Seeing the word competitve or open implys to me that the negotiations are open for the right person. Hence why they do not advertise salary on their postings. They're attempting to attract the best talent possible. A range stops that from happening because you are not willing to "bid to play".

<comment><AUTHOR> Ah sorry, I've muddled myself somewhat with 'bid to play.'

But what you've said here would be appropriate when it comes to the best in their fields. And not just with salary (other compensation, care packages, etc). But would 'competitive' be less appropriate than something like 'negotiatiable?'

<comment><USER7> I would not say less apporpriate. I view both as equal. My example does not have to refer to the best in their fields. I just used that as the best case example to prove a point. It can refer to any level(jr., mid., sr., etc.) of qualified talent.

</comment></comment></comment></comment></comment><comment><USER3> Let's flip this around, suppose a lot of applicants started waiting until the end of the interview process to mention that they only expected to work 35 hours a week but made up for it by "being really fun to work with".

Do you think that hiring companies would start wishing that applicants would put that information right up front in their resume or cover letter?

How would a company interpret applicants coyness about revealing this bit of information (a) "Awe shucks you got us!" OR (b) "Hey, you tricked us and we assumed you meant 40 hours a week."

</comment><comment><USER8> 200% yes. I've got better things to do than go through the whole recruiting cycle only to find they're not going to pay what I'm willing to take -- especially when it's wayyyyy out of range. Happens more and more as I get older, as the term "senior engineer" has really gotten watered down since I started (I'd be like senior^3 I suppose). I've gotten to the point where I have to be really interested to go very far at all without having pinned down a range.

<comment><AUTHOR> Job titles have definitely become weirder/amgbiguous/watered down over time.

Instead of salary range, what would interest you? (firm, tech stack, vision?)

<comment><USER9> Email addresses of two or three peers on the team that is advertising the position.

<comment><AUTHOR> To get in touch/an understanding of the company/team?

</comment></comment></comment></comment><comment><USER10> Showing sallaries saves everyone's time and money, some people want higher wages, others are willing to go for the same, just want to change.. Really depends.

<comment><AUTHOR> Showing salaries would seem to be a way of offering transparency. One worry might be people going for a higher paying role with just that intent.

Why do you think companies might not show salaries?

<comment><USER11> So that they get to screw over people who don't know what they are actually worth.

Sorry about the relatively-crude language, but I don't know of a better way to put it that's still succinct.

<comment><AUTHOR> No need to apologise - it's a perfectly justified way of putting it. Could be considered a cynical view, but justified still.

<comment><USER11> Also, note that employers are seldom as rushed to find an employee as an employee is to find an employer.

</comment></comment></comment></comment></comment><comment><USER12> I don't know that this survey really demonstrates anything interesting, but humans typically reciprocate demonstrations of trust, suggesting that greater transparency in hiring would create a virtuous cycle.

<comment><AUTHOR> It is admittedly not a totally methodical study, but the discussion is sort of compelling.

Human nature would suggest as much (we'd certainly hope for reciprocations of actions that demonstrate trust in the everyday at least). But as others have mentioned - there are drawbacks to being transparent, even with the potential benefits from the created virtuous circle.

</comment></comment><comment><USER13> Personally? I am 100% more likely.

<comment><USER6> Likewise, especially since "competitive" is such a huge range. As an example, if I'm currently making $100k, I might entertain a position at a slightly interesting company that's offering a "competitive" salary of $95k. However, I don't think there's anything that would make me go through the hassle of interviewing for a job paying a "competitive" $60k.

Basically, posting the salary range gives me a quick and easy way to weed out those companies which aren't serious without a significant investment of my time.

<comment><AUTHOR> So a displayed salary range (perhaps $5-15k in swing?) in any case offers something more tangible/clear than 'competitive'?

I could certainly agree with that. It doesn't confine a company to a certain $x, but isn't as opaque as the bog standard 'competitive.'

<comment><USER14> A range would at least give me a good idea of whether the salary is more or less than what I'm currently getting paid. If the high end of the range is well below my current salary, I know I shouldn't waste my time. "Competitive" can mean just about anything, so it gives me absolutely no information.

<comment><AUTHOR> That's fair logic - what if other forms of compensation were included in the listed range? (e.g. top end of band + equity)

</comment></comment></comment></comment></comment><comment><USER15> not me.

What i care about is where the office is located, whether there is anything to do in the area around the office, what technologies i will work with and whether i regard the company as ethical.

I once worked for a former white panther at half the salary i could have commanded anywhere ele.

<comment><AUTHOR> Your rationale is certainly a strong one - salary is but only one consideration in the end.

What was your experience with the former white panther like?

<comment><USER15> he ran the company into the ground but we all had a great time while he did so.

that was the best place i ever worked. the problem was that dave really didnt want to be in the software industry anymore.

nowadays, jimmy carter reads his political blog.

<comment><AUTHOR> Enjoying it at the end of the day is the key thing, on a personal level and as a team. Shame it ended, but seems an understandable reason.

Now, having an ex-POTUS reading their is one helluva bragging right for him!

<comment><USER15> Im hoping to meet jimmy someday but hes pissed at me bcause i made an offcolor joke at the expense of his exgirlfriend.

<comment><AUTHOR> Ah, oh dear haha.</comment></comment></comment></comment></comment></comment>


Ask HN: What self-study curriculum organizer tool do you use? - <AUTHOR>

I found myself recently with a lot of free time on my hands, so I decided to brush up on everything hacking related. Out come Skiena's "The Algorithm Design Manual", Sipser's "Theory of Computation", Axler's "Linear Algebra Done Right", and plenty of other stuff I never knew or already forgot. I want to organize all of that into some method as it was once done in college: schedule, assigned readings, problem sets, etc. except this is all self-imposed. What nifty Web 2.0 tool can I use to do this? A To-do list like "www.rememberthemilk.com" doesn't seem adequate - I think I would like a more rigid setup. <comment><USER2> I'm not sure how it will integrate with the books you are using, but I'd suggest checking out MIT's OpenCourseware. They provide the syllabi / assignments / calendar used for all of their courses. You could probably take the corresponding classes and adapt their schedules and problem sets. I've done this for classes where I didn't find my lectures or suggested materials particularly helpful.

</comment><comment><USER3> I'm not sure if this is what you're after but Supermemo is a fantastic learning tool.

It uses a system of spaced repetitions to significantly increase retention and memory. It's been around a long time and has been refined over many years. The creator was featured in Wired not long ago..

<http://www.supermemo.com>

Unfortunately it's windows only.

<comment><USER4> There is an open source project providing similar functionality called Mnemosyne that runs on Linux, Mac OSX and Windows.

Its home page is here: <http://www.mnemosyne-proj.org/index.php>

</comment></comment><comment><USER5> Have you considered using a spreadsheet? Maybe a Google Spreadsheet or Excel. You can use to create a list of topics and associated readings, lessons, problem sets and materials. Then create an extra column "completed" to track the status of each item. Then just filter out the completed items to see what else you need to do. It's a simple solution, but should work well.

<comment><AUTHOR> Yes, and this will probably be my final solution if nothing else comes up. I was thinking perhaps someone already went through the pain of setting up the structure around it, and also maybe figured out some interesting use cases that wouldn't be apparent in a spreadsheet.

</comment></comment><comment><USER6> Got a Mac? Try Yojimbo or DevonThink... both are superb.

<http://www.devon-technologies.com/products/devonthink/> <http://www.barebones.com/products/yojimbo/>

I've been using DevonThink for a while and it has helped me immensely with staying organized.

</comment><comment><USER7> +1 for MIT's OpenCourseware

<comment><USER8> If you want to say plus 1, you should just vote on the comment instead of making a new post. It's both nicer to the author and it reduces the noise in the thread.

</comment></comment><comment><USER9> text files win</comment>


Reciprocal Altruism or Why Not to Screw People Over in Silicon Valley - <AUTHOR> http://startuphoodlum.com/2011/06/26/reciprocal-altruism-why-the-valley-works-and-why-not-to-screw-over-people/

<comment><USER3> Okay so - person A commits an act which person B believes to be a betrayal. Community opinion splits. Intuitions go either way. Particularly - those who converse more with A and have greater allegiance with him, view the matter as he does, and vice versa with person B.

As per the principle advocated in the article - B hates A and refuses to further interact. And that's it. If they're lucky - they'll cause a divisive rift in their entire social group.

I've seen many examples of above stated sort of case. I haven't seen that many where it's just clearly obvious that one person was the a-hole - to the point where intuitions on the matter don't split to a significant degree. But of course most people when IN the situation believe that it is in fact black and white - just as this author supposes. Well - more often than not, that's hubris.

So here is some contrarian advice.

As I see it - trust and understanding only comes after the overcoming of a thousand mis-understandings. It comes after a mountain of forgiveness from both sides. I've never had a single friendship of any significance that did not involve a large degree of conflict.

So take some time to cool off - let some water flow under the bridge - <USER2> call em up and buy em a beer. Admit that you were probably just as much of an a-hole, even if you don't entirely understand why - and talk to the guy as much as you can to figure out if maybe... just maybe... you got things wrong.</comment>


LoRa Backscatter [pdf] - <AUTHOR> https://homes.cs.washington.edu/~gshyam/Papers/loRaBackscatter.pdf <comment><USER2> It says regarding CSS "That makes even faint LoRa signals easy to distinguish from background noise, which fluctuates randomly".

Is CSS better than FSK than in this respect or..?

Edit: [http://www.akermann.bg/files/Semnrs/H2016/Module3.4_100km%20...](http://www.akermann.bg/files/Semnrs/H2016/Module3.4_100km%20TI%20NarrowBand%20vs%20LORA.pdf)

Says

"Spreading codes does not improve sensitivity over FSK systems, for usable datarates you get similar sensitivity using standard FSK modulation"

<comment><USER3> >background noise, which fluctuates randomly

From years of experience selling, supporting, and installing 900MHz ISM radios, I can tell you this is not the case in many, many places (it describes a greenfield application more or less correctly, though). 900MHz is heavily used in the US and describing the noise as "background" or "random" is disingenuous at best. I'd like to see someone install a LoRa hub on a tower with several other 900MHz radios (common) and see how well it works.

<comment><USER2> That's very interesting cheers. Just to clarify that quote was from the article this post originally linked to, rather than the paper it now links to.

</comment></comment></comment><comment><USER4> "So, we reverse-engineer the LoRa physical layer using the patents filed by Semtech [27, 57], which is the key LoRa chipset manufacturer. We also use the Semtech 1276 starter kit [10] that provides an interface to transmit LoRa packets with various bitrates and an arbitrary payload. Finally, we analyze the transmissions from the LoRa chipsets on a USRP."

This is some impressive work.

<comment><USER5> There has been some prior work on this:

\- Decoding LoRa: Realizing a Modern LPWAN with SDR [1]

\- Presentation on this work from GRCon16 [2]

\- Slides from the above presentation [3]

[1] [https://pubs.gnuradio.org/index.php/grcon/article/download/8...](https://pubs.gnuradio.org/index.php/grcon/article/download/8/7/)

[2] [https://www.youtube.com/watch?v=-YNMRZC6v1s](https://www.youtube.com/watch?v=-YNMRZC6v1s)

[3] [https://static1.squarespace.com/static/54cecce7e4b054df1848b...](https://static1.squarespace.com/static/54cecce7e4b054df1848b5f9/t/57489e6e07eaa0105215dc6c/1464376943218/Reversing- Lora-Knight.pdf)

</comment></comment><comment><USER6> This paper to be presented in ACM SenSys in November actually demonstrates ability to backscatter to distances as high as 3.4 kilometers at 70 microwatts using narrow band FSK transmissions.

[http://www.ambuj.se/LoRea-CR.pdf](http://www.ambuj.se/LoRea-CR.pdf)

LoRa while achieves impressive sensitivity levels, this is for very low bitrates of tens of bps. For any practical data rate the sensitivity levels are similar to FSK.

</comment><comment><USER7> Anyone know of any notable related research on real world use of this tech?

Best I was able to find was "An Investigation of Fading on a Short Range 900MHz radio link":

[https://mentor.ieee.org/802.11/dcn/10/11-10-1355-00-00ah- fad...](https://mentor.ieee.org/802.11/dcn/10/11-10-1355-00-00ah-fading-on- short-range-900-mhz.pdf)

<comment><USER8> You might have more luck looking at Active RFID. The same technology in any meaningful sense.

</comment></comment><comment><USER9> I worry about encryption of sensitive data.

I don't doubt it can be done, but can their "twenty-cent" chip handle it without messing up its lightweight low-power nature?

<comment><USER8> Modern microcontrollers can be had in the sub-$5 range that support hardware implemented encrypting algorithms. Mostly it's a worthless feature but we aren't far out from it being more or less standard even in the $0.20 guys.

The bigger issue is that the entire point of this system is to remove cost of deployment and maintenance for cheap highly distributed lo-fi systems. The cost of keying all those devices for encryption would defeat the purpose. Also the added data overhead of the encryption would possibly exceed the amount of actual data you are trying to get out of the system. Also, why do you even want to encrypt it in the first place?

<comment><USER10> > Also, why do you even want to encrypt it in the first place?

I want to encrypt _and_ authenticate any and all wireless gadget data because I've been paying attention to the last 5 years of defcon talks.

<comment><USER8> HN ate my reply, apparently I was posting too fast, but as a TLDR you can avoid the overhead of encryption and authentication by revisiting the trust framework in the design of your network and simply assuming that you don't trust your sensors. This moves the overhead from the sensors and the network which are heavily constrained to the processing of the central authority where you have a lot more lee-way and moore's law to help. If you are interested in learning more about this sort of system, it is a topic of research in control theory often lumped under robust systems.

</comment></comment></comment></comment><comment><USER11> It would be nicer if it were not proprietary.

</comment><comment><USER12> Which font is used in the document?

<comment><USER13> Linux Libertine: [https://en.wikipedia.org/wiki/Linux_Libertine](https://en.wikipedia.org/wiki/Linux_Libertine)

      $ pdffonts loRaBackscatter.pdf

      name                                 type              emb sub uni object ID
      </comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment> </comment><comment></comment><comment>----- --- --- --- </comment><comment>---
      OZJJTN+LinBiolinumTB                 Type 1            yes yes yes    116  0
      LWEMPN+LinBiolinumT                  Type 1            yes yes yes    118  0
      LWEMPN+LinBiolinumT                  Type 1            yes yes yes    119  0
      LILBVD+LinLibertineT                 Type 1            yes yes yes    120  0
      LILBVD+LinLibertineT                 Type 1            yes yes yes    121  0
      ...

</comment><comment><USER14> "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."

—Tanenbaum, Andrew S. (1989).

<comment><USER15> A more up-to-date take on this:

> Games on Disc More Energy Efficient than Downloads

[http://www.notechmagazine.com/2014/09/games-on-disc-more- ene...](http://www.notechmagazine.com/2014/09/games-on-disc-more-energy- efficient-than-downloads.html)

And if you _really_ want to dive into the complications of this topic from a broader perspective of energy use, this piece is full of thought-provoking questions, even if you don't necessarily agree with the conclusions:

[http://www.lowtechmagazine.com/2015/10/can-the-internet- run-...](http://www.lowtechmagazine.com/2015/10/can-the-internet-run-on- renewable-energy.html)

</comment></comment><comment><USER16> LoRaWAN packet received at record distance of 702 km | [https://news.ycombinator.com/item?id=15201692](https://news.ycombinator.com/item?id=15201692) | _(5 days ago, 178 points, 50 comments)_

> animats: _Wow. Both the receiving and transmitting antennas were > omnidirectional_

> vvanders: _I regularly see APRS packets of 120mi+, although probably at a > lot more power._

> superkuh: _I run two ubiquiti nanostation M900 at home on a 10m pole and in > my car through the sunroof for a mobile data link._

> aw3c2: _From a balloon in almost 40km altitude._

</comment><comment><USER17> This website is so brokenly slow. The initial load does 184 xhr-requests mostly in series, oh my god where does this end?

<comment><USER18> They're just cleverly preparing you for the experience of the first website served over LoRa.

</comment></comment><comment><USER19> Got a mirror? Website imposes a article viewing limit...

<comment><USER20> Disable Javascript for that site and it reads normally. I've found that most news sites become _much_ more readable (and chew through far less of my CPU, and stop autoplaying loud videos, and skip paywalls) with JS disabled.

The Chrome plugin I'm using (Quick Javascript Switcher) disables on a per- domain basis and remembers the setting for each.

I'm a huge fan of SPAs and JS in the browser and yet I'm quickly blocking JS out of large swaths of the internet simply because it improves the browsing experience. I'm not quite sure what this lesson is teaching me.

<comment><USER21> YesScript worked for me on Firefox. Thanks for the idea. [https://addons.mozilla.org/en- US/firefox/addon/yesscript/dev...](https://addons.mozilla.org/en- US/firefox/addon/yesscript/developers)

<comment><USER22> Just a note that YesScript isn't compatible with my Firefox Nightly now (due to the move to WebExtensions) and will probably stop working with Firefox in general in the future.

</comment></comment></comment></comment><comment><USER23> Here's the paper: [https://homes.cs.washington.edu/~gshyam/Papers/loRaBackscatt...](https://homes.cs.washington.edu/~gshyam/Papers/loRaBackscatter.pdf)

Tech like this already exists (look up "UHF RFID") and the picture they've got looks very similar to existing tags (image search for "alien rfid tag").

The interesting thing here is managing to implement LoRa's modulation scheme in a passive tag.

<comment><USER8> It's not a passive tag. If you only read 3 sentences into the abstract, you find out that it is an active device. This is repeated at the end of the abstract and right at the beginning of page 2 in the introduction.</comment></comment>


Experimental support for WebAssembly in V8 - <AUTHOR> http://v8project.blogspot.com/2016/03/experimental-support-for-webassembly.html <comment><USER3> The big news here is coordinated announcements from _multiple_ browsers:

[https://blogs.windows.com/msedgedev/2016/03/15/previewing- we...](https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly- experiments/) [https://v8project.blogspot.com/2016/03/experimental- support-...](https://v8project.blogspot.com/2016/03/experimental-support-for- webassembly.html) [https://hacks.mozilla.org/2016/03/a-webassembly- milestone/](https://hacks.mozilla.org/2016/03/a-webassembly-milestone/)

introducing support for the live demo:

[https://webassembly.github.io/demo/](https://webassembly.github.io/demo/)

<comment><USER4> A WebKit announcement is notably missing, unfortunately. However, it is great to see Edge, even though it is not a surprise, as they have been pushing for WebAssembly from the start.

<comment><USER3> WebAssembly is "In Development" on WebKit's status page: [https://webkit.org/status/#specification- webassembly](https://webkit.org/status/#specification-webassembly)

<comment><USER5> Also cf. [https://bugs.webkit.org/show_bug.cgi?id=146064](https://bugs.webkit.org/show_bug.cgi?id=146064)

</comment></comment></comment></comment><comment><USER6> Standard caveats apply here. It's experimental: a couple bugfixes are already in flight and we're working hard on improving the startup time.

Overall a huge thanks to our friends at Mozilla and Microsoft and Apple, with whom we've worked closely with over the past year to make this a reality.

</comment><comment><USER7> Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for performant web development in the future, especially since even with complete adoption of WebAssembly this will still create a split between browsers that support it and browsers that don't.

From glossing over the wasm spec, it seems it's designed for C++ compilation, which in the environment I do development, is totally impractical. It sounds like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that case, it might be time to work on some tools for analyzing syntax and start annotating types, because compiling from ECMAScript to WebAssembly would be a great boon in production.

<comment><USER8> Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?

<comment><USER9> If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet.

Update: Here's a quote from the Microsoft announcement:

"Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case."

[https://blogs.windows.com/msedgedev/2016/03/15/previewing- we...](https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly- experiments/)

<comment><USER10> You are misunderstanding. A C++ application compiled to wasm is smaller than a C++ application compiled to a subset of javascript.

A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. The best you could do would be to store some kind of compressed representation of the source code, along with a JIT compiler to run that source code. It isn't a sensible thing to do.

<comment><USER11> _A javascript application compiled to wasm doesn 't really make sense. Javascript isn't a compiled language._

This compiled/interpreted distinction has gotten quite fuzzy, and it has been for decades now. Smalltalk was always a compiled language with really late binding. It did compile to a bytecode which was interpreted at first, but that became JIT compiled in all but one commercial VM. This all happened over a decade ago.

Also, there is clearly a subset of Javascript programs that could be usefully compiled down to a small, fast, compact machine language program.

<comment><USER8> > there is clearly a subset of Javascript

I suppose the extra restrictions of Typescript would help. At least if you add extra restrictions to make it easier to compile.

</comment></comment></comment></comment></comment></comment><comment><USER12> Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is much sooner in the pipeline.

<comment><USER13> Should just be replacing Emscripten in the toolchain with Binaryen [1].

[1] [https://github.com/WebAssembly/binaryen](https://github.com/WebAssembly/binaryen)

<comment><USER14> This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share.

The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.

</comment></comment></comment><comment><USER15> I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code loaded over the internet in your browser? As a free-software advocate, this concerns me.

<comment><USER16> WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2].

[0]: [https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/)

[1]: [https://github.com/WebAssembly/design/blob/master/TextFormat...](https://github.com/WebAssembly/design/blob/master/TextFormat.md)

[2]: [https://github.com/WebAssembly/design/blob/master/Tooling.md](https://github.com/WebAssembly/design/blob/master/Tooling.md)

<comment><USER17> Great!

We should make sure that browsers refuse to run any code in the future that isn't available in its full source.

Yes, that includes ReCaptcha

/me looks angrily at Google

<comment><USER18> I think the idea is that WebAssembly apps will normally be closed-source, but browsers will ship with disassemblers, making it easy to inspect the app logic in a common text format.

<comment><USER19> Then every exe file is open-source, because we have disassemblers. Don't lie to yourself: webassembly is for closed-source applications. They will be compiled by an obscure compiler, so dissassembling back to logical code will be too costly to be practical. We saw this many times: for v1, disassembler works perfectly and maps 1:1 from binary to code, but for version xxx.0 it's no longer true, because of various tricks and optimizations.

<comment><USER18> No one's saying wasm apps will be open source, just that there will be a reasonable way to inspect their logic. Of course making sense of certain wasm apps will be challenging. JS code can be hard to follow as well, if it was generated by a tool like GWT, or minified, or obfuscated.

<comment><USER19> I am agree, that wasm will be on par with generated/minified JS right now, but I predict that wasm will beat JS in future versions. My prediction is based on experience. It is very easy to introduce a binary thing which is hard to map to flat text. I.e. first version of wasm will be 1:1 map to JS, but NEXT versions of wasm will introduce optimizations, which are quite possible in compact binary format but are not possible in flat text format, so 1:1 map from wasm to JS will be broken.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> Are there any plans to run WebAssembly outside of a browser? Would it be difficult (once the binary format is nailed down) to distribute a standalone program?

<comment><USER21> Given that node.js uses v8, and there are a few options for stand-alone distribution of node-based apps [1], I'm sure there will be many options (by the end of the year most likely)... Though, I'm not sure why you wouldn't take a more direct approach to building your code to different platform targets directly if you're using a compile language already... though if you're building web and want a standalone, I can see that.

[1] [http://stackoverflow.com/a/12486874/43906](http://stackoverflow.com/a/12486874/43906)

<comment><USER20> But you only have to compile once for all platforms (famous last words, I know). Including future platforms, platforms you don't know about, and platforms you don't care about but your users do.

</comment></comment></comment><comment><USER22> Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language like JS is now.

Will I have the ability to write a library in one language and use it in another as long as they both compile to wasm?

<comment><USER23> Finally I can write in HyperTalk!

<comment><USER24> The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.

</comment></comment></comment><comment><USER25> So who's going to be first to recreate an entire Flash runtime for WASM? ;)

<comment><USER26> Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz.

<comment><USER25> > Even better, port the JVM and the applet infrastructure for maximum > "remember the last time we did this exact thing" retro-lulz.

You cant port the entire applet infrastructure since WASM is limited to the same API as Javascript. If WASM doesn't support multithreading, languages targetting WASM wont.

<comment><USER27> But it does support multithreading.

Things missing are usually specific external protocols. e.g. being able to make a TCP socket; (or higher level things like ignoring CORS).

</comment></comment></comment></comment><comment><USER28> So when is Google going to deprecate Native Client?

<comment><USER29> When WebAssembly is further along the capabilities of PNaCl should be polyfillable to WebAssembly, and it would then make sense to ship one fewer VM. Otherwise NaCl and PNaCl have a solid track record of running code near native speed in an extremely secure sandbox. It's under Chrome's Vulnerability Reward Program, you're welcome to look for payoffs ;-)

</comment></comment><comment><USER30> For all the complaining about it, I think I will actually be a little sad to see Javascript go. It wasn't perfect, but it had a powerful unifying effect on the Web Community when we could write, share and learn about our code in a higher-level scripting language that we could all read. (Even if there were some surprising little quirks that took a while to get used to.) Despite the stated intention from WASM - there is just something fundamental about AST trees - no matter how well you pretty-print them - that doesn't allow sharing and shared learning the same way. As a run-of-the-mill guy who makes my bread maintaining websites as much as greenfield-developing them, I feel like I'm in for a bit of a rough ride trying to decipher and debug binary/AST code compiled from Perl (or whatever). Guess I'll have to suck it up and learn to do it, though.

<comment><USER29> JS isn't going anywhere. wasm and JS are a dynamic duo, complement each other.

<comment><USER30> It seems like they "could" complement each other, but that's not a defining characteristic of WASM. WASM, as I understand it, essentially allows me to take my higher-level language like Python/Haskell/Perl/(Maybe also JS) and compile an AST that can be interpreted by the engine on the client-side. Which is great for Python/Haskell/Perl developers that they no longer have to pay the toll of learning/sharing/contributing to JS - they are Haskell devs, maybe they shouldn't have to contribute to JS. We can call that a good thing, but let's not pretend that doesn't marginalize JS (which - again!! - maybe it should). "But they still don't have access to the DOM" is not much of an impediment to that Perl dev, and means as your run-of-the-mill guy I now have to debug the Perl-produced WASM AST (Maybe pretty-printing will let me read it in 5 hours instead of 12, but I'm still reading binary/AST which does not seem like an awesome time) and the cruft from whatever Perl-WASM binding library they forked from Github. Again - I know this makes life better for that Perl dev, and maybe he/she deserves it. But unless I'm missing something, I don't see how allowing that dev to (basically) skip JS in their path from whatever IDE Perl devs use to the Web makes WASM "chummy" with Javascript. In fact, it seems like now that dev will start making/contributing to libraries that conform to their stack (Perl-specific web libraries that compile to WASM). Now if I want to contribute to that library - which is now a part of the web - <USER2> have to learn Perl. Before, that Perl dev would have had to learn Javascript - which I know sucks for them - but it was good for me and good for Javascript... and I would say "good for the web". We were all speaking the same language, which led to an explosion of learning and collaboration. Sure, .3 != .1 + .2 But it was that way for all of us. Now everyone is going to go back to their own little feifdoms and just tipping their hat to JS along the way with a lightweight DOM binding port.

</comment></comment></comment><comment><USER31> does this mean i wont have to learn javascript, css, d3, svg, typescript, jquery, etc ... to make webistes and web apps

<comment><USER32> From my understanding, WebAssembly won't have DOM access. So it certainly won't replace jQuery, D3 or CSS any time soon.

<comment><USER16> WebAssembly doesn't intend to replace jQuery, D8, or CSS. However, we definitely plan to enable efficient DOM access. Doing so requires supporting some sort of native Garbage Collection, as well as the concept of opaque reference types. See more here: [https://github.com/WebAssembly/design/blob/master/GC.md](https://github.com/WebAssembly/design/blob/master/GC.md)

<comment><USER33> Any specific plans for python support?

<comment><USER29> Python is just another language VM. C Python should work just fine in WebAssembly, and bridging the APIs to the web (e.g. filesystem, etc) is already possible through Emscripten.

We don't plan to do things for WebAssembly, we plan to make WebAssembly powerful enough that anyone can run their language VM :-)

<comment><USER34> I think what they meant is that they could use python without having to also ship the implementation like CPython. I mean, that thing is huge. How is it feasible to serve 10mb for a website?

<comment><USER35> Yes, thats what I meant.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Will WebAssembly allow us to create custom video codecs? Or is there still a bottleneck somewhere that makes this unrealistic?

<comment><USER4> You could already make video codecs in JS, or in C using asm.js. It is absolutely realistic; see for instance the jsmpeg project: [https://github.com/phoboslab/jsmpeg](https://github.com/phoboslab/jsmpeg).

It is unlikely to ever compete battery-wise with hardware support for a codec, however.

<comment><USER29> Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support.

* Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.

<comment><USER37> I don't think WebAssembly is likely to be any faster than JavaScript is it? It's literally the same compiler in V8.

<comment><USER38> Oh but it is; see also asm.js, which is a subset of JS that removes a lot of the potential performance bottlenecks by removing those features from JS (mostly having to do with JS' dynamic nature, iirc).

Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format.

<comment><USER37> > Or in other words: javascript is an interpreted script language, webassembly > is a compiled binary format.

They're both just-in-time compiled. It doesn't matter if your program comes in as source code or a binary format if you're compiling it dynamically.

But I didn't know that WebAssembly ran under asm.js semantics. I guess that's the difference.

<comment><USER29> WebAssembly has its own semantics, similar to asm.js (statically typed) but much cleaner because it doesn't need to map onto JavaScript.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> Would there be any benefit to compiling dynamic languages with GCs (like Python or Ruby) to WASM? It is cool that is technically possible, but this looks like a target for C, C++, and Rust code.

<comment><USER29> C Python and Ruby should "just work" because you can compile their GC into you wasm module.

More general-purpose GC will be supported, but not in the initial release: [https://github.com/WebAssembly/design/blob/master/GC.md](https://github.com/WebAssembly/design/blob/master/GC.md)

</comment></comment><comment><USER40> Does anyone who is familiar with WebAssembly development know what kinds of things Dynamic Linking (mentioned among the future features) will enable? For instance, would it permit the creation of optimized WebAssembly libraries written in C++ that could be called by a JavasSript program (say, for things like image processing)? Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser?

Because that would pretty cool.

<comment><USER6> You can already do some of that without the dynamic linking feature. There is a JS API to instantiate a WebAssembly module, providing JS functions that are callable as external functions from within the WASM module. Conversely the WASM module exports functions that are callable directly from JS.

This allows rudimentary interop between JS and WASM, and dynamic linking will make it possible to deliver your WASM application in separate pieces, e.g. a large, rarely-changing library that is cached, precompiled, by the browser, and a small, often-changing application piece.

</comment></comment><comment><USER41> This is going to be huge for the WebVR community. The demo actually ran great on my janky laptop, whereas the ASM.js version at a lower resolution ran at the considerably crappy level I had come to expect of Unity HTML5-built apps on an Intel integrated GPU. Faster = more efficient, also, so equivalent demos should burn less battery power on my smartphone as well, which means less heat build up, which means a longer time before the GPU throttles down.

</comment><comment><USER42> More importantly, will rust compile to wasm one day?

<comment><USER43> [https://users.rust-lang.org/t/rust-to-js-with- emscripten/587](https://users.rust-lang.org/t/rust-to-js-with-emscripten/587) There's been interest in compiling to JS for a while. I don't follow Rust closely, so I'm not sure how much progress there has been.

<comment><USER44> Lots! We're getting really close, actually.

</comment></comment></comment><comment><USER45> When I read news like this, I think: this is the cool stuff you should be doing, not maintaining a lousy e-commerce shop...

<comment><USER46> I work on OS level stuff myself, but I find this comment insulting. What are you even working on?

</comment></comment><comment><USER47> Giant Leap for Web Platform.

How is the mapping from wasm to asm done, at all?

Are they directly mapping from web world to native world in a sandbox ?

<comment><USER48> [https://github.com/WebAssembly/design/blob/master/FAQ.md](https://github.com/WebAssembly/design/blob/master/FAQ.md)

<comment><USER47> {Any Language} => WASM => {OPTIMIZATION/COMPILATION} => NATIVE CODE

</comment></comment></comment><comment><USER49> It is a wonderful news. Firefox version is ready too.

</comment><comment><USER21> I can't help but to think that this could be a huge win for binary modules in node.js, as it could finally allow for cross-platform, prebuilt binary modules without the tight coupling and build dependencies that are currently needed.

</comment><comment><USER50> This is moving fast.

Does anyone know if theres a webassembly to js compiler to support legacy browsers?

<comment><USER16> The Emscripten toolchain can be used to produce both WebAssembly and asm.js from the same codebase [0]. There are also the nascent beginnings of a translation tool from WebAssembly to asm.js here [1] (look for wasm2asm). Ultimately, it should be possible to write a streaming polyfill for WebAssembly, but no one has gotten around to making anything suitable for production yet. You're better off producing a separate fallback asm.js bundle for now.

[0]: [https://github.com/kripken/emscripten/wiki/WebAssembly](https://github.com/kripken/emscripten/wiki/WebAssembly)

[1]: [https://github.com/webassembly/binaryen](https://github.com/webassembly/binaryen)

</comment></comment><comment><USER33> Question please: Even though there is stated desire to support python etc vm, this will be hampered by the need for the client to download the large VM vs native code that can be distributed itself, correct?

<comment><USER29> Correct, though we're working on dynamic linking to ease the pain, and improving compilers such as LLVM so that the generated code is smaller.

<comment><USER33> Thanks. I'm not familiar with dynamic linking. What will that do?

<comment><USER51> There's a response above this one from titzer describing it, or you can read more here: [https://github.com/WebAssembly/design/blob/master/DynamicLin...](https://github.com/WebAssembly/design/blob/master/DynamicLinking.md)

</comment></comment></comment></comment><comment><USER52> This is great news! And a nice working demo ... And a general question about wasm - since typescript can be strictly typed, would it benefit much, if it would be compiled to wasm?

<comment><USER53> I currently write compilers that target JavaScript and have looked a TypeScript a lot for something like this. In practice, TypeScript isn't actually strictly typed. There is a ton of TypeScript code out there that does stuff like run-time prototype manipulation (mixins, for example), using arbitrary objects as hash tables, and liberal use of the "any" type.

So either you cross-compile a JavaScript VM to be able to handle everything (super slow and bloated, especially without the ability to JIT compile executable code) or you pick a small subset of TypeScript to compile, in which case it wouldn't really be TypeScript at all.

Plus TypeScript doesn't have integer types (only doubles) so it would generate pretty inefficient code. JavaScript JITs do a _lot_ of work to turn usage of doubles into integers based on run-time behavior that is unknowable at compile-time.

<comment><USER52> I think I would be happy with the subset and the add of Integers ... Dynamic languages are great for rapid prototyping and debugging, but once the programming is done and everything is clear, I don't realy need stuff like window["foo" \+ someString](1,2,3) or the "any" type anymore ... I don't think it will be too hard, to "strongtype" your ts or js if there will be such a subset and you have a smart IDE.

</comment></comment></comment><comment><USER54> Oh man I'm very excited about this! Great job all around!

Web Assembly should make code more portable and faster on the web. No more transpiling to JavaScript (which honestly is a hack; going from one language to another language which is then compiled). If you want to use CoffeeScript, even though I dislike it, you'll be able to compile directly to WebAssembly instead.

I can't wait until this is fully baked with DOM access, etc.

<comment><USER29> Transpiling some dynamic languages to JS is still sensible. WebAssembly is initially for static languages, and eventually (with JIT and GC support) it'll be usable as a building block to host dynamic language VMs.

<comment><USER54> > Transpiling some dynamic languages to JS is still sensible.

It's still practical, today, should you want to use something other than JS but I don't think it's that sensible. You take one language's syntax and idiosyncrasies, convert it to another language with its own, sometimes differing, idiosyncrasies and now you have to debug it, sometimes in a different language than it was written it.

I don't mind TypeScript or any of the others but I think WebAssembly is what makes those language great; transpiling to JavaScript is a hack.

Just imagine ECMAScript 7 then ECMAScript 8 support coming in very quickly after announcement because your JavaScript now compiles to WebAssembly. You won't have to wait or deal with browsers that are lacking the necessary APIs; it'll "just work" because it's all compiled to WebAssembly.

<comment><USER55> That's not what jfbastien is saying. The point is, until the time when WebAssembly has a GC and a JIT, many dynamic languages simply won't be able to target WebAssembly (unless the dynamic language developers create their own bespoke JIT/GC), so you may as well stick to targeting JS.

At the point at which WebAssembly gets a JIT and GC, then the situation changes.

<comment><USER54> Yup I know; I never said anything to the contrary just talking up WebAssembly's advantages. This release is a very early and somewhat rough version.

</comment></comment></comment></comment></comment><comment><USER56> I know programmers sometimes write directly in assembly for certain performance enhancements and certain hardware access. Is there a foreseeable reason someone would program directly in WebAssembly though? I realize that's not the reason this technology exists, just curious.

<comment><USER57> When asm.js came out I ported [http://wry.me/hacking/Turing- Drawings](http://wry.me/hacking/Turing-Drawings) to use it. It would've made as much performance sense to do the same for WebAssembly. This is not quite the same as hand-coding WebAssembly -- it's making a custom code generator for a little language.

</comment></comment><comment><USER58> Nim, which is objectively the best programming language, is perfect for Web Assembly.

</comment><comment><USER59> It might sound like a stupid question, but is it faster then vanilla JavaScript!?

<comment><USER25> Yes since it's lower level, and No since you'll still be limited to Web APIs like Javascript. The code isn't being executed outside the browser like a Java applet or Flash.

</comment></comment><comment><USER25> Great news, this is the beginning of the "Javascript Less" movement.

<comment><USER60> It'll be really interesting if people think of JavaScript more as a highly available scripting language, rather than a necessity.

</comment></comment><comment><USER61> That three major browser teams implement and publish a new standard/technology at the same time is exciting. OTOH I can't believe we start over again with Assembler (a machine language).

<comment><USER18> Well it's not really machine code, since no hardware uses wasm as its native instruction set; it's just low level bytecode.

And it's really intended as a compilation target; I don't think anyone wants or expects average web developers to code in wasm.

<comment><USER61> Well, it runs on a virtual machine, not that much different. And the design doc states "writing by hand", but the s-expressions look interesting. Finally Lisp for browsers :)

</comment></comment></comment><comment><USER62> I wonder if Google has any plans on using C++ in any of their web applications now.

Might help them improve Google Docs a lot if they could utilize some mature C++ libraries from a desktop word processor.

<comment><USER63> Google can already run whatever code they want on your docs server side.

</comment></comment><comment><USER64> This is really exciting, because it's going on a great path and it's a matter of time before all this is available out of the box!

Is anyone working on a Go to WebAssembly compiler yet?

<comment><USER55> > "Is anyone working on a Go to WebAssembly compiler yet?"

I don't think that'll work until WebAssembly has GC, which isn't likely to be ready for a while.

<comment><USER65> Go has it's own GC, so why would it need WebAssembly's? Does web assembly disallow programs from doing their own GC?

<comment><USER55> Go has a GC that runs on top of an OS. The virtual machines that run WebAssembly are highly likely to have different mechanisms to manage memory compared to an OS that Go runs on, so Go's GC will not work 'out of the box'.

This leaves two options:

1\. Go developers could write a GC especially designed to enable Go on WebAssembly.

2\. Go developers could wait until WebAssembly gets its own GC implementation, and make use of that.

Considering option 2 is less work, and that a GC for WebAssembly is on the WebAssembly roadmap (check the GitHib page for details), I'd suggest option 2 is what will end up happening.

</comment></comment></comment></comment><comment><USER66> Is there any news for WebAssembly on mobile browsers?

<comment><USER29> It should "just work", but we're still at the experimental stage right now so it may break randomly. It's not production quality yet, but mobile is a first- class platform for launch.

</comment></comment><comment><USER67> Is this in a state where I can go and try making experiments in webassembly?

<comment><USER68> It's a little early, so things are not easy to use yet. Spec still changes, tools still change and break, nothing is optimized for convenience yet, etc. But here is how to use emscripten to emit WebAssembly currently,

[https://github.com/kripken/emscripten/wiki/WebAssembly](https://github.com/kripken/emscripten/wiki/WebAssembly)

</comment></comment><comment><USER69> Anyone gonna write an LLVM backend for this? =D _mouth waters_

<comment><USER3> Already on it :-).

[https://github.com/llvm- mirror/llvm/tree/master/lib/Target/W...](https://github.com/llvm- mirror/llvm/tree/master/lib/Target/WebAssembly)

(linked to the Github mirror because the LLVM viewvc is currently down)

</comment></comment><comment><USER70> The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all.

<comment><USER71> Lynx?

<comment><USER72> I always use elinks when I'm trying to get work done as anything worth reading (documentation etc) works just fine in it but you don't have all the distracting "web stuff".</comment></comment></comment>


OVH's hubiC offers 10TB storage for €50/year - <AUTHOR> https://hubic.com/en/offers/ <comment><USER2> [https://hubic.com/en/contracts/Contrat_hubiC_2014.pdf](https://hubic.com/en/contracts/Contrat_hubiC_2014.pdf)

The bandwidth is limited to 10 Mbit/s upstream and downstream.

Still, it's good to have a cheap offsite backup to complement a local one.

<comment><USER3> It would take roughly 900 days to upload the data at that speed.

<comment><USER4> I think you're off by an order of magnitude.

10TB == 10,000GB == 10,000,000MB

10Mbit == 1.25MB

10000000/(1.25 * 60 * 60 * 24) = 92.6 days

Time to upload is probably not a problem, you gradually add to it over time. Time to download all the data in the event of a disaster is the bigger issue. There aren't a lot of use cases where you'd need all the data back ASAP but if you have such a case, don't rent this storage.

</comment></comment></comment><comment><USER5> Great timing. I have just decided to move away from Google Drive - had all sorts of problems with it in the past months - including sync conflicts, connection problems and crashes.

</comment><comment><USER6> File storage and sync market get commoditized. E.g. for Dropbox pro with 1 TB $99/year + taxes. So this is roughly 20 times cheaper.

</comment><comment><AUTHOR> It uses OpenStack Swift so it is compatible with a bunch of existing tools.

<comment><USER7> Although it requires a prior additional authentication step with OAuth 2.0. Cyberduck just added interoperability for in version 5.0.1.

<comment><AUTHOR> Tested it Cyberduck from Belgium.

Upload speed: 1.4MB/s. Close to my maximum of 1.6MB/s.

Download speed: 1.3MB/s. Far from my maximum of 15MB/s.

This could be good for NAS backups.

<comment><USER4> Considering the agreement jankey linked to above says bandwidth is limited to 10Mbit/s (1.25MByte/s) you're getting "bonus" throughput.

I agree, offsite back up of local storage is a good use case.</comment></comment></comment></comment>


Ask HN: What are specific tangible benefits of learning Haskell? - <AUTHOR> I've worked in C/C++ for many years and recently started trying to learn Haskell. As many new people learning Haskell, I am running into issues with not just the quality of learning material but the general attitude of members of the Haskell community. For example, when asking for an explanation of a particular topic recently, I received a barrage of insults about how annoying it is for people to be asking such questions, short unhelpful answers without explanation, a near constant refrain of "ask this question on IRC" because apparently people cannot be bothered to answer questions outside of there, answers which do not actually answer the question raised, various forms of pats on the head and patronizing "You go ahead and think that, Timmy. You'll soon see how wrong you are" styled answers, etc., etc., etc. Some members of the community have been nice but the more abrasive members have left a sour taste in my mouth. Is anyone ready, willing, and able to provide clear and concise explanations of specific tangible benefits of learning Haskell? I've spent almost 6 months trying to learning the language and I really don't feel like wasting another 6 months if it's not worth the effort in the end. If making objectively verifiable arguments, like "functions are more concise", please provide proof of claim. <comment><USER2> To me the value of Haskell comes from its being an extreme point in the language design space: that of a pure, lazy, strictly-typed language. I think that Haskell provides a very nice syntax and GHC a very nice implementation for exploring this extreme point. The primary benefit of this exploration is that it enriches our understanding as a community regarding language design and program design. I think that is a worthwhile enough contribution.

I think that Haskell's strangeness harms it in two ways. One it puts off people because the superficial strangeness takes some getting used to. More dangerously it makes a small fraction of Haskell programmers dangerously arrogant. They feel that just because they are now familiar with this strange jargon they have become superior to the users of other languages. Depending on temperament this turns them into snobs or evangelists.

I don't think there is any concrete evidence of Haskell's superiority as a practical tool. Programs like pandoc, darcs or xmonad are great but there is no proof (and as far as I know neither have their authors claimed) that they were easier to develop than comparable programs in imperative languages (TeX, git?).

Much better is the attitude of Haskell leaders like Simon Peyton Jones who present Haskell as a ongoing research project with its set of successes and unsolved problems: [http://research.microsoft.com/en- us/um/people/simonpj/papers...](http://research.microsoft.com/en- us/um/people/simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf) [http://research.microsoft.com/en- us/um/people/simonpj/papers...](http://research.microsoft.com/en- us/um/people/simonpj/papers/marktoberdorf/)

<comment><AUTHOR> So, the only tangible benefit you see is "it enriches our understanding as a community regarding language design and program design"? To be clear, when you say, "I think that is a worthwhile enough contribution," are you saying this benefit of enrichment is "worthwhile enough" to warrant learning it?

<comment><USER2> Yes to the first. For the second, it is worthwhile enough for some people and I think it is a net benefit to society. Whether it is worth your time depends on your tastes and priorities.

</comment></comment></comment><comment><USER3> I too found learning Haskell difficult, because there is, or so it seems, quite a big hurdle to get over at the start.

But it turns out that you can live in the IO Monad and just write Haskell as if were a strongly-typed kind of Python, and quickly get to the point where you are doing something useful, and benefiting from the type system and lazy evaluation (e.g. being able to define an infinite list then just consume as much of it as you want) and the nice syntax for pattern matching, and so on. Then you can gradually add in more and more Haskell concepts as and when a) you feel ready and b) you encounter situations where they'd be useful.

Jumping straight in with monads is the wrong way to do it (and monads are actually easy if you let them sneak up on you rather than trying to chase them, like cats) and the monad tutorials you find on the web are all written by idiots who think they a lot cleverer than they are. Burrito Spacesuit guy, I'm looking at you.

<comment><AUTHOR> So, are you saying there are no tangible benefits?

<comment><USER3> Not at all, there are loads, see for example [http://donsbot.files.wordpress.com/2009/01/semicolon.pdf](http://donsbot.files.wordpress.com/2009/01/semicolon.pdf)

What I'm saying is, don't let a minority of the community put you off. The "conventional wisdom" on how to learn Haskell, is wrong.

<comment><AUTHOR> Thanks for the link. I see 5 benefits listed. Concise code; native code optimization (LLVM) and compilation; parallel and concurrent runtime; debuggers, profiling tools, refactoring, coverage, testing tools; library support, distribution mechanisms. With the exception of concise code, however, I think I get the rest with a combination of clang and a good static analyzer, no?

<comment><USER3> What's your static analyzer? It's probably written in OCaml, which some call the "practical Haskell".

[https://github.com/facebook/pfff/wiki/Main](https://github.com/facebook/pfff/wiki/Main)

[http://frama-c.com/](http://frama-c.com/)

<comment><AUTHOR> PC-lint. It has served me well.

</comment></comment></comment></comment></comment></comment><comment><USER4> [http://www.paulgraham.com/know.html](http://www.paulgraham.com/know.html)

Learning Haskell adds to the mass of things you know, and the volume of that mass determines the level of your general expertise.

You asked for tangible things, but it's harder to see what those may be. Perhaps your perception will be enhanced: perhaps you will better see and care about side-effects, opportunities for pure functions, etc.

I don't think any learning effort that leads to increased knowledge can be a waste of time.

<comment><USER5> In absolute terms, no, learning is never a waste of time. In a world with limited time, though, everything has its opportunity cost. The time spent learning A could have been spent learning _any_ of B through Z.

So: "Is Haskell worth learning?" Yes, certainly. "Is learning Haskell the best use of my limited time for such activities?" That's a much harder question.

(And it doesn't have to be _the_ best use of your time. It could be close enough that it's not worth the time looking for something better.)

<comment><USER6> I think the opportunity cost is meant to be weighed in any question of "is X worth it?"

That said, I appreciate your calling it out specifically (even if I'd have used other words), as that is absolutely the real question.

My answer, I'm sure you'd guess, is "yes" \- but certainly I agree that it's harder than the same question but ignoring the costs :-P

</comment></comment></comment><comment><USER7> Funny, I once asked the same question about pure mathematics, and got similar answers. In the end I decided pure math wasn't the best bang for buck in terms of benefit to humanity, and decided to work on other things.

When it comes to Haskell, there is a big problem that the people best qualified to speak on the matter have invested a lot of time in Haskell, and therefore are subject to biases associated with their investment in the field.

For one thing, I would ask what programs use Haskell. The only major project I'm aware of is xmonad. This should tell you something about how practical Haskell is.

On the other hand, you may learn something from Haskell. I studied Haskell because I believe there are much better languages out there, and in order to find them we need to understand and improve on the theoretically most advanced languages (i.e. dependently typed languages) and learning Haskell was the best starting point. If this is not your goal, I actually doubt another 6 months of Haskell will help your day to day programming.

Also, what have you managed to learn in the past 6 months? And how were you studying? I found Learn you a Haskell to be the best introduction.

<comment><AUTHOR> I am confused. If you feel there are much better languages than Haskell, how would Haskell be the "theoretically most advanced language"?

As far as what I have learned and how I have been studying, I did try "Learn You a Haskell" but found its explanations inadequate and sometimes confusing. Searching the web, I find a number of people feeling the same. Meanwhile, I find a large number of people agreeing with your experience the text is the best introduction. I think the fact the supposed best text is utterly failing a sizable number of people also suggests how worthwhile Haskell might be.

<comment><USER8> > I think the fact the supposed best text is utterly failing a sizable number > of people also suggests how worthwhile Haskell might be.

I think it says a lot more about the fact that learning (and, therefore, the best text for learning) is highly subjective than it does about the worth of Haskell.

I mean, how does the logic even work that leads from "some people think that this text is good for learning about X but I find it is 'inadequate and sometimes confusing' to me" to "X isn't generally worthwhile" even work?

<comment><AUTHOR> > I mean, how does the logic even work that leads from "some people think that > this text is good for learning about X but I find it is 'inadequate and > sometimes confusing' to me" to "X isn't generally worthwhile" even work?

I'm pretty sure I did not make that particular claim. I have trouble learning from the supposed best text; others have trouble learning from the supposed best text; asking questions gets me treated with hostility and non- helpfulness. I want to know what I am going to get out of learning the language if I put additional time into it. If I am not going to get any more from Haskell beyond (a) what I already know in C/C++ and (b) the ability to put Haskell on a resume, the question of cost/benefit analysis arises quite quickly.

</comment></comment></comment></comment><comment><USER9> There are two languages that more than anything changed how I thought about programming.

The first is Lisp.

The second is Haskell.

Lisp taught me, essentially, that most of what I'd been doing in other languages was unnecessary tedium, and introduced me to the functional style for the first time.

Haskell taught me that even some of what I was doing in Lisp was itself unnecessary tedium, and that things like typing that I'd found tedious in other languages, could actually work to my benefit. Even though I still don't code in Haskell as my main language, it made a functional believer out of me, and still affects my coding style and the design projects I've done since.

As for 'objectively verifiable', well, go look at most any equivalent program in Haskell or Lisp to one in C or Python and just compare how many code lines it takes to do the same work. All the 'design patterns' and 'constructors' and costly looping constructs and everything else falls away for so much tedious bullshit when you get your hands on a language with proper functional tools. And the benefits to sanity of writing in a state-free style are literally the reason I left purely imperative languages behind.

Even the best, least tedious code I see in imperative languages usually comes from people who've had experience in functional languages: probably my favorite Python programmer to read is Peter Norvig, because his Lisp background shows through even in his Python code. This is why people say over and over again that, even if you never touch a functional language again, it's still good to learn at least one, because it will improve the way you code and how you think about functions and composition of same.

</comment><comment><USER10> Here is a tangible benefit of learning Haskell which people agree on _almost universally:_ learning Haskell _will_ make you a better programmer _even in other programming languages._

You will want to code using more elegant, more composeable and succinct, methods. You will want to break things down into small, provably correct units, and then combine them into larger solutions which take advantage of the proven correctness at the lower levels.

You will want to lean heavily on the type system and encode as many of your program constraints in there as possible, leaving your unit tests free to only deal with the logic of your code.

Even if you never write a piece of Haskell code again, you _will_ find over time that more and more ideas from Haskell and similar languages are bleeding through into the languages you use. C++? Closures, optionals. C#? LINQ (monads). Obj-C? On the path to retirement, replaced with Swift. Java? Lambdas, optionals. Clojure? Typed Clojure. Scala? Scalaz. In fact, Swift? Swiftz. JavaScript? People are building _entire functional languages_ (and reactive frameworks) on top of JS.

These things aren't happening by accident. Haskell is a fertile proving ground for the future of programming.

</comment><comment><USER6> I recently spent a year and a half writing C. There were a couple points where, subjectively, it seemed that my Haskell experience suggested solutions that I would not have found otherwise. One in particular seemed to do quite a bit of heavy lifting over the course of the project. I've been meaning to put together a blog post but have several things above it in both my general "things to do" queue and my "blog posts to write" one.

I apologize on behalf of the Haskell community for any harsh treatment that wasn't deserved, and I wouldn't be surprised if there was some - the tone does seem to have shifted unfortunately.

What were the questions you had, and where did you ask them?

</comment><comment><USER11> I don't think HN is the best forum for this kind of question.

<comment><AUTHOR> Where would you suggest I ask?

<comment><USER12> You can try the /r/haskell subreddit. They'll have more detailed information there, and on the subreddit you can browse some of the topics and projects currently going on in the haskell world, which may give you a better idea of what haskell is capable of.

Also, if you haven't been getting traction with the #haskell IRC channel, try the #nothaskell channel. The title is a little confusing (it should be called something like #notjusthaskell), but they try to be more helpful there than the regular #haskell generally is.

You may also want to check out this recent post about the quality of various haskell resources: [http://bitemyapp.com/posts/2014-12-31-functional- education.h...](http://bitemyapp.com/posts/2014-12-31-functional- education.html)

<comment><AUTHOR> I have seen the /r/haskell subreddit. I lurked there for a few of months and my overall impression of it unfortunately is a sizable portion of people on that subreddit treat others exactly in the way which I have been treated while trying to learn Haskell, which is quite a shame. :-(

Do you have nay experience with the #haskell-beginner channel and knowledge about the degree of helpfulness there compared to #nothaskell?

I will check out the link; thanks a bunch!

<comment><USER11> > I have seen the /r/haskell subreddit. I lurked there for a few of months and > my overall impression of it unfortunately is a sizable portion of people on > that subreddit treat others exactly in the way which I have been treated > while trying to learn Haskell, which is quite a shame. :-(

If you could privately forward me links to some of the examples of behaviour that discouraged you I would appreciate it. I spend a lot of time on /r/haskell and am keen to keep it an encouraging place for new visitors.

My email address is here: [http://web.jaguarpaw.co.uk/~tom/contact/](http://web.jaguarpaw.co.uk/~tom/contact/)

</comment></comment></comment></comment></comment><comment><USER13> Could you elaborate a bit what you want to achieve by learning Haskell?

I'm a Haskell newb as well. Learning it because I'm interested in theoritical CS (category theory, type system, etc).

If you ask me do I have any benefits of learning Haskell, then my answer is no. At least for the moment. But that doesn't stop me from pursuing it.

Of course, your mileage my vary... :)

<comment><AUTHOR> I am looking to write some scientific programs in which I have a good degree of confidence is accurate and are easily understandable, maintainable, and extendible. Speed, in terms of both writing the programs and running them, is also a factor. Theoretically, I can write these programs in just about any language. However, I get the impression Haskell can do all this in a well- balanced way. At the least, I hear claims of such.

</comment></comment><comment><USER13> Perhaps you could elaborate a bit why you are interesting in learning Haskell?

I'm a Haskell newb as well (write apps in Java for daily living). I'm quite interested in theoritical CS, and that's what keep me pursuing Haskell.

If you ask me what specific benefits I get, then my answer is none. At least at the moment.

</comment><comment><USER14> For me:

I can hack something together quickly cutting corners if needed, then refactoring is easy and almost always works on compile when you get around to fixing things up.

</comment><comment><USER15> Spoiler: there aren't any. It's something hipsters, wannabe be mathematicians and idiots that haven't done any real programming like to circle jerk over. If you thought well designed classes were hard to understand and bloated than just wait until it's condensed into an ugly, undocumented, confusing set of alien hieroglyphics that denote instructions for a theoretical machine that doesn't resemble how modern computers actually work.</comment>


China's Hacker Army: A look inside the teeming, chaotic world that exists - <AUTHOR> http://www.foreignpolicy.com/articles/2010/03/03/china_s_hacker_army

<comment><USER2>
      ...a leading figure in the third generation of Artificial
      Intelligence scientists...

Hmm, I remember reading a book back in the 80s about how Japan was going to dominate the world using fourth-generation artificial intelligence systems... What are the three generations being referred to here?

</comment><comment><USER3> Hmm... the article should have taken up two more aspects:

1\. Plausible deniability. For example, the President can't be officially informed. PLO/PA had separate terror groups (but financed by money from Arafat, ultimately from EU). And so on. Governments have an interest in doing their criminal activities without getting their hands dirty. So, considering the hard control of Internet cafés in China, would hackers be allowed to exist if they weren't useful?

2\. The break in at Google did explicitly target Chinese democracy dissident's email accounts. A little bit too useful.

Arguments that groups-for-hire wasn't doing a government's bidding, while doing what the government want, would sound less unlikely if e.g. those criminals are extradited.

Wake me up if that happens.</comment>