wulfklaue

* Limited IO * Max 16GB Memory ( at unjustified cost ) * Limited Multi monitor support * No eGPU support ( as of now )

* Only about 50 a 55% of all the software is M1 ready ( looking at some tracking sites ). Technically this is not a M1 flaw but you need something to push the market/iron out the bugs. While when the M2 gets introduced, you may be at 60 or 70%. As in less likely to run into issues as the M1 users are the real beta testers. Even Parallels only recently got good M1 support ( with massive speed increases ).

As of this moment, buying a M1 laptop is a less beta tester feature then it was several months ago. If you ended up buying in Nov/Dec, you spend a lot of time under Rosetta 2 or dealing with issues.

> I haven’t read many negative reviews.

The above was kind of always overglanced by a lot of the reviews, as the youtubers mostly looked at their own us for video editing etc and there most software was on point very early in the release cycle.

You see a lot of reviews in Jan/Feb from people going back to Windows laptops after a month, not because of the CPU being bad but because they ran into software issues.

In the mean time the software situation has evolved a lot more but the progresses with software being made M1 ready has also slowed down a lot.

As a PC user i want a M1 like laptop, that has long battery life, is silent and still powerful ( unlike a lot of Windows laptops where its always the old saying: Pick 2, you can never have all 3 ).

But i prefer one with 8 performance cores, double the iGPU cores ( with preferably DDR5 ) for light gaming and standard 16GB. So some macBook 16 Pro or whatever, if the price is not insane. We shall see what Apple introduces...

So far the new offerings from AMD and Intel are fast but still power hungry and heat generating ( aka fan noise! ). AMD is only going little.big in 3nm.

Intel's alder lake may be a M1 competitor ( for battery life under light loads ) but its again first generation product so expect to be a beta tester until Windows gets fine tuned for a long time to properly use the little cores! For heavy loads, ... well, 10nm is 10nm, no matter how many +++ you add.

The EU is introducing legal laws that will combat planned obsolescence. And that protect the right to repair. The EU is also fed up with manufactures thinking they can get away with everything. Those laws will also have a effect across the world because its easier to design on product that applies to the strictest laws, then two products.

So yea, Apple their gravy train is going to run into a massive road block. In the US states are also starting to rectify laws that push the right to repair.

Its one of the reasons why Apple "suddenly" allows repair shops to buy parts. As a way to change the narrative. Of course that buying parts has "issues" Apple style. A grifter is going to grift.

> IDEs such as IntelliJ can easily consume 8GB of memory

Sound more like a Jetbrain ( IntelliJ company ) problem. Used to develop on PHPstorm ( another Jetbrain ) product ( same software in the background ) and the slow startup's, 2GB+ memory eating for relative small projects, crashes way too much, expensive as hell for what it does ( especially with the license change years ago ) ...

Eventually switched to Visual Studio Code and while people whine how Electron is memory inefficient, its like 1/6 the memory usage of PHPstorm, with only a few features missing.

Even on a 32GB PC system, i barely use 16GB ( and WSL2 is eating up a lot with a lot of docker images. And its not really docker, just Linux cache eating up memory ). Not a issue on a Mac that does not need a VM like layer.

Its about priorities sometimes. If people keep upgrading their memory, developers/companies simply push the responsibility to the clients and do not bother with spending time on optimizing.

If people start leaving software product on the way side for being just horrible inefficient messes, then maybe a bit of focus will come back to actually optimizing products! You will see Jetbrain change tune, when VSC etc keep eating its market share.

> I'm honestly for the first time in a decade a bit excited about an upcoming computer,

I think we are more excited about a shake up in the whole computer world, that may mean the dead of ATX/MB's/etc as we know it. And a more profound move to eGPU/NUC/Laptop like powerful devices with a low power usage.

This feels a bit like a wakeup call to the industry. Like how the first (commercial) successful smartphone, the iPhone 1 fueled a entire industry for over 10 years to massive evolve. What is kind of funny because i felt like the smartphone evolution was starting to loos steam. The conversion between PC/Laptop/Smarthones will begin now.

Plenty move advantages then just round trip latency. The fact that its a single SOC, what in turn reduces traces on the MB. Freeing up real-estate.

We are finally moving to the conversion point between smartphone's and PCs. It has been in the making for a while.

Now, if that is a good thing for the consumers ( losing upgradability ) is another thing? But given how PC's have become less and less flexible anyway.

