What are your unordinary/unusual suggestions for finding a technical co-founder? - <AUTHOR> I know a similar question has been asked/answer before, but thought I'd ask to help others out.
What is a tried and true way to find a technical co-founder for a start-up you're working on?
Let's say the person has not just an app idea, but a live app in the App Store, a business plan, 10k+ downloads, traction, and revenue.
Although this question has been asked many times before, I'm wondering if you have any unordinary/unusual suggestions.
I appreciate your help and hope others can also benefit from this question too! <comment><USER2> Plenty of people are working as "Cloud CTO's" these days - Basically senior developers (with or without a team of their own) who can help you architect, build and scale your products. Some work on cash, some purely on equity also. They will also offer solid tech advice on other aspects like SEO, Digital Marketing etc. though they may not be experts in those.

In my experience, good technical guys are either blocked by large corporations (the Google's and Microsoft's of the world) or are doing something of their own, so finding good cofounder/CTO talent is a big challenge. The cloud CTO model has worked well for a surprisingly large number of startups.

Disclosure: I work on the same model as well.

</comment><comment><USER3> Try making friends with some technical people. Not on a transactional, I-make- a-post-on-HN-and-we-go-into-business-together level, but on an actual, get-to- know-them, build-a-relationship level.</comment>


The Doxing Trend - <AUTHOR> https://www.schneier.com/blog/archives/2015/10/the_doxing_tren.html <comment><USER2> In spite of the headline, this article is not so much about doxing. It's about the fact that doxing is way too easy, because companies are ridiculously lax about keeping people's private information safe.

Schneier is arguing for government regulation, and letting people sue for damages after an information breach, and I think he's right. We have enough data at this point to show that very few companies are going to take good care in this area unless a regulator or their insurance company forces them to. It's too hard, it's too expensive, and it's too easy to brush off the consequences when the inevitable breach happens.

<comment><USER3> _> It's about the fact that doxing is way too easy, because companies are ridiculously lax about keeping people's private information safe._

Even more that _people_ are terrible at keeping their own information safe. A collection of one-off facts over the past 8 years of a person's internet life can paint a rather vivid picture. You can tell how many relationships they have been in, if they have a new job, what country they live in, what _town_ they might live in, what their pet's name is, who their friends are, and more.

With enough metadata it becomes trivial to find their social profile (where they often speak about bits of information contained in the metadata) and then you have their full name, family, friends, etc. At that point it becomes trivial to find more information on them.

Informing people is rarely enough to get people to understand. On the contrary - they'll blast all the info you need to know on their Facebook or Twitter. They'll take pictures of local parts of town and post them on Instagram, etc.

It's extremely hard to be doxed unless the _user_ shares information with the public. It's extremely rare to be publicy doxed due to leaked credit card information or a company being hacked and a database being released.

<comment><USER2> Schneier really isn't using "doxing" the way you and I would. He's using it to refer to what happened to Mat Honan[0], when someone managed to social engineer Amazon customer service and Apple tech support to take over Honan's accounts. Honan didn't do anything wrong, or release too much data to the public. He simply made the "mistake" of owning @mat on Twitter. Someone wanted the username, so they tricked Apple tech support (using data they got by calling Amazon) into thinking they were Honan, hacked into his account and took what they wanted.

The point of the article is that in a case like this, Apple and Amazon are both at fault, and should be held legally responsible.

[0] [http://www.wired.com/2012/08/apple-amazon-mat-honan- hacking/](http://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/)

<comment><USER3> So after all the years of misusing and redefining "hack" they are now jumping ship to "doxing" to misuse that when their redefined version of "hack" is acceptable? Gah!

Thanks for the explanation. I do agree companies should be held responsible when they are too lax on identifying people as who they claim to be.

OTOH, I can see customer complaints about slow service and constantly having to prove identity w/ 4 last of SSN and such. It's an area where idealism and reality don't meet very well.</comment></comment></comment></comment>


6.S974 Decentralized Applications, Fall 2018 - <AUTHOR> http://nil.lcs.mit.edu/6.S974/ <comment><USER2> I would take this, if i were in school.

This project assignment is good: "Build an ambitious multi-user decentralized application on top of some existing infrastructure, or on your own new infrastructure."

If decentralization is going to have a chance, it either needs to integrate with existing services or offer some niche where it provides x10 the value.

</comment><comment><USER3> I'd enroll in this class in an instant if I could.

Fun fact: the instructor, Robert Morris, co-founded YC and was one of the first people to be indicted for a computer crime.

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

</comment><comment><USER4> Really good historical background on one of the most interesting topics in CS right now. The mission statement up front seems to imply that decentralization of data is a direct check against the concentration of power.

A few more subjects I'd like to see covered: rare digital art, fintech exchanges such as Stox, aggregating data science on platforms like Numerai, fractional ownership of real estate, voting systems, and peer-to-peer lending.

</comment><comment><USER5> Will they make video lectures available as open courseware?

<comment><AUTHOR> Not sure. The attached readings and class notes are great resources though.

<comment><USER6> Yes, a well curated list of the vital papers for blockchain competency:

[http://nil.lcs.mit.edu/6.S974/papers.html](http://nil.lcs.mit.edu/6.S974/papers.html)

</comment></comment></comment><comment><USER7> > Pre-requisites

>You'll need a 6.033-level understanding of the web, SSL, security, public key cryptography, and _Bitcoin_

Interesting.

</comment><comment><USER8> Are there no-cost courses that cover the same material and have already completed?

</comment><comment><USER9> Must read:

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

I think the future is a community overlay platform like i2p or similar where people can donate with micropayments or electricity/computing power to access/offer storage, computing, networking and other higher-level resources anonymously and privately.</comment>


How to avoid appearing "difficult" when you refuse to reveal your last salary? - <AUTHOR> http://www.quora.com/How-can-you-avoid-appearing-difficult-when-you-tell-a-recruiter-you-wont-reveal-your-last-salary

<comment><USER2> The recruiter is supposed to be on your side, so it makes sense to share this information. I went through a recruiter to get my last two jobs, and was able to secure a 35% and 37.5% increase each time (same recruiter), and she was well aware of my compensation each time. She said that in both cases she was prepared to share it with the companies, but they never ended up asking. I think that if the companies like you enough, they will offer you what you're worth, regardless of what you were making before. And I'm sure they can figure out the number within a reasonable range using Glassdoor and salary.com anyway.</comment>


BP oil spill clearly foreseeable on monitoring software, official - <AUTHOR> http://www.computerworlduk.com/news/it-business/3256288/bp-oil-spill-clearly-foreseeable-on-monitoring-software-official/

<comment><USER2> There is a real conflict when designing systems for control of these types of processes, between "too much alarming" and "not enough alarming". They both have the same consequence -- a lack of trust in the control software. The too much alarming case is obvious, but the too little case also leads to a lack of trust like this:

1\. software doesn't alarm when operator thinks it should

2\. bad consequence

3\. thoughts of "software doesn't work"

4\. valid alarm not trusted in the same way too many false positives.

This sequence of events is not necessarily rational, but it is human non-the- less.

There is a lot of really cool work going on, and a lot more to be done, in this space. Current best practices include lots of training for operators, who do an awful lot of "flying the factory by feelings and hunches", rather than by good, informed software interaction.

</comment><comment><USER3> Here is a related interesting article on what any industry can learn from this incident in regards to risk management and regulatory oversight.

Two pointers: 1) Ensure layers of controls are implemented and tested for known risks.

2) Do not underestimate or ignore the low risk vulnerabilities. It does not take many in aggregate to result in catastrophe.

[http://www.redspin.com/blog/2011/01/07/lessons-learned- from-...](http://www.redspin.com/blog/2011/01/07/lessons-learned-from-the-bp- well-blowout-for-your-industry/)</comment>


Welcome To Zaffoo - <AUTHOR> http://www.zaffoo.co.uk Create your own premium Online shop with ZAFFOO, fully featured and cost effective. Reach your target market. Reach your potential.
ZAFFOO Specialist software and Hosting provides you with an innovative e-commerce solution, build your own shop at a fraction of the cost.
Free e-commerce website – pay only for the hosting! Simple to use with comprehensive back end management. <comment><USER2> are you asking us to review this? Please give _some_ information on it. Why did you make it? how did you make it? whats your exit?

</comment><comment><USER3> Save your logo as a PNG or GIF.</comment>


Web Trumps by MJOM Cards - <AUTHOR> https://mjom.cards <comment><USER2> Definitely the best xmas present for geeks this year :)</comment>


Ask HN: Need Start-up Critiqued :) - <AUTHOR>

Hi All, I don't have faith in my servers in case the the traffics peaks out - I've heard horror stories from Start-ups posting their website on HN because of the unexpected rush.
That being said, Fellow HN's if your email is in your profile - can you let me know so I can send you the link individually. Be INCREDIBLY critical and ask any questions if necessary.
It's for non-profits, Thanks. <comment><USER2> mail at arsalanbashir dot com :)

</comment><comment><USER3> Mine is. :)

<comment><AUTHOR> Sorry you all - but on HN your email has to be in bio section for users to see it.

<comment><USER3> ah newbie alert. sorry. if you still would want a critique (i hope you do ;)) pls do reach me at chandru89new on Gmail.

</comment></comment></comment><comment><USER4> same here!

</comment><comment><USER5> Me!

<comment><AUTHOR> Look out for a link! Thanks.</comment></comment>


20 Must Have Tools For Small Businesses - <AUTHOR> http://www.forbes.com/sites/tanyaprive/2012/10/18/20-must-have-tools-for-small-businesses/

<comment><AUTHOR> Ok,except GoDaddy.

<comment><USER2> What's the problem with GoDaddy?

