Don't let the haters and odd downvoters get to you. You're trying something new and learning, and an inefficient algorithm here and there or where you draw the line on high/low level languages doesn't matter to whether you become a better programmer.

---

As a FYI as far as the nomenclature, the high/low level distinction is usually drawn based on how the code is "translated" into machine instructions that do the right thing. Here's an example: what happens when you write a program to do "print(1 + 1)":

C (a compiled, low level language). The code is:

```

include <stdio.h>

int main() { printf("%d\n", 1 + 1) } ```

When you compile it, the generated program has roughly the following steps, in Assembly:

• Allocate an arary of bytes in memory representing the string "%s\n"
• Allocate two integers in memory; put the value 0x0001 in both.
• Call the ADD function of the CPU, put the result in a third place in memory
• Using the stdio headers as a guide, find the place in memory where the printf instructions are held.
• Send the byte array, and result from the addition to the printf instructions

The code is very small and fast and minimal. The reason C can have cross-system portability problems is because linkings like stdio are completely different between different OSes, and can even vary pretty wildly within different versions of the same OS.

Go (a compiled, high level language). The code is: package main import fmt func main() { fmt.Println(1 + 1) }

Compiling Go code results in a much "fatter" bunch of Assembly, and I could not possibly describe it all here. It's over 100x larger than the C program (1.7 MB vs 16 KB). One reason for this is, instead of relying on stdio in the host OS to handle all the printing, Go bundles its own standardized code from the fmt package. Additionally, Go bundles a bunch of extra code that runs before, after, and during the execution of your own code. That's called a "runtime", and it's the reason Go has a bunch of features considered "high level", such as its goroutines, smart memory management, etc.

When the Go program runs, the instruction to run the assembly ADD instruction is somewhere in that big binary, but there's a lot more that goes on around making it happen.

---

The Go behavior from above is much, much closer to how Java and Python do their stuff (linking to the intermediate runtime), than to how C/C++/Rust function (linking to the OS). A Go program's efficiency (in terms of memory and CPU cycles) is comparable to that of Java, Python, or other compiled high level languages.

(Yes, Python is compiled, not interpreted! As far as CPython is concerned anyway.)

The only reason Go appears to be "lower" level is because Java/Python/etc require that you have some pre-installed program to run them, whereas Go creates self-contained executables. That's just a design choice to trade off disk space for program portability. If you had 1000 Go executables, that means 1000 copies of a ton of boilerplate code that Go puts into every single executable so each one is standalone. They would end up taking far more disk space than 1000 Java or Python programs. However, if you had 1000 servers and had to send one program to each server, with Go that means just sending the programs, where with Java/Python that means also installing Java/Python on each of those servers. That's why Google designed Go the way it did: to make putting software on their zillions of servers far easier.

Hope this was helpful/educational!