Sean Parker's Email to Daniek Ek of Spotify - <AUTHOR> http://www.scribd.com/doc/67465758/Sean-Parker-s-Email-to-Spotify-s-Daniel-Ek# <comment><USER2> "Until now, no digital musicservice has met, let alone exceeded the bar set by Napster."

Did he ever _use_ Napster? It was slow, search was terrible, most files were bad copies, there were viruses everywhere...

Napster was great because it was the first widespread way to get digital music. It was _terrible_ as a platform, and quickly surpassed by its successors in every meaningful way.

Parker's got his reality distortion field going full blast if he thinks napster was a better music delivery system than Kazaa/Limewire/etc, or torrents. With Grooveshark and the like out there, saying Napster has yet to be surpassed is like saying a PII is superior in every way to an i7.

<comment><USER3> He came off as insecure in that email, to me. Constantly dropping how "great" Napster was and how _nothing_ but Spotify could match its brilliance.

<comment><USER4> Again with this. Every time someone from the Silicon Valley pantheon does something interesting and it reaches HN, people feel the need to voice if they 'like' it or resist 'liking' it.

I think it's immensely interesting Parker and Zuck think in terms of experiences, not just UX, but the experiential realities of using a piece of technology. Every tech visionary I've met looks at products and services this way. This is an inside look into the way Parker thinks about technology, and the comments are just a bunch of people mashing the mythical 'dislike' button.

Emotions change thinking, I get it. Optimism and Pessimism are the two emotional reactions to an opportunity. Optimists imagine a positive reason for the event happening- superstition- (I need a hacker to help me with my startup, he's perfect), pessimists focus on the risks- paranoia- (I don't want to give equity to this guy). Understand how emotion directs thought and then see things as they are.

That being said, I think it's weird that the actions of successful people provoke emotional responses on this forum.

<comment><USER2> My response wasn't emotional, it was incredulous. Parker's a smart guy; I was surprised he made such a statement.

It would be as if Henry Ford, at 100 and whatever, claimed that no car had ever matched the Model T until the 2012 Lamborghini Aventador. It's just a clearly false statement, and something that inspires incredulity on the part of those hearing it, especially from a guy like Ford/Parker.

</comment></comment></comment></comment><comment><USER5> I was disappointed by the lack of an "a million dollars isn't cool..." pitch.

That being said, I think he did a fine job of endearing himself to the Spotify team by stroking their egos a bit and demonstrating that he's like minded. All you founders here on HN looking for co-founders or partnerships should take note.

</comment><comment><USER6> I particularly agree with all of his reasons for a desktop client instead of web interface. It's just a better experience for music. And there's an edge use case I hope Spotify will support at some point:

I find a cool remix on Youtube, but it doesn't exist anywhere else. I use a flash downloader to get it, then another program to strip the audio out of it. Now I want to load it into Spotify (Ok so far) and add it to a playlist to share with my friends. So far it seems that sharing music like this (or say that I downloaded from Newgrounds.com) that's not in Spotify's catalog is not enabled. Hope it will be someday.

 _"Final thought: I'm glad that you guys resisted the temptation to build a web basedapp. I remain a strong believer in the desktop client approach in music for a numberof reasons.

1\. Speed/responsiveness of interface, and optimized downloading and streaming

2\. Bandwidth savings of P2P architecture

3\. Easy integration with hardware devices such as the iPod (ultimately you want tocontrol the interface to the portable devices where you can monetize moreeffectively by charging for download…)

4\. There are vast repositories of "grey" content on people's computers across theworld. This content is often forgotten by the labels and publishers. The fact that youhave a client and P2P capability will allow you to someday unlock all of thiscontent…this goes way beyond the master music catalog that is licensed to you bythe labels. A big part of Napster was the joy of discovering various remixes, liverecordings and other obscurities that copyright owners have literally lost track of.

5\. While you could have built a "thin" client that runs in the background and powersweb based streaming, why go to all the trouble of building and distributing clientsoftware when you could build the real experience? There is tremendous value incontrolling the client software real estate and it allows for a much snappierexperience."_

<comment><USER7> I'm glad I'm not the only one that uses youtube for music.

I often wonder how much google would save on bandwidth if they let me stream _audio only_ versions of things. The vast majority of the time, I'm not even looking at the visual component of the "video", just listening to the song.

I suppose that this would add computational complexity, as well as additional storage, though. I'm not terribly familiar with the way that youtube stores video.

Can anyone chime in on this? "Extracting" audio from the video containers that youtube uses; how hard is this to do on the server side?

<comment><USER8> It wouldn't add computational complexity, or use extra storage. Surely the audio is already stored as an mp3 or some similar format, after all wasn't mp3 invented to be the audio part of video (mpeg) files.

From wiki: "Audio in Flash Video files is usually encoded as MP3." On this page:<http://en.wikipedia.org/wiki/Flv>

<comment><USER7> My question comes down to how they're stored. [Obviously] I'm not an expert on video encoding or containers.

FLV is a container, yes? Usually, I'm guessing, MP3 and H.264. H.264 works out well for youtube because they can then also use this on their HTML5 video players.

So are the H.264 blobs and the mp3 blobs stored as discrete files, then packaged when a video is loaded and sent down the tubes? If so, then yeah, obviously, it would be really easy or youtube to serve "audio only"; probably "a few lines of code".

But if the MP3 and H.264 (again h.264 is an assumption) are stored as one [flv] package, they would have to be unpacked before being able to be sent down as their individual components.

Again, this is a shortcoming in my understanding of video containers, so maybe I'm missing the point on this completely. (As in: maybe "unpacking" an FLV is trivial)

</comment></comment></comment></comment><comment><USER9> Pretty much sums up why I ended up ditching my subscription to Spotify after a year. Spotify is a really great service -- it's just that I truly hate Facebook and all it stands for.

<comment><USER10> Do you hate the concept of facebook or the realization?

<comment><USER11> Is there a difference? ;)

</comment></comment></comment><comment><USER12> I use Rdio all day, 50/50 web and desktop (and desktop is just an Air wrapper around web), and I like it better than iTunes (which I like a lot). It's very responsive. The browser actually contributes the experience (history, back button). What am I missing here? I'm not convinced that the web isn't already the best place to build a music streaming application.

<comment><USER13> Minor nitpick: the Air app has been deprecated, the desktop app is a native app wrapped around the web site. It also allows downloading purchases and matching your iTunes collection.

<comment><USER14> Matching iTunes collection only matches songs which are also available in Rdio's catalog. Everything else you'll still have to open up iTunes to play, and you can't even mix and match.

<comment><USER12> You sound surprised. How could that feature work otherwise?

<comment><USER14> Well in spotify your itunes music is imported into the spotify player.

</comment></comment></comment></comment></comment><comment><USER15> I paid $10 to spotify, and I still wasn't as happy as I am with what grooveshark gives me for free.

I have no idea if what grooveshark is doing is sustainable, but I've talked to others, and they concur.

<comment><USER16> I have found that Grooveshark actually has much better content selection, as well. Most of my listening is through Pandora One, but when I want a specific song I have never failed to find it on Grooveshark, but frequently cannot find it on Spotify.

<comment><USER17> Because many of those songs have not been licensed to Spotify or Grooveshark. But Grooveshark is much like Honey Badger.

</comment></comment></comment><comment><USER18> All I saw was,

"Blah blah CONGRATS!!! blah blah blah Facebook. Blah blah Zuck. Blah blah blah napster, blah blah blah napster, blah blah blah CONGRATS! Blah blah blah napster."

<comment><USER19> I really wonder if he speaks like this IRL too. I had a pretty high impression of Parker till now, but if he can't say a good thing about Spotify without talking about how he did or thought about doing everything in Napster first ..

<comment><USER20> No, he is not anything like this letter in real life. He is happy to have wide ranging conversations without reference to his own history or accomplishments. I suppose that in the letter he was trying to establish credibility and rapport with the Spotify guys. It certainly worked out well for both of them in the end.

