{"id":167933,"date":"2026-05-23T18:04:10","date_gmt":"2026-05-23T15:04:10","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=167933"},"modified":"2026-05-23T18:04:10","modified_gmt":"2026-05-23T15:04:10","slug":"python-nodejs-go-rust-fedora","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/python-nodejs-go-rust-fedora\/","title":{"rendered":"Set Up Python, Node.js, Go, Rust on Fedora 44 \/ 43 \/ 42"},"content":{"rendered":"

A clean Fedora install is already half a developer workstation. The toolchain group (GCC, Make, Git, kernel headers) is one DNF transaction away, Python ships current, and the language runtimes you need for the four most common stacks are all in the default repositories with no extra mirrors to chase. The other half is knowing which path to take for each language so you do not end up with three competing toolchain installs fighting over PATH<\/code> a month from now.<\/p>\n\n

This guide walks through setting up a complete Python, Node.js, Go, and Rust development environment on Fedora 44, including the DNF-packaged path for each, the upstream toolchain installer where it matters (rustup, nvm, pyenv), and a sanity-check build in every language. The same commands work on Fedora 43 and Fedora 42 with the version numbers shifted accordingly. Tooling beyond the runtimes (VS Code, Distrobox, version managers) gets a quick pointer to the dedicated guides so this article stays a focused setup walkthrough.<\/p>\n\n

Tested May 2026<\/strong> on Fedora 44 (kernel 7.0.8-200.fc44) with Python 3.14.4, Node.js 22.22.2, Go 1.26.3, Rust 1.95.0, GCC 16.1.1. Same commands verified on Fedora 43 and Fedora 42 clones.<\/em><\/p>\n\n

What ships by default on Fedora 44<\/h2>\n\n

Before installing anything, see what is already there. Fedora 44 ships Python and the core build tools by default; the language runtimes for Node, Go, and Rust are the ones you add. Quick inventory:<\/p>\n\n\n

cat \/etc\/fedora-release\npython3 --version\ngcc --version | head -1\nmake --version | head -1\ngit --version\nrpm -q nodejs golang rust cargo 2>&1 | head -5<\/code><\/pre>\n\n\n
On a fresh F44 Workstation the runtimes report installed; the four language packages are “not installed”. That is the starting point. The next sections each add one runtime, verify it with a one-line program, and show the version-manager alternative where the packaged version is too old for your workflow.<\/p>\n\n
Install the GCC toolchain group<\/h2>\n\n
Most projects need a C compiler, headers, and the basics to build native extensions (Python wheels with C code, Node native modules, Go cgo, Rust crates that link to C). Install the whole group in one command instead of cherry-picking packages:<\/p>\n\n\n
sudo dnf5 group install -y \"Development Tools\"\nsudo dnf5 install -y kernel-devel kernel-headers<\/code><\/pre>\n\n\n
The kernel-devel<\/code> + kernel-headers<\/code> pair pulls in matching kernel-source artifacts. You only need these when building DKMS modules, VirtualBox guest additions, or NVIDIA akmod packages; skip them for a pure userland dev box. Sanity check the compiler stack:<\/p>\n\n\n
gcc --version | head -1\nmake --version | head -1\ngit --version<\/code><\/pre>\n\n\n
On Fedora 44 you should see gcc (GCC) 16.1.1<\/code>, GNU Make 4.4.1<\/code>, and git version 2.54.0<\/code> or newer. The compiler bump to GCC 16 across the F44 cycle is the biggest single change for native-extension builds; if you have wheels or modules pinned to GCC 14 you may need to rebuild them. A complete toolchain inventory after the next two install steps looks like this on a fresh F44 box:<\/p>\n\n\n
\"Python<\/figure>\n\n\n
Those are the four runtimes plus the supporting tools you reach for daily: GCC and Make for native builds, Git for everything that touches version control. The DNF-shipped versions track upstream LTS\/stable cycles within a few weeks of release.<\/p>\n\n
Set up Python with pip and venv<\/h2>\n\n
Python 3.14 is the system interpreter on Fedora 44. The split is the same as on F43 and earlier: python3<\/code> ships, but pip<\/code> and venv<\/code> require their own packages. Install both:<\/p>\n\n\n
sudo dnf5 install -y python3-pip python3-virtualenv\npython3 -m pip --version\npython3 -m venv --help | head -1<\/code><\/pre>\n\n\n
Verify the install with a tiny script that reports back the interpreter version and parses the OS-release file (platform.freedesktop_os_release()<\/code> is available on Python 3.10 and newer). Create the workspace and the script file:<\/p>\n\n\n
mkdir -p ~\/dev-test\nvi ~\/dev-test\/hello.py<\/code><\/pre>\n\n\n
Paste this content into the editor and save:<\/p>\n\n\n
import platform\nrelease = platform.freedesktop_os_release()\nprint(f\"Hello from Python {platform.python_version()} on Fedora {release['VERSION_ID']}\")<\/code><\/pre>\n\n\n
Run it:<\/p>\n\n\n
python3 ~\/dev-test\/hello.py<\/code><\/pre>\n\n\n
The expected output is Hello from Python 3.14.4 on Fedora 44<\/code>. Per-project isolation goes through venv<\/code>, which avoids the “did I install this for the system or for the project” trap that sudo pip install<\/code> creates:<\/p>\n\n\n
python3 -m venv ~\/dev-test\/myproj-venv\nsource ~\/dev-test\/myproj-venv\/bin\/activate\npip install requests\npython -c \"import requests; print(requests.__version__)\"\ndeactivate<\/code><\/pre>\n\n\n
When you need multiple Python minor versions side by side (3.12 for one project, 3.14 for another), pyenv<\/a> is the standard tool. It compiles each interpreter from source on first install, so install the build deps first: sudo dnf5 install -y zlib-devel bzip2-devel readline-devel sqlite-devel openssl-devel xz-devel libffi-devel<\/code>, then curl https:\/\/pyenv.run | bash<\/code>. The system python3<\/code> stays at 3.14; pyenv shims override per-project.<\/p>\n\n
Install Node.js and npm<\/h2>\n\n
Fedora 44 ships Node.js 22 LTS by default. The DNF path is one command and covers most needs:<\/p>\n\n\n
sudo dnf5 install -y nodejs npm\nnode --version\nnpm --version<\/code><\/pre>\n\n\n
The expected versions on F44 are v22.22.2<\/code> for Node and 10.9.7<\/code> for npm. The dedicated Node.js install guide<\/a> covers NodeSource (for newer Current branches) and side-by-side major versions. For one-project-needs-Node-20-and-another-needs-Node-24 setups, fnm<\/a> is the fast modern alternative to nvm:<\/p>\n\n\n
curl -fsSL https:\/\/fnm.vercel.app\/install | bash\nexec $SHELL\nfnm install 24\nfnm install 22\nfnm default 22\nfnm list<\/code><\/pre>\n\n\n
Quick verification with a script that reports both the runtime and platform info. Create ~\/dev-test\/hello.js<\/code>:<\/p>\n\n\n
console.log(`Hello from Node.js ${process.version} on ${process.platform}\/${process.arch}`);<\/code><\/pre>\n\n\n
Run it with the Node binary:<\/p>\n\n\n
node ~\/dev-test\/hello.js<\/code><\/pre>\n\n\n
Output: Hello from Node.js v22.22.2 on linux\/x64<\/code>.<\/p>\n\n
Install Go (Golang)<\/h2>\n\n
Fedora 44 ships Go 1.26 in the default repos. For most workflows this is fresher than upstream’s go.dev binary releases anyway, and dnf-updated alongside the rest of the system:<\/p>\n\n\n
sudo dnf5 install -y golang\ngo version\ngo env GOPATH GOMODCACHE<\/code><\/pre>\n\n\n
F44 reports go version go1.26.3-X:nodwarf5 linux\/amd64<\/code>; GOPATH<\/code> defaults to ~\/go<\/code>, GOMODCACHE<\/code> to ~\/go\/pkg\/mod<\/code>. The X:nodwarf5<\/code> tag is Fedora’s downstream build flag (DWARF 5 disabled in default builds for older tooling compatibility). Create ~\/dev-test\/hello.go<\/code> with the standard runtime-info pattern:<\/p>\n\n\n
package main\n\nimport (\n    \"fmt\"\n    \"runtime\"\n)\n\nfunc main() {\n    fmt.Printf(\"Hello from Go %s on %s\/%s\\n\", runtime.Version(), runtime.GOOS, runtime.GOARCH)\n}<\/code><\/pre>\n\n\n
Build and run with the standard go run<\/code> invocation:<\/p>\n\n\n
go run ~\/dev-test\/hello.go<\/code><\/pre>\n\n\n
The output reads Hello from Go go1.26.3-X:nodwarf5 on linux\/amd64<\/code>. For a real project, initialize a module first: mkdir myproj && cd myproj && go mod init github.com\/you\/myproj<\/code>. If you need to track a specific Go minor (say 1.24 for a legacy project), go install golang.org\/dl\/go1.24.5@latest<\/code> followed by go1.24.5 download<\/code> installs that version side by side; the per-version binaries live in ~\/go\/bin\/<\/code>. The full Go install guide<\/a> covers binary tarball installs and per-version directory layouts.<\/p>\n\n
Install Rust via rustup (recommended) or DNF<\/h2>\n\n
Rust is the one language where the upstream toolchain installer beats the distro package in every practical scenario. The DNF-packaged rust<\/code> works for casual builds, but it ships one version at a time, lags upstream stable by 2-4 weeks, and offers no clean path to nightly. Use rustup for any real Rust work; reach for the DNF package only when you cannot install a userland toolchain (locked-down CI, air-gapped boxes).<\/p>\n\n
The rustup<\/strong> path is one command, no root needed, lives entirely under ~\/.cargo<\/code> and ~\/.rustup<\/code>:<\/p>\n\n\n
curl --proto '=https' --tlsv1.2 -sSf https:\/\/sh.rustup.rs | sh -s -- -y --default-toolchain stable --profile minimal\nsource \"$HOME\/.cargo\/env\"\nrustup --version\nrustup show\nrustc --version\ncargo --version<\/code><\/pre>\n\n\n
After the install, rustc --version<\/code> reports the upstream stable (1.95.0 at the time of writing), and cargo<\/code> lands in ~\/.cargo\/bin\/<\/code>. The rustup-managed install shows up clearly in its own status command:<\/p>\n\n\n
\"rustup<\/figure>\n\n\n
Switch toolchains as needed:<\/p>\n\n\n
rustup toolchain install nightly\nrustup default stable\nrustup override set nightly       # in a project dir, override per-project\nrustup component add clippy rustfmt rust-analyzer\nrustup update<\/code><\/pre>\n\n\n
The DNF<\/strong> path is the fallback. It installs into \/usr\/bin<\/code>, updates with the rest of the system, and pins to whichever Rust version Fedora is currently shipping:<\/p>\n\n\n
sudo dnf5 install -y rust cargo rust-src clippy rustfmt\nrustc --version\ncargo --version<\/code><\/pre>\n\n\n
The two paths coexist. If both are installed, rustup wins because ~\/.cargo\/bin<\/code> is earlier in PATH<\/code> than \/usr\/bin<\/code>. To force the system rust temporarily, run \/usr\/bin\/cargo<\/code> directly. A first project sanity check:<\/p>\n\n\n
cd ~\/dev-test\ncargo new --quiet hello-rust\ncd hello-rust\ncargo run --release --quiet<\/code><\/pre>\n\n\n
Cargo creates the project skeleton, compiles, and runs Hello, world!<\/code> in one shot. Subsequent builds reuse the compiled deps; only your code rebuilds. End-to-end, the four-language sanity test on Fedora 44 produces:<\/p>\n\n\n
\"Hello<\/figure>\n\n\n
Each language reports its own version and the host platform, which is the quickest way to confirm the toolchain you just installed is the one actually running your code.<\/p>\n\n
Editor and project tools<\/h2>\n\n
The dev environment is the runtimes; the daily-driver editor is a separate decision. VS Code is the most common choice on Fedora and works cleanly via Microsoft’s RPM repo (covered in the VS Code install guide<\/a>). Other strong picks: NeoVim via sudo dnf5 install -y neovim<\/code>, Helix via sudo dnf5 install -y helix<\/code>, JetBrains Toolbox via the official Flatpak. Whichever you pick, install the matching language-server packs:<\/p>\n\n\n
sudo dnf5 install -y python3-lsp-server gopls\n# Rust LSP comes from rustup:\nrustup component add rust-analyzer\n# Node\/TypeScript LSP installs with VS Code or via:\nnpm install -g typescript typescript-language-server<\/code><\/pre>\n\n\n
Git is already installed. The minimum setup for committing under your own identity:<\/p>\n\n\n
git config --global user.name \"Your Name\"\ngit config --global user.email \"you@example.com\"\ngit config --global init.defaultBranch main\ngit config --global pull.rebase true<\/code><\/pre>\n\n\n
For GitHub specifically, generate an SSH key (ssh-keygen -t ed25519 -C \"you@example.com\"<\/code>), add ~\/.ssh\/id_ed25519.pub<\/code> to your GitHub account, then test with ssh -T git@github.com<\/code>. Avoid HTTPS + token unless you also configure a credential helper, otherwise every push prompts.<\/p>\n\n
Container-based dev environments<\/h2>\n\n
For projects that need a wildly different distro base than Fedora (Ubuntu, Debian, Arch), or for testing your code against a Python 3.12 \/ Node 18 \/ older Go combination without polluting the host, container-based dev environments are the cleanest answer. Two F44-native options:<\/p>\n\n