Live data from Hacker News

Welcome Chris Lattner

tesla.com

271–280 of 291 posts

Re: Welcome Chris Lattner

#271
post #207

Earlier quoted context omitted.

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

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

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...

Re: Welcome Chris Lattner

#272
post #269

Earlier quoted context omitted.

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…

>noGCPoint : POINTER(UNTRACED) TO point;

That's fine for one point. How about N points where N varies at runtime?

If I allocate memory dynamically outside the GC's remit, I'm going to have to release that memory somehow.

Re: Welcome Chris Lattner

#273
post #265

Earlier quoted context omitted.

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.

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.

Re: Welcome Chris Lattner

#274
post #207

Earlier quoted context omitted.

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

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...

Power banks are convenient and I'd rather have a power bank and a thin phone than a really thick phone and no power bank. Thin when you want it, bulky when you don't.

The 3.5mm headphone market is also massive but people don't want 3.5mm headphones, they just want headphones. You're confusing demand for intrinsic virtue.

Re: Welcome Chris Lattner

#275
post #269

Earlier quoted context omitted.

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

>noGCPoint : POINTER(UNTRACED) TO point; That's fine for one point. How about N points where N varies at runtime? If I allocate memory dynamically outside the GC's remit, I'm going to have to release that memory somehow.

Depends on the specifics of the language.

On Active Oberon's case, those pointers are still safe. They can only point to valid memory regions, think of them as weak pointers that can also point to data on the stack or global memory.

This in safe code.

If the package imports SYSTEM, it becomes an unsafe package, and then just like e.g. Rust's unsafe, the rules are bended a bit and usage with SYSTEM.NEW() SYSTEM.DISPOSE() is allowed.

Just like any safe systems programming language, it is up to the programmer to ensure this pointer doesn't escape the unsafe package.

Re: Welcome Chris Lattner

#276
post #207

Earlier quoted context omitted.

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

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...

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.

Re: Welcome Chris Lattner

#277
post #275

Earlier quoted context omitted.

>noGCPoint : POINTER(UNTRACED) TO point; That's fine for one point. How about N points where N varies at runtime? If I allocate memory dynamically outside the GC's remit, I'm going to have to release that memory somehow.

Depends on the specifics of the language. On Active Oberon's case, those pointers are still safe. They can only point to valid memory regions, think of them as weak pointers that can also point to data on the stack or global memory. This in safe code. If the package imports SYSTEM, it becomes an unsafe package, and then just like e.g. Rust's unsafe, the rules are bended a bit and usage with SYSTEM.NEW() SYSTEM.DISPOS…

I still don't get how you can say that this memory is not under the GC's control but it's "not really" manual memory management either. Is it reference counting then? How does that memory get released?

Re: Welcome Chris Lattner

#278
post #275

Earlier quoted context omitted.

Depends on the specifics of the language. On Active Oberon's case, those pointers are still safe. They can only point to valid memory regions, think of them as weak pointers that can also point to data on the stack or global memory. This in safe code. If the package imports SYSTEM, it becomes an unsafe package, and then just like e.g. Rust's unsafe, the rules are bended a bit and usage with SYSTEM.NEW() SYSTEM.DISPOS…

I still don't get how you can say that this memory is not under the GC's control but it's "not really" manual memory management either. Is it reference counting then? How does that memory get released?

It doesn't get released, unless you are doing manual memory management inside an unsafe package.

In a safe package it can only point to existing data, there isn't anything to release.

If the pointee is something that lives on the heap, it is similar to weak references. Points to GC data, but doesn't count as yet another GC root.

If the pointee is on the stack or global memory (data segment in C), then there is also nothing to release. Global memory only goes away when program dies, stack gets released on return. Memory that was allocated by the compiler due to VAR declarations, it is static.

Usually the idea is that you use untraced pointer to navigate statically allocated data structures, they are not to be exposed across modules.

Re: Welcome Chris Lattner

#279
post #171
post #127

Earlier quoted context omitted.

Pretty much none of Apple's current software is written in Swift though, from what I can tell.

Actually a fair bit is in Sierra. Apple decided apparently not to invest resources in targeting 32-bit platform support, so they have had to hold off shipping software relying on it until the platforms drop 32-bit support. Sierra did that last year, and I'd put $5 on iOS 11 doing that as well.

Sierra did not drop support for 32-bit applications. Pretty sure Microsoft Office just released a 64-bit version of their product a month or two ago. Good luck dropping 32-bit on the Mac and godspeed.
Post reply on HN