5 ms·

> I'm not sure why this is remotely surprising or noteworthy. It might not be for you, but then I'm curious why it's noteworthy enough to have two layers of co

by DCKing 6y ago

> I'm not sure why this is remotely surprising or noteworthy. It might not be for you, but then I'm curious why it's noteworthy enough to have two layers of comments about it. If you don't want to talk about that then by all means let's not. Apple has priorities, and these have results. I think it would be interesting to talk about that, as Apple could have invested time and money in getting some more things going (I'm thinking virtualization and Docker related things especially - you know, the stuff they demoed at WWDC!), but they didn't. It's fine they didn't, but we can still talk about that can't we?

ogre_codes 6y ago
> It might not be, but then I'm curious why it's noteworthy enough to have two layers of comments about it. You noted it, I was trying to explain something which seems to me exceedingly obvious. > Apple has priorities, and these have results. The reason these tools were built/ run first is due to the priorities and constraints of outside individuals, not Apple's. If you build a graphics editor or a text editor using Apple's toolchain and most of your clients run Apple, porting is likely high priority and not super hard. A lot of these things you are complaining about are just really hard problems. Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go. Go isn't available because porting languages to a new processor is non-trivial. Rust has the above issues, plus didn't Mozilla lay off a huge chunk of the Rust team?
- DCKing 6y ago
  Well we can talk about this! > Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go. Apple did have prerelease hardware that supported virtualization, which they supplied to Parallels. Docker has not worked with this hardware based on their press release and GitHub issue [1][2], although they may have received some specs. In any case, Docker depends on Golang with won't release until February. If Apple did make Docker a priority (which you'd expect given the namedrop at WWDC), this seems quite strange to me. [1]: https://www.docker.com/blog/apple-silicon-m1-chips-and-docker/ https://www.docker.com/blog/apple-silicon-m1-chips-and-docke... [2]: https://github.com/docker/for-mac/issues/4733 https://github.com/docker/for-mac/issues/4733 > Go isn't available because porting languages to a new processor is non-trivial. I'm sorry, I don't buy this at face value for Go and Rust. I believe these teams could support a new architecture very well very quickly with the right tools and support, like how their stuff also runs on weird things like S390. They show day in day out their stuff is very flexible. By no means do I want to suggest it's a trivial matter, but these toolchains are made to be portable and currently support both much more exotic and very similar systems to aarch64 macOS at the same time - like x86-64 macOS and arm64 iOS. Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI? It seems that if Rust and Go developers were approached with the right tools and support, they wouldn't have had to figure things out now. Is it that bad that they have to figure things out now? Not really - but I do think it could have been avoided, and we wouldn't have had to wait for a golang release in February and a Docker release after that.
  - steveklabnik 6y ago
    > Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI? Rust's CI is pretty demanding, both in general, as well as given that it's core to our stability story, we need it to be reliable, and something we can rely on for a long time. DTKs are by very nature not a long-term thing, but a short term stopgap.
- steveklabnik 6y ago
  > Rust has the above issues, plus didn't Mozilla lay off a huge chunk of the Rust team? Mozilla laid off a huge chunk of the people they paid to work on Rust, but that was a very small (but important!) portion of the overall Rust team.

by DCKing 6y ago

ogre_codes 6y ago

> It might not be, but then I'm curious why it's noteworthy enough to have two layers of comments about it. You noted it, I was trying to explain something which seems to me exceedingly obvious. > Apple has priorities, and these have results. The reason these tools were built/ run first is due to the priorities and constraints of outside individuals, not Apple's. If you build a graphics editor or a text editor using Apple's toolchain and most of your clients run Apple, porting is likely high priority and not super hard. A lot of these things you are complaining about are just really hard problems. Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go. Go isn't available because porting languages to a new processor is non-trivial. Rust has the above issues, plus didn't Mozilla lay off a huge chunk of the Rust team?

DCKing 6y ago
Well we can talk about this! > Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go. Apple did have prerelease hardware that supported virtualization, which they supplied to Parallels. Docker has not worked with this hardware based on their press release and GitHub issue [1][2], although they may have received some specs. In any case, Docker depends on Golang with won't release until February. If Apple did make Docker a priority (which you'd expect given the namedrop at WWDC), this seems quite strange to me. [1]: https://www.docker.com/blog/apple-silicon-m1-chips-and-docker/ https://www.docker.com/blog/apple-silicon-m1-chips-and-docke... [2]: https://github.com/docker/for-mac/issues/4733 https://github.com/docker/for-mac/issues/4733 > Go isn't available because porting languages to a new processor is non-trivial. I'm sorry, I don't buy this at face value for Go and Rust. I believe these teams could support a new architecture very well very quickly with the right tools and support, like how their stuff also runs on weird things like S390. They show day in day out their stuff is very flexible. By no means do I want to suggest it's a trivial matter, but these toolchains are made to be portable and currently support both much more exotic and very similar systems to aarch64 macOS at the same time - like x86-64 macOS and arm64 iOS. Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI? It seems that if Rust and Go developers were approached with the right tools and support, they wouldn't have had to figure things out now. Is it that bad that they have to figure things out now? Not really - but I do think it could have been avoided, and we wouldn't have had to wait for a golang release in February and a Docker release after that.
- steveklabnik 6y ago
  > Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI? Rust's CI is pretty demanding, both in general, as well as given that it's core to our stability story, we need it to be reliable, and something we can rely on for a long time. DTKs are by very nature not a long-term thing, but a short term stopgap.
steveklabnik 6y ago
> Rust has the above issues, plus didn't Mozilla lay off a huge chunk of the Rust team? Mozilla laid off a huge chunk of the people they paid to work on Rust, but that was a very small (but important!) portion of the overall Rust team.