Programming Languages I Use in Production

JavaScript

JavaScript is the language of the browser. If something interactive happens on a web page, JavaScript makes it work. I use it for front-end interactivity, DOM manipulation, animations, form validation, and dynamic content loading. On the server side, I use JavaScript through Node.js for APIs, real-time applications, and build tooling.

I write vanilla JavaScript when the project does not need a framework. A marketing site that needs a mobile menu, a smooth scroll effect, and a form submission handler does not need React. It needs 50 lines of clean JavaScript. I am deliberate about this. Every kilobyte of JavaScript you ship to the browser costs your users time. It has to parse, compile, and execute before the page becomes interactive. Less JavaScript means faster pages.

When a project does need a framework, I use React or Next.js. Single-page applications, dashboards, complex forms with real-time validation, and interactive tools all benefit from a component-based architecture. But I do not default to a framework. I evaluate the actual requirements first and choose the simplest tool that handles them well.

On the backend, Node.js gives me a unified language across the entire stack. For real-time features like chat, live notifications, or collaborative editing, Node.js with WebSockets is my go-to. For REST APIs that need to handle high concurrency with low overhead, Express on Node.js is fast to build and fast to run.

When I Reach for JavaScript

• Client-side interactivity, animations, and DOM manipulation
• Single-page applications and complex user interfaces
• Node.js backend APIs and real-time features
• Build tooling, bundling, and development workflows
• Lightweight scripts where a framework would be overkill

Python

Python is my primary language for AI integration, data processing, automation, and scripting. When a project involves calling OpenAI or Anthropic APIs, processing datasets, scraping websites, building data pipelines, or automating repetitive workflows, Python is almost always the right tool.

The ecosystem is the main advantage. Libraries like pandas, requests, BeautifulSoup, and LangChain let me build complex data workflows in a fraction of the time it would take in other languages. For AI work specifically, Python is the industry standard. Every major AI model provider publishes their primary SDK in Python first. The tooling, documentation, and community support are unmatched.

I use Python for backend services when the project is data-heavy or AI-focused. Flask and FastAPI give me lightweight web servers that are fast to build and deploy. For scheduled tasks, ETL pipelines, and batch processing, Python scripts running on cron jobs or serverless functions handle the job cleanly.

I do not use Python for front-end web development or for applications where raw execution speed is critical. Python is not the fastest language, and it is not designed for the browser. But for its core strengths, data processing, AI, automation, and scripting, nothing else comes close to the combination of speed-of-development and ecosystem depth.

When I Reach for Python

• AI and LLM integrations using OpenAI, Anthropic, and open-source models
• Data processing, transformation, and pipeline automation
• Web scraping and data extraction
• Backend APIs for AI-powered features
• Scripting and task automation

SQL

SQL is the language of data. Every web application I build talks to a database, and that means writing SQL — whether it is raw queries, migrations, or the logic behind an ORM. I write SQL for PostgreSQL, MySQL, and SQLite depending on the project, and I understand the differences between them well enough to write queries that perform correctly on each.

I write schema designs that normalize data without over-engineering. I write queries that use proper indexing, avoid N+1 problems, and return only the data the application needs. When an application is slow, the database is usually the first place I look, and SQL is the tool I use to diagnose and fix it.

For complex reporting, analytics dashboards, and data-heavy applications, SQL is often doing the heavy lifting behind the scenes. Aggregate queries, window functions, CTEs, and joins replace what would otherwise be hundreds of lines of application code. Writing that logic in SQL instead of PHP or JavaScript means less code to maintain and faster execution.

When I Reach for SQL

• Database schema design and migrations for new applications
• Performance optimization — slow queries, missing indexes, query plan analysis
• Reporting dashboards and analytics that aggregate large datasets
• Data migrations between systems or during platform upgrades
• Complex filtering, search, and sorting logic that belongs in the database layer

Go

Go, also called Golang, is what I reach for when a service has to absorb heavy concurrent traffic without heavy operational complexity. It was designed at Google for exactly this problem, and it shows. Go compiles to a single static binary with no runtime to install, no dependency tree to resolve on the server, and no interpreter to keep patched. You build it, you copy it, it runs. That property alone eliminates an entire category of deployment problems.

The concurrency model is the real reason to use it. A goroutine costs about two kilobytes of memory, which means a Go service can hold tens of thousands of concurrent operations on hardware that would choke a thread-per-request architecture. Channels pass data between goroutines without the shared-memory locking that makes concurrent code in most languages fragile and hard to debug. When I need a webhook receiver that absorbs traffic spikes, a job processor chewing through a queue, or an API that stays responsive under load, Go is the most direct path to it.

Go is also excellent for command-line tooling. Because the output is one self-contained executable that cross-compiles to Linux, macOS, and Windows from a single machine, internal tools I write in Go can be handed to a client and simply run. No Node version manager, no Python virtual environment, no "works on my machine."

I am pragmatic about where it fits. I do not rewrite a working Node.js or PHP application in Go for its own sake. But when a specific service in the system is throughput-bound, or when a piece of infrastructure needs to be dead simple to deploy and operate, Go earns its place in the stack.

When I Reach for Go

• High-throughput REST APIs and webhook receivers that need to absorb traffic spikes
• Background workers and job processors handling thousands of concurrent tasks
• Microservices where a single static binary simplifies containers and deployment
• Command-line tools that must run anywhere without a runtime installed
• Data-processing services where raw throughput matters more than development speed

Swift & Kotlin

Most mobile projects I build are cross-platform, because writing one codebase for iOS and Android is usually the right economic call. But "cross-platform first" is not the same as "cross-platform only." Every serious app eventually reaches a feature that needs to talk directly to the operating system, and that is where Swift and Kotlin come in.

The typical pattern is a native module. The app's screens, navigation, state, and API calls stay in shared TypeScript, and a small, well-defined slice gets written natively and exposed to the rest of the app: a Core Bluetooth integration for a medical device, a HealthKit sync, a camera pipeline that has to process frames in real time, a background location service that must survive the OS killing the app, a home screen widget, or a watch companion. That slice is usually five percent of the codebase and one hundred percent of the reason the app is worth building.

Both languages have converged on the same modern idea for building interfaces. SwiftUI and Jetpack Compose are declarative UI frameworks, which means the mental model is nearly identical to React: describe what the screen should look like for a given state and let the framework handle the updates. If you already know component-driven development, moving between them is far less jarring than it was in the UIKit and XML-layout era.

Native fluency also matters for shipping. App Store review, code signing, provisioning profiles, TestFlight distribution, Play Console staged rollouts, and platform permission requirements are where mobile projects actually get stuck. Knowing the native side means I can diagnose a rejection or a signing failure directly instead of guessing from behind an abstraction layer.

When I Reach for Swift or Kotlin

• Native modules that expose platform APIs to a React Native or Flutter app
• Bluetooth devices, HealthKit data, camera pipelines, or background location tracking
• Home screen widgets, watch apps, and other OS-level integrations
• Performance-critical screens where the cross-platform bridge is the bottleneck
• Fully native builds when platform guidelines or App Store review demand it