Xcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?
* Windows: 61 MiB
* Linux (x86): 49 MiB
* macOS (x86): 42 MiB
* macOS (arm): 38 MiB
* Windows: 7 MiB (updated D3D12 headers & libs)
* MacOS: 112 MiB (almost all frameworks provided by XCode, for x86+arm+iOS)
* Linux (x86): 22 MiB (x11/wayland headers & libs)
* Linux (arm): 15 MiB
* GLFW
* Dawn (Chrome's WebGPU implementation)
* The DirectX Shader Compiler (a fork of LLVM)
* Freetype and HarfBuzz
All from source, cross-compiled to every OS. Plus with Zig you can link+sign macOS binaries from Linux and Windows (AFAIK that's not possible with a regular C compiler, but maybe that's changed recently?)
It was annoying for me because part of the reason I wanted to try Rust on Windows was specifically to avoid multi-gigabyte C/C++ toolchain downloads. I bet the actual compiler and linker aren't that big, so I kind of wonder where all those bytes are going...
Aside: I see a sibling comment mentions Zig. While I haven't really explored Zig, the tiny single-binary download was a breath of fresh air. Go also had a quick and easy download, but I wanted a language without a garbage collector.
> Not so easy to fit it all on an SSD drive.
Professionally, no excuse. As an open source or otherwise unpaid pursuit, a 250GB SSD is about $45 on Amazon right now. That more than comfortably fits your 60GB estimate, with plenty of room to spare.
Would love to see a breakdown of where that space is going. FWIW IntelliJ takes up 2.5GB, and honestly, even THAT seems like a lot to me.
> even THAT seems like a lot to me.
That's a little silly - what is an acceptable amount in that case. The JDK on its own is about 700MB (that's a guesstimate based on last time I installed it sorry).
25GB is enormous. 2.5GB is enormous. Consider that the core value of this software is text editing. Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all (e.g. the Apple IIe). Windows XP and Office 97, for example, were (if memory serves) less than 1 GB total. FoxPro for DOS was something like 4 megabytes - and FoxPro was a form builder plus relational database. Consider that with a thoughtful use of resources and an eye toward minimizing attack surface, you can put a fully functional http/s app server in a 1.9MB package (redbean).
These sizes are silly, and they should give you pause. The space is cheap, yes, but the attack surface is not.
Don't be reductive - just because your linux hides those costs directly in /usr and /var it doesn't mean those things don't exist.
> Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all
Not that long ago in history, but an absolute eternity ago in computing terms. I have a direct internet connection to my home that is faster than the read write speeds of those computers.
> Consider that with a thoughtful use of resources and an eye toward minimizing attack surface
Attack surfaces have changed significantly since people were buying 10MB hard drives - you cannot write applications with the same security considerations from that time.
> you can put a fully functional http/s app server in a 1.9MB package (redbean). The space is cheap, yes, but the attack surface is not.
Firstly, redbean is the absolute extreme example of minimalism and portability. It's not "normal" it's an incredible feat of engineering frankly. Nginx isn't much bigger (~5mb) and caddy is bigger but still small (30Mb). The big difference between these and IDEs is that web servers dont provide client interfaces. For user facing tools they rely on web browsers to render html and interpret JS, so to make a comparison it's only fair to compare redbean + chrome to a Windows SDK install for example.
It's easy to forget that there are billions of people for whom $45 is a massive investment, and that SSD isn't so conveniently available even if they have the money.
I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was using really crappy internet.
I don't think it's unreasonable for the poster to wish that they could build useful binaries without 60GBs of downloading and storage...
So those people can use whatever hardware they have available to them and not buy the SSD. The parent specifically said it was hard to fit on an SSD, so I assumed they could buy one based on that
> I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was using really crappy internet.
Graphing calculators, and raspberry PIs (and other various low power devices) are still widely available for people to learn and experiment with. Internet speeds are still a problem in many places but ay some point the software has to be delivered to you, and as I mentioned previously the actually install sizes are not 60GB, and the downloads are significantly smaller (a windows 10 iso fits on a 4GB usb)
> without 60GBs of downloading and storage...
Firstly, it's not 60GB - see my previous post about how much space it actually takes up. It's closer to 30GB. Secondly, if you don't have 30GB of storage of any kind available to you on a computing device,then sure, meanwhile anyone running a machine bought in the last 15 years will have that space available to them.
Let me say it again, 60, 30, even 10GBs, is a lot when there's tooling from the same company, that still make similarly functional binaries, that took 342 MB.
You don't need to keep obsessing over "how dare this person with limited resources use an SSD!", like I said you run into similar issues with just downloading the stuff.
Again, forest for the trees.
-
Instead maybe you can sit back and just ask "why the bloat over time"?
And the reality is likely: "because no one optimized for it". Because for them lots of fast storage and internet speed are no problem
That line of reasoning maybe allows you to see things from a different prospective and break some assumptions about end users.
Isn't that more useful than browbeating some random for not having 30GB free on their SSD?
Here's a hint: if they had the budget and availability they'd just get a bigger SSD and not write that comment.
-
Obviously, due to some aspect of their circumstance, be it availability, cost, download speeds, etc. the size of the toolkit is problematic.
I mean there's no intrinsic size for a development toolkit, but I don't know anyone who'd say 60GBs of data is a small development toolkit when as others have pointed out, there are older versions of the same Windows toolchains that still complete the same function and manage to take a fraction of the space...
This whole assuming everyone is destitute is getting rather tiring.
But yeah, seriously woe is you having to momentarily imagine some people are poor or have trouble getting access to tech.
I'm from Ghana so I guess it's not as onerous to imagine people don't live the exact same life I do in the US.
This is a utility that fixes a lot of the cross-compiling issues for windows by giving you a portable, unfucked naming, and not-massive SDK. It's the same SDK you get when you install MSVC but it's only a few hundred megs and the names are consistent even with all of Windows' fucked up tooling.
The only caveat is you need to provide your own compiler, in this case clang is often the best option.
Many of the high level categories, like Web Development,contain features you'll probably never use. If you're concerned about file size you can do a custom install to get a very lean install.
That being said, I would still recommend a Windows VM be allocated a 120Gb drive.
[0] https://visualstudio.microsoft.com/downloads/#build-tools-fo...
Maybe a decade ago, but SSDs are so much cheaper per GB nowadays. Around $0.11/GB. Pretty sure that's cheaper than the first 1TB HDD I've owned.
I don't really think that the toolchain is to blame for that one.
Can you please tell that to my IT department which refused to issue me a Linux laptop for 1 month, then took two months to put the order in... I had to get an executive (President of R&D) at the company to harangue IT... I still haven't seen it, apparently they are trying to install the standard "employee spyware" package on it.
Jesus. I have an executive level officer in the company that has my back and you're telling me to quit? Utterly horrible advice.
M1 is very impressive. But I hate macOS as much, if not more than, you hate Windows. My Threadripper makes me very happy.
I have no problems with external drives. Is this a Mac thing too?
32 years ago as a fresh out I got a government job with an SGI box with an enormous monitor. I stare in wonder at the future, right now. It sure doesn't look like happiness.
My work stack is tight on 32gb (yeah, it is what it is), that simply wouldn't fly for me. 8gb, especially with all the memory used by the os on MacOs, there's just no way.
[0] ...but with frequent travel?
I believe you mean 256GB.[0] Unless you meant to say 14" or 16" MacBook Pro, in which case the base spec is still only 512GB for either of them, not 1TB.[1][2]
For the prices Apple is charging, I wish they would make 1TB the base spec... but Apple Silicon is so good that the machines sell like hotcakes anyways.
[0]: https://www.apple.com/shop/buy-mac/macbook-pro/13-inch
If that's out of reach im not sure how you're powering your dev machine.
> A 1tb M.2 drive is what... £70?
To be contextually fair, Apple charges $400, and the storage isn't replaceable. Who runs their editor off of an external drive? I imagine the number is very small.
Although, on my machine, Xcode only seems to be taking up 17GB, not 70GB.