TL;DR

Many people start coding and wonder if they have to be a math genius. The short answer is: Not really! Most coding jobs rely more on logic and problem-solving than on complex math. Beginner-friendly programming (like building websites or apps) usually only needs basic arithmetic and clear thinking. In fact, writing code is often more like writing in a foreign language than solving equations . In other words, you can absolutely write code without deep math skills.

However, it’s also true that software engineering spans many areas, and some roles use more math than others. We’ll walk through the spectrum of developer jobs, from low-math to high-math, and explain how math skills help along the way. We’ll also see that logic and problem-solving are really the core of programming, so even without a heavy math background you can have a successful coding career.

Low-Math and High-Math Engineering Roles

Software engineering isn’t one-size-fits-all. Different roles need different math levels. At one end, web developers, mobile app builders, and QA/testers mostly do practical tasks with little math. They use programming languages, frameworks, and libraries, but rarely use advanced math in their day-to-day work. For example, front-end web developers often work with pixel dimensions and layouts. They might use basic geometry or algebra (e.g. calculating a column’s width or form field size), but that usually just involves simple arithmetic . DevOps engineers and QA testers likewise focus on processes, debugging, and automation, not math formulas. In this low-math category, the biggest math you’ll do might be gentle estimations (like how many users a system can handle) or basic statistics (like understanding an A/B test result).

On the other hand, some fields demand heavy math. Think game development, graphics, machine learning, data science, and cryptography. In game and graphics programming, you constantly deal with vectors, matrices, and physics. You need linear algebra to transform 3D objects and geometry to calculate collisions. Game engines often simulate forces, gravity, or light, which involves calculus and physics equations. Likewise, an AI or machine learning engineer must use linear algebra, calculus, and statistics to build and train models . Even building something like a recommendation engine or image recognizer relies on advanced math under the hood.

Between those extremes are many mid-level roles. Back-end web developers (server-side) might use a bit more math than front-end. They often query databases (calculating totals or averages) and might handle algorithms with moderate complexity. They should know basic algebra and maybe some geometry or even basic calculus to understand certain formulas or performance estimates . Mobile developers fall in between: if an app has no heavy computation, you might hardly touch math at all; but if you build something like a navigation or finance app, you’ll use trigonometry or statistics depending on the feature . Data engineers and analytics engineers use more statistics and probability to process data, but often rely on libraries and tools for the hard work.

You can think of roles from least math to most math like this:

• Low math: Front-end web developer, UI/UX designer, QA/testing, technical support. These focus on code, design, and tools, and “no special math course” is needed.
• Some math: Back-end developer, mobile app developer, DevOps engineer. You use basic algebra and logic for things like formulas, database queries, or simple physics for animations.
• More math: Systems programmer, embedded systems, cybersecurity specialist. You might need discrete math (logic, bitwise ops), number theory, or signal processing math.
• High math: Game/graphics developer, ML/AI engineer, data scientist. These need linear algebra, calculus, probability, stats every day. Cryptography experts need number theory and abstract math. Also, computer science researchers or algorithm developers (often in academic or R&D settings) use the most math of all, designing new algorithms or proving things with discrete math and proofs.

The level of math required varies by role. Some projects need extensive math while others need none at all . In fact, many web or app projects simply never touch advanced math. Instead, they rely on libraries to handle any heavy lifting. Writing code is no math at all! no need to take a special course about math for software engineers.

How Math Skills Help Software Engineers

Even if you don’t need calculus every day, math is still a helpful tool in many areas of software engineering. Understanding math can make you a sharper problem-solver and open doors to advanced fields. Here are some ways strong math skills pay off:

• Algorithms and efficiency: Algorithms often use discrete math concepts. Sorting, searching, and graph algorithms rely on logic and combinatorics. Analyzing an algorithm’s speed means using mathematical concepts like Big-O notation (which is about functions and growth rates). For example, to optimize code, a math background helps you improve the performance of systems and make solutions scalable. When writing loops or recursive functions, you implicitly use math to figure out how they grow with input size. Discrete math (logic, sets, graph theory, recursion) is foundational in programming for making sure code is efficient.
• Game graphics and simulations: If you venture into game development or simulations, math is crucial. Modeling a 3D world on a 2D screen is literally a math problem. You need geometry and linear algebra to handle rotations and 3D projections. Physics engines use calculus and algebra to simulate movement and forces. For example, to simulate wind resistance or gravity you solve differential equations. Math-savvy developers can create more realistic games and graphics.
• Machine learning and data science: Building neural networks or data models is math-heavy by nature. ML engineers use linear algebra (to handle matrices of data), calculus (for optimization like gradient descent), and probability/statistics (to model uncertainty). Without these math tools, they can’t truly understand or innovate in AI. Math helps in creating new models. Knowing advanced math and statistics will allow you to create new ML models.
• Cryptography and security: Modern encryption is built on number theory and modular arithmetic. If you work on security features, you will eventually use math to encrypt and decrypt data. Learning math principles like prime numbers and modular math is essential for cryptography.
• Data analysis and optimization: Many developers do at least some data crunching or performance tuning. Math helps you analyze numbers (like understanding metrics or logs) and optimize code. For instance, when balancing server load, you might do capacity planning calculations; a background in math makes you confident in those estimates. Engineers apply math to optimize systems, make algorithms efficient, and ensure designs can handle large-scale problems.
• Logical thinking: Beyond specific topics, studying math trains your brain to think logically. Math classes teach you to break a problem into steps and prove why a solution works. This logical mindset is invaluable in coding. Learning math sharpens your ability to approach complicated problems using logic, which directly improves your programming skills. The reasoning used in math is very similar to the reasoning in software engineering. In fact, someone who enjoys solving math puzzles or logic problems will find that programming feels natural because it’s all about applying rules and logic to produce a result (much like composing music or writing code).