<comment><USER3> Their CEO is offensive, their user interface is awful, they screw with DNS, they're typically on the wrong side of supporting internet regulation in the US, they try to upsell you on everything...

In complete contrast to GoDaddy, I really like the exposure that the DreamHost panel gives you to your hosting configuration. It's straightforward and made for people that know what's going on under the hood. Also, they keep the mail they send you to a minimum and when they do send you something, it's worth reading. I tend to recommend them to even my non-tech friends when they need to register a domain or need hosting.</comment></comment></comment>


Ask Y Combinator: Notification information for W2010? - <AUTHOR>

1) Originally, tomorrow was the day that applicants would hear if they should book a flight for demo day.  But the application deadline got extended two days due to the Twitter and Justin.tv deals.  Are things still on track for tomorrow?
2) Will all applicants be notified of their status, or just the ones who are invited to demo?
3) Is there a specific time that you expect applications will go out by?
I hope this doesn't sound pushy; I wanted to set realistic expectations for myself.  Thanks for the opportunity to apply. <comment><USER2> By the way: thanks for asking this. I was wondering the same things. I'm trying to concentrate on coding today, but there's this constant buzz in the back of my brain wondering about the application; I haven't been able to get rid of it.

</comment><comment><USER3> yes, yes, no

<comment><AUTHOR> Thank you.</comment></comment>


Is there a company that sells meal planning? - <AUTHOR> I'm spending so much $ on Munchery, because I am not good at planning my shopping / cooking / eating. I have a small repertoire of cooking recipes, I don't know whats seasonal, etc. Also, planning just takes a lot of time.
Is there a service I can pay to just give me shopping lists and quick easy tasty recipes each week?
Then I can just put the shopping list into instacart and be ready to go.
I know there are a lot of shitty recipe websites and outdated cooking blogs but I'm looking for something quality and reliable, with an easy-to-use experience. <comment><USER2> The Ontario government has you covered: [https://www.eatrightontario.ca/en/MenuPlanner.aspx](https://www.eatrightontario.ca/en/MenuPlanner.aspx)

<comment><AUTHOR> HAHAHA

</comment></comment><comment><USER3> Isn't that what Blue Apron is for? [https://www.blueapron.com/](https://www.blueapron.com/)

Still kind of pricey at $10/meal.

<comment><AUTHOR> no but they sell you the food too. I want to just get the food from the cheap mexican market near my house.

