Go was created by Rob Pike and Ken Thompson to solve real problems Google was having with its massive C++ code base.
The domain they work in is huge scalability, server backends.
You are right, it is a boring language, and that's just how they like it because Google is trying to solve their very specific problems without creating nightmares of new ones.
Go is designed to address many of the scale complexity problems they faced with C++, in both human terms and machine terms. In human terms, C++ is a very complex language. In machine terms, the joke was that Go was invented while waiting for a C++ compile job. (Google's build times are frequently measured in hours.)
Go also addressed scaling problems for other languages. Java, C#, Python, Ruby, NodeJS, etc. consume a lot more resources to spin up their virtual machines. At Google scale, this adds up to needing a lot more hardware, and a lot more power to run the data center, and a lot more cooling needed.
And since most of Google's server requests have no dependencies with each other, they could build directly into the language mechanisms to support concurrency. (And they make it a point to distinguish between concurrency and parallelism in computer science terms.)
In the end, Go is a fairly simple language that people from scripting languages can pick up reasonably, while getting pretty decent native performance, and also getting concurrency features which are optimized for their domain.
Be aware that coroutines are not the same as threads. They are much lighter and you can have a lot more.
Also remember, concurrency is not the same as parallelism. The Go literature tries very hard to remind people of this computer science fundamental.
Go's primary domain is server backends. The workload is basically handling many thousands of requests per second that are completely independent of each other (embarrassingly parallel). You are absolutely correct that you don't want zillions of threads. Coroutines can be very effective here.
> Go billed itself as a systems programming language.
They backed off on this claim a while ago. It's popularity and main use case has been as a server backend language.
Because the language compiles to native code and is closer to the hardware, everybody lumped it in with "systems" programming languages.
As a server language, it meets its objectives well. The native aspects give it an advantage over languages like Ruby (Rails), JavaScript (NodeJS), Python with smaller memory footprints and ability to take advantage of multiple cores/processors.
The built in design for coroutines makes it easier to do concurrency easier than other native languages which only have threads, and coroutines are much lighter weight than threads. (Please note, concurrency is not the same as parallelism. The Go literature tries very hard to remind people of this computer science fundamental.)
Dude, don't get me started on first world problems. We're about to get either Hillary Clinton or Donald Trump as President. Cut me some slack.
"Desperately needed" in the sense that Metroid 2 is the hardest game to play *legally* now and the longest in tooth technology-wise. Most people aren't going to casually go to eBay and pick up a working GameBoy.
The original Metroid got remade as Zero Mission. Super Metroid can be played on Wii U Virtual Console, and at least that game has color. Metroid 2 can be played on 3DS, but the low resolution monochrome graphics are a hard sell in today's modern world of retina displays and GPU in your pocket that are more powerful than the supercomputers of that era.
We just went through this a week and a half ago with the fan Metroid 2 remake AM2R. Nintendo shut that down in 2 days. http://www.ign.com/articles/20...
It is a brilliant remake, which was desperately needed because Nintendo seems to constantly ignore Metroid. If Nintendo shuts down something like this, Pokemon doesn't have a prayer.
"But they have avoided the steep cost of rebuilding their reservations systems from the ground up,"
As somebody who had family affected by the Southwest outage 3 weeks ago, the reservation system was one of systems that remained up the longest. Southwest still could happily take your money even if nobody was going anywhere. (I suspect they manually took it down later it became clear the day was lost.)
Focusing on the reservation system sounds like a contractor lobbying to sell something...
Yes, like memcpy, except memmove (there should be an 'e' at the end for the C89 ANSI compliant name) allows memory to overlap. memcpy can be optimized to be faster since it doesn't have this constraint.
I'm about to start a project for fun using C and I was wondering what the best version would be C89? C99? C11? It seems that nothing in C99/C11 is all that compelling and I'd like to have solid multi-threaded support (POSIX threads). Any reason to use anything other than C89 features?
C99 has some really convenient features: - inline functions (note: these work slightly differently than C++ because they fix the problem of guaranteeing symbol generation for linkage concerns) - long long - _Bool and - (uint32_t, int8_t,...) -// comments - not requiring all variables to be declared at the top of the scope - local scoping for for-loop variables: for(size_t i=0; ival; i++) - variadic macros - snprintf - designated initializers - restrict (for the hardcore performance sensitive folks)
Microsoft dragging its feet on updating Visual Studio's C compliance to C99 and beyond has been the major reason for people sticking to C89. But the rest of the world has moved on. Microsoft finally started waking up and realized not being able to compile massively cross-platform open source projects like Git was a problem. Also, Microsoft's iOS compatibility bridge requires a good C compiler as Obj-C is a superset of C and Obj-C devs take for granted a lot of the above listed features. Visual Studio 2015 has *finally* started adding a bunch of the more popular C99 features so it can finally compile Git, though it is still missing things, with __STDC_VERSION__ still not up to date as a telltale sign.
Sony uses FreeBSD now. And after stuff like this, it probably makes them glad they have nothing more to do with Linux or allowing anybody to do stuff with their own hardware.
Though what's interesting about the Return of the Jedi holographic Death Star briefing is also the point my prof was making. Despite the cool hologram, the rendered graphics in the hologram get intentionally dumbed down. You can see color filled translucent polygons and smooth curves (making the green and red colors of the moon and Death Star) in some parts showing the technology was actually there, but the major focus parts of the briefing are the Death Star and the tunnels to the reactor which are all wireframes, and the forest moon shield visualization is done with individual pixels.
My graphics prof told us that the people hired to do the graphics for Star Wars were instructed to make it look more primitive. The technology already existed to do filled colored polygons and deal with pop-up and so forth. But when Lucas or whoever saw their first pass, they said it looked too good. So for example, in the trench run briefing, you see that they went to green wireframes with massive pop-up problems where big chunks just suddenly appear.
This isn't going to affect anything. DMCA abusers still have financial incentives to continue abusing (by automatically diverting ad money to themselves on claimed videos) and have no financial disincentives to stop doing this. If it gets to the rare point where Google does step in, they can just release the video in question while simultaneously continue abusing a thousand other videos.
I disagree about Steam Machines. There are real problems I have that I hope Steam Machines solves. I want a fully powered, gaming PC that just works, but doesn’t lock me down in what I can do with it.
- I want the benefits of mass production commodities and be able to buy a good PC gaming machine off-the-shelf for a lower price. - I’m tired of spending so much time building my own custom PC and doing OS installations. - I’m sick of Microsoft charging me many times more than everybody else for a Windows license because I didn’t buy a pre-configured machine from an OEM. - I’m sick of Windows blue screening and corrupting my EFI boot partitions so my dual boots won’t work. - I’m sick of Windows nagging me about turning on Secure Boot. I don’t want it. - I’m sick of big giant PC towers that take up massive space and don’t fit well in home theater cabinets (or anywhere else). - I’m sick of loud PC fans and the unnecessarily high power consumption and heat - I want a gaming PC that is fully utilized for games, not loaded down with needless background processes sucking up CPU and RAM - Hardware driver updates for Windows is such a chore. - Windows mostly broke DirectX/DirectInput compatibility. I’m so sick of having to get xce360 working and re-configured for every single game I buy now. - I hate it that Fraps doesn’t work any more with non-fullscreen mode starting in Windows 8 - I don’t want to be pushed to Windows Store
Gary Bernhardt was ahead of the curve with his extremely amusing talk The Birth & Death of JavaScript. https://www.destroyallsoftware...
A look back from the year 2035, he talks about the importance of having a assembly language for the web (asm.js) and tongue and cheek allowed the world to move past JavaScript where it finally becomes both a dead language and also what everything is built on.
- It only worked on A8/PowerVR. Apple didn't know if they could generalize it.
Where did the idea that "Apple didn't know if they could generalize it" come from?
Attendees who asked Apple engineers about it at last year's WWDC.
Standards ratifications are really hard, especially if somebody on the committee doesn't like you.
Look up Apple's attempt to standardize Bonjour (Zeroconf) with the IETF.
Just because they had problems with the IETF doesn't mean they would have problems with Khronos, in fact the history of OpenCL proves the opposite. But again, I didn't say it should be pushed as a standard.
An underlying point that is under appreciated is that it is a lot of work/time/money to submit with no guarantees of acceptance. I don't see much incentive for Apple to standardize it at this point. Nor should they throw away Metal, because it works today. Viable Vulkan would be at least another full release cycle for them to adopt.
But you can look up the stories of how Google/Android is now spiking OpenCL support and pushing RenderScript.
It's odd that you say Google is "spiking" OpenCL by pushing their own RenderScript yet you don't see a problem with Apple "spiking" open graphics API standards by pushing their own proprietary Metal.
Just reiterating my earlier statement of fact (Glide, DirectX, OpenGL, OpenGL ES, Mantle, Metal, Vulkan) that standardization doesn't necessarily mean anything in the end.
I've been sticking to the facts because logical conclusions can be easily drawn from the facts.
Last Year: Submitting Metal last year for standardization would have been a waste of everybody's time. - It only worked on A8/PowerVR. Apple didn't know if they could generalize it. - Nobody else would waste time with it for standardization if it wasn't going to work for anybody else.
Today: - As of a few months ago Khronos now has what hopefully will be a usable standard. - Apple has just finished (or nearly finished) porting to Metal to OS X for 10.11.
There is probably little interest now for Apple to submit Metal as a standard. Khronos is committed to Vulkan now. Nobody else is going to take Apple seriously for Metal at this point if they tried. And submitting Metal as a standard would mean Apple would be unable to improve/change things quickly.
Not to mention all the work and time of writing draft standards and proposals. Standards ratifications are really hard, especially if somebody on the committee doesn't like you.
Look up Apple's attempt to standardize Bonjour (Zeroconf) with the IETF. It got really close to ratification, but Microsoft spiked the Draft Standard at the last minute. With some aggressive searches, you can find Stuart Cheshire (creator of Zeroconf) lambasting both Microsoft for offering a completely unusable counterproposal simply to kill/poison/derail ratification, and members of the IETF for going along with it, knowing full well Microsoft's proposal had not been implemented, didn't address the point of Zeroconf, and wouldn't even work. Even without ratification though, Zeroconf is now shipped standard on every major platform except Windows where Microsoft is stilling being obstinate. (Bonjour, Avahi, Android NSD.)
Historically, the OpenGL committee hasn't agreed on much of anything of practical use for graphics developers. Hence the new Vulkan standard, to dump some of the conflicting interest. But you can imagine interests from Samsung, Microsoft, Google, would look at Apple suspiciously and may even try to spike it again. (Apple did manage to get OpenCL standardized, but not a lot of interests were invested in this technology and paying attention in that period. But you can look up the stories of how Google/Android is now spiking OpenCL support and pushing RenderScript.)
- Apple needed to ship something that worked for real on their platform (iOS/ARM/PowerVR) that they could ship, not vaporware or theory. Nothing existed. AMD Mantle the closest thing didn't work with the ARM/PowerVR design. Hence they did Metal for iOS.
- One year later, they figured out how to bring it to OS X and announced it today.
- A few months ago, Vulcan was announced, but is still not final. That doesn't help Apple for devices shipping this fall.
- Vulkan probably wouldn't haven't gotten as far as it had gotten without Apple's push on Metal and noise by Microsoft on DirectX 12. Consumers benefited from competition.
- The trade off of waiting for standardization that to many didn't look like it would ever come, was stagnation.
- Fragmentation sucks, but this is nothing new. 3DFX/Glide, Direct3D, OpenGL, OpenGL ES, and all the incompatibilities between versions and feature sets, including shader version incompatibilities.
Because it was unclear, even to Apple, if Metal could work outside their tightly integrated ARM/PowerVR designs. (Engineers who asked about Metal on OS X at WWDC last year said they would like to, but they aren't sure they could actually pull it off since.)
This was a similar early concern about Mantle. To get high performance, "to the metal" often means certain requirements. Things like Apple's A8 or AMD having a unified/shared memory architecture on chip between the CPU and GPU is vastly different than Nvidia having separate VRAM from CPU RAM. Hardware differences like these are not easy to abstract away without performance loss.And for an API that is supposed to be "to the metal"/"direct to hardware", nobody wanted to repeat the current problems we have with OpenGL.
Slashdot Mirror
Go was created by Rob Pike and Ken Thompson to solve real problems Google was having with its massive C++ code base.
The domain they work in is huge scalability, server backends.
You are right, it is a boring language, and that's just how they like it because Google is trying to solve their very specific problems without creating nightmares of new ones.
Go is designed to address many of the scale complexity problems they faced with C++, in both human terms and machine terms. In human terms, C++ is a very complex language. In machine terms, the joke was that Go was invented while waiting for a C++ compile job. (Google's build times are frequently measured in hours.)
Go also addressed scaling problems for other languages. Java, C#, Python, Ruby, NodeJS, etc. consume a lot more resources to spin up their virtual machines. At Google scale, this adds up to needing a lot more hardware, and a lot more power to run the data center, and a lot more cooling needed.
And since most of Google's server requests have no dependencies with each other, they could build directly into the language mechanisms to support concurrency. (And they make it a point to distinguish between concurrency and parallelism in computer science terms.)
In the end, Go is a fairly simple language that people from scripting languages can pick up reasonably, while getting pretty decent native performance, and also getting concurrency features which are optimized for their domain.
Be aware that coroutines are not the same as threads. They are much lighter and you can have a lot more.
Also remember, concurrency is not the same as parallelism. The Go literature tries very hard to remind people of this computer science fundamental.
Go's primary domain is server backends. The workload is basically handling many thousands of requests per second that are completely independent of each other (embarrassingly parallel). You are absolutely correct that you don't want zillions of threads. Coroutines can be very effective here.
> Go billed itself as a systems programming language.
They backed off on this claim a while ago. It's popularity and main use case has been as a server backend language.
Because the language compiles to native code and is closer to the hardware, everybody lumped it in with "systems" programming languages.
As a server language, it meets its objectives well. The native aspects give it an advantage over languages like Ruby (Rails), JavaScript (NodeJS), Python with smaller memory footprints and ability to take advantage of multiple cores/processors.
The built in design for coroutines makes it easier to do concurrency easier than other native languages which only have threads, and coroutines are much lighter weight than threads. (Please note, concurrency is not the same as parallelism. The Go literature tries very hard to remind people of this computer science fundamental.)
Dude, don't get me started on first world problems. We're about to get either Hillary Clinton or Donald Trump as President. Cut me some slack.
"Desperately needed" in the sense that Metroid 2 is the hardest game to play *legally* now and the longest in tooth technology-wise. Most people aren't going to casually go to eBay and pick up a working GameBoy.
The original Metroid got remade as Zero Mission. Super Metroid can be played on Wii U Virtual Console, and at least that game has color. Metroid 2 can be played on 3DS, but the low resolution monochrome graphics are a hard sell in today's modern world of retina displays and GPU in your pocket that are more powerful than the supercomputers of that era.
We just went through this a week and a half ago with the fan Metroid 2 remake AM2R. Nintendo shut that down in 2 days.
http://www.ign.com/articles/20...
It is a brilliant remake, which was desperately needed because Nintendo seems to constantly ignore Metroid. If Nintendo shuts down something like this, Pokemon doesn't have a prayer.
"But they have avoided the steep cost of rebuilding their reservations systems from the ground up,"
As somebody who had family affected by the Southwest outage 3 weeks ago, the reservation system was one of systems that remained up the longest. Southwest still could happily take your money even if nobody was going anywhere. (I suspect they manually took it down later it became clear the day was lost.)
Focusing on the reservation system sounds like a contractor lobbying to sell something...
so, it's like memcpy?
Yes, like memcpy, except memmove (there should be an 'e' at the end for the C89 ANSI compliant name) allows memory to overlap. memcpy can be optimized to be faster since it doesn't have this constraint.
I'm about to start a project for fun using C and I was wondering what the best version would be C89? C99? C11? It seems that nothing in C99/C11 is all that compelling and I'd like to have solid multi-threaded support (POSIX threads). Any reason to use anything other than C89 features?
C99 has some really convenient features: ...) // comments
- inline functions (note: these work slightly differently than C++ because they fix the problem of guaranteeing symbol generation for linkage concerns)
- long long
- _Bool and
- (uint32_t, int8_t,
-
- not requiring all variables to be declared at the top of the scope
- local scoping for for-loop variables: for(size_t i=0; ival; i++)
- variadic macros
- snprintf
- designated initializers
- restrict (for the hardcore performance sensitive folks)
Microsoft dragging its feet on updating Visual Studio's C compliance to C99 and beyond has been the major reason for people sticking to C89. But the rest of the world has moved on. Microsoft finally started waking up and realized not being able to compile massively cross-platform open source projects like Git was a problem. Also, Microsoft's iOS compatibility bridge requires a good C compiler as Obj-C is a superset of C and Obj-C devs take for granted a lot of the above listed features. Visual Studio 2015 has *finally* started adding a bunch of the more popular C99 features so it can finally compile Git, though it is still missing things, with __STDC_VERSION__ still not up to date as a telltale sign.
Ridiculous. We all know Pokemon is a plot to get children to bomb Pearl Harbor. South Park already proved it.
Though Chun Li has been focusing turtle (half-shell) evolution.
Seriously.
https://groups.google.com/foru...
Sony uses FreeBSD now. And after stuff like this, it probably makes them glad they have nothing more to do with Linux or allowing anybody to do stuff with their own hardware.
UWP is only for Windows Store apps. Steam games won't get this feature.
Remember the Tim Sweeney editorial from just 2 months ago?
https://games.slashdot.org/sto...
Though what's interesting about the Return of the Jedi holographic Death Star briefing is also the point my prof was making. Despite the cool hologram, the rendered graphics in the hologram get intentionally dumbed down. You can see color filled translucent polygons and smooth curves (making the green and red colors of the moon and Death Star) in some parts showing the technology was actually there, but the major focus parts of the briefing are the Death Star and the tunnels to the reactor which are all wireframes, and the forest moon shield visualization is done with individual pixels.
My graphics prof told us that the people hired to do the graphics for Star Wars were instructed to make it look more primitive. The technology already existed to do filled colored polygons and deal with pop-up and so forth. But when Lucas or whoever saw their first pass, they said it looked too good. So for example, in the trench run briefing, you see that they went to green wireframes with massive pop-up problems where big chunks just suddenly appear.
For example, it takes about an hour for the OS to boot up.
Man, I thought my PC had bad boot times.
That sounds about normal to me. Time to defrag the hard disk and do a fresh reinstall of Windows.
They didn't buy Roland. They did buy E-mu.
It's a status symbol. It's like the 'H' on my Honda. That's how people know it's a Honda! Why would you drive a Honda if you can't show it off?
This isn't going to affect anything. DMCA abusers still have financial incentives to continue abusing (by automatically diverting ad money to themselves on claimed videos) and have no financial disincentives to stop doing this. If it gets to the rare point where Google does step in, they can just release the video in question while simultaneously continue abusing a thousand other videos.
I disagree about Steam Machines. There are real problems I have that I hope Steam Machines solves. I want a fully powered, gaming PC that just works, but doesn’t lock me down in what I can do with it.
- I want the benefits of mass production commodities and be able to buy a good PC gaming machine off-the-shelf for a lower price.
- I’m tired of spending so much time building my own custom PC and doing OS installations.
- I’m sick of Microsoft charging me many times more than everybody else for a Windows license because I didn’t buy a pre-configured machine from an OEM.
- I’m sick of Windows blue screening and corrupting my EFI boot partitions so my dual boots won’t work.
- I’m sick of Windows nagging me about turning on Secure Boot. I don’t want it.
- I’m sick of big giant PC towers that take up massive space and don’t fit well in home theater cabinets (or anywhere else).
- I’m sick of loud PC fans and the unnecessarily high power consumption and heat
- I want a gaming PC that is fully utilized for games, not loaded down with needless background processes sucking up CPU and RAM
- Hardware driver updates for Windows is such a chore.
- Windows mostly broke DirectX/DirectInput compatibility. I’m so sick of having to get xce360 working and re-configured for every single game I buy now.
- I hate it that Fraps doesn’t work any more with non-fullscreen mode starting in Windows 8
- I don’t want to be pushed to Windows Store
Gary Bernhardt was ahead of the curve with his extremely amusing talk The Birth & Death of JavaScript.
https://www.destroyallsoftware...
A look back from the year 2035, he talks about the importance of having a assembly language for the web (asm.js) and tongue and cheek allowed the world to move past JavaScript where it finally becomes both a dead language and also what everything is built on.
but there is a secret alien base on Pluto
Was this a reference to the Spathi in Star Control 2? I think I know what I'm going to play tonight... :)
http://sc2.sourceforge.net/dow...
That's what I was thinking too. Captain Fwiffo and the StarRunner.
- It only worked on A8/PowerVR. Apple didn't know if they could generalize it.
Where did the idea that "Apple didn't know if they could generalize it" come from?
Attendees who asked Apple engineers about it at last year's WWDC.
Standards ratifications are really hard, especially if somebody on the committee doesn't like you.
Look up Apple's attempt to standardize Bonjour (Zeroconf) with the IETF.
Just because they had problems with the IETF doesn't mean they would have problems with Khronos, in fact the history of OpenCL proves the opposite. But again, I didn't say it should be pushed as a standard.
An underlying point that is under appreciated is that it is a lot of work/time/money to submit with no guarantees of acceptance. I don't see much incentive for Apple to standardize it at this point. Nor should they throw away Metal, because it works today. Viable Vulkan would be at least another full release cycle for them to adopt.
But you can look up the stories of how Google/Android is now spiking OpenCL support and pushing RenderScript.
It's odd that you say Google is "spiking" OpenCL by pushing their own RenderScript yet you don't see a problem with Apple "spiking" open graphics API standards by pushing their own proprietary Metal.
Just reiterating my earlier statement of fact (Glide, DirectX, OpenGL, OpenGL ES, Mantle, Metal, Vulkan) that standardization doesn't necessarily mean anything in the end.
I've been sticking to the facts because logical conclusions can be easily drawn from the facts.
Last Year:
Submitting Metal last year for standardization would have been a waste of everybody's time.
- It only worked on A8/PowerVR. Apple didn't know if they could generalize it.
- Nobody else would waste time with it for standardization if it wasn't going to work for anybody else.
Today:
- As of a few months ago Khronos now has what hopefully will be a usable standard.
- Apple has just finished (or nearly finished) porting to Metal to OS X for 10.11.
There is probably little interest now for Apple to submit Metal as a standard. Khronos is committed to Vulkan now. Nobody else is going to take Apple seriously for Metal at this point if they tried. And submitting Metal as a standard would mean Apple would be unable to improve/change things quickly.
Not to mention all the work and time of writing draft standards and proposals. Standards ratifications are really hard, especially if somebody on the committee doesn't like you.
Look up Apple's attempt to standardize Bonjour (Zeroconf) with the IETF. It got really close to ratification, but Microsoft spiked the Draft Standard at the last minute. With some aggressive searches, you can find Stuart Cheshire (creator of Zeroconf) lambasting both Microsoft for offering a completely unusable counterproposal simply to kill/poison/derail ratification, and members of the IETF for going along with it, knowing full well Microsoft's proposal had not been implemented, didn't address the point of Zeroconf, and wouldn't even work. Even without ratification though, Zeroconf is now shipped standard on every major platform except Windows where Microsoft is stilling being obstinate. (Bonjour, Avahi, Android NSD.)
Historically, the OpenGL committee hasn't agreed on much of anything of practical use for graphics developers. Hence the new Vulkan standard, to dump some of the conflicting interest. But you can imagine interests from Samsung, Microsoft, Google, would look at Apple suspiciously and may even try to spike it again. (Apple did manage to get OpenCL standardized, but not a lot of interests were invested in this technology and paying attention in that period. But you can look up the stories of how Google/Android is now spiking OpenCL support and pushing RenderScript.)
- Apple needed to ship something that worked for real on their platform (iOS/ARM/PowerVR) that they could ship, not vaporware or theory. Nothing existed. AMD Mantle the closest thing didn't work with the ARM/PowerVR design. Hence they did Metal for iOS.
- One year later, they figured out how to bring it to OS X and announced it today.
- A few months ago, Vulcan was announced, but is still not final. That doesn't help Apple for devices shipping this fall.
- Vulkan probably wouldn't haven't gotten as far as it had gotten without Apple's push on Metal and noise by Microsoft on DirectX 12. Consumers benefited from competition.
- The trade off of waiting for standardization that to many didn't look like it would ever come, was stagnation.
- Fragmentation sucks, but this is nothing new. 3DFX/Glide, Direct3D, OpenGL, OpenGL ES, and all the incompatibilities between versions and feature sets, including shader version incompatibilities.
Because it was unclear, even to Apple, if Metal could work outside their tightly integrated ARM/PowerVR designs. (Engineers who asked about Metal on OS X at WWDC last year said they would like to, but they aren't sure they could actually pull it off since.)
This was a similar early concern about Mantle. To get high performance, "to the metal" often means certain requirements. Things like Apple's A8 or AMD having a unified/shared memory architecture on chip between the CPU and GPU is vastly different than Nvidia having separate VRAM from CPU RAM. Hardware differences like these are not easy to abstract away without performance loss.And for an API that is supposed to be "to the metal"/"direct to hardware", nobody wanted to repeat the current problems we have with OpenGL.