</comment></comment></comment><comment><USER21> I think the real take away from this is not Desktop vs. Web Based its how Sean Parker conducts himself. This guy knows how to work the room, he's a great networker. I know very few that would have put the time and energy into writing a letter like that. It really shows what it takes to be a top notch entrepreneur. Fascinating stuff.

</comment><comment><USER22> Napster - 12 occurrences, Facebook - 10 occurrences, Spotify - 7 occurrences

<comment><USER23> You - 48 occurrences

</comment></comment><comment><USER24> TL;DR: Sean Parker brags a lot about Napster.

<comment><USER25> That was more like TL;DR_I_DIDN'T_EITHER_BUT_I'LL_TELL_YOU_ANYWAYS.

IMHO it was a class on "How to get somebody interested on you to partner with them".

</comment></comment><comment><USER26> Anyone else perfectly content using Youtube as their primary music player and discovery service?

Where else can I instantly switch between the rarest Medieval Madrigals and the latest Reni Lane dubmixes as the mood suits?

<comment><USER6> Youtube is awesome for discovery, but meh as a music player imho.

Youtube is like MTV for the web - your music gets served with a video of some sort, whether you want it or not. Most people seem fine with that, but I just want the music.

</comment></comment><comment><USER27> I don't understand why he talks about web vs. desktop as it it's an either/or argument.

I agree with all the points he makes about a desktop client, but I still prefer Rdio- I can use the desktop client when I'm at my normal PC, but if I'm ever anywhere else, I can just fire up the web client. What possible argument is there _against_ flexibility like that?

<comment><USER14> I believe their desktop app is just their web app wrapped in a container.

<comment><USER27> It isn't- I'm looking at it now. I have premium accounts with both Spotify and Rdio (so I can try them out and make a choice) and while the Rdio client might possibly be more HTML-oriented, it doesn't show.

</comment></comment></comment><comment><USER28> Unfortunately, having seen "The Social Network", I can't help but read a lot between the lines here. And it's mainly in a voice that's both Machiavellian and threatening...

Maybe the level of enthusiasm is all positive and innocent: But reading the recent news, it seems that Spotify has tied itself closely to Facebook, but the monogamy only goes one way.

<comment><USER29> I picked up on that too. Just read the first line of every paragraph... "Your design is clean, elegant, tight, and fast... Ever since Napster I've dreamt of building a product similar to Spotify.... You know what's cool, a billion dollars is cool..."

<comment><USER30> Yeah, between the tone and the length, it doesn't seem like Parker has pure motives for Spotify.

</comment></comment></comment><comment><USER31> Justin Timberlake just read a letter in my head.

<comment><USER32> Yep, and yech.

</comment></comment><comment><USER33> The responsiveness of their desktop client is why I ditched rdio for spotify

</comment><comment><USER34> I'm surprised at how helpful Sean Parker was trying to be in the email, and the open offer to help.

</comment><comment><USER6> Serious question for everyone who prefers web-based players:

The main reason that doens't work for me is b/c I'm a browser tab-a-holic. Anytime I open Chrome, Chromium, or Firefox, it's usually two windows with 5 to 10 tabs each. Stuff I'm working on or reading during breaks or whatever.

But sometimes I don't want the browser open, when I'm working on something that doesn't immediately require it, but I do want my music. Eg, I want my music decoupled from the browser. Hence I prefer a native app for music players.

Is that just an edge case, or anyone else have same or similar issues with browser-based players?

<comment><USER35> You could use a second browser strictly for music playback.

<comment><USER6> Yeah, unfortunately my tab problem applies to all my browsers - chrome, chromium, firefox, opera. Yes I'm starting therapy.

</comment></comment></comment><comment><USER36> Already covered here: <http://news.ycombinator.com/item?id=3077312>

</comment><comment><USER37> Having the option to listen to my music without having to install an app is the main reason why I choose Rdio over Spotify. Rdio's desktop app could be a lot better but I do appreciate the choice on how I get to listen.

Also there are a large amount of people that can't install anything on their work computers but can access a music website.

</comment><comment><USER38> More interesting to me than the content of the email itself is the length. Jesus, that's a three-page email.

I have no idea how a long-winded email like this can be convincing. Effective communication is about quickly and concisely providing a message of substance, not writing 3 pages of fluff that could have by written in a paragraph:

 _Hey,

I love what you guys have been doing with Spotify. As you know, I had a very similar vision when I built Napster. I would love to extend my help in any of my area of expertise, whether it be the music business, the social space or potential investment.

Let's grab coffee and talk a little more!

Cheers, -Sean_

<comment><USER39> Well, that clears up the 'Sean-athon.'

</comment></comment><comment><USER40> Spotify has blown me away in all the good ways. They have definitely significantly reduced the time I spend on YouTube and made iTunes obsolete for me.

Unfortunately, I've experienced one too many subscription stream service(Yahoo Music anyone?) only to see them go down under after a few years. Anyone know Spotify's future prospects in this regard?

Yes, they are superb right now. But what are the chances they'll increase their price from 10 bucks to 30 bucks or something even more ridiculous once they have peaked growth.

</comment><comment><USER41> Grooveshark is the best, and it's completely free, plus no forceful sign-ins into Facebook.

</comment><comment><USER42> The key word in that email is "sequencing". Which features to build and in which order.

</comment><comment><USER43> Lessons learned: 1\. Build MVP 2\. Get in front of a bunch of users & iterate (build whatever else supporting features) 3\. :)

</comment><comment><USER44> I was waiting for something at the end like, "And one more thing. Drop the -ify. Just Spot. Cleaner."</comment>


A centerfold does not belong in the classroom - <AUTHOR> http://www.washingtonpost.com/opinions/a-playboy-centerfold-does-not-belong-in-tj-classrooms/2015/04/24/76e87fa4-e47a-11e4-81ea-0649268f729e_story.html

<comment><USER2> why?

<comment><USER3> Do you think there's really an answer to your question that would make you reflect on the issue?

If so, what might the answer look like?

If not, why did you ask the question?

<comment><USER2> Do you think you could be a little bit more condescendingly passive aggressive? If not, I'd appreciate it if you'd turn it up a notch. In for a penny, in for a pound.</comment></comment></comment>


Google Ordered to Pay for News in French Antitrust Crackdown - <AUTHOR> https://www.bloomberg.com/news/articles/2020-04-09/google-told-to-pay-up-in-french-crackdown-on-news-free-for-all <comment><USER2> Ah, another attempt to attack the law of unintended consequences, I recall how this was tried in some countries and google stopped linking and desperate beggars hammered at Google's doors when their web traffic headed towards zero... Take care of what you wish for - you may get it...</comment>


Uber for Software Engineers - <AUTHOR> Hello everyone, I built something! :)
A common scenario is the following: team leader requests feature A, but feature A requires expertise in X, and no one on the team has expertise in X. Vertlas steps in to provide the X. You can find Vertlas here: https://vertlas.com
Please let me know what you think. Thanks very much! <comment><USER2> Here's my feedback after checking out this site for a few minutes:

It seems a bit strange to post credit card details at the same time that you ask a question, especially without needing any sort of an account.

The items on the Pricing page raise up when I hover over them, as if I can click them to get some more information. But they can't be clicked. I would expect to see something like an example question and response to know what I'm really getting, plus hopefully a link to find out even more details since these are some rather pricey questions. Given the shortness of the responses, couldn't I just ask the same questions on Stack Overflow or Quora for free and potentially get even more responses?

Another thing: when posting credit card details, if the card fails, then there is no response on the page. I tried this with a Visa test card and the loader just kept loading as if the request was being processed. Meanwhile, my Developer Tools showed that the request was rejected by the Stripe API.

Finally, I get a ton of CORS errors from Mixpanel when I visit any page.

