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

Google’s not-so-secret new OS

techspecs.blog

Post reply on HN
Print view View original

511–520 of 561 posts

Re: Google’s not-so-secret new OS

#511

Post by Touche »

jgon wrote: post #506
Touche wrote: post #495

Earlier quoted context omitted.

I'd love to see data that concludes that iOS has better battery life than Android. I haven't seen such data and doubt the truth of that statement.

iOS devices routinely ship with batteries ~60% the size of flagship android devices and have competitive amount of battery life. If apple chose to ship an iphone with a 3000mah battery like what can be found in Android flagships it would absolutely crush the competition in terms of battery life.

Maybe it would, maybe it wouldn't. Without research into this it's all just conjecture.

Re: Google’s not-so-secret new OS

#512

Post by nathanasmith »

wmccullough wrote: post #11
pier25 wrote: post #9

We definitely need a universal OS for all our devices and I really believe Google is in a great position to get us there. It would really surprise me if Apple got there first. Tim lacks vision and will keep on milking iOS even if the iPad Pro is a failure as a laptop replacement. Windows is still king in the desktop space, at least as far a user base goes, but it's terrible on tablets and phones. MS has all the tech…

Terrible on tablets and phone? Phones I can agree with but the surface line is getting to be really solid. I've been an iPad guy for years and my next tablet will be a surface.

I had a Surface Pro 4 for a while and it is really great for the first few weeks but when the honeymoon period is over, the warts start to show. Slowly but surely I gravitated back to my iPad and laptop. The day the SP4 went back to Costco was when I realized it had been collecting dust for over a week.

Re: Google’s not-so-secret new OS

#513

Post by munificent »

quanticle wrote: post #280
ocdtrekkie wrote: post #233

Earlier quoted context omitted.

I suspect this is true, in that Fuchsia is simply a potential replacement for both... not a "merge". But bear in mind, marketing voices like Hiroshi's job is to promote and sell people on the existing product... right up until the day they decide to officially announce something else. So, even if they were presently 100% focused on merging the two OSes, Hiroshi's job would be to convince you they aren't as not to ris…

But bear in mind, marketing voices like Hiroshi's job is to promote and sell people on the existing product... right up until the day they decide to officially announce something else. Absolutely. I'm reminded of how Steve Jobs claimed that Apple was absolutely, 100% committed to PPC... right up until he announced the first Intel Macs at Macworld in 2006. And Apple, at that point, didn't even have OEM partners to wor…

Yup. The Osborne effect[1] is widely known now, so most companies are very careful not to telegraph a future change that may impact current sales.

[1]: https://en.wikipedia.org/wiki/Osborne_effect

Re: Google’s not-so-secret new OS

#514

Post by munificent »

throwawaydbfif wrote: post #131
cwp wrote: post #79

Earlier quoted context omitted.

Give me a break. It's just as accurate to say "Dart is an open standard, Javascript is owned by Mozilla". There may be valid technical, pragmatic or moral reasons to prefer Javascript, but this is just FUD. (See http://www.ecma-international.org/publications/standards/Ecm... )

Really? Google's once rosy history with open source project isn't looking too friendly these days. And yeah ECMA is a totally open standard with committee members from all sorts of companies and backgrounds. Dart is not. I don't care if JS is slightly worse, as least I know that for now and the foreseeable future I won't be paying a google tax to use it. After the open source community "stole" mapreduce and hbase goo…

> And yeah ECMA is a totally open standard with committee members from all sorts of companies and backgrounds. Dart is not.

Dart is an ECMA standard: https://www.ecma-international.org/publications/standards/Ec...

Re: Google’s not-so-secret new OS

#515

Post by munificent »

logicchains wrote: post #324
isoos wrote: post #231

Earlier quoted context omitted.

Looks like alternative facts have reached the tech world too? You can take as hard look at Google as you would like, but choosing Microsoft over Google (one for-profit company over another), while not caring how the technology, the licensing or the workflow compares is a bit hypocrite. (e.g.they are both open, and they both have rules of commits). I'm wondering, why do you need a throwaway for such heavily invested F…

>I think it is way ahead of the JS/TS stack in many regards. In what ways do you consider it ahead of Typescript? Personally as someone who's particularly fond of static type systems (Haskell and the like), Typescript's type system seems way more advanced and powerful than Dart's (union and intersection types, in particular, and non-nullable types). Map types (introduced in Typescript 2.1) also seem pretty interestin…

