First, you may be able to accomplish all the key mapping you need via the stock system preferences on MacOS. Unlike, Windows, the Mac is very flexible when it comes to managing keyboard shortcuts.

Apple Menu -> System Preferences -> Keyboard -> Shortcuts. You'll see a list of the left side of the preference panel with a number of categories (Spotlight, etc.). The last item, "App Shortcuts", is where you can set your own shortcuts for all applications or specific applications. It's amazing that Microsoft still doesn't offer this in Windows 10.

Another *great* 3rd-party utility for the Mac, is Karabiner (formerly KeyRemap4MacBook). It will do very sophisticated key mapping -- probably on-par with AHK. However, if you want to do something simple, it may have a simple option built-in. For example, I use it to make the space bar behave as a the ctrl key when pressed with another key (saves the emacs pinky).

[OffTopic]
Why not start to get used to a PC?
OK, you're allowed to use your standard MAC keyboard [/OffTopic]

AutoHotkey Mappings to emulate OSX behavior with a Mac keyboard on Windows

This AutoHotkey configuration file makes usual keyboard shortcuts work with an Apple keyboard on Windows. It has been testet with a german keyboard layout, but should work under different layouts as well.

Unfortunately AutoHotkey cannot be used in macOS. In terms of ease of use vs complexity and capability, have a look at 2 built-in programs - Automator and AppleScript. After the debacle of Windows 10 I'm trying to wean myself off Windows now in favour of macOS (and Linux Mint Cinnamon) and have just started getting used to Automator first... drag'n'drop automation.

Automator is the natural choice in Mac , but it does not work inside the applications (like AHK can). For mac, there is the open-osource kantu desktop automation - it works quite differently then AHK, but does the same: autoamte mouse and keyboard

Is it possible to run the same AHK code written for Windows on a Mac by using a different software (e.g. Karabiner)?

I've heard you can do this by translating AHK via another common language, such as Lua. For instance have Lua "interpret" the AHK code by reading regular AHK code and then tranforming it into something Mac OS can understand. (untested on my end, so not 100% sure)

Is it possible to run the same AHK code written for Windows on a Mac by using a different software (e.g. Karabiner)?

I've heard you can do this by translating AHK via another common language, such as Lua. For instance have Lua "interpret" the AHK code by reading regular AHK code and then tranforming it into something Mac OS can understand. (untested on my end, so not 100% sure)

That sounds like a Transpiler or Source-to-Source Compiler, https://en.wikipedia.org/wiki/Source-to-source_compiler. Many other programming languages make use of such. It's interesting that this isn't being done for AutoHotkey. I don't know how well Lua works out as a cross-platform language. C#, Object Pascal, or Red would be good cross-platform candidates as well.

I think the other part of the issue is mindset. The thinking that AutoHotkey code must be married to C++ and Windows, instead of thinking of AutoHotkey as it's own language that could use other interpreters, written in other programming languages.

Additionally, it appears users in the past have ran Bootcamp and/or Parallels on their Macs to utlilize AutoHotkey - with success. The posts I have seen around the net do not appear to be doing any complex/advanced AHK programming, however, mostly doing simple key remapping as far as I can tell.

Would be awesome if someone could do some testing in this area to see what does/doesn't work. It seems like from lexikos' post that everything should work though. When I have some free time I may do some testing myself and report back