Given all of this, and despite the assurance on the site that my card would not be charged, I would feel apprehensive about using this service.</comment>


Don't Get Grinfucked By Your Users - <AUTHOR> http://fullcontact.com/2012/02/04/dont-get-grinfucked-by-your-users/

<comment><USER2> Grinfucked is an unnecessary and combative neologism. Users are not trying to deceive anyone except to avoid looking stupid when navigating the latest UI tricks that often only make sense to tech insiders. Also, this has been happening for decades.

<comment><USER3> I agree, the original article seemed more aimed at people who would deliberately pretend they were on your side and then turn around and do the opposite. Applying this combative term to include people who are trying to be nice or succeed at using your app may lead to bad outcomes. I don't disagree with others who have suggested that it may be "more efficient" to get the most honest feedback possible, but all parties have to understand that going into it.

All of this reminds me a little of Crocker's Rules on SL4, where participants would explicitly invoke a special conversational mode to request brutal honesty. That's an important distinction: It's okay to ask for brutal honesty, but if you dish it out to someone without having been asked to, they may react more to the brutality than the honesty, which will probably make the rest of the exchange markedly _less_ efficient.

</comment></comment><comment><USER4> Is it common in the US to be dishonestly nice to other people? Eg being positive and friendly toward them while waiting to stab them in the back.

This theme is something I've picked up on earlier. Another example: some Americans mentioned the lack of smiles from waiters in Europe as problematic, thinking it was rude.

Personally, I prefer living in a culture where people are honest assholes and only smile at you if they actually like you.

<comment><USER5> Yes, absolutely.

I just moved to Sweden and immediately noticed the lack of "dishonestly niceness" that I took for granted in the US. It's quite refreshing actually and communication is more efficient.

Edit: In a US workplace you can't tell someone directly "that's wrong" or "I don't like that". You have to politely get to the point in an indirect fashion so as not to offend. It's an especially acute problem when giving that kind of feedback to superiors or other people in power.

<comment><USER6> Honest question: how does this difference in behavior impact dating in Sweden vs. the US?

<comment><USER5> I'm married, so unfortunately I don't know.

</comment></comment></comment></comment><comment><USER7> random idea: tell the testers that they are testing a _competitors_ product, so they don't have the feeling that their criticism is insulting to you

<comment><USER8> What I've found to be helpful is to set them up to be critical: "Yeah, so, this is an interface that my (cousin/roommate/________) designed, but I just don't think it's quite ... there. I haven't been able to articulate _just_ what isn't right about it. I'd love to know your thoughts on it."

Set it up that way and they're primed to give critical feedback. If they can help you articulate what's problematic about the interface, they end up being the hero. You both win.

</comment></comment><comment><USER9> Hacker News comment threads are notorious for this. A number of times I have been the brutally honest one when I shouldn't have to be. People are very unwilling to criticize the development efforts of others. That's OK to an extent, but it's frustratingly unhelpful when you are trying to solicit genuine feedback on something you plan to devote your life (or part of your life) to.

Sometimes the worst people to get feedback from on an app is other developers. They focus on the wrong things and overlook important stuff. They provide a type of useful feedback, but their suggestions and your instinct can easily run contrary to what a user expects and needs.

<comment><USER10> That's a good point and I agree.

That was my experience as well at first, but then I realized that there is a certain pattern to the way americans communicate, and it goes something like this:

\- First state the positive aspects that you like, or show appreciation for the effort - even though those things have already been said by other people in the thread. \- Then count what you find negative but don't use words such as "sucks" and "not good" etc.. but use words such as "could be better" and "can be iterated on" or "needs improvement". \- Then end the post by encouragement.

This technique has also helped me IRL as I started working with other americans in a startup in the bay area.

It takes some practice, imo, but it makes for some better communication with americans.

Good luck! ;)

</comment></comment><comment><USER11> He could have learned this years ago if he'd looked at existing knowledge arond user testing. Who knew, users tend not to give direct negative feedback?

<comment><USER12> I personally learned some of this in my UX course, but nothing substitutes for experience. As is, the article is seems to be extolling the virtues of keeping good feedback practices in mind (as well as highlighting a rather amusing term, "grinfucked").

It's good though that you can leave negative feedback on a rather open article. Keep up the Ivory Tower routine.

<comment><USER11> If nothing substitutes for experience, why is it any use to write or share this article?

</comment></comment></comment><comment><USER13> When a user needs to pay or is paying for your product, in general, there is no grinfucking.

<comment><USER14> Yeah, and if it's a free product, you can usually tell who is your target user by the feedback he/she is giving. The hardcore users who would love to use it will be writing an essay filled with recommendations on how to improve it, while the people who won't use it as much will just tell you it looks great.

</comment></comment><comment><USER15> I've found that many people that tell you what you want to hear change their tune once their own money/work/happiness is involved.

Make compensation dependent on a products success and your employees will start speaking a bit more clearer.

Instead of relying on a review process to rate employees, a company might let people choose who they work with and on what projects.

If a significant portion of one's income can actually be influenced by an employee's choices, they will tend to act on what they know rather than tell you what you what to hear.

In other words, people should have a stake or actual stock in their projects, not stock in the whole company.

And if its actual stock that can be traded within the company, the stock price will tell you whether the project is going to succeed.

</comment><comment><USER16> Yeah yeah but how do you avoid getting grinfucked by yourself? That's what I want to know.

</comment><comment><USER17> +1 for alerting me to the term "grinfucking" with references. Excellent post!</comment>


Show HN: Stay Focused – Be Awesome. Commit to your priorities and take action - <AUTHOR> http://rakepage.com

<comment><USER2> This looks really cool.</comment>


My favourite "ace" things on amazon - <AUTHOR> http://www.acekit.co.uk/

<comment><AUTHOR> Website maker here. Avid HN fan also.

I love building sites and have been trying to monetise something for a long while. Am hoping to get a small amount of success which would spur me on. Am failing.