Strong math skills help when you need them. They let you design better algorithms, tackle specialized fields, and understand the “why” behind advanced techniques. But for everyday coding tasks, those advanced topics are optional. Even if advanced math isn’t used on the job, the thinking skills gained from math (logic, structured problem solving) are always useful.

Building a Career Without Heavy Math

What if math isn’t your strength? Don’t worry! Plenty of successful software engineers have thrived with only basic math. In fact, many developers don’t have a math degree or any college math beyond high school. They learned to code through bootcamps, self-study, or non-traditional paths, focusing on programming practice and projects.

You don’t need to be good at advanced math to become a good software developer. Basic math like order of operations and simple algebra suffices, because most math-heavy work is already handled by programming languages and libraries. In coding you really need a basic working knowledge of math (order of operations, basic algebra) and knowing how to use built-in math methods. In practice, software engineers rely on math for tasks like adding numbers, comparing values, or using library functions, things we learn in middle or high school.

Moreover, daily coding often feels more like writing a story or composing music than solving equations. The key is to break problems into logical steps and test your code, not to derive new mathematical formulas from scratch. Many beginners find that they use math only for simple tasks: estimating project effort, tweaking variables, or understanding runtime of loops (Big-O). For example, Some occasional math-related tasks are as follows: rough system load estimates, analyzing an A/B test (stats), a little probability, or thinking about Big-O notation. These tasks use only basic math and logic, not calculus.

And companies agree! Most software jobs expect only fundamental math skills. Practical programming requires attention to detail, clear thinking, and creativity rather than heavy math. Frameworks, libraries, and even Google and AI are there to handle any tricky math you encounter. If a problem really does need math, you can usually learn just that piece on the spot.

The essence of programming is logical thinking and problem-solving. With that approach, even a background in non-STEM fields (philosophy, writing, arts) can produce great coders. In short, don’t let math anxiety stop you. You likely already have the math you need: arithmetic, logic, and a dash of algebra. Focus on building projects, learning to think in code, and practicing problem-solving, and you’ll advance in software engineering just fine.

Academic vs Industrial Contexts: Who Uses More Math?

It’s also useful to distinguish academic computer science from industry software engineering. Academic CS (or research) is math and theory heavy. It’s about understanding fundamental principles: algorithms, computational complexity, machine learning theory, etc. A CS degree typically requires courses in calculus, linear algebra, discrete math, probability, etc. In other words, computer science as a field delves into “why things work”, and that’s grounded in math. Many CS grads go into research, AI, security research, or theoretical work. In academia, you might design new algorithms or prove the limits of computation, jobs that do require strong math.

By contrast, industrial software engineering (working at tech companies) is more practical and application-focused. The goal is to build products and services: websites, mobile apps, business software, etc. In other words, computer science (the degree) requires a lot of math. Software engineering (the career) usually requires much less math. Industry roles emphasize tools, frameworks, teamwork, and shipping working code. Typical developer jobs (front-end, back-end, full-stack, mobile) use the essentials of computer science but rely on creativity and code craftsmanship more than advanced math.

That isn’t to say industry engineers never use math; they do use logical thinking and sometimes basic algorithms. But they generally aren’t proving theorems or deriving formulas. In fact, many software engineering educational programs are project-based and hands-on, covering only the math needed for the job. And there are many pathways into industry (such as coding bootcamps or self-learning) that skip heavy math entirely, focusing on programming skills and problem-solving.

Academic CS = math-heavy, theoretical; industry SE = applied, practical. If you’re passionate about inventing new algorithms or researching AI theory, math will be front and center. But if you want to build apps, websites, or consumer software, basic math (algebra, logic, arithmetic) plus your coding know-how will take you far.

Conclusion

In the end, you don’t need to be a math genius to become a software engineer. For most developers, especially beginners, basic math is enough. The real focus is on learning to think logically, solve problems step-by-step, and write clear code. Math is a helpful tool in certain specialties (like graphics, ML, crypto), but it’s not a barrier to entry in programming. Programming relies on problem-solving skills and built-in tools, not constant calculations.

If you’re starting out, use whatever math you know to your advantage. Arithmetic, logical operations, and simple algebra. Don’t let math anxiety stop you! The programming community welcomes people with diverse strengths. With practice, curiosity, and persistence, you can build a great software career. And who knows? Along the way, you might even start to enjoy some of the mathematical ideas too, now that you see them in action in your own code.

Sources

• EducatingEngineers.com: “How Much Math Do You Need for Computer and Software Engineering?” (Nov 2024)
• Codecademy Blog: “Can You Be a Software Engineer Without Strong Math Skills?” (2024)
• Institute of Data: “Does Software Engineering Require Math? A Comprehensive Guide”
• Brett Fazio (Medium, Better Programming): “You Don’t Need Math to Be a Software Engineer”
• Educative.io: “How much math do you need to know to be a developer?” (July 2022)
• BloomTech (Fullstack Academy): “Does Coding Require Math? The Answer Might Surprise You” (July 2022)
• Intuit Blog: “What’s the difference between software engineering and computer science?” (2025)
• TripleTen Blog: “Does Software Engineering Require Math Skills?” (2024)

What is a JIT Compiler?

Meet Mr. Speed Booster: The JIT Compiler. He doesn’t wait until your code is done cooking. Nope. He jumps in while your program is running, turning it into blazing-fast machine code just in time for execution. Hence the name: Just-In-Time!

Imagine you’re talking to someone who only understands a secret language. You can either:

• Translate everything before the conversation (like a regular compiler), or
• Translate line by line as you speak (like an interpreter).

A JIT compiler is the genius friend who listens, figures out what’s being said most often, and starts translating those parts perfectly on the fly while you’re still talking. That’s JIT compilation. It compiles code while the program is running, not before.

In programming terms: a JIT compiler takes your program’s intermediate code (like Java bytecode or .NET IL) and compiles it into real machine code during execution. The goal? To mix the speed of compiled languages with the flexibility of interpreted ones.

