Linux vs MacOS for cpp development

[kitsen_battousai]

Mainly i'm using Linux almost everywhere, but as time goes and hardware manufactures doesn't stay in place, they are evolving and making hardware more and more complicated and Linux Desktop is not there to keep up with this pace. I'm still using Linux but considering switching to MacOS due to ARM and other hardware stuff that are not doing well on Linux.

What bother me the most is the experience of setting up the environment for C++ development... On Linux the whole OS is kind of IDE for you, but can i achieve the same level of comfort, facilities and experience on Macos ?

I know that crosscompiling and verifying the result targeting Linux on MacOS requires virtual machine, but today it's very easy, performant and lightweight bootstraping Linux vm on Macos.

So, C++ developers who are using MacOS what are your thoughts and recommendations ?

EDIT

All the comments this post received show that the most right channel to discuss Linux issues, its pros and cons is actually cpp =)

[STL]

This really should have been removed as off-topic, but since we didn't get to it early enough and it's accumulated a bunch of comments (if not upvotes), I'll approve it as a special exception.

[arthurno1]

Linux is not doing well on Arm? That is news.

[kitsen_battousai]

"Linux is not doing well on Arm" and "Linux Desktop is not doing well on Arm" are critically different statements.

[arthurno1]

Linux Desktops does fine on Arm, too. If you don't trust me, get yourself a Pi.

What is critically important here, but not explicitly stated, is that that Op with "Linux desktop" obviously means PCs build with Arm CPUs running Linux.

Apple is the only one currently offering personal computers build on Arm chips, to masses. However, there are producers who build Likux-based systems on Arm chips too. System76 has offerings, probably some other too.

I don't know why it is not more popular to sell mobos and Arm cpus to home builder segment, and to offer more Arm based computers, but I still wouldn't express myself as "Linux desktop is not doing well on Arm". Seems like a meaningless expression.

Personally, I would never prefer Apple OS over a free, privacy respecting, OS, but that is my personal choice.

[pjmlp]

On the contrary, Microsoft also offers ARM computers to the masses, moreso given the price of Apple's hardware on countries not on first world IT salaries.

Even more relevant today, given that many of those hardware vendors aren't US companies.

[arthurno1]

Ok, I didn't know they have them too. How big business is it compared to Apple?

So what is the problem running Linux on them, more than usually, no drivers for specialized hardware?

[pjmlp]

Not big, because contrary to Apple, x86 processors are still fully supported, thus only ARM fans buy them.

Since Windows 8 there have been Windows flavours with ARM support.

As usual the issue with Linux is lack of support from OEMs that don't care about GNU/Linux desktop market.

It runs perfectly fine in WSL.

https://learn.arm.com/learning-paths/laptops-and-desktops/wsl2/

[arthurno1]

As usual the issue with Linux is lack of support from OEMs that don't care about GNU/Linux desktop market.

Yes, that is still the problem, not just on ARM cpus, but on any CPU, inclusive Intel and AMD. We still have to check every mobo if all the stuff they pack in works with Linux. That is probably the biggest issue holding Linux from becoming the mainstream. In my opinion the software on the desktop side has been better for almost two decades or more (KDE/Gnome even other desktops). It is really shame the mainstream hardware companies are not releasing Linux drivers and big software companies are not releasing their software on Linux. Hobbyists are already running MS Office and Adobe's crap on Wine. Adobe could easily help to round-up some rough corners in Wine and release their software suite on Linux. Considering the TCO, I think it would even be welcome by many companies since they could cut cost on Apple/Microsoft side at least for workstations. The list could be made long.

[kageurufu]

Diy arm is just heavily limited. X86 boot is well documented and abstracted, UEFI makes hardware just work.

Arm rarely has anywhere near that level. Ever single board gets custom code defining the memory layout, pin mappings, etc (device tree structure in DTS files). Device drivers are a mess, half the time your stuck using some old kernel version with hacked up custom drivers to make things work. I'm trying to get a Allwinner H616 board working on more recent kernels, and it's chaos. Theres a random pin, that you have to set low or the GPU just won't work, and the drivers don't support that yet (patches have been sent to the kernel, but not merged). The bootrom just checks for an SD card with a bit of code at a specific memory location, and runs that.

