Re:Apple Silicon M1 chip in MacBook Air outperforms high-end...
by pjmlp on Thursday November 12, 2020 @05:03AM
(#25068283)
> Working with C/C++ is another pain point for cross platform, which already starts with Apples own Clang and different lib naming conventions.
A walk in the part to anyone that had to deal with coding with C or C++ across UNIX flavours.
Re:Apple Silicon M1 chip in MacBook Air outperforms high-end...
by oneplane on Thursday November 12, 2020 @08:14AM
(#25069464)
Or anyone who had to deal with Microsoft's on version of everything.
Re:Apple Silicon M1 chip in MacBook Air outperforms high-end...
by pjmlp on Thursday November 12, 2020 @08:23AM
(#25069547)
Point one C or C++ compiler vendor that has a pure ISO compiler with zero extensions.
Toy projects don't count.
Re:Apple Silicon M1 chip in MacBook Air outperforms high-end...
by bstar77 on Thursday November 12, 2020 @11:27AM
(#25071497)
I do web development and I'm not sure how my locally compiled libs will behave on x86 based servers. We often upload our local build artifacts to the DEV envs... I'm not sure this will work on a different arc.
That said, my wife returned the macbook air she bought 3 weeks ago in favor of this new one, so I'll be able to test on that machine before I dive in.
Re:Apple Silicon M1 chip in MacBook Air outperforms high-end...
by ghaff on Thursday November 12, 2020 @07:47AM
(#25069232)
I'm primarily a Mac user but laptops are cheap. If I were working on a team doing Linux development for x86 I'd certainly have a Linux laptop for that even if I preferred a MacBook for other purposes.
There are enough people who do not want to deal with MacOS and Darwin regardless the hardware specs.
Also the way of least friction is usually to use whatever the rest of your team uses. There are even relevant differences in Docker for MacOS vs Docker for Linux that make cross platform difficult (in particular thinking about host.docker.internal, but there are certainly more). Working with C/C++ is another pain point for cross platform, which already starts with Apples own Clang and different lib naming conventions.
Going away from x86 makes this situation certainly not better.