Languages like Java, C#, and JavaScript (V8 engine) all rely heavily on JIT compilers. The JIT watches what your code does, finds the “hot” parts (the functions that run a lot), and compiles those into fast native code. The result? A program that keeps learning and optimizing itself as it runs. Pretty smart, right?

Why Do We Even Need a JIT?

Let’s break it down into bite-sized reasons:

1. Speed Boost

JITs take code that would normally be interpreted and compile it into native CPU instructions while the program runs. So, instead of reading instructions one by one, your CPU can just execute them directly, way faster.

2. Adaptive Optimization

A JIT compiler doesn’t waste time compiling everything at once. It monitors which functions or loops are executed often (a.k.a. hot code), and only compiles those. If a function gets even hotter over time, the JIT can recompile it with smarter optimizations.

3. Perfect for Dynamic Languages

Languages like JavaScript and Python are constantly changing types and doing runtime checks. A JIT can handle these dynamic behaviors gracefully, because it compiles code as it goes, adjusting for real runtime conditions.

4. Cross-Platform Flexibility

Java and C# ship platform-independent bytecode. Then, each machine’s JIT compiles that bytecode into the native instructions of that CPU. So, one .class file works on both Windows and Linux, but still runs at native speed.

The Trade-Offs (Because Nothing’s Free)

Every hero has a weakness, and the JIT is no exception:

1. Startup Delay

Compiling during runtime takes CPU time. If a JIT tried to compile everything at startup, your app would open like a sleepy turtle. That’s why JITs are smart — they start with interpreted code and compile only when needed.

2. Limited Optimization Time

JITs can’t afford to spend 10 minutes analyzing your entire codebase like a C compiler does. They focus on quick, practical optimizations; enough to get good performance fast.

3. More Memory Usage

Every piece of generated machine code lives in memory. On large, long-running programs, this adds up.

Think of it like cooking:

• Interpreter: Fast food => instant but not fancy.
• AOT Compiler: Gourmet meal => slow to prepare, perfect results.
• JIT Compiler: Omelette on demand => fast, fresh, and tailored for you.

How Does a JIT Compiler Actually Work?

Let’s go step by step through the JIT’s secret recipe:

1. Load & Interpret

The runtime starts reading bytecode or intermediate code. It might interpret it first for quick startup.

2. Profiling

While running, the runtime tracks which functions or loops are used the most.

3. Trigger Compilation

When something becomes “hot,” the JIT decides to compile it.

4. Machine Code Generation

The JIT converts the hot code into native CPU instructions. It might also inline small functions or unroll loops for extra speed.

5. Install & Execute

The compiled code is placed in executable memory, and the runtime jumps straight to it. From now on, that function runs natively!

6. Re-Optimize

If it keeps getting hotter, the JIT might compile it again with even better optimizations. Some JITs even discard old compiled code when memory is tight.

At the CPU level, what’s happening is simple:

The JIT writes machine code bytes into memory, marks that memory as executable, and then runs it. Just like calling a regular function.

Here’s a minimal C example that mimics what a JIT does:

#include <stdio.h>
#include <sys/mman.h>
#include <string.h>

typedef int (*func_t)(int,int);

int main() {
    // Imagine these bytes represent compiled machine code for:
    // int add(int a, int b) { return a + b; }
    unsigned char machineCode[] = { /* ... machine code bytes ... */ };
    size_t codeSize = sizeof(machineCode);
    // Allocate a read/write/execute memory region
    void *buf = mmap(NULL, codeSize, PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_PRIVATE | MAP_ANON, -1, 0);
    memcpy(buf, machineCode, codeSize);
    // Cast and call it like a function
    func_t add = (func_t)buf;
    int result = add(3, 4);
    printf("3 + 4 = %d\n", result);
    return 0;
}

Here, we use mmap() to create executable memory, copy some machine code into it, and then call it like a regular function. That’s literally what a JIT compiler does behind the scenes; it builds and runs code on the fly.

JIT vs. Interpreter vs. AOT Compiler

Most modern languages like Java, C#, and JavaScript, actually use a mix of techniques. They start by interpreting code for fast startup, then JIT-compile hot code for maximum performance. This is called tiered compilation.

When and Why to Use a JIT

• Runtime Environments: Perfect for VMs like JVM or .NET CLR.
• Dynamic Languages: Ideal for JavaScript or Python (e.g., PyPy, V8).
• Game Engines or Emulators: They can translate instructions dynamically and optimize them.
• Big Data Systems: JITs like those in Apache Spark speed up repeated computations.

If you ever want to write your own JIT (which is a fun challenge), check out tools like LLVM or GNU Lightning. They handle most of the heavy lifting — you just focus on what to compile and when.

Final Thoughts

A Just-In-Time Compiler is like having a translator who learns as you talk.

It listens to your program, finds the important parts, compiles them right when you need them, and keeps making them faster the more you run them.

It gives you the speed of compiled code and the flexibility of interpreted code, all rolled into one.

In simple terms:

A JIT takes some memory, writes machine code into it, and executes it like magic.

Understanding it isn’t hard, it’s just a clever trick that turns time into performance.

Now you know the secret sauce behind how modern languages get so fast.

When someone mentions “JIT Compiler,” you can confidently say,

“Oh yeah, that’s Mr. Speed Booster doing his thing.”

Sources

1. https://stackoverflow.com/questions/219323/difference-between-just-in-time-jit-and-interpretation
2. https://en.wikipedia.org/wiki/Just-in-time_compilation
3. https://stackoverflow.com/questions/627132/what-is-a-jit-compiler
4. https://blogs.oracle.com/javamagazine/post/jit-compiler-java
5. https://stackoverflow.com/questions/29784125/what-is-a-jit-compiler-how-does-it-work
6. https://stackoverflow.com/questions/70348619/creating-jit-code-at-runtime-in-c
7. https://stackoverflow.com/questions/46818642/how-to-execute-machine-code-generated-at-runtime

Introduction