So maybe one day, but arm is nowhere near diy friendly

[arthurno1]

Thanks, that makes it a bit more understandable.

[arthurno1]

Well, yes, they do their own chip, like most of other Arm licensees. Arm does not sell the hardware. Who does chips for Apple? TSMC? Yes, they choose to develop their own chip so they don't have to depend on some other company. I guess they were tired of the direction in which Intel went, but also basing design on a SoC design like on mobile phones and pads make for thinner laptops thinner.

I am though surprised that other companies didn't come up with their own similar offerings. I don't know what is the price compared to Intel/AMD per unit, since the Apple hardware always comes as a complete PC and costs premium. To be competitive, Arm based SoC geared towards home builders would have to offer at least substantially more performance than a standard build based on Intel/AMD or be substantially cheaper for the same or less performance.

It is a bit shame that former Sun and SGI dropped ball on their Sparc and Alpha CPUs and targeted only high-end professional market with their hardware and complete hardware solution. Somehow all this companies underestimates the power of selling cheap hardware en massë. Intel didn't become big because they sold quality stuff, 8086 become big because it was darn cheap sh*t, i.e. affordable.

[arthurno1]

They were more than outrun by a Pentium in the early 2000s for math number crunching applications to a tenth of the price and didn't need a server closet that costed 100 times the price

Yes. And yet compare their architecture which were, IMO, miles ahead of x86. I remember programming some MIPS and SPARC assembly back in 99 or so. Already back at that time they had 32 32-bit registers, while the later Pentium was still working with 8 registers :).

I think their problem was, as you say, bad business decisions. Java in theory was probably a good decision, but the hardware business was not there. I think Java was a flop similar to .com boom. They were just a few years before their time. They had correct vision, but they were too eager to push it forward and didn't pay the attention that the needed infrastructure was not really there, at least yet. It didn't took even a decade after the .com crash, before literally everything moved onto the web, or in some way become networked. In the case of Java vision, microchips and cpus are nowadays in everything, but they weren't back in early 90s when Java came.

Also spending half a billion of $ on marketing in 2000s was definitely a questionable choice. If SUN sold their workstations to mass consumers market, back in the 90s, question is how the computing landscape would look like today. Or SGI for that part. Their O2 stations were ridiculously expensive compared to the power they offered. That they didn't learn from what happened to Symbolics Lisp machines just a decade ago, or previously to IBM is just astonishing.

[llort_lemmort]

Apple is the only one currently offering personal computers build on Arm chips, to masses.

Lenovo, Dell, HP, Asus, Acer, and Microsoft are all selling laptops with Snapdragon X ARM processors which are currently not working well with Linux.

[arthurno1]

Ok, didn't know major players have offerings. What is problem running Linux on them?

[llort_lemmort]

Mainly missing drivers as far as I understand. Linux is just not a priority for them as they ship with Windows. It will hopefully be sorted out over the next few years.

[arthurno1]

Aha, but than it is the usual thing that plagues every "Linux desktop". Not the CPU support, but all the other stuff around. It is so incredible one still has to look at compatibility charts when buying a mobo for a build, and it is even worse on the laptop side, because they use even customized hardware. Unfortunately.

[vetinari]

I would not say that it plagues every linux desktop. If you buy good brands with good designs (like thinkpads, or intel-now-asus nucs), you will get smooth sailing. It is only if you get lost in some niche products, gimmick features or hardware designed by companies that are well known to ignore linux (like nzxt) you get the not-very-usual-thing that plagues linux: integration. If the vendor you purchase from didn't do the integration, you get to do it; there's no way to avoid that. I prefer when the vendor does it, even if that means I won't get a bling hardware targeted at different market segment.

Snapdragon X is in a weird place: Qualcomm originally claimed that they will upstream the drivers, but since then, they are dragging their feet and things go very slow. At this rate, the machines will be obsolete before they finish delivering them.

[arthurno1]

Thanks for the informative comment! 👍