My latest plan is [http://www.acekit.co.uk](http://www.acekit.co.uk)

The traffic is just not there despite trying webmaster tools / page speed optimisations / social media etc. I even threw some AdWords money at it - please don't tell Mrs Acekit - boy you can burn money quick on that if you turn on the tap.

Obviously the idea is to make money via the Amazon click through scheme. Maybe it's too overt abd users don't like that or google are penalising. Idea to use Amazon was that it was frictionless and easier to build (no user authentication etc required).

Just don't know.

They say fail quick, maybe I should pull plug and think again?

Maybe I spread myself too thin with some product reviews. The most extensive and "from the heart" one is the raspberry here..

[http://www.acekit.co.uk/products/3-raspberry- pi-2](http://www.acekit.co.uk/products/3-raspberry-pi-2)

Any tips / reviews / comments appreciated, fully prepared for some tough love. Would dearly love to get something built with some sort of following that I can develop.

<comment><USER2> When I use review sites, I'm normally looking for a comparison, so that I can choose the best toaster (for example), or I'm looking for assurance that the product I'm looking at has no major issues. Your site seems to provide more of the latter than the former - perhaps more reviews would help? (But would _you_ want to buy three different toasters in order to compare them?)

<comment><AUTHOR> Thanks for this, appreciate the feedback. I'm going to think that over. My initial idea was to just feature a few products that I really value and talk about them in detail. The router on the site for example has been great, so much so that I got one for my Mum also - so it has an extensive review, billion 7800n in case it matters.</comment></comment></comment>


Tell HN: Removing "Bluetooth PAN" from Mac OS settings fixed all my pains - <AUTHOR> It's been months since I have annoying issues with bluetooth devices connected to my Macs. My mouse was sluggish and laggy and my speakers were unreliable and disconnecting randomly. It was an everyday pain that I learned how to live with.
I always though it was the 3rd-party but today I removed the Bluetooth PAN from the Network settings and almost immediately everything was working as new.
PS: I'm reading on some (6 years old) articles that the Bluetooth PAN was causing issues like this. Can't believe how Apple sometimes can be this unreliable, I almost gave up on using my equipment thinking it was faulty.
-- For people having same issues, hardware references :
* Mac : Pro 15 (2018) / Air 2020 both on Catalina * Keyboard : Apple Magic Keyboard * Mouse : Logitech MX Master 2S * Speakers : Harman/Kardon Onyx Studio 4 <comment><USER2> I have similar issues with a late 2012 MBP when playing music to Bose headphones, sometimes airpods, and external speakers. I thought it was interference from other bluetooth devices. Trying out your recommendation, though I didn't remove Bluetooth PAN, I just set it to 'inactive'. We'll see how that works. I also went through all the network services and set all of the ones I never use to 'inactive' as well. Thanks for the post.</comment>


Show HN: Tensorflow and Inception v3 on MNIST - <AUTHOR> https://medium.com/@teavanist/digit-recognition-using-tensorflow-mnist-in-jpg-inception-v3-transfer-learning-93-accuracy-501ba7eb52ea <comment><AUTHOR> Hi all,

I used TensorFlow and Google's Inception v3 model to recognize the MNIST digits after converting it to JPG format. Model got an accuracy of 93% I wrote a medium post about it. Do read and let me know what you think. Thanks !

[https://medium.com/@teavanist/digit-recognition-using- tensor...](https://medium.com/@teavanist/digit-recognition-using-tensorflow- mnist-in-jpg-inception-v3-transfer-learning-93-accuracy-501ba7eb52ea)</comment>


Why TV newswomen look like they're going to a cocktail party - <AUTHOR> http://www.bostonglobe.com/metro/2017/08/14/why-newswomen-look-like-they-going-cocktail-party/AQq0w7piieQagmHCeFQ8IO/story.html?s_campaign=bdc:article:stub <comment><USER2> Sheesh and I thought they were only supposed to advance themselves on their powers of vocal persuasion and creative storytelling. You mean to tell me some career professionals take advantage of our innate biological differences to leverage their careers? Scandalous. Who will be the first to "out" them?

</comment><comment><USER3> what else does tv news have left to sell?

</comment><comment><USER4> Hi. Hetero here. Author of that article has been to some pretty sad cocktail parties. I love that the main image of this story features a woman reporter wearing a shirt cut just below her _chin_. Sorry, that's not exactly sexy. I've never really had a thought about how hot the anchorwoman looks. Never. Never seen cleavage or anything close to it. Not that I would care anyway if they did. It's mainstream state media anyway. If I wanted to see tits I would go watch porn. If I want news I would certainly not watch TV. Maybe the female reporters want to look good? Ever think of that? Sometimes its not for others, but for that person. Maybe they feel better not looking frumpy on live TV..

You know, it seems bullshit arguments like this are probably coming from the same line of the emasculating messaging generally present. Nobody wants any more dick? Fine. The obnoxious man hating liberals who scream inequality can't have any more spawn to further their nonsensical agenda.

Meanwhile, maybe we can have male reporters wear thongs. Would that make the author happier? Then they'd say male reporters were being lewd hairy creeps. Maybe we have a dog or Microsoft Clippy read the news? Fuck you people. You're the reason society is slowly eroding and everyone is becoming needy whining pussies. Go rub some dirt in it. Learn to stand up for what really matters. See things for what they are and not what you want them to be. And most of all, maybe don't report on non-issues. You should be ashamed to be a reporter.

<comment><USER5> You haven't been watching tv in the last 30 years if you don't think female reporters are told to dress sexy, with too much makeup an cleavage on display. Then you complain that society is being degraded by complaining about this - so you do see the sexy reporter stereotype?

Imagine if these standards were applied to men who are programmers. Instead we can dress however poorly we want, bad grooming is basically celebrated.

<comment><USER6> While I think it's ridiculous for women to have to dress a certain way, we also have to understand that sex sells and it's not illegal to use sexualized images to sell products.

News is a product like any other. If the way anchors look and dress are correlated with the number of viewers and the station's bottom line, what are we supposed to do in a capitalist society? Pretend there is no value in aesthetics or provocative imagery?

I bet if programmers dressing provocatively was positively correlated with increased profits, we'd see some low-key encouragement on programmer attire.

I still think it's bullshit for women, but I can see a case for wanting sexy people in front of a camera. If looks didn't factor into anchors careers in any way whatsoever (for both men and women), I am willing to bet over half of current news anchors would never have become anchors in the first place.

However, I do think if stations want their anchors to be glorified models then they need to be upfront about it from the get-go so all people are aware of the requirements and stipulations of the careers/jobs they are pursuing.</comment></comment></comment>


U.S. Moving Forward with Rule to Limit Chips to Huawei - <AUTHOR> https://www.wsj.com/articles/u-s-moving-forward-with-rule-to-limit-chips-to-huawei-11585261519 <comment><USER2> As Dirty Harry would say "Go ahead. Make my day!"

If the US wants China to go ahead and develop its own chip manufacturing and undercut and then destroy future US chip sales, it's going about it exactly the same way as it has already destroyed US textile, paper, and pharmaceutical manufacturing in favor of the Chinese manufacturing those things.</comment>


Ask HN: Do you know what is Digital Clothing? - <AUTHOR> Hi all! I am doing a research for FashionTech project and I need your voice in 2 simple questions:
1) What is most important for you in clothing?  Choose one: (Speed&Access | Brand&Exlusivity | Personality&Customization | Ecologic) 2) Do you know what is Digital Clothing? ( Yes|No)
It would be great if you can answer like that: "Brand.Yes" or "Speed.No".
Feel free to comment or ask something. Unfortunately, I can't post my full survey here but if you interested or into help me with cusdev -write something in comments.
Thanks in advance! <comment><USER2> Customization.Yes

DigitalClothing.No

A bit confused regarding your formatting requirements there... but basically fitment and quality are most important to me and I'm not sure it's in your list. No, I don't know what Digital Clothing is. This is an engineer centric crowd so your responses would probably differ from other channels..

<comment><AUTHOR> Thanks for your voice! I know that suggested things do not reflect all values and may not respond to yours perfectly but we are focused on particular things.

</comment></comment><comment><USER3> Ecologic.Yes Digital.No

For me "ecologic" has to do with durability and practicality, not necessarily that the materials are exotic in origin. Some of my best clothes I bought used; if you are going to wear a shirt 100 times you can afford to spend more on it.

</comment><comment><USER4> Ecologic.yes

It has to last a long time and ideally be made of commonly available materials. Cheaper is better, but quality is worth it.

Digital Clothing.No</comment>


What is Rust and why is it so popular? - <AUTHOR> https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/ <comment><USER2> Over the last couple of months I've been slowly, but steadily playing with Rust. I work on embedded systems and while it's gaining traction only slowly, it feels to me reasonably likely that we'll be seeing non-trivial applications in the next 8-10 years. I doubt that we'll see it used for low-power/resource- constrained firmware, but lots and lots of embedded systems are now bulky Linux boxes with years of uptime, and I can see Rust making inroads there. It's not a bad idea to be ready for this, just in case it turns out to be a revolution.

Honestly, I like it, and for all the non-hyped reasons.

Like ownership. Lots of us in the embedded space aren't so impressed by the extra memory safety because, if you allocate all your memory statically, there are fewer ways to screw things up with references, and it's a lot easier to do bounds checking, so fewer bugs slip in. Not that "even fewer" isn't good, it's just that the impact is less dramatic than in application code.

 _But_ : the borrow checker still pesters me about something I've written every once in a while. And every once in a while, what it pesters me about is a data race that would have definitely bit me in the back sooner or later. It has no security implications, I guess, and it wouldn't crash my program, but it's still wrong. Yay!

Or like traits, which are just so refreshingly sane.

Lots of people are hung up on security and segfaults, and spend far less time talking about a far less categorical property: the conventions that Rust enforces make it easier to write correct code. _Sometimes_ it's not straightforward code, mind you, but "works right" trumps "fits in a single line" in my book...

In many ways, Rust is what C++ could have been if it had not been designed by saying yes to everything. I guess it's not _there_ yet, but there's a chance it might be.

On a more, uh, philosophical note, I think it's pretty cool that our industry has been granted a second chance in this regard. We've already been given Ada, and we missed the chance to adopt it on a wide enough scale to make a difference. Maybe we won't miss this chance.

<comment><USER3> I think that Rust's approach to safety -- soundly eliminate UB in safe code -- comes at the high cost of complexity. This affects how easy it is to write custom compilers (very important in the embedded space), but it is also not necessarily the best way to reduce bugs. For some, this cost is acceptable, and I'm sure some people may even welcome the high-level-looking code [1] that Rust and C++ support, but I think there are better ways, ones that are more appealing in low-level ("systems") programming in general and the embedded space in particular: [https://news.ycombinator.com/item?id=21970987](https://news.ycombinator.com/item?id=21970987), [https://news.ycombinator.com/item?id=22021237](https://news.ycombinator.com/item?id=22021237)

Rust is without a doubt a (much) "better C++" but I'm not sure a better C++ is necessarily what systems programming needs most.

[1]: Not that _writing_ that code is as easy as in a high-level language, nor does it offer the same level of abstraction as high-level languages, where changing the details of the implementation does not affect the API and its clients, but it _looks_ high level, or "expressive", on the page.

<comment><USER4> > This affects how easy it is to write custom compilers (very important in the > embedded space)

Is there a reason you'd write your own Rust compiler _frontend_ , rather than just letting rustc generate LLVM IR as it does, and then writing your own LLVM arch target? None of the Rust complexity leaks over into the LLVM IR it generates; it looks just like the LLVM IR that e.g. clang generates.

<comment> Const-me > None of the Rust complexity leaks over into the LLVM IR it generates

The leakage even triggers performance issues in compilers: [https://users.rust-lang.org/t/5-hours-to-compile-macro- what-...](https://users.rust-lang.org/t/5-hours-to-compile-macro-what-can-i- do/36508)

<comment><USER4> No, that's not "Rust leakage", because that misbehavior has nothing to do with the _semantics_ of Rust as a language. That's the effect of some non-optimized function-scope-level pattern-matching substitutions that LLVM is applying, as applied to the user's very large function body. Quoting a reply in that same thread:

> LLVM is not good at big functions, I have seen this before as well. One of > the functions you are generating is almost 100,000 lines of Rust code > including tons of internal control flow.

The same would happen if you wrote (or generated) 100,000 lines of C in one function body, and fed it through Clang with -O2.

If you're wondering, there's nothing in rustc that makes it implicitly turn regular code into huge function bodies, either. It's just someone abusing Rust macros to codegen _badly_ , not taking into account how the granularity of units of compilation interacts with the time-complexity of optimization passes.

<comment> Const-me > that misbehavior has nothing to do with the semantics of Rust as a language.

Macros are part of the language; they aren't an external code generation tool.

> The same would happen if you wrote (or generated) 100,000 lines of C in one > function body

Absolutely, but neither C nor C++ makes it easy to generate such code. Technically doable with C preprocessor, but it's not easy. C++ templates don't normally expand into 100k lines functions either, they can easily expand into 100k small functions.

<comment><USER5> People write code generators that emit C/C++ code all the time, and 10KLOC functions coming from such a generator isn't unheard of. The x86 instruction selector LLVM generates from tablegen is over 240KLOC, although that's emitted effectively as an interpreted table, so the actual code size of the function is much, much smaller.

<comment> Const-me You're correct that it's possible to trigger that performance issue without Rust.

However, it doesn't happen with idiomatic C or C++ code. C macros are too hard to use for that. C++ templates are designed to expand into many small functions, as opposed to a single huge one.

It was Rust complexity leaking over into the LLVM IR.

<comment><USER4> > C++ templates are designed to expand into many small functions, as opposed > to a single huge one.

...so are Rust macros. The user was using Rust macros very non-idiomatically.

Also, you don't use C macros to write (large amounts of) C. 90% of the world's generated C, by volume, comes from, I would say, one of two programs: autoconf (through m4), or yacc. And both autoconf check stanzas and yacc's inline C support are easy to screw up in ways that result in horrible code that makes compilers barf.

Also, to be clear, you're conflating two things with the phrase "Rust complexity." This thread was originally about the difficulty of _implementing a Rust compiler_ for a toolchain, which therefore makes "Rust's complexity" here refer specifically to the complexity of the static-analysis semantics of Rust that make writing a Rust compiler _frontend_ difficult.

The solution—relying on the existing rustc frontend for the "hard stuff", and just implementing your own compiler backend to target the embedded architecture—is not rebutted by a claim that you can write bad Rust code that makes the _optimization passes_ of certain compilers choke. You wouldn't even be writing optimization passes. You'd be writing a backend. The optimization passes are universal. It's the job of the LLVM developers to ensure that they don't choke on things like this.

And, despite the fact that 100,000-line functions are dumb, it's the LLVM development team's fault that the optimization passes were written in such a way that their time-complexity is superlinear in a way that stalls out when optimizing a function like that. It's not up to the Rust compiler authors to not emit that type of code, or to somehow prevent you from writing it; it's up to the LLVM devs to make their optimizer work, and work efficiently, for any "valid" code. Honestly, if anything, this code—if you could get it—would be a great integration test to submit to LLVM, for them to work towards passing.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I work in the embedded space, but the majority of my work is writing simuators, mathematical models and tests. One of the hidden benefits for us was that rust is suitable for both resource-constrained embedded code (we use a lot of C for this) and high-level desktop and cloud based infrastructure/sim/test code, which we would never consider writing in C. Serde is amazing, crates.io has so much good stuff on it, C interop is a breeze. We still use Python/matlab for exploratory and data-sciency work, but as soon as something lives for more than about 6 months, it usually gets re- written in rust.

<comment><USER7> Now switch to Julia instead of Python/matlab and you have a really solid stack.

<comment><USER8> Julia lost its momentum, and for good reasons: insuficient or rushed up libraries, no option for the generation of standalone executables and general overselling (by the way, bashing Python at every opportunity didn't lead to a higher volume of users)

<comment><USER9> Not sure the data supports that ,: [https://juliacomputing.com/blog/2020/01/06/january- newslette...](https://juliacomputing.com/blog/2020/01/06/january- newsletter.html)

</comment></comment></comment></comment><comment><USER10> I think one of the biggest benefits of Rust is it bakes in static analysis of code as a first class feature. Which means the language is amenable to analysis and you don't have to use third party tools to benefit from it.

I also like some of the abstractions. They're clever in their simplicity. For example, an iterator over an array or vector is simply doing a for loop using pointers.

<comment><USER3> Yes and no. It provides _some_ kinds of (important!) static analysis out of the box, but at the cost of complexity, which directly adversely affects some other kinds of (also important) static analysis. For example, there are _sound_ static analysis tools that guarantee no undefined behavior of C code, but AFAIK, such tools can at best only work on a subset of C++, because of its complexity.

Rust goes all out on eliminating undefined behavior, and may well be the best way of doing that in low-level programming, but eliminating UB is just a means to an end, UB is not the only source of dangerous bugs, and if the cost of eliminating it is high it may not be the best way overall of reducing bugs in low-level languages.

<comment><USER11> What is the complexity, and what are its costs? As an active user of Rust, I haven't seen the (adverse) complexity or its costs yet.

It's worth pointing out that Rust combats more than undefined behavior. Undefined behavior is a category of bad things that Rust works to eliminate, but Ownership goes beyond eliminating UB, and eliminates a large swath of potential logic bugs.

<comment><USER12> Programming in Rust is complex, I'm not sure how can argue against that, it is not straight forward to do simple tasks because of how you need to organise your architecture with the borrow checker.

Most people that starts using Rust get stuck on issues that you woudn't have with other languages.

<comment><USER13> In my experience the difficulty of picking up Rust is most pronounced for people experienced in other languages that have common design patterns that are discouraged or made impossible by Rust. It's harder to unlearn something that from your point of view _works_ (even if it had hidden or clear drawbacks) when you're also having to learn other things simultaneously. Also, I feel the biggest hurdle Rust has for experienced developers from other languages is that Rust makes some ineficient code _visible_ , but the way of optimizing it requires delving into more advanced parts of the language, frustrating people when they are most "vulnerable". This is where the common piece of advice for people starting with rust "just clone for now and don't think about it" comes from: get used to the language first and deal with borrowing on its own at a later time.

But all of this frustrating learning curve comes to fruition later in when writing code because the experience is closer to pair programming with the compiler rather than trying things in a vacuum on your own.

</comment></comment></comment></comment></comment><comment><USER14> Because the StackOverflow survey which Rust keeps winning defines "Most Loved" as:

> % of developers who are developing with the language or technology and have > expressed interest in continuing to develop with it

Because there aren't that many Rust jobs, almost no one _has to_ use it. Which means people either try it and leave, they like the language and stick around, or they never use it (the overwhelming majority of developers). This leads to the Rust being the most loved language by the above definition, which is completely different from "popular" (as in the title of the OP).

If I make up my own language that I plan to never stop using, even if no one else ever touches it, I'll get 100% "Most Loved" on StackOverflow's survey.

<comment><USER15> Well, yes. There are plenty of popularity metrics there already, this one is about something else.

As you said, mainstream languages won't win this one. But it is a valid metric anyway, and there is plenty of merit on winning it.

<comment><USER14> Think about this - if a bunch of people hate a language and stop using it, the following year that language's "most loved" score will _increase_. I wouldn't call that merit, it's just a bad metric.

<comment><USER15> Yes, if people can simply stop using a language, it will not be hated. That's how it works on real life too.

But most of the time, people can't stop using languages.

</comment></comment></comment></comment><comment><USER16> Rust is a great language if you use for what was intended, system programming and as safe substitute of C and C++.

But it's not the answer of everything, to me it's nowadays abused in a lot of projects, there are instances of project where using Rust not only doesn't make a lot of sense but also can be slower than another languages, there are cases where Go is better, other where Node.js is better, other where Python is better, other where Java is better, etc. To me the Rust community seems to want to argue that everything should be rewritten in Rust, just because Rust solves every problem, while it's not.

<comment><USER17> OK, I will bite. If I had to come up with a case where Python is better than Rust, I would say with rapid prototyping and scientific computing. If you just want to try a few things out, python has faster development cycle and if you want to do some super clever math python has better library support. With a bit more mind stretching, I can make a case for Go with a bit more mind stretching. If you want to write a massively parallel network server of some sort you might be better off with Go, especially if you want to use protobufs and grpc. But what would be the case for Node and Java?

<comment><USER18> > If I had to come up with a case where Python is better than Rust, I would > say with rapid prototyping and scientific computing.

Scripting? I'm not gonna write a 50 LOC single-use script in Rust.

<comment><USER13> I've found that a lot of scripts end up _not_ being single use. In my case they usually do end up rewritten in Rust, with the benefits of having a proper --help command from the bother. Once you know enough Rust the obtuse parts of the language that must exist to cater for the performance critical crowd cease to be a problem.

</comment></comment></comment></comment><comment><USER19> Rust using the LLVM toolchain is a real plus, which Clang also uses in the C++ world. The Clang and Rust compilers are basically frontends to LLVM, and any language that compiles using LLVM is translated to IR (intermediate representation). All code optimization is done on the IR code itself in LLVM, which both Rust and C++ compile down to before being compiled further into assembly. That means that the same effort that goes into optimization in the C++ world for Clang is shared by the Rust community too, and any other compiler that uses LLVM.

<comment><USER20> We have started doing our own optimizations too: [https://blog.rust- lang.org/inside-rust/2019/12/02/const-prop...](https://blog.rust- lang.org/inside-rust/2019/12/02/const-prop-on-by-default.html)

Your overall point is absolutely correct though. We couldn't have done this without LLVM.

<comment><USER21> Can you comment on the current state of non-aliased related optimizations? The issue tracker is byzantine on that one and i can't tell if or to what degree those optimizations are now done.

<comment><USER22> Yes, Rust has the potential to be faster than C, or even C++. But the compilers' implementations of such optimizations are far too buggy to turn on.

<comment><USER21> All the usual caveats apply, but benchmark game has rusts median already better than c++, but not as good as c. They are all so close that performance shouldn't really be a consideration between them I think. You can see g++ vs clang++ now too.

</comment></comment></comment></comment></comment><comment><USER23> The example of an error message in the blog post is the kind of thing that makes me seriously consider trying out rust. It's excellent. Are most rust error messages like that?

<comment><USER24> Most are that good, or better. I actually debated putting that error because it's one that doesn't have a "help:" line that actively suggests how to fix it.

Some errors are admittedly worse, and people like estebank are actively working on improving them.

<comment><USER25> You're the author of the blog post? Dunno if this is something you care about, but with JS turned off the code boxes are omitted (with no placeholders or other clues that something is missing.)

<comment><USER24> I am! It's something I care about, but not sure if there's something I can do about it. The code blocks are powered by a `<script>` tag from GitHub's Gists. Unfortunately, I don't have the ability to edit that post without Wordpress completely removing those tags (I don't have appropriate permissions). I can ask for them to put `<noscript>` tags, but don't know if that will really help.

</comment></comment></comment></comment><comment><USER26> The more pressing question: What is Rust and why is it so popular on HN?

<comment><USER27> I did an internet search for Rust jobs and it was near-zero. Would be nice but reality calls.

<comment><USER28> Rust is over the "100% hobbyist" phase, but it isn't still in the phase where you hire "Rust developers" verbatim. There's an important phase in between: Rust is being introduced in organizations as we speak, and some people that were originally hired for some other skills, develop in Rust they picked up because they were enthusiastic about it.

I am in that position at the moment. We are a multi-language shop, and there's some components that make sense to write in Rust.

<comment><USER29> I'm in the same spot. Given the large number of companies who are willing to state that they use Rust ([https://www.rust- lang.org/production/users](https://www.rust-lang.org/production/users)) without being able to find openings that are explicitly for Rust, I'd say you're right.

</comment></comment></comment></comment><comment><USER30> Wow, that is an extremely well-written brief introduction to Rust. I love the way it manages to address some more technical (e.g. FFIs, distinction between borrow-checker and other parts of compiler) but important concepts despite being so short. Thanks very much Jake Goulding if you're reading.

<comment><USER24> You are quite welcome! Hope to see you writing some Rust sometime!

<comment><USER30> I have tried one project so far: [https://github.com/dandavison/delta](https://github.com/dandavison/delta)

</comment></comment></comment><comment><USER31> Rust for me is the modern C/C++, as much as Go is the modern Java. I see no point going back to C/C++ now and I will now reject any job offers that deal with these languages.

</comment><comment><USER32> I like the fact that Rust has a set of libraries (crates and the standard library) that provide a lot of the features that you end up re-inventing if you stick with C. Even C++ is pretty fractured in this regard.

A lot of why this is hard in C/C++ is memory management. Even if you had a package manager it would be hard to compose libraries together unless they were designed together (like boost for C++).

<comment><USER22> I see that you have no experience with C++ in the past decade. There has been no fragmentation in C++ resource management since C++11.

<comment><USER32> That's fair - last time i used C++ in earnest was around 2007. Unless they broke compatibility, it would still be opt-in, though, right? Nice thing about Rust is that the resource management approach is built-in and enforced by default.

<comment><USER22> Everything in C++ is opt-in.

The Standard C++ Library supports user-managed allocators for all the containers, heavily used in embedded, low-latency, and real-time applications to get deterministic performance.

Lack of standard support for user-provided allocators indicates immaturity. E.g., C++ lacked them until 2011.

</comment></comment></comment></comment><comment><USER33> I realize /r/rust (Reddit) isn't representative of the entire Rust community but it's given me a really bad impression of Rust culture.

<comment><USER14> Reddit is great for memes and humour, not much more. Go through any subreddit on a topic that you know well, and you'll likely be disappointed.

<comment><USER15> /r/haskell is pretty good. /r/python isn't great, but not bad either.

There are subredits of every kind, even great ones. But they change with time.

</comment></comment></comment><comment><USER34> As an embedded systems engineer I have very mixed feelings about Rust. There are a lot of things to like, but Rust seems to miss the point why C++ didn't replace C and will fail at that for the same reasons. I wish for an economic, unexciting, conservative evolution of C, which I don't see in Rust. I could imagine C++ being replaced by Rust, though I don't think borrow checking is the future of programming.

Another point is the tight integration with cargo, which may lead to the same dependency problems that npm has. But it will cause significantly more struggles because of licensing issues. While most npm code was running on servers, it didn't matter. In the embedded space companies typically insist to have every library checked by a lawyer before it gets shipped with the product, which will make cargo essentially useless.

The last one is the community. In fact I think a programming language is to the largest part about the people using it. And Mozilla sadly created a hype and a hostile community by aggressively evangelizing the language.

<comment><USER20> Just so you know, there's tools that let you check the entire set of licenses of your dependency tree, and whitelist/blacklist them. Amazon implemented one after they started using Rust more seriously.

</comment></comment><comment><USER35> The reason that it's popular is that it's immediately clear that Rust's model of memory safety without a GC and safe concurrency is the best way to create a programming language since it unifies the memory safety of GC languages like Java, the efficiency of C and the concurrency of message-passing systems like Erlang in a single language that has none of the drawbacks of those systems.

Before Rust, everyone simply assumed that it was impossible to create such a programming language since it would have otherwise been what everyone used, and now that it turns out that it's possible, it's clear that it's the best solution and what should be used in the future whenever possible.

</comment><comment><USER36> Some problems which are harder in Rust:

[https://stevedonovan.github.io/rustifications/2018/08/18/rus...](https://stevedonovan.github.io/rustifications/2018/08/18/rust- closures-are-hard.html)

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

</comment><comment><USER37> Still not hyped. The article does not show anything special or new about the language that would attract me personally. Type inference -- nothing new and exists in many other languages. Actually how about compile type inference not only in function bodies? :) Functional niceness with iterators -- also nothing new. It can be even more succinct and elegant in Scala for example. But Scala is not as fast you'd say! Yeah, so what? Python is not as fast as Scala, so.

Control over low-level details is something that exists and should be in any system-programming language. How is that even a benefit? It is a niche feature.

Memory safety? You can circumvent it by using "unsafe" and as recent Actix case shows it can propagate really deep. Should I read the code of any other Rust library now? What if I am a programmer newbie driven by the hype without a clue what does memory safety entail? What-ifs... I won't talk about compile times and the fact that in order to compile some cli tool one has to download ~200mb of rust "stuff". This is simply insane and I refuse to understand how is this considered to be not an issue.

Rust ecosystem is probably its strongest point right now which is somewhat funny because it grew out of beliefs in the above "benefits". So, not hyped, sorry.

<comment><USER20> > Actually how about compile type inference not only in function bodies?

This is actually an explicit design decision; it means that the analysis is tractable, and that you don't get spooky-at-a-distance error messages.

<comment><USER38> It's a major detractor, especially for people new to Rust.

The number of times I see people recommend "just cut and paste in whatever type the compiler said it expected ..." just makes my hair curl.

It also tends to make the code more obscure and unreadable, sometimes completely so.

</comment></comment></comment><comment><USER39> What influential applications are written in rust? For c++, there is llvm, chrome, game engines, I feel like c++ is standing very strong in any of these fields still, why is that? Do u think it's going to change soon?

<comment><USER22> No essential programs are in Rust, in the way that e.g. Docker is in Go, or your examples in C++, and none are on the horizon unless Cargo becomes a popular way to build C++ or C programs. Rust is popular to post about on HN, but the number of people actively coding it is at least 4 orders of magnitude fewer than mature languages, and the number of people adopting it, likewise: the number of people adopting C++ is many times larger than the number who have ever even heard that Rust exists. Those numbers will take many years to change, if they do. Just as likely, some new hotness will pop up and distract the early adopters; Rust could very possibly fizzle out. (That would be a shame unless the new hotness were enough better. Rust++?)

Promoting Cargo as a way to build C++ and C programs could be a way to establish Rust underpinnings. Cargo is better than most other build systems now used for C++, and with C++20 getting modules, the fit is improving.

</comment></comment><comment><USER40> Does anyone know how StackOverflow measures "love" towards a language?

<comment><USER24> > % of developers who are developing with the language or technology and have > expressed interest in continuing to develop with it

[https://insights.stackoverflow.com/survey/2019?__hstc=188987...](https://insights.stackoverflow.com/survey/2019?__hstc=188987252.63a31c9ff9cab1812469cb8b44e5d5f1.1579486003016.1579544559356.1579630210345.5&__hssc=188987252.1.1579630210345&__hsfp=3030258021)

</comment></comment><comment><USER41> I like everything I see and read about rust but I'm unsure where I'd fit it into my work. Does rust have a future in areas like backend web development or mobile?

<comment><USER20> My employer, Cloudflare, uses Rust as part of our mobile app for 126.96.36.199. It's still rough around the edges, you basically integrate Rust like you would a C dependency, but it's been working great.

There are some backend web development deployments at other companies, but the ecosystem has been changing a lot over the last year. It's starting to settle down though. Expect more "Flask" and less "Rails."

</comment></comment><comment><USER42> I like Rust, however as usual the article fails short of mentioning Ada, and GC languages that share the same resource management capabilities as C++, alongside their GC.

<comment><USER24> I wouldn't want to mention any language I don't have experience with for the risk of mis-speaking. I also tried to minimize talking about any specific language where I could.

<comment><USER42> Fair enough.

I just made the point, because from security point of view, we all have to gain no matter what safe systems programming languages get adopted.

It doesn't need to be Rust vs the others, in what concerns improving the current state of IT security.

For example, Nvidia is now adopting Ada/SPARK for security critical firmware.

</comment></comment></comment><comment><USER43> Rust newbie here. How do you fix the compile error for the example given? I imagine it has something to do with transferring ownership, but I'm not too sure.

<comment><USER44> Are you familiar with C++? That example is roughly equivalent to:

      #include <string>
      #include <iostream>
      #include <string_view>

      int main()
      {
          std::string name { "Vivian" };
          auto nickname = std::string_view { name }.substr(0, 3);
          name.clear();
          std::cout << "Hello there, " << nickname << "!\n";
      }

which will happily compile, but whose behavior is undefined.

<comment><USER45> Is the behavior undefined because std::string makes a deep copy of the string? I thought 'Vivian' would be placed in read-only memory and as long as you don't modify it, you can hold read-only references to it.

<comment><USER44> Yes, `std::string` owns its own copy of the string in typical implementations (as does Rust's `String` type).

`std::string_view` references that copy. `std::string::clear` destroys it, leaving the `std::string_view` dangling.

</comment></comment></comment></comment><comment><USER46> Great article. One nitpick:

> One of the biggest benefits of using a systems programming language is the > ability to have control over low-level details.

I think this is a misguided conflation of "systems programming" and "low-level programming", those are separate things. See [http://willcrichton.net/notes/systems- programming/](http://willcrichton.net/notes/systems-programming/)

<comment><USER47> Ah, the eternal argument over what qualifies as "low-level". I think we can all agree it's not Javascript, but beyond that opinions vary greatly and it's mainly a semantic issue.

<comment><USER22> With current languages, we should speak more about range.

C++'s and Rust's ranges stretch from C's at the bottom up to near ML's. Java is stuck in a little space in the middle.

</comment></comment></comment><comment><USER48> It's a programming language and it's not popular.

<comment><USER49> Any day now, it's going to overtake Logo on the TIOBE index. You just wait.

</comment></comment><comment><USER50> This language is awesome, but I'm quite conservative when it comes to syntax. I don't like how Rust is trying to move away from C when considering syntax. I tend to prefer languages that can adopt the "C flavor". Python, in my view, does this very well: its syntax is simple, because it borrows a lot from C in its "flavor".

Rust is not doing that, and that's a hurdle.

In my view, the "C flavor" is very important because it's a standard of how people are able to read code. This has nothing to do with the C programming language, I'm just saying that simplicity is what made C popular and easy to use. I can understand that Rust brings very nice innovations, but in my view it should have done so while keeping the "C flavor" as most as it could have.

I admit it's a conservative view, but I tend to believe that a language can be more easily adopted if at its most basic level, it's simple to read for beginners. Rust is not great: I'm not talking about its learning curve, I'm just talking about the "flavor". A language is a tool of expression and communication, features matter less than readability.

<comment><USER51> I'm not sure I follow. Rust syntax seems far more similar to C than Python syntax does. What parts of the Rust syntax do you feel depart from C-style syntax?

<comment><USER50>
        fn add2(x: i32, y: i32) -> i32 {
            x + y
        }

variable declaration is varname: type, it makes it very hard to read when declaring arrays or other things

return type is after the paren

the let keyword seems redundant/unnecessary, a little like var in js

Those are good example of "c flavor". I guess they're easier to parse, but still I would rather have C flavor instead.

<comment><USER26> "Very hard to read"? As in, _harder_ to read than the C declaration syntax for the same types? That's a logical impossibility!

<comment><USER50> STL containers are pretty easy to read</comment></comment></comment></comment></comment>


Show HN: Fast Style Transfer in TensorFlow - <AUTHOR> https://github.com/lengstrom/fast-style-transfer/ <comment><USER2> Terminology note: there is a difference between Style Transfer and _Fast_ Style Transfer.

Fast Style Transfer takes a _very_ long time to train a style model (and the output models can be somewhat large; the pre-trained models in the Dropbox are 20MB), but the styles can be applied quickly. Fast Style Transfer is the technique that is used by Prisma/Facebook. This repo is the first I've seen that uses TensorFlow instead of lua/Torch dependency shenanigans, and as a result should be much easier to set up. (this code release also beats Google's TF code release for their implementation: [https://research.googleblog.com/2016/10/supercharging- style-...](https://research.googleblog.com/2016/10/supercharging-style- transfer.html) )

EDIT: Playing around with this repository, I can stylize a 1200x1200px image on a dual-core CPU on a 2013 rMBP in about 30 seconds.

Normal Style Transfer is ad-hoc between the style image and the initial image; it can only be used for one image at a time, but overall it is faster than training a model for Fast Style Transfer (however, this is infeasible for mobile devices).

<comment><USER3> Thanks for the details on this - one question is your rMBP using CUDA/Nvidia for the 30 sec render?

<comment><USER2> No, which is why I specified dual-core CPU.

The README cites ~100ms with a Titan X using CUDA, although speed depends on image size.

</comment></comment></comment><comment><USER4> Nice work! Have you seen this - could help reduce some of those checkerboard artifacts

[http://distill.pub/2016/deconv-checkerboard/](http://distill.pub/2016/deconv- checkerboard/)

<comment><USER2> Playing around with the tool a bit, supersampling seems to work pretty well to avoid those artifacts. (Thanks to the speed of Fast Style Transfer, this is feasible.)

EDIT: There's a catch. The checkpointed models are calibrated for smaller images, so you'll get better _styles_ with smaller images. Larger images tend to just have images repeated: [https://twitter.com/minimaxir/status/793161755992002560](https://twitter.com/minimaxir/status/793161755992002560)

</comment></comment><comment><USER5> Utterly amazing what people are achieving with neural nets. The idea that 'style transfer' can be fit into an algorithm is slightly blowing my mind right now.

The jumping fox video does looks a bit 'off' though, I think because the animation is kept the same and so it ends up looking too realistic for that style. Still this is early days!

<comment><USER6> To get an idea of how style transfer works, it can be useful to look at some less successful examples. Here's one from the same git repo:

[https://github.com/lengstrom/fast-style- transfer/blob/master...](https://github.com/lengstrom/fast-style- transfer/blob/master/examples/results/chicago_wave.jpg)

(Original photo: [https://github.com/lengstrom/fast-style- transfer/blob/master...](https://github.com/lengstrom/fast-style- transfer/blob/master/examples/content/chicago.jpg) )

With the "Great Wave" painting as the network's style input, the limitations of the technique become more apparent. It's clear that a human painter would never render the Chicago skyline in this way: there are incongruent little waves on buildings' edges and all over the sky.

The antennas on top of the tallest tower are particularly revealing. The neural network just sees an area of higher local contrast, and has continued the same pattern that was applied in the sky at the top-right of the antennas but with more contrast applied. This doesn't make any sense for what's supposed to be a painting.

There's no intelligence here, "just" pattern matching that can do a brilliant illusion of creative variance on the right kind of content. ("Just" in quotes because it's still a great achievement.)

<comment><USER7> Now we need some kind of object recognition-enhanced version of style transfer that learns constraints on what "makes sense" given "sensible" labeled/captioned training examples!

<comment><USER8> It has been done with manual segmentation [1]. And the results are mind blowing. There also a lot of work done on segmentation with neural nets [2, 3], so I wouldn't be surprised to see someone implementing this idea in the near future.

1: [https://github.com/alexjc/neural-doodle](https://github.com/alexjc/neural- doodle) 2: [https://arxiv.org/pdf/1605.06211.pdf](https://arxiv.org/pdf/1605.06211.pdf) 3: [http://mi.eng.cam.ac.uk/projects/segnet/](http://mi.eng.cam.ac.uk/projects/segnet/)

</comment></comment></comment></comment><comment><USER9> There has been a lot of cool image manipulation/transformation/synthesis work coming out over the past couple of years using NNs and such. I'm curious if any of these techniques have started worming their way into products? Will new effects in Photoshop (or whatever) get better over point releases as companies train up better and better NNs?

</comment><comment><USER10> It would be nice if this algorithm could be created in a more localised form, so that you could take a photo and apply the effect with different intensities as if you were using a brush.

Merely because sometimes it gets things wrong, and I think a normal human could correct things if they had more control over the process.

<comment><USER11> Can surely be done with the original neural style transfer algorithm. You'd just have to use a soft mask over the picture when calculating the content loss function.

Don't know if there's an analog way for fast style transfer.

</comment></comment><comment><USER12> Relevant Tensorflow/Brain blog post: [https://research.googleblog.com/2016/10/supercharging- style-...](https://research.googleblog.com/2016/10/supercharging-style- transfer.html)

</comment><comment><USER7> So you can transfer style from image A to image B. What I want to know is, can you use style transfer to "amplify" image A's style to, say, 500%?

<comment><USER13> presumably this could be done by enlarging image A image by 500% and getting and cropping a relevant 1/25th of the image?

</comment></comment><comment><USER14> Nice work. I'd be curious how this technique compares with other fast style transfer methods, if any exist.

</comment><comment><USER15> Results look pretty nice. Congrats!

</comment><comment><USER16> This is ridiculously cool.</comment>