A computer’s CPU, which is responsible for running your code, doesn’t understand JavaScript, Go, C++ or any other high-level programming languages that we know. These high-level languages, are basically some layers of abstraction, made by computer programmers and engineers, so speaking to a computer becomes easier for us as humans.

What is a Compiler?

A CPU, and computer’s hardware in general, only understand zeros and ones, which we technically refer to as binary code. The reason behind this is that a computer’s hardware is basically made out of billions of transistors, which can only have two states: on or off. These “on” and “off” states are represented with zeros and ones; 1 meaning on, thus the electrons pass through, and 0 meaning off, which stops electricity from passing through a transistor. Literally everything that a computer does, is made possible by these on or off states of those tiny transistors.

Now, compilers are fascinating tools that transform the high-level code written by programmers, which is more easily readable by humans compared to zeros and ones, into binary code language that computers understand.

At its core, a compiler is like a translator. Just as a person might translate Spanish into English, a compiler translates the code written in a high-level programming language, into machine code (binary code).

But How Do Compilers Work?

The process of compilation, which is the name of what a compiler does under the hood, involves several stages. Here we take a brief look at each of these stages, all with real examples:

1. Lexical Analysis: This is the first step where the compiler breaks down the code into basic elements or tokens. For example, in the line String greeting = "Hello";, the tokens would be String, greeting, =, "Hello", and ;​.

2. Syntax Analysis: Here, the compiler uses the tokens to build a structure called an Abstract Syntax Tree (AST), which represents the logical structure of the program. This step checks the grammatical structure of the code and looks for syntax errors​. If an AST’s structure becomes invalid, the compiler immediately knows that the original code had a syntax error, and in most cases it knows exactly where the error is coming from.

3. Semantic Analysis: The compiler uses the AST to detect semantic errors, such as assigning the wrong type to a variable or using a keyword as a variable name. This stage includes type checking, flow control checking, and label checking​.

4. Intermediate Code Generation: The compiler generates an intermediate code that is machine-independent; meaning that it can be used on any hardware later on to generate the final binary code for that specific machine. This also means that the code can be easily translated into the machine code of any target machine. The intermediate code can be either high-level, similar to the source language, or low-level, closer to machine code​. Now you might ask, if the generated intermediate language may be sometimes similar to the source code or another high-level language, what is the need for generating it at all? Can’t we just make the original source code machine-independent? The answer is pretty easy: The compiler does that so it can optimize the code way more easily, make sure that the code has the least amount of dependencies to your current hardware, and the complexity of designing a compiler decreases.

5. Optimization: In this phase, the compiler makes the code more efficient without altering its meaning and purpose. The optimization focuses on consuming fewer resources and speeding up the operation of the software​. This is where the intermediate language that was generated in the previous step becomes really handy! In the upcoming example, the original source code written in C was this:

Then it was used to generate the intermediate code, which consists of a highly inefficient loop, and then was optimized by the compiler to eliminate the problematic part:

6. Code Generation: Finally, the compiler converts the optimized intermediate code into the machine code specific to the target machine. This code should be efficient in terms of memory and CPU resource usage​. This is actually where the compiler does its magic! It knows if your CPU understands Spanish Binary (which is a word that I just made up to make it easier to understand) or English Binary. Our Mr. Translator knows exactly what each of those words of the intermediate language mean in the binary language of your own CPU. How? By examining and using the actual hardware that you’re using, and sometimes some of the high-level APIs that are accessible from the operating system itself.

Advanced Resources

The overall process of a compiler design isn’t really hard to understand. But if you want to get deep and actually design a compiler yourself or even contribute to an already-existing compiler, you definitely need more advanced knowledge about each steps. Here, I include some resources that I think they may be helpful for the advanced readers. I haven’t studied all of them myself, so please do your own research before actually studying any of them:

• Compilers: Principles, Techniques, and Tools” by Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman, often referred to as the “Dragon Book”.
• “Engineering a Compiler” by Keith Cooper and Linda Torczon.
• Online courses on platforms like Coursera, edX, and MIT OpenCourseWare, which often feature in-depth lectures and materials on compiler design.

If you’re really into designing a compiler, I suggest you start with reading the code of open-source compilers. This gives you a clear vision of what is exactly going on under the hood. Also by contributing to these open-source compilers, you’re not only helping yourself learn more by getting your hands dirty, but also helping a lot of people out there who are actually using those tools! That’s how we, as software engineers, have each other’s backs. :)

Sources

https://www.baeldung.com/cs/how-compilers-work

• Introduction to Compiler
• What is a Compiler? Compilers in C Explained for Beginners

Introduction

In macOS, the folder structure is integral to understanding how the system organizes files and applications. For many of us, knowing the correct path for everything is only to fulfill our sense of curiosity. However, for some people, specially programmers and software developers, knowing what is where in their computer means more than that.

Why Am I Writing This?

As someone with a keen interest in this operating system, I spent some time understanding the correct folder structure of a Mac system and gathering this information all in one place, so you don’t have to. :)

Please note that all these data are subjective to change. If you find anything missing, or stated incorrectly, please let me know in the comments and I will fix them for the next fellow Mac user who’s reading this.

Enough Talking. Let’s Dive In!

Here’s a detailed list of what you need to know:

• Applications: This folder contains all the applications installed on your Mac, such as Mail, Calendar, Safari, etc. These apps are also accessible through Launchpad​. Any new apps that you install, will end up here.
• Library: This is where fonts and other items used by applications are stored. It’s accessible to all users on the Mac and is not intended for personal file storage​. Some of the apps store the files that they need to function with in this directory.
• System: This folder houses the macOS operating system itself. You cannot change its name, location, or contents​.
• Users: It contains the home folders of all users on your Mac. Each user’s home folder is represented by a house icon when logged in. It also includes a Shared folder for items available to all users​.
• Home: Named after your username, this folder holds your personal files and folders, such as desktop files, downloads, pictures, documents, movies, music, and public files. You can create new folders here​. This is where you mostly work in. Well, usually.
• Developer: Appears only if Apple’s Developer Tools are installed, containing tools, documentation, and files for development​. (If you’re planning to make and publish apps for macOS, iOS, or any other Apple devices.)
• Network: Contains network-related devices, servers, libraries, etc​.
• Volumes: This directory includes mounted devices and volumes, such as hard disks, CDs, DVDs, DMG mounts, etc​.
• Root Directory (/): The topmost directory in macOS, parent to all other files and directories​.
• Bin (/bin): Holds essential common binaries necessary for booting the operating system and its proper functioning​. (Not the OS itself)
• Etc (/etc): Contains local system configuration files, including administrative and system files​.
• Dev (/dev): Includes device files representing peripheral devices like keyboards, mice, and trackpads​.
• Usr (/usr): A major hierarchy containing subdirectories with information, configuration files, and other essentials used by the operating system​.
• Sbin (/sbin): Contains essential system binaries and utilities for system administration​. Somehow similar to Bin (/bin).
• Tmp (/tmp): A directory for temporary files and caches​.
• Var (/var): Holds variable data, which includes files whose contents change as the operating system runs​.
• Opt (/opt): This directory is typically used for installing optional software packages that are not part of the core operating system. It provides a location for add-on software that is not managed by the package manager of the operating system. For example, third-party software like Homebrew may install packages under `/opt`. [UPDATED on 2024/05/11 — Thanks to PyProcrast for their comment.)

Now this, specially the part that contains /bin, /usr, /tmp etc. may trick you into thinking that these are the same as a Linux operation system. While your guess is not incorrect, it’s not totally correct neither. Let’s see how.

How macOS and Linux Differ?

Both macOS and Linux are UNIX-based operating systems, and their file structures share similarities. Like macOS, Linux also has a hierarchical tree structure starting from the root directory (denoted by a forward slash /). However, Linux treats everything as a file, including external devices, and allows files with the same name in the same directory if they use different cases, which is not the case in macOS.

Sooo, Why Is It Called “A Closed OS” Then?!

If the folder structure in macOS is very much similar to Linux and other Unix-based systems, then why is it called “A Closed Operating System”?

Well, the answer is, that’s not directly related to the folder structure. macOS is often referred to as a closed operating system compared to Linux, but for these reasons:

• Source Code Accessibility: macOS, developed by Apple, is proprietary software. Its source code is not publicly accessible, unlike Linux, which is open-source and allows users to view, modify, and distribute its code.
• Customization and Control: macOS offers limited customization options compared to Linux. Linux users have more freedom to alter the system’s core functionalities, including its kernel, which is not possible with macOS.
• Software Ecosystem: Apple controls the macOS software ecosystem tightly. This includes restrictions on software installation sources and stringent app store policies. Linux, conversely, supports a wide range of software from various sources without such restrictions.
• Hardware Compatibility: macOS is designed primarily for Apple hardware and is not officially supported on non-Apple hardware. In contrast, Linux can be installed on a wide variety of hardware platforms, including Apple hardware.

Thus, the “closed” nature of macOS stems more from its proprietary, controlled approach to software distribution, customization, and hardware compatibility, rather than its folder structure or file system organization.

Conclusion

Understanding the macOS folder structure is crucial, especially for new users transitioning from other operating systems. I hope this guide could serve as a comprehensive overview for anyone new to macOS, providing insights into how the system organizes and manages files.

Sources:

• Folders that come with your Mac
• Mac OS X Directory Structure explained
• The Differences Between Mac, Windows, and Linux (2021 Update) - ShiftWeb

Overview

Channels are here to solve the concurrency problem in GO! They’re basically some bunch of pointers as well that hide the hardness of implementing FIFO queues under the hood to read from and write to.

Concurrency, You Say?

Yes! Concurrency is when you want to run more than one block of code at the same time. Concurrent jobs in GO are called goroutines and GO, under the hood, is very efficient when it comes to concurrency as it sends each job (block of code) to a different CPU core to be executed as a completely separated thread. This is unlike some other programming languages like Javascript that your entire program gets run on only one single thread thus they can’t take advantage of multicore systems, making them not very efficient when it comes to concurrent jobs.

How To Run Something In A Concurrent Manner?

Say go before it. Yup! That simple! When you wanted to run a function in the usual synchronized way, you’d simply say it’s name like myFuncName(). Now if you want to run it in an asynchronized manner, just say go myFuncName() and it’ll be sent to it’s own thread to be executed, thus it won’t block the next lines of codes that come after it to get executed like it did in the synchronized way. Now if you want to know that how concurrency helps to solve some major problems in programming, you’re a Google search away from your answer.

So What Are Channels?

Channels, in appearance, are basic variables that work like a FIFO queue. However, their syntax is a little bit different than simple variables. At the first glance they might look a little hard to grasp but believe me they’re not that hard. As soon as you know how do they work, you’ll get addicted to using them left and right! The idea of the Channels is to solve the mutual exclusion issues when working in an asynchronous way by reversing the dependencies. Read this sentence carefully a few times to understand how Channels do such job:

Instead of trying to establish the communication across your application by sharing the memory, Channels try to share the memory by establishing the communication across your application.

It might sound hard a little bit but it’s really not. As you get more familiar with them you’ll see this yourself in action.

So, How Do They Work?

We have receive-only Channels, which you can only receive (read) values from them, and we have send-only Channels, which you can only send (write) values to them, and we have receive/send Channels which you can perform both of the operations on them. Based on your use case, you can decide which one to use. For example if your function only wants to read the value from the Channel and never intends to write a value to it, you may want to pass your receive/send Channel as a receive-only Channel to your function to prevent logical errors. But what is really happening with Channels is that when you try to read from a Channel, GO will wait for a value to be written to it if there’s no values inside it already. And if there are multiple values inside a Channel, GO will pop the first value that is sent to it and gives it back to you when you try to read from it once. (Hence the FIFO structure) It means that the second time you try to read, you’ll get the second value. So any written values to a Channel can be read only once, and after that, the value is gone. Try to think of it as a tube; A block of code pushes a value inside the tube. The other end of the tube is where you can receive the value from it. But once you get the value out of the tube (read it) it’s not inside the tube for anyone else to receive anymore. Now if you try to read from a Channel that you never send to it anywhere inside your code flow, GO’s compiler will complain that it is a deadlock, because it waits for an infinite time for a value to be sent inside the tube but it never happens. Thus the next lines of code will never be executed and GO is very intelligent finding where the things are going wrong.

