Welcome Chris Lattner - <AUTHOR> https://www.tesla.com/blog/welcome-chris-lattner <comment><USER2> What's really interesting about this is not just that Lattner is brilliant and liked, but that is highlights just how critical _software correctness and reliability_ is to autonomous vehicles. Naively one might have expected some machine learning expert to take over the reins at Tesla. But fast-moving Silicon Valley needs a fundamental shift in quality standards when it comes to safety-critical software, and if you look closely, Lattner has been leading this charge at the language and compiler level.

His work has been distinguished by the melding of language _safety_ , _reliability_ and _clarity_ , that is, not merely having sophisticated constructs that help the guarantee correctness, but also making code simple, beautiful and easy to read. Ultimately writing safe code depends on the ability of the programmer to comprehend it, so creating a programming environment that's successful on all fronts is a foundational achievement.

A notable example: LLVM enabled ARC, a beautifully simple approach to memory management that removed much (not all) of the need for the developer to implement details in code, while providing high efficiency and, perhaps even more importantly, predictable performance (no garbage collection pauses). These are all essential for safety-critical realtime software.

<comment><USER3> ARC is a whole debate, but the one thing it is not is simple and I would argue its more error prone than a traditional GC. I've used it for most of my career and I have seen what sloppy/unaware coding can do to it.

Lattner is a well known expert on compilers. Having used Swift since its inception, I would call into question the reliability of the Swift LLVM compiler. In its current state (3.0.2) its absolutely terrible and does not back up the sentiment; "But fast-moving Silicon Valley needs a fundamental shift in quality standards when it comes to safety-critical software, and if you look closely, Lattner has been leading this charge at the language and compiler level".

<comment><USER4> The right comparison for ARC is with manual memory management -- not GC.

<comment><USER5> Depends on what your point is. Both ARC and GC are approaches to limit the complexity and difficulty of memory management. As such, I think it's very reasonable to compare them, because they're different approaches to the same underlying problem.

FWIW, as someone who was a Java programmer for over a decade before learning Objective C right after ARC came on the scene, I greatly prefer ARC over garbage collection. I find the things you have to remember to think about with both ARC and GC (e.g. circular references and unintentionally strongly reachable references) to be about the same cognitive load, but the deterministic, predictable behavior of ARC means you won't have to try to debug random GC hangs that only happen in prod under heavy load and the subsequent fiddling with a million GC options to get performance to be acceptable.

<comment><USER6> ARC is a GC implementation algorithm, you probably mean tracing GC algorithm.

"The Garbage Collection Handbook", chapter 5