TypeScript has some really cool type system features. Union and intersection types are fun and really handy when interacting with dynamically typed code. (If you go back through history, you'll find almost every language with union types also has a mixture of static and dynamic typing. See: Pike, Typed Racket, etc.)

Self types (the "this" in the return type) is handy.

I can see us adding some of those to Dart eventually.

Non-nullable types are great, which I've said for a very long time[1]. We are finally working to try to add them into Dart[2]. It's early still, but it looks really promising so far. It kills me that I've been saying we should do them for Dart since before TypeScript even existed and still they beat us to the punch, but hopefully we can at least catch up.

The main difference between TypeScript and Dart's type systems (and by the latter I mean strong mode[3], not the original optional type system) is that Dart's type system is actually sound.

This means a Dart compiler using strong mode can safely rely on the types being correct when it comes to dead code elimination, optimization, etc. That is not the case with TypeScript and at this point will likely never be. There is too much extant TypeScript code and JS interop is too important for TypeScript to take the jump all the way to soundness. They gain a lot of ease of adoption from soundness, but they give up some stuff too.

In addition to the above, it means they'll have a hard time hanging new language features on top of static types because the types can be wrong. With Dart, we have the ability to eventually support features like extension methods, conversions, etc. and other things which all require the types to be present and correct.

[1]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...

[2]: https://github.com/dart-lang/sdk/pull/28619

[3]: https://github.com/dart-archive/dev_compiler/blob/master/STR...

Re: Google’s not-so-secret new OS

#516

Post by munificent »

throwawaydbfif wrote: post #343
isoos wrote: post #320

Earlier quoted context omitted.

Your worries about being locked in may have been valid 2-3 years ago (1), but things have changed a lot since: Dart has an ongoing project (Dart Developer Compiler) which has a goal, among others, to produce readable, idiomatic EcmaScript 6. That is as close to your TypeScript fallback as it can get. (2) Somebody also demonstrated Dart to LLVM compilation is possible. The language has a decent library for parsing the…

I didn't know of the developer compiler, when that reaches production I won't have any real citicism of Dart. For now Js fallback is the only realistic option for running code on the web. Even if we get native typescript or dart support tomorrow we will still need to put up with JavaScript for like 7-10 years. For this reason a readable JS fallback seems like a vital feature to me at least. It's depressing but realit…

> when that reaches production I won't have any real citicism of Dart.

It's still got bugs, of course, but we have internal customers working on real projects using it on a daily basis.

I agree totally that picking a language is a huge commitment and you want to do that with an organization (company, standards committee, group of open source hackers, whatever) that you trust.

Google is a huge company and has done lots of good and bad things, so it's easy to find enough evidence to support assertions that we should or shouldn't be trusted based on whichever view you want to demonstrate.

One way I look at it is that instead of answering the absolute question "Can I trust Google to shepherd the language well?", consider the relative question "Can I trust it to shepherd the language as well or better than the maintainers of other languages I might choose?"

Assuming you've got some code to write, you have to pick some language, so the relative question is probably the pertinent one. I hope that we on the Dart team are a trustworthy pick, but different reasonable people have different comfort zones.

> Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's?

All of our stuff is open source[1], including all of our compilers and the libraries they are built on. Most of it isn't explicitly pluggable because plug-in APIs are hard and Dart in particular doesn't do dynamic loading well.

But it's all hackable, and much of it is reusable. In particular, the static analysis package[2] that we use in our IDEs also exposes a set of libraries for scanning, parsing, analyzing, etc. that you can use.

[1]: https://github.com/dart-lang/sdk [2]: https://github.com/dart-lang/sdk/tree/master/pkg/analyzer

Re: Google’s not-so-secret new OS

#517

Post by munificent »

throwawaydbfif wrote: post #212
innocentoldguy wrote: post #200

Earlier quoted context omitted.

JavaScript sucks because it has a weak standard library, ugly syntax, and its monopoly in web development has the industry stuck in a state of mediocrity, in my opinion. I have a VERY hard time believing that the apex of engineering intelligence and ingenuity is found in JavaScript. Also, as much as I love Elm, for instance, languages that transpile to JavaScript are just lipstick on a pig, and do little to solve the…

I agree with you that JavaScript sucks balls in far more ways than is reasonable for such a widely used language. The design is seriously shit when compared directly to really any popular language, even PHP. I disagree with transpilers not being a reasonable answer. Eventually JavaScript will be okay to work with, some day. Until then, transpilers offer nearly unlimited freedom in redesigning the bad parts of the lan…

> since it offers many potential performance optimizations on top of what js is capable of.

It doesn't, unfortunately. TypeScript's type system is unsound, so the VM can rely on types for optimization.

Re: Google’s not-so-secret new OS

#518

Post by kiallmacinnes »

drewg123 wrote: post #441
pjc50 wrote: post #310

Earlier quoted context omitted.

There's one design decision in Linux that makes this slightly harder than it needs to be in this situation: Linux's lack of a driver ABI. At the moment, phones include all sorts of custom drivers for very specific versions of the hardware. The OEMs ought to send these upstream, but don't want to. You can't build your own kernel and upgrade without breaking all the binary-only drivers. Android falls between two stools…

"Linux's lack of a driver ABI." RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility. The RHEL kA…

So, taking a tangent here... If you fork, and that includes backporting security fixes upstream won't, you need a new version.

Obviously, you can't just take .28, apply a fix, and call it .29... But you have to do something.. ideally something that indicates binary ABI compat with upstream .28, (so software vendors can just decide, your .28, you get .28 features.

Maybe something like SemVer needs a model for versioning of forks? (I'm not a SemVer fan or hater, it's just the best known effort in this area..)

Re: Google’s not-so-secret new OS

#519

Post by skj »

macintux wrote: post #475
skj wrote: post #469

Earlier quoted context omitted.

I think a single platform for all our devices: mobile, tablet, desktop, etc, is a mistake. The word platform means more than just the OS and includes the entire L&F/experience with the UI. I think a single OS for them all is fine. Consider gnome+linux vs android+linux. They're both linux, and they're not the same platform.

By that definition, I could argue Apple got there years ago by using the same core kernel and frameworks for OS X and iOS. That's clearly not what the original poster was arguing.

Well, it's the definition. I also believe that OS X and iOS have diverged somewhat in the kernal/framework space.

Re: Google’s not-so-secret new OS

#520

Post by michaelmrose »

bitL wrote: post #345
simonh wrote: post #332

Earlier quoted context omitted.

I read a story years ago about a guy who changed careers from being a Programmer when Visual Basic was launched. He reasoned that anyone would be able to create applications so it wouldn't be a viable career anymore. > You can use ML like deep learning variations to learn association between your wishes and corresponding code blocks I suggest you read up on ML.

I am currently working on deep learning as well as generating custom programming languages. Maybe you could consider updating yourself? ;-)

Programming touches both comprehension of the code and the world it interacts with. Any program which can write programs based on comprehending natural language ought to be able to rewrite itself. Can you please explain how what you are describing is distinct from AGI?
Post reply on HN