Syntax! Shall We?

Since the syntax of the Channels is a little bit different than simple variables, it’s a good thing to know it before we see them in action.

The birth of a Channel:

# The "CHANNEL_TYPE" can be any type that we already know
# But it should be prefixed with "chan"

myChannelName := make(chan CHANNEL_TYPE)

Writing (sending) to a Channel:

# the "VALUE" should be of the type that the Channel is made of
# It's basically saying "send the value inside the tube (queue-Channel)"

myChannelName <- VALUE

Read from a Channel:

# Get the latest value of a Channel in a Variable

myVariableName := <-myChannelName

# OR use the value directly. Either way it's now popped out of the queue

fmt.Println(<-myChannelName)

Note the <- that does the read and write operations on Channels based on whether it comes before or after the Channel’s name respectively.

Typing a Channel as an argument:

# Receive/send Channel

func myFunctionName(myChannelName chan CHANNEL_TYP) {

# Now you can perform both read and write ops on the Channel
  ...
}

# Receive-only Channel

func myFunctionName(myChannelName <-chan CHANNEL_TYP) {

# Now you can only receive (read) values from the Channel
  ...
}

# Send-only Channel

func myFunctionName(myChannelName chan<- CHANNEL_TYP) {

# Now you can only send (write) values to the Channel
  ...
}

Aight we good. Let’s see the code.

Code.

The result should be:

144

Some important notes about the above code:

• The Pow function that comes from the built-in math package simply powers it’s first argument by it’s second argument. Both arguments should be of type float64 and so the result.
• As you can see in the code, if you run two goroutines at the same time and they’re dependent, you’ll run into a race condition! Be very careful with this. Not everything needs to be asynchronous. Only the jobs that are time consuming and are not dependent on some other jobs that are running on some other simultaneous goroutines. But if you run everything on a synchronized manner you won’t have this race condition problem. However in that case, if the square function is calculating something that it’s a little time consuming (say that it’s making an HTTP request inside it), you’re entire program is blocked until it does it’s job. Try messing around in your IDE/Editor and you’ll eventually know how to thing like GO.

Are we good now? Hell yeah! Next we’re gonna talk about the Function Receivers. Buckle up!

Next:

Coming soon…

Previous:

Let’s GO! Part 11: Reference Types 3: Maps

List Index:

Let’s GO! List Index

Overview

If you’re already familiar with some other languages like Java or Python, Maps in GO are exactly what we call them Hashmaps or Dictionaries respectively in those languages. They’re basically a key-value pair data structure that both the keys and the values are statically typed.

How Do They Work?

Exactly like Hashmaps and Dictionaries, Maps in GO are implemented using a hash table underneath. Now we’re not gonna go into how the hash tables work in this course. If you don’t know them already, there are pretty good articles out there about them that are only a Google search away from you!

Exactly like Hashmaps in Java, Maps in GO are not multi thread safe. This means if you are willing to write to or read from them in a concurrent manner, you need to implement a synchronization mechanism yourself. You can read more about how to do it safely in this article:

Concurrent map access in Go

Code, Sweet Code!

First the syntax, which is really simple:

# First declare a map:
myMapName := make(map[KEY_TYPE]VALUE_TYPE)

# Then assign key-pair values to it:
myMapName[KEY] = VALUE

Pretty straightforward, right? Now let’s see it in action:

The output should be:

myMap: map[one:1 two:2]
oneValue: 1     twoValue: 2
myMap after deletion: map[two:2]

Some important notes:

• You can specify any types for the keys and the values. It’s really up to you and it’s very flexible.
• The time order to search, insert and delete in maps are mostly constant. Meaning that they’ll be done in the most efficient way possible.
• In Maps, unlike arrays and slices, if you iterate through them with a for loop, you’ll get different orders of key-value pairs in each iteration. Meaning that you can’t put a trust on the order of them.
• In Maps, unlike structs, your keys should not be determined at the build time. You needed to tell GO that which keys your struct will be having when writing it and then you could use features like auto code completion on the key names provided by your IDE/Editor. But in Maps, you only tell GO that the keys will have what type, and then you can even make new keys with the same type at the runtime. Thus the auto code completion on the key names wouldn’t work. So be careful not to encounter errors about specifying wrong key names at runtime.

This is it! With Maps you’re now very powerful!

We’ll talk about Channels in the next part. 👀

Next:

Let’s GO! Part 12: Reference Types 4: Channels

Previous:

Let’s GO! Part 10: Reference Types 2: Slices

List Index:

Let’s GO! List Index

Overview

Slices are a very clever data type that you see in GO. They’re a concept originated in the GO language itself and you won’t find them in any other languages like they are in GO. Thus you might find them slightly hard at the first glance but they’re really easy.

Wait A Minute, What Are Them?!

Slices are basically simple views on Arrays! Think of them as a middleware class between you and your array which provides some very useful methods on your array, as well as hiding the complexity of working with arrays and providing you a very consistent and easy-to-use API to do things on arrays that weren’t possible in a simple and clean manner before.

No! They’re NOT Slower Than Arrays!

With the given explanation above, you might think that Slices might be slower than arrays since they’re providing more features than arrays and doing some magic under the hood; but that’s not true. Since the provided methods in Slices are implemented in the most efficient way possible, and since they do some magic when allocating and deallocating memory (which we’ll talk about soon), they’re even faster and more efficient than simple arrays in the most use cases!

What Magic?!