Usually the issues presented about AutoHotkey being on a different OS has been the Windows APIs and Dlls, where the code needs to be different for that OS. However, to make this a bit more complicated, there is WINE (https://en.wikipedia.org/wiki/Wine_(software). Open-source software that provides a Windows runtime enviornment for running applications on Linux and Macs. WINE has been discussed a number of times on the forums, example- https://www.autohotkey.com/boards/viewtopic.php?t=25741 (AHK installer under Linux/WINE).

From that forum post about the installer, what we are getting is that the present AutoHotkey developers are very Windows centric and lack any motivation to create a cross-platform version of AutoHotkey. And because they are so Windows centric, this can result in development choices that makes the AutoHotkey source code even harder to port over to a different OS. Though let's keep in mind that the Windows OS still holds a huge user base. The present AutoHotkey C++ interpreter, installer, etc... would have many "landmines", that I believe a person or a group would have no choice but to create a new fork (think IronAHK in C# as an example) or transpiler.

A person or group would likely have to focus on "translating" the AutoHotkey scripting language (not the C++ source code), and create a new interpreter. Preferably one in a more cross-platform friendly language (in terms of tools available), thus the suggestion of C#, Object Pascal, or Red. C# probably being a bit more easier for those that know C++ to adapt to, where Object Pascal is as almost as close to the hardware as C++, but has more cross-platform friendly tools (Lazarus, FPC, etc...). Object Pascal also has some AutoHotkey-like automation tools, such as Simba (often use for making bots) and WinAutoKey (so far a bit limited), that can provide example code. Red being more of a wildcard with future potential.

Going the way of the transpiler, would be more about translating the AutoHotkey scripting language into a compiled equivalent into another programming language. An interpreter would be running AutoHotkey in a way similar to how it runs on Windows, where a transpiler would be more specific to creating an application that could run on a different OS.

Though interestingly, it's not really known how far or what is the limit that somebody could get with AutoHotkey and WINE. Though I would think to make significant progress, it would likely turn into a fork.

True, but that doesn't have to be the case. I think it requires developers willing to go outside of the Windows OS and possibly knowing a programming language other than C++. Strong candidates would be Lua, C#, Object Pascal, Red, and maybe Dart.

In the case of Lua, I'm a bit surprised there has never been an attempt. I've never really dug into Lua before, as tend to look more at Object Pascal for anything extra, but was surprised by it's possibilities. Lua is also a scripting language, so a source to source compiler (transpiler), seems even more feasible. Lua already has multiple interpreters for different operating systems (like the macOS and Android). So looks to be easier to make an attempt than with C#, Object Pascal, Red, or Dart. With those languages, there would be more of tendency to attempt rewriting the C++ interpreter of AutoHotkey to the different language, which would be a very significant task. This was the case with the now abandoned IronAHK project, which attempted to make a C# interpreter instead of using the C++ one.

Where with Lua, it appears an attempt can be made to transpile the AutoHotkey language to the Lua language directly, not the C++ interpreter. Somewhat of an example of this type of thing is CoffeeScript to JavaScript. In doing so, you could decouple some of the Windows centric thinking because there can be different "translations" of what the Lua code will do, depending on the OS. Tigerlily's suggestion about using Lua, might be worth looking deeper into.

If I remember correctly, IronAHK is supposed to work on platforms outside of Windows if I'm not mistaken.
Either that or I'm making sh*t up.

Yes, IronAHK could work on different OSes. This is because of .NET and Mono, and Microsoft's (and the company they bought, Xamarin) push to make C# cross-platform. But part of the problem with IronAHK, and part of why it was never finished, appears to have been a major fight between the developers and the AutoHotkey websites. There is possibly still a lot of bad feelings, so IronAHK went untouched. To include that it requires developers to switch focus from C++ and Windows centric, to C# and cross-platform development, which is harder to do.

Possibly with Lua, things might be a bit easier. Less focus on creating a new C++ interpreter or one in a more cross-platform friendly language (like C#, Object Pascal, Red, Dart), and more focus on "translating"/transpiling scripting language syntax and functions from AutoHotkey to Lua. Lua already has multiple interpreters for different OSes. I'm guessing there are probably way more people that know Lua well enough to attempt an AutoHotkey to Lua transpiler than they are C++ experts at or near developer level or people capable of writing a new interpreter in another programming language for a different OS.

Though it might be a matter of preference, one does have to overcome the eye burn of Lua syntax. It also falls in the bad taste category of Python, where it thinks it's cute not to use any curly brackets for the clarification of code blocks. Particularly for large programs and to help avoid problems with indentation mistakes. Still, seems like Lua might be a good chance for a "cross-platform" version of AutoHotkey.