Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Welcome Chris Lattner

tesla.com

Post reply on HN
Print view View original

261–270 of 291 posts

Re: Welcome Chris Lattner

#261

Post by ksec »

mrkd wrote: post #32

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.

Inspirational? People keep saying this but I cant see it. He has inspirational "ideas", but a person? At least not behind a screen and when he is doing demo.

And for the iPhone Vs Electric Car comparison. Oh well may be i am old school, if BMW or other Car makers made a Electric Car ( assuming we have to choose a e-car ) i would choose them over Tesla any day. The interior quality of Tesla just dont compare well. The iPhone was truly a revolutionary product, in that many people tried smartphone before but they have ALL FAILED. This is speaking from someone who has used pretty much all smart phone prior to iPhone introduction.

If anything i say the difference is Elon Musk lack of taste.

Re: Welcome Chris Lattner

#262

Post by pjmlp »

fauigerzigerk wrote: post #229
devsquid wrote: post #214

Earlier quoted context omitted.

There are some web frameworks that are indevelopment. That does not mean Swift has gained any traction. Also having toyed around with one, the experience was not great. When writing a server, I would take Go over Swift anyday. It out preforms it, uses less memory, its simpiler, oh and it uses a "tradiontal" GC.

>uses less memory That is very much _not_ the case according to the testing I have done recently. Swift uses a lot less memory than Go unless the program uses only trivial amounts of memory in the first place. Using interfaces in Go data structures makes the difference even more pronounced. On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully…

> On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully written to avoid memory allocation.

Only if the said language doesn't allow for stack or static globals.

Quite a few languages do allow it.

Re: Welcome Chris Lattner

#263

Post by pjmlp »

autoreleasepool wrote: post #248
steeve wrote: post #246

Earlier quoted context omitted.

It looks like you haven't used C++ in a while. C++14 is a whole other world, and can be written with most (if not all) the safety guarantees you would expect from Swift or Rust. I had to use it for a project and was very surprised about this too...

You're lucky if you get to use C++14 in the real world. My last C++ job was maintaining a 2 millions of line of legacy MFC code.

Even there one can write quite safe C++ code with help of CArray, CString, CComPtr, ...

I used MFC like that in the late 90's/early 2000.

The problem are the team mates that write Win32/C like code, instead of MFC/C++ code.

Re: Welcome Chris Lattner

#264

Post by pjmlp »

ryanmarsh wrote: post #258
freyir wrote: post #116

Earlier quoted context omitted.

Swift, XCode, and Apple software in general don't scream reliability to me. No doubt Lattner is a smart guy, but I'd be more comfortable with a smart guy from NASA or somewhere similar with experience developing survival-critical software systems.

NASA has a culture of safety and redundancy ad nauseam because people are indoctrinated into it, not because their hires have an innate proclivity for it. It is not fair to judge Lattner's ability or commitment to safety based upon Xcode and Swift. One of these predates him, the other is the result of his decisions (no doubt) but also countless decisions of others, including those above his pay grade at Apple. Xcode…

Probably not, but the WWDC session about real time audio used Swift on their presentation.

http://devstreaming.apple.com/videos/wwdc/2016/507n0zrhzxdzm...

Re: Welcome Chris Lattner

#265

Post by pjmlp »

ajeet_dhaliwal wrote: post #93
n00b101 wrote: post #15

Chris Lattner : Tesla :: Bjarne Stroustrup : Morgan Stanley [1] [1] http://www.morganstanley.com/profiles/bjarne-stroustrup-mana...

I'm surprised Stroustrup is working at Morgan Stanley.

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.

Re: Welcome Chris Lattner

#266

Post by therockhead »

Matthias247 wrote: post #227
PinguTS wrote: post #220

Earlier quoted context omitted.

If you want to talk about safety and reliability in automotive, then we talk about Autosar[1]. One of the concepts is to prevent the use of any dynamic behavior, which means you don't need any garbage collection at all. Because garbage collection is not predictable. It can be good and bad, but even a good one is not predictable. Embedded design and development is completely different to classical IT. For IT that soun…

True, AUTOSAR is the current standard for embedded automotive systems. Regarding safety I heard different things about it, some parties would only use it for up to ASIL A, others to C, others also to D. My personal opinion is that AUTOSAR (and even it's basics like C as a programming language and the OSEK OS) are not the best solutions that we should come up with for all the safety critical tasks in the autonomous dr…

I often wonder would Erlang be a good language for embedded automotive systems. It's seems to have the right traits - no GC pauses, built for reliability etc.

Re: Welcome Chris Lattner

#267

Post by fauigerzigerk »

pjmlp wrote: post #262
fauigerzigerk wrote: post #229

Earlier quoted context omitted.

>uses less memory That is very much _not_ the case according to the testing I have done recently. Swift uses a lot less memory than Go unless the program uses only trivial amounts of memory in the first place. Using interfaces in Go data structures makes the difference even more pronounced. On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully…

> On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully written to avoid memory allocation. Only if the said language doesn't allow for stack or static globals. Quite a few languages do allow it.

Doesn't that effectively amount to manual memory management? What particular languages are you referring to?

Re: Welcome Chris Lattner

#268

Post by abalone »

pjmlp wrote: post #190
abalone wrote: post #70

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 loo…

> 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. A GC algorithm known since the early days of Lisp GC research and used in…

By PR you mean public relations? Note, I did not claim that Lattner invented the general idea. I'd suggest that dismissing the careful selection, refinement, integration and popularization of design elements as "PR" underestimates how great products are made. It's like saying Tesla's doing nothing new or the Macintosh was invented by Xerox.

Re: Welcome Chris Lattner

#269

Post by pjmlp »

fauigerzigerk wrote: post #267
pjmlp wrote: post #262

Earlier quoted context omitted.

> On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully written to avoid memory allocation. Only if the said language doesn't allow for stack or static globals. Quite a few languages do allow it.

Doesn't that effectively amount to manual memory management? What particular languages are you referring to?

> Doesn't that effectively amount to manual memory management?

Not really, example in Active Oberon:

    TYPE
      point = RECORD x, y : INTEGER; END;

    VAR
      staticPoint : point; (* On the stack or global *)
      gcPoint     : POINTER TO point; (* GC pointer *)
      noGCPoint   : POINTER(UNTRACED) TO point; (* pointer not traced by the GC *)
> What particular languages are you referring to?

Mesa/Cedar, Oberon, Oberon-2, Active Oberon, Component Pascal, Modula-2+, Modula-3, D, Oberon-07, Eiffel, BETA.

There are probably a few other ones.

Re: Welcome Chris Lattner

#270

Post by abalone »

adevine wrote: post #174
solidsnack9000 wrote: post #170

Earlier quoted context omitted.

The right comparison for ARC is with manual memory management -- not GC.

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 f…

I'm actually excited about server-side Swift for exactly this reason. It's early days though.
Post reply on HN