A Slice has basically 3 different parts. First part is a pointer named ptr. A pointer to an array. Yes! You heard it right! The two other parts are two integers named len and cap which contain the length and the capacity of the Slice respectively. Now, when you create a Slice, basically an array gets created on the disk. A pointer to that specific array is stored inside ptr. The length of the array is stored inside cap and the size of the Slice itself is stored inside len. What is happening here, is that GO tells you Ok don’t worry about anything! You want an array-like structure, you got one. You want to be able to resize it, you got it. You want all the methods to be efficient, you also got it! But how? Since a Slice is a pointer to an array, resizing it is a matter of changing the pointer and the two integers. If you initialize a Slice from an existing array or another Slice, GO will only add a pointer to that array or Slice on the disk. It doesn’t copy the data to a new place on the disk, although it will if you ask it to with the copy function. Now if you modify one of the members of such Slice, surprise surprise, the same member of that array or the other Slice is also modified since they’re all pointing to the same place on the memory. Now since we’re only dealing with pointers and not copy pasting values over new places on the disk, it’s very efficient to work with Slices. And since GO provides built-in functions to deal with Slices, which in all cases they’re dealing with the pointers as well instead of copy pasting values, you have great power added to your array with a simple abstraction called Slice. Everybody’s happy, right?

The Difference Between len and cap

len is the size of the Slice. It tells you how many elements are inside this Slice. However cap is the size of the array that this Slice points to. These two values are usually the same but sometimes they’re not. Imagine when you’re making a Slice from a range (from an index to another) from your array. That’s when len and cap become different. But in this case cap won’t be the exact size of the underlying array, but the size of the underlying array starting from the element that the range starts from to the end of the array. For reading more about these details, here’s two good articles about Slices:

• Go slices are not dynamic arrays - Applied Go
• Go Slices: usage and internals - The Go Programming Language

Code, Code, COOOOODEEEE!

Enough with the long and boring descriptions. Let’s see some code:

The output should be this:

myFirstSlice: [1 2 3]
myFirstSlice after modification: [5 2 3 10]
mySecondSlice: [5 2 3 10]
mySecondSlice after modification: [5 2 73 10]
myFirstSlice after modifying mySecondSlice: [5 2 3 10]
myThirdSlice: [5 2 3 10]
myThirdSlice after modification: [5 153 3 10]
myFirstSlice after modifying myThirdSlice: [5 153 3 10]
Length of mySecondSlice: 4
Capacity of mySecondSlice: 4

Some important notes about Slices:

• The built-in make function has two implementations: The first one takes 2 arguments (as you already saw in the code). The first argument is the type of your Slice, and the second one is the length of it. This way the capacity of your Slice is equal to the length you specified as the second argument. The second implementation takes 3 arguments. The first 2 arguments are as same as the first implementation, and the third one is the capacity of your Slice. This is useful when you know how much the underlying array of your Slice is going to expand throughout your application. Something a little more professional to keep an eye on the efficiency since if you expand your Slice more than it’s capacity, GO has to allocate a new space on the memory with the needed capacity and copy the data to the new location as well as changing the pointer value. Which you can say it’s somehow expensive.
• Earlier we talked about ranges. If you’re familiar with Python, ranges in GO work as same as they do in Python. On both arrays and Slices, you can get a portion of them like this: Imagine you have a Slice named mySlice that has 6 elements inside it. You want to get the elements from index 2 to index 4 (excluding the index 4 itself). You can basically say it like this: mySlice[2:4]. That will give you a new Slice that contains the third and the fourth elements of mySlice. If you don’t mention the left side of the :, it’ll be considered from the first element of the array or Slice, and if you don’t mention the right side, it’ll be considered until the end of it.
• Same as the arrays, the order of the values stored in Slices are always constant. Meaning that if you try to loop through them with a for loop, which you’ll see later on in the part about loops, you’ll get the same order of the results in each iteration. Thus it’s safe to trust their orders.

Ok well done! You’re a giga gopher now by knowing Slices!

Next:

Let’s GO! Part 11: Reference Types 3: Maps

Previous:

Let’s GO! Part 9: Reference Types 1: Pointers

List Index:

Let’s GO! List Index

Reference Types, as the name suggests, are those that are somehow referential. These types are classified as Reference Types in GO:

• Pointers
• Slices
• Maps
• Functions
• Channels

We’ll be talking about each and every one of them on their own parts.

Overview

Pointers are simple variables or arguments (if passed to functions) that hold the address of another variable on the memory. If you’re already familiar with C or C++, you might wanna think about pointers in GO as they are in C and C++. Well that is not false but also not true. The main functionality is the same but they’re somehow different.

How Pointers Differ in GO from C/C++?

Since C and C++ are not automatically garbage collected, it might be a good idea to pass the arguments as pointers in those languages to reduce the overhead of holding the copied values on the memory and prevent memory leaks, and also be faster because the value doesn’t get copied to a new address. But GO is smarter. GO has an automatic garbage collector which only works on the heap. When you pass the variable as it is, it’ll go on the stack which will be pushed and popped only. But if you pass your variable as a pointer to another variable it might go to the heap and may even be slower due the garbage collection process that runs on the heap. Read more about this on this great article.

When to Use Pointers?

While it’s totally up to you either to use them at all or not, because almost anything that can be done with Pointers can simply be done with simple variables as well and it’s even faster most of the times, but there are some cases that you might want to consider using them:

• Passing large structs. The overhead of copying large structs might be worse than the overhead of the garbage collector process that runs on the heap. If this is the case, maybe it’s better to use pointers.
• Mutability. If you pass a variable as it is as an argument to a function, since the value gets copied to a new address, the function will not be able to mutate the original variable directly in it’s body. If you want to mutate the original variable directly inside the body of your function (“But why? Why would you do that? Why would you do any of that?” -JonTron), you have to use pointers instead. Jokes aside, there will be some cases where you want to do that and you’ll see them in the part about Receivers.
• API consistency. You might want to have an API consistency in your application as some of the Receiver Functions (which you’ll see in the part about Receivers) NEED to get the value by pointer so they can mutate the original value. In this case, having your other Receiver Functions getting their values also as pointers makes your API consistent.
• To signify true absence. Since the default value of pointers is nil instead of the original default values of the variables (which you saw at Part 6: Basic Types), they’re useful to know if the value is assigned or not. I mean you might assign 0 to a variable of type int and you want to know which variables of this type are assigned the value of 0 and which are 0 by default because no value is assigned to them. In this case using pointers is a good idea. But be careful of the billion dollar mistake.