</comment></comment><comment><USER4> [https://emeals.com/](https://emeals.com/)

<comment><AUTHOR> yeah that looks like the right idea but that site looks 20 years old. is it even still working?

<comment><USER4> Yes, it is. I use it (the featured meal this week is Cuban-Stuffed Pork Tenderloin), and like it quite a bit. They have menus for restrictive diets as well as menus to take advantage of sales at certain food retailers. Their menu is better than their website (which actually is better than it used to be), and they have a decent android app.. They have a free trial, check it out - [https://emeals.com/account/trial.php](https://emeals.com/account/trial.php).</comment></comment></comment>


Turing is being pardoned, which is short of being exonerated. - <AUTHOR> http://www.newstatesman.com/david-allen-green/2013/07/putting-right-wrong-done-alan-turing <comment><USER2> Somewhat related: [http://blog.jgc.org/2011/11/why-im-not-supporting- campaign-f...](http://blog.jgc.org/2011/11/why-im-not-supporting-campaign- for.html)

</comment><comment><USER3> Flagged, not only is this an old article but the consensus around the traps for the current links is they are fakes that a couple of lazy mainstream news site picked up unverified.

<comment><USER3> I was wrong. Unflagged.

</comment></comment><comment><USER4> I'm sure he's excited.</comment>


DeepLog: Anomaly Detection and Diagnosis from System Logs Through Deep Learning [pdf] - <AUTHOR> https://www.cs.utah.edu/~mind/papers/deepLog.pdf <comment><AUTHOR> Anomaly detection is performed at two levels:

1\. A log key anomaly detection LSTM model (a type of recurrent neural network) predicts the next log message type (log key). If it is wrong for any log entry, the operator is alerted that there is an anomaly in the execution flow.

2\. If there is no anomaly in the execution flow, the parameter value and performance anomaly detection model is invoked. If the predicted parameter vector for that particular log key is very different from the actual parameter vector, the operator is alerted. The second model performs regression, in high-dimension space of the parameter feature vector. Therefore, the mean- squared error (MSE) is used as the loss function when training this model and when deciding to alert the operator.</comment>


The Perfect Compliment - <AUTHOR> http://www.esquire.com/features/how-to-compliment-1009

<comment><USER2> <http://news.ycombinator.com/item?id=4199015> with discussion, and currently #6 on the Front Page.</comment>


Search Engines: Specify your canonical URL - <AUTHOR> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html

<comment><USER2> Regarding the question of whether Google is a monopoly or not: non-monopolies cannot easily cause a new Internet standard to spring into being simply by announcing that a program of theirs will now apply specified behavior to a previously undefined syntactical element.

This line has a whole lot of chutzpah:

"This _standard_ can be adopted by any search engine when crawling and indexing your site."

[Edit: Incidentally, I will have this implemented on my site by the end of the day. Because I'd be an idiot not to. Google is, I think, probably the only company who can create "drop what you are doing, now, this is your new priority" work for me besides my _actual employer_.]

<comment><USER3> (Agree with most of your points)

Yahoo and Google have both posted things before to the effect of "web authors: it'd really help us out if you did X", and often times the other will adopt the convention. The spec only describes some uses of link elements for example, so it doesn't really seem like an abuse of anything as much as it is a case of saying that something which was previously undefined now means something to you (or them).

</comment></comment><comment><USER4> You are much better off with doing the following: (1) All responses for non- canonical URLs are 301 redirects to the canonical URLs, (2) Your website will never link to a resource using a URL other than its canonical one, (3) you encourage people to link to pages on your site using the canonical URLs.

This way your site will be very cache-friendly while still being usable. Also, all search engines will be able to understand your site without any proprietary extensions (a.k.a. "standards" at Google, apparently) being needed.

<comment><USER5> I generally agree with that approach, but Google gives an example of pages with query strings that need to have different URLs because they are subtly different, but not in a way that search engines need to care about.

OTOH, Google's wiki example is bogus; people have been telling MediaWiki that they should be using 301s for years but they just won't. This workaround just encourages them to never fix it.

<comment><USER6> It's not just one example, you can 'hurt' a website simply by making a huge list of links with arbritrary query string garbage so that google picks it up, eg:

<http://domain.com/?dupcontent>

<http://domain.com/?blabla>

What an app should really do is validate the arguments in the query string, remove any invalid ones, then issue a 301 redirect to the proper url.

For example:

[http://www.google.com/search?q=someterm&unknown_variable...](http://www.google.com/search?q=someterm&unknown_variable=nothing)

redirects to

<http://www.google.com/search?q=someterm>

Of course that's like getting everyone's CSS to validate correctly :)

Edit: It is also why I prefer to sort my query string so that it can be deterministic and always be the same no matter what order the args are in.

<comment><USER4> That kind of attack won't work on a website that does a 301 redirect from all non-canonical URLs to the canonical ones.

</comment></comment></comment></comment><comment><USER7> Why didn't they use the already established rel=bookmark value from the hAtom microformat? That's already in the wild on countless blogs and websites.

I swear, sometimes Google's awareness of existing web conventions is _shockingly_ lacking.

<comment><USER3> Maybe I'm crazy, but a canonical URL is different from an hAtom permalink.

Besides, its a canonical URL for the whole document and not just a portion of a page. How does Google know what the scope of a given rel=bookmark is? What if people already use it, and using it in a way with a slightly different way would pollute hAtom?

<comment><USER7> Well, that's why you'd use a <link> tag instead of a <a> tag.

Link tags in the head are information about the whole document. Anchor tags are more vague in their semantics, and in the context of an hAtom item, <a rel="bookmark"> would be the link to the canonical URL for that item.

For a document, <link rel="bookmark"> would be the canonical URL for that document. As in, "If you are looking to save or _bookmark_ this document's URL, you should do it using this URL over here."

</comment></comment></comment><comment><USER8> (Black hat on) This might be very interesting for some types of injection attacks. Instead of simply getting backlinks you could steal the pagerank of your victims without leaving a visible mark. Limited to subdomains, though.

<comment><USER9> No, it's the same domain, so unless your victims are your co-workers, it won't work.

</comment></comment><comment><USER10> I've got a site that runs on both http and https.

Is a protocol change enough of a difference to consider the identical content as a duplicate?</comment>


Managing Secrets with Ansible Vault – The Missing Guide - <AUTHOR> https://dantehranian.wordpress.com/2015/07/24/managing-secrets-with-ansible-vault-the-missing-guide-part-1-of-2/

<comment><USER2> Why don't you just specify the modes in the task, rather than in the encrypted vault? That way you can use your octal representation, and more of your configuration is inspectable, without owning and using the vault keys.</comment>


FBI says pirated Android apps a "top priority" - <AUTHOR> http://arstechnica.com/tech-policy/2012/08/fbi-says-pirated-android-apps-a-top-priority-seizes-three-domains/

<comment><USER2> I guess pirating really isn't because it's "too expensive". Oh yeah, 99 cents is too expensive for some people.</comment>


Go vs. Swift [pdf] - <AUTHOR> https://github.com/jakerockland/go-vs-swift/blob/master/go-vs-swift.pdf <comment><USER2> I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance.

The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication.

Go is a very original language in this aspect as well as with concurrency. Understanding and mastering these properties goes beyond simple syntax analysis.

To me the most remarkable property of Go is its simplicity. As I explained to a friend who is a strong advocate of D, the difference with other programming language is the same as dealing with a spoken language of 1000 words instead of 10,000 words. It's true that the language with 10,000 words is more expressive and richer. But the effort required to learn, read and write a language of 1000 words is much lower than a with a language of 10000 words. I'm beyond 50 years old, and too me this makes a huge difference. The best way to express it is that _with Go programming is fun again_. I hope that Go will preserve this simplicity. At the beginning Java was simple too. They later killed it to the point I don't want to deal with Java code anymore.

<comment><USER3> > Go is a very original language in this aspect as well as with concurrency

Actually it isn't.

Using object Composition/Aggregation is a very old, and composition as the recommended paradigm dates back at least to COM (that's just my memory, it's probably older). Granted, delegation in COM aggregates was based on conventional interface and not structural typing, and it was implemented using ugly C macros, but dynamic languages made it easier and far more flexible. Kotlin even made it part of the language: [https://kotlinlang.org/docs/reference/delegation.html](https://kotlinlang.org/docs/reference/delegation.html)

What Go has, despite all the hype, is not real composition with delegation though, but a crippled form of inheritance. With proper composition, your child objects are named, and you can choose which interfaces you want to delegate to which object. This doesn't just give you better control over which functionality you wish to expose, but also avoids conflict when two member objects implement the same interface. In Go you essentially get the same nasty diamond problem of multiple inheritance, with none of the benefits. Sure, you can disambiguate your method calls, but you could do the same in C++ and Python.

As for Go's approach for concurrency obviously isn't new. The CSP model was implemented by Rob Pike in at least 3 different languages previous to Go (Newsqueak, Alef and Limbo) and theory behinds it dates to research by Tony Hoare in the late 1970s.

I won't argue with you that Go is simple, but it's not revolutionary. As for the fun, I think that really depends on the individual. I know many people who think Go is fun, but for others, like me, it's about as fun as fingernails on chalkboard. There seem to be a strong correlation between people who like functional programming (especially the ML camp, but also the LISP camp).

For me coding in Go is plain drudgery: error handling boilerplate, noisy imperative looping (and in general very low SNR) and almost no ways to create abstractions. Yeah, you can make very useful and down to earth software in this language and it's currently satisfying much of my microservices needs at work. But it isn't what I would call fun.

<comment><USER4> > With proper composition, your child objects are named, and you can choose > which interfaces you want to delegate to which object. This doesn't just > give you better control over which functionality you wish to expose, but > also avoids conflict when two member objects implement the same interface.

Oh but you can avoid that, it's part of the language, see this link:

[https://golang.org/doc/effective_go.html#embedding](https://golang.org/doc/effective_go.html#embedding)

Typically, you can have something like this:

        type lockedReader struct {
            io.Reader
            sync.Mutex
        }

        lr := lockerReader{someReader, sync.Mutex{}}
        lr.Lock()
        lr.Read(...)
        lr.Unlock()

By default, methods will be delegated to the first field that has the method. If you want something else, you are free to override this default behavior.

<comment><USER3> No they're not. io.Reader and sync.Mutex do not embed the same type and do not have conflicting methods with the same name.

This is how a diamond looks like:

      type Base struct {
        Foo int32
      }

      type Child1 struct {
        Base
      }

      type Child2 struct {
        Base
      }

      type Diamond struct {
        Child1
        Child2
      }

      func (c *Child1) DoSomething() {
        fmt.Println(c.Foo)
      }

      func (c *Child2) DoSomething() {
        fmt.Println(c.Foo)
      }

      func main() {
        c := Diamond { }
        c.Foo = 42       // Doesn't Compile
        c.Child1.Foo = 10
        c.Child2.Foo = 20
        c.DoSomething()  // Doesn't Compile
      }

</comment></comment></comment></comment><comment><USER5> I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]?

I would rather see a discussion about performance, platform support, maintainability, governance and do on.

\---

[1] someone please create a new programming language where the empty file means "print hello world". Since you can't do any better than that it would once and for all put an end to this stupid benchmark.

<comment><USER6> The author notes here (in the HN thread) that it's a very very cursory overview and there are plans to add more later given time. This could have been a blog post (or series of blog posts), so maybe the academic-paper feel was misleading.

While I'm not sure this content should be on the front page, it never was represented as a very deep comparison. I do admit that when I read it through I expected much more.

Also, how do you determine what libraries to use and what projects to invest in these days? Do you always do a full audit of every project? I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. If a ton of people think a thing is useful, it's probably at least a little useful. Of course, that kind of thinking can be dangerous (see: javascript ecosystem), but a lot of the time, it's "good enough".

BTW, the paper does cover a tiny bit of information regarding differences in platform support when it covers how Swift deals with concurrency.

<comment><USER5> > I know I don't have the time, so I use stars on a Github project just like > one might use word-of-mouth.

Up to a certain point, stars can be useful as it helps you discover projects other people have found of use. But saying project X is better than project Y because it has more stars? What does it show other than more people using X are on github or people using X a more prone to push the star button?

For reference, bootstrap has 100K stars, Linux has 40K...

<comment><USER6> Oh I definitely am not trying to imply you should use a project just because it has more stars -- maybe the right term was "hype" instead of word-of-mouth

</comment></comment></comment></comment><comment><USER7> The more I use swift, the more I've grown to appreciate the concept of Optionals and how the compiler enforces it's usage. I have found that my swift code is more robust and explicit than my ObjC or Android java code is, as well as the team members around me.

<comment><USER8> > the more I've grown to appreciate the concept of Optionals

You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs.

Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenever a function returns one.

There's another ADT, usually called "Either" or "Result", that allows you to shift exceptions to the type level. You can see from the type of the function what kind of exception it might return, and you deal with exceptions like any other value instead of via a special exception handling mechanism.

<comment><USER9> One of the things that makes Optional so pleasant in Swift is the syntax support. This includes optional-chaining, if-let and guard-let unwrapping, and some convenient operators.

For example, in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. But in Swift this works like you would want.

All that is to say that Options in Swift are a bit nicer than what you could get with pure ADTs. It's a similar story for Swift's syntax-level error handling vs type-level monadic error handling. (The downside of course is that the compiler has to be specially taught about these - but maybe you want that anyways, e.g. for Rust's null-pointer optimization.)

<comment><USER8> > This includes optional-chaining,

Haskell has bind (>>=) and do-syntax, rust has `and_then`. This is pretty standard with any ADT-supporting language.

> if-let

Most languages with ADT support have good pattern matching that subsumes if- let syntax and allows you to do other things as well. Swift's pattern matching, such as it is, is a bit of a mess.

> guard-let unwrapping

Haskell has `guard` and `MonadFail`, which address the use cases for this in a more principled way. `guard` for boolean matching (like equality) and `MonadFail` for structural matching (like pattern matching on a constructor).

Rust has (?) and `try`, which are syntactic sugar around a simple match/return statement that addresses most use cases of guard-let.

Obviously there are going to be small differences between this implementations, but Swift doesn't really excel here.

> `5 == Just 5` fails.

As it probably should. Supporting such implicit casting could lead to some obvious confusion and buggy behavior. Ideally, the fact that "a == b" typechecks should indicate that "a" and "b" are of the same type.

In Haskell, you would just do `Just 5 == x` if you want to check that something is, in fact, `Just 5`. If that really wasted a lot of space somehow, you can define something like `x ==: y = Just x == y`.

<comment><USER10> Rust copied 'if let' from Swift (~2 years ago) despite having decent pattern matching; community consensus today is that it's highly worthwhile as a feature. There have also been proposals to add 'guard let'. So, while I don't have enough Swift experience to judge its ADT support overall, I wouldn't cite those features as evidence that it's wanting. They might not be as natural in traditional FP languages like Haskell, but they seem to fit pretty well in the stylistic niche Rust and Swift (among other languages) have carved out.

edit: FWIW, there's some overlap between '?' and 'guard let', but not that much. Using hypothetical Rust syntax, they'd overlap in this case:

        guard let Some(x) = foo else {
            return Err(GettingFoo);
        }

better expressed as

        let x = foo.ok_or(GettingFoo)?;

…but if you want to return something other than a Result, or the ADT being matched on is something custom rather than Option/Result, there's no good way to make '?' do the job.

<comment><USER11> ? is bind for Either monad if you squint.

`context(e?)` becomes `e >>= \x -> context(x)`

<comment><USER12> You mean `e >>= context` ? ;)

<comment><USER11> Hah!

I should have been clear about CPSing things first so I didn't need to eta- expand :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Swift: better OO, syntax, IDE; Go: built-in concurrency;

Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

<comment><USER14> I never understand the praise for XCode. I love the iOS specific features like GUI creator out property explorer. But the text editor part is just awful compared to anything else I've used (primarily JetBrains IDEs, but also vim, sublime and some atom). On top of that it also has comparatively poor git integration.

Edit: one thing I forgot is the very slow feedback at least when editing Swift. For syntax error notifications to get updated sometimes takes tens of second which can be very confusing.

<comment><USER15> Yeah agree. While I've moved on, IMHO xcode was generally crap compared to dev envs I used back in the friggin 90's, like Delphi or Topspeed. Not many on HN know much about Delphi, but it set the gold standard for the desktop IDE.

Great thing about Go is you don't need much of an IDE because it's best to just keep Go in its sweet spot, which is services. LiteIDE works great for Go- small footprint,debugging, enough project management to get by. Just like with everything else about Go, you can get a newbie dev going with the Go toolchain actually producing something that works in hardly any time.

<comment><USER16> To add some anecdata, I know three people (myself included) who moved from "playing with Delphi 5 as a student" into iOS dev. And I still feel that ObjC in Xcode is (sadly) the best replacement for Delphi right now:

\- A stable and pragmatic language that interfaces well with the C world.

\- Nice separation of class interface/implementation; ARC is as easy as COM was in Delphi; solid reflection/metaprogramming capabilities (e.g. enumerating properties).

\- Compilation is fast enough on my 5y/o laptop.

\- A standard library that is so good that people never re-invent it.

\- The debugger works really well and is always-on (IntelliJ still has separate "Run" and "Debug" buttons, facepalm).

\- IBDesignable/IBInspectable makes writing your own components as nice as it was in Delphi: [http://nshipster.com/ibinspectable- ibdesignable/](http://nshipster.com/ibinspectable-ibdesignable/)

The points above will probably fall apart with Swift, but right now it's not actually too bad.

</comment></comment></comment></comment><comment><USER17> > Because concurrency is supported through an Apple API rather than being > explicit in the language's design, using it is currently very much coupled > to iOS or macOS development.

I am not sure this is accurate, because libdispatch has been ported to Linux:

[https://github.com/apple/swift-corelibs- libdispatch](https://github.com/apple/swift-corelibs-libdispatch)

They are "...early in the development of this project..." but server-side frameworks use it.

<comment><AUTHOR> This is one of the things I have marked as an issue to elaborate a bit more on.

[https://github.com/jakerockland/go-vs- swift/issues/8](https://github.com/jakerockland/go-vs-swift/issues/8)

Thanks for the link! :)

<comment><USER17> The two differences that I wonder about:

* What is the cost profile of Dispatch relative to the Go scheduler? It seems that Go programs suffer a slow down just to enable multi-threading, for example -- which is not unlike other systems (GHC at some time in the past) that have a similar model.

* Is Dispatch suitable for "millions of threads" ala Erlang? Hundreds of thousands of threads? Dispatch allows you to decide which queue to put things on; but also kind of requires it of you.

<comment><USER18> AIUI Dispatch is suitable for potentially hundreds of thousands of queues. It doesn't spin up thousands of actual OS threads, instead it intelligently manages a pool of OS threads and multiplexes the queues onto them. IIRC each dispatch queue is around 100-200 bytes in size (while empty).

<comment><USER17> Yeah but I wonder about is, is the concurrency truly fine-grained and scalable? For example, you want to do a map over an array of 1 million elements. Can you dump a million blocks on a queue for a linear speed-up?

<comment><USER18> You could dump a million blocks in the queue, but that's probably too fine- grained. Each block is an allocation and there's some amount of overhead to executing blocks (though I've never measured how much). So unless each element actually takes a long time to process, you probably want to batch it up into larger segments. Dispatch has an API explicitly meant for this scenario (doing concurrent work over an array of elements), which is dispatch_apply() in C or DispatchQueue.concurrentPerform(iterations:execute:) in Swift, though the block is just given an index and it has to do the legwork of reading the correct elements from the input.

</comment></comment></comment></comment></comment></comment><comment><USER19> Very basic comparison. Doesn't go into the quality of the generated code, compiler speed or efficiency, etc.

<comment><USER20> I would hope that Go is better in all of the above. It has been available for much longer, and it's supported by a great team.

I want to know how the languages compare for writing code. Dos one make it easier to write more succinct and correct code? Swift is missing concurrency support until at least the next version, for example.

<comment><USER9> Go's compiler emits naive code quickly. For example, parameters are always passed on the stack.

Swift is built atop LLVM, and it emits code more slowly, but supports many optimizations like hoisting, vectorization, etc. that Go does not currently perform.

</comment></comment></comment><comment><USER21> Semi-related, side-by-side comparison of how common things are done in swift and go:

[http://rosetta.alhur.es/compare/swift/go/#](http://rosetta.alhur.es/compare/swift/go/#)

</comment><comment><USER22> Go feels like a beefed up version of C.

Swift feels like a high level language with static typing.

Interestingly, Swift doesn't feel much like Obj-C.

<comment><USER23> With C you almost always know what you have, and can always cast it to anything else you want (safely or otherwise).

With Go, I'm never sure what I have (pointer? reference? something other and weird?), and can't cast things that should be castable.

Either way, I'd still rather take Haskell or Common Lisp, but I'd gladly take C over Go after having used Go for a highly multithreaded communications server.

</comment></comment><comment><USER24> I favored Swift over Go in a small project (developed in my freetime) because it has template / metaprogramming support, and it calls destructors inmediately on unreferenced objects.

Some things that can be improved:

* It needs more support / packages for Linux (and Windows maybe?). I was using Manjaro Linux, and around November 2016 (dont remember exactly), the existing packages in the AUR didnt work anymore.

* No built-in weak collections.

* No source subfolders for the same project when using the buit-in package manager (I dont know about Go in this matter).

</comment><comment><USER25> I use Swift every day and appreciate it a lot, while I have only cursory experience in Go, mostly because it didn't have any real debugger support in the past. But any comparison is rather shallow because at the moment they don't really address the same target usage, and Swift is only minimally supported on the server side where Go is generally used. Give it a couple years and the comparison might be more meaningful.

Once Jetbrains Gogland is up and running I will be playing more with Go.

</comment><comment><USER26> The analysis looked good to me, but I was only able to read it after I downloaded it. I hate to be "that guy", but the Github pdf viewer brought Chrome to its knees.

</comment><comment><USER27> I can't believe many people are making that choice, it strikes me the domains of the two languages don't intersect very much.

</comment><comment><USER28> It's not true that Go requires import "fmt" to print something.

<comment><AUTHOR> I have a note about that:

> Note that Go does support a 'println' function that does not require import- > ing from the standard library; however, this function reports to 'stderr', > rather than 'stdout', and is not guaranteed to stay in the language 19.

</comment></comment><comment><USER29> No mention of functional programming and the idiomatic async calls using closures made popular as of late by JS?

<comment><AUTHOR> This paper definitely has a lot of room for elaboration and improvement. There are some open issues in the repo for things I'd like to add at some point when I have the time, feel free to open new issues if there are other things you think are missing--I'm also welcome to contributions if you'd like to make a PR.

</comment></comment><comment><USER30> I'm confused as to why this piece was written using LaTeX.

<comment><AUTHOR> Because it's nice to learn how to use new tools? Hadn't used LaTeX before and saw this as a good learning opportunity for getting started. I'm confused as to what is wrong with writing this piece with LaTeX?

<comment><USER31> I'm not who you're replying to but I was looking for some way to convert it to an html page. It's unfortunate that the only readable copy is the pdf since it cuts the code examples and renders poorly on my laptop.

<comment><USER32> Interesting, it renders fine on mine (not OP).</comment></comment></comment></comment>


Criticizing the Rust Language, and Why C/C++ Will Never Die (2015) - <AUTHOR> http://www.viva64.com/en/b/0324/ <comment><USER2> It's interesting that his own points argue against his own conclusion. For instance, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology", doesn't jive with the conclusion that C/C++ are here to stay, nor does it agree with his point that he was annoyed with the restrictions Rust placed on him.

If humans are the problem, then a language that restricts these problematic human urges in a way that maximizes safety and extensibility is an important solution. C/C++ does only one of these, and not very well either. Any solution that strikes a better balance will replace C/C++ eventually, and I think Rust is on the right track.

<comment><USER3> I was going to make that exact point. Language design philosophy has shifted. It used to be a question of giving programmers all the tools and trusting them to do it right.

History (the list of CVEs if nothing else) has shown that even the best and most well-intentioned programmers will shoot themselves in the foot on occasion if handed a gun.

Modern language design has shifted to prioritise preventing such footguns, while retaining as much programmer power as possible.

Humans _are_ the source of troubles, and so we give them tools that help them not make mistakes. That's what will actually get Rust adopted (if that actually happens): companies will weigh off the extra productivity (fewer bugs) against the cost of switching.

<comment><USER4> I totally agree, simply because all tools have learning curves. It is one thing to learn a language, but it is another entirely to learn a language + debugger + profiler + static analyzer + IDE + build system + package manager + test framework + test runner, etc.. (Just typing this is giving me Node/javascript anxiety...)

Rust has done an amazing job packing almost all of that into rustc + cargo, and while there is a learning curve it is nothing like the learning curve necessary to produce code of similar quality in C/C++.

</comment></comment></comment><comment><USER5> As I remarked when this article originally came out last year, there's a certain delicious irony in a hit piece on Rust coming from a company that makes its money writing static analysis tools to try and plug the safety holes in C++. :P

<comment><USER6> There is irony all around including in the rust communities own positions - relying on jemalloc and llvm while claiming that reliable software cannot be written in C/C++.

<comment><USER7> Show me where anyone involved in Rust in an official capacity has claimed that "reliable software cannot be written in C/C++"

</comment></comment></comment><comment><USER8> > take, for instance, the inevitable "stop the world" issue during garbage > collection. ... Rust is safe indeed but, unfortunately, far from fast. By > the moment of writing this article, it is comparable to Java, Go, and > Haskell regarding performance

...and then he goes on to show a boxplot graph of (likely) CPU-bound benchmarks. C++ pays a penalty (~1.7x?) and so does Rust (~2.5x).

Well, who cares about CPU?! Yes, okay, lots of you. But if you really care, you rewrite that inner loop of your C++ system in C. And if you really, really, care, you rewrite that inner loop in assembly (or corresponding intrinsics). So, hey, here's what I care about: latency! Many systems designed in C/C++ are thus because until recently it was just about the only game in town for predictable low latencies (refer to the "stop the world GC" paragraph above).

Also, there's no other language out there offering both memory safety and the ability to do things like I/O and system control with memory-mapped registers.

Linking your rust code against C libraries and executables is not-super- painful. So phase-in of rust code is easier than other languages described.

> On the one hand, it's not bad to make programmers ponder if their variables > are stored in the stack or heap and if they can or cannot be handled by > several threads at a time.

Indeed! All the C/C++ static checkers in the world can only hint "Hey this might not be safe, but WTF I have no idea..." only to be declared [FALSE_POSITIVE, IGNORE].

BTW authors of static checkers (like the translators at PVS-Studio) have a vested interest in unsafe languages like C/C++.

<comment><USER9> The benchmarks are from The Computer Language Benchmarks Game. I used to think this was a good way to compare programming language performance. But if you look into the results in detail, it's really not that simple.

If you look at rust vs C, you'll see many cases where rust is on par with C, or beats C.

When you start comparing WHY some rust version of a program is twice as slow as the C version, usually what you'll find is that someone has not spent the same amount of effort optimizing that program. Or in some cases, you'll see the C program using SIMD instructions, which you could do in rust, but it isn't stabilized yet.

What you won't find, is some intrinsic reason that the safety of rust is causing it to be slower than C. To just look at the benchmark totals and make that assumption would be wrong, and that's exactly what the author did.

<comment><USER10> Also, that screenshot is from a long, long time ago.

</comment></comment></comment><comment><USER11> It's hard to follow this author's arguments because so many of them are simply wrong and off base.

I've used Rust since 1.0 stable release, I have yet to write a piece of unsafe code. Almost all of my code has run at speeds similar to C/C++. If something in Rust is slow, then it is a bug. Of which the Rust contributors are very good at getting rid of. The new MIR stuff will change a lot.

This guy also makes many blunt assumptions on what other programmers will do. He says no sane programmer will write a webserver/service in Rust. Uhhh.. yes they will and do. When they need to benefits that the Rust lang comes with, they will/do already.

This guy clearly doesn't like Rust, which is fine. Most programmers have a language they really dislike that is popular. Nothing wrong with that.

As for "replacing" C/C++, no, in the near future it won't It may never. But the fact of the matter is old programmers will....grow older, retire and be gone. Young programmers just getting started in their career/education will look at the ecosystem of tools available to them and make their own choices on what to use. Which in turn has the potential to make C/C++ go the way of COBAL. Rust isn't the only language either. Many new languages will arise in the next few decades that will completely displace some of the most popular languages now. That's how it is. I frankly do no see C++ being used for new programs 20 years from now. Unless it is a new subset of C++ that does not resemble anything like C++ today...which for that matter...is a new language.

Sure, C/C++ programs will be around for at least a few decades. But will anyone new program in them? Highly doubtful. Rust is just one of the first displacing languages. And this is not a bad thing. We SHOULD rewrite many of the things that we heavily rely on. They have to evolve and not be tied down to something written decades past. System kernels will be re-written. Linux itself, eventually, will effectively be re-written. (Yes...it will take a while, may be something else, not called Linux...Redox perhaps?)

If it were up to this author, all language developers would only be working to make C++/C faster/safer.(The author calling C++ "safe" is laughable, he even counters his own argument elsewhere in the article about humans being the weak point. ) No. We have to reject that. Just as Henry Ford said, "If I asked people what they wanted, they would say 'faster horses'".

<comment><USER3> > I've used Rust since 1.0 stable release, I have yet to write a piece of > unsafe code

Yes, he conflates 'unsafe' with 'fast'. Speed doesn't necessarily require unsafety. Very occasionally it does, but Rusts approach to checking everything at compile means that mostly it doesn't.

</comment></comment><comment><USER12> I'm not upvoting this toward the front page because, although the writer makes some smart observations, the piece largely doesn't apply to Rust due to key misconception:

"You know, it's like the "Chicken or the Egg" dilemma. On very rare occasions, this problem does get resolved (relatively representative examples are Go and Scala) - mostly thanks to investments of time and money from some large company (Google, Typesafe) who for some reason finds it worthy to popularize a new language."

Which is exactly what happened with Rust. A large company put significant resources into language, compiler, libraries, and community. Already meant his write-up didn't apply to Rust if that was a precondition of its truth. It then of exploded in usage and available code. It was also deployed at Dropbox for mission-critical apps. So, many things he says it will need to prove something are already there. Amazing thing is the article from 2015 was disproven by Rust ecosystem by 2016.

<comment><USER13> Agreed.

I think the freetype alternative that made the front page of HN the other day puts the performance argument pretty well to bed. The rest seems to be things that the author doesn't agree with(exceptions) or "You're just not using it right"(to paraphrase the last bullet point at the end).

So far I've been using Rust in every side-project where I'd use C++ and you know what I don't miss? Crashes/stack corruptions/etc because of an off-by-one error. 90% of the C++ code you write is not the inner loop, that said if I want to use modern C++ stuff I'd still be hitting the heap for std::vector. Rust's iterators are an awesome way to keep everything stack based in a nice ergonomic way.

Most recently I wrote a packet library over an AX.25 radio link in Rust. With about 1:1 code:unit test radio most stuff _just worked_. I've almost never seen that in a production C++ library. C++ isn't going away but for me Rust is here to stay.

</comment></comment><comment><USER14> C and C++ will eventually die in the same way that COBOL has died. That is, they'll never go away, but there will be fewer and fewer people able and willing to use them.

<comment><USER15> I prefer data on evaluating a programming language's potential:

Search indeed.com for

C++ : 4287 jobs.

golang : 71 jobs

Java : 6817 jobs

Rust : 7 jobs

<comment><USER16> Trust me. You would _not_ enjoy roughly the 92% of Java jobs out of that number. My Java work was easily the most corporatish "enteprise" soul-sucking nightmare that I'm glad to be out of forever. I bet the majority of the Golang jobs are fun, in small teams though. I know which one I'd rather work on.

<comment><USER17> How much of that is Java's fault, though? Would those jobs be any less horrible if that software was written in COBOL or C++ plus CORBA? Probably not.

</comment></comment></comment></comment><comment><USER18> So Rust has started to receive criticism which means it's becoming popular. As the creator of c++ says:

        "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

<comment><USER19> How about "the ones that are evangelized to the point of annoying everyone else"?

<comment><USER17> They're in the second category - the ones nobody uses. Once people start using them, they'll move into the first category.

(Note well: This does not mean that no improvement is possible, or that all languages are equally bad. It merely means that the perfect language has never been written, and likely never will be. If people are using it, they will run into limitations, problems, and areas of frustration. Then - hello, human nature - they will complain.)

</comment></comment></comment><comment><USER20> I always chalked it up to the "I'm old" sentiment. There hasn't been a language that has actually caused us to think of writing a different kind of software. Sure we write nicer easier code but the software remains the same in the end, buggy, full of problems and not maintainable. These are the problems we should be solving.. the result of what WE code, not how pretty it looks in the ide.

</comment><comment><USER21> He considers Racer to be insignificant. And while It's true that it doesn't yet do everything an IDE usually does it's also true that Racer is exactly the path that Languages should be taking in the future. Locking all of that logic up in an IDE in ways that it can't be factored back out makes automated refactoring and analysis tools harder to build.

It locks people into editors they may prefer not to use and just generally splits your user base up in ways that are unnecessary.

Providing a build your own IDE api is a superior approach that more and more languages are moving over to.

<comment><USER5> Going forward there are indeed plans to continue to develop suitable interfaces for IDEs/tooling in the Rust compiler itself, to further facilitate easy integration (for example, the ability to typecheck incomplete fragments of code). Mozilla has a vested interest in making the programming experience as pleasant as possible, since it intends to have more and more employees using the language as time goes on. :)

</comment></comment><comment><USER22> > Wikipedia tells us that there were a lot of other attempts besides D to kill > C++ - for example Vala, Cyclone, Limbo, BitC.

Vala pretty much is a DSL for writing GTK+ programs. Cyclone is a safe dialect of C. Both don't really have anything to do with C++.

</comment><comment><USER23> > Note: Further in this text, I am presuming that Rust is a conscious attempt > to create a fast and safe language. After all, it was initially conceived by > the guys from Mozilla as a tool to develop a browser engine. But if it > proves to be yet another just safe language, then I just don't get the whole > thing. There is plenty of very different safe languages to choose from to > any taste, and if Rust is not meant to replace C++, then (1) why does it > need to include an unsafe subset?; and (2) why did the authors throw away > lightweight processes from Rust? They are convenient, after all, aren't > they? In other words, if I'm wrong in my assumption, then the whole affair > just doesn't seem to make any sense at all.

> I sincerely hope that programmers will find a way to speed it up in time, > but until then, it's going to be of hardly more interest than Scala or Go > from the viewpoint of the safety/speed compromise. The question is still > open if it is possible at all to make a language both fast and safe or if it > is automatically doomed to be twice slower than C/C++ because of the > constant checks for array overruns, safe wraps of bindings to C-libraries, > and other stuff like that.

If it ends up being a factor of 2 slower than C I really don't think that matters. The point isn't to be faster than Ada/Go/Scala/Java/Haskell/OCaml, it's to be as safe as those without GC - primarily for the sake of using it in a Javascript runtime and not having to run two GCs.

> Anyway, in any serious project, you use a continuous integration system and > run tons of tests when compiling builds. If you don't, then your troubles > are much worse than the language's lack of safety because static typing > doesn't guarantee correct execution logic!

Guarantees are absolutely possible. Most practical programs don't guarantee everything in the type system, but test suites don't guarantee everything either. For a practical program where you have a certain acceptable defect rate, it's not at all clear that a large test suite will be a cheaper way to achieve that than a type system, and my experience is in fact the opposite.

> Following its logic, we could rewrite 90% of WebKit or VirtualBox or GCC > into Java and get the same result. But it is obviously wrong.

Not at all obvious - I suspect not in fact wrong at all.

> Well, it depends on the project scale. For Google, even a few percent may > help save millions of dollars (see Section 5, "Utilization", in the paper). > Or imagine that with a next update, JVM will suddenly start requiring 10% > more resources!

So maybe C++ is worth using at Google. Most of us aren't Google.

> But if we want to follow it word for word, why not use bubble sort instead > of quicksort in all of the code?

Go ahead. See if I care. See if you care. 99% of the time, bubblesort really isn't a problem. (Not using library functions is a problem, so in practice this would never come up, but it really isn't a performance problem if you do end up using bubblesort)

> After all, who will dare to argue that finding a hot spot, rewriting the > code (perhaps tons of it) and proving it has become really faster is an > easier job than think about performance in advance?

What are you talking about? That is absolutely a lot easier. Needing to rewrite tons is extremely rare, at least in a well- or even moderately- structured program.

> So, to sum it up, personally I will be investing my time into studying C/C++ > rather than Rust in the next 5 or so years. C++ is an industrial standard. > Programmers have been using it to solve a huge variety of tasks for over 30 > years now. As for Rust and stuff like that - they are just odd toys with > vague future. People have been predicting C++'s soon death since the 2000-s, > but C/C++ hasn't become less used and demanded for since then. Quite on the > contrary, in fact. It is evolving (C ++11, C++14), new tools are released > (take CLion and Clang, for example), and the number of vacancies is just > huge.

If you believe the future looks like the past then sure. Personally I think the Internet will become both more vital and more hostile: the security requirements of a web browser are a canary for things that will become requirements for every program in 5 or 10 years' time. Mozilla started Rust because they couldn't write a safe enough browser in C++. That should be a warning to anyone who wants to continue using the language.

<comment><USER24> > it's to be as safe as those without GC - primarily for the sake of using it > in a Javascript runtime and not having to run two GCs

That's not actually the reason why Rust doesn't have a GC, nor it the reason why Servo doesn't have a GC. (It's worthwhile remembering that Rust predates Servo, and it has always been a goal to not require a GC.)

The reason why there's such a big desire to avoid GC is to have predictable memory layout and to avoid the overhead of the GC. In a browser, having predictable memory layout is important to be able to control memory usage, as well as for performance.

> Personally I think the Internet will become both more vital and more > hostile: the security requirements of a web browser are a canary for things > that will become requirements for every program in 5 or 10 years' time. > Mozilla started Rust because they couldn't write a safe enough browser in > C++. That should be a warning to anyone who wants to continue using the > language.

With the proviso that Rust predated Mozilla's involvement and any attempt to write a browser in it, I totally agree. The fact that no browser vendor has managed to write a secure piece of software is pretty damning—these aren't small applications written by small teams, these are big applications written by very well funded development organisations which absolutely have the budget to do plenty of work to ensure their products are secure.

</comment></comment><comment><USER25> What is dead may never die!

(sorry, couldn't help myself :P)

<comment><USER26> That is not dead which can eternal lie. And with strange aeons even death may die.

</comment></comment><comment><USER3> This title needs editing with a [2015] tag.

The original was written in April last year and some of the things it talks about are out of date.

<comment><USER27> Previous discussion: [https://news.ycombinator.com/item?id=9531822](https://news.ycombinator.com/item?id=9531822)

</comment></comment><comment><USER28> Rust isn't a proper systems language, it restricts how you can access the machine in the name is spurious "safety". A small number of people are making a lot of noise about it, but it's not going anywhere.

<comment><USER29> Maybe it doesn't line up with your definition of a systems language, whatever that is. But in practice it's works in places where you would otherwise need a systems language, like writing device drivers. Don't get too worked up over semantics.</comment></comment>


Stanford engineers build computer using carbon nanotube technology - <AUTHOR> http://phys.org/news/2013-09-stanford-carbon-nanotube-technology.html <comment><USER2> Each report has its own take on the topic - here are a few other HN submissions:

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

      First computer made of nanotubes unveiled
      (bbc.co.uk)

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

      Processor made from carbon nanotubes runs multitasking OS
      (arstechnica.com)

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

      First computer made from carbon nanotubes debuts
      (ieee.org)

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

      Researchers Build a Working Carbon Nanotube Computer
      (nytimes.com)

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

      World's first carbon nanochip computer, comparable to 4004
      (technologyreview.com)

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

      Breakthrough in Carbon Nantotube Computing Could 'Save' Moore's Law
      (pcmag.com)

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

      First Computer Made From Carbon Nanotubes Debuts
      (ieee.org)

A few currently have any comments, a few have an upvote or two.

<comment><USER3> Surely those (ieee.org) articles are dupes.

For once we have an announcement that isn't about some advance that might lead to something 5 years down the line. They built an actual computer. Wow.

</comment></comment><comment><USER4> The method for getting rid of the metal ones is stunningly simple. Presumably you could use the same trick to blow stuff like encryption keys or specific finite state machines into the actual chip.

</comment><comment><USER5> Hmm,

Over the last forty years, a Moore's Law of processor speed, transistors per chip, information storage and I assume other things has operated [1].

Moore's Law of processor speed has definitely broken down in the last ten years and I assume that this research is attempting to address this fundamental limitation. I believe Moore's Law of transistors per chip is still here but that without increasing speed, this tendency is nowhere as useful (we don't want a whole lot of slow cores, we _want_ a few fast cores).

Moore's Law of data storage is still here but it's also not as useful without a similar exponential increase in system data throughput [2].

[1] [http://en.wikipedia.org/wiki/Moore%27s_law](http://en.wikipedia.org/wiki/Moore%27s_law) [2] [http://en.wikipedia.org/wiki/Throughput](http://en.wikipedia.org/wiki/Throughput)

<comment><USER6> I have a prediction about where this will go:

First, things will continue about the way they are now: cores will stay at the same speed or get slower but there will be more of them.

The industry will stay this way for at least the next 5 to 10 years, and during that time we are going to get better and better figuring out how to take advantage of the increasing number of cores.

Finally, at some point in the future (I predict between 10 and 15 years), we are going to see an _explosion_ in materials science that allows us to suddenly jump from 3 - 5GHz / core to 400 GHz - 5 THz per core (with even more cores than we have now and dramatically lower power consumption).

At this point we will be nicely prepared to exploit _both_ the parallelism and the return of raw speed gains. We'll also see completely different architectures like Chuck Moore's greenArrays, quantum co-processors, "memory/compute fabrics" like memristor crossbar arrays, and further advancements in the GPU/APU area. These changes will continue to challenge our assumptions about what are the "proper" paradigms, languages, and architectures for computer programs.

We've made great progress already. I can think of myself as an example: in 2005 I, like most of the programmers here, read Herb Sutter's essay _The Free Lunch Is Over_ [1] and realized that he was correct: the era of easy speedups was giving way to the era of concurrency. And programmers were going to have to figure out how to take advantage of that concurrency or an app in 2013 was going to run at about the same speed as an app in 2005.

But I had _no idea_ how we were going to do that. I'd used threads and mutexes and locks in my professional work so I knew that correct concurrency was hard (and correctness almost never survived past a few rounds of maintenance). But I didn't have the first clue how we were going to get out of this mess without all becoming experts in Category Theory.

Fast forward to today and I find myself using things like "lambda expressions", "functional closures", "higher order functions", "map/reduce", "filters", and even "monads" and, you know what, they now seem as natural to me as the for-loop.

These days, I'm much more likely to write:

        stuff.select {|l| l > 23}.map(&:increment_magically).sum

than I am to write the equivalent imperative loop. I'm no genius, so I consider it remarkable that I've been able to digest these concepts as fast as I did.

And I am willing to bet that many other programmers here feel the same way. Not only that, but we are beginning to _really understand_ things like:

\- Identity vs value

\- The benefits and dangers of mutable state

\- Impure vs pure functions

\- Software Transactional Memory

\- MVCC / persistent data structures

\- Even Category Theory :)

None of this stuff was even remotely on my radar 8 years ago, and now it's part of our professional lives. We may not get to _use_ it all yet, but we can use more and more of it on every project.

And we are seeing the benefits.

Now fast forward to a time when we not only have hundreds or thousands of cores, but they suddenly jump up to 500 GHz. I guarantee you none of these skills will have been for nought.

[1] [http://www.gotw.ca/publications/concurrency- ddj.htm](http://www.gotw.ca/publications/concurrency-ddj.htm)

<comment><USER7> > _Finally, at some point in the future (I predict between 10 and 15 years), > we are going to see an explosion in materials science that allows us to > suddenly jump from 3 - 5GHz / core to 400 GHz - 5 THz per core (with even > more cores than we have now and dramatically lower power consumption)._

I don't see this happening. There are some physical limitations to getting to that.

</comment></comment></comment><comment><USER8> The just add certain amount of CNT transistors together. There is nothing worth for nature... I think a paper of Graphene transistors "computer" will publish on nature recently....

</comment><comment><USER9> "computer with 178 transistors". What is the minimum number of transistors to be called a computer ?</comment>


Show HN: Todo lists with time tracking - <AUTHOR> https://tokkapp.com <comment><AUTHOR> Hello everyone at HN,

We created this web app (mobile app in development) that combines todo lists functionality with time tracking.

Feedback or questions welcome!

</comment><comment><USER2> If you're going to use a manual time tracker, basing it around a TODO list makes sense. :)

</comment><comment><USER3> Mission for Mars for 48H is TOP</comment>


Michael Moritz: Silicon Valley Would Be Wise to Follow China's Lead - <AUTHOR> https://theoutline.com/post/2996/michael-moritz-china-essay-for-financial-times-is-real-garbage?zd=1 <comment><USER2> At some point though money ends up being a means to obtain a standard of living / a world worth living in. There is no point earning money if you never spend it to get something you want.

Money also takes precious time and opportunity to earn. Know what you want and aim for it asap. All the money in the world won't buy you fond memories of an adventurous youth if you spent all of your teens, 20s and 30s slaving away for currency that can be inflated to nothingness over time. All the money in the world won't save you if you end up accepting a totalitarian world where you or your loved ones can be cast away by armed police or where making one-too-many Taiwanese friends endangers your social standing.

</comment><comment><USER3> In Germany there is a push for 6-hour workdays, yet on the other side of the Atlantic the trends seem to be opposite. Hey human, the only reason for your existence is to work! Now stop thinking about it, work yourself to death, so that VCs can scrap more money off you. You know, that Lambo my daugther destroyed after 2 days costs something!

Seriously, you see workers dying at work in China weekly from exhaustion; due to their cultural and political repression they have to stick with it; now what does that say about people in the West calling for the same?

<comment><USER4> > workers dying at work in China weekly from exhaustion

I don't think they were better off before China turned to capitalism. Colonial Americans also pretty much worked themselves to death (according to archaeological evidence). Things got steadily better as the industrial revolution took hold.

</comment></comment><comment><USER5> You know, I feel like a huge part of this is just founder motivation. I don't agree with Mike's assertions. But I can understand reasons why an article like this might actually be productive, though it feels a little tone deaf.

I'm not sure if this thinkpiece is really meant for Silicon Valley employees. I think the goal (conscious or otherwise) is to inspire and align incoming or yet-to-prove-themselves Sequoia-backed founders. I expect the veteran Sequoia founders (some of them which treat their employees tremendously well and fairly) will take this advice a little more lightly: they understand how to motivate and get the most out their employees far better than Mike Moritz does and it's certainly not by saying, "work harder because of China and reasons also your happiness means nothing to us muahahah."

But the subtext here is: if you're a founder looking for an investment from Sequoia, China is in play in a big way, and you'd do well to follow their lead. Founders _intentionally_ burn the midnight oil and give up their lives to pursue a dream or vision, and willingly sacrifice a large chunk of their careers to generate returns for their investors with the understanding that _this is how you play in the big leagues_. The coach says "jump" and you ask "how high?"

There's a big kerfuffle raised, this article gets blasted around tech circles, every founder reads it, and the point gets made. The implication is that if you don't want to work harder than you've worked in your life, don't think about Sequoia money. Whether that's the reality of actually working with Sequoia or not is immaterial, there's a cult of personality and a commitment. Some part of me believes (maybe naively) that 10/10 times Mike Moritz would prefer the balanced, brilliant strategist and product founders who keep fit and still work a solid work-week to the narcissists willing to burn themselves out being easily manipulated by an article like this. My impression is that's all this is - a filter.

I could be wrong, but we don't need to manufacture outrage here. VC gonna VC. Maybe this is a tone deaf opinion piece, or maybe in the current bull market of (potentially irrational) exuberance, Mike feels the need to make this assertion to new and upcoming founders to keep them aligned, public image be damned. Employees say, "hogwash" but if a founder puts in even an extra 2%, that's going to be have multiplicative effects. The founders willing to burn their teams out will fail quickly and be selected against.

If you work for a Sequoia-backed company and this is concerning to you (or you feel like you're being burned out), ask your founder(s) their opinion and voice concerns. VCs don't make the decisions at the end of the day, the CEO does, and you likely joined your company for a reason and trust your CEO: they're human beings, they're responsible for your wellbeing, a good CEO will keep your best interests in mind as best they can.

(That said, maybe I'm reading too much into it and it's just a poorly timed opinion piece. Either way. Bring up concerns with your founders if you're worried. Not sure we need to run the outrage train on the age-old story of "VCs expect founders to work hard.")

</comment><comment><USER6> All: this sort of "We've interpreted what he's really saying" riler-upper is off topic for HN. Please don't post those here.

To see why, read [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html). The purpose of HN to gratify intellectual curiosity. I'm impressed that a number of users responded to this post in that spirit, but that's unusual. In general, internet rage is a self-licking ice cream cone, and [https://news.ycombinator.com/item?id=16194750](https://news.ycombinator.com/item?id=16194750) is far more typical.

<comment><USER5> Daniel, this is just my opinion, but I'm not sure if it was fair for you to take this down / flag it. I understand your concerns, but maybe give this one a pass?

This is obviously a controversial topic. You say you're impressed with how people have responded - why not let "the market" sort itself out? Mike is a very influential figure in SV, and it might be good for the community as a whole to air their grievances and try and work out how they themselves feel about the issue, and broader implications about the world of VC and how it interplays with companies, founders and employees. I worry that by moderating this HN is artificially contributing to the echo chamber here; flagging this post doesn't remove the Facebook posts and Tweets proclaiming the evils of VC without room for discussion.

<comment><USER6> People are welcome to discuss the Moritz piece if they think it's important, though even there I'm skeptical; the thread would likely just be the usual reiterations of the usual. But to post it through a rage filter like this is just off topic for HN, for two reasons: (1) starting off with indignation is statistically guaranteed to produce flamewars and other junk, and (2) this genre is a internet cliché. From long experience we know that if HN is to have a solid discussion on a divisive topic, the starting point can't be something as shallow as this. There's also the site guidelines, which ask: _Please submit the original source. If a post reports on something found on another site, submit the latter._

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER5> Thanks for the response. My concern is this; I've seen a few posts by friends, colleagues, etc. lambasting Mike's piece. My co-founder and employees read it and we had an earnest discussion about it. _We_ all burn the midnight oil in pursuit of our vision, but it opened up important distinctions between risk- adjusted compensation and expectations now vs. as the company matures, as well as how we manage customer, VC and employee expectations and keep each other healthy and happy.

Given the right framing, I think it's possible to turn "outrage" pieces into thoughtful discussion pieces and examine the intricacies of why individuals may have certain opinions or behave certain ways. Facebook and Twitter aren't great mediums; Twitter is practically an outrage-manufacturing hot-take machine and Facebook is restrictive in content distribution. I guess part of me just wonders if by silencing outrage we're actually helping it proliferate in other mediums - that emotional energy has to dissipate somewhere.

Edit: Saw your edit with link to guidelines afterwards. I understand completely. Given this is a hot-button topic I guess I was supposing this might be a good opportunity to let people air out concerns, but I also understand the need to be consistent in enforcement. Cheers!

<comment><USER6> I have no quarrel with what you're saying. Why don't you submit the original article and then post a version of your comments in this thread as a first comment to that one? This may help to seed good discussion. If it turns into a flamewar we can always deal with that later.

<comment><USER5> Thank you for the offer! We're in the midst of helping students during a 36 hour Hackathon. This was a nice distraction, I thought it might be productive to discuss here but don't know if I want to deal with the ownership of an entire thread right now. :)

</comment></comment></comment></comment></comment></comment><comment><USER7> There is always a backlash.

Those kids growing up with absent parents are going to have some psychological problems and some desires in common. The US had its "greatest generation", followed by their children, the boomers; China will not escape that cycle. Despite their cultural isolation and the Great Firewall, they will have a generation that will want to live very differently from their parents.

There's no denying China's incredible growth over the last couple of decades, but there's an excellent debate to be had about the long-term effects of that growth.

Of course, VC's aren't known for their long-term thinking.

</comment><comment><USER8> Yes, so that they can accumulate wealth, so that they can build a safety net, welfare, better education, freedom of speech, so that they finally can start working less in maybe 10 years.

Working so much loses its importance once your country already has those things, because it burns an entire generation, where people aren't humans, but just working machines.

Another really short sighted article by a very very smart VC.

</comment><comment><USER9> > Beyond the week-long breaks for Chinese new year and the October national > holiday, most will just steal an additional handful of vacation days.

Wow.

</comment><comment><USER10> As always there is some truth from his piece. What would SV do, when their competing edge is waning? How do SV keep its perks when employers discover they can do the same thing elsewhere with less money? The realization should be, software is not a novel technique it uses to be, more people and more countries can do it now possibly cheaper. To justify the money, SV needs to do better. Whether it is to take the perks away and work longer, or find a new competing edge, only time would tell.

</comment><comment><USER11> Elon's take: [https://youtu.be/GtaxU6DZvLs?t=1m36s](https://youtu.be/GtaxU6DZvLs?t=1m36s)

</comment><comment><USER12> This guy has never created anything.

</comment><comment><USER13> Tweetstorm by David Heinemeier Hansson: [https://twitter.com/dhh/status/954319522151976960](https://twitter.com/dhh/status/954319522151976960)

<comment><USER14> No need to read it - you know what it says

</comment></comment><comment><USER15> Michael Moritz would be wise to stay in China since it's so damned awesome.

<comment><USER16> Is it satire?

<comment><USER17> The piece linked to here is my annotation on a very real post by Michael Moritz. Yes, my take is... a form of satire.

</comment></comment></comment><comment><USER12> Money is power for stupid people.

<comment><USER18> It's also a power multiplier for intelligent people.

<comment><USER12> Multiplying by 0 is still 0.

</comment></comment></comment><comment><USER11> I can see why people hate on this POV, but one thing is very reasonable:

Imagine company A and company B are equal in all ways, except company B's workers work twice as much. If they come into competition, company A will be crushed.

All the SF tech companies will come into competition with Chinese companies in the next 20 years. And there's a chance they just get outworked.

<comment><USER19> This was the line in the 80s about japan. Didn't actually work out like that. Edit: typo

<comment><USER11> True. Because everything else wasn't equal. And it won't be here. But if it gets close to equal ...

I imagine Chinese work ethic had something to do with the destruction of the Rust Belt, no?

<comment><USER20> Work ethic doesn't matter much if one workforce works for a tenth of the wages of the other.

<comment><USER11> And this explains Africa's dominance of the world economy?</comment></comment></comment></comment></comment>


High Burn Rates Result in Short Startup Runways - <AUTHOR> http://www.caycon.com/blog/2011/03/high-burn-rates-result-in-short-startup-runways/ <comment><USER2> Isn't this obvious?</comment>


Atom: Scalable Anonymity Resistant to Traffic Analysis - <AUTHOR> https://arxiv.org/abs/1612.07841 <comment><AUTHOR> As stated in the paper, "The source code will be made available at github.com/kwonalbert/atom". Usually the most difficult or challenging part is the deployment of the infrastructure and the security of the implementation(s).</comment>


Hacker News for [domain] - <AUTHOR> https://hn.algolia.com/?q=%22hacker+news+for%22#!/story/forever/0/%22hacker%20news%20for%22

<comment><USER2> thumbs up to these guys. i just clicked on the link to their site and had a chat w/ one of their reps. very helpful. very accommodating to ad hoc requests. answered all of my questions in less than 5 min.

it's refreshing to find alternatives to the stacks that actually work for the benefit of small businesses and startups.</comment>


So Many Publishing Platforms, So Little Time - <AUTHOR> http://nocategories.net/ephemera/publishing-platforms/

<comment><AUTHOR> I posted a run-down of just a few of the publishing platforms I've heard of recently. I haven't had time to try very many of them, so I'm curious what anybody else might think of them before I jump into using one(s). Are there others like these? What are the differences among them?</comment>


A Case for Universal and Simplified Journal Systems - <AUTHOR> https://scholarlykitchen.sspnet.org/2019/08/20/guest-post-a-case-for-universal-and-simplified-journal-systems/ <comment><USER2> For me, if a journal/conférence has a weird format but gives a functional latex template with a bibliography style that matches their needs I'm fine with it. Although I do wish that it was more standardized. In my experience a lot of the time wasted for submission is filling forms which contains the same information already in the paper: abstract, authors, affiliation, funding and etc... I wish this was adressed somehow.</comment>


Slack is now forcing users into arbitration - <AUTHOR> https://konklone.com/post/slack-is-now-forcing-users-into-arbitration-and-that-is-terrible <comment><USER2> >I won't be deactivating my account over this

Personally, I consider that quote and post contents in general harmful to a stated cause of a post. At the time of writing, this is a top HN story and what message does it convey to other HN users?

Praising Slack on "being humane", stating that Slack "exudes the feeling of a playground built by kids that know all the cool things" and "feels like the best of the Internet" while mildly disagreeing with TOS policy?

Competitors applying pressure over very low probability event that most users won't even know about? Yeah, that's a competitive advantage Hipchat was dreaming about./s

OP could write a raving Slack review with the same effect. "There is no such thing as bad publicity" is certainly wrong as a general rule, but in this case it fits perfectly.

Btw, Watsi,not Slack, feels like the very best of the Internet but your mileage may certainly vary.

</comment><comment><USER3> Comments moved to [https://news.ycombinator.com/item?id=8653838](https://news.ycombinator.com/item?id=8653838).</comment>


Sandsifter: x86 processor fuzzer - <AUTHOR> https://github.com/xoreaxeaxeax/sandsifter <comment><USER2> Reveal talk at Blackhat showing this off: [https://www.youtube.com/watch?v=KrksBdWcZgQ](https://www.youtube.com/watch?v=KrksBdWcZgQ)

<comment><USER3> Fascinating! Plus a very easy to follow presentation. Thanks for the link.

</comment></comment><comment><USER4> Same guy who did the [https://github.com/Battelle/movfuscator](https://github.com/Battelle/movfuscator) which compiles programs into code with only the x86 MOV instruction.

</comment><comment><USER5> It seems this is the preferred URL: [https://github.com/xoreaxeaxeax/sandsifter](https://github.com/xoreaxeaxeax/sandsifter) \- for example the issue tracker is enabled, and has 45 issues, whereas the other URL has the issue tracker disabled.

Can one of the admins fix?

<comment><USER6> Ok, changed from [https://github.com/Battelle/sandsifter](https://github.com/Battelle/sandsifter).

</comment></comment><comment><USER5> Can anyone actually get this to compile? I failed last year, and it's still failing:

        $ CFLAGS=-fPIC make clean all
        rm -f *.o injector
        cc -fPIC -c injector.c -o injector.o -Wall
        injector.c:321:93: warning: excess elements in array initializer
          .start={.bytes={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, .len=0},
                                                                                ^<comment>
        injector.c:321:93: note: (near initialization for 'total_range.start.bytes')
        injector.c:322:91: warning: excess elements in array initializer
          .end={.bytes={0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}, .len=0},
                                                                                ^<comment>
        injector.c:322:91: note: (near initialization for 'total_range.end.bytes')
        injector.c: In function 'inject':
        injector.c:778:2: warning: asm operand 15 probably doesn't match constraints
          __asm__ __volatile__ ("\
          ^<comment><comment>
        injector.c:778:2: error: impossible constraint in 'asm'
        make: *** [Makefile:38: injector.o] Error 1
        2

<comment><USER7> Seems like using immediate values in inline assembly operands can be fragile depending on what optimizations the compiler decides to apply. Try building with -ftree-ter in your CFLAGS, as suggested by [https://stackoverflow.com/a/11518308](https://stackoverflow.com/a/11518308)

<comment><USER5> I figured it out, it's because Debian enables PIE and that somehow causes GCC not to be able to satisfy its own rules for allowing inline-assembly to modify %rsp to the value required by this program.

<comment><USER7> You ought to update your pull request, then! I'm not sure why they don't accept regular issues.

<comment><USER8> Because this github release was only for talk and he has since moved on (albeit is still using it for other projects)

The sifter isn't terrible intresting it self but could use a lot of chances. Like the ability to use multiple disassemblers. God that was such a pain to hack that one together.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The demonstration in Figure 7 of a program that executes a benign codepath on QEMU but malicious on baremetal - and the benign codepath is what shows up in the disassemblers they tested - is very neat.

<comment><USER10> Note that "provide an emulation of an x86 CPU that is sufficiently true to the hardware that it is impossible for a guest program to distinguish it" is not a goal of upstream QEMU -- in part because we don't think it's actually possible. Don't trust TCG (pure-emulation) QEMU to contain a potentially- malicious piece of code, either...

</comment></comment><comment><USER11> I love the visual design of the UI. It looks like something out of a hacker movie.

</comment><comment><USER12> this page fault trick to check insn len is awsome, this is such a good technique!</comment>


Whitespace delimited Scala - <AUTHOR> https://github.com/lihaoyi/Scalite

<comment><USER2> Good job, I like it. I think it would be good though to still optionally allow braces as a way of scoping.</comment>


Particletree: Rediscovering the Button Element - <AUTHOR> http://particletree.com/features/rediscovering-the-button-element/ <comment><USER2> Beautifully written. Not just a nice article, but I'm going to look more into using the button element now.</comment>


Ask HN: Web Should Stay as Centralized? - <AUTHOR> Current web, is not decentralized. Information are not permament even not near-permanent, and that describes us, people doesn't really want to decentralize web, so why web should stay as centralized? <comment><USER2> Is there a standard for decentralized web?</comment>


Uber + Boatbound are teaming up for an on-demand commute by boat Monday Aug 5th - <AUTHOR> http://boatbound.co/uber

<comment><USER2> I salute companies which are quick to turn a negative, random event into positive publicity / users. We should all be on the lookout for ways to do this in our own businesses.

</comment><comment><USER3> However, Monday Aug 5th is 3 days away and they still have zero details on how to use their service. Doesn't seem like the best business plan to me...

<comment><AUTHOR> we'll be announcing details tomorrow via FB and Twitter...

<comment><USER3> Will you release them via this website also?

<comment><USER4> More details have just been released on Uber's blog - [http://blog.uber.com/2013/08/02/uber-boatbound-sail-to- work/](http://blog.uber.com/2013/08/02/uber-boatbound-sail-to-work/)

<comment><USER3> But it isn't on the announcement site. What is the point of having a site announcing your new idea if you post all of the details elsewhere?</comment></comment></comment></comment></comment>


Why we all should be following high frequency trading  - <AUTHOR> http://zocontrary.com/2014/02/26/why-we-all-should-be-following-high-frequency-trading/

<comment><USER2> Because it never hz.</comment>


It's 2016 already, how are websites still screwing up these user experiences? - <AUTHOR> http://www.troyhunt.com/2016/01/its-2016-already-how-are-websites-still.html <comment><USER2> > When you block a character, I'm going to assume one thing: your input > sanitisation and your query parameterisation sucks.

Not really. This is to reduce issues with users unable to login because...

1) they might have used symbols like [, { or similar while registering on a Windows machine - and they cannot find these symbols written on a Mac keyboard

2) Umlauts - these are not available in foreign countries and no one knows the escape sequences out of memory

3) They're on the phone and cannot see the password in cleartext (and thus cannot spot input errors). Seriously, I accept that asterisk stuff on PCs where you might be connected to a projector or someone glances over your screen. But on a phone? Anyone looking over your shoulder can already see what you typed!

> Delayed pop-over ads – evil personified

I might accept these when I can close them with Esc like any other modal window in my OS. Kill that behaviour and you deserve to rot in hell.

> EU cookie warnings – this is just plain stupid

Thank the EU for this bullshit, they mandated it.

<comment><AUTHOR> The password field should allow anything because it all gets hashed to the same size string with safe characters in the end.

If users choose something funky that's their problem but if they're typing like that then they'll probably do so on all of their devices. It also discourages the use of randomly generated strong passwords with password managers by having these weird rules.

<comment><USER2> It 'd be great if the password field could encode the required rules so that a password manager could automatically generate the strongest password.</comment></comment></comment>