DEV Community: Lucas Braun

Why Python is the best first language (and when it isn't)

Lucas Braun — Fri, 17 Apr 2026 17:54:40 +0000

Search "what language should I learn first" and 90% of the answers will say Python.

That's not a conspiracy, not hype, not a course sponsorship. There's real reason behind it. But there's also context those answers ignore — and ignoring context is what makes a lot of people start with the right language for the wrong goal.

So let's be honest about both sides.

Why Python makes sense as a first language

1. The syntax doesn't fight you

Most languages have ceremonies that make no sense when you're starting out. Declaring variable types, semicolons at the end of every line, curly braces everywhere.

Python removes most of that. Compare "hello, world" in Java:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

And in Python:

print("Hello, world!")

This isn't just aesthetics. When you're learning programming logic, every unfamiliar syntax element is one more thing to worry about. Python lets you focus on what matters: the reasoning.

2. You can build useful things fast

With Python, in a few weeks you can already:

Automate repetitive tasks on your computer
Analyze a data spreadsheet
Make a request to an API
Write a script that renames 500 files at once

That's motivation. And motivation is what keeps beginners going when things get hard.

3. The industry actually uses Python

Python isn't a toy language you learn and throw away. It powers a big chunk of:

Data science and ML: pandas, numpy, scikit-learn, TensorFlow, PyTorch
Automation and DevOps: scripts, pipelines, infrastructure tools
Web backend: Django, FastAPI, Flask
Security: pentest scripts, malware analysis

If you learn Python well, there are real jobs waiting on the other side.

4. The community is huge (and generous)

Got an error in your code? There's a Stack Overflow answer for it. Want to do something specific? There's a library for that. Want to learn for free? There's quality material at every level.

A large community means less time stuck on a problem with no way out.

When Python is not the best choice

Now for the part tutorials skip.

If you want mobile development

Python has no meaningful presence in mobile app development. If your goal is to build Android or iOS apps, you'll want:

Kotlin (native Android)
Swift (native iOS)
JavaScript/TypeScript with React Native (cross-platform)
Dart with Flutter (cross-platform)

Learning Python first will slow you down. Go straight to where you want to be.

If you want frontend web development

Python runs on the server, not in the browser. If you want to build interfaces, buttons, animations, the visual side of a website — that's JavaScript and HTML/CSS territory.

Python might complement your stack later on the backend, but if the goal is frontend, it's not where you start.

If you want to build games

There's Pygame, but honestly? It's not what the industry uses. If games are the goal:

C# with Unity is the most practical path for the indie market
GDScript or C# with Godot if you prefer open source
C++ if you have ambitions to work at large studios

If extreme performance is the requirement

Python is slow compared to compiled languages. For embedded systems, drivers, game engines, or anything where every millisecond counts, you'll want C, C++, or Rust.

That doesn't mean Python is useless in those contexts — sometimes it's used as glue between components. But as the primary language of a performance-critical system, it's not the ideal choice.

The question that actually matters

Before choosing a language, answer one question:

What do you want to build?

Goal	Where to start
Data science, AI, automation	Python
Web development (visual)	JavaScript + HTML/CSS
Mobile apps	Kotlin, Swift, or Flutter
Web backend	Python, JavaScript (Node), Go
Games	C# (Unity) or GDScript (Godot)
Low-level systems	C or C++
Offensive security	Python + Bash

If you still don't know what you want to build, then Python is the best bet. It's versatile enough to help you figure out what interests you without locking you into a niche.

One thing that matters less than it seems

A lot of people get stuck on the language choice because they think it's a permanent decision. It's not.

Your first language is there to teach you how to think like a programmer: loops, conditionals, functions, data structures, debugging. Those concepts exist in every language. Once you learn the logic well in Python, picking up JavaScript or Kotlin later becomes much easier.

The language is the vehicle. The reasoning is what you actually learn.

Python is an excellent first language for most people. But "most" isn't "everyone". Knowing what you want to build matters more than following the default recommendation on autopilot.

Git beyond push: the commands nobody taught you

Lucas Braun — Fri, 10 Apr 2026 13:30:28 +0000

Everyone learns Git the same way: git init, git add ., git commit -m "first commit", git push.

And then just... stops there.

The problem is that Git has a huge set of commands that make a real difference day-to-day — and almost no beginner tutorial ever mentions them. You only find out about them when something breaks, at 11pm, with an open pull request.

This article is here to change that.

1. `git stash` — Git's secret pocket

You're in the middle of a feature, the code is half-done, and you get a message: "there's an urgent bug to fix on main". What do you do?

If you try git checkout like that, Git will complain. If you make a commit, you'll pollute your history with a "WIP: saving to switch branches".

The solution is stash:

git stash

This saves all your uncommitted changes to a temporary place and leaves your working directory clean. Fix the bug, come back, and restore:

git stash pop

Want to see what you have saved?

git stash list

You can have multiple stashes and give them names:

git stash push -m "login feature halfway done"

2. `git log --oneline` — because the default log is terrible

Ever opened a git log and stared at a massive wall of text? There's a much better way:

git log --oneline

Output:

a3f1c2e feat: add JWT authentication
9b2d441 fix: correct form validation
3c8e109 chore: update dependencies

Clean, readable, one commit per line.

Want to see branches too?

git log --oneline --graph --all

This draws a visual tree of your branches in the terminal. Looks like something from a hacker movie, but it's just Git.

3. `git diff` — before committing, see what you actually changed

You know that moment when you type git add . without even checking what changed? Yeah, everyone does it. But the right way is to review first:

git diff

This shows line by line what changed in files that haven't been staged yet.

Already ran git add and want to review before committing?

git diff --staged

Want to compare two specific commits?

git diff abc1234 def5678

Reviewing your diff becomes a habit once you stop accidentally committing garbage.

4. `git commit --amend` — fixing your last commit

Committed with the wrong message? Forgot to include a file? You don't need to create a new commit just for that:

git commit --amend

This opens your editor with the last commit message for you to edit. Save, close, done.

Want to change the message directly without opening the editor?

git commit --amend -m "feat: add JWT authentication"

Want to include a forgotten file?

git add forgotten-file.py
git commit --amend --no-edit

⚠️ Warning: only use --amend on commits that haven't been pushed to the remote yet. If you've already pushed, you'll run into trouble pushing again.

5. `git restore` — undoing changes without drama

You changed a file and regretted it. Want to go back to how it was at the last commit?

git restore filename.py

This discards all local changes in that file. No commit, no hassle.

Want to undo a git add (unstage a file)?

git restore --staged filename.py

This doesn't delete your changes, it just removes the file from the staging area. Your edits are still there.

6. `git revert` — undoing a commit without rewriting history

Made a commit you shouldn't have? The temptation is to use git reset, but there's a problem: it rewrites history, which can cause a mess for teams.

git revert is safer: it creates a new commit that undoes the changes from a previous commit:

git revert abc1234

The history stays intact, you just add a new commit that reverts the damage. Perfect for team environments.

7. `git cherry-pick` — taking only what you need

Imagine you have a bugfix on a feature branch, but you need to apply that fix to main right now, without merging everything.

cherry-pick takes a specific commit and applies it to another branch:

git cherry-pick abc1234

Switch to the target branch, run this command with the hash of the commit you want, and done. Only that commit gets copied over.

Bonus: aliases that will save you time

Tired of typing git log --oneline --graph --all every time? Create an alias:

git config --global alias.tree "log --oneline --graph --all"

Now just type:

git tree

You can create aliases for any command. Some I use all the time:

git config --global alias.st "status"
git config --global alias.co "checkout"
git config --global alias.unstage "restore --staged"

Summary

Command	When to use
`git stash`	Save work in progress to switch context
`git log --oneline`	View history in a readable way
`git diff --staged`	Review what's going into the next commit
`git commit --amend`	Fix the last commit (message or files)
`git restore`	Undo changes in files
`git revert`	Safely undo a commit in a team environment
`git cherry-pick`	Apply a specific commit to another branch

These commands aren't advanced — they're essential. They're what separates someone who "uses Git" from someone who actually works well with it.