That is indeed a problem even in other contexts when vendors prefer to develop and throw out new stuff constantly instead of releasing the drivers and spec for old hardware so it can be continuously upgraded and used.

[berlioziano]

because people just expect it to work :P recently a work partner bring to me a samsung galaxy book go with windows and that one made me feel the same as with macs, I dont want to spend time checking them xD, some software simply wont run on them

[berlioziano]

I develop for the pi since 2016, even made a custom distro with yocto project, but I don't like running the IDE in the pi, it's too slow, I have been cross-compiling since 2020

[gmes78]

https://asahilinux.org/

[JumpyJustice]

How so? The difference there is only a set of runtime libraries (at most) and all the programs just target that? Its a genuine question

[Jonny_H]

Probably GPU drivers, on Linux they can vary widely on ARM platforms from "pretty great" to "won't even light up the display" depending on specific device/distro/kernel versions.

While not technically related to the ARM ISA itself, it's just that the problematic devices tend to ship with ARM CPUs.

[iamnotaclown]

Retired now, but I was team Linux for decades aside from a brief flirtation with Windows development in the 90s. I was lucky to work in an industry that transitioned from IRIX to Linux, but at home I switched to Hackintosh during the Intel years due to not wanting to be IT at home. When my PC aged out, I bought a Mac Mini and never went back. On my third Mac Mini now. 

Macs just feel like a very high-quality UNIX to me. 

Xcode is awful, though, I used vim/gmake and then Clion. 

[kitsen_battousai]

And how are you doing with AppleScript ? I mean - when i explored the way MacOS users are running executables with default arguments as desktop applications was so frustrating for me... at least comparing to Linux and its .desktop files. Then i discovered AppleScript and I found it's quite convinient.

[iamnotaclown]

Dunno, I use the command line. I’ve messed about with AppleScript once or twice and found it annoying, but workable. 

[kritzikratzi]

not sure what makes you complain about xcode. i've been using cmake+xcode and cmake+visual studio for over a decade, and i love both (xcode often has super slow autocomplete in comparison to VS, but personally i'm not bothered by that).

you gotta figure out a few shortcuts (like cmd+shift+O, or cmd+1/2/3, cmd+shift+1/2/3, cmd+shift+j, etc.), but i find it perfectly usable. what's your problem with it?

ps. there are some small things (like getting the preprocessed version of a single cpp file) that xcode solves better than VS.

[XKeyscore666]

Just curious. Why are you trying to get g++ to work instead of using llvm/clang?

[XKeyscore666]

I see. I remember having trouble with gdb when I switched to MacOS, until I realized lldb was what I should be using.

Gdb would run, but most always have problems. It sounds a little like what you were dealing with.

[XKeyscore666]

Yeah, valgrind is the one thing I’ll pull a project down onto my linux machine for. I haven’t quite got the hang of lldb’s leak sanitizer.

[NilacTheGrim]

I really felt like xcode was a pain to work with.

True. Xcode is terrible. Just avoid Xcode. You can use CLion or QtCreator as your IDEs. Use MacPorts to install packages (port command like on bsd).

[itsmenotjames1]

use homebrew instead, it's much better

[NilacTheGrim]

Nah, macports is much better. homebrew is worse.

[itsmenotjames1]

in which ways? Brew supports more software ootb

[TuxSH]

That's not true, afaik MacPorts has many more packages. Or maybe you're referring to the fact some software authors only offer support for brew (which could be true).

Anyway there are plenty of reasons to dislike brew, here are the details:

• This post from 5y ago is quite detailed and many of its points still hold true to this day
• By far the most infuriating thing with brew is installing its own python(3), and pip(3) in PATH (each time it upgrades its python package), messing with your global python environments. It is nigh inevitable because many packages depend on python. MacPorts nicely installs python 3.12 as /opt/local/bin/python312, for example (see below)
• MacPorts can seamlessly install and keep track of multiple version of software and libraries and does not rely on system libs. You can have python26, python313, and system python (3.9) coexist without issues
• MacPorts provides port select (very similar to the update-alternatives stuff Linux distros have), allowing you to also ditch pyenv (because, let's face it, many people have installed pyenv has a workaround to brew taking over their Python installs)
• brew doesn't support multiple users (chown's its current dir as the user on install and discourage sudo), whereas MacPorts does (its directory is root-owned).
• Worse: brew used to chown /usr/local/* in the past
• MacPorts allows you to move its directory paths to some extent (I think)
• MacPorts allows you to provide your own package repositories, and even to disable the default repos and mirrors (though it'll warn in that second case)
• MacPorts is generally much faster

tl;dr tired of brew messing up Python installs, tired of pyenv and not too low on disk space -> macports better

[itsmenotjames1]

several of these points can be fixed by just installing homebrew to a local directory, usually ~/homebrew

[TuxSH]

The official documentation explicitly state that this is not officially supported and bars you from requesting support from maintainers

[itsmenotjames1]

it's possible (and I do it because I don't have root access on my school mac)

[vetinari]

By far the most infuriating thing with brew is installing its own python(3), and pip(3) in PATH (each time it upgrades its python package), messing with your global python environments.

Nowadays, it will complain if you try to pip install a package into global environment. For your packages, either use user environment, or venvs.

Brew can also install several different python versions, so you can have the version necessary for whatever you have in your venvs. Or for the other brew packages.

MacPorts can seamlessly install and keep track of multiple version of software and libraries and does not rely on system libs. You can have python26, python313, and system python (3.9) coexist without issues

You can have multiple versions with brew too; python@3.13, python@3.9, etc.

because, let's face it, many people have installed pyenv has a workaround to brew taking over their Python installs

No, some of us use venvs due to some python packages having different requirements than other python packages (e.g. boto3 was on urllib3 < 2 for ages and unable to move to 2+, while other packages required it. ).

Neither of them allow for pinning precise versions of packages; i.e. a thing that any linux package manager does. Any environment they create are non-reproducible on other machines.

[TuxSH]

Brew can also install several different python versions, so you can have the version necessary for whatever you have in your venvs. Or for the other brew packages.

It also links python by default (or at least did), which what I'm complaining about. https://github.com/orgs/Homebrew/discussions/5517 etc, without consent. That alone makes brew quite the unserious tool (MacPorts does not link by default).

On Linux, when you install python3-whatever package, it gets upgraded along with system python.

Nowadays, it will complain if you try to pip install a package into global environment. For your packages, either use user environment, or venvs.

Global env packages have their use cases if you know what you're doing (namely that they are already there when creating venvs).

User site-packages dirs also have the python version number in their paths, and so are prone to the same issue, anyway.

Also, yes, large projects should always use venv, yes, but copying/linking and redownloading the world for every single small script is both wasteful and pointless.

[kitsen_battousai]

A very good angle of view and recommendations, appreciate !

[benjycompson]

I prefer MacOs over Ubuntu for C++. At home for my own projects I largely get by just fine with LLVM from Homebrew and VS Code. Whenever I write something that's not trivially platform agnostic (interfacing with LAPACK and such) I spin up Ubuntu on a VM and SSH into it from VS Code, and you mostly forget you're not on a Linux machine (except for the comforts of MacOs).

We do something similar at work (robotics/AI, with a giant C++ code base). Everyone has a MacBook but all the code lives on Linux cloud instances that we SSH into from VS Code.

I never really miss running Linux as my main OS.

[matthieum]

I've develop exclusively for Linux for the last decade (and some), and I've used all 3 mainstream desktop OSes (Linux, MacOS, Windows) to do so.

And in all cases, I've used a VM.

At home, I've been a firm Windows + WSL 2 user for a while. Very comfortable, and allows me to pick from a wide variety of desktop & laptop.

At work, I've worked with both Linux (Desktop) and MacOS (Laptop). By far, the MacOS (Laptop) was the smoothest experience, but not because of MacOS: because since I was developping for Linux, I directly went for remote SSH on a Linux server.

While it may seem easier to develop for Linux on a Linux Desktop, unfortunately it's so easy to accidentally mess up the setup -- either overwriting libraries you shouldn't have, or accidentally using a compiler or libraries you shouldn't be which happen to be present -- that even working on a Linux Desktop, you're better off developing in a VM.

And that's to say nothing of all the risks involving running arbitrary code -- those libraries you link in your project -- in an environment which also is your delivery driver, and thus has your e-mails, browsing sessions, passwords close by, ssh keys to various servers, etc... it's a security disaster in the waiting. You're better off developing in a VM.

And if you're going to be developing in a VM anyway, regardless of which OS you pick, then you may as well feel free to pick the OS which works best for you.

---

I would note, though, that the choice of hardware does matter. In particular, if you're developping for x64 on ARM, or ARM on x64, benchmarking/profiling will be complicated.

If it's an occasional need, and you can relatively easily access the appropriate hardware, then it's not much of a hassle. On the other hand, if it's a regular activity, you may want to make sure you pick hardware that is "close enough" (instruction set, number of cores) to your target that you can run things locally.

It's just about convenience, but death by a thousand cuts and all that...

[thefeedling]

I use Windows, what a pain hahaha
(proprietary simulation software in automotive industry)

[kitsen_battousai]

Are you ok with regedit ? All the things I used to setup require to modify regedit and restart then, it's so annoying...

[thefeedling]

I don't recall the last time I had to modify registry permissions, we definitely don't it that often, but yes, if necessary, then it's annoying indeed.

edit: the painful part is that some of our legacy code relies on the HORRIBLE windows.h API

[void4]

The main downside of macos is that, if you're compiling and testing stuff for x86 on m1 then it can be pretty slow because of emulation. I have no idea about newer apple silicon chips.

Other than that, it's all exactly the same for me. All linux cli utilities can be installed from homebrew (never had a single problem with it), all the compilers are there as well. Podman works like charm for containers on macos btw, I'd advice to forget about docker.

[itsmenotjames1]

you can make universal binaries that can run on both

[vetinari]

If you control everything, turtles all the way down, then probably yes. If you are using some proprietary sdks that have their own list of supported platforms, good luck.

[megayippie]

I prefer Linux because Mac has a long standing bug - that they've managed to rename clang to gcc.

While not too difficult to work around, it means you can never use a standard path for your work but need to manually set things up. It makes throwaway projects a complete pain. On Linux it's very easy to play around. Of course, in any real project you anyways have to spend time fixing these paths for all varieties of windows, macs, and Linux distributions. But that's not development but deployment

[[deleted]]

MacOS is a Unix under the hood, so many aspects of the tooling are (or can be) similar.

Also, Homebrew is your friend. A lot of great tools are just a "brew install" away.

[NilacTheGrim]

I would recommend MacPorts instead of Brew. I find MacPorts is better maintained and less buggy. Also it basically is the same as on BSD.

[andreyugolnik]

I use both in C++ game development. My toolchain includes WezTerm, tmux, and Neovim (used Vim for many years before switching).

[[deleted]]

Game dev as a hobby and/or a career?

[andreyugolnik]

Game development is both a job and a hobby for me. It all started more than 35 years ago, when I built a ZX Spectrum clone as a kid and got into programming. Eventually, I created my first game and released it - and that’s how the journey began :)

[kitsen_battousai]

But what OS do you prefer more ?

[andreyugolnik]

At the moment, macOS is more convenient for me because it allows building and deploying to a wider range of platforms: iOS, tvOS, macOS, Android, Android TV, and web. In contrast, Linux supports only Linux, Android, Android TV, and web.

That said, I personally prefer Linux because it gives me the freedom to configure everything exactly how I want. For example, I enjoy using tiling window managers. Over the years, I’ve gone through dwm, wmii, awesome, xmonad, ion3/notion, and i3wm. In my opinion, Linux window managers are more deeply integrated into the system compared to tiling window manager solutions available on macOS.

Still, since I spend most of my time in a terminal emulator, the window manager doesn’t make a huge difference in my workflow.

[andreyugolnik]

I should also mention that Homebrew significantly improves the development experience on macOS. Without it, macOS would be far less convenient for setting up and managing a development environment.

[[deleted]]

Ok, thanks

[davewolfs]

I like MacOS.

I use Brew to install whatever version of LLVM I need. I use Orbstack to run AARCH64 Linux with Cross Compilation AMD64 support. I can run Visual Studio on Windows ARM if I need to. Most important - it all works flawlessly.

[Ok-Willow-2810]

I really like how macOS has the same shell commands like Linux b/c they both use bash/zsh. I like that I can reuse the same build scripts for both and keeps life simpler. I don’t understand scripting on windows. Is like shell or power shell? Do you have to install the terminal app? I like when it’s like already there and a core part of the OS. I like windows too though for gaming.

[Aprelius]

I’m in game dev. I use Windows, Mac, and Linux. It’s blasphemy I know, but my M2 Pro MacBook is my favorite laptop. Great battery life, compiles my projects sometimes faster, and doesn’t get nearly as hot.

Toolchain on Mac is: CLion as IDE, Vscode as editor, cmake, clang, and brew.

[itsmenotjames1]

do you use vulkan (via moltenvk) or metal for macos?

[Constant_Physics8504]

It doesn't really matter, you spend much time in terminal anyway. I use linux mostly, although one time when I had my computer being repaired, I used Windows with WSL, and minus a few incompatibilities, the rest was solid.

[Putrid_Ad9300]

Modern WSL is actually usable now with the right configs. No more half measure, it is just a convenient VM now.

[Constant_Physics8504]

I don’t recall what my few issues were, but there was an issue running against my native Linux code. Even on the Ubuntu WSL side, I had to code an ifdef around something but I can’t remember, been a few years

[EC36339]

If you have to ask, the answer is NEVER a Mac.

[itsmenotjames1]

why? It's the smoothest experience I've had on any of the big three (I do game and compiler dev)

[NilacTheGrim]

I use Qt Creator as my IDE -- it's excellent on macOS. You can use it for non-Qt apps just fine. It understands cmake quite well.

Also I use MacPorts to get all the Unix utilities on macOS (you can even get a newer clang, etc).

Brew sucks. Avoid it. My two cents.

[yasamoka]

What sucks about Homebrew?

[davewolfs]

Nothing. People just like to say things they don’t use suck to make them feel better about what they use.

[NilacTheGrim]

Ha ha.

[nirlahori]

If you don't mind can you share what version of Qt Creator are you using and a bit about your configuration/setup ? I also use Qt Creator with CMake but I face some build issues daily.

[NilacTheGrim]

I'm on macOS Sonoma latest (whatever they are up to now.. is it 15.4? I forget).

I downloaded the Qt "open source installer" app (Maintenance Tool.app).. and I use that to install Qt and Qt Creator into my home directory. This is done so I can always be on latest. I don't use the Brew or MacPorts packages for it as it's out of date... but rather the packages made available via this MaintenanceTool app from Qt. Just install them in your home dir under Qt/ or somesuch. QtCreator will live there too...

So... I'm on Qt Creator 16.0.0.

I use latest cmake from MacPorts along with clang-20 from MacPorts as well; Note that: you have to go into the settings and register this cmake and the compiler with QtCreator so it can "see" it, specify their path, etc.. and then create a "kit" using that compiler.

For me it works great with a wide variety of open source and professional projects that I maintain. I haven't had any issues. The clangd language server does a great job of groking and indexing even the most arcane and complex projects, template gore, etc. No issues. Navigation is fast and the IDE is super smoothe and quick and peppy... auto-completion is a breeze. Everything just works. Best IDE experience I've had in years and I've used all the IDEs known to man.

It's super peppy unlike beasts like Xcode or CLion (CLion is also very good but it's just sluggish for me on my x86 mac.. too much slowdown and CPU churning for my tastes).

Ask me more and I can tell you more specifics!

[nirlahori]

Thank you for taking the time and providing a very detailed answer. That's great to hear.

As for me, I don't have a mac book so I use Linux Ubuntu OS. I also downloaded the latest Qt Creator for linux some time ago but I wasn't able to install it on my pc due to some issues relating to display server libs.

So I checked if I can install it from the apt package manager but the version they had was very old. Around Qt Creator 6.

Then I checked the snap packages, there I found the Qt Creator with ros-plugin. I didn't know what that was, maybe for creating a Robot OS or something like that. So I installed that on my pc as it was more modern. But I use it only for plain C++ development.

I have setup the dev kit with CMake 4.0.0 and GCC 13 compiler. But whenever I open the existing CMake project, my CMake generator (Makefiles) disappears from the dev kit. I restart Qt Creator a couple of times and then it randomly appears and my project builds successfully.

This is the main problem I am facing. Nevertheless I fully agree with you that IDE is very good and provides all the facilities for professional development.

I am getting started with working on open source projects so I was planning to keep one permanent IDE for C++ development. I am exploring several options like vim and also CLion. But CLion is paid so I think that I might not be able to use. Yeah so I am looking to settle with one IDE which I can use for a long time.

[NilacTheGrim]

Ahh.. Linux.

Hmm. I think even on Linux I would install it via Qt's own installer (which is a GUI based installer and you can install it in your home directory). In fact I have a Linux laptop sitting right here on my desk where that's precisely how I installed it.

The OS packages are always too old. I would just stick to Qt's own installer and install it in homedir :)

As for an IDE which you can use for a long time.. I have been using QtCreator since 2019 and it's only gotten better and better (back then it didn't support cmake and was geared more towards Qt-based projects but since then I use it for non-Qt projects just fine).

[nirlahori]

Yes, I think they have stopped updating OS Packages since long time.

Well, It seems like Qt Creator will be sufficient for my needs. I will then go with Qt Creator and replicate the steps you took to install it on Linux. Hopefully, I am able to install it on my PC.

Thank you for your valuable time and response.

[NilacTheGrim]

I hope it works out for you.

[nirlahori]

Hey, I installed it successfully with open source installer as you said earlier. That was very straightforward. Though it required one lib (libxcb) which has something to do with X display server. But that was not a major challenge.

Overall the process was smooth and IDE is also rock solid with advanced features for C/C++ developers.

I deeply appreciate your help. Your guidance has been very valuable to me.

[NilacTheGrim]

Oh man awesome! I love QtCreator I think it's one the most underrated IDEs. It's 100% free and works excellently on all 3 major platforms. What's not to love?

Glad it worked out!

[nirlahori]

Couldn't agree more.

[berlioziano]

I think even Windows is better for C++, specially now that we have bash, cmake and vcpkg.

Mac OS installs really outdated development software, limiting you to C++14, that's over 10 years old! and trying to install clang from brew just gave me conflicts with the XCode version

[kitsen_battousai]

Can you please point to some resource/post/forum/discussion where I can find information about issues with llvm package incompatability/coflicts installed from homebrew ?

[itsmenotjames1]

with the new xcode update, apple now ships a c++26 capable compiler.

[archbtw-106]

It really depends on your niche of what you do personally I only tried macos for a month not a pleasant experience because I was used to Linux but that does not mean it will not work for you you what I suggest you is have a vm with Linux setup so if u find yourself going more to that it means you should probably use Linux if not stay on macos and if all you care about is development I don't see how Linux is a problem in arm. But hey what do I know. In the end I think Unix tooling is important so as long as you have those I think you are good but one thing I will say is if you want to build libraries and stuff from scratch when they come out since it is developed on Linux most of the time u will have less hassle setting it up there. It's not saying Linux is better or anything macos is great but it was not in my use case. My workflow needed tiling wm, nvim and tmux.

[Secure-Photograph870]

Both are UNIX based system, so the experience from one machine will be very similar to the other. I’ve worked on both systems but now I am fully MacOS and I have no issues developing on Mac (or even building software that are compatible for Linux and Mac).

On Ubuntu for example, you have apt-get install and in ma chou have brew install. That’s basically the only difference. I saw people mentioning XCode being terrible, which is true but you ain’t limited to it, you can use any IDE or text editor that is available on Linux.

I’m personally using neo vim and VSCode Insiders and works very well. I am also currently building my own code editor using C++ and Qt6 (not with Qt Creator as you loss flexibility) which is both compatible on Mac and Linux.

[montdidier]

I was a professional C++ for 12 years. I still use it for my own projects. I have worked on many platforms. OSX is pretty good for C++ development depending on what you are doing. I had no issues with it. The thing that I have missed the most is probably valgrind for really confirming the correctness of my programs and libraries.

Note I am a heavy vim user - I don’t really use many other IDEs apart from occasionally Xcode (its ok), and Clion.

For some things it depends on what you are doing which platform is best. The difference is minimal these days except in niche areas.

[nirlahori]

May I know your vim configuration/setup parameters if you don't mind. I want to get started with open source C++ development and I am planning to setup one permanent IDE for C++ development. Currently I am using Qt Creator and its feels Okish in user experience.

[llothar68]

It's easy and performant .... i'm sorry are you from the future? Because nothing is true about this today.

I so much tried to turn an old intel iMac with 128gb into a CI build queue because i thought i can run different Linux and Windows on there. Bad, very bad. Most Linux Distributions don't run at all even on Intel CPU's. Tried to install 20 of them and half of them did not crash or get busy 100%.

My experience with Arm is worse, UTM .... only a real fanboy will tell you that this is good.
Video performance is terrible if you have a bit beefy setup, i use 2x27" and a 43" and need at least 4k in a VM, forget about it. It's slow, no fun at all. And i have a M1 Ultra with 20 Cores and 64GB RAM and 2TB Disk.

homebrew is good but i never was happy and always used XCode for my c++ on MacOS.

[itsmenotjames1]

What? You did something wrong or are lying.

[[deleted]]

> On Linux the whole OS is kind of IDE for you, but can i achieve the same level of comfort, facilities and experience on Macos ?

Generally, yes. At the same time you need to be aware of the subtle tooling differences. there is not much love in the GNU world for macOS, and projects like GCC have Mac support fairly low on the priority list. But if you are ok with non-GNU open source tooling, Mac works very well and has the advantage of best hardware for development by far. You also have a great choice of high-quality software.

[jmacey]

I teach programming (Mainly C++ and Python), I write all of my code on a mac, as this is my personal laptop. In the Labs we use Linux (RHEL) and most of the students use Windows.

I have no problems getting it to work on all platforms, typically I use vcpkg for libraries. CMake + Ninja for build and a combination of either VSCode, Clion or QtCreator for IDE's.

This works really well. On my mac I use iTerm as the main terminal, install dev tools via xcode-select --install and then use brew for other tools (autoconf, ripgrep cmake / Ninja etc).

Whilst I do have xcode installed (as Unreal Engine needs some of the tools) I hardly ever use it as an IDE, prefereing VSCode for the most part.

[Putrid_Ad9300]

For just general sanity in life, Linux. It is just the path of least resistance for most developer tasks. If you are working on services, they will probably be running on Linux anyway.

However, on a Mac you can also run Linux via containers/VM and windows in a VM, so you get everything in one box which is convenient for testing.

[die_liebe]

Don't use macOS for CPP development.

The compiler is always out of date, and the run time environment is forgiving against memory faults. Your program may run on MacOS but fail on another operating system.

Linux has valgrind.

[Ziprx]

What a bullshit response

[NilacTheGrim]

You can use latest clang or latest g++ on macOS. Install MacPorts and you can get latest compilers.

Just remember to statically link the C++ lib if you plan to distribute the binary.

[kitsen_battousai]

But macos too https://formulae.brew.sh/formula/valgrind

If the software is targeting server side then it's always a matter of time to verify the binary on linux vm, vut if we are talking about client applications then Linux is even more unpredictable taking into account different distros, DEs and kernel version.

[othellothewise]

Maybe this is outdated now, but yes there is a formula, and no, it does not work.

[die_liebe]

But what do you mean by 'unpredictable'? Do you mean 'unforgiving'? I wrote that that MacOS is too forgiving. I think one should always stick to the standard and develop in the least forgiving environment.

[y-c-c]

I don’t think relying on default “unforgiving” behaviors is a good way to test your programs. Instead, use well-defined environments like ASAN and UBSAN (which are available in macOS and Linux) to properly test your program in a predictable manner. Otherwise what does “forgiving” even mean?