Again, more info about this on this great article.

Syntax

There are two operators that you need to be aware of before diving into the syntax of Pointers:

• * operator which is called the Dereferencing Operator and it’s used to define pointer variables and access the value stored in the address.
• & operator which is called the Address Operator and it’s used to return the address of a variable or to access the address of a variable to a pointer.

Lesss gooo:

# Either the long syntax
var myPointerName *TYPE
myPointerName = &myVariableName

# Or the shorthand syntax
myPointerName := &myVariableName

• The type of your pointer should be as same as the type of the variable that you want your pointer to point to.
• Get the address by the variable’s name with & and get the value by the address with *.

IMPORTANT NOTE: If you log the value of a pointer, you’ll see a hexadecimal number starting with 0x. That number is the address of your variable on the disk. The note here is that you can store hexadecimal numbers even in simple variables in GO. Every number that starts with 0x will be considered a hex number. In the Printf function that comes from the built-in fmt package, if you format your hex variable with %v you’ll get the decimal value of it, whilst if you format it with %X you’ll get the exact hexadecimal value. Try it yourself in your editor.

Let’s see some code:

The output should be:

The address of myVar on disk is: [Some hex number starting with 0x]
The value that is stored in that address is: 23
The address of myVar after mutating should remain the same: [Some hex number starting with 0x]
But the value should change to: 25
The value of myVar after mutation inside the function's body: 12

Note: In the above code, the hex number you’ll get from each iteration of the program for the address will be different.

Yup that’s it! That’s the Pointers! Good job so far. I think it’s too soon to decide either to use pointers at all or not as there are some related things remained to learn that’ll help you decide better while designing the flow of your applications. So just know what the Pointers are and how are they declared for now and we’ll talk about these concepts later on.

Let’s learn about the Slices next.

Next:

Let’s GO! Part 10: Reference Types 2: Slices

Previous:

Let’s GO! Part 8: Aggregate Types 2: Arrays

List Index:

Let’s GO! List Index

1. Let’s GO! Part 0: Introduction
2. Let’s GO! Part 1: A Word or Two About GO
3. Let’s GO! Part 2: Setup
4. Let’s GO! Part 3: Hello, world!
5. Let’s GO! Part 4: Variables and Constants
6. Let’s GO! Part 5: Functions
7. Let’s GO! Part 6: Basic Types
8. Let’s GO! Part 7: Aggregate Types 1: Structs
9. Let’s GO! Part 8: Aggregate Types 2: Arrays
10. Let’s GO! Part 9: Reference Types 1: Pointers
11. Let’s GO! Part 10: Reference Types 2: Slices
12. Let’s GO! Part 11: Reference Types 3: Maps
13. Let’s GO! Part 12: Reference Types 4: Channels
14. Coming soon…

Overview

Arrays are basically different values from the same type that come under one name. These are the conceptual differences between Arrays and Structs:

• In Structs your values can have different types while in Arrays they must be from the same type.
• In Structs each value has it’s own name that you can access that specific value with that specific name later on, while in Arrays values only have index numbers and no names.
• In Arrays the order of the stored values is always constant. Meaning that if you try to loop through an array with a for loop, which you will see later on in the part about Loops, in each iteration the order of the values remains the same as the last time. With that said, you can put a trust on their order. However this isn’t a case with structs. The order that the key/value pairs get stored inside a struct, is not easily determined (it depends on how the compiler will decide that the is more efficient.) Thus not trustable, and the order that you define them in your code has no effect on how the compiler will decide in which order to store them.

Knowing the above info may lead you to think that Arrays are much simpler aggregate types than Structs, and that is true. Let’s see them in action.

How to Define and Use Arrays?

The syntax is very easy and almost like defining simple variables:

# Either define the type first and assign it to a variable later on
type MyArrayTypeName [ARRAY_SIZE]TYPE
var MyArrayName MyArrayTypeName
MyArrayName[INDEX] = VALUE
...

# Or define the type when initializing the variable itself
var MyArrayName [ARRAY_SIZE]TYPE
...

In the above syntax:

• ARRAY_SIZE is the size of your array that should be determined while defining your array’s type.
• TYPE can be any types that exist in GO. Even functions type!
• INDEX is the index number of the value starting from 0.

Let me show you some code:

The output should be:

The third value of mySecondArray: 1
myFirstArray: [10 3 89 54 4378]
mySecondArray: [23 34 1 832 33]
myThirdArray: [Ali Gopher You Let's GO!]
myFourthArray: [false true true]
myThirdArray after mutation: [KYXEY Gopher You Let's GO!]
myFourthArray after mutation: [true false false]

Note 1: Arrays are mutable. Only their size and type are not mutable.

Note 2: Arrays in GO can be multidimensional. But like the first dimension, the other dimensions should have a determined length as well when defining. Also the type of the elements of the other dimensions is as exact as the first dimension. For example, for defining a simple 3 dimensional array of integers, you can simply say var myArray [SIZE_OF_FIRST_DIM][SIZE_OF_SECOND_DIM][SIZE_OF_THIRD_DIM]int. This is basically an array of arrays of arrays.

Alright all done! That’s it for the Aggregate Types in GO. Let’s see a cute gopher gif together:

We’ll talk about the Reference Types in the next few parts.

Next:

Let’s GO! Part 9: Reference Types 1: Pointers

Previous:

Let’s GO! Part 7: Aggregate Types 1: Structs

List Index:

Let’s GO! List Index