[http://gchandbook.org/](http://gchandbook.org/)

<comment><USER7> I think it is time for you to buy more books.

<comment><USER6> I have a very good collection of CS books and papers about programming languages and compiler design...

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Apple has a car project. Autopilot must be one of its core features. But Apple would not create a VP-level position for Autopilot or any one feature for any of their products (even if they it called something else for secrecy/generalization reasons).

This move increases his compensation and clout. Post-Tesla, he'll only have VP or founder titles elsewhere, never anything lower-level (unless he gets his old job back). The change must be welcoming, too.

That Apple could not retain him speaks volumes of the company they've become. They're a conglomerate at the intersection of tech and fashion. Groundbreaking engineering is not always given its proper due (or compensation) because there's only so many seats at the table. They've become rigidly corporate and not particularly inspiring.

Good luck to him, and good job taking a chance. Working for someone with a vision other than "thin" must be a welcoming change.

<comment><USER9> > Working for someone with a vision other than "thin" must be a welcoming > change.

This is so spot on. I would kill for a thicker phone with a less vibrant display that would last 2x as long on a single charge. They're pushing stuff that the consumer doesn't want (thinner/less battery volume, no headphone jack) in order to make money. It reminds me a lot of the TV industry pushing 3D TV's. I don't know a single person who has ever watched, let alone regularly, any 3D content on their 3D TV. It's a technology that few wanted but was pushed to drive sales.

<comment><USER10> >They're pushing stuff that the consumer doesn't want (thinner/less battery volume, no headphone jack) in order to make money.

But how do you know that people don't want this? All the people who told me they were switching to Android because of the headphone jack ended up with iPhone 7s anyways and love them. And now it seems that Samsung's next phone is going to ditch the jack too. Not to mention the numbers aren't really in favor of suggesting this change is hugely unpopular.

<comment><USER9> Because the portable battery pack market size was estimated to be $15B in 2014[0], and is projected to grow to $17B by 2020[0]. That's saying nothing of the massive anecdotal evidence.

[0] [https://globenewswire.com/news- release/2016/04/04/825448/0/e...](https://globenewswire.com/news- release/2016/04/04/825448/0/en/Global-Power-Bank-Market-Poised-to-Surge-from- USD-15-09-Billion-in-2014-to-USD-17-2-Billion-by-2020-MarketResearchStore- Com.html)

<comment><USER11> I would argue that the battery pack market has little to do with whether or not folks think their phones are too thin. For instance, in day-to-day use I don't recall ever plugging a device into a battery pack. But I own two of them. Because once in a while I'm in the middle of, say, the Yukon or Alaska and haven't seen a power outlet in days, but perhaps would like a movie in my tent or to write a blog post. (I could charge from outlets on the motorcycle, but I've got enough crap plugged in the way it is.) So most of the time those packs sit on a shelf and are no reflection on whether or not I feel the iPhone battery is adequate for normal use.

Not everyone hangs in the same circles, but lots of (for example) motorcyclists buy these for general "plug in at camp" use. Run a small light, charge the GoPro, and some do use them to charge a phone. Hell, some of them use them as jump start batteries which is about as far away from anything related to cell phones as I can imagine in the portable power market.

In summary, quoting battery pack market size merely reflects the desire for folks to have portable electrical power, for whatever they feel they might need it for.

</comment></comment></comment></comment></comment><comment><USER12> Elon Musk is the new Steve Jobs.

He is an inspirational leader and talented people want to work with him. It appears it will be harder and harder to attract and keep talent at Apple with out a leader like Steve Jobs.

<comment><USER13> I think Elon Musk is what Steve Jobs wanted to be. Steve Jobs thought he was changing the world with the iPhone, and while it was new it wasn't world changing. What Elon Musk does is world changing.

<comment><USER14> Probably not a popular opinion, but I think Musk is overrated. The guy has a huge ego, just like Jobs had, and while he's putting it into a nice package, he's not the guy to come up with anything; electric cars, spacecraft etc.

Yes, he might change the world if/once he gets to Mars, but most of his stuff is a marketing tech demo.

Bell Labs changed the world. Tesla did not.

<comment><USER15> Have you read Vance's biography of Musk? He's definitely a flawed individual in many ways, but I don't think he's fundamentally an egotist. Certainly not to the sociopathic degree many business leaders are.

And I think your categorisation of his work as a tech demo is unfair, and uninformed. SpaceX have built rockets that are delivering satellites into orbit and supplies to the international space station, and have achieved reusability. They have played a significant part in building a private sector space industry. These are not tech demos, they are real things. Can you boast any such achievement in your own life?

Likewise, Tesla have built and sold electric cars that people want. They've created a global re-charging network to supply them. And they've been the first company to deploy significant automation into the automobile market on a large scale. These are not tech demos, any more than the gigafactory rising out o the Nevada desert is.

<comment><USER16> > Can you boast any such achievement in your own life?

That was an unnecessary remark; the commenter never claimed that he/she has achieved more than Musk.

<comment><USER15> The commenter claims Musk hasn't achieved anything at all, other than give some tech demos.

I'm perfectly entitled to ask what they've achieved themselves that puts them in a position to so casually demean what, by most people's standards, are quite considerable feats.

<comment><USER16> What OP has or has not achieved is irrelevant in my opinion. I think it's better form to just refute the criticism and leave OP out of it. But it's up to you of course.

<comment><USER17> In the meanwhile you've taken the entire conversation off course to serve as the politeness police.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Wow, that was unexpected. Great hire by Tesla. Interesting move from compiler development to driving AI, though I guess for the VP position, his experience in managing those teams is much more important.

<comment><USER19> > Wow, that was unexpected. Great poach by Tesla.

Tangential, but I really hate the term "poach" when referring to recruiting employees.

We shouldn't think of hiring people as "poaching", because employees are not property. You can't "poach" an employee because there's no ownership, and employees should be free to make their own decisions regarding their employment opportunities.

<comment><USER20> I hope you similarly dislike the term 'head-hunt' on the grounds that no-one's head is severed. 'Poach' is a useful metaphor that suggests that one company actively tried to lure an employee from another. It is a metaphor, it doesn't imply that the employee is a chattel. I think one can get a bit too precious about these things.

<comment><USER21> Language shapes perception shapes language, so it's absolutely worthwhile to be vigilant and critical about the idioms we endorse by adopting, especially for engineered phrases (e.g., "right to work").

<comment><USER20> I absolutely agree about the power of language to shape thought. But consider, whenever you've heard of company A poaching employee Y from company B, has it really subtly made you think of Y as a helpless object?

Whenever, I see it, I think of the two companies plying Y with enticements, with Y manipulating them until (s)he finally gets rich rewards with the new company.

<comment><USER22> It doesn't make me think of Y as a helpless object. But it does make me think of A as doing something wrong. I strongly object to the term because it implies that companies shouldn't compete for employees, which pushes our salaries down.

<comment><USER23> I think that's fair. After all, poach has literal meanings that apply to acts that are clearly wrong or illegal. In fact, if I look at the dictionary, you see words like trespass, steal, etc.

You do hear poach used colloquially or even somewhat jokingly when it's not intended to imply anything nefarious but the word does imply something underhanded.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Chris Lattner : Tesla :: Bjarne Stroustrup : Morgan Stanley [1]

[1] [http://www.morganstanley.com/profiles/bjarne-stroustrup- mana...](http://www.morganstanley.com/profiles/bjarne-stroustrup-managing- director-technology)

<comment><USER25> I'm surprised Stroustrup is working at Morgan Stanley.

<comment><USER6> Finance is one area where C++ still rules as full stack language.

In the typical enterprise, whose domain isn't selling software products, C++ tends to be mostly used as infrastructure language for .NET/Java/JS native libraries or interacting with their runtime APIs.

<comment><USER25> I work in the games industry and C++ is used for almost all system code (not tools) but this still feels like Shigeru Miyamoto taking a gig at a toy shop or Spielberg working at Universal Studios amusement park.

</comment></comment></comment></comment><comment><USER26> There's got to be more to this story. You don't spend years developing a language (Swift) as culmination of previous work (LLVM) and then abandon it for a job in a relatively new and different discipline. It doesn't make much sense to me.

<comment><USER24> My guess is that the Tesla Autopilot Software team is working on language/compiler abstractions to reduce their dependency on semiconductor hardware manufacturers, particularly NVIDIA [1]. NVIDIA hardware has been Tesla cars for many years, and they have a dominating position in both embedded and data center hardware for self-driving AI, and they are not afraid to partner with Tesla's competitors [2]. This whole ecosystem is based on CUDA toolchain, which is built atop LLVM [3]. And Chris Lattner is the original developer of LLVM.

[1] [https://www.nvidia.com/object/tesla-and- nvidia.html](https://www.nvidia.com/object/tesla-and-nvidia.html) [2] [https://www.nvidia.com/object/audi-and- nvidia.html](https://www.nvidia.com/object/audi-and-nvidia.html) [3] [http://docs.nvidia.com/cuda/nvvm-ir- spec/#axzz4VMqXIKfo](http://docs.nvidia.com/cuda/nvvm-ir-spec/#axzz4VMqXIKfo)

<comment><USER27> Considering the recent hire of Tesla's new Vice President of Autopilot _Hardware_ Engineering team was Jim Keller[0], the lead architect for AMD's K8 (Athlon 64) and a very influential force behind both Apple's A* chips and AMD's Zen (Ryzen), I think you're right that they're looking to rely less on NVIDIA.

My guess would be that Tesla's ambitions are set on controlling the whole stack. Something along the lines of a custom software toolchain for tailor- built silicon.

[0] [https://en.wikipedia.org/wiki/Jim_Keller_(engineer)](https://en.wikipedia.org/wiki/Jim_Keller_\(engineer\))

</comment></comment></comment><comment><USER28> Well, mystery solved.

Now, the new mystery: What does this mean for Apple's car project?

Yes, I realize he probably didn't have much (or anything) to do with it (whatever it really even is). There are going to be some batshit crazy theories though, and I can't wait to see how this affects Apple's stock price.

<comment><USER29> Car is clearly a bet-the-company level product for Apple. Tesla looking more and more like a bet-the-company acquisition.

<comment><USER30> How is Apple Car clearly a bet-the-company level product for Apple? It could just be Apple's normal secrecy, but as far as I know that project isn't generally well-known enough to be mentioned in the same pantheon as Google or Tesla.

</comment></comment></comment><comment><USER31> So I kinda what to be Chris Lattner when I grow up. :) LLVM, Swift, and Autopiloting cars is a hell of a run.

</comment><comment><USER32> I've met Chris and he is one of the nicest and humblest guy you can imagine. I'm not betting on him lasting in Tesla for more than 12 months. I think there will be a cultural conflict.

<comment><USER33> Could you explain why you think there will be a cultural conflict? Do Tesla engineers typically act in ways counter to being nice and humble?

<comment><USER34> It's more like the person above than the people below.

<comment><USER35> Chris did work under the leadership of Steve Jobs for 5 years.

<comment><USER36> He worked under Jobs as a direct report, like a VP role is?!

I had the impression he wasn't that high in the totem pole before Jobs died...

</comment></comment></comment></comment></comment><comment><USER37> This is very exciting for the future of Autopilot. I thought it was amazing already. I can't wait to see what they have in store.

</comment><comment><USER38> Being a Rust-lang fan, I would have loved to see him join the rust-lang group (which I am not a part of). I thought there might be a chance of this after I saw the post of him leaving Apple.

</comment><comment><USER39> Top two stories right now are about people leaving Apple... I don't think that bodes well for Apple.

</comment><comment><USER40> I always liked that Chris Lattner pubicly acknowledged Light Table as the inspiration for SWIFT Playgrounds: [http://www.nondot.org/sabre/](http://www.nondot.org/sabre/) Now, of course their new project is Eve

</comment><comment><USER41> Obviously, also related from the home page right now: [https://news.ycombinator.com/item?id=13366542](https://news.ycombinator.com/item?id=13366542)

</comment><comment><USER42> (wish) Maybe he's being hired to make enhancements to swift/llvm for numerically intensive computation? It would be awesome to see a pure-swift version of something like tensor-flow and all the compiler machinery to make it fast!

</comment><comment><USER43> What languages are used by Tesla for developing autopilot software?

</comment><comment><USER44> Way to go Chris! It has to be pretty awesome when the CEO tweets and blogs that you're joining the team. No pressure!

</comment><comment><USER45> Interesting twist : Apple buys Tesla and elevates Elon to the missing role of Steve Jobs. Wouldn't it be nice...

</comment><comment><USER46> It's quite interesting that there is no public comment from any other member of the Swift Core Team.

</comment><comment><USER47> Yesterday reading "Update on the Swift Project Lead" I was going to comment "He will go to Tesla".

Pure lucky, but my reasoning was that it is difficult for a compiler (etc) engineer like him to find a better job than the one he was doing at Apple: developers' tools, compiler infrastructure, a new programming language, Coding playground and so on.

</comment><comment><USER48> Argh who's in charge of Xcode and Swift at Apple now????

</comment><comment><USER49> Recording the conversation and filmed

</comment><comment><USER50> Wow! My faith in autopilot just increased.

</comment><comment><USER51> I doubt that this is a right decision.

<comment><USER52> Care to elaborate?

</comment></comment><comment><USER53> Congrats from us CS @ UIUC peeps!

</comment><comment><USER54> That was quick! Congrats.

</comment><comment><USER55> Did not see that coming...

</comment><comment><USER56> Maybe Tesla is the Apple Graveyard now.

[http://venturebeat.com/2015/10/08/elon-musk-if-you-dont- make...](http://venturebeat.com/2015/10/08/elon-musk-if-you-dont-make-it-at- tesla-you-go-work-at-apple/)

</comment><comment><USER57> Yeah, I would work for Tesla in a heartbeat (or SpaceX, or Solar City or any of the Mega Factories). Well it's back to Access programming for me ... :(

</comment><comment><USER58> Good for him.

This is awful though. People can't really think spending time on autopilot for rich people sports cars is more important than the LLVM compiler infrastructure.

Give me a break!

Even if tesla invents cool new batteries and changes the way we think about power all of that stuff still has to run on software, that the compiler infrastructure depends on...

<comment><USER59> Developing a system that can handle a complex, variable, real-world environment like driving surely has applications in other domains. LLVM and Swift are great contributions, and make development easier. That said, I don't see them changing software development as significantly as the possibilities opened up by systems like Tesla's autopilot.

</comment></comment><comment><USER60> I guess CarPlay or "Project Titan" just wasn't as interesting?

</comment><comment><USER61> I hate it when big companies buy other, smaller entities, and hope they don't interfere and change them too much.

But seriously, exciting news for Tesla.

<comment><USER18> What? What small entity are you referring to?

<comment><USER62> Some apple vendor, probably</comment></comment></comment>


NextGlass Knows If You'll Love a Beer or Wine by Scanning the Label - <AUTHOR> http://lifehacker.com/nextglass-knows-if-youll-love-a-beer-or-wine-by-scannin-1660912282

<comment><USER2> Interesting concept, guessing it's based on the same sort of user data as Amazon "users who liked X, also liked Y" system. Often thought that this would be a good fit for restaurants. i.e. I like Metallica, I'm 32, I like spicy food. Will I like this Korean restaurant?

<comment><USER3> Hi jamesfx4, I've got the answer you're looking for. The technology powering our recommendations does not use a collaborative filtering approach, such as Amazon's "users who liked X, also liked Y" solution. The recommendations are backed by artificial neural networks which have been tweaked to provide the best results at a personal level.

</comment></comment><comment><USER4> Added about two dozen ratings, checked my favorite IPA's and my least favorite ones. It nailed them with scores. Definitely using this over the weekend.

</comment><comment><USER3> This app just makes life easier - rely on your taste buds and personal experiences, rather than the anecdotal suggestions of "Joe Waiter".

</comment><comment><USER5> The augmented reality in this app is sickkkk!</comment>


Ask HN: Could you suggest how to market a proxy server? - <AUTHOR>

I'm working on a side project, I've set a proxy server and I'm trying to find the best way to generate profit from it. Subscriptio via paypal (not really sure about this) , find an exclusive Sponsor for advertising , sell part of the service as CDN (or Cache) or just sell the software? any feedback on the viability? would you pay to use it? <comment><USER2> I don't think it would be worth the effort to try monetizing. These things are a dime a dozen and they get blacklisted quickly. They can also be expensive to run because of the bandwidth usage. Also, some hosting providers don't allow proxies. My biggest problem with them is that I wouldn't want my server IP address showing up as accessing pedo sites or other types of illegal sites because of the users. Even worse is that some proxy server software caches sites by default (and can even get spidered.)

Good luck, but I think your efforts would best be spent elsewhere.

<comment><AUTHOR> thanks , you might be rigth on that, well I don't really need to worry about the bandwidth as it's hosted on GAE, the idea was to have a 0 effort side project set up

</comment></comment><comment><USER3> Who would use the proxy server and why?

<comment><AUTHOR> the target audience is the average internet user , and peoples in countries with Firewalls and censorship, and probably people that have concern about their Privacy. If you leave in china , iran , myamar...you obviously need one, if you leave in other western countries, you may need one for facebook, you tube , twitter, and to stay under the google radar</comment></comment>


The Rust module system is too confusing - <AUTHOR> https://withoutboats.github.io/blog/rust/2017/01/04/the-rust-module-system-is-too-confusing.html <comment> awinter-py In keeping w/ rust's philosophy of being 'c++ with marginally better tooling', I'm happy with the current setup. It's light years ahead of the perf overhead of #include + the pain of setting up linker args for libraries.

Are the keywords idiosyncratic? Maybe. Can a new user get it working in an hour and learn it in 2 days? Yes.

It would be cool if there were a polyglot build system that you could learn once and have the same expectations in every language. But there are downsides to this proposal (not least of which is the fact that when someone names a polyglot build tool, it's often NPM). I doubt the module system is the #1 or even the #5 thing people struggle with when learning rust.

<comment><USER2> > It's light years ahead of the perf overhead of #include + the pain of > setting up linker args for libraries.

Sadly not yet.

My VC++ builds are still faster, because they can enjoy using binary libraries across projects, something that cargo doesn't yet support.

Also VS 2015 and the new VS 2017 do have quite a few improvements regarding the linker, incremental builder and C++ modules support.

<comment><USER3> > My VC++ builds are still faster, because they can enjoy using binary > libraries across projects, something that cargo doesn't yet support.

This isn't anywhere near the top issue that I (or anyone else I know of) encounter with build performance in Rust. Dependent library builds are very parallelizable, so they tend to build quickly. Moreover, the build performance that matters in the day-to-day cycle is mostly _re_ build performance, and the binary artifacts are cached in this case.

We could spend time adding a global cache of build artifacts, I guess, but all the time we'd spend working on this wouldn't impact my development velocity much at all. Incremental compilation, on the other hand, would.

<comment><USER2> Every time a new Rust release comes out, I try to update all the VSCode relevant plugins.

It takes me more than one hour on a core duo with 8 GB + HDD, while I occasionally see the same crates being compiled and get to do something else.

I could probably buy a new computer, as this one isn't something that one can easily parallelize, but why should I when my C++ builds are actually fast enough?

I am just an opinated Rust dabbler, please take my complaint as contributing feedback about what I see as one possible show stopper for Windows developers to adopt Rust, vs our current .NET + C++ workflow, in terms of productivity.

Thanks for Rust.

</comment></comment></comment></comment><comment><USER4> IMHO there are many obscure things about Rust for newbies, and its syntax is also less readable than that of Ada. This gives me high confidence that it has a bright future.

I'm not being sarcastic here, Rust seems to be a great language (definitely on my list to learn), I'm really just observing. Looking at the success and history of programming languages it seems to me that many if not most professional programmers _want_ some obscurity, a desire that is often disguised as an apparent need for brevity which in reality plays no role with modern editors.

Maybe this makes sense, after all it's better to have a language that an incompetent boss or a marketing department cannot just pick up easily to 'roll their own solution'.

<comment><USER5> Which evidence do you see that points to obscurity or partial obscurity leading to success (or adoption, I can't tell which you're claiming)?

<comment><USER4> Not evidence, only subjective gut feelings, and I've had adoption in mind. But I'm hesitant to answer this question, because it will invariably lead to language flame-wars. Anyway, it seems to me that Algol68, Pascal, and Ada are less obscure than C and C++, but the latter are clearly more popular and have proven their worth over a long time.

At the same time, implicit-block type procedural languages like Visualbasic and Realbasic/Xojo _are_ popular, but they do not get much love from professional programmers, even though they are maybe the least obscure among all imperative mainstream languages. LISPs are also an interesting case, S-expressions are among the least complicated and easiest to grasp syntax and CommonLisp offers practically everything a programmer could ever wish for (including multiple dispatch) but it never became very popular.

But maybe I'm wrong. For example, advanced Lisp macrology is definitely obscure, so that should count in favor of Lisp being more popular according to me 'hypothesis'. Haskell syntax is fairly easy, but monads are certainly obscure, yet Haskell does not seem very popular. Likewise, Python does not seem to be very obscure, it certainly isn't syntax-wise, and it's still very popular.

So I don't know, perhaps my assessment was premature. It almost certainly was. ;-) I've just always had this impression that many programmers prefer a certain amount of special trickery and shortcuts over clarity. But perhaps it's the availability of libraries what counts most in the end.

<comment><USER6> C is FAR less obscure than most of the languages you mention, ignoring things newbies generally don't need to worry about like standards, compiler implementations, memory alignment, virtual memory, etc.

I was able to learn C reasonably well as a child precisely because of how straightforward it is. You can reserve a block of memory. You can free it. You can get the address of a value. You can get the value from an address. It works in an extremely straightforward way, unlike most languages. To a child, programming in C feels like the computer is doing exactly what it was told to do and nothing else. It _feels_ like you understand what is going on, even though your understanding is a very simplified model of what is actually going on.

Modern languages like C#, Javascript, Ruby... They are much harder to understand than C. The first time I saw a closure, I was completely dumbfounded. This doesn't make sense, a function is accessing a local variable of another function that has since been popped off the stack! What sorcery is this?? Even today things often confuse me, when I saw C# async/await for the first time I just couldn't understand how it can possibly work until I spent some time reading about it and I had been programming for decades by then including a decade in C#.

<comment><USER7> > This doesn't make sense, a function is accessing a local variable of another > function that has since been popped off the stack! What sorcery is this??

This is an issue with learning a _new_ language when you've already got your mind molded to a different one.

JS programmers have the exact opposite issue when learning C. Why can't we do this? Why must we worry about scopes for the stack? Wtf is the stack? I wonder what happens if I try to use this variabSEGMENTATION FAULT.

These languages generally are dealt with differently in one's mind, and trying to apply the mental model from language 1 to language 2 usually makes it feel harder than it really is.

I really could say the same about "it feels like the computer is doing exactly what you told it to do" about the other languages you listed. A crucial part is that you don't actually need to _understand_ what the computer is doing under the hood to use it, especially in a higher level language. C is more like "you were forced to talk to the computer in its own language", whereas with JS/C#/etc you don't have to know what addresses and memory are. You just tell the computer what tasks you want done, and how to model them, and it does them.

So I'm very skeptical that the other modern languages you listed are harder to understand than C. They're just _different_.

<comment><USER6> The only problem is, I've used C# and JS way more in my life than C, and C wasn't even my first language (QBASIC was).

So unless learning C somehow causes permanent disability I will have to respectfully disagree.

<comment><USER7> Right, my point is that it's highly subjective and depends on how you approach things. I know programmers who have learned C later and they've always found the whole having-to-deal-with-memory thing an unnecessary distraction that they spend way too much time wrangling with, even after spending lots of time with C. I'm one of these; I have done lots of C programming but find languages like Python to be easier to learn.

C sort of does cause a disability (not really a disability, this is a useful skill!) in the sense that now you're actually thinking about how a language feature works in the hardware, which is not something you necessarily _need_ to do for higher level languages. The moment you _ignore_ all this it's likely that the language will make sense again. Of course, like I said, this is all subjective. The solution to "I can't use async/await because I don't understand how they work" is basically that you pretend that they're magic, and try to figure out the internals on the side. You need not understand how things work under the hood to _use_ them, though it is an extremely valuable skill to know what C#/JS/etc end up doing at the lower level.

It's a sort of "ignorance is bliss" situation.

It varies from person-to-person though. It's not specific to programming either. When I was a physics student I personally would be easily able to define layers of abstraction in my mind and work within one layer, even if I didn't understand another -- you ignore how the other layer works and assume that it is magic (while simultaneously working to understand the other layer). One of my friends could not do this -- he _had_ to understand rigorously how the theorems worked all the way down. As you can imagine, this required a lot of effort. It meant that he always had a thorough understanding of the topic at hand, but often meant that he spent a lot more time to understand something and had no middle ground to choose.

For me, this has carried over to programming. If I'm dealing with a language like C or C++ I _will_ try to understand how everything works on the metal. When I first learned about C99 VLAs I spent an hour mucking with a debugger and inspecting the stack. When I realized that C++ had function-local initialized statics I spent many hours digging through C++ spec/implementations to understand how it worked ([http://manishearth.github.io/blog/2015/06/26/adventures- in-s...](http://manishearth.github.io/blog/2015/06/26/adventures-in-systems- programming-c-plus-plus-local-statics/)). These are things at the same abstraction level as C/++ which I must understand to be able to use them.

But when I'm dealing with languages like JS, I can operate perfectly fine without knowing how they work. Indeed, when I first learned about generators, I was able to use them for quite a while before I learned how they work. I still _want_ to know how things work (and generally dig into it), but it doesn't block me from proceeding if I don't.

This is not how everyone approaches languages. Like I said, it is subjective.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The Rust module system is a little bit weird. As far as I can tell, this is the result of two things:

\- 'use' statements are relative to the root of the crate, not the current module. To work around this, you can write 'use self::name' or 'use super::name' for relative imports. Annoying but no big deal.

\- If you import a symbol into module 'a', it doesn't also get added to 'a::b'. I don't know why I keep expecting this.

Once I learned these two things, Rust imports were easy.

I'm not sure I agree with withoutboats' proposals. His chnages would make several obvious things work the first time, but at the expense of taking a simple, easy to explain rule and replacing it with something implicit and mysterious.

The bigger Rust learning curve issue is making friends with the borrow checker. I like the borrow checker. It has my back, even when I'm trying to write fast code that would be recklessly abusive of pointers in C. But I can't deny that it took me a week or two to make friends with the borrow checker.

<comment><USER9> _' use' statements are relative to the root of the crate, not the current module. To work around this, you can write 'use self::name' or 'use super::name' for relative imports. Annoying but no big deal._

I'm writing an application. Inside main.rs I can write

      extern crate foo;
      use foo::Bar;

If I create a module and use the same crate, I need to write:

      extern crate foo;
      use self::foo::Bar;

This always surprises me and I never found anything explicit written on the Book. To me, it looks like a nice papercut to fix.

<comment><USER10> What if I really do want the 'foo' crate to be inside the sub-module? If you want it in the crate root, you should put it in the crate root.

<comment><USER9> Sorry, I don't really grasp your comment. Maybe I can clarify what I'm trying to do.

My typical use case is importing definitions, for example an error type or enum from the crate, let's say something from tokio_core.

I'd like to use this enum both in main and in my module; from my (limited) experience, you need to _extern crate_ tokio_core both in main and the module, then _use_ the definition. In this case the syntax is different for somewhat obscure reasons.

<comment><USER11> Hm, I'm still confused about what you're trying to do :-/ If you're trying to use something from tokio_core in your own crate, in neither place will `use self` do that, like you had in your first example... it would be `use tokio_core::foo::Bar`... and the `self` was the only difference between the binary and library, so I'm not sure what the paper cut is exactly.

<comment><USER9> Basically I start hacking on a project, then when finally something is working, I want to split it into a separate "something". Coming from the C++ world, I'd create a new cpp/h couple, maybe in its own subdir. I understand that the equivalent in Rust is creating a module.

I made a simple example with just two files: (In the meanwhile I realized that my first example was wrong :) [https://github.com/lucaotta/rust_modules](https://github.com/lucaotta/rust_modules)

Let's say that after my refactor, I've "moved" the crate import into the module since "logically" it belongs there. In this case the compilation fails if I don't use _self::_. But previously it was working in main.rs! And I have no idea why...

<comment><USER12> This is the "use starts at the crate root" thing. If you move the "extern crate", then the place it ends up in the module hierarchy is different, and so it breaks.

I always leave "extern crate" in the crate root; then it all Just Works.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> For me what's quite unnerving about `extern crate` is that the `extern` keyword has another function, that is to declare foreign functions [0]. `extern crate` on the other hand, is not an extension of `extern` but serves a completely different purpose.

0: [https://doc.rust-lang.org/book/ffi.html](https://doc.rust- lang.org/book/ffi.html)

<comment><USER14> I fail to see how the usage is different? They both reference things that are 'external' eg. already compiled etc...

<comment><USER13> I mean if anything the syntax should me more specialised as you go into sub- keywords, which makes sense in this industry (e.g. ISO 8601). The problem is that `extern` seems to have been taken from C++ and extern crate is almost tacked on (or that's the impression I get). Comparing with other languages, Rust looks to be the only instance where two keywords are required to simply require a module/library, which sticks out to me.

</comment></comment></comment><comment><USER15> The main issue with Rust's module system is that your own modules and crates live in the same namespace. So if you have a `mylib/image.rs` file and you want to use the image crate then you can't without either renaming your `image.rs` or you alias the crate on import.

I really wish your own modules would require some relative import and be scoped within `mylib`. Eg you would do `use mylib::image::MyImage` and `use image::OtherImage` instead of `extern crate image as image_crate; use image::MyImage; use image_crate::OtherImage`.

<comment><USER16> So Rust essentially has the same design issue that Python had before PEP 328?

<comment><USER7> Not exactly; Python had the problem where `import foo` had two different meanings and there was no way of working around it. Rust still understands that crates are different, and will let you do `extern crate foo as bar` to avoid conflicts.

</comment></comment></comment><comment><USER17> This was my experience, too. I had to keep checking other crates to see what was expected from me, and managed to finally understand through trial-and- error.

The problem with this is that I'm not likely to remember how modules work a few months after finishing a Rust project. I reckon core aspects of a language should be so simple that they don't need any work memorising them.

<comment><USER18> Mine too, or rather, for my first rust project I initially had all the code in main.rs and then I found it very difficult to split up the project into several source files. I think with some better documentation it wouldn't have been that hard.

<comment><USER19> I think it's the documentation. It took me a few tries to get everything I needed out of the Book to use my own modules, but then it was easy.

Although I still don't quite get how macro importing works. It feels like when you #[macro_use] on an extern crate you get all the macros implicitly everywhere without having to issue any use statements. This seems weird and I have yet to try to find an explanation of it. But I've got modules all over my Advent of Code solutions which use macros from nom without having any nom- related use statements.

<comment><USER12> Yeah, I hear you. I've always thought this, and honestly, I think the issue is that I've always found the module system _very_ intuitive, so it's been harder for me to connect with how people struggle to learn it.

[http://rust-lang.github.io/book/ch07-00-modules.html](http://rust- lang.github.io/book/ch07-00-modules.html) is the second edition of the book's chapter on it, I think it's much better.

> This seems weird

Yes, that is how it works. Macros aren't in a namespace. Yes, it's weird. It's an artifact of history; eventually, it will be fixed.

<comment><USER19> > [http://rust-lang.github.io/book/ch07-00-modules.html](http://rust- > lang.github.io/book/ch07-00-modules.html) is the second edition of the > book's chapter on it, I think it's much better.

It is better, yes, although I think it takes a while getting to the point in a few places.

Docs are something I'm interested in, so you might hear more from me through appropriate channels about this and that.

> Yes, that is how it works. Macros aren't in a namespace. Yes, it's weird. > It's an artifact of history; eventually, it will be fixed.

I'm glad that I both got it right and that it's not necessarily going to stay that way. I don't know how much macros are going to proliferate in the future, but I don't want to find myself with macro naming collisions. I can certainly imagine some of nom's causing issues with other crates, and having to define a new crate within my tree just to contain them would be irritating. I assume that would work as a workaround, anyway.

<comment><USER12> Great. Please don't hesitate to reach out and or file issues or whatever, I really want to make this stuff good.

Basically, today you define macros with macro_rules!. This shipped in Rust 1.0 because we did not have the ability to invent and implement a more proper macro system, and didn't want to hold the whole language up on one thing. In the future, you'll write macros with a "macro" keyword, and macro_rules! will be deprecated, and "macro" macros will support namespacing, etc.

<comment><USER19> Is that "Macros 2.0", or something beyond that?

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> > extern crate is like mod, but it declares an external crate dependency > instead of a submodule.

Naive question: What the hell's the difference? Is a crate not a module? IMO, there shouldn't be a difference.

(EDIT for clarity)

<comment> awinter-py crate is what gets released / distributed (i.e. a whole 'library', 'package', 'dependency', 'bundle'). Modules are single source files.

<comment><USER20> A binary is of course something different from a source file. But that's just a detail. The "user interface" should be the same for both, except maybe in the Makefile / Cargofile.

<comment> awinter-py crates aren't binaries -- they're source bundles.

<comment><USER20> Oops, my bad. That makes the distinction even more baffling to me.

<comment><USER21> To be clear, `extern crate foo` refers to the compilation artifact, not the source of foo.

</comment></comment></comment></comment></comment></comment><comment><USER22> Rust module system is similar to C#: mod is namespace, extern is assembly reference. The difference here is that there is no separate "project" file, so all references to inner module files need to be described in the parent file.

</comment><comment><USER23> FYI, /s/bare/bear

<comment> awinter-py Well, maybe. Or you're viewing the article through your western cultural bias and missed the author's primary intent.

<comment><USER23> "bare with me" can only make sense if the author is asking us to remove our clothing along with him. I don't think that was his intent.

Telling him about the typo was meant as a courtesy to him, because I appreciate his post and want to help strengthen it in this small way.

<comment> awinter-py you're assuming he wants to bare his body. maybe he wants to bare his soul.

</comment></comment></comment></comment><comment><USER24> I think it's possible to design a more intuitive system with less busywork:

1) For imports, the namespace hierarchy should have a one-to-one correspondence with the file and directory hierarchy.

2) For publishing code, instead of modules and Cargo, there would be one huge worldwide repository. You'd be able to freely import anything marked public, and the build system would cooperate with version control to make things work seamlessly.

Unfortunately it's probably too late for Rust to adopt such ideas. I wish some new language used them, though.

<comment><USER12> Given that crates.io has no namespaces, this is kinda sorta how this already works, I think. Or at least, I don't understand the distinction.

<comment><USER24> Well, you have two tools that can fetch stuff - git and cargo. In my preferred workflow there'd be only one tool. It would also work as a cloud filesystem, like p4fuse.

<comment><USER12> Cargo can use git, but it doesn't primarily. Crates are stored as tarballs on S3.

<comment><USER24> Right, I don't see why that's necessary. The whole world could be one big source control repository where each client keeps only their local changes. So e.g. if you want to make a local tweak to a third party library you're using, you 1) edit their file in your filesystem which is a transparent view into the world repo, 2) recompile your project.

<comment><USER12> That forces everyone to use git, which is not something we're interested in doing.

<comment><USER24> Agreed, it would force everyone to use the same VCS. I've lived in this kind of setup for years and I'm very happy with it, but point taken.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> This matters less once we get good IDE support. E.g. "mod" should be inserted automatically when you create a new submodule, "use" will be inserted as necessary if you try to use something that is not in scope.

The other part is to have a set of conventions. Do I put "extern crate" in the root module or in the submodule that uses it? How do I order my use statements? Do I import just the module or each item in it? When the community settles on a standard way, IDEs can follow it.

<comment><USER26> Unless an IDE is part of the standard somehow I strongly disagree that "IDEs make it better" is a good argument for preserving a language feature that is confusing. Not everyone uses an IDE, and for certain low level systems programming kinds of things (you know, the things Rust wants to target) sometimes an IDE isn't available or is cumbersome to use.

That said I am a bit confused at the confusion. Rust is better than C++ in this regard, in my opinion, even if the system is a tad slower to build still.

<comment><USER7> Agreed. This should be fixed in the docs, diagnostics, and maybe by changing the language in a way withoutboats recommends, but we should not rely on folks having an IDE.

</comment></comment></comment><comment><USER27> They should have looked at the good module system of OBJECT PASCAL (derived from MODULA). It is easy and allows all kinds of protections.

The main difference is that in this language a module always is one file, which consists of 2 parts. 1\. INTERFACE (public) 2\. IMPLEMENTATION (private) The way it is organized makes compilations also very fast.

USES only uses the public parts of the module. A LIBRARY is like crate in rust.

Sadly, this module system does not use private classes/types in public functions. But that would not be hard to add.

I have no idea what Rust tried to accomplish. Being used to Object pascal many other module systems seem primitive.

<comment><USER2> Actually that model came originally from USCD Pascal and was adopted by Apple for Object Pascal, but Borland did improved it quite a bit.

You forgot to mention, cyclic dependencies were allowed on implementation part.

Also later on, Delphi introduced packages, which are a set of units, with just some of them being public. Similar to the upcoming Java 9 package model.

</comment></comment><comment><USER28> All you need to do is make `use` paths look absolute with a leading `::`, followed be either name a crate or `create` for the current crate.</comment>


Mtgox stolen Bitcoins moving into MaidSafe's $6M IPO? - <AUTHOR> https://bitcointalk.org/index.php?topic=582731.0

<comment><USER2> Likely not true. Apparently the address linked to MtGox is actually likely from BitStamp. Can't rely on a bitchain.info label.</comment>


An actual Turing machine - <AUTHOR> http://blog.makezine.com/archive/2010/03/an_actual_turing_machine.html

<comment><USER2> I think this is a re-post, but nonetheless:

Has anyone else noticed how beautiful the simple font is that the machine creates for the 1s and 0s? Not that it's any surprise though... The whole thing reeks of amazing attention to detail and the end result looks fantastic!

<comment><USER3> _I think this is a re-post_

Indeed: <http://news.ycombinator.com/item?id=1255045>

<comment><USER4> Also <http://news.ycombinator.com/item?id=1221668>

</comment></comment></comment><comment><USER5> Now if someone could create a Non-Deterministic Turing Machine; that would be much cooler.

</comment><comment><USER6> holy sh*t. that's amazing.</comment>


Half of millennials and 75% of Gen-Zers have quit jobs for mental health reasons - <AUTHOR> https://www.cnbc.com/2019/10/08/millennials-gen-z-have-quit-jobs-due-to-mental-health-issues-survey.html <comment><USER2> Millennial here. I haven't had anything extreme like the article, but I'm currently on a break from my last job that I left as office drama got to be too much. It felt odd to do it, but I'm really glad I did. We have such a strong work culture, and its easy to fall into the grind and lose track of things. I'm not in a rush to start whatever is next, but that's also helped by having some savings and relatively frugally.

</comment><comment><USER3> ive done it myself in a way, being autistic means im somewhat sensitive to my environment, drastic shifts have seen me simply walk out at some places, its partly why im trying to shift to remote work, its much easier to be productive in an environment i control</comment>


'We are Wall Street - we are smarter and more vicious than [dinosaurs]' - <AUTHOR> http://ftalphaville.ft.com/blog/2010/04/30/217381/we-are-wall-street-we-are-smarter-and-more-vicious-than-dinosaurs/ <comment><USER2> Here's the real story from a former UBS trader from the UK Independent...

American excess: A Wall Street trader tells all

Fine wines, lobster lunches and million-dollar salaries – life as a Wall Street shark was thrilling at first. But amid the extravagance, Philipp Meyer was sickened by a moral deficit at the heart of America's financial system

"I'd been working for the bank for about five weeks when I woke up on the balcony of a ski resort in the Swiss Alps. It was midnight and I was drunk. One of my fellow management trainees was urinating onto the skylight of the lobby below us; another was hurling wine glasses into the courtyard.

Behind us, someone had stolen the hotel's shoe-polishing machine and carried it into the room; there were a line of drunken bankers waiting to use it. Half of them were dripping wet, having gone swimming in all their clothes and been too drunk to remember to take them off. It took several more weeks of this before the bank considered us properly trained...."The financial markets operate on the principle that, at our core, we're all basically shit: selfish, self-interested creatures. There's a whole branch of economics devoted to proving that if you help someone, say, run in front of a speeding train to push another person out of the way, you are actually acting out of self- interest, not altruism; that what most of us would consider humankind's cardinal virtues - love, honor, compassion - do not actually exist....The fact is, I became pretty good at making this argument myself. Until a roommate of mine, a guy named Mark Brewin, asked me: "So is that really what you want to be? A selfish animal?" "It's not like we have a choice," I said. "No," he said. "You always have a choice. It's just easier to pretend that you don't." Ouch. The strangest thing was, this thing I'd wanted for so long, this chance to become wealthy, was causing me more internal conflict than anything I'd ever done. I began writing a second novel, about a kid from the provinces who comes to Wall Street and is both drawn in and horrified by the culture of excess.

I understood it well. I put on 45 pounds in my first year at the bank, and, as you might guess, it was not from eating McDonalds. Occasionally I ate stuff like sushi, but mostly it was steak. We went to the good places like Sparks, Peter Luger's, and the Strip House. We tended to look down on chains like Morton's and Ruth's Chris-they were for car dealers or stock brokers, not traders. Regardless of where we ate, we ate in quantity. My standard strategy was to order half a dozen appetisers, plus a steak and lobster, plus a few desserts and much wine as I could drink, as long it was under a few hundred dollars a bottle. Followed by a digestif, typically a 30-year-old port. There's not any way to justify this except to say I was trying to catch up to my colleagues. We would treat those restaurants like Roman vomitoriums. And it wasn't the food so much as the wine. Being a junior employee, I couldn't really order bottles that cost more than a few hundred dollars, but the senior guys could get nicer stuff - Opus One, Chateau Latour. As long as we were out with a client, the bank paid. I remember being stunned the first time I saw a dinner bill for ten grand. But that was just the beginning.

What it boiled down to was austerity for everyone else and rampant consumption for ourselves. I never saw anyone literally set fire to money, but I did drink most of a bottle of 1983 Margaux ($2,000)...."

[http://www.independent.co.uk/news/world/americas/american- ex...](http://www.independent.co.uk/news/world/americas/american-excess-- a-wall-street-trader-tells-all-1674614.html)

</comment><comment><USER3> Translation: "We are more entitled and delusionally grandiose then you. Even though we don't produce anything and we don't solve any fundamental problems, the fact that we make money is a service to you. Paper profits equal prosperity, why can't you peons understand that?"

<comment><USER4> Yeah, you spend a million trading two pieces of paper, and you have two pieces of paper.

You spend five bucks making a hat, sell it for ten, and someone has a hat to shade their head. Or a hammer. Or a car. Or a pencil. Or a computer. Or a defibrillator. Or a softball. Or a picture frame.

</comment></comment><comment><USER5> _Do you really think that we are incapable of teaching 3rd graders and doing landscaping?_

I suspect so. They are tasks where goals are long-term and less quantifiable, and where the financial rewards are modest, so someone motivated by the adrenaline rush and high wages of Wall Street may well find it tough. Also, plants and small children are less easily impressed by all that swaggering braggadocio.

</comment><comment><USER6> A lesson: always think your quote through before speaking to journalists lest you accidentally pronounce yourself smarter than reptile with a walnut-sized brain.</comment>