Don't worry, by the time it is complete and mature, it will be complex and full of quirks too.
I'm not convinced that even Google has the resources to build something like that successfully. Except perhaps if they target a very specific use case.
Sponsoring Go introduction workshops for university undergrads, complete with Google-swag prizes and actual Google employees flown in from another country.
So, quite a lot if that experience is anything to go by.
I will say that my professor Axel Schreiner at RIT offered one of the two first Golang classes at a collegiate level back in... 2009? and he reached out to Google and said, "send us some Android phones so that we can develop Go on ARM"
They obliged with a full crate of first generation Motorola phones, each one preloaded with a 30 day free Verizon plan. Every person who took that class got one, and surely all of them made it back into the school's hands at the end of the quarter.
(I'm not sure how many people actually ever compiled and executed any go binaries on arm that year; we all learned Go, and it was a great class! But as far as the class, the phones were completely unnecessary. I think that they did make a more relevant class where the phones were able to be used again the year after that.)
> companies using the language with hopes of being acquired by them
This is beyond belief. What companies are using Go with the hopes of being acquired by Google? Does anyone honestly believe that Google's acquisitions teams know or care about programming languages? Any business that acquires companies on that basis is doomed to failure, as is any company that hopes to be acquired on that basis.
Go initially billed itself as a language for systems programming, but that claim was quickly retracted when it turned out that Go's creators had a different notion of systems programming than everyone else.
Not everyone. Just self-proclaimed authority who decided systems means operating system or some embedded code. Lots of companies I worked have title Systems Engineer or departments Systems engineering which has nothing to do with Operating systems but just some internal applications.
> Just self-proclaimed authority who decided systems means operating system or some embedded code
Systems does mean that. There are 2 broad categories of software you can write. One is software that provides a service to the user directly. That is an application. The other kind is software that provides a service to applications. That's systems software. Do you think there's something wrong with this notion? It's pretty well accepted over the decades:
Well by that definition Docker, Kubernetes, etcd and so on are systems software. But people here somehow explicitly make it to mean Computer Operating Systems.
This was all over with way before the 1.0 release even happened. There's no point in arguing over something that was addressed several years ago before Go even reached stability. Plus, trying to say that Go was a "failure" because of this is absurd. It was an issue of terminology, not technology. Given Kubernetes, Docker, etc you would have to be totally delusional to claim that Go has been a failure.
But Google as a whole isn't working on this. A lot of the projects at Google require collaboration across multiple teams, but I could see Fuschia being done by a fairly small and cohesive team.
I concur, macOS is a nightmare. I didn't think so before I had to write code for it, but I am currently writing code that runs on 5 OSs (Linux, Windows, macOS, Android and iOS) and macOS is by far the worst of all. In particular, everything related to filesystems was a nightmare, especially HFS+. Thankfully Apple is replacing it with the much more sane APFS.
I don't have much experience with them but I think VxWorks and QNX are good examples of simpler OSs. I do have some experience with Minix3 and it is certainly one. I guess the BSDs stand somewhere in the middle.
QNX always had practically oriented limitations of the general microkernel idea (eg. QNX native IPC/RPC is always synchronous) which allowed it to be essentially the only reasonably performant true micro kernel OS in the 90's. Unfortunately it seems that after QNX got repeatably bought by various entities the OS got various weird compatibility-with-who-knows-what hacks.
OS X has tons of weird quirks and compatibility mindfucks going back to their transition from OS 9 (all those .DS_Store and _filename files for "resource forks")
Backwards compatibility is #1 reason for increasing complexity. Apple is sometimes good in cutting away compatibility for the sake of cleaning up, but there are still weird issues poking now and then
hell the whole NSEverything is a compatibility thing with NextStep, which is long dead.
Apple doesn't really appeat to care about backward compatibility though. They break lots of things with every release of the OS. I would give that excuse to Microsoft, but not Apple.
Disagree. Microsoft keep making new APIs and depricating old ones. With Mac you got cocoa which goes back to 1989 and you can still use.
It might not be backwards compatible but from a developers perspective it is nice to be able to reuse old knowledge.
I think Apple has been much better than MS or Linux in continously modernizing and upgrading what they have. On windows and linux things tend to become dead ends as new flashy APIs appear.
Sure old win32 and motif apps might still run but nobody really develops using these APIs anymore.
On windows I first use win32, then MFC, then it was WinForms. Then all of that got depricated and we got WPF, silverlight and then I sort of lost track of what was going on. Meanwhile on Linux people used tcl/tk for GUIs early on. And there was motif, wxeindows. KDE and Gnome went through several full rewrites.
If we look at MacOS X as the modern version of NeXTSTEP the core technology has been remarkable stable.
Sure they have broken compatibility plenty of times but the principles and API are at their core the same.
I'm referencing the abilities of F500 companies to sustain OS development. OS X has roots in mach, and some BSD, but to call it either one is trivializing the amount of work that has gone on.
And NeXTStep itself is to large extent one big ugly hack that stems from experience of trying to build Unix on top of Mach. In fact it is not microkernel, but monolithic kernel running as one big Mach task, thus simply replacing user/kernel split with task/priviledged-task split (which to large extent is also true for OS X).
Correct. The Mach research project at Carnegie Mellon aimed to build a replacement kernel for BSD that supported distributed and parallel computing.
Next's VP of Software Engineering, Avie Tevanian, was one of the Mach project leads. Richard Rashid, who lead the Mach project ended up running Microsoft Research's worldwide operations.
Their work on a virtual memory subsystem got rolled back into BSD.
It did not. Mach is traditional microkernel which provides IPC mechanism, process isolation and (somewhat controversially) memory mapping primitives and not much else.
In late 80's/early 90's there were various projects that attemted to build unix on top of that as true micro kernel architecture with separate servers for each system service. Performance of such design was horrible and there are two things that resulted from that that are still somewhat relevant: running whole BSD/SysV kernel as Mach task, which today means OS X and Tru64 (at the time both systems had same origin as both are implementations of OSF Unix) and just ignoring the problem which is approach taken by GNU/Hurd.
The fuchsia part of android is linux? Anyway Google has a lot of people working for it. I don't think anyone would have expected NT to come from Microsoft at the time that it did.
You posted a video wherein the tester simply sequentially opens and closes a series of apps on a Samsung and Apple device seeing which will run through the sequence faster...and the Samsung was a bit slower.
In theory it makes me wonder if iphone's storage is slightly faster than the latest galaxy or if the process by which one loads an iphone app is slightly faster/more efficient than the one by which an android app is loaded or if the tiny selection of apps the reviewer picked are just better optimized for iphone. Nobody smoked anyone and nothing of note was learned by anyone. So much so that I wonder why you bothered to watch said link or paste it here.
I said half an OS because its built on technologies like linux and java not because its half assed even though it is.
>You posted a video wherein the tester simply sequentially opens and closes a series of apps on a Samsung and Apple device seeing which will run through the sequence faster...and the Samsung was a bit slower.
Certain apps were slower to load on the Samsung device. Additionally, the Samsung device encoded the 4K siginificantly video faster and took round 1 by 14 seconds and round 2 by 16 seconds.
>In theory it makes me wonder if iphone's storage is slightly faster than the latest galaxy or if the process by which one loads an iphone app is slightly faster/more efficient than the one by which an android app is loaded or if the tiny selection of apps the reviewer picked are just better optimized for iphone. Nobody smoked anyone and nothing of note was learned by anyone. So much so that I wonder why you bothered to watch said link or paste it here.
The iPhone X has faster storage and a significantly faster SoC. A 30 second win by the Samsung phone is what I could call getting smoked.
>I said half an OS because its built on technologies like linux and java not because its half assed even though it is.
And iOS is was a decedent of MacOS which itself is a decedent of NeXTSTEP. It also uses a language 11 years older than Java. So it sounds like iOS also meets your criteria of being "half assed".
I'm not convinced that even Google has the resources to build something like that successfully. Except perhaps if they target a very specific use case.