We used to have slots for everything ( GPU, Network, Audio, ...). Now we have ATX boards where you maximally put in a GPU. SATA is going the way of the dodo with m.2 becoming the new standard for anything data. I mean, what do we even change anymore on PC's... CPU, Memory, GPU.

GPU's will become a external device with USB4. Mass storage has been moving to NAS more and more or USB3 devices. The people that need 4+ HDD's are more exceptions. And you can get away with USB3 HUB's + external enclosures.

I questioned for a long time, why we still have Chipset, that artificially segment MB's when the difference has become very small between them anyway. You can easily move that last bit of IO into the CPU SOC.

The days that we buy AMD or Intel SOC's with some default CPU+RAM+IO is probably closer then what most think.

Separate hardware is probably going to become a Server / Workstation Pro only feature ( with big $$$ prices ).

The reality is that hardware has reached a point, that most people did not even upgrade for years anymore. And its more a smaller group / minority that really needs ultra fast hardware.

Flexibility is moved from big MB's to external devices, connected over high speed connections.

Sorry if i have gone a bit off topic but when you mentioned the onboard memory, it got me thinking about how we really are moving to a SOC/NUC/... future for even powerful hardware.

I am not the author of the Twitter post.

The mentioned post shows the results after switching from Ruby + Sinatra over to Crystal + Kemal.

https://pbs.twimg.com/media/DabQrScW4AAycuC.jpg:large https://pbs.twimg.com/media/DabQtJdXcAAMo9j.jpg:large

Links:

* https://crystal-lang.org * http://kemalcr.com/

What is Crystal?

> In computer software programming languages, Crystal is a general-purpose, object-oriented programming language, designed and developed by Ary Borenszweig and Juan Wajnerman and more than 200 contributors. With syntax inspired by the language Ruby, it is a compiled language with static type-checking, but specifying the types of variables or method arguments is generally unneeded. Types are resolved by an advanced global type inference algorithm.

/Looks at price...

Gets you 11 Pi's ... Gets you only 1 Intel CPU, no memory, motherboard, heatsink, fans.

Reminds me of the Celeron® Processor J3455... 10W rating on Intel there page. On AVERAGE! Then when you see the real power usage under load for MB + CPU + 16GB memory, its actually doing 35W.

Where as the Pi's are doing 3.7W max per piece. So even with 4 pieces to match the performance, your still half the wattage.

If Intel really scaled that good in power vs performance, why are we not seeing x86 phones all the time?

So simply use the free "freepascal / lazarus". You wallet will thank you later. :)

> So, apparently you didn't even read the article, as it is explicitly stated that this was not the intention or direction of Swift.

It might actually help that there is a real commitment in that direction. The issue being that it was IBM that mostly pushed for changes in foundation and without there initial blue socket support, even the most basic tasks did not even succeed.

Let alone the none existing windows support. It may not have been Chris his intention but one now ex-employee intention does not mean a lot when the company determines the direction after his release.

Good luck on seeing D on that site. There seems to be a active war between the sites maintainer and D. There used to be D benchmarks on the old site and people tries to release new code to the site, but for some reason the current maintainer has a issue with D.

And he thinks its no unfair that D is not resented when a lot of people look at his site and think: "If your not here as a language, then the language must be bad".

Good luck on changing his mindset because i have seen topics going back years regarding D not being there.

If you want a more impartial benchmark set:

https://github.com/kostya/benchmarks

And where is D on those tests ;)

It was my impression that CoreRT work was put on the back burner ( not on hold ) so the team was able to focus on Core 2.0 release. Theoretically the team can move more resources to CoreRT as Core 2.0 is now in preview.

There was some talk about CoreRT and July but i forget where that news came from.

D is a good C++ replacement language. But it needs more community support.

Its advised to develop in DMD compiler and only compile the release code in LDC/GCC as this can be twice or trippel as fast. Not saying that DMD is slow ( unless you consider Go/Swift slow).

https://github.com/kostya/benchmarks

With the 3 reference compilers:

D DMD also written sometimes as simply D D LDC = LLVM backend D Gdc = GCC backend

The benchmarks are somewhat out of date for D, as it has never versions of Rust, Go etc where as the D LDC is still using the very old 0.15.2-beta1. Now its at 1.3.0 beta1, that support LLVM 3.5 to the latest 4.0 ( what is faster ).

Except that there are other languages like Go, Crystal, D, Nim that all offer memory safety ( thanks to there GC ), with a light GC ( like reference counting ). And based upon the same benchmarks that Rust in participates, they are close or even faster at times, with close or better memory usage.

https://github.com/kostya/benchmarks