While I figured out early on that narrowing my focus by using a project-based learning approach (as opposed to the topic-by-topic laundry list approach) was important, finding the best tools for the job was a different matter.

If you happen to be searching for some of those things, then this article is for you. After over a decade of programming products, building client applications, answering thousands of questions from junior and intermediate developers, and wrestling with these questions myself, I will do my best to explain how to find the best things.

This article is intended for junior to intermediate level developers looking to get some practical answers to difficult problems. You will not need extensive programming experience to get through it and you may skip over any technical discussions specifics. Those are meant to be helpful pieces of information, but the core of this article is about how to make these decisions in general using what I call: The Law of Suitability.

The topics I will cover are:

• How to Find the Best Anything

  • How to Find the Best Water Bottle

• How to Find the Best Programming Language

  • Navigating Public and Expert Opinions

  • Low Level vs High Level

  • Tightly Structured (Static) vs Loosely Structured (Dynamic)

  • Popularity Is Only One Factor

  • Popularity Is Not A Guarantee Of Employment

  • Hardware & Working With What You Have

  • What if I Want the AI to Code For Me?

  • Avoid the Sunk-Cost Fallacy

• How to Find the Best Libraries and Frameworks

  • What Are Libraries and Frameworks?

  • How to Choose Libraries and Frameworks

• How to Find the Best Programming Principles and Practices

  • D.R.Y – Don’t Repeat Yourself

  • What About Other Programming Principles?

• A Note About Patterns and Architectures

  • How to Find the Best Software Architecture

  • The Design Pattern Trap

• Summary

How to Find the Best Anything

I invite you to follow along with some basic non-technical examples which lay the groundwork for the rest of this article. The examples may sound silly to some, but I have layered in some conceptual patterns which you can apply to programming languages, tools, and concepts – as well as just about anything where terms like good, bad, best, or worst can apply.

How to Find the Best Water Bottle

Suppose that you are looking to solve the problem of staying hydrated and wish to purchase a water bottle.

You consider that figuring out the best water bottle might involve looking into:

• Public opinions and reviews

• Expert opinions and reviews

• The manufacturer’s descriptions and reputation

• Buying and testing water bottles (though preferably not all of them, as that costs too much time and money, generally)

All of those things are fair for consideration. Something which is not well-tested in public presents uncertainty. Expert reviews can help inform your decision, but you have to consider the biases and motivations of such experts. You also should consider if the manufacturer has a history of quality, design, and customer support, or whether they’re simply maximizing profit.

After doing some research, you come up with these options:

• A plastic bottle of water from a vending machine

• A high-tech metal bottle which you can even boil stuff in!

• A simple but ethically sourced, refillable, BPA-free plastic water bottle

However, you noticed that nobody seemed to universally agree about which option was the best. There were usually some common opinions, but it was never the case that every expert had the same evaluation or recommendation.

After reflecting on this, it became obvious that you need to consider how, when, and where you will be using this water bottle. In other words, you need to consider the context or situation of its usage.

Suppose three different contexts within which you have to make this decision:

• You are standing in a rest stop in Death Valley California (often thought to be the hottest place on Earth in summer) and there is a vending machine full of micro-plastic filled, old, generic, and cheap plastic bottles of water in front of you. But you have no other options and are very thirsty

• You are in a camping store preparing for a camping trip to New Zealand with lots of hiking and not too much access to filtered water

• You are looking on your favorite shopping website for something you can bring to work each day to avoid those dehydration headaches from not drinking enough water

In summary, you shouldn’t ignore second-hand knowledge, expert opinions, popularity, ratings, reviews, testimonials, and even first-hand experience. But you will never find the best water bottle for every situation you find yourself in. The best “anything” depends on the problem you are trying to solve and the context (words like requirements or situation also apply here) of that problem.

In other words, none of these things have an absolute or fixed value – their value is always relative. I call that the Law of Suitability.

Let’s now discuss some examples which are directly related to software design and development.

How to Find the Best Programming Language

The Law of Suitability applies just as much to programming languages as it does to water bottles – even though the details and contexts are different. There is no such thing as the best programming language for every person, team, problem, or feature.

But I do have some specific details and contexts to offer which may help you answer that question for yourself. This section will cover concrete details and some general ideas on how to choose a programming language. These patterns also apply to frameworks, libraries, and most other aspects of programming.

If you are not interested in the topic of finding a programming language, feel free to skip to the next sections on topics like libraries, principles, and patterns.

Navigating Public and Expert Opinions

Firstly, you need to be skeptical of popularity and the opinions of experts and “influencers” here.

My general tip here is to be extremely cautious about anyone who makes one of these claims:

• “X” language is the best (though saying “X” language is my favourite is perfectly acceptable)

• “X” language is the worst, is terrible, is dead, is garbage, is useless, and so on.

There are three groups of people who generally make these sorts of statements:

• Actual experts who are voicing their personal preferences but presenting them as immutable facts (how I wish this was not so common in this industry)

• Non-experts parroting opinions of the above group or who have not yet understood the Law of Suitability

• Engagement farmers

It’s also worth noting that people can be experts in a subset of problems but that doesn’t guarantee their opinions about all problems are expert level.

This doesn’t mean you should reflexively dismiss expert opinions in general. Consider both the track records of the person and the degree to which they pay attention to the context of their statement.

Let us look at two examples:

• Expert A says: “Python has the best tooling, support, and ecosystem for ML development”

• Expert B says: “Python is the best programming language”

While Expert B is obviously displaying a lack of precision (either deliberately or not) if you have followed me so far, Expert A is a different case. Whether or not the statements made by Expert A are true (for the record, I have written a bit of Python but no ML code), you can tell that they are considering details and context. Look for people like Expert A!

Low Level vs High Level

In simple terms, low level programming languages are difficult for humans to read and write. Also, they tend to be faster and have a lower memory footprint than high level languages. Conversely, high level languages are closer to human language which generally makes them easier for humans to work with.

I must confess, though, that I have seen plenty of examples of people writing unintelligible code in high level languages – please don’t do that.

Someone working on an embedded system might want to do so in a language like C or C++ to optimize performance or work around the limitations of memory and processing power.

But in enterprise systems, which need to run on a variety of platforms and which closely intermingle with business requirements, rules, and real world objects (thing products, users, and so on), lower level languages are not so popular. After all, upper and middle management generally tends to care about low level optimizations only to the extent it affects the user experience.

I love optimization in general, but never forget that everything is fast with small datasets (that is, when n is small) or high processing power. In simpler terms, sometimes human concerns like legibility are significantly more important than insignificant optimizations on efficiency.

Tightly Structured (Static) vs Loosely Structured (Dynamic)

Ironically, the main downsides and benefits of a language like Java (which is very structured and verbose) versus a language like JavaScript (quite the opposite, depending on how you use it) are the same depending on the context.

Speaking of enterprise systems, using structures, types, interfaces, classes, threading, concurrency primitives, and similar programming constructs can have a variety of benefits. It can insulate you from safety while providing some flexibility via type hierarchies, interfaces, protocols, abstractions and so on.

Further, studying design patterns can teach you repeatable solutions to problems which have been encountered since the dawn of the general purpose computer – or shortly thereafter.

But the Law of Suitability still applies here. Maybe you just need to write a quick script to migrate some data from one SQL database to another. Maybe you know how to approach problems using a more functional approach that doesn’t require or discourages the use of objects, classes, or structs. Maybe you realize one day that trying to apply design patterns, architectures, hierarchies and similar constructs in every situation has actually created as many problems as they were solving. More on that later.

It’s also worth mentioning that most modern language designers and maintainers have understood that we developers like flexibility. Many of us want to avoid premature optimization and unnecessary structure but also don’t want our code to blow up because we accidentally told the program to add together 1.23356 + “Rhinoceros”.

The main point is that structure or a lack of structure is both a blessing and a curse, depending on where it is used.

Popularity Is Only One Factor

I’m not going to say that popularity is irrelevant and that you should start with the least popular hipster programming language you can find. No shade intended to hipster programming languages, but unpopularity is not generally a good thing in isolation, either.

The key point is that many people weighing in on programming languages (probably most) don’t have abundant experience working on a variety of platforms, languages, and settings. If someone has only ever written Python and enjoys doing so, they will naturally tend to regard it above others.

We humans have a tendency to find the first thing that works for us and then die on a hill defending it. But to take a more anecdotal approach here, I know a couple dozen intermediate to senior level developers who have extensive experience in Java and other programming languages. Despite Java still being ranked as one of the most popular languages globally, only one of those developers I know actually prefers to write in Java if they have the choice.

Don’t make the mistake of assuming that the first thing that works for many people will be the last thing you need to try out. I have from time to time experimented with languages such as Haskell, which taught me many valuable lessons about the benefits of making my code more functional (and functionally pure) in nature.

But I have zero intention of using Haskell as my go to solution for building GUI applications.

Popularity Is Not A Guarantee Of Employment

One of the most common things you ought to consider is whether or not the language you pick will help you get a job – assuming that’s a concern. Influencers absolutely love to tell people to choose one particular language because it has the most public commits on GitHub, or another because it has the largest number of programmers using it (which is in practice something that’s impossible to say for sure).

Let me flip that on its head: suppose that the most common programming language and platform combination is JavaScript and web. Let’s further suppose that we have pretty concrete data on the number of job postings on the web which confirms that the largest volume of jobs available is for that combination. Let’s finally suppose that for whatever reason, you strongly dislike JavaScript and enjoyed building a website using PHP.

You will find voices who will tell you that PHP is a dead language and a dead end for job searching.

But if you go looking, you may notice that there is a good supply of job postings out there looking for PHP developers who can expand and maintain existing codebases. You might also have a much better chance of getting an interview because the ratio of job postings to applications is significantly better for PHP developers than JavaScript developers. In fact, my team recently hired a PHP developer!

Hardware & Working With What You Have

This section is largely irrelevant to web developers, but may be extremely important for those looking to target specific hardware or operating systems. Simply put, if you don’t have a computer with Mac OS and XCode, you will have a very hard time developing an iOS app, for example. In my case, back in 2014, I chose Android development partly because I had studied a bit of Java – though a big consideration was that I had an Android phone.

There are some ways around this by paying to use a remote device (such as a remote Mac via an online service), but my experience with such services years ago is that they weren’t great.

Think about what resources you have and how that fits into what you want to build or whom you want to work for. If you have not much other than a cheap computer with a web browser, and you still want to build GUI applications, web development can be a great choice.

What if I Want the AI to Code For Me?

While this topic is worthy of a separate article, I don’t believe this is an unreasonable question to ask. A year ago, I would have told you that at best, the AI can write some basic code and help you learn some things which may or may not be wrong.

How things have changed! Though I would be bad at my job if I copy pasted code I didn’t understand or didn’t test, AI has absolutely become a force multiplier for me as a developer.

Back to the topic in question, how does this relate to choosing a programming language? Well, after telling you that popularity is not always a big deal, by the nature of how LLMs work, popularity is a factor. In terms of general use, languages like Python, JavaScript, and Java are likely to have the largest amount of training data. My experience has been that the languages I typically use, such as Kotlin, TypeScript, and Swift also do fine.

But there is a curious side effect of developing Android or iOS applications that I don’t experience so much in web development. The nature of these constantly changing platforms and SDKs, with tens of thousands of third party libraries, dozens of architectures, and endless opinions about best practices and anti-patterns, means that LLMs can have serious troubles with complexity or specificity.

I expect this issue to be fixed as LLM services improve correctness checking or other methods to reduce hallucinations.

Avoid the Sunk-Cost Fallacy

Perhaps the most important point I can make in choosing a programming language is to avoid the sunk-cost fallacy. For the first several years of my part-time studies, I didn’t imagine learning a second language based on how difficult it was for me to learn Java.

Roughly 12 years later, I have written non-trivial code in Java, Kotlin, Swift, C++, TypeScript, and SQL. Further, I have dabbled with code in C, Python, JavaScript, Racket, Haskell, Objective C, Visual Basic, and C#.

It was not the case that I sought out to learn all of these things artificially – I don’t tend to learn things outside of the problems in front of me. It’s that these learning opportunities naturally unfolded along with my personal and professional interests.

Learning the fundamentals or approaching mastery of any general purpose programming language will have carry over to others. It’s true that someone learning Python or JavaScript without CS fundamentals is not going to have much of a clue how things work at the OS level or lower.

It’s also true that I have met several people who could probably code circles around me in C/C++/Assembly but never made it past building toy programs in University or College.

Just keep learning and try to find a balance between personal interest and professional goals.

How to Find the Best Libraries and Frameworks

The next few topics revolve around a question which we’ll revisit a couple of times before the end of this article: “Does it solve more problems than it creates?”

What Are Libraries and Frameworks?

Before we proceed, here’s a useful but not definitive definition about the relationship between libraries and frameworks. You’ll find other definitions, but there’s remarkably little consensus on topics like this in this industry.

For me, a library is code which you can take from somewhere and use it to build things. It could be anything from a single line to a large and complex sub-system – usually something in between. I could give you a long and pedantic definition, but that’s not appropriate for this context (suitability!).

One example could be Java’s Math (java.lang.Math) library, which provides you with the following: “The class Math contains methods for performing basic numeric operations such as the elementary exponential, logarithm, square root, and trigonometric functions.”

Some people use the term framework interchangeably with library, and I don’t have any problems with that. When I think of a framework, I’m thinking about something which you build stuff around and is not necessarily to do with solving a specific problem domain (such as mathematics).

An example of this would be RxJava, which is a rather complex framework you can use to bind together and manage data flows across an entire application. I’ve used this framework in almost a dozen applications which did very different things in principle.

I do consider a framework to be a library, fundamentally – they just have a different set of goals and often a larger footprint.

How to Choose Libraries and Frameworks

When I think about choosing libraries and frameworks, I ask myself these questions:

• Does it solve more problems than it creates compared to writing my own solution?

• Is it well-maintained (regularly worked on, responsive authors, backed by tech companies)?

• Does it have good documentation (less of a problem now that we can leverage AI for this purpose)?

• What kind of footprint does it have?

Let’s take two examples. I won’t refer to the specific platform or name of these libraries to avoid offending anyone. But they were/are both used in mobile development (though they are solving common GUI problems on any platform).

Firstly, one of my favorite libraries had one job: It loads images into the UI.

Although devices are more powerful than they used to be, it can still be a problem to load large images on smart phones for display. Mobile operating systems can be aggressive about killing programs (that is, processes) which use up too much of the system’s resources.

This library handles all aspects of loading images that I’m concerned about:

• Loading the image into a particular widget

• Displaying an appropriate loading indicator

• Displaying an optional error or fallback state that tells the user something went wrong

• Handling the complexities of asynchronously loading in (via URL/URI), processing, and compressing potentially large streams of bits (that is, image data)

• Doesn’t inflate the packaged application’s size unnecessarily

• Doesn’t change its public API frequently (think changing function names which cause people’s implementations to break when updating versions)

• It solves problems that I’m not interested in solving

Secondly, one of my least favorite libraries also had one job: Pagination. Pagination, or paging, in this case refers to loading data in chunks into an application. This is an extremely common pattern in shopping cart or social media applications.

The library I am thinking of approaches that problem like so:

• Tightly couples every layer of your client application (from front end to back end) to its dependencies

• This tight coupling makes testing difficult without jumping through some hoops

• Handles the core problem of pagination well unless you need customization or specialized cases

• Frequently changed its public facing API

• Solved (in general) a problem which I am quite happy to write my own solution for

• Did not play well with other frameworks due to a restrictive set of types and lack of flexibility

• Was constantly updated for a couple of years then ditched and marked deprecated

• Did not inflate the packaged applications size too much but certainly more than my own solution would

As you can see, even something which solves a core problem reasonably well, can still fail this simple test of: Does it solve more problems than it creates? Having written pagination code by myself on a couple of occasions now, I would have to be pretty strongly convinced not to.

How to Find the Best Programming Principles and Practices

There are more best practices and principles than I care to describe in detail. What I will do is explain why I treat programming principles as being distinct from immutable/unbreakable laws. Similarly to my goal of finding the best programming language, I wanted to find the best principles in order to write the best code.

The problem is that any programming principle I’ve come across has also been subject to the Law of Suitability. I’ll discuss one example from personal experience and point out that the question we asked above, “does it solve more problems than creates,” also applies here.

D.R.Y – Don’t Repeat Yourself

This principle can be summarized with the idea that if you find duplicated code, you should pull it into a separate module (file, function, class, library, and so on). Without getting into the weeds, the act of pulling the duplicated code into a separate module can be thought of as a process of abstraction.

To be fair to the creators and proponents of this idea, it’s more nuanced than that. But many developers never bother to dig that deep into nuances – nor should they have to. I ran into the nuances simply by applying this idea more than I should have.

There a couple of cases where code duplication is sometimes preferable:

• You have a set of similar modules (say similar widgets or business rules) but they get used in different places for different reasons

• You have a set of similar modules which might change for different reasons (for example, rapidly changing demands from product teams and clients with different priorities)

• You’re deliberately grouping certain modules that work together in distinct packages, files, or directories to insulate modules/groupings from affecting each other

• You find that you need to add details about one particular implementation into your abstraction, but those details don’t apply to other implementations (that is, it’s a bad abstraction)

All of the things I listed above are summaries of things I have run into in the past. The key take away is that I broadly agree with avoiding code duplication. I also know of some cases where I prefer it. Suitability!

What About Other Programming Principles?

In general, you can think of all programming principles like YAGNI, DRY, SRP (and other aspects of SOLID), and even software development methodologies like AGILE and Waterfall in the same way. Contextually, you can use them as guidelines to help avoid some common problems. But a person of sufficient creativity and experience can come up with a situation where following any of these principles creates more problems than it solves.

In many cases, you need to apply these things too much in order to understand what too much means in practical terms. Just be careful not to swing too far in the other direction when one of these principles really breaks down in front of you. I’ve also made that mistake and had to re-adjust.

To date, I haven’t come across a programming principle which is universally true. There are some which come close to that, but I can always imagine a situation where they’re not the best approach. Take a good one like: Always write the simplest code you can write. In other words, don’t add extra complexity without a reason.

Well, suppose you have a not great value system or incentive structure which encourages inflating your work artificially. Need I say more?

A Note About Patterns and Architectures

I’ll now discuss the topic of patterns and architectures in software systems with respect to the Law of Suitability. Software architecture is the only thing I consider myself an expert in, and I have read multiple books on design patterns. I always try to provide some useful info on these topics when I get the chance.

How to Find the Best Software Architecture

To summarize entire articles, courses, and public talks I have given on this topic: The best software architecture depends on project and personal requirements.

One way to grasp the main idea is to ask yourself whether the best architecture for a hospital is also a good fit for a 2-bedroom apartment. The obvious answer is that we might expect a few commonalities (doors, windows, bathrooms of some kind, and so on) among these different sets of requirements. But the ideal, or even just a good architecture for a 2 bedroom apartment cannot possibly be the same for a hospital.

In short, you will never find an architecture which works well for all projects and requirements.

Here is a list of architectures I have some familiarity with:

• Model-View-Controller

• Model-View-Presenter

• Model-View-ViewModel

• VIPER

• Clean Architecture (Robert C. Martin style)

• Model-View-Intent

To make matters more confusing, there are multiple different ways to implement these architectures – almost as many ways as developers implementing them! M-V-VM is one of the more common architectures in mobile development, and I can think of at least five different variations on how to achieve what some people think of as a single architecture.

Here are my general suggestions for working with these architectures:

• Be wary of adding unnecessary complexity with the more complex architectures (particularly Clean Architecture, as many people get this horribly wrong)

• Don’t try to make the project requirements fit the architecture – work the other way around (the best indicator for this is noticing that something you’re trying to implement is made unnecessarily difficult because of the architecture you’re using)

• Don’t be afraid of applying different approaches in different features of the same application instead of blindly applying the same pattern just for consistency’s sake

The Design Pattern Trap

One of the most common engagement farming tactics I see on social media is to post lists of design patterns “that you must know” in order to get a job or to scare junior programmers into buying your low-quality, copy-pasted content of each pattern.

Don’t get me wrong, I loved studying design patterns and I use a couple key patterns in most GUI applications I build. The Observer (a.k.a. Publisher-Subscriber or Pub-Sub) Pattern really shines when you need to glue together a bunch of asynchronous data sources. I love seeing library developers give me a nice Builder Pattern to work with their APIs. I think understanding the basics of patterns like the Bridge or Facade can teach you how to hide details behind abstractions, which is actually simpler than the big scary words describing these things make it sound.

But I spend very little time in my day to day work thinking about or in design patterns. Instead, I’m always thinking about the kinds of attitudes and principles that give rise to these patterns:

• Promoting loosely coupled code (separating the creation and usage of dependencies and parameters, reasonable usage of abstraction)

• Writing classes, interfaces, protocols, and functions which do one thing (though this “one thing” might be a macroscopic goal instead of a microscopic operation)

• Avoiding complexity wherever possible (a common source of this complexity is over-use of abstractions)

• Not pretending that every complex problem has a simple solution (that is, as simple as it can be but no simpler)

• Avoiding pre-mature optimization

Again, I will only apply these principles and attitudes to the extent that I find they solve more problems than they create. Design patterns, when applied too rigorously, can break many of those principles – particularly when it comes to avoiding complexity and pre-mature optimization.

Don’t try to make your project requirements fit your patterns. Instead, think about which patterns might suit your project requirements and deviate as necessary.

Summary

My goal with this piece was to provide three things:

• A practical overview of choosing a programming language and avoiding the traps the people can fall into when navigating these sorts of topics

• A philosophical but pragmatic framework which you can use to evaluate the suitability of anything – with emphasis on learning and developing software

• A breakdown of how I approach other topics like tools, architectures, and patterns

While it can be important to consider things like job opportunities and your current hardware, don’t discount personal interest as a driving factor. From what little I remember about studying cognition (learning how to learn), interest is tightly coupled to motivation and memory. We can’t always exclusively do what interests us, but I suggest you look for intersections between personal and practical concerns as often as you can.

In closing, I encourage you to think about other areas where you might be able to explore the principles of suitability and the problems of tribalistic thinking. Change is constant and value is relative.

With the release of Swift 6 and its new Embedded Swift compilation mode, developers now have access to a modern, memory-safe, and performant alternative that’s tailored specifically for resource-constrained systems.

While languages like Rust have also emerged to address these issues, Embedded Swift brings the clarity and safety of Swift to microcontroller environments, without giving up on determinism, binary size, or hardware access.

This article introduces Embedded Swift and explores how it compares to traditional C/C++ development. We’ll cover its key features, programming and memory models, how to set up the toolchain for STM32 microcontrollers, and how to link Swift with existing C drivers.

Along the way, we’ll examine performance trade-offs, growing ecosystem support, and the broader industry movement toward memory-safe languages. As I hope you’ll see, Swift is a serious contender in the future of embedded development.

Prerequisites

To get the most out of this article, you should have a basic understanding of programming in Swift and C. Familiarity with embedded hardware platforms and firmware development concepts will also be helpful.

If you're new to embedded systems, consider reviewing this introductory guide to embedded firmware to build foundational knowledge before diving into Embedded Swift.

Scope

This article is intended as a practical introduction to Embedded Swift. It covers:

• An overview of Embedded Swift and its key language features

• Swift’s programming and memory model in an embedded context

• Setting up the Embedded Swift toolchain on macOS for STM32 microcontrollers

• Interoperability with C code and linking to existing low-level drivers

• A look at memory and instruction-level performance

• Future directions and use cases for Embedded Swift

Note that this article does not provide a full tutorial on the Swift language itself. While the primary focus is on STM32, similar principles apply to other supported platforms such as ESP32, Raspberry Pi Pico, and nRF52.

Table of Contents:

• What is Swift? What is Embedded Swift?

• Swift Programming Model

• Swift Memory Management

• Memory and Instruction Cycle Comparison

• How to Setup Embedded Swift

• C-Swift Linkages:

• Future Work

• Conclusion

What is Swift? What is Embedded Swift?

Swift is a modern programming language developed by Apple that combines the performance of compiled languages with the expressiveness and safety of modern language design. While Swift was originally created for iOS and macOS development, it has evolved into a powerful general-purpose language used in server-side development, systems programming, and increasingly, embedded systems.

Embedded Swift is a special compilation mode introduced in Swift 6 that brings the benefits of Swift to resource-constrained platforms like microcontrollers. It lets developers use a safe, high-level language while still producing compact, deterministic, and performant binaries suitable for embedded applications.

Key Features of Swift

Embedded Swift retains many of the powerful language features that make Swift an attractive alternative to C/C++ in embedded development:

Type Safety: Swift uses a strong static type system, which prevents many programming errors at compile time. Unlike C, where type mismatches can result in undefined behavior, Swift ensures all types are used correctly before code even runs.

Strict Type Checking: Swift doesn't allow implicit type conversions that could lose data or cause unexpected behavior. For example:

// This won't compile in Swift
let integer: Int = 42
let decimal: Double = 3.14
let result = integer + decimal  // Error: Cannot convert value of type 'Int' to expected argument type 'Double'

// You must be explicit about conversions
let result = Double(integer) + decimal  // Correct

Non-nullable Types by Default: In C, pointers can be null by default, which introduces risk. In Swift, variables cannot be nil unless explicitly marked as optionals:

var name: String = "John"
name = nil  // Compile error - String cannot be nil

var optionalName: String? = "John"
optionalName = nil  // This is allowed

Memory Safety via ARC (Covered in detail later):

Swift manages memory automatically using Automatic Reference Counting (ARC). Unlike manual memory management in C/C++, ARC handles object lifecycles efficiently without unpredictable garbage collection pauses. We'll cover ARC and its impact in embedded contexts in a dedicated section later.

Modern Syntax:
Swift's syntax is clean, consistent, and designed for readability. It supports modern paradigms including:

• Functional programming (map, filter, reduce)

• Generics (type-safe abstractions)

• Protocol-Oriented Programming (discussed in the next section)

These features allow you to write more expressive and maintainable code compared to procedural C or inheritance-heavy C++.

Performance:
Swift is designed to perform on par with C++ in many scenarios. Optimizations such as inlining, dead code elimination, and static dispatch help ensure that high-level abstractions don’t compromise performance. In embedded mode, Swift disables features like runtime reflection and dynamic dispatch to further reduce overhead.

To fully leverage Swift for embedded development, it's important to understand its programming model. Unlike C’s procedural approach or C++’s class-heavy design, Swift promotes protocol-oriented programming and composition, which offers both flexibility and safety in embedded system design.

Swift Programming Model

Swift embraces a multi-paradigm programming model that blends object-oriented, functional, and protocol-oriented programming, all underpinned by strong type safety and memory safety.

For embedded developers coming from C or C++, this model may feel different at first. But it provides a more modular and testable way to build complex systems, something especially valuable in embedded applications where hardware abstraction and strict reliability are critical.

Protocol-Oriented Programming (POP)

Swift emphasizes protocols over inheritance, encouraging developers to define behaviors through protocols and implement them using value types like struct and enum, rather than relying heavily on classes.

This philosophy favors composition over inheritance, allowing you to build complex functionality by combining smaller, well-defined components.

Key Concepts:

• protocol defines required behavior.

• Protocol extensions provide default behavior.

• Prefer value semantics using struct.

Example:

protocol Speakable {
    func speak()
}

extension Speakable {
    func speak() {
        print("Default sound")
    }
}

struct Dog: Speakable {
    func speak() {
        print("Woof!")
    }
}

Embedded Swift uses protocols with static dispatch. With static dispatch, the compiler knows the exact memory address of the function to call and can generate a direct jump instruction. There's no runtime lookup, no indirection, and no uncertainty.

Why POP Matters for Embedded Systems

First, you get flexible hardware extraction. Protocols make it easy to define interfaces for hardware components, allowing for mock implementations during testing or platform-specific variations.

Second, you have nice low overhead. Embedded Swift uses static dispatch for protocols, meaning there’s no runtime lookup, and calls are resolved at compile time for maximum performance.

Also, struct and enum types avoid heap allocations, making code more efficient and predictable in low-memory environments.

Now that we’ve explored how Swift’s programming model enables safer and more modular embedded code, let’s turn to another critical piece of the puzzle: memory management. Swift’s use of Automatic Reference Counting (ARC) replaces manual memory handling and offers important benefits, and tradeoffs, for embedded systems.

Swift Memory Management

One of Swift’s most impactful features, especially in the context of embedded systems, is its use of Automatic Reference Counting (ARC) for memory management. Unlike C/C++, where memory must be manually allocated and freed using malloc and free, Swift automates this process while maintaining deterministic performance.

This automation significantly reduces the risk of common memory-related bugs like leaks, dangling pointers, or use-after-free errors, all of which are notorious in low-level C code.

How ARC works

Swift supports ARC not only for the Cocoa Touch API's but for all APIs, providing a streamlined approach to memory management. Unlike garbage collection systems that can cause unpredictable pauses, ARC works deterministically at compile time and runtime to manage memory.

ARC automatically tracks and manages the lifetime of objects in memory based on how many references point to them.

• Reference Counting: Every object has a counter that tracks how many strong references point to it.

• Retain / Release: The compiler inserts retain and release calls automatically during assignment and deinitialization.

• Immediate Deallocation: When the reference count reaches zero, the object is deallocated immediately.

• Deterministic: Unlike garbage collectors, ARC doesn’t introduce unpredictable pauses or runtime scanning.

Swift offers multiple reference types to give you precise control over memory behavior and prevent cycles:

Strong References (default)

• Keeps the referenced object alive.

• Used in most cases.

class MotorController {
    var sensor: SensorData?  // Strong reference

    func updateReading(newData: SensorData) {
        self.sensor = newData  // Previous sensor data automatically deallocated
    }
}

Weak References

• Used to break reference cycles (especially in two-way object relationships).

• Automatically becomes nil when the referenced object is deallocated.

class Device {
    var controller: MotorController?

    deinit {
        print("Device deallocated")
    }
}

class MotorController {
    weak var device: Device?  // ← Weak reference breaks the cycle

    deinit {
        print("MotorController deallocated")
    }
}

func breakCycle() {
    let device = Device()
    let controller = MotorController()

    device.controller = controller
    controller.device = device  // ← This is now a weak reference

    // When this function ends, both objects are properly deallocated
}

breakCycle()
// Output:
// Device deallocated
// MotorController deallocated

Unowned References

• Non-optional version of weak.

• Assumes the object will never be deallocated while still in use.

• More lightweight than weak, but unsafe if misused.

class SensorSystem {
    unowned let controller: MotorController  // unowned reference

    init(controller: MotorController) {
        self.controller = controller
    }
}

class MotorController {
    var sensorSystem: SensorSystem?

    func setupSensors() {
        sensorSystem = SensorSystem(controller: self)
    }

    deinit {
        print("MotorController deallocated")
    }
}

func testUnowned() {
    let controller = MotorController()
    controller.setupSensors()
    // sensorSystem deallocates before controller ends
}

testUnowned()
// Output: MotorController deallocated

ARC Overhead in Embedded Systems

While ARC provides safety benefits, it does introduce some overhead compared to manual memory management:

Memory Overhead:

ARC-managed class instances in Swift typically include an additional 4 or 8 bytes to store reference count metadata, depending on the system architecture, 4 bytes on 32-bit systems and 8 bytes on 64-bit systems. This metadata allows the runtime to track how many active references exist to a given object and deallocate it when no references remain. When developers use weak or unowned references, the memory footprint increases further. These references require additional data structures, such as side tables or tracking mechanisms, to manage object liveness and cleanup. In the case of weak references specifically, Swift maintains zeroing weak reference tables that automatically null out pointers once the referenced object is deallocated, ensuring memory safety.

CPU Overhead:

ARC introduces some runtime overhead due to retain and release operations, which are inserted automatically during reference assignments. These operations involve incrementing or decrementing the reference count and are especially common in code that passes objects between functions or stores them in collections. To ensure thread safety, these updates are typically implemented using atomic operations, which add further instruction cycles. In complex object graphs, ARC may also engage in cycle detection and cleanup through the use of weak references to prevent memory leaks caused by strong reference cycles. While Swift's ARC provides deterministic and efficient memory management, it does so with both memory and CPU costs that developers should consider carefully, especially in performance-critical embedded systems.

Type Safety and Error Prevention

Swift's type system prevents many common errors that plague C/C++ programs:

• Buffer Overflows: Swift arrays are bounds-checked, preventing buffer overflow vulnerabilities that are common in C.

• Null Pointer Dereferences: Swift's optional types make null pointer dereferences impossible at compile time.

• Use After Free: Swift's ownership model prevents use-after-free errors that can cause crashes or security vulnerabilities.

Now that we’ve covered Swift's memory model and ARC behavior, let’s explore how it compares to C in terms of memory usage and instruction cycles, a crucial aspect when evaluating Embedded Swift for real-world deployment.

Memory and Instruction Cycle Comparison

Understanding the performance characteristics of Swift versus C is essential for embedded systems, where every instruction cycle and byte of memory matters. While Swift brings advantages like safety and expressiveness, these benefits come with certain trade-offs in terms of memory usage and runtime behavior that embedded developers must evaluate carefully.

Memory Management:

Swift uses Automatic Reference Counting (ARC) to manage memory. ARC tracks the number of references to each object and deallocates it when no references remain. This eliminates the need for explicit free() calls but introduces overhead.

C, in contrast, uses manual memory management. Developers allocate memory using malloc and release it using free, or rely on the stack for most short-lived data.

The table below provides the memory management comparison between Swift and C:

Swift ensures safety through deterministic cleanup and predictable memory usage. But this comes at the cost of added memory and CPU overhead.

C’s approach offers complete control over memory layout and minimal runtime cost, but increases the risk of memory leaks and fragmentation without disciplined practices.

Instruction Cycle Analysis

The safety features in Swift, such as bounds checking, optional unwrapping, and ARC updates, translate into additional CPU instructions. While this can impact performance, the Swift compiler is aggressive about optimization in release builds. For example, inlining and ARC elision can remove much of the overhead in performance-critical paths.

C has no built-in safety checks, allowing it to generate highly efficient, predictable code. Developers can even use inline assembly for tight control over performance.

The table below provides the instruction cycle comparison between Swift and C:

Although Swift inserts extra instructions for safety, much of this cost can be mitigated through compiler optimization.

C has no such features by default, making it ideal for applications where performance must be tightly controlled and the developer is willing to take full responsibility for safety.

Instruction Count Comparison: Swift vs C Loop Performance

When evaluating Swift and C for embedded use, it's helpful to analyze instruction-level performance on basic operations, such as a loop that processes an array of floating-point numbers. This gives us a concrete sense of the computational cost of each language's safety and abstraction features.

Let’s consider a simple example: summing an array of Float values and returning the average. In Swift, the code uses a high-level for-in loop over an array:

Simple loop performance:

// Swift loop with safety checks
func processData(_ data: [Float]) -> Float {
    var sum: Float = 0.0
    for value in data {  // Iterator with bounds checking
        sum += value     // Safe arithmetic
    }
    return sum / Float(data.count)  // Safe division
}
// Estimated: ~8-10 instructions per iteration

Although elegant and safe, this loop includes several safety mechanisms:

1. Bounds checking on every array access

2. Reference counting if data is passed as a reference type

3. Overflow protection in debug mode

4. Optional handling or runtime checks if data might be empty

These checks introduce runtime overhead, resulting in an estimated 8–10 instructions per iteration on most platforms (depending on optimization level and target architecture). In release builds, Swift aggressively inlines and strips redundant checks, but some level of abstraction cost remains, especially compared to raw memory access in C.

Now, compare that to its equivalent in C:

// C loop without safety checks
float process_data(float* data, int count) {
    float sum = 0.0f;
    for (int i = 0; i < count; i++) {  // Direct pointer arithmetic
        sum += data[i];                // Direct memory access
    }
    return sum / count;  // Direct division (no safety check)
}
// Estimated: ~4-5 instructions per iteration

This version performs direct memory access with pointer arithmetic, no bounds checks, and no type safety. The C code is lower-level, with fewer runtime checks, and compiles down to just 4–5 instructions per iteration, depending on the target CPU and compiler flags. It is lean and fast, ideal for cycles-per-instruction-critical scenarios.

The table below shows the comparison of single loop performance between Swift and C:

Now that we’ve compared Swift and C in terms of memory and cycle costs, let’s move into the practical side: how to set up Embedded Swift on an STM32 platform and get started with real-world development.

How to Setup Embedded Swift

In this section, we'll walk through how to configure and use Embedded Swift for development on STM32 microcontrollers. STM32 is a popular family of ARM Cortex-M–based microcontrollers, commonly used in industrial, consumer, and IoT applications.

Prerequisites

Required Software:

• Swift Development Snapshot (includes the Embedded Swift toolchain)

• Swiftly - Easiest way to manage and install swift toolchains

• Swiftc - Swift Compiler command-line tool

• Python3 - Required to run scripts to convert Mach-O to binary files

• Git (to clone sample repositories) like https://github.com/swiftlang/swift-embedded-examples

• A Unix-like development environment (macOS is currently best supported)

Target Hardware: This guide focuses on STM32 microcontrollers, which are widely used in embedded applications and have excellent community support.

This guide walks you through the full setup process, from installing the required Swift toolchain to flashing the final binary onto your board. We’ll begin by installing the Swift Development Snapshot using Swiftly, a simple command-line utility for managing Swift toolchains. From there, we’ll configure the build system, set up the correct board variant, customize the build script, and compile the Swift and C source code into a binary. Finally, we’ll flash the firmware onto the STM32 using standard tools

Install Swift Development Snapshot

The easiest way to install and manage Embedded Swift toolchains is by using the swiftly tool, which simplifies downloading and using Swift snapshots.

macOS Installation:

The below steps will help install the Swift embedded toolchain:

# Using Swiftly (Recommended)
curl -O https://download.swift.org/swiftly/darwin/swiftly.pkg
installer -pkg swiftly.pkg -target CurrentUserHomeDirectory
~/.swiftly/bin/swiftly init --quiet-shell-followup
source "${SWIFTLY_HOME_DIR:-$HOME/.swiftly}/env.sh"

# Install and use development snapshot
swiftly install main-snapshot
swiftly use main-snapshot

# Verify installation
swift --version

You can clone this Github example repository:

git clone https://github.com/swiftlang/swift-embedded-examples.git 
cd swift-embedded-examples/projects/stm32-blink

The stm32-blink contains:

• Swift code that toggles GPIOs

• A C startup file with vector table

• A build.sh script that uses swiftc, clang, and a custom linker setup

Setup the STM32 Board

Tell the build script which STM32 board is being used:

export STM_BOARD=STM32F746G_DISCOVERY

You can add your own board variant by defining the appropriate memory map and compiler flags in the script.

Modify build.sh (Optional)

Ensure the script correctly locates the following:

• swiftc: should point to the toolchain you installed with Swiftly

• clang: can be macOS’s default Clang

• libBuiltin.a, crt0.s, and macho2bin.py: used to provide minimal runtime support and convert output to flashable binaries

If needed, update these paths:

SWIFT_EXEC=${SWIFT_EXEC:-$(swiftly which swiftc)}
CLANG_EXEC=${CLANG_EXEC:-$(xcrun -f clang)}
PYTHON_EXEC=${PYTHON_EXEC:-$(which python3)}

Ensure the linker flags match your target’s flash and RAM sizes.

Build and Flash the Project:

Run:

./build.sh

This compiles Swift and C code, links them, and produces a blink.bin file.

If successful, you’ll see:

.build/blink.bin  # ready to flash Step 6: Flash the Firmware to STM32

Use ST-Link tools or openocd to flash your board. Example using st-flash:

brew install stlink
st-flash write .build/blink.bin 0x8000000

You should now see an LED blinking.

Here’s a more detailed step by step approach to writing a bare metal code on STM32. For comprehensive installation guides covering other platforms (Raspberry Pi Pico, ESP32, nRF52), detailed IDE configuration, troubleshooting, and advanced examples, you can check out the official documentation:

• Complete Setup Guide: Install Embedded Swift

• Platform Examples: Swift Embedded Examples Repository

• Getting Started Tutorial: Embedded Swift on Microcontrollers

Now that we’ve set up Embedded Swift and explored how to build and run an example project, let’s look at a critical real-world scenario: interfacing Swift with low-level C drivers.

C-Swift Linkages

In many embedded projects, low-level hardware drivers are written in C because of its close-to-metal control and widespread ecosystem support. Embedded Swift supports seamless interoperability with C, which lets you reuse existing C libraries and drivers, write hardware control logic in C, and implement higher-level application logic in Swift.

This hybrid model lets you combine Swift’s safety and productivity with C’s hardware-level control, with no runtime overhead or object translation.

Let’s walk through an example where a low-level sensor driver is implemented in C and the application logic is written in Swift.

C Header File (sensor_driver.h):

This C header file defines the public interface for a low-level sensor driver. It includes standard fixed-width integer types and declares four functions:

• sensor_init(): Initializes the hardware sensor

• sensor_read_temperature() and sensor_read_humidity(): Read raw sensor values

• sensor_delay_ms(): Delays execution for a given number of milliseconds

This interface acts as a bridge between Swift and C. Swift will link to these functions by name, no wrappers or bindings required.

#ifndef SENSOR_DRIVER_H
#define SENSOR_DRIVER_H

#include <stdint.h>

// Low-level sensor driver functions
void sensor_init(void);
uint32_t sensor_read_temperature(void);
uint32_t sensor_read_humidity(void);
void sensor_delay_ms(uint32_t milliseconds);

#endif

C Implementation (sensor_driver.c):

This implementation assumes the sensor is memory-mapped at a fixed address (0x40001000). Each register, temperature, humidity, and control, is accessed by offset from that base address.

The sensor_init() function writes 0x01 to the control register, presumably enabling or starting the sensor hardware.

The sensor_read_temperature() method and sensor_read_humidity() method reads from memory-mapped registers and return the raw ADC values from the sensor.

The sensor_delay_ms() method performs a simple busy-wait loop using nop (no-operation) instructions to approximate a delay. This is suitable for short, coarse-grained delays in bare-metal contexts.

#include "sensor_driver.h"

// Hardware register addresses
#define SENSOR_BASE_ADDR    0x40001000
#define TEMP_REG_OFFSET     0x00
#define HUMIDITY_REG_OFFSET 0x04
#define CONTROL_REG_OFFSET  0x08

void sensor_init(void) {
    // Initialize sensor hardware
    volatile uint32_t* control_reg = (volatile uint32_t*)(SENSOR_BASE_ADDR + CONTROL_REG_OFFSET);
    *control_reg = 0x01; // Enable sensor
}

uint32_t sensor_read_temperature(void) {
    volatile uint32_t* temp_reg = (volatile uint32_t*)(SENSOR_BASE_ADDR + TEMP_REG_OFFSET);
    return *temp_reg;
}

uint32_t sensor_read_humidity(void) {
    volatile uint32_t* humidity_reg = (volatile uint32_t*)(SENSOR_BASE_ADDR + HUMIDITY_REG_OFFSET);
    return *humidity_reg;
}

void sensor_delay_ms(uint32_t milliseconds) {
    // Simple delay implementation
    for (uint32_t i = 0; i < milliseconds * 1000; i++) {
        __asm__("nop");
    }
}

Swift Code Using C Driver:

To use these C functions from Swift, you declare them using @_silgen_name, which tells the Swift compiler to link directly to these symbol names at runtime.

The SensorController class encapsulates sensor-related logic. In its init() method, it calls the sensor_init() function defined in C to initialize the sensor hardware.

The readSensors() method reads the raw values from the C driver, converts them into human-readable units using helper functions, stores them internally, and returns the processed values.

The convertTemperature() and convertHumidity() conversion methods apply a basic linear formula to turn raw ADC values into temperature in Celsius and humidity in percentage, respectively. These formulas would be based on the specific sensor’s datasheet.

The checkThresholds() method applies simple threshold logic, a good example of where Swift’s readability and type safety shine. You could easily expand this logic to include error bounds, state machines, or alerts.

// Import C driver functions

/*
These declarations match the C function signatures exactly. 
They allow Swift to invoke the C functions as if they were native Swift functions 
— with zero overhead.
*/
@_silgen_name("sensor_init")
func sensor_init()

@_silgen_name("sensor_read_temperature")
func sensor_read_temperature() -> UInt32

@_silgen_name("sensor_read_humidity")
func sensor_read_humidity() -> UInt32

@_silgen_name("sensor_delay_ms")
func sensor_delay_ms(_ ms: UInt32)

// Swift sensor controller using C driver
class SensorController {
    private var lastTemperature: Float = 0.0
    private var lastHumidity: Float = 0.0

    init() {
        // Initialize the C driver
        sensor_init()
    }

    func readSensors() -> (temperature: Float, humidity: Float) {
        // Read raw values from C driver
        let rawTemp = sensor_read_temperature()
        let rawHumidity = sensor_read_humidity()

        // Convert raw values to meaningful units in Swift
        let temperature = convertTemperature(rawValue: rawTemp)
        let humidity = convertHumidity(rawValue: rawHumidity)

        // Store for comparison
        lastTemperature = temperature
        lastHumidity = humidity

        return (temperature: temperature, humidity: humidity)
    }

    private func convertTemperature(rawValue: UInt32) -> Float {
        // Convert raw ADC value to Celsius
        return (Float(rawValue) * 3.3 / 4095.0 - 0.5) * 100.0
    }

    private func convertHumidity(rawValue: UInt32) -> Float {
        // Convert raw ADC value to percentage
        return Float(rawValue) * 100.0 / 4095.0
    }

    func checkThresholds() -> Bool {
        // Swift logic for threshold checking
        let tempThreshold: Float = 25.0
        let humidityThreshold: Float = 60.0

        return lastTemperature > tempThreshold || lastHumidity > humidityThreshold
    }
}

// Main application loop
func main() -> Never {
    let sensorController = SensorController()

    while true {
        // Read sensors using Swift controller with C driver
        let readings = sensorController.readSensors()

        // Process data with Swift's type safety and expressiveness
        if sensorController.checkThresholds() {
            print("Warning: Temperature: \(readings.temperature)°C, Humidity: \(readings.humidity)%")
        } else {
            print("Normal: Temperature: \(readings.temperature)°C, Humidity: \(readings.humidity)%")
        }

        // Delay using C driver function
        sensor_delay_ms(1000) // 1 second delay
    }
}

The func main() is the main event loop standard for embedded systems. It creates the sensor controller, reads sensor data in a loop, checks thresholds, and prints results accordingly. The loop includes a delay (via the C driver) to avoid hammering the sensor continuously.

In an actual embedded context, instead of using print(), you might blink an LED, send UART messages, or log data to memory.

With Embedded Swift and C now working together, let’s explore what lies ahead. The next section outlines ongoing improvements, emerging use cases, and research directions that are shaping the future of Embedded Swift.

Future Work

Embedded Swift is still a young but rapidly evolving technology. Its modern language features, type safety, and performance make it an attractive option for embedded development, and ongoing work is expanding its capabilities, reach, and ecosystem.

Ongoing Improvements

Compiler Optimizations: The Swift compiler team is actively improving code generation for embedded targets, including:

• Reducing binary size

• Minimizing ARC overhead

• Improving static dispatch performance

Hardware Support: Embedded Swift can target a wide variety of ARM and RISC-V microcontrollers, which are popular for building industrial applications. Support for additional architectures is being developed.

Tooling Enhancements: Tooling support for Embedded Swift is still evolving, but several community-driven and open-source efforts are making development more accessible:

• Build Systems: The Swift Embedded Working Group provides example projects that adapt Swift Package Manager (SwiftPM) for cross-compilation. Custom linker scripts and build helpers are available for platforms like STM32 and nRF52.

• Debugging Support: Developers can debug Embedded Swift programs using existing tools like GDB or OpenOCD, provided the build includes appropriate debug symbols. While not yet officially streamlined, this approach enables step-through debugging on real hardware.

• IDE Integration: There is no official IDE support yet, but some developers use VSCode with Swift syntax highlighting and external build tasks. These setups are still manual but serve as early prototypes for embedded workflows.

Emerging Use Cases

There are a number of emerging use cases for embedded Swift. For example, Swift’s memory safety, type guarantees, and protocol-oriented design make it ideal for secure and scalable IoT devices, especially where firmware bugs could affect user safety or privacy.

The automotive sector is also exploring Swift for infotainment systems, driver assistance features, and safety-critical logic (where deterministic execution and safety matter).

Swift’s expressive syntax and compile-time safety make it suitable for industrial automation – think real-time control loops, sensor fusion systems, and edge devices in smart manufacturing.

It’s also useful for medical devices, as it aligns well with strict medical regulations around memory safety, type guarantees, and predictable resource usage.

Community and Ecosystem

Open Source Projects

The Swift Embedded working group maintains example repositories showcasing how to use Embedded Swift on microcontrollers such as STM32, nRF52, and ESP32. Early-stage libraries for UART, GPIO, and basic peripherals are emerging, though the ecosystem is still young compared to C or Rust.

Learning Resources

While Embedded Swift is not yet widely taught in formal curricula, community tutorials and exploratory projects (for example, Swift for Arduino) are lowering the barrier for hobbyists and independent learners. As tooling matures, educational adoption is likely to follow.

Industry Interest

Embedded Swift is beginning to draw attention from developers and companies looking for safer, more maintainable alternatives to C. Although large-scale adoption remains limited, use cases like rapid prototyping, IoT development, and internal experimentation are gaining traction.

Conclusion

Embedded Swift represents a major step forward in embedded programming. By combining the power and safety of Swift with the low-level control needed for microcontrollers, it offers an exciting alternative to traditional C and C++ development.

While C will remain essential for hardware-level programming and performance-critical paths, Swift brings compelling advantages to many embedded scenarios:

• Memory safety: Swift eliminates entire categories of bugs such as buffer overflows, use-after-free, and null pointer dereferencing.

• Type safety: Many logic errors are caught at compile time, long before they can cause runtime failures.

• Modern language features: Developers can use functional paradigms, generics, and protocol-oriented design even in embedded code.

• C interoperability: Swift works seamlessly with existing C libraries, allowing gradual adoption without rewriting low-level drivers.

• Developer productivity: Clear syntax, automatic memory management, and strong tooling lead to faster development and easier maintenance.

Government and regulatory bodies are increasingly encouraging or mandating the use of memory-safe programming languages to reduce vulnerabilities in critical software systems. For example:

• In 2022, the U.S. National Security Agency (NSA) recommended moving away from unsafe languages like C/C++ for new software projects, promoting memory-safe alternatives.

• In June 2025, the NSA and CISA released a joint Cybersecurity Information Sheet titled “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development”, which emphasized that memory safety flaws remain a persistent risk, and organizations should develop strategies to adopt memory-safe programming languages in new systems.

• The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and NIST have echoed similar guidance in the context of national cybersecurity.

While these documents do not mention Swift explicitly, Swift's strong type system, ARC-based memory model, and compile-time safety guarantees align closely with the goals outlined in these recommendations. As such, it offers a practical, developer-friendly path toward safer embedded development.

Swift may not be the right fit for every embedded system. In applications where every byte of memory or instruction cycle is critical, real-time guarantees are hard requirements, or toolchain maturity is essential (for example, RTOS integration, static analyzers), C or Rust may still be preferred.

But in many modern embedded applications, especially those involving rapid prototyping, fast product iteration, safety-critical or maintainable firmware, and interoperability with existing C codebases, Swift offers a highly productive and safe development experience.

Embedded Swift is still maturing, but its momentum is undeniable. With ongoing compiler work, community-driven examples, and growing interest from developers, it’s poised to play a major role in the future of embedded systems.

Whether you're building an IoT device, a piece of industrial equipment, or a proof-of-concept wearable, Swift can help you write safer, more expressive firmware, without giving up performance or control.

Swift can be especially powerful during the prototyping phase, when the primary goal is to validate functionality quickly and safely. And with its increasing support for multiple hardware platforms, it offers a strong foundation for bringing modern software development practices to the embedded world.

On the other hand, there were (and still are) more general-purpose editors, but they lacked in functionality when it came to more advanced language-specific features like code completion, “go to definition”, and so on. As an example, code highlighting was done using regular expressions.

With the growing number of code editors and programming languages available, this became the classic M*N complexity problem.

But then Microsoft introduced the Language Server Protocol (LSP) as a solution to the problem above, which elegantly transforms this M*N complexity into a more manageable M+N situation.

Table of Contents

• Why Microsoft Created the LSP

• What is the Language Server Protocol (LSP)?

• Language Server Features

• How Does LSP Work?

• Language Server for Go

• LSP Adoption

• Conclusion

• Resources

Why Microsoft Created the LSP

The LSP was initially driven by the needs of VS Code. VS Code had to work with hundreds of different Language Servers as part of its extensions. But there were multiple problems:

• Language mismatch: Language Servers are often written in different languages than the editor (like VS Code's Node.js).

• Performance impact: Language features can be resource-intensive, potentially slowing down the editor.

• Integration complexity: Multiple editors and multiple languages introduces the M*N complexity mentioned above.

Exactly because of that, Microsoft introduced LSP to standardize the communication between language tools and editors, allowing language servers to be written in any language, run separately for better performance, and easily integrate with any LSP-compliant editor. This simplifies language support for both tool providers and editor vendors.

You can find more info in this Language Server Extension Guide.

What is the Language Server Protocol (LSP)?

The LSP separates language servers from code editors (language clients). By making language servers independent processes dedicated to language understanding, the LSP enables any editor to utilize a standard language server. This means that a single standard language server can be used by all editors.

This interoperability is achieved through a defined set of standard messages and procedures that govern communication between language servers and editors. The LSP defines the format of the messages sent using JSON-RPC between the development tool and the language server.

Language Server Features

The list of features may vary for each individual language server, but usually they provide the following functionalities:

• Auto-completion

• Go to definition/declaration

• Find references

• Code formatting

• Diagnostics

• Documentation

And more.

For example, here you can see the list of editor features that gopls (the Go Language Server) provides.

And here you can see the full LSP specification for available features.

There are hundreds of Language Servers out there. Typically, every mature programming language (or markup language) has at least one Language Server. You can see the full list of language servers that implement LSP here.

How Does LSP Work?

The Language Server Protocol is built upon JSON-RPC. It specifically uses JSON RPC 2.0. You can think of JSON-RPC as a remote procedure call protocol that uses JSON for data encoding.

In a nutshell, it works like this. First, the editor establishes a connection with the language server. Then as the developer types code, the editor sends incremental changes to the language server. It then sends back insights like code completion suggestions and diagnostics.

Let’s see one real example for auto-completion. The request from the Language Client (editor) for this case will be:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "textDocument/completion",
  "params": {
    "textDocument": {
      "uri": "file:///home/alex/code/test/main.go"
    },
    "position": {
      "line": 35,
      "character": 21
    }
  }
}

As you can see, it sends the information about current cursor position and the buffer file. Let’s break it down:

• ID: The client sets this field to identify the request uniquely. Once the request is processed, it will return a response with the same request ID so that the client can match which response is for what request.

• Method: A string containing the name of the method to be invoked.

• Params: The parameters to be passed to the method. This can be structured as an array or an object.

Language server can access this file, analyze it, and respond with suggestions:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "isIncomplete": false,
    "items": [
      {
        "label": "Println",
        "kind": 3,
        "insertText": "Println(${1:format}, ${2:a ...interface{}})$0",
        "insertTextFormat": 2,
        "detail": "func Println(a ...interface{}) (n int, err error)",
        "documentation": "Println formats ..."
      },
      // ... other items
    ]
  }
}

Language Server for Go

The most popular and commonly used language server for Go is gopls. It is used by many editors, for example by the Visual Studio Code Go extension. Previously, there was another popular Language Server for Go by the Sourcegraph team called go-langserver, but this is no longer under active maintenance.

Many editors install gopls Language Server automatically if it’s not present on the host machine. But you can install it manually as well:

# check if its' installed and which version
gopls version
# golang.org/x/tools/gopls v0.16.2

# install or upgrade
go install golang.org/x/tools/gopls@latest

gopls also provides an experimental CLI interface:

gopls references ./main.go:35:8

LSP Adoption

The trend is definitely towards LSP adoption. Many editors that didn't initially support it are adding LSP capabilities due to its benefits.

But it's important to note that not all editors use LSP. Classic editors like Vi, Vim (in its basic configuration), and emacs (without specific plugins) traditionally rely on simpler methods for language support, such as syntax highlighting based on regular expressions.

Also, when your editor uses a Language Server, it can have a noticeable impact on CPU and memory, especially for large projects or complex languages. The good news is that you can choose a more efficient language server or disable them in your editor.

Here is how I can inspect what language servers my Zed editor is currently running:

ps aux | grep language-server

node yaml-language-server --stdio
node tailwindcss-language-server --stdio
...

Conclusion

Thanks to the Language Server Protocol, advanced coding capabilities are becoming universally accessible across various programming languages and coding environments.

It’s good to know how your code editors work, so it’s beneficial to have an understanding of this widely used technology called LSP. In short, LSP knowledge helps you understand and better utilize modern coding tools.

LSP is a win for both language providers and tooling vendors.

Resources

• Language Server Protocol

• gopls

• Discover more articles on packagemain.tech

In this guide, we’ll explore the ins and outs of the zip() function with simple, practical examples that will help you understand how to use it effectively.

How Does the zip() Function Work?

The zip() function pairs elements from multiple iterables, like lists, based on their positions. This means that the first elements of each list will be paired, then the second, and so on. If the iterables are not the same length, zip() will stop at the end of the shortest iterable.

The syntax for zip() is pretty straightforward:

zip(*iterables)

You can pass in multiple iterables (lists, tuples, and so on), and it will combine them into tuples.

Example 1: Combining Two Lists

Let’s start with a simple case where we have two lists, and we want to combine them. Imagine you have a list of names and a corresponding list of scores, and you want to pair them up.

# Two lists to combine
names = ["Alice", "Bob", "Charlie"]
scores = [85, 90, 88]

# Using zip() to combine them
zipped = zip(names, scores)

# Convert the result to a list so we can see it
zipped_list = list(zipped)
print(zipped_list)

In this example, the zip() function takes the two lists—names and scores—and pairs them element by element. The first element from names ("Alice") is paired with the first element from scores (85), and so on. When we convert the result into a list, it looks like this:

Output:

[('Alice', 85), ('Bob', 90), ('Charlie', 88)]

This makes it easy to work with related data in a structured way.

Example 2: What Happens When the Lists Are Uneven?

Let’s say you have lists of different lengths. What happens then? The zip() function is smart enough to stop as soon as it reaches the end of the shortest list.

# Lists of different lengths
fruits = ["apple", "banana"]
prices = [100, 200, 150]

# Zipping them together
result = list(zip(fruits, prices))
print(result)

In this case, the fruits list has two elements, and the prices list has three. But zip() will only combine the first two elements, ignoring the extra value in prices.

Output:

[('apple', 100), ('banana', 200)]

Notice how the last value (150) in the prices list is ignored because there’s no third fruit to pair it with. The zip() function ensures that you don’t get errors when working with uneven lists, but it also means you might lose some data if your lists are not balanced.

Example 3: Unzipping a Zipped Object

What if you want to reverse the zip() operation? For example, after zipping two lists together, you might want to split them back into individual lists. You can do this easily using the unpacking operator *.

# Zipped lists
cities = ["New York", "London", "Tokyo"]
populations = [8000000, 9000000, 14000000]

zipped = zip(cities, populations)

# Unzipping them
unzipped_cities, unzipped_populations = zip(*zipped)

print(unzipped_cities)
print(unzipped_populations)

Here, we first zip the cities and populations lists together. Then, using zip(*zipped), we can "unzip" the combined tuples back into two separate lists. The * operator unpacks the zipped tuples into their original components.

Output:

('New York', 'London', 'Tokyo')
(8000000, 9000000, 14000000)

This shows how you can reverse the zipping process to get the original data back.

Example 4: Zipping More Than Two Lists

You aren’t limited to just two lists with zip(). You can zip together as many iterables as you want. Here’s an example with three lists.

# Three lists to zip
subjects = ["Math", "English", "Science"]
grades = [88, 79, 92]
teachers = ["Mr. Smith", "Ms. Johnson", "Mrs. Lee"]

# Zipping three lists together
zipped_info = zip(subjects, grades, teachers)

# Convert to a list to see the result
print(list(zipped_info))

In this example, we are zipping three lists—subjects, grades, and teachers. The first item from each list is grouped together, then the second, and so on.

Output:

[('Math', 88, 'Mr. Smith'), ('English', 79, 'Ms. Johnson'), ('Science', 92, 'Mrs. Lee')]

This way, you can combine multiple related pieces of information into easy-to-handle tuples.

Example 5: Zipping Strings

Strings are also iterables in Python, so you can zip over them just like you would with lists. Let’s try combining two strings.

# Zipping two strings
str1 = "ABC"
str2 = "123"

# Zipping the characters together
zipped_strings = list(zip(str1, str2))
print(zipped_strings)

Here, the first character of str1 is combined with the first character of str2, and so on.

Output:

[('A', '1'), ('B', '2'), ('C', '3')]

This is especially useful if you need to process or pair characters from multiple strings together.

Example 6: Zipping Dictionaries

Although dictionaries are slightly different from lists, you can still use zip() to combine them. By default, zip() will only zip the dictionary keys. Let’s look at an example:

# Two dictionaries
dict1 = {"name": "Alice", "age": 25"}
dict2 = {"name": "Bob", "age": 30"}

# Zipping dictionary keys
zipped_keys = list(zip(dict1, dict2))
print(zipped_keys)

Here, zip() pairs up the keys from both dictionaries.

Output:

[('name', 'name'), ('age', 'age')]

If you want to zip the values of the dictionaries, you can do that using the .values() method:

zipped_values = list(zip(dict1.values(), dict2.values()))
print(zipped_values)

Output:

[('Alice', 'Bob'), (25, 30)]

Now you can easily combine the values of the two dictionaries.

Example 7: Using zip() in Loops

One of the most common uses of zip() is in loops when you want to process multiple lists at the same time. Here’s an example:

# Lists of names and scores
names = ["Alice", "Bob", "Charlie"]
scores = [85, 90, 88]

# Using zip() in a loop
for name, score in zip(names, scores):
    print(f"{name} scored {score}")

This loop iterates over both the names and scores lists simultaneously, pairing up each name with its corresponding score.

Output:

Alice scored 85
Bob scored 90
Charlie scored 88

Using zip() in loops like this makes your code cleaner and easier to read when working with related data.

Conclusion

The zip() function is a handy tool in Python that lets you combine multiple iterables into tuples, making it easier to work with related data. Whether you're pairing up items from lists, tuples, or strings, zip() simplifies your code and can be especially useful in loops.

With the examples in this article, you should now have a good understanding of how to use zip() in various scenarios.

If you found this explanation of Python's zip() function helpful, you might also enjoy more in-depth programming tutorials and concepts I cover on my blog.

Happy coding!

Usually it’s something like “Learn ______”

But how do they decide which language to search for?

“They always joke about Java on Silicon Valley. I guess I should learn that.”

Or:

“Haskell. So hot right now. Haskell.”

Or:

“That Go gopher is just so gosh-darn cute.”

And then there’s the rest of us. We’ll probably search for something like:

“Which programming language should I learn first?”

Few questions are so commonly asked that they get the full infographic treatment. But this is one of them:

_[Image credit](http://carlcheo.com/startcoding" rel="noopener" target="blank" title=")

Deciding on your first programming language can be a fun process — kind of like one of those “Which Quentin Tarantino character are you?” personality quizzes.

But before you run off to learn Ruby because you enjoyed playing with Play-Doh as a kid, let me remind you: the stakes are pretty high here.

It will take you hundreds of hours of practice to become even remotely competent with your first programming language.

So you should consider the following factors:

• the job market for the language

• the long term prospects for the language

• how easy the language is to learn

• what projects you can build while you’re learning (and share with friends so you can stay motivated)

Every year brings new programming languages, and with them, new academic papers. And new web comics.

Seriously. Check out this gem from last month:

When it comes to choosing a first programming language, there’s no shortage of options. To narrow it down a bit, here are the most common Google searches related to learning programming, over the past 12 years:

Java has had its ups and downs.

Python has gradually risen to become the most popular choice.

But tucked away below these is the Little Engine That Could, slowly choo-choo’ing up in popularity over the past few years. And that engine is JavaScript.

Before I talk about these programming languages, let me clarify:

• I’m not arguing that any one language is objectively better than any other

• I agree that developers should eventually learn more than one language

• I’m arguing that first they should learn one language well. And — as you can probably guess from the upside down text in my headline — that language should be JavaScript.

Let’s kick things off by exploring how programming is currently taught in school.

Computer Science 101

Universities have traditionally taught programming under the umbrella of computer science, which itself is often seen as an extension of mathematics, or tie-in to an electrical engineering degree.

Of course, as you may have heard by now:

“Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.” — Eric S. Raymond

Many universities still treat programming like it’s computer science, and computer science like it’s math.

As a result, many introductory programming courses focus on low-level-of-abstraction languages like C, or mathematically-focused languages like MATLAB.

And department chairs generally stay the course, pointing to annual programming language leaderboards like the TIOBE Index, or this one from the IEEE:

Most of these leaderboards look virtually identical to how they were 10 years ago.

But change does happen. Even in academia.

In 2014, Python overtook Java as a the most popular language of instruction at top US Computer Science programs.

And yet another change is bound to… eventually… happen.

Because if you look at the languages actually used by the workforce, it paints a very different picture:

JavaScript is by far the most popular language used by the 49,397 developers who responded to Stack Overflow’s Survey.

More than half of all developers use JavaScript. It’s vital to front-end web development and increasingly relevant for back-end development. And it’s rapidly expanding into areas like game development and the Internet of Things.

Job postings also mention JavaScript more than any programming language other than Java:

_Data from the world’s largest job posting aggregator, [Indeed.com](http://www.indeed.com/jobtrends/q-java-q-python-q-javascript-q-ruby-q-php-q-android-q-ios.html" rel="noopener" target="blank" title=")

It’s no accident that we built our open source community’s curriculum around JavaScript. Over the past two years, more than 5,000 people have used Free Code Camp to get their first developer job.

I’m not advocating JavaScript because I teach it. I teach JavaScript because it’s the surest path to a first developer job.

But is JavaScript right for you? Is it worthy of being your first programming language? Let’s explore those factors I mentioned earlier.

Factor #1: The job market

If you’re learning to program purely out of intellectual curiosity, feel free to skip this factor. But if you — like the vast majority of people learning to program — want to use this skill to get a job, this is an important consideration.

As I mentioned earlier, Java is mentioned in more job postings than any other programming language. JavaScript is a close second.

But here’s the thing about JavaScript: even though it’s been around for 20 years, it only recently became a serious tool that companies like Netflix, Walmart, and PayPal would build entire applications around.

As a result, plenty of companies are hiring JavaScript developers, but there just aren’t that many on the job market.

_Data from [Indeed.com](http://www.indeed.com/jobtrends/q-java-q-python-q-javascript-q-ruby-q-php-q-android-q-ios.html" rel="noopener" target="blank" title=")

There are 2.7 Java developers competing for every open Java position. Competition for PHP and iOS jobs is similarly fierce.

But for every open JavaScript position, there are only 0.6 JavaScript developers. It is very much a sellers’ market for developers with JavaScript skills.

Factor #2: The long term prospects

The average JavaScript project receives twice as many pull requests as the average Java, Python, or Ruby project. And on top of this, JavaScript is growing faster than any other popular language.

The most widely-used programming languages for GitHub projects, which is a good proxy for overall language popularity

JavaScript’s ecosystem also benefits from a heavy investment of money and engineering talent from companies like Google, Microsoft, Facebook, and Netflix.

For example, TypeScript (a statically-typed superset of JavaScript) has more than 100 open source contributors, many of whom are Microsoft and Google employees being paid to work on it.

This type of inter-company cooperation is harder to find with Java. Oracle — who effectively owns Java through its acquisition of Sun Microsystems — often sues companies who try to expand upon it.

Factor #3: Difficulty to learn

_This is a parody of an [XKCD comic](https://xkcd.com/435/" rel="noopener" target="blank" title=").

Most programmers would agree that high-level scripting languages are relatively easy to learn. JavaScript falls into this category, along with Python and Ruby.

Even though universities still teach languages like Java and C++ as first languages, they’re considerably harder to learn.

Factor #4: Projects you can build with it

This is where JavaScript really shines. JavaScript runs on any device that has a browser, right there in the browser. You can build basically anything with JavaScript, and share it anywhere.

Because of JavaScript’s ubiquity, Stack Overflow co-founder Jeff Atwood coined his now-famous law:

“Any application that can be written in JavaScript, will eventually be written in JavaScript.”

And with each passing month, Atwood’s Law holds strong.

Java once promised to run everywhere, too. You may remember Java Applets. Oracle officially killed them off earlier this year.

Python suffers from much the same problems:

“How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it? Um.” — James Hague in Retiring Python as a Teaching Language

By contrast, here are some apps that members of our open source community built in their browsers on CodePen. You can click through and use these right in your browser:

Conway's Game of Life

1970s-style Simon game

Star Wars-themed Wikipedia Search

A rougelike dungeon crawler game

Learn one language well. Then learn a second one.

If you keep jumping from language to language, you won’t get far.

In order to move beyond the basics, you need to learn your first language well. Then your second language will be much, much easier.

From there, you can branch out, and become a more well-rounded developer by learning lots of languages:

• C is a great way to learn how computers actually work in terms of memory management, and is useful in high-performance computing

• C++ is great for game development.

• Python is awesome for science and statistics.

• Java is important if you want to work at large tech companies.

But learn JavaScript first.

OK, now I’m going to attempt the impossible — I’m going to try and anticipate objections from the comments section.

Objection #1: But isn’t JavaScript slow?

JavaScript is — for most practical purposes — as fast as high-performance languages.

JavaScript (Node.js) is orders of magnitude faster than Python, Ruby, and PHP.

It is also nearly as fast as high-performance languages like C++, Java, and Go.

Here are the results of the most comprehensive recent cross-language benchmark:

Objection #2: But JavaScript isn’t statically typed

Like Python and Ruby, JavaScript is dynamically typed, which is convenient. But you can get into trouble. Here I intend for exampleArray to be an array. I set its values, then check its length — meaning the number of elements it contains.

exampleArray = [1, 2]
-> [1, 2]

exampleArray.length
-> 2

But then I accidentally assign it to be a string.

exampleArray = “text”
-> “text”

exampleArray.length
-> 4

These kinds of errors happen all the time in dynamically typed languages. Most developers just put checks in place to prevent them, and write tests accordingly.

If you absolutely must have static typing in your first programming language, then I still recommend you learn JavaScript first. Then you can quickly pick up TypeScript.

“Typescript has a learning curve, but if you already know JavaScript, it will be a smooth one.” — Alex Ewerlöf on TypeScript

Objection #3: But I really want to make a mobile app

I still recommend learning JavaScript first.

1. JavaScript features several tools for making native mobile apps, such as Angular Cordova and React Native.

2. In order for your mobile app to actually do anything interesting, it will probably need a proper back end, which you’ll want to build with a proper web development framework, like Node.js + Express.js.

Also, it’s worth pointing out that the mobile app development’s best days may very well be behind it.

For starters, as much as people use mobile apps, nearly half of all developer jobs are web development. Compare this with a mere 8% of jobs that involve mobile app development.

Developers by occupation, according to the 2023 Stack Overflow Survey. This question had 76,872 responses from developers who took the survey, so it's quite representative.

The grand vision of “there’s an app for that” has not come to pass. Instead, most smartphone owners have stopped downloading new apps.

Sure — they still use apps. Mostly Facebook, Google Maps, and handful of others. As such, much of the demand for mobile app developers is concentrated in a few large employers.

The outlook for those mobile development jobs is hard to forecast. Many aspects of developing, maintaining, and distributing mobile apps are easier with JavaScript. So companies like Facebook and Google are investing heavily in better tools for building these using JavaScript.

Pretty much all development is web development. Everything touches that big platform that is “the web.” And the next wave of devices that you’ll talk to around your home, and cars that pick your kids up from school — they’ll all be piped together using the web, too.

And that means JavaScript.

Objection #4: Isn’t JavaScript a toy language that was written in 10 days?

JavaScript has a quirky history.

You will undoubtedly hear people crack jokes at its expense.

Well people love to hate on C++, too. And like JavaScript, C++ has succeeded despite this hate, and now it’s pretty much everywhere as well.

So if anybody ever gives you a hard time for learning JavaScript instead of elite-language-of-the-week, just remember the famous words of the guy who created C++:

“There are only two kinds of programming languages: those people always bitch about and those nobody uses.” — Bjarne Stroustrup

I only write about programming and technology. If you follow me on Twitter I won’t waste your time. ?

They could've relied on plain English, but that would not be a good solution because of the potential verbosity and ambiguity. So they used specially designed languages for it.

In this article, you'll learn about two of these widely used languages: BNF and EBNF.

Another fascinating aspect of these special languages or notations is that you can write the grammar of your own language using them and give it as input to some magical computer programs called "parser generators". These can output other programs capable of parsing any text according to the grammar you used. How amazing is that?

This feature can save you a lot of time since manually writing such programs is challenging and time-consuming.

Before learning (E)BNF, it's helpful to be able to distinguish between syntax and semantics. So let's start from there.

Syntax vs Semantics in Programming Languages

Syntax refers to the structure of the elements of a language based on its type. On the other hand, semantics are all about the meaning.

Something written syntactically correctly in a language can be completely meaningless. And no text can be meaningful if its syntax is incorrect.

Two of the most famous sentences regarding syntax and semantics are composed by Noam Chomsky:

1. Colorless green ideas sleep furiously.
2. Furiously sleep ideas green colorless.

The first sentence's syntax is correct but it's meaningless. And since the second one is syntactically wrong, it is far from being meaningful.

The same is true for programming languages too. Let's look at the following two JavaScript code snippets to see what I mean.

The following code is syntactically correct but semantically wrong because it's not possible to reassign something to a constant variable:

const name = "Palash";
name = "Akash";

The following is syntactically incorrect and thus does not even have any chance to be semantically correct.

"Palash" = const name;
"Akash" = name;

You check the syntax of your JavaScript code online with a tool like the Esprima Syntax Validator.

There are two more concepts you need to understand before learning to read BNF/EBNF.

Terminals and Non-Terminals

BNF/EBNF is usually used to specify the grammar of a language. Grammar is a set of rules (also called production rules). Here language refers to nothing but a set of strings that are valid according to the rules of its grammar.

A BNF/EBNF grammar description is an unordered list of rules. Rules are used to define symbols with the help of other symbols.

You can think of symbols as the building blocks of grammar. There are two kinds of symbols:

• Terminal (or Terminal symbol): Terminals are strings written within quotes. They are meant to be used as they are. Nothing is hidden behind them. For example "freeCodeCamp" or "firefly".
• Non-terminal (or Non-terminal symbol): Sometimes we need a name to refer to something else. These are called non-terminals. In BNF, non-terminal names are written within angle brackets (for example <statement>), while in EBNF they don't usually use brackets (for example statement).

The whole language is derived from a single non-terminal symbol. This is called the start or root symbol of the grammar. By convention, it is written as the first non-terminal in the BNF/EBNF grammar description.

Finally, you are ready to learn BNF. It's easier than you might think it is.

What is BNF?

BNF stands for Backus–Naur Form which resulted primarily from the contributions of John Backus and Peter Naur.

The syntax of BNF/EBNF is so simple that many people adopted their styles. So in different places, you will most likely see different styles. If the syntax is different from conventional ones, that's usually documented there. In this article I will use one particular style, just to keep things simple.

Below is an example of a simple production rule in BNF:

<something> ::= "content"

Each rule in BNF (also in ENBF) has three parts:

• Left-hand side: Here we write a non-terminal to define it. In the above example, it is <something>.
• ::=: This character group separates the Left hand side from Right hand side. Read this symbol as "is defined as".
• Right-hand side: The definition of the non-terminal specified on the right-hand side. In the above example, it's "content".

The above <something> is just one thing fixed thing. Let's now see all the ways you can compose a non-terminal.

How to compose a non-terminal

BNF offers two methods to us:

• Sequencing
• Choice

You can just write a combination of one or more terminals or non-terminals in a sequence and the result is their concatenation, with non-terminals being replaced by their content. For example, you can express your breakfast in the following ways:

<breakfast> ::= <drink> " and biscuit"
<drink> ::= "tea"

It means the only option for breakfast for you is "tea and biscuit". Note that here, the order of symbols is important.

Let's say someday you want to drink coffee instead of tea. In this case, you can express your possible breakfast items like below:

<breakfast> ::= <drink> " and biscuit"
<drink> ::= "tea" | "coffee"

The | operator indicates that the parts separated by it are choices. Which means the non-terminal on the left can be any such part. Here the order is unimportant, that is there is no difference between "tea" | "coffee and "coffee" | "tea".

That is really all you need to know about BNF to read and understand it and even express the syntax of your own language using it. Believe it or not, it's that simple. And yet it can be used to describe the syntax of many programming languages and other kinds of coding languages.

The thing that makes it possible to break down complex syntax programming languages easily is the ability to define non-terminal symbols recursively.

As a simple example let's see how you express one or more digits in BNF:

<digits> ::= <digit> | <digit> <digits>
<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

If you want to see a simple real-world example of BNF grammar checkout: Semver notation.

What is EBNF?

BNF is fine, but sometimes it can become verbose and hard to interpret. EBNF (which stands for Extended Backus–Naur Form) may help you in those cases. For example, the previous example can be written in EBNF like below:

digits = digit { digit }
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

The braces above mean that its inner part may be repeated 0 or more times. It frees your mind from getting lost in recursion.

One interesting fact is that everything you can express in EBNF can also be expressed in BNF.

EBNF usually uses a slightly different notation than BNF. For example:

• ::= becomes just =.
• There are no angle brackets around non-terminals.

For concatenation, instead of juxtaposition, some prefer `,` to be more explicit. However, I will not use it here.

Don't assume that these styles to be universal. There are several variants of them and they are usually clear from the context. The more important thing to focus on is the new operations it offers like the braces we've seen above.

EBNF extends BNF by adding the following 3 operations:

• Option
• Repetition
• Grouping

Option

Option uses square brackets to make the inner content optional. Example:

thing = "water" [ "melon" ]

So the above thing is either water or watermelon.

Repetition

Curly braces indicate the inner content may be repeated 0 or more times. You have already seen a good example of it above. Below is a very simple one just to make the idea solid in your mind:

long_google = "Goo" { "o" } "gle"

So "Google", "Gooogle", "Gooooooogle" are all valid long_google non-terminal.

Grouping

Parentheses can be used to indicate grouping. It means everything they wrap can be replaced with any of the valid strings that the contents of the group represent according to the rules of EBNF. For example:

fly = ("fire" | "fruit") "fly"

Here fly is either "firefly" or "fruitfly".

With BNF we could not do that in one line. It would look like the following in BNF:

<fly> ::= <type> "fly"
<type> ::= "fire" | "fruit"

The BNF Playground

There is a very nice online playground for BNF and EBNF: Playground.

I recommend you check it out and play with it. It uses a slightly different notation so read the "Grammar Help" section beforehand.

It can test if a string is valid according to the grammar you entered. It can also generate random strings based on your grammar!

For fun this is the syntax of a poem-like text (credit goes to chatGPT):

<poem> ::= <line> | <line> "\n" <poem>
<line> ::= <noun_phrase> " " <verb_phrase> " " <adjective>
<noun_phrase> ::= "the " <adjective> " " <noun> | <noun>
<verb_phrase> ::= <verb> | <verb> " " <adverb>
<adjective> ::= "red" | "blue" | "green" | "yellow"
<noun> ::= "sky" | "sun" | "grass" | "flower"
<verb> ::= "shines" | "glows" | "grows" | "blooms"
<adverb> ::= "brightly" | "slowly" | "vividly" | "peacefully"

Go ahead and copy-paste it into the playground and press the "Generate Random" button to get some mostly meaningless lines of a grammatically correct poem.

Conclusion

BNF and EBNF are simple and powerful notations to write what computer scientists call context-free grammar.

In simple terms it means the expansion of a non-terminal is not dependent on the context (surrounding symbols), that is it's context-free. It is the most widely used grammar form to formalize the syntax of coding languages.

Here are some resources you might find interesting:

• EBNF: How to Describe the Grammar of a Language
• The language of languages
• Parser generators:
  • ANTLR, a very powerful parser generator capable of writing parsers in many languages.
  • If you are a JavaScript person like me and want to get started with a parser generator, take a look at nearly.js for a gentle start.

Below are some real-world grammars written using BNF/EBNF or similar notations that you might find interesting:

• Lisp
• Lua
• Semver
• JavaScript
• JSX
• Python
• Value Definition Syntax in CSS

Thanks for reading. Let me know on Twitter if you have any questions or found this article helpful. Happy learning!

Photo by Ryan Wallace on Unsplash

Coding is one of the most valuable skills to learn today. You can not only build any idea you have and see it come to life, but you can also improve your future.

Knowing how to code increases your chances of getting a higher-paying job.

According to the U.S. Bureau of labor statistics, software engineers earned a median annual salary of $109,020 in 2021.

In addition, the computer programming and software engineering industry is growing fast, and coding jobs are in high demand.

According to the U.S. Bureau of labor statistics, the anticipated change for 2021-2031 is a 25% growth, which is much faster than average.

All the data above sound great, but with hundreds of programming languages available today, choosing the best one to learn can leave you confused, intimidated, or even overwhelmed.

The truth is, there is no one correct answer to the question 'What is the best programming language to learn?'.

The language you choose to learn will depend on many things, such as what you want to build, what projects you want to work on, your individual career goals, the desired path you want to take, or even how much you want to challenge yourself.

In this article, I first explain what programming languages are and go over the differences between programming, scripting, and markup languages.

I also list some of the most popular languages that beginners choose to learn according to the Stack Overflow Developer Survey for 2022.

Here is what we will cover:

1. What are programming languages?
   1. Programming languages vs scripting languages vs markup languages - what's the difference?
2. The most popular programming languages to learn
   1. HTML and CSS
   2. JavaScript
   3. Python
   4. SQL
   5. C++
   6. Java

Let's dive in.

What Are Programming Languages?

Coding involves telling a computer what to do how to do it. You do this by providing it with a sequence of instructions using a language both humans and machines understand.

The machine interprets the instructions and carries them out to achieve a specific result.

Computers do not understand human languages. They only speak binary – a language consisting of 0s and 1s.

In binary, 0 represents off, and 1 represents on.

It makes perfect since that binary is the primary language of all machines since electronic devices have thousands of transistors (or tiny switches) inside them. And the switches turn on or off depending on the flow of electricity.

But coding in binary is time-consuming and very error-prone. So, humans invented computer programming languages that are readable, easier to learn and understand, and much more human-friendly.

Computer programming languages fall into one of two groups: low-level and high-level.

Low-level programming languages have little or no abstraction from the machine's instruction set. Essentially, their instructions are close to the machine's processor's instructions.

Binary code (or machine code) and assembly language are considered low-level programming languages.

High-level programming languages are more human-friendly.

They are similar to human languages and look a lot like English. They offer a shorter, more precise, and less verbose way to create instructions that the computer can understand.

Programming Languages VS Scripting Languages VS Markup Languages - What's the Difference?

At this point, it is worth mentioning that every language fits into a specific category.

There are three categories of languages:

• Programming languages
• Scripting languages
• Markup languages

Programming languages are used for writing logical sets of instructions for computers to execute and solve a problem.

Programming languages are written in a human-readable form but get converted to machine code (binary).

And this conversion happens with the help of a compiler, which fully translates at once all the instructions written in a high-level programming language into something the computer's CPU can easily understand.

Once the instructions are in a machine-readable form, the computer executes them, and they can run on the machine.

Scripting languages go hand in hand with programming languages – you can think of them as a subset or subcategory of programming languages.

The main difference between programming and scripting languages is how each gets compiled.

Scripting languages get intrerpreted rather than compiled.

Scripting languages use an interpreter which translates each instruction, executes it, and then moves on to the next instruction and continues to do the same line by line instead of all at once as a compiler does.

Markup languages are presentational languages and not programming or scripting languages. They are entirely different since they don't involve logical processing.

Markup languages are languages used for defining, describing, and structuring data on a web page. They also lay out and style data on a page.

The Most Popular Programming Languages to Learn

In the following sections, I list some of the most popular languages that beginners choose to learn. I also list their use cases and some resources for you to get started learning them.

HTML and CSS

HTML and CSS are not technically programming languages, but according to the Stack Overflow developer survey for 2022, they rank first as the most popular languages for people learning to code.

HTML and CSS are markup languages, and you use them to create static web pages.

They are two languages you need to learn if you are interested in becoming a frontend developer. You can also learn them alongside JavaScript to add interactivity to the static pages you create.

HTML (which stands for HyperText Markup Language) defines the structure and content of a web page. So, the paragraphs, headings, lists, forms, and links you see on a page, along with their hierarchies, are all HTML code.

And thanks to the latest version of HTML, HTML5, you can embed images, videos, and audio in web pages eliminating the need to use extra plugins like you had to in the past.

CSS (short for Cascading Style Sheets) styles HTML elements. It is responsible for presenting content in a visually appealing way.

CSS code enables all the different colors and fonts. The sizing of elements and how those elements get displayed on the page. The page layout and how items get arranged next to one another.

To learn HTML and CSS, check out the following resources:

• Learn HTML – Beginner's Course
• Learn CSS in this free 6-hour video course
• Learn HTML and CSS with this free 11 hour course
• Learn HTML and CSS in Spanish – Course for Beginners
• Responsive Web Design Certification

JavaScript

According to the Stack Overflow developer survey for 2022, JavaScript has ranked first as the most commonly used programming language for ten consecutive years. And it is the second most popular language for people learning to code.

JavaScript (not to be confused with Java) is a scripting language that lets you add interactivity and dynamic behaviors to otherwise static web pages.

Some interactive features JavaScript can add are:

• A map with a user’s current location
• A message shown to a user once they land on the page
• A change on the page based on user input
• An animation when a user clicks a button
• A smooth scroll effect when there is a button to scroll back up to the top of the page.
• Mouseover effects

One of JavaScript's strengths as a language is that you don't need to compile your code to see the results of your work.

Javascript is built in and runs in browsers, meaning you don't need to install it on your local machine and go through a complicated and error-prone installation process.

JavaScript is used primarily for client-side programming and server-side scripting.

Specifically, JavaScript is used for frontend web development and even backend web development with the help of Node.js, a JavaScript runtime environment for running JavaScript on a server and not just the browser.

Knowing JavaScript is a must if you want to work as a frontend developer, and it is a popular language of choice for backend and full stack web development roles.

To learn more about the differences between frontend and backend web development, give this article a read. And to learn what the job of a full stack web developer entails, give this article a read.

Besides creating complex web applications, JavaScript is also used for creating browser games.

To learn JavaScript, check out the following resources:

• Full JavaScript Course for Beginners
• Learn JavaScript in Spanish – Full Course for Beginners
• Learn JavaScript by Building 7 Games - Full Course
• JavaScript Tutorial: Build Flappy Bird and Doodle Jump
• JavaScript Algorithms and Data Structures certification

Python

Python is a general-purpose server-side scripting language. And according to the Stack Overflow Developer Survey for 2022, it is the third most popular language for people learning to code.

Python is a great language for beginners thanks to its readable, intuitive, concise, and beginner-friendly syntax.

It is a popular language when working with large amounts of data, so it's often used for machine learning, data science, data analysis, and data processing.

It is also the language of choice for web scraping. Web scraping is an automated technique that extracts, collects, and processes large amounts of raw data from the web.

You can also use Python for backend web development to create web applications with the help of frameworks such as Django and Flask.

In addition, Python is a popular language for test automation.

Instead of writing all the tests for your programs manually, you can rely on automation tools, Python libraries, and Python scripts to get the job done.

To get started learning Python, check out the following recourses:

• Python For Beginners Courses Ranked from Best to Worst – freeCodeCamp Edition
• How to Code 20 Beginner Python Projects
• Learn Python by Building 12 Projects in This 3-Hour Course
• Backend Web Development with Python - Full Course

SQL

SQL is short for Structured Query Language.

You will likely hear it pronounced one of two ways – "S. Q. L." (ess-kew-ell) or "sequel" (like a sequel to a movie).

Either way, SQL is a language used for working with databases and any job that involves storing, managing, accessing, and analyzing data. It is one of the languages of choice for data scientists, data analysts, statisticians, and marketers.

Specifically, with SQL, you can access, query, manipulate and interact with data stored in relational databases.

A database is an electronic storage localization for data. In databases, you can easily retrieve and search through your data.

And a relational database stores data in a structured and tabular format. That is, it stores information in tables (which you can think of as storage containers for the data) organized in columns and rows. All data items stored have pre-defined relationships with each other.

With SQL, you can write database queries to perform any CRUD (Create, Read, Update, Delete) operations on the data.

It is worth mentioning that SQL is not technically a programming language - you cannot build web applications or software tools using it. It is a query language and a tool used for managing relational databases and performing operations on the data stored in them.

And although it ranks fifth as the most popular language for people learning to code according to the Stack Overflow Developer Survey for 2022, it ranks third as the most popular language for professional developers.

So, it is a good idea to learn SQL as you may need to use it in a professional setting.

To learn SQL, check out the following resources:

• Learn SQL – Free Relational Database Courses for Beginners
• SQL Commands Cheat Sheet – How to Learn SQL in 10 Minutes
• Learn SQL with These 5 Easy Recipes
• SQL and Databases - A Full Course for Beginners
• Relational Database Certification

C++

In the early 1980s, Bjarne Stroustrup created a language influenced by the C programming language. It could get close to the machine hardware and do demanding low-level computational tasks, but it also provided a higher level of abstraction without losing the low-level efficiency of C.

So, the language 'C with classes' was created, and in 1984 'C with classes' was renamed C++.

C++ is a superset of C and provides additional capabilities to the C language.

C++ allows the programmer close access to and manipulation of the machine while providing efficiency and high performance for large-scale systems. At the same time, it is higher level with enough abstraction away from the machine.

C++ is both a procedural and an object oriented programming language. OOP divides a program into objects.

Everything gets organized and divided into smaller groups of related parts or objects, which are an instance of a class, following a bottom-up approach.

This programming style creates more readable and usable code that is easier to maintain while providing better data security.

C++ is a popular language for:

• creating game engines
• creating computer graphics
• creating applications
• creating VR applications
• creating web browsers such as Google Chrome, Mozilla Firefox, Safari
• creating web browser extensions - the Google Search Engine is built in C++

According to the Stack Overflow Developer Survey for 2022, it ranks sixth as the most popular programming language for people learning to code. And it is a great language if you want to get a software engineering job and develop programs and applications.

To learn C++, check out the following resources:

• How to Learn the C++ Programming Language
• Learn C++ Programming for Beginners – Free 31-Hour Course
• Learn Object Oriented Programming (OOP) in C++ | Full Video Course

Java

Java is an object-oriented, general-purpose programming language whose syntax is based on the C and C++ programming languages.

One of the language's advantages is its portability. Portability in computing means that programs get written once on one machine and can be transferred and run smoothly on another.

The Java Virtual Machine lets Java run on any device and operating system.

Java is used for:

• Building mobile applications for the Android Operating System
• Backend web development
• Game development
• Creating embedded systems
• Building desktop applications
• Building enterprise-level software tools for the banking industry
• Building artificial intelligence and Internet of Things (or IoT) devices

Keep in mind that Java is not the same as JavaScript – they are in no way related to each other despite having the word 'Java' in their names.

JavaScript is an interpreted scripting language that runs in the browser and doesn't need to be compiled.

Java uses a combination of a compiler and an interpreter and runs on machines - not in browsers.

According to the Stack Overflow Developer Survey for 2022, Java ranked 4th as the most popular language for people learning to code.

Java coding skills can help you get a job as a software engineer, a web developer, and an android developer.

To start learning Java, check out the following resources:

• Learn Java – Free Java Courses for Beginners
• The Java Handbook – Learn Java Programming for Beginners
• Learn Java Programming (version 17)
• How to Build a Sudoku Game Java Desktop Application – A Free 2-hour Course

Conclusion

Hopefully, this guide was helpful and gave you some insight into some of the best languages to learn as a beginner programmer.

Thank you for reading, and happy coding!

What is Haskell? What is it used for? Why are there relatively few Haskell programmers? How can I get started with Haskell?

If you're asking yourself these questions, then this article is for you. In it, I'll answer your questions about the Haskell programming language and demystify it for you.

You will learn about the Haskell ecosystem and how to set it up for development. You will also learn the beauty of Haskell and where the language can be applied for real world problem solving.

Given the complexity of Haskell, you should know the basics of programming prior to diving into Haskell. It'll also help if you're very comfortable with another functional programming language to best understand Haskell syntax.

What We'll Cover

• Haskell — A Proper Introduction
• Functional Programming
• Strongly Statically Typed Programming
• The Haskell Ecosystem
• How to Set Up Haskell Development Environment
• The Code Editor
• Hacking into the Beauty of Haskell
• The ghci Compiler
• Python vs Haskell – the Easiest vs the Hardest
• Major Use Cases for Haskell
• Web development: Backend with Spock, Frontend with Elm
• Cardano Blockchain Development with Plutus

Haskell — A Proper Introduction

Haskell is a fully functional programming language that supports lazy evaluation and type classes.

Haskell forces the developer to write very correct code, which is the quintessential nature of the language.

Functional Programming

The world of computer programming allows different programming styles: functional, imperative, object-oriented.

The functional programming style treats functions as the first-class citizens – the most important parts of a program.

In functional programming languages, functions can be passed as values or data types. Functions can be passed as arguments to other functions, returned as results from functions, and assigned to variables. This promotes code reuse in a single codebase.

Haskell is a functional programming language and it supports these properties. Modern Java, C++, Go, and C# are all tethered to the functional style of programming.

Strongly Statically Typed Language

Programming languages can either have a dynamic or static type system. In dynamic typing, values are tagged to data types during execution. This is common among languages like Python and JavaScript which allow implicit conversion between data types.

In static typing, tagging is done during compilation and is common among low-level languages. In statically typed languages, programs are evaluated by the compiler before they are compiled into machine or bytecode and run.

Haskell is statically typed as its programs must be type checked before compilation and execution. Unlike Java and C#, the Haskell compiler only does type checking once, which boosts performance.

Also, Haskell’s type system is called strong because of the error safety at compile time. As such, a common phrase among Haskell developers is, “Once it compiles, it works.”

The Haskell Ecosystem

The most challenging aspect of starting out with a new language is configuring the development environment perfectly.

To install and set up Haskell, you need to grab the entire Haskell ecosystem. The Haskell ecosystem contains:

• The compiler called Glasgow Haskell Compiler (GHC)
• The Interpreter called Glasgow Haskell Interpreter, (GHCi)
• The Stack tool for managing Haskell projects
• Other Haskell packages

You can get the one-for-all software package from www.haskell.org/downloads#platform. Haskell, like every other programming language widely adopted, has a database for its libraries, called Hackage.

How to Set Up the Haskell Development Environment

Linux Environment

If you use a Linux machine, it’s easier to run a shell command. The command below will install the Haskell platform on your machine.

$ sudo apt-get install haskell-platform

Next, type ghc on the Linux command line and hit Enter. This should prompt whether you install the GHCi interpreter or not. Type Y and hit Enter. You should also install the Cabal build tool by running this chain of commands:

$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:hvr/ghc
$ sudo apt install cabal-install

After installation, you should see the following output when you re-run ghci on the shell:

$ ghci
GHCi, version 8.8.4: <https://www.haskell.org/ghc/>  :? for help
Prelude>

Run a simple arithmetic to confirm that ghci works properly.

Windows and Mac OS

The Haskell platform can be gotten from the official download page for both Windows and macOS.

You can install the Cabal libraries tool on Windows from here. You can install it for macOS here.

The Code Editor

Haskell does not have a specially suitable code editor for writing its programs. You can write Haskell code in any of these Code Editors:

• IntelliJ IDEA with the Haskell Plugin installed
• Visual Studio Code with Haskell plugins installed
• Emacs in Haskell Mode
• Neovim

Alternatively, you can also write Haskell code on a “dumb” code editor like Notepad++ and Sublime Text and then compile with the GHC.

What Haskell does is condition you to write codes in bits or modules, reiterating over it to make sure each module is correct and perfect for production. Thus, a smart or dumb code editor has minimal impact whatsoever on the finished code.

Feel free to check for extensions in the code editor marketplaces that will make writing Haskell source files a lot easier, like Haskero or Haskell Runner for VSCode.

Hacking into the Beauty of Haskell

The beauty of Haskell lies in:

• The logic
• The ease of reading Haskell code like mathematical expressions
• You can specify the probable output for a program and the language does the rest
• Its self-documenting nature
• The magnificent GHCi compiler
• The concept of purity

The ghci Compiler

Unlike other programming languages, the ghci compiler allows you to interactively use the compiler.

Also, multi-line coding which isn’t allowed in other compilers is allowed in ghci. For example, if you want to write a full script in Python IDLE, you would have to write it step by step, with each line being complete. But Haskell’s compiler makes it possible to do multi-line coding like this:

$ ghci
GHCi, version 8.8.4: <https://www.haskell.org/ghc/>  :? for help
Prelude> :{
Prelude| 60 +
Prelude| 30
Prelude| :}
90
Prelude>

Python vs Haskel – the Easiest vs the Hardest

Haskell is considered a very hard language to learn and master. On the other hand, Python is considered the easiest and most useful programming language to use.

Given that a lot of programmers are comfortable with Python programming, it is logical to explain Haskell in terms of Python:

1. Haskell is a functional language, as mentioned before, while Python is a mixture of procedural, object-oriented, and functional programming styles. Haskell has procedural programming support, but the side-effects in the language do not make it easy.
2. Python and Haskell have a strong type system, which means explicit conversions have to be done. However, while Python is dynamically typed, Haskell is statically typed.
3. Python is a lot slower than Haskell.
4. As mentioned earlier, Python is easier than Haskell to learn. The learning curve for Haskell is steep, especially for those with no prior functional programming experience.
5. In terms of library support, Python has more libraries and use-cases than Haskell.

Major Use Cases for Haskell

The major uses of the Haskell language today include Web Development and Cardano Blockchain Development.

Haskell for Web Development

You can use Haskell for web development. Just as Python has Flask and Django, Go has Gin, Echo, and Bevel, Haskell has Scotty, Servant, and Yesod all built on top of Wai.

Wai is the Haskell package for managing HTTP requests/responses. Among the three popular Haskell frameworks, Yesod is more of a complete web framework than the others.

Haskell also has the blaze-html package used to build HTML files, similar to gohtml.

Haskell for Cardano Blockchain Development

Cardano is a new blockchain platform that adopts the Proof-of-Stake consensus algorithm. It is the first to allow peer-review research and it was created to address the downsides of Bitcoin and Ethereum.

The Cardano cryptocurrency, ADA, is a popular coin in Japan, and they have ADA ATMs installed in Tokyo.

The Cardano blockchain system is written in Plutus, a Haskell-based, Turing-complete programming language.

Plutus makes use of several tools to build smart contracts on the Cardano blockchain. It has the Plutus Application Backend which provides the environment and tools used to interact with smart contracts. Plutus also provides a fee estimator for in-house cost calculations.

You can preview and run Plutus code on the Plutus Playground.

Since Haskell is a high assurance language built for users in the financial industry, it tackles the problem of transaction exchanged failures due to bad code, and multi-sig failures that enable hackers to steal digital money.

Final Words

Thank you for reading this introduction to Haskell and its ecosystem and main uses. I hope you are inspired to start learning more about it.

In my future articles, you will be able to learn the basics of Haskell programming, as well as more about its main use cases.

If you are just starting out in tech but do not know which path to take, then this article is for you.

If you've started learning, but you're still confused on which programming language or tools to choose, don't worry – we'll discuss that here.

And if you've ever wondered how many tutorials you need to read to become a better programmer, we'll talk about that, too.

Let's begin with which programming language to choose. Then we'll look at how to best use tutorials to make yourself a better programmer.

What Programming Language Do I Learn First?

This question has been asked by almost everyone you know in tech today. There are so many different areas in the tech field, along with a ton of design tools, writing tools, programming languages, frameworks and so on. All this makes your choices quite difficult and possibly overwhelming.

So let's start with one of the most basic questions: which programming language should you learn first?

The most common answer to this question is: "Learn any language you want, and the others will become easy to learn afterwards". I totally agree with this answer.

Sometimes, it might still be difficult to just pick one at random. Here are a few points that will help you make your choice.

Choose a programming language based on your interests

You'll likely learn faster if you have interest in the subject you're learning about. So you might want to ask yourself what your interests in the tech field are.

First, this will help you pick a language that aligns with your interests. And second, it will make it easier and more interesting to learn. Most importantly, you will hardly find a reason to give up.

For example, if you have interest in hardware, you might consider a language that helps you build robotics like C/C++, Python, MATLAB, Java and so on.

If you are interested in animation, you might want to look for a language that is often used for animation like CSS, JavaScript, or Python.

If you love aesthetics, you might want to go for design or frontend development using tools like Figma, Adobe XD, CSS, PhotoShop and others.

If you love writing, you can consider technical writing or documentation using tools like snipper for image capturing, Photoshop for image editing, grammarly for proofreading, and a markdown editor for formatting content.

Choose a programming language based on its community

Most popular programming languages have a large community built up around them. These are people in that field who use the language regularly, and they might even work on or contribute to it if it's open source.

The size and robustness of the community determines how many contributions are made to that language and how much support you might find if you have issues with it.

For example, if you're learning a language like Python that has a large and thriving community, you probably won't have to wait very long before a bug gets fixed if you find one.

JavaScript and its accompanying frameworks or libraries enjoy a large community and this is why there are so many packages built by the people of that community to make building applications with it a lot easier and faster. This also means that the language will last a very long time.

PHP didn't used to have frameworks, but people who use and love the language went ahead and built some for it such as Code Igniter and Laravel. And other devs built packages that you can just add to your code to get a lot done in very little time.

Another benefit of this is that you will have a lot of people with similar interests to network with. If you have a good network, you get to learn not just about the language but also about opportunities around it.

In general, there is usually a higher probability of getting help from a community of 10,000 people compared to a community of 1,000 people.

Choose a programming language based on job availability

Unless you have a particular project you want to build or you work as a freelancer, you should focus on learning a language that many companies use, especially those around your area. This is a practical consideration for when you start looking for a developer job.

So you might want to ask around and find out which languages the companies use that you wish to work for.

For example, it would be wise to learn JavaScript if most companies you want to work for use JavaScript.

Choose a programming language based on your background

Your educational background can also help you choose a programming language to learn. If you learn a programming language related to your background, you will find it easier to pick up and you'll likely make progress more quickly.

For example, if you have a background in statistics and analysis, you will find it more interesting to learn programming languages used for those purposes, such as Python and R. If you have a background in creative art, you might find design and frontend web development more interesting.

Choose a programming language based on your ability to persevere

Every developer (that is, problem solver) should strive to become patient, resilient, and tough. When you're learning to code, you'll have to persevere through a lot of hard times.

And learning some programming languages requires more of these qualities than others.

So you might want to ask yourself the following questions:
"Am I in a hurry to get a job?", "Am I a total tech beginner with no previous programming experience?" or "Am I the type that gives up a little easier?"

If you answered "YES" to those questions, or if you just want to start slow, you should start with a language that is clearer and easier to understand instead of jumping right into a language that might be very complicated.

For example, if you are going into backend web development and you already know or learned JavaScript while doing frontend, it will be easier to go for Nodejs since it is based off the JavaScript syntax.

This will help you focus more on learning backend programming structures, database relationships, and so on. On the other hand, if you jumped straight into PHP, Java, or Python (which have a totally different syntax), things would be more difficult at first.

And then, if you later choose to learn another backend language, it becomes even easier because you already have experience in backend development. So now you can focus on learning the syntax of the new language only.

If you keep these five points in mind when you're choosing a language to learn, you are most likely going to find it a lot easier to find your way.

But after you choose a language, there is another crucial question that bothers many new developers: "How many more tutorials do I need to go through to become a better programmer?" The next section of this article addresses that question.

How many coding tutorials should you go through?

The answer to that question is this: tutorials alone don't make you a better programmer. You don't need to follow tutorials to become a professional programmer. What you really need is constant practice.

Don't get me wrong: I am not saying you shouldn't go through tutorials – but no amount of tutorials will make you a pro.

Programming is just like every other thing you do in this life. You don't learn by just looking (that is, only theory) but rather by also doing (that is, continuous practice).

You don't learn how to drive just by watching someone drive.
You don't learn how to cook just by watching someone cook.
You don't learn how to do anything just by watching someone do it.

Let me relate with you a bit: You get a tutorial and you read or watch it as the case maybe. You see the instructor do everything step by step and it looks so easy – so you feel like you can do it and you say to yourself: "When I need this I will refer to this tutorial" and you move to another tutorial.

Well, this is OKAY. Many of us have made this mistake already so we understand!

But have you ever thought to yourself:

Why are these tutorials usually bug-free?

Why does it take you so much time to do what took the instructor a short time to accomplish?

Now, think about that for a moment!

Well, the answer is simple - the teacher has practiced and thought through the tutorial carefully before coming to teach you!

Just like that teacher, you have to practice constantly. When you practice, this is what will follow:

1. You will come across bugs (problems) – after all, programming is all about problem solving.
2. You go through the pain and joy of solving the problem.
3. When you finally do, you will have really learned something and become a better programmer.

My Advise

Please grab your cup of coffee or tea and follow me:

1. Learn the basics of programming (any language of your choice).
2. Pick up a project (It could be anything ranging from a TODO App, a blog, a portfolio, geo-search app, and so on – here and here are some beginner-friendly project ideas in JavaScript and Python to get you started).
3. Draw out a plan to build the app (This might include how the front-end (UI) looks, how the databases are related or connected, how the back-end works, and so on).
4. Set a reasonable deadline and work towards it (This is very important as it keeps you focused – you know when you are moving fast and when you are slow).
5. Always use Documentation (Don't try to learn everything in the documentation – just focus on what you need for the completion of the project you chose).
6. Don't forget Google Search and Youtube, especially when you run into bugs (Most problems you will run into have been faced by someone and documented online).

Conclusion

Starting out in tech is not easy but anyone can do it with some hard work and determination. In this article, I've explained five points that can help you make a decision about how to start learning.

It is important to note that the qualities mentioned in point five can be built on or worked on over time. So don't give up if it doesn't come easily!

Just remember: PRACTICE! PRACTICE!! PRACTICE!!!

That is what you really need to become a professional programmer. Build projects – lots of them – and use tutorials to help you more fully understand concepts or problems you come across. Some of us have already made this mistake, so learn from us.

If you're struggling to learn your first language, don't worry. It might be because you have not been building stuff. So build something, anything at all, fix bugs, write about what you are learning if you want to. All this will help you grow as a developer.

In this article, I've shared 7 questions I had when I first started learning to code about 20 years ago (man, now I feel old). And I've answered them as thoroughly as possible to help you start your coding journey.

What programming language should I learn first?

In my opinion, it doesn't really matter! There are certainly languages that are easier for beginners to pick up, such as Python, Ruby, or JavaScript. But most programming languages have a plethora of things in common, and the core concepts are usually fairly similar.

In most cases, the syntax (the keywords, structure, and semantics) of languages differ much more than the underlying concepts.

Once you know the basics of any programming language, it becomes a lot easier to pick up another one. It is also likely that the language you learn first won't be the central one you end up using at your job or side hustle.

For example, I started with Python back in the day, dabbled with JavaScript and PhP, but now use Java for my job and side hustle.

Of course, you probably don't want to start by learning some obscure and difficult language that isn't commonly used. But you really can't go wrong by starting with a popular modern language like Python, Java, Ruby, or JavaScript.

The most important part isn't what language you learn first, but that you actually start and incrementally improve your skills over time. In a nutshell, focus on mastering essential coding concepts as opposed to the syntax of a specific language.

How do we categorize programming languages?

Although most programming languages have a lot in common, there are many ways to organize languages into various categories.

These categories are used to group together languages with a particular feature or trait, although two languages with an overlapping trait might very well differ with respect to others.

Here are 5 of the most useful programming language categories for new devs to know about:

• Compiled programming languages

• Interpreted programming languages

• Statically-typed programming languages

• Dynamically-typed programming languages

• Object-oriented programming languages

Below, is a short description of each of these categories, along with a short list of languages in each one.

Compiled programming languages

A compiled language is one that uses a compiler to convert source code (the code you write yourself) into a form the computer knows how to understand (often called machine code).

Usually, the output from the compiler is saved in one or more files called executables. Executables can be packaged for sale and distribution in standard formats that make it easy for users to download, install, and run the program.

An important characteristic of the compiling process is that the source code is compiled before the program is executed by the end user. In other words, code compilation typically takes place separately from program execution.

Popular compiled languages:

• C

• C++

• Java

• Rust

• Go

Interpreted programming languages

An interpreted language is one that uses an interpreter to convert source code (the code you write yourself) into a form the computer knows how to understand.

An interpreter is a program that takes a set of source code written in a specific programming language, converts it into a form the computer can understand, and immediately executes it in real-time.

A primary difference between compiling and interpreting is that the interpreting process has no gap between code conversion and execution – both of these steps happen at program run time or on-the-fly. Whereas with compiling, the code conversion takes place in advance (sometimes far in advance) of program execution.

Popular interpreted languages:

• Python

• JavaScript

• Ruby

Statically-typed programming languages

Static-typing means that the data types of the variables in a programming language are known and established at the time the program is compiled. Furthermore, the datatype of a variable is not allowed to change during program compilation or execution.

For example, each time you create a variable in a statically-typed language, you must explicitly specify the datatype of that variable. This datatype could be an integer, string, boolean, and so on. This is called variable declaration. Once you declare a variable’s data type, it can only hold that type of data throughout the execution of the program.

Popular statically-typed languages:

• C

• C++

• Java

Dynamically-typed programming languages

Dynamic-typing means variable data types are established during program execution, also known as runtime.

Variable data types are not explicitly stated in the source code and variables can be easily reassigned to store values of any datatype on the fly.

Popular dynamically-typed languages:

• Python

• JavaScript

• Ruby

Object-oriented programming languages

Object-oriented programming (OOP) is a coding paradigm that allows programmers to create and work with "objects". An object is a representation or model of something the programmer needs to describe via code.

This probably sounds super vague, because it is. Pretty much anything can be modeled as an "object" in code. Objects often represent real things, such as the products for sale in a store or the customers buying those products.

But objects can also represent digital things such as web forms, and even more abstract stuff like URL endpoints, network sockets, and so on.

Object-oriented programming is usually implemented in a language using Classes. You can think of a class as a template (or model) for the type of object that is being created.

A class contains a set of attributes (properties or characteristics) that define each object of the class. Classes also contain a set of methods (functions) that allow operations to be performed on specific objects of the class.

For example, a "Product" class might have the following attributes:

• Product SKU (unique identifier for each product)

• Product name (descriptive name for each product)

• Product type

• Product price

• Product discount

As mentioned, a class is really just a template for creating objects. Creating an object using a class as a template is known as instantiation. You can create as many objects as you want from the same class, and each object created is known as an instance of that class. The instance is usually stored as a variable in code that you can use as you need it by interacting with its attributes and methods.

Continuing with our example, you can use our "Product" class above to create multiple objects of type "Product". Each product would have its own set of attribute values, such as SKU, name, type, price, and discount.

Representing structured sets of data in this object-oriented fashion can be a very intuitive way for programmers to write and organize their code. This is likely because humans tend to be naturally good at thinking in terms of identifiable entities that exist in the real world.

What's the difference between front-end, back-end, and full-stack development?

As a newer dev, you've likely browsed job opportunities in tech and noticed frequent mention of the terms "front-end", "back-end" and "full-stack".

These terms generally refer to the part of the application you'll be working on. Moreover, they also imply that you'll be working on a software application, usually a web application or mobile app.

The front end refers to the parts of the application that users (also known as "clients") interact with directly. For a web application, the front end is the collection of webpages (and functionality) that are presented in the user's browser. For a mobile app, the front end is the set of screens that the user interacts with on their mobile device.

Development tasks related to the front end include user experience design, user interface creation, client-side networking, integration and use of client-side libraries, and collecting/validating/submitting user input.

As a front-end dev, you'll implement these tasks primarily using HTML to define the structure of web pages, CSS to add styling, and JavaScript to add interactivity.

The back end refers to the parts of the application that run behind the scenes and aren't presented directly to the user/client.

The back end typically includes a web server which handles HTTP connections received from the front-end client (usually a web browser). The web server handles these connections and directs them to the back-end code which performs the logic necessary to respond to the client. This part of the back end is called routing or the API (application programming interface).

The back-end code itself is traditionally a standalone monolith codebase that is deployed as a single unit. But depending on the application's architecture, the back-end code can operate as a set of serverless functions running on a cloud service as opposed to a standalone codebase.

The back-end code validates user input, applies business logic, interacts with data storage such as a database, and crafts a response that gets sent back to the front-end client.

Now that we've covered the front end and back end, full-stack development is easy! :) Full stack simply includes both the front end AND back end! The term "full stack" comes from the term "stack" which is a shortened form of "software stack". The software stack is the collection of tools, frameworks, programming languages, and operating systems that are used to support an application.

What are some popular software stacks?

Now that we know what a software stack is, we'll briefly discuss some popular options for you to choose from.

LAMP Stack (Linux, Apache, MySQL, PHP)

The LAMP stack is a time-tested and industry standard back-end stack that uses the Linux operating system as its foundation. On top of that, you use an Apache webserver to handle web requests and direct them to a PHP codebase. Data is stored in a MySQL database, which is a free and open-source (FOSS) relational database platform.

This stack is great for fairly standardized content-serving websites like blogs.

You might notice that I didn't explicitly mention any front-end tools as being a part of this stack – so this means that LAMP is a back-end stack.

MEAN Stack (MongoDB, Express.js, Angular.js, Node.js)

The MEAN stack is a more modern stack that uses the MongoDB unstructured database platform for storing data. You use Express.js as the back-end web framework and Angular.js for the front end. Finally, you use Node.js to run JavaScript on the back end.

A major benefit of the MEAN stack is that all components are designed to natively operate using the JavaScript programming language, via JSON (JavaScript Object Notation).

Note that this stack's components are geared toward both the front end (Angular.js) and back end (MongoDB, Express.js, Node.js), so MEAN can be considered full stack.

MERN Stack (MongoDB, Express.js, React.js, Node.js)

As you can probably see, the MERN stack is very similar to the MEAN stack except it uses React.js library as the front end instead of Angular.js.

This stack is well suited to devs who like React for its flexible and intuitive style of creating user interfaces.

Notable frameworks

I wanted to take a brief moment to point out two other popular backend frameworks (not stacks) that you can incorporate or swap out for specific components of the stacks mentioned above.

Spring Boot is a Java framework (technically a special case of the broader Spring Framework) that is excellent for developing back-end Java code for web applications and mobile apps. If you are new to Java coding, I highly recommend you check it out.

Django is a Python framework that is specifically crafted for use with the Python programming language. If you prefer building web apps in Python, it is definitely worth looking into.

How do devs collaborate on code without being in the same room?

When I started coding, I opened up a Python text editor on my local machine and created a single file which grew to contain all the code for my project. I quickly found that this became unruly, so I split my code up into several Python .py files (or modules as they are known).

When I coded with a friend, they would usually be sitting there behind me while I typed, or I would be sitting there behind them. If we needed to exchange code snippets or files, we would just send them back and forth via email.

It was years before I learned how devs successfully collaborate while coding, and that it is often done remotely.

The key to successful code collaboration is learning to use a Version Control System (VCS). A VCS is a tool that tracks changes that multiple developers make to code files over time, and enables developers to efficiently work together on the same set files.

Version control systems create a repository that stores the data necessary to recreate any version of the code files as they existed at specific points in time. This is called version control.

Version control systems are very versatile tools, since they serve multiple useful functions for development teams:

• Tracks changes made to code files

• Allows devs to easily share their changes with others and access changes made by others

• Offers simple ways for merging code changes made by multiple devs or teams

• Provides a full-history backup of a project's code as it evolves over time, and a way to efficiently restore any previous version of the code

• Allows developers to easily manage code conflicts made on the same lines of the same files

• Provides various other tools to improve team collaboration and efficiency

There are many version control systems out there, but you've almost certainly heard of one: GitHub.

Actually, GitHub itself is not a version control system. GitHub is a company that provides online hosting for projects using version control. GitHub gets its name from the specific version control system that it uses: Git.

The first version of Git was created in 2005, and it has evolved into by far the most well-known and most popular version control system on the planet. Git is used by the vast majority of development teams today, and it is an essential tool to learn if you plan on coding professionally.

Does it matter what operating system I use?

When it comes to learning to code for the first time, I would answer this question similarly to the first in this list. I think what matters much more than which operating system you have, is that you get started learning as soon as possible with what you have.

That being said, I feel my answer would be a cop-out if I leave it at that. Let's assume you're trying to make an active decision about what OS to choose for coding work.

Taking into account the fact that there are many subjective reasons people prefer their operating system, in my opinion an operating system that provides access to a quality command-line terminal can be very useful to wrap your head around.

For that reason, my preference is using Unix-like operating systems such as a Linux flavor or MacOS if possible for development work. Full disclosure – I develop mostly on MacOS.

My reasoning for this is that learning to work on the command-line (much like learning to use Git) is an essential coding skill to learn. A fully featured and intuitive command line is a core part of software development. In my opinion, Linux and MacOS better incorporate modern command lines than Windows.

What text editor or IDE should I use?

Text editors and IDE's (Integrated Development Environments) have evolved massively over the years, and developers pick favorites for many reasons.

One reason could be that a particular editor or IDE was created specifically for a particular programming language or framework. Another could be that your company uses a specific editor, so that is the one you learned and stuck with. I found this reason to be especially true in my experience.

If you are primarily working with interpreted, dynamically-typed languages such as Python, JavaScript, Ruby, or PHP, I recommend that you start with a GUI-based editor such as Sublime Text or Visual Studio Code. These are two of the most popular text editors out there and provide a plethora of features and customizations to make your life easier as a developer.

If you work with Java, I recommend either Eclipse or IntelliJ IDEA which offer a multitude of features specifically crafted for working in the Java ecosystem.

Finally, regardless of which editor you choose for your main dev work, I recommend that you learn a bit of Vim. Vim is a text editor that is meant to be used directly within your command-line terminal. It definitely takes more time to get used to since you have to learn to use Vim's keyboard commands to interact with your files instead of point-and-click with your mouse.

But in my experience is well worth it. Even if you only learn the basic commands, these will help you immensely if you find yourself browsing through a non-GUI terminal at work, and need to inspect or modify some files.

I highly recommend the built-in Vimtutor program that is downloaded automatically when you install Vim. It walks through the basic directly in your command-line terminal.

Summary

In this article, I discussed 7 questions commonly asked by new coders. We cast a fairly wide net, covering questions about programmings language selection, software dev stacks, operating systems, and text editors.

If there are any questions you have that I didn't cover, feel free to message me at jacob@initialcommit.io.

Next steps

If you got value out of this article, I wrote a book called Coding Essentials Guidebook for Developers which has 14 chapters, each covering a core coding concept, language, or tool.

Topics include computer architecture, the Internet, Command Line, HTML, CSS, JavaScript, Python, Java, SQL, Git, and more.

These topics were meticulously selected to help put together a bigger picture of the development puzzle, instead of focusing on one topic in depth. This might be a good resource for you to check out if you got value out of this article.

There are so many programming languages out there, and more are developed every few years. We have Python, JavaScript, PHP, C++, Ruby, Java, C#, and way too many more to list here.

So you might be wondering – why are there so many programming languages, and do we even need all of them?

In this article, you will learn why developers keep creating more programming languages and how you can choose which one to learn.

The Evolution of Technology and Programming Languages

The first and perhaps the biggest reason why we have so many programming languages is that technology is always evolving. As more technologies come into being and advance, we need more tools that can make software for these technologies.

The programming languages we currently have might not be able to deal with specific problems that arise because of the nature of the languages' capabilities. The issue might be so unique that there are no existing solutions that address their needs, so people or companies decide to create a new language themselves.

Here are some notable examples of programming languages that developed from specific needs:

1. C – Dennis Ritchie and Bell Labs created C in 1972 to overcome older languages' problems. They first used it to run the Unix operating system. Today, it can run on almost all kinds of software and hardware.
2. C++ – Bjarne Stroustrup create C++ in 1985 for two main reasons. The first reason was to upgrade the features of the C programming language, and the second reason was to make it accessible for everyone to use in all fields.
3. PHP – PHP was created in 1994 by Rasmus Lerdorf, and he initially used it for a personal project. Later he improved the language and released it to the public, and developers started using it heavily for web development.
4. Go – Google created Go in 2009 because the languages they worked with at the time took were too slow and inconvenient for certain tasks. Also, Google wanted a programming language that was fast in performance but still relatively simple to read.
5. JavaScript – Netscape created JavaScript in 1995. They initially created it for front end development so both web developers and designers could learn and create website features in a short timeframe. Now we use it for back end, front end, and mobile development.

Different Kinds of Developer Jobs Require Different Languages

Another reason we have so many programming languages is that there are different kinds of developer jobs out there that require different tools.

Think of it like a doctor and their patients. A doctor's job is to treat patients. There are different kinds of illness and injuries, and each one is complex enough to treat with different remedies. So doctors specialize in certain areas such as a cardiology, dentistry, surgery, and so on.

The same is true for programmers. As there are different kinds of software and platforms, each one requiring its own tools and features, programmers can specialize just like doctors.

Here are some developer jobs and the main programming languages they use:

• Game developers use C++ or C# to make video games for PCs and consoles.
• Web developers use HTML, CSS, JavaScript, and PHP to make websites and web applications.
• Mobile app developers use Java and Kotlin to make Android applications or use Swift to make iOS applications.
• Software developers use C++, C#, and Java to make desktop applications, business applications, and system software.
• Data scientists use Python, R, and MatLab to analyze data for scientific research and educational purposes.

These aren't the only languages you can use to perform these tasks. These are just examples of some of the most commonly used.

Developer Have Different Needs and Goals for their Projects

The third reason there are so many programming languages is that not all of them will meet a developer or a company's goals. Different developers have their own goals and priorities, and some programming languages are better suited for certain types of tasks than others.

• Some developers want a programming language that's super fast and performant. Welcome Go or C++. These languages enable very granular control over system resources like memory and threads.
• Other developers want a programming language that can build the program in a few days and not weeks. Say hello to JavaScript! It's hard to find a more versatile language. You can use JS everywhere from the backend to web and mobile apps.
• Then some developers prefer a programming language for a specific task. In 2021 a ton of data science gets delivered in Python.
• And finally, some developers want a programming language that is fun to work with. Try Haskell or Lisp and let me know how it goes :)

How to Choose a Programming Language

Now that you understand why there are so many programming languages, there is one more question you are probably asking next:

Which programming language should I learn?

Luckily, there is a pretty straightforward answer: instead of looking at the programming languages themselves, you should think of your end goals.

What type of programming job do you want to work in? What do you want to build? What do job postings require in your area? Once you look at these factors, you can pick a programming language that helps you achieve your goal.

For example, if your goal is to make a professional website, then learn HTML, CSS, and JavaScript.

If you want to break into game development, then go for C++ and C#.

Or, if you wish to start your career in mobile applications, you should check out Swift for iOS applications and Java or Kotlin for Android applications.

Conclusion

To sum it up, the main reason why there are many programming languages out there is that different problems require different tools to solve them. Each programming language has certain features and characteristics that make it suitable for specific tasks.

Just like how doctor's jobs are divided into various specialties, and each solves complex problems and uses the right tools for their job, the same is true for programming.

I hope this article has answered your questions and given you a better idea of what programming language to choose for your career as a programmer.

If you want to learn more, you can get my free e-book to prepare for technical interviews or start Learning Full-Stack JavaScript.

These two languages are very popular and powerful, but they do have key differences. We will cover them in detail here.

In this article, you will learn:

• The different real-world applications of Python and JavaScript.
• The key syntactic and functional differences between Python and JavaScript.

Let's begin! ✨

🔹 Python VS JavaScript: Real-World Applications

We will start with a quick tour of their real-world applications.

Python

Python has become an essential tool in virtually every scientific application around the world because of its power and versatility. It is a general-purpose programming language that supports different programming paradigms.

It is widely used in scientific and specialized applications, including data science, artificial intelligence, machine learning, computer science education, computer vision and image processing, medicine, biology, and even astronomy.

It is also used for web development. This is where we can start to compare its applications to the applications of JavaScript. Python is used for back-end development, which is the area of web development in charge of creating the elements that users don't see, such as the server side of an application.

JavaScript

While Python can be used to develop the back-end part of a web application, JavaScript can be used to develop both the back-end and the front-end of the application.

The front-end is the part of the application that the user sees and interacts with. Whenever you see or interact with a website or web application, you are using JavaScript "behind the scenes".

Similarly, when you interact with a mobile app, you might be using JavaScript because frameworks like React Native let us write applications that adapt to different platforms.

JavaScript is so widely used in web development because it is a versatile language that gives us the tools we need to develop the components of a web application.

Differences between the applications of Python and JavaScript

In short, developers use Python for a range of scientific applications. They use JavaScript for web development, user-facing functionality, and servers

🔸 Python VS JavaScript: Syntax

Now that you know what they are used for, let's see how they are written and the differences in their syntax.

We will cover the differences in their main elements:

• Code Blocks
• Variable Definitions
• Variable Naming Conventions
• Constants
• Data Types and Values
• Comments
• Built-in Data Structures
• Operators
• Input/Output
• Conditional Statements
• For Loops and While Loops
• Functions
• Object-Oriented Programming

Code Blocks in Python and JavaScript

Each programming language has its own style to define code blocks. Let's see their differences in Python and JavaScript:

How Python defines code blocks

Python relies on indentation to define code blocks. When a series of continuous lines of code are indented at the same level, they are considered part of the same code block.

We use this to define conditionals, functions, loops, and basically every compound statement in Python.

These are some examples:

Use of indentation to define code blocks in Python

💡 Tip: We will see the specific differences between these elements in Python and JavaScript in just a moment. At this moment, please focus on the indentation.

How JavaScript defines code blocks

In contrast, in JavaScript we use curly braces (**{}**) to group statements that belong to the same code block.

These are some examples:

Use of curly braces to define code blocks in JavaScript

Variable Definitions in Python and JavaScript

The assignment statement is one of the most fundamental statements in any programming language. Let's see how we can define a variable in Python and JavaScript.

How to define a variable in Python

To define a variable in Python, we write the name of the variable followed by an equal sign (**=**) and the value that will be assigned to the variable.

Like this:

<variable_name> = <value>

For example:

x = 5

How to define a variable in JavaScript

The syntax is very similar in JavaScript, but we just need to add the keyword **var** or **let** before the name of the variable and end the line with a semicolon (**;**).

Like this:

var <variable_name> = <value>;

💡 Tip: When you define a variable using **var**, the variable has function scope.

For example:

var x = 5;

We can also use the keyword **let**:

let <variable_name> = <value>;

For example:

let x = 5;

💡 Tip: In this case, when we use **let**, the variable will have block scope. It will only be recognized in the code block where it was defined.

Variable definitions in Python and JavaScript

💡 Tip: In JavaScript, the end of a statement is marked with a semicolon (;) but in Python, we just start a new line to mark the end of a statement.

Variable Naming Conventions in Python and JavaScript

Python and JavaScript follow two different variable naming conventions.

How to name variables in Python

In Python, we should use the **snake_case** naming style.

According to the Python Style Guide:

Variable names follow the same convention as function names.

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Therefore, a typical variable name in Python would look like this:

first_name

💡 Tip: The style guide also mentions that "**mixedCase** is allowed only in contexts where that's already the prevailing style, to retain backwards compatibility."

How to name variables in JavaScript

In contrast, we should use the **lowerCamelCase** naming style in JavaScript. The name starts with a lowercase letter and then every new word starts with an uppercase letter.

According to the JavaScript guidelines article by the MDN Web Docs:

For variable names use lowerCamelCasing, and use concise, human-readable, semantic names where appropriate.

Therefore, a typical variable name in JavaScript should look like this:

firstName

Constants in Python and JavaScript

Great. Now you know more about variables, so let's talk a little bit about constants. Constants are values that cannot be changed during the execution of the program.

How to define constants in Python

In Python, we rely on naming conventions to define constants because there are no strict rules in the language to prevent changes to their values.

According to the Python Style Guide:

Constants are usually defined on a module level and written in all capital letters with underscores separating words.

This is the naming style that we should use to define a constant in Python:

CONSTANT_NAME

For example:

TAX_RATE_PERCENTAGE = 32

💡 Tip: This serves as a red warning for ourselves and for other developers indicating that this value should not be modified in the program. But technically, the value can still be modified.

How to define constants in JavaScript

In contrast, in JavaScript we can define constants that cannot be changed in the program, and the variable identifier cannot be reassigned.

But this does not mean that the value itself cannot be changed.

According to the article **const** in MDN Web Docs:

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable—just that the variable identifier cannot be reassigned. For instance, in the case where the content is an object, this means the object's contents (e.g., its properties) can be altered.

To define a constant in JavaScript, we add the keyword **const** before the name of the variable:

const TAX_RATE_PERCENTAGE = 32;

If we try to change the value of the constant, we will see this error:

Therefore, the value cannot be changed.

💡 Tip: To run and test small code snippets of JavaScript code, you can use the console in Chrome Developer Tools.

Data Types and Values in Python and JavaScript

Let's see the main differences between Python and JavaScript data types.

Numeric Data Types

Python has three numeric types to help us perform precise calculations for scientific purposes. These numeric types include: int (integers), float (floating-point numbers), and complex. Each one of them has its own properties, characteristics, and applications.

In contrast, JavaScript has only two numeric types: **Number** and **BigInt**. Integers and floating-point numbers are both considered to be of type **Number**.

According to the article Number in MDN Web Docs:

A number literal like 37 in JavaScript code is a floating-point value, not an integer. There is no separate integer type in common everyday use. (JavaScript now has a BigInt type, but it was not designed to replace Number for everyday uses. 37 is still a Number, not a BigInt.)

None vs. null

In Python, there is a special value called **None** that we typically use to indicate that a variable doesn't have a value at a particular point in the program.

The equivalent value in JavaScript is **null**, which "represents the intentional absence of any object value" (source).

The undefined Value

In JavaScript, we have a special value that is assigned automatically when we declare a variable without assigning an initial value.

This is an example:

As you can see, the value of the variable **x** is **undefined**.

In Python, you have to assign an initial value to the variable. We can't declare it without an initial value.

💡 Tip: You can assign **None** as the initial value of a variable in Python to represent the absence of a value.

Primitive Data Types in Python and JavaScript

Primitive data types represent the most fundamental values that we can work with in a programming language. Let's compare the primitive data types of these two languages:

• Python has four primitive data types: Integers (int), Floats (float), Booleans (bool), and strings (str).
• JavaScript has seven primitive data types: undefined, Boolean, String, Number, BigInt, Symbol, and null (source).

How to Write Comments in Python and JavaScript

Comments are very important to write clean and readable code. Let's see how you can use them in Python and JavaScript:

Single-Line Comments

• In Python, we use a hashtag (**#**) to write a comment. All the characters on the same line after this symbol are considered part of the comment.
• In JavaScript, we write two slashes (**//**) to start a single-line comment.

This is a graphical example:

In Python:

# Comment

In JavaScript:

// Comment

Multi-Line Comments

• In Python, to write a multi-line comment we start each line with a hashtag.
• In JavaScript, multi-line comments start with a **/*** and end with a ***/**. All the characters between these symbols are considered part of the comment.

In Python:

# Multi-line comment 
# in Python to explain
# the code in detail.

In JavaScript:

/* 
Multi-line comment 
in JavaScript to explain 
the code in detail.
*/

Built-in Data Structures in Python and JavaScript

The built-in data structures in Python and JavaScript also have key differences.

Tuples

• In Python, we have a built-in data structure called tuple that is very similar to a list but immutable. Therefore, it cannot be changed during the execution of the program, so it is used to store data that should not be modified.
• In JavaScript, there isn't a built-in data structure with these characteristics. Although you can implement a similar data structure with certain features of the language.

Lists vs. Arrays

• In Python, lists are used to store a sequence of values in the same data structure. They can be modified, indexed, sliced, and used in the program.
• In JavaScript, an equivalent version of this data structure is called array.

This is an example:

Hash Tables

• In Python, there is a built-in data structure called dictionary that helps us map certain values to other values and create key-value pairs. This works as a hash table.
• JavaScript doesn't have this type of built-in data structure, but there are certain ways to reproduce its functionality with certain elements of the language.

Operators in Python and JavaScript

Operators are essential to write expressions in any programming language. Let's see their key differences in Python and JavaScript.

Floor Division

While most of the arithmetic operators work exactly the same in Python and JavaScript, the floor division operator is a little bit different.

• In Python, the floor division operation (also called "integer division") is represented with a double slash (**//**).
• In JavaScript, we don't have a particular floor division operator. Instead, we call the **Math.floor()** method to round down the result to the nearest integer.

Comparing Values and Types

In Python, we use the **==** operator to compare if two values and their data types are equal.

For example:

# Comparing Two Integers
>>> 0 == 0     
True
# Comparing Integer to String
>>> 0 == "0"
False

In JavaScript, we also have this operator but it works a little bit differently because it converts the two objects to the same type before actually performing the comparison.

If we check the result of the "integer vs. string" comparison from the previous example using JavaScript (0 == "0"), the result is **True** instead of **False** because the values are converted to the same data type before being compared:

In JavaScript, to check if the value and the data type are both equal, we need to use this operator **===** (a triple equal sign).

Now we get the result that we were expecting:

Awesome, right?

💡 Tip: The **==** operator in Python works like the **===** operator in JavaScript.

Logical Operators

• In Python, the three logical operators are: **and**, **or**, and **not**.
• In JavaScript, these operators are: **&&**, **||**, and **!** (respectively).

Type Operators

• In Python, to check the type of an object we use the **type()** function.
• In JavaScript, we use the **typeof** operator.

This is a graphical description of their syntax:

Input and Output in Python and JavaScript

Asking for user input and displaying values to the user are very common operations. Let's see how you can do this in Python and JavaScript:

Input

• In Python, we use the **input()** function to ask for user input. We write the message within parentheses.
• In JavaScript, one alternative (if you are running the code on a browser) is to display a small prompt with **window.prompt(message)** and assign the result to a variable.

The main difference between these two approaches is that in Python, the user will be prompted to enter a value in the console while in JavaScript, a small prompt will be displayed on the browser and it will ask the user to enter a value.

💡 Tip: You will see this in the Python console to enter a value:

In JavaScript, if you open Chrome Developer tools and enter this line of code in the console:

This prompt will be displayed:

Prompt displayed when window.prompt() is called

Output

• In Python, we print a value to the console with the **print()** function, passing the value within parentheses.
• In JavaScript, we print a value to the console using **console.log()**, passing the value within parentheses as well.

💡 Tip: If you are working on a browser, you can also call **alert()** to display a small prompt with the message (or value) passed within parentheses.

Conditional Statements in Python and JavaScript

With conditionals, we can choose what happens in the program based on whether a specific condition is **True** or **False**. Let's see their differences in Python and JavaScript.

if Statement

• In Python, we rely on indentation to indicate which lines of code belong to the conditional.
• In JavaScript, we have to surround the condition with parentheses and the code with curly braces. The code should also be indented.

Conditional in Python (left) and JavaScript (right)

if/else Statement

The else clause is very similar in both languages. The only difference is that:

• In Python, we write a colon (**:**) after the **else** keyword
• In JavaScript, we surround the code that belongs to this clause with curly braces (**{}**) .

Multiple Conditions

To write multiple conditions:

• In Python, we write the keyword **elif** followed by the condition. After the condition, we write a colon (:) and the code indented on the next line.
• In JavaScript, we write the keywords **else if** followed by the condition (surrounded by parentheses). After the condition, we write curly braces and the code indented within the braces.

Conditional in Python (left) and JavaScript (right)

Switch in JavaScript

• In JavaScript, we have an additional control structure that we can use to choose what happens based on the value of an expression. This statement is called **switch**.
• Python doesn't have this type of built-in control structure.

This is the general syntax of this statement:

Switch statement in JavaScript

In JavaScript:

switch (expression) {
    case value1:
        // Code
        break;
    case value2:
        // Code
        break;
    case value3:
        // Code
        break;
    default:
        // Code
}

💡 Tip: We can add as many cases as we need and the expression can be a variable.

For Loops and While Loops in Python and JavaScript

Now let's see how we can define different types of loops in Python and JavaScript and their main differences.

For Loops

The syntax to define a for loop in Python is relatively simpler than the syntax in JavaScript.

• In Python, we write the keyword for followed by the name of the loop variable, the keyword in, and a call to the range() function specifying the necessary parameter(s). Then, we write a colon (:) followed by the body of the loop indented.
• In JavaScript, we have to specify several values explicitly. We start with the for keyword followed by parentheses. Within those parentheses, we define the loop variable with its initial value, the condition that must be False to stop the loop, and how the variable will be updated on every iteration. Then, we write curly braces to create a code block and within the braces we write the body of the loop indented.

For Loop in Python (left) and JavaScript (right)

Iterating Over Iterables

We can use a for loop in Python and JavaScript to iterate over the elements of an iterable.

• In Python, we write the keyword for followed by the loop variable, the in keyword, and the iterable. Then, we write a colon (:) and the body of the loop (indented).
• In JavaScript, we can use a **for .. of** loop. We write the for keyword followed by parentheses and within those parentheses, we write the keyword var or let followed by the loop variable, the keyword of, and the iterable. We surround the body of the loop with curly braces and then we indent it.

For Loop in Python (left) and JavaScript (right)

In JavaScript, we also have **for .. in** loops to iterate over the properties of an object.

According to MDN Web Docs:

The for...in statement iterates over all enumerable properties of an object that are keyed by strings (ignoring ones keyed by Symbols), including inherited enumerable properties.

This is an example:

const object = { a: 1, b: 2, c: 3 };

for (const property in object) {
  console.log(property, object[property]);
}

The output when we run this code in the console of Chrome Developer Tools is:

While Loops

While loops are very similar in Python and JavaScript.

• In Python, we write the keyword while followed by the condition, a colon (:), and in a new line, the body of the loop (indented).
• In JavaScript, the syntax is very similar. The differences are that we have to surround the condition with parentheses and the body of the loop with curly braces.

While Loop in Python (left) and JavaScript (right)

do..while Loops in JavaScript

In JavaScript, we also have a type of loop that doesn't exist in Python.

This type of loop is called a **do..while** loop because it does something at least once and it continues running while a condition is True.

This is the basic syntax:

do {
    // Code
} while (condition);

💡 Tip: This type of loop guarantees that the code will be executed at least once.

This is particularly helpful when we ask for user input because the user will be prompted to enter the input. If the input is valid, we can continue with the program. But if it's not valid, we can prompt the user to enter the value again until it is valid.

Functions in Python and JavaScript

Functions are incredibly important to write concise, maintainable, and readable programs. The syntax is very similar in Python and JavaScript, but let's analyze their key differences:

• In Python, we write the keyword **def** followed by the name of the function, and within parentheses the parameters list. After this list, we write a colon (:) and the body of the function (indented).
• In JavaScript, the only differences are that we define a function using the **function** keyword and surround the body of the function with curly braces.

Function in Python (top) and JavaScript (bottom)

In addition, there is a very important difference between Python and JavaScript functions:

Number of Function Arguments

• In Python, the number of arguments passed to the function call has to match the number of parameters defined in the function definition (unless default values have been assigned for them in the function definition). If this is not the case, an exception will occur.

This is an example:

>>> def foo(x, y):
    print(x, y)


>>> foo(3, 4, 5)
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    foo(3, 4, 5)
TypeError: foo() takes 2 positional arguments but 3 were given

• In JavaScript, this is not necessary since parameters are optional. You can call a function with fewer or more arguments than the parameters that were defined in the function definition. Missing arguments are assigned the value **undefined** by default and extra arguments can be accessed with the **arguments** object.

This is an example in JavaScript:

Notice how the function was called with three arguments but only two parameters were included in the parameters list of the function definition.

💡 Tip: To get the number of arguments passed to the function, you can use arguments.length within the function.

Object-Oriented Programming in Python and JavaScript

Both Python and JavaScript support Object-Oriented Programming, so let's see how you can create and use the main elements of this programming paradigm.

Classes

The first line of a class definition is very similar in Python and JavaScript. We write the keyword **class** followed by the name of the class.

The only difference is that:

• In Python, after the name of the class, we write a colon (**:**)
• In JavaScript, we surround the content of the class with curly braces (**{}**)

Class definition in Python (left) and JavaScript (right)

💡 Tip: In Python and JavaScript, class names should start with an uppercase letter and each word should start with an uppercase letter as well.

Constructor and Attributes

The constructor is a special method that is called when a new instance of the class (a new object) is created. Its main purpose is to initialize the attributes of the instance.

• In Python, the constructor that initializes the new instance is called **init** (with two leading and trailing underscores). This method is called automatically when an instance of the class is created to initialize its attributes. Its parameters list defines the values that we have to pass to create the instance. This list starts with **self** as the first parameter.
• In JavaScript, the constructor method is called **constructor** and it has a parameters list as well.

💡 Tip: In Python, we use **self** to refer to the instance while in JavaScript we use **this**.

To assign values to the attributes in Python, we use this syntax:

self.attribute = value

In contrast, we use this syntax in JavaScript:

this.attribute = value;

Class Example in Python (left) and JavaScript (right)

Methods in Python and JavaScript

• In Python, we define methods with the **def** keyword followed by their name and the parameters list within parentheses. This parameters list starts with the **self** parameter to refer to the instance that is calling the method. After this list, we write a colon (**:**) and the body of the method indented.

This is an example:

class Circle:

    def __init__(self, radius, color):
        self.radius = radius
        self.color = color

    def calc_diameter(self):
        return self.radius * 2

• In JavaScript, methods are defined by writing their name followed by the parameters list and curly braces. Within the curly braces, we write the body of the method.

class Circle {

    constructor(radius, color) {
        this.radius = radius;
        this.color = color;
    }

    calcDiameter() {
        return this.radius * 2;
    }
}

Instances

To create instances of a class:

• In Python, we write the name of the class and pass the arguments within parentheses.

my_circle = Circle(5, "Red")

• In JavaScript, we need to add the **new** keyword before the name of the class.

my_circle = new Circle(5, "Red");

🔹 To Summarize

Python and JavaScript are very powerful languages with different real-world applications.

Python can be used for web development and for a wide range of applications, including scientific purposes. JavaScript is mainly used for web development (front-end and back-end) and for mobile app development.

They have important differences, but they both have the same basic elements that we need to write powerful programs.

I hope you liked this article and found it helpful. Now you know the key differences between Python and JavaScript.

⭐ Subscribe to my YouTube channel and follow me on Twitter to find more coding tutorials and tips.

Rust is a systems programming language that you can use to write applications with high performance. Rust is used by some of the top tech companies like Dropbox and Cloudflare to deliver speed and concurrency to their customers.

For the last five years in a row, Rust has been voted as the most loved programming language.

But chances are, you might not have worked with Rust. Or worse, you might not have heard of it before. So let's learn more about it.

StackOverflow 2020 Survey

Why Rust?

Let’s look at why a developer would choose Rust.

Typical programming languages like Python and C++ abstract a lot of details away from developers.

If you are a junior developer working on a simple web application, this might not an issue. You just want to find a solution to a problem.

For large scale applications that millions of users will use on a daily basis, the ‘problem-solving’ approach will not work. More users consume more system resources. And more resources mean bigger bills for your company.

This is where Rust shines. Rust combines ease of programming with access to core system configurations. Rust is built with memory-safety, concurrency, and security from the ground up.

Rust is a “systems programming language that focuses on speed, memory safety, and parallelism”.

Rust is also considered to be a great alternative for C++. Rust offers high performance in addition to helping you eliminate common bugs caused by languages like C++.

Now that you know what Rust can do for you, let's look at Rust in detail.

 Origins

Rust is an open-source programming language. It was first introduced to the world in 2010 by Graydon Hoare, while he was working at Mozilla. Shortly after, Mozilla began sponsoring this project and is still a core contributor to Rust.

Rust started gaining popularity over the years. Even Microsoft uses Rust to build secure and safety-critical software components.

 Core Features

Let's look at some core features that make Rust stand out from other programming languages.

Performance

Rust was built to be high performance form the ground up. Rust offers fine-grained control of memory management and has a minimal standard library.

Source: Figma

If you look at some of the metrics shared by Figma, they had incredible improvements in performance once they switched to Rust.

Rust’s low memory footprint also makes it an ideal choice for embedded systems programming. You can use Rust to write software for IoT devices like home automation hubs, smart security systems, and so on.

Security

One of the major reasons Microsoft decided to root for Rust is its security.

The majority of vulnerabilities in Microsoft software were due to poor memory management in C & C++. This lead to simple yet powerful exploits like the Buffer Overflow exploit that had crippled Windows for years.

So Microsoft decided to look for the best alternative to C++. And they found Rust.

Using Rust eliminates an entire class of security vulnerabilities from software applications. This helps companies build applications with better performance and higher security.

Concurrency

Concurrency is when two or more tasks start, run, and complete in overlapping time. Database operations are a great example to explain concurrency.

When thousands of users are using your application at the same time to perform different actions, your database handles them concurrently. Concurrency is a key concept when it comes to scaling applications.

Concurrency and parallelism are also built into Rust. Rust solves most of the concurrency problems during compile time by using the concept of Ownerships. Learn how Rust handles concurrency here.

Working With Rust

Now that you understand the core features of Rust, let's write a few lines of code. You can find installation instructions here if you want to try out Rust on your computer.

Let's start with a simple “Hello World!” function.

// Main function
fn main() {
    println!("Hello World!");
}

Yep. That's pretty much it. Let's try to add two numbers.

// Main function
fn main() {
    let a = 100;
    let b = 200;
    println!("Result is {}",a+b);
}

Again, pretty standard. Now let's look at an array operation.

// Main function
fn main(){
    let arr:[i32;4] = [1,2,3,4];
    println!("array size is {}",arr.len());
}

If you look at line 3, we use “:[i32;4]”. Here we tell Rust that we are declaring an array of length 4 with 32-bit integers.

Declaring data types in detail is a key factor in improving the performance of a program. You are helping the compiler save time by explicitly declaring what type of data you are about to assign to a variable.

Letting the compiler figure out the data type is one of the main reasons you run into performance issues while scaling your application.

Also, Rust is a statically typed language, which means it must know the types of all variables at compile time.

Though Rust is syntactically similar to C and C++, don't let its simplicity fool you. Rust does come with a steep learning curve. But it is totally worth it once you get a good grasp of the basics.

Who Uses Rust?

Now that you have a good grasp of what Rust is, let's look at who uses Rust.

Microsoft

Once a fierce adversary of open source, Microsoft is now an avid contributor to a number of open-source projects. Their .net core project is one of the most popular open-source frameworks used by developers today.

Microsoft has chosen Rust for security and performance-critical applications. Rust is also used extensively in Azure, especially in its IoT Edge platform to run AI applications on IoT devices.

Dropbox

Dropbox uses Rust to improve its data center efficiency. Rust is now powering core services of Dropbox serving more than 500 million users.

Dropbox recently wrote a detailed article on how they re-wrote their core engine.

In Dropbox’s own words,

Rust has been a force multiplier for our team, and betting on Rust was one of the best decisions we made.

Rust was also a contributing factor that helped Dropbox move its infrastructure from AWS to its own data centers.

Figma

Figma is a cloud-based designing and prototyping tool that you can use in your browser. It is an excellent tool for designing, prototyping, and exporting your designs into code. Learn more about Figma here.

Concurrency is crucial for a collaborative tool where many users will be working on a single design at a time. Figma used Rust to write a high-performance server that helped them scale their product and achieve the performance they were looking for.

Here is the article Figma wrote about their experience with Rust.

TL;DR

Rust is a systems programming language that has been voted as StackOverflow’s most loved programming languages, four years in a row.

Rust gives you control over low-level details and provides remarkable improvements in speed and stability.

It has helped companies like Dropbox, Figma, and Microsoft build better applications for their customers.

The language is being increasingly adopted by companies looking to scale their applications with higher performance and concurrency. Sounds interesting? Start learning Rust here.

I regularly write about Machine Learning, Cyber Security, and DevOps. You can signup for my weekly newsletter here.

It has been several years since Kotlin came out, and it has been doing well. Since it was created specifically to replace Java, Kotlin has naturally been compared with Java in many respects.

To help you decide which of the two languages you should pick up, I will compare some of the main features of each language so you can choose the one you want to learn.

These are the 8 points I'll discuss in this article:

• Syntax

• Lambda Expressions

• Null Handling

• Model Classes

• Global Variables

• Concurrency

• Extension Functions

• Community

Syntax comparison

To start it all let's do some basic syntax comparison. Many of you who are reading this might already have some knowledge about Java and/or Kotlin, but I will give out a basic example below so we can compare them directly:

Java

public class HelloClass { 

    public void FullName(String firstName, String lastName) {
        String fullName = firstName + " " + lastName;
        System.out.println("My name is : " + fullName); 
    } 

        public void Age() { 
        int age = 21;
        System.out.println("My age is : " + age); 
    } 

    public static void main(String args[]) { 
        HelloClass hello = new HelloClass(); 
        hello.FullName("John","Doe");
        hello.Age();
    } 
}

Kotlin

class NameClass {
    fun FullName(firstName: String, lastName:String) {
        var fullName = "$firstName $lastName"
        println("My Name is : $fullName")
    }
}

fun Age() {
    var age : Int
    age = 21
    println("My age is: $age")
}

fun main(args: Array<String>) {
    NameClass().FullName("John","Doe")
    Age()
}

The feel of the code isn't that different aside from some small syntax changes in the methods and classes.

But the real difference here is that Kotlin supports type inference where the variable type does not need to be declared. Also we don't need semicolons ( ; ) anymore.

We can also note that Kotlin does not strictly enforce OOP like Java where everything must be contained inside a class. Take a look at fun Age and fun main in the example where it is not contained inside any class.

Kotlin also typically has fewer lines of codes, whereas Java adheres more to a traditional approach of making everything verbose.

One advantage of Kotlin over Java is Kotlin's flexibility – it can choose to do everything in the traditional OOP approach or it can go a different way.

Lambda Expressions

If we are talking about Java and Kotlin, of course we have to talk about the famous lambda expression. Kotlin has native Lambda support (and always has), while lambda was first introduced in Java 8.

Let's see how they both look.

Java

//syntaxes
parameter -> expression
(parameter1, parameter2) -> { code }

//sample usage
ArrayList<Integer> numbers = new ArrayList<Integer>();
numbers.add(5);
numbers.add(9);
numbers.forEach( (n) -> { System.out.println(n); } );

Kotlin

//syntax
{ parameter1, parameter2 -> code }

//sample usage
max(strings, { a, b -> a.length < b.length })

In Java, the parentheses are more lenient: if only one parameter exists, there is no need for parenthesis. But in Kotlin brackets are always required. Overall, however, there are not many differences aside from syntax.

In my opinion, lambda functions won't be used much aside from using them as callback methods. Even though lambda functions have so many more uses, readability issues make it less desirable. They'll make your code shorter, but figuring out the code later will be much more difficult.

It's just a matter of preference, but I think it's helpful that Kotlin enforces the mandatory brackets to help with readability.

Null Handling

In an object oriented language, null type values have always been an issue. This issue comes in the form of a Null Pointer Exception (NPE) when you're trying to use the contents of a null value.

As NPEs have always been an issue, both Java and Kotlin have their own way of handling null objects, as I will show below.

Java

Object object = objServ.getObject();

//traditional approach of null checking
if(object!=null){
    System.out.println(object.getValue());
}

//Optional was introduced in Java 8 to further help with null values

//Optional nullable will allow null object
Optional<Object> objectOptional = Optional.ofNullable(objServ.getObject());

//Optional.of - throws NullPointerException if passed parameter is null
Optional<Object> objectNotNull = Optional.of(anotherObj);

if(objectOptional.isPresent()){
    Object object = objectOptional.get();
    System.out.println(object.getValue());
}

System.out.println(objectNotNull.getValue());

Kotlin

//Kotlin uses null safety mechanism
var a: String = "abc" // Regular initialization means non-null by default
a = null // compilation error

//allowing null only if it is set Nullable
var b: String? = "abc" // can be set null
b = null // ok
print(b)

For as long as I can remember, Java has been using traditional null checking which is prone to human error. Then Java 8 came out with optional classes which allow for more robust null checking, especially from the API/Server side.

Kotlin, on the other hand, provides null safety variables where the variable must be nullable if the value can be null.

I haven't really used optional class yet, but the mechanism and purpose seems pretty similar to Kotlin's null safety. Both help you identify which variable can be null and help you make sure the correct check is implemented.

Sometimes in code there might be just too many variables lying around and too many to check. But adding checking everywhere makes our code base ugly, and nobody likes that, right?

In my opinion, though, using Java's optional feels a bit messy because of the amount of code that needs to be added for the checks. Meanwhile in Kotlin, you can just add a small amount of code to do null checking for you.

Model Class

Some people might also refer to this as the Entity class. Below you can see how both classes are used as model classes in each language.

Java

public class Student {

     private String name;
     private Integer age;

     // Default constructor
       public Student() { }

     public void setName(String name) {
         this.name = name;
     }

     public String getName() {
         return name;
     }

     public void setAge(Integer age) {
         this.age = age;
     }

     public Integer getAge() {
         return age;
     }
}

Kotlin

//Kotlin data class
data class Student(var name: String = "", var age: Int = 0)

//Usage
var student: Student = Student("John Doe", 21)

In Java, properties are declared as private, following the practice of encapsulation. When accessing these properties, Java uses Getters and Setters, along with the isEqual or toString methods when needed.

On the Kotlin side, data classes are introduced for the special purpose of model classes. Data classes allow properties to be directly accessed. They also provide several in-built utility methods such as equals(), toString() and copy().

For me, data classes are one of the best things Kotlin offers. They aim to reduce the amount of the boilerplate code you need for regular model classes, and they do a really good job of that.

Random Pic because you are halfway there! Photo by [Unsplash](https://unsplash.com/@dinoreichmuth?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Dino Reichmuth / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit)

Global Variables

Sometimes your code might need a variable needs to be accessed everywhere in your code base. This is what global variables are used for. Kotlin and Java each have their own ways of handling this.

Java

public class SomeClass {
    public static int globalNumber = 10;
}

//can be called without initializing the class
SomeClass.globalNumber;

Kotlin

class SomeClass {
    companion object {
        val globalNumber = 10
    }
}

//called exactly the same like usual
SomeClass.globalNumber

Some of you might already be familiar with the static keyword here since it's also used in some other language like C++. It's initialized at the start of a program's execution, and is used by Java to provide global variables since it is not contained as an Object. This means it can be accessed anywhere without initializing the class as an object.

Kotlin is using quite a different approach here: it removes the static keyword and replaces it with a companion object which is pretty similar to a singleton. It let's you implement fancy features such as extensions and interfacing.

The lack of the static keyword in Kotlin was actually quite surprising for me. You could argue that using the static keyword might not be a good practice because of its nature and because it's difficult to test. And sure, the Kotlin companion object can easily replace it.

Even then, using static for global variable should be simple enough. If we are careful with it and don't make it a habit of making every single thing global, we should be good.

The companion object might also give us some flexibility with interfacing and such, but how often will we ever be interfacing singleton classes?

I think static keywords help us keep things short and clean for global variables.

Concurrency

Nowadays, concurrency is a hot topic. Sometimes the ability of a programming language to run several jobs concurrently might help you decide if that will be your language of choice.

Let's take a look at how both languages approach this.

Java

// Java code for thread creation by extending 
// the Thread class 
class MultithreadingDemo extends Thread 
{ 
    public void run() 
    { 
        try
        { 
            // Displaying the thread that is running 
            System.out.println ("Thread " + 
                  Thread.currentThread().getId() + 
                  " is running"); 

        } 
        catch (Exception e) 
        { 
            // Throwing an exception 
            System.out.println ("Exception is caught"); 
        } 
    } 
} 

// Main Class 
public class Multithread 
{ 
    public static void main(String[] args) 
    { 
        int n = 8; // Number of threads 
        for (int i=0; i<n; i++) 
        { 
            MultithreadingDemo object = new MultithreadingDemo(); 
            object.start(); 
        } 
    } 
}

Kotlin

for (i in 1..1000)
    GlobalScope.launch {
        println(i)
    }

Java mostly uses threads to support concurrency. In Java, making a thread requires you to make a class that extends to the in-built Java thread class. The rest of its usage should be pretty straightforward.

While threads are also available in Kotlin, you should instead use its coroutines. Coroutines are basically light-weight threads that excel in short non-blocking tasks.

Concurrency has always been a hard concept to grasp (and also, to test). Threading has been used for a long time and some people might already been comfortable with that.

Coroutines have become more popular lately with languages like Kotlin and Go (Go similarly has goroutines). The concept differs slightly from traditional threads – coroutines are sequential while threads can work in parallel.

Trying out coroutines, though, should be pretty easy since Kotlin does a very good job explaining them in their docs. And one bonus for Kotlin over Java is the amount of boilerplate code that can be removed in Kotlin.

Extension Functions

You might be wondering why I'm bringing these up since Java itself doesn't even have this feature.

But I can't help but mention it, because extension functions are a very useful feature that was introduced in Kotlin.

fun Int.plusOne(): Int {
    return this + 1
}

fun main(args: Array<String>) {
    var number = 1
    var result = number.plusOne()
    println("Result is: $result")
}

They allow a class to have new functionality without extending it into the class or using any of the fancy Design Patterns. It even lets you to add functionality to Kotlin variable classes.

You can practically say goodbye to those lib method that need you to pass everything inside your parameters.

Community

Last but not least, let's talk about something non-technical. First, let's take a look at this survey showing top commonly used programming languages in 2020.

taken from stack overflow survey

We can see that Java is one of the most commonly used languages. And while Kotlin is still rising a lot in popularity, the Java community still remains several times larger than Kotlin and it will probably not change anytime soon.

So what does that matter then? Actually it does matter, a lot. With the amount of people in the Java community, it's much easier to find references and get help when you need it, both on the Internet and in the real world.

Many companies are also still using Java as their base and it might not change anytime soon even with Kotlin's interoperability with Java. And usually, doing a migration just doesn't serve any business purpose unless the company has really really important reasons for it.

Wrapping up

For those just scrolling for the summary, here's what we discussed:

• Syntax: the patterns don't differ that much aside from slight syntax differences, but Kotlin is more flexible in several aspects.

• Lambda Expressions: the syntax is almost the same, but Kotlin uses curly brackets to help readability.

• Null Handling: Java uses a class to help with null handling while Kotlin uses in-built null safety variables.

• Model Classes: Java uses classes with private variables and setter / getter while Kotlin supports it with data classes.

• Global Variables: Java uses the static keyword while Kotlin uses something akin to sub-classes.

• Concurrency: Java uses multi-threading whereas Kotlin uses coroutines (which are generally lighter).

• Extension Functions: a new feature introduced by Kotlin to easily give functionality into classes without extending it.

• Community: Java still reigns supreme in the community aspect which makes it easier to learn and get help.

Photo by [Unsplash](https://unsplash.com/@glenncarstenspeters?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Glenn Carstens-Peters / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit)

There are many more features we could compare between Java and Kotlin. But what I've discussed here are, in my opinion, some of the most important.

I think Kotlin is well worth picking up at the moment. From the development side it helps you remove long boilerplate code and keep everything clean and short. If you are already a Java programmer, learning Kotlin shouldn't be too hard and it's okay to take your time at it.

Thanks for reading! I hope that this article will help you decide which programming language you should pick, Java or Kotlin. And for anything that I'm missing, feel free to leave feedback for me as it will be very much appreciated.

One day I came across this tweet from Lari Mazza:

As a software engineer who learned Python, Ruby, JavaScript, and Clojure first, when I tried C++ it was a horror movie. I couldn't do much, and it was so counterproductive and frustrating. Maybe because I was doing everything wrong and I didn't understand types the right way.

But even though I had so many problems, I could implement a bunch of algorithms and data structures.

Now that I'm using more and more TypeScript in my day-to-day job and my side projects, I feel I'm more prepared to confront types. Actually, not confront, but use them in my favor.

This post is my attempt to help developers think more in types and understand this mental model.

Thinking in JavaScript types

If you're here, you've probably heard that TypeScript is a superset of JavaScript. If not, great, you just learned something new today. YAY!

TypeScript is a superset because any JavaScript code is valid in TypeScript, syntactically speaking. It may or may not compile depending on the TypeScript compiler configuration. But in terms of syntax, it works just fine.

This is why you can migrate JavaScript to TypeScript progressively by just replacing the .js extension with the .ts. Everything will be without type declarations (the any type), but that's another story.

Also, if you code in JavaScript - or any other programming language - you probably think in types:

• "Hm, it is a list of integers, so I'll need to filter only the even numbers and return a new list"
• "This is an object, but I just need to get this string value from the property X"
• "This function receives two parameters. Both A and B are integers and I want to sum them"

Yeah, you get the idea. We think in types. But they are just in our heads. We constantly think about them because we need to know how to handle, parse, or modify data. We need to know which methods we are allowed to use in this object type.

To give a more concrete example, imagine you want to sum the price of all products. A product object looks like this:

const product = {
  title: 'Some product',
  price: 100.00,
};

But now with a list of products:

const products = [
  {
    title: 'Product 1',
    price: 100.00,
  },
  {
    title: 'Product 2',
    price: 25.00,
  },
  {
    title: 'Product 3',
    price: 300.00,
  }
];

Ok! Now we want a function to sum all the products prices.

function sumAllPrices(products) {
  return products.reduce((sum, product) => sum + product.price, 0);
};

sumAllPrices(products); // 425

Just receive the products as the argument and reduce all product prices. JavaScript works just fine. But while building this function you start to think about the data and how to handle it properly.

The first part: products as an argument. Here you just think: "well, we're receiving a list of some objects". Yeah, in our heads the products are a list. This is why we can think of using the reduce method. It is a method from the Array prototype.

Then we can think about the object in detail. We know that the product object has a price property. And this property is a number. This is why we can do product.price and sum with the accumulator.

Recapping:

• products is a list of objects.
• As a list, we can use the reduce method, as this method is a member of the Array prototype.
• The produce object has some properties. One of them is the price, which is a number.
• As a number property, we can use it to sum with the reduce accumulator.
• We wanted to return a number, the sum of all products prices.

We are always thinking of data types, we just need to add the type annotations to make it more explicit and ask the compiler for help. Our memory is limited and the compilers are here to help us, humans.

The type system will not only make our data more consistent, but it can also provide autocompletion for data types. It knows the types, so it can show the members for the data. We will take a look at this idea later. Here I just wanted to show that we think in types in our heads.

Simples Types & Simple Uses

So we are ready to use some strongly typed programming languages like TypeScript. We simply need to explicitly add type annotations to our data structures. It's simple, right?

But sometimes it's not that easy (usually it's not easy when you come from dynamically typed languages. You feel unproductive. It feels like a battle against types). The idea here is to make this learning curve smoother and more fun.

Here we will see many examples of how to use types in TypeScript. We'll start with easy and silly examples and progressively make it more complex while designing the mental model to think in types.

As in JavaScript, TypeScript also has basic data types like number, string, boolean, null, etc. You can find all the basic data types in the TypeScript Docs.

With these units of data, we can make our programs more useful. To be more practical, let's get a simple example. A sum function.

How does it work in JavaScript?

function sum(a, b) {
  return a + b;
}

Everything ok? Good.

Now let's use it:

sum(1, 2); // 3
sum(2, 2); // 4
sum(0, 'string'); // '0string'   WTF!

The first two calls are what we expect to happen in our system. But JavaScript is very flexible, it lets us provide any value to this function.

The last call is bizarre. We can call with a string, but it will return an unexpected result. It doesn't break in development, but it will result in strange behavior in runtime.

What do we want? We want to add some constraints to the function. It will only be able to receive numbers. That way, we narrow the possibility of having unexpected behaviors. And the function return type is also a number.

function sum(a: number, b: number): number {
  return a + b;
}

Great! It was very simple. Let's call again.

sum(1, 2); // 3
sum(2, 2); // 4
sum(0, 'string'); // Argument of type '"string"' is not assignable to parameter of type 'number'.

As we type annotate our function, we provide information to the compiler to see if everything is correct. It will follow the constraints we added to the function.

So the first two calls are the same as in JavaScript. It will return the correct calculation. But in the last one we have an error in compile time. This is important. The error now happens in compile time and prevents us from shipping incorrect code to production. It says that the string type is not part of the set of values in the number type universe.

For basic types, we just need to add a colon followed by the type definition.

const isTypescript: boolean = true;
const age: number = 24;
const username: string = 'tk';

Now let's increase the challenge. Remember the product object code we wrote in JavaScript? Let's implement it again, but now with the TypeScript mindset.

Just to remember what we are talking about:

const product = {
  title: 'Some product',
  price: 100.00,
};

This is the product value. It has a title as string and the price as number. For now, this is what we need to know.

The object type would be something like this:

{ title: string, price: number }

And we use this type to annotate our function:

const product: { title: string, price: number } = {
  title: 'Some product',
  price: 100.00,
};

With this type, the compiler will know how to handle inconsistent data:

const wrongProduct: { title: string, price: number } = {
  title: 100.00, // Type 'number' is not assignable to type 'string'.
  price: 'Some product', // Type 'string' is not assignable to type 'number'.
};

Here it breaks down into two different properties:

• The title is a string and should not receive a number.
• The price is a number and should not receive a string.

The compiler helps us to catch type errors like that.

We could improve this type annotation by using a concept called Type Aliases. It's a way to create a new name for a specific type.

In our case, the product type could be:

type Product = {
  title: string;
  price: number;
};

const product: Product = {
  title: 'Some product',
  price: 100.00,
};

It's better to visualize the type, add semantics, and maybe reuse in our system.

Now that we have this product type, we can use it to type the products list. The syntax looks like this: MyType[]. In our case, Product[].

const products: Product[] = [
  {
    title: 'Product 1',
    price: 100.00,
  },
  {
    title: 'Product 2',
    price: 25.00,
  },
  {
    title: 'Product 3',
    price: 300.00,
  }
];

Now the function sumAllPrices. It will receive the product and return a number, the sum of all product prices.

function sumAllPrices(products: Product[]): number {
  return products.reduce((sum, product) => sum + product.price, 0);
};

This is very interesting. As we typed the product, when we write product., it will show the possible properties we can use. In the product type case, it will show the properties price and title.

sumAllPrices(products); // 425
sumAllPrices([]); // 0
sumAllPrices([{ title: 'Test', willFail: true }]); // Type '{ title: string; willFail: true; }' is not assignable to type 'Product'.

Passing the products will result in the value 425. An empty list will result in the value 0. And if we pass an object with a different structure - TypeScript has a structural type system and we will dig deep into this topic later - the compiler will throw a type error telling that the structure is not part of the Product type.

Structural Typing

Structural typing is a type of type compatibility. It's a way to understand the compatibility between types based on its structure: features, members, properties. Some languages have type compatibility based on the names of the types, and it's called nominal typing.

For example, in Java, even if different types have the same structure, it will throw a compile error because we are using a different type to instantiate and define a new instance.

class Person {
  String name;
}

class Client {
  String name;
}

Client c = new Person();  // compiler throws an error
Client c = new Client();  // OK!

In nominal type systems, the relevant part of a type is the name, not the structure.

TypeScript, on another hand, verifies the structural compatibility to allow or not specific data. Its type system is based on structural typing.

The same code implementation that crashes in Java, would work in TypeScript.

class Person {
  name: string;
}

class Client {
  name: string;
}

const c1: Client = new Person(); // OK!
const c2: Client = new Client(); // OK!

We want to use the Client type, and it has the property name, to point to the Person type. It also has the property type. So TypeScript will understand that both types have the same shape.

But it is not only about classes, but it works for any other "object".

const c3: Client = {
  name: 'TK'
};

This code compiles too because we have the same structure here. The TypeScript type system doesn't care about if it is a class, or an object literal if it has the same members, it will be flexible and compile.

But now we will add a third type: the Customer.

class Customer {
  name: string;
  age: number;
};

It not only has the name property, but also the age. What would happen if we instantiate a Client instance in a constant of type Customer?

const c4: Customer = new Client();

The compiler will not accept that. We want to use the Customer, that has name and age. But we are instantiating the Client that has only the name property. So it doesn't have the same shape. It will cause an error:

Property 'age' is missing in type 'Client' but required in type 'Customer'.

The other way around would work because we want Client, and Customer has all the properties (name) from Client.

const c5: Client = new Customer();

It works fine!

We can go on for enums, object literals, and any other type, but the idea here is to understand that the structure of the type is the relevant part.

Runtime and Compile time

This is a much more complex topic in programming language theory, but I wanted to give some examples to distinguish runtime from compile time.

Basically, the runtime is the execution time of a program. Imagine your backend receiving data from a frontend form page, handling this data, and saving it. Or when your frontend is requesting data from a server to render a list of Pokemons products.

Compile time is basically when the compiler is executing operations in the source code to satisfy the programming language's requirements. It can include type checking as an operation, for example.

Compile time errors in TypeScript, for example, are very related to the code that we wrote before:

• When the type is missing property: Property 'age' is missing in type 'Client' but required in type 'Customer'.
• When the type doesn't match: Type '{ title: string; willFail: true; }' is not assignable to type 'Product'.

Let's see some examples to have a better understanding.

I want to write a function to get the index of a part of the passed programming language.

function getIndexOf(language, part) {
  return language.indexOf(part);
}

It receives the language and the part that we will look for to get the index.

getIndexOf('Typescript', 'script'); // 4
getIndexOf(42, 'script'); // Uncaught TypeError: language.indexOf is not a function at getIndexOf

When passing a string, it works fine. But passing a number, we got a runtime error Uncaught TypeError. Because a number doesn't have an indexOf function, so we can't really use it.

But if we give type information to the compiler, in compile time, it will throw an error before running the code.

function getIndexOf(language: string, part: string): number {
  return language.indexOf(part);
}

Now our program knows that it will need to receive two strings and return a number. The compiler can use this information to throw errors when we get a type error... before runtime.

getIndexOf('Typescript', 'script'); // 4
getIndexOf(42, 'script'); // Argument of type '42' is not assignable to parameter of type 'string'.

Maybe, for small projects (or small functions like ours) we don't really see too much benefit.

In this case, we know that we need to pass a string, so we won't pass a number to the function. But when the codebase grows or you have many people adding code and more complexity, it's clear to me that a type system can help us a lot to get errors in compile time before shipping code to production.

At first, we need all the learning curve to understand types and all the mental models, but after a while, you'll be more used to type annotations and eventually become friends with the compiler. It would be a helper, not a yeller.

As we are learning about the basic difference between compile time and runtime, I think it's great to differentiate types from values.

All the examples I'll show here can be copied and run in the TypeScript Playground to understand the compiler and the result of the compilation process (aka the "JavaScript").

In TypeScript, we have two different universes: the value and the type spaces. The type space is where types are defined and used to enable the compiler to do all the great magic. And the value space is the values in our programs like variables, constants, functions, value literals, and things that we have in runtime.

It's good to have an understanding of this concept because in TypeScript we can't use type checking in runtime. It has a very clear separation between type checking and the compilation process.

TypeScript has the process of type checking the source code types and sees if everything is correct and consistent. And then it can compile to JavaScript.

As these two parts are separate, we can't use type checking in runtime. Only in "compile time". If you try to use a type as a value, it will throw an error: only refers to a type, but is being used as a value here.

Let's see examples of this idea.

Imagine we want to write a function called purchase where we receive a payment method and based on this method, we want to do some action. We have a credit card and a debit card. Let's define them here:

type CreditCard = {
  number: number;
  cardholder: string;
  expirationDate: Date;
  secutiryCode: number;
};

type DebitCard = {
  number: number;
  cardholder: string;
  expirationDate: Date;
  secutiryCode: number;
};

type PaymentMethod = CreditCard | DebitCard;

These types are in the Type space, so it only works in compile time. After type checking this function, the compiler removes all the types.

If you add these types in the TypeScript Playground, the output will be only a strict definition "use strict";.

The idea here is to really understand that the types live in the Type space and will not be available in the runtime. So in our function, it won't be possible to do this:

const purchase = (paymentMethod: PaymentMethod) => {
  if (paymentMethod instanceof CreditCard) {
    // purchase with credit card
  } else {
    // purchase with debit card
  }
}

In the compiler it throws an error: 'CreditCard' only refers to a type, but is being used as a value here..

The compiler knows the difference between the two spaces and that the type CreditCard lives in the Type space.

The playground is a very cool tool to see the output of your TypeScript code. If you create a new credit card object like this:

const creditCard: CreditCard = {
  number: 2093,
  cardholder: 'TK',
  expirationDate: new Date(),
  secutiryCode: 101
};

The compiler will type check it and do all the magic and then it transpiles the TypeScript code to JavaScript. And we have this:

const creditCard = {
    number: 2093,
    cardholder: 'TK',
    expirationDate: new Date(,
    secutiryCode: 101
};

The same object, but now only with the value and without the type.

Constraints & Type Narrowing

When we restrict what we can do, it’s easier to understand what we can do.

We use types as constraints to limit the bugs in your program. To understand this concept, I'm stealing an example from Lauren Tan's talk about Type Systems.

const half = x => x / 2;

How many ways does this function can fail? Imagine a number of possible inputs:

[
  null,
  undefined,
  0,
  '0',
  'TK',
  { username: 'tk' },
  [42, 3.14],
  (a, b) => a + b,
]

And what are the results for input:

half(null); // 0
half(undefined); // NaN
half(0); // 0
half('0'); // 0
half('TK'); // NaN
half({ username: 'tk' }); // NaN
half([42, 3.14]); // NaN
half((a, b) => a + b); // NaN

We have different and unexpected results here. Here it's clear that we want a number as the half function, do the calculation, and great, it's done! But sometimes we don't control the input or the codebase is big, or new/unfamiliar, and we're able to make these little mistakes.

The idea of adding constraints to our code is to narrow the possibilities of a range of types. In this case, we want to limit the input type to a number type. It's the only type that we care about to do the half calculation. With type narrowing, we again give type information to the compiler.

const half = (x: number) => x / 2;

And with this new information, if we call the function with the test cases again, we have different results:

half(null); // Argument of type 'null' is not assignable to parameter of type 'number'.
half(undefined); // Argument of type 'undefined' is not assignable to parameter of type 'number'.(
half(0); // 0
half('0'); // Argument of type '"0"' is not assignable to parameter of type 'number'.
half('TK'); // Argument of type '"TK"' is not assignable to parameter of type 'number'.
half({ username: 'tk' }); // Argument of type '{ username: string; }' is not assignable to parameter of type 'number'.
half([42, 3.14]); // Argument of type 'number[]' is not assignable to parameter of type 'number'.
half((a, b) => a + b); // Argument of type '(a: any, b: any) => any' is not assignable to parameter of type 'number'.

Basically the compiler will tell us that only the number type, in this case, the 0 value, is a valid input, it will compile, and allow to run the code. We narrow the input type and allow only the value we really want for this function.

But are other ways to narrow the types in TypeScript. Imagine we have a function that receives a parameter that can be either a string or a number.

type StringOrNumber = string | number;

function stringOrNumber(value: StringOrNumber) {}

In the function body, the compiler won't know which methods or properties we can use for this type. Is it a string or number? We only know about the value in runtime. But we can narrow the type using the typeof:

function stringOrNumber(value: StringOrNumber) {
  if (typeof value === 'string') {
    // value.
        // your ide will show you the possible methods from the string type
        // (parameter) value: string
    value
  }

  if (typeof value === 'number') {
    // value.
        // your ide will show you the possible methods from the number type
        // (parameter) value: number
    value
  }
}

With an if statement and the typeof, we can give more information to the compiler. Now it will know the specific type for each if body.

The IDE knows what to show for the specific type. In runtime, when the value is a string, it will go to the first if statement, and the compiler will infer that the type is a string: (parameter) value: string.

When the value is a number, it will go to the second if statement and the compiler will infer that a type is a number: (parameter) value: number.

The if statement can be a helper to the compiler.

Another example is when we have an optional property in an object, but in a function, we need to return a value based on this optional value.

Imagine we have this type:

type User = {
  name: string;
  address: {
    street: string;
    complement?: string;
  }
};

It's a simple User type. Let's focus on the complement property. It's optional (take a closer look at the ? symbol), which means that it can be a string or undefined.

Now we want to build a function to receive the user and get the length of the address complement. What about this?

function getComplementLength(user: User): number {
  return user.address.complement.length;
    // (property) complement?: string | undefined
  // Object is possibly 'undefined'.
}

As we see earlier, the complement can be a string or undefined. undefined doesn't really have a property called length:

Uncaught TypeError: Cannot read property 'length' of undefined

We could make something like:

function getComplementLength(user: User) {
  return user.address.complement?.length;
}

If the complement has a string value, we can call length, otherwise, it will return undefined.

So this function has two possible return types: number | undefined. But we want to ensure that we only return number. So we use a if or a ternary condition to narrow the type. It will only call .length when it has real value (or when it is not undefined).

function getComplementLength(user: User): number {
  return user.address.complement
    ? user.address.complement.length
    : 0;
}

If it is undefined, we return the minimum length: 0. Now we can use the function with the right type design with and without the complement. Without compile and runtime errors.

getComplementLength({
  name: 'TK',
  address: {
    street: 'Shinjuku Avenue'
  }
}); // 0

getComplementLength({
  name: 'TK',
  address: {
    street: 'Shinjuku Avenue',
    complement: 'A complement'
  }
}); // 12

We'll get 0 from the first function call and 12 from the second call.

With this if concept, we can also use other helpers to do the same thing. We could use the in operator to verify a property from an object, a Array.isArray to verify an array, or the instanceof for any other class type.

We could also use more advanced concepts like assertion function or type guards, but I'll leave these concepts to future posts.

One thing that I want to dig deep in this Constraints topic is immutability.

In JavaScript and TypeScript, we have the idea of mutable objects. If you define value in a variable, we can reassign it with another value later.

let email = 'harry.potter@mail.com';
email // 'harry.potter@mail.com'
email = 'hermione.granger@mail.com';
email // 'hermione.granger@mail.com'

Now imagine you have a list of numbers. And you want to use a function to sum all of its numbers. The function looks like this:

function sumNumbers(numbers: number[]) {
  let sum = 0;
  let num = numbers.pop();

  while (num !== undefined) {
    sum += num;
    num = numbers.pop();
  }

  return sum;
}

You call the function passing your list and get the result. It works just fine.

const list = [1, 2, 3, 4];
sumNumbers(list); // 10

But what happened to your list? Did the function mutate it entirely?

list; // []

If we use the list, it's empty now. The pop in the sumNumbers function is a "mutate" function. It gets the references and removes the item from them. It's not a copy, it's the real reference.

In runtime, we can use other functions or ways to do the same thing: using reduce, do a for loop without the need to pop items from the array.

But using TypeScript, we can provide immutability in compile time. If you are not using types, it's possible to use a type assertion as const. Imagine this:

const author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

author.books.push({
  title: 'Steve Jobs',
  price: 10.00
});

Just an author object and then we add a new book to this author. The push method updates the book's array reference. It's a "mutate" method. Let's see if you use the const assertion as const:

const author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
} as const;

author.books.push({
  title: 'Steve Jobs',
  price: 10.00
});
// Property 'push' does not exist on type
// 'readonly [{ readonly title: "Leonardo Da Vinci"; readonly price: 50; }]'

The compiler won't compile. It gets an error on the author's object. It's is now readonly, and as a readonly object, it has no method called push (or any "mutate" method).

We added a constraint to the author's object. Before it was a specific type (with all the "mutate" methods), and now we narrowed the type to be almost the same, but without the "mutate" methods. Type narrowing.

To continue, let's add types to this object. The book and the author:

type Book = {
  title: string;
  price: number;
};

type Author = {
  name: string;
  email: string;
  books: Book[];
};

Add the type to the author object:

const author: Author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

Add the type to a new book object:

const book: Book = {
  title: 'Steve Jobs',
  price: 30
};

And now we can add the new book to the author:

author.name = 'TK';
author.books.push(book);

It works just fine!

I want to show another way to add immutability in compile time. TypeScript has a utility type called Readonly.

You can add the readonly for each property in an object. Something like this:

type Book = {
  readonly title: string;
  readonly price: number;
};

But it can be very repetitive. So we can use the Readonly utility to add the readonly to all properties of an object:

type Book = Readonly<{
  title: string;
  price: number;
}>;

One thing to keep in mind is that it doesn't add the readonly for nested properties. For example, if we add the Readonly to the Author type, it won't add the readonly to the Book type too.

type Author = Readonly<{
  name: string;
  email: string;
  books: Book[];
}>;

All the properties from the author can't be reassigned, but you can mutate the books list here (push, pop, ...) because the Book[] is not readonly. Let's see it.

const author: Author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

const book: Book = {
  title: 'Steve Jobs',
  price: 30
};

author.books.push(book);
author.books;
/* =>
 *
 * [
 *   {
 *     title: 'Leonardo Da Vinci',
 *     price: 50.00,
 *   },
 *   {
 *    title: 'Steve Jobs',
 *    price: 30
 *   }
 * ]
 *
 */

The push will work just fine.

So, how do we enforce a readonly to the books? We need to make sure that the array is a readonly type. We can use the Readonly, or use another utility from TypeScript called ReadonlyArray. Let's see the two ways to do it.

With Readonly:

type Author = Readonly<{
  name: string;
  email: string;
  books: Readonly<Book[]>;
}>;

With ReadonlyArray:

type Author = Readonly<{
  name: string;
  email: string;
  books: ReadonlyArray<Book>;
}>;

For me, both work great! But in my opinion, ReadonlyArray is more semantic and I also feel it is less verbose (not that the Readonly with an array is).

What happened if we try to mutate the author object now?

author.name = 'TK'; // Cannot assign to 'name' because it is a read-only property.
author.books.push(book); // Property 'push' does not exist on type 'readonly [{ readonly title: "Leonardo Da Vinci"; readonly price: 50; }]'.

Great! Now we can catch mutable operations in compile time. This is a way to use the concept of adding constraints to our types to make sure they only do what is really needed.

Semantics & Readability

At first, I felt that TypeScript could be very verbose because of the types and make the code much more complex than it should be. And it actually can. Strive for simplicity is the goal and it is difficult at the same time.

This idea is very related to clean code and how we can write code to be human-readable and maintainable. TypeScript is no different. Most of the cases, we don't need super complex types. Let the simple types do the work.

Another thing that I find very useful is semantic of types.

Imagine you need to add a string to the sessionStorage to save it in the browser. Your function looks like this:

function saveMyString(value: string): any {
  sessionStorage.myString = value;
}

You add a type annotation to the string input and as you don't know about the returning type, you probably add a any type.

But what's the real meaning behind this returning type? Is it returning anything?

It just saves the string to the sessionStorage. It doesn't return anything. The void type was what you're looking for. As TypeScript docs says: the absence of having any type at all.

function saveMyString(value: string): void {
  sessionStorage.myString = value;
}

Great, the meaning of the type is correct now. The correctness is very important in a type system. It's a way to model our data, but also help maintain systems for future developers. Even if the developer is ... you!

Before we were talking about verbose code. And we can improve a lot of our code by using TypeScript type inference.

For some code, we don't need to explicitly add type annotation. The TypeScript compiler will understand and infer it implicitly. For example:

const num: number = 1;

This code is redundant. We can just let the compiler infers it like this:

const num = 1;

In our example earlier, we add the annotation void to the saveMyString function. But as the function doesn't return any value, the compiler will infer that the returning type is void implicitly.

When I learned this, I thought with myself. But one of the biggest advantages of using TypeScript (or any other type system / static type language) is types as documentation. If we let the compiler infer most of the types, we won't have the documentation we want.

But if you hover over the TypeScript code in your editor (at least VS Code works like that), you can see the type information and relevant documentation.

Let's see other examples of redundant code and make the code less verbose and let the compiler works for us.

function sum(a: number, b: number): number {
  return a + b;
};

We don't need the returning type number, because the compiler knows that a number + another number is equal to a number type, and it is the returning type. It can be:

function sum(a: number, b: number) {
  return a + b;
};

Implicit code, but with documentation, and the compiler does the work.

Type inference works for methods too:

function squareAll(numbers: number[]): number[] {
  return numbers.map(number => number * number);
};

This function gets a list of numbers and makes every number a squared value. The returning type is number[], even though the result of a map is always a list, and as we have a list of numbers, it will always be a list of numbers. So we let the compiler infers this too:

function squareAll(numbers: number[]) {
  return numbers.map(number => number * number);
};

This works the same way for objects too.

const person: { name: string, age: number } = {
  name: 'TK',
  age: 24
};

A person object with a string name and a number age. But as we are assigning these values, the compiler can infer these types.

const person = {
  name: 'TK',
  age: 24
};

If you hover the person, you get this:

const person: {
  name: string;
  age: number;
}

The types are documented here.

Another benefit of type inference is that we can easily refactor our code. It's a simple example, but good to illustrate the refactoring process. Let's get the sum function again.

function sum(a: number, b: number): number {
  return a + b;
};

Instead of returning the sum number, we want to return "Sum: {a + b}". So for a = 1 and b = 2, we have the resulting string as "Sum: 3".

function sum(a: number, b: number): string {
  return `Sum: ${a + b}`;
};

sum(1, 2); // Sum: 3

Great! But now letting the compiler infers this.

// function sum(a: number, b: number): number
function sum(a: number, b: number) {
  return a + b;
};

// function sum(a: number, b: number): string
function sum(a: number, b: number) {
  return `Sum: ${a + b}`;
};

We just need to modify the returning value and the type inference will work. No need to think about the returning type. This is a small example, but for more complex functions, it would work too.

Back to the readability part, we can use Enum. A utility that defines a set of named constants. It's a way to give more meaning to the data in your application.

In your node app or a frontend app, you possibly do some fetching to request data. You commonly use a fetch object to perform a request and sometimes you need to pass the accept headers.

fetch('/pokemons', {
  headers: {
    Accept: 'application/json'
  }
});

fetch('/harry-potter/spells', {
  headers: {
    Accept: 'application/json'
  }
});

It's good, but we can also use an enum to separate this accept string in a constant and reuse.

enum MediaTypes {
  JSON = 'application/json'
}

fetch('/pokemons', {
  headers: {
    Accept: MediaTypes.JSON
  }
});

fetch('/harry-potter/spells', {
  headers: {
    Accept: MediaTypes.JSON
  }
});

And we are able to add more data related to the MediaTypes like PDF:

enum MediaTypes {
  JSON = 'application/json',
  PDF = 'application/pdf'
}

With Enum, we can encapsulate data into a meaningful block of code.

Recently, I was implementing a "state" React component. It's basically a component that renders an empty state or an error state based on the request response.

The UI for the empty and the error states were very similar. Only the title and the description text and the image icon were different. So I thought: "I have two ways in my mind to implement this: do the logic outside the component and pass all the information needed or pass a 'state type' and let the component render the correct icon and messages."

So I built an enum:

export enum StateTypes {
  Empty = 'Empty',
  Error = 'Error'
};

And I could just pass this data to the component as the type:

import ComponentState, { StateTypes } from './ComponentState';

<ComponentState type={StateTypes.Empty} />
<ComponentState type={StateTypes.Error} />

In the component, it had a state object with all the information related to the title, description, and icon.

const stateInfo = {
  Empty: {
    title: messages.emptyTitle,
    description: messages.emptyDescription,
    icon: EmptyIcon,
  },
  Error: {
    title: messages.errorTitle,
    description: messages.errorDescription,
    icon: ErrorIcon,
  },
};

So I could just receive the type based on the enum and use this stateInfo object with the State component from our design system:

export const ComponentState = ({ type }) => (
  <State
    title={stateInfo[type].title}
    subtitle={stateInfo[type].subtitle}
    icon={stateInfo[type].icon}
  />
);

This is a way to use an enum to encapsulate important data into a meaningful block of code in your application.

Another cool feature from TypeScript is optional properties. When we have properties from an object that can be a real value or undefined, we use an optional property to be explicitly that the property can be or not be there. The syntax for this is a simple ? operator in the object property. Imagine this function:

function sumAll(a: number, b: number, c: number) {
  return a + b + c;
}

But now the c value is optional:

function sumAll(a: number, b: number, c?: number) {
  return a + b + c;
}

We add the ? after c. But now we have a compiler error saying:

(parameter) c: number | undefined
Object is possibly 'undefined'.

We can't sum an undefined value (well, actually in JavaScript we can, but we receive a NaN value).

We need to ensure that the c exists. Type narrowing!

function sumAll(a: number, b: number, c?: number) {
  if (c) {
    return a + b + c;
  }

  return a + b;
}

If the c exists, it will be a number and we can sum all. If not, sum only the a and b values.

An interesting part of this optional property is that it is a undefined not null. This is why we do this, we get a compile error:

let number = null;
sumAll(1, 2, number);
// Argument of type 'null' is not assignable to parameter of type 'number | undefined'.

As the ? operator doesn't handle the null value, choose to use the undefined type in your application and so you can still use the optional property and make the types consistent. We can use it like this:

let value: number | undefined;
sumAll(1, 2, value); // 3

If you add a default value to the parameter, you won't need the ? operator. Actually, the compiler will say that the Parameter cannot have question mark and initializer.

function sumAll(a: number, b: number, c: number = 3) {
  return a + b + c;
}

Optional properties not only works on variables and parameters, but also in objects.

An API response is a good example of type definition and optional property together. In API responses, data can be optional. Sometimes the API sends, sometimes it has no value.

How we model our types is really important for an application. If an optional property is defined as a required type, we can make our application breaks in runtime. But if we design the types correctly, we have the possible errors in compile time.

Imagine we are fetching a user data and this is the way we modeled the response type:

type UserResponse = {
  name: string;
  email: string;
  username: string;
  age: number;
  isActive: boolean;
};

But in reality, the email is optional for the user. The API endpoint could return or not. But the UserResponse type we built treat it as a required property.

After fetching the user data, we want to see if the user email matches with a specific domain.

function matchDomain(email: string) {
  return email.endsWith(domain);
}

As the email property is required in the UserResponse type, the email parameter will also be required in the matchDomain function.

This is the runtime we can get if the email is undefined:

// Uncaught TypeError: Cannot read property 'endsWith' of undefined

But what would happen if we modeled the UserResponse correctly?

type UserResponse = {
  name: string;
  email?: string;
  username: string;
  age: number;
  isActive: boolean;
};

Now the email is possibly undefined and it is explicit.

But if we still keep the function matchDomain the same way, we get a compile error:

// Argument of type 'undefined' is not assignable to parameter of type 'string'.

And this is great! Now we can fix the email parameter in this function using the ? operator:

function matchDomain(email?: string) {
  return email.endsWith('email.com');
}

But now we get a compile error when running email.endsWith, because it could be undefined too:

// (parameter) email: string | undefined
// Object is possibly 'undefined'.

Type narrowing! We use an if block to return a false when the email is undefined. And run endsWith method only if the email is really a string:

function matchDomain(email?: string) {
  if (!email) return false;
  return email.endsWith('email.com');
}

It's pretty nice when we can get runtime errors in compile time. Better to code than debugging after we ship in production, isn't it?

Type composition

Type composition is very useful when trying to reuse existing types for new places of the codebase. We don't need to rewrite new types, we can create a new type by composing existing ones.

One example of composition I always have to handle using Redux or the useReducer hook from React is the idea of "reducers". A reducer can always receive a number of different actions.

In this context, actions are objects with at least a type property. It looks like this:

enum ActionTypes {
  FETCH = 'FETCH'
}

type FetchAction = {
  type: typeof ActionTypes.FETCH;
};

const fetchAction: FetchAction = {
  type: ActionTypes.FETCH
};

A fetchAction has a type FetchAction that has a property type that is a typeof FETCH.

But a reducer can receive other actions too. For example a submit action:

enum ActionTypes {
  FETCH = 'FETCH',
  SUBMIT = 'SUBMIT'
}

type SubmitAction = {
  type: typeof ActionTypes.SUBMIT;
};

const submitAction: SubmitAction = {
  type: ActionTypes.SUBMIT
};

For a specific container, we can compose all these actions into just one type and use it for the reducer parameter type.

It would look like this:

type Actions = FetchAction | SubmitAction;

function reducer(state, action: Actions) {
  switch (action.type) {
    case ActionTypes.FETCH:
    // fetching action
    case ActionTypes.SUBMIT:
    // submiting action
  }
}

All the possible actions are the Actions type. And we use a union type to "join" all action types. The action in the reducer can have the FetchAction or the SubmitAction.

As a Potterhead, I couldn't miss a Harry Potter example. I want to build a simple function to choose a Hogwarts House based on the person trait. Let's start with the houses first.

type House = {
  name: string;
  traits: string[];
}

const gryffindor: House = {
  name: 'Gryffindor',
  traits: ['courage', 'bravery']
};

const slytherin: House = {
  name: 'Slytherin',
  traits: ['ambition', 'leadership']
};

const ravenclaw: House = {
  name: 'Ravenclaw',
  traits: ['intelligence', 'learning']
};

const hufflepuff: House = {
  name: 'Hufflepuff',
  traits: ['hard work', 'patience']
};

const houses: House[] = [
  gryffindor,
  slytherin,
  ravenclaw,
  hufflepuff
];

I want to keep it simple, so the House type has only the name and the traits, a list of possible traits from people related to the house.

And then, I create each house and added all of them to the houses list.

Great! Now I'll build the Person type. A person can be a witch or a muggle.

type Witch = {
  name: string;
  trait: string;
    magicFamily: string;
}

type Muggle = {
  name: string;
    trait: string;
  email: string;
}

And this is the part we combine these two different types using the union type:

type Person = Muggle | Witch;

Using the intersection type, the Person type has all properties from Muggle or all from Witch.

So now, if I create a Muggle, I need just the name, the trait, and the email:

const hermione: Muggle = {
  name: 'Hermione Granger',
    trait: 'bravery',
  email: 'hermione@mail.com'
};

If I create a Witch, I need the name, the trait, and the magic family name:

const harry: Witch = {
  name: 'Harry Potter',
  trait: 'courage',
  magicFamily: 'Potter'
};

And if I create a Person, I need at least the name and the trait properties from Muggle and Witch:

const tk: Person = {
  name: 'TK',
  email: 'tk@mail.com',
  trait: 'learning',
  magicFamily: 'Kinoshita'
};

The chooseHouse is very simple. We just pas the houses and the person. Based on the person trait, the function will return the chosen house:

function chooseHouse(houses: House[], person: Person) {
  return houses.find((house) => house.traits.includes(person.trait))
}

And applying all the people we created:

chooseHouse(houses, harry); // { name: 'Gryffindor', traits: ['courage', 'bravery'] }
chooseHouse(houses, hermione); // { name: 'Gryffindor', traits: ['courage', 'bravery'] }
chooseHouse(houses, tk); // { name: 'Ravenclaw', traits: ['intelligence', 'learning'] }

Nice!

The intersection type is a bit different, but it can also be used to combine existing types.

When I was implementing a web app to apply my studies on UX, I needed to create a prop type for the Image component.

I had the type ImageUrl from the product type:

type ImageUrl = {
  imageUrl: string;
};

And the ImageAttr to represent all the attributes for the image:

type ImageAttr = {
  imageAlt: string;
  width?: string
};

But the props expected all this information in the component. Intersection type for the rescue!

type ImageProps = ImageUrl & ImageAttr;

Simple as that. So now, the component needs all these properties. The type looks like this:

type ImageProps = {
  imageUrl: string;
  imageAlt: string;
  width?: string
};

And we can use this type this way:

const imageProps: ImageProps = {
  imageUrl: 'www.image.com',
  imageAlt: 'an image',
};

const imagePropsWithWidth: ImageProps = {
  imageUrl: 'www.image.com',
  imageAlt: 'an image',
  width: '100%'
};

Nice! One more concept to reuse and compose types.

I also find the Pick type very interesting and useful. We have other interesting types that we could write here, but the idea here is to understand that we can compose type and there is no limit to reuse types. If you're interested in study other types, take a look at this post I wrote: TypeScript Learnings: Interesting Types.

Tooling

When you npm install typescript, you don't just get the compiler, you get the language service API, a standalone server called tsserver that editors can run to provide autocompletion, go-to, and other cool features.

These features are what some people from the TypeScript team call developer productivity tools like smart errors when type checking and IntelliSense (code completion, hover info, signature information). We look at these features throughout the whole article, but I want to make a special topic to talk about it.

The TypeScript type checker is powerful in the sense that it can infer types and provide information to some possible issues. Example: It inferred that the city is a string. And the uppercase is used the wrong way. As it knows it is a string, it also tries to find a possible method that the engineer is looking for.

const city = 'Tokyo';
city.toUppercase();
// Property 'toUppercase' does not exist on type
// 'string'. Did you mean 'toUpperCase'?

In this case, the compiler is really smart, because it finds exatcly what we wanted.

It also works for objects:

const people = [
  { name: 'TK', age: 24 },
  { name: 'Kaio', age: 12 },
  { name: 'Kazumi', age: 31 },
];

for (const person of people) {
  console.log(person.agi);
  // Property 'agi' does not exist on type '{ name: string; age: number; }'
}

With the static types, the tooling can provide a great developer experience with code completion, hover info to show defined types, and signature information for methods and other data.

If you type: 'TK'., the editor will show all the possible methods for the string object. The compiler knows it is a string. And it knows the methods from the String prototype. But it also provides the method signature. This is very interesting because we don't necessarily need to go to the docs. The "docs" is already in our code editor.

It's an awesome experience while coding.

The type definition "on hover" is another thing that we saw earlier in this article. Let the compiler infer the types implicitly and you won't lose the type documentation. Using the hover in the object, the IDE or editor will always be able to show the type definition.

Another interesting thing is that TypeScript will not only flag what could go wrong on runtime, but it also helps to find code that doesn't do what you intend.

Imagine we have a function to open a snackbar if it is still closed. It would verify the status of the snackbar. If it is closed, just call another function to open it.

const buildSnackbar = (status: SnackbarStatus) => {
  if (status.isClosed) {
    openSnackbar();
  }
};

And the type information for this snackbar is:

type SnackbarStatus = {
  isClosed: boolean;
};

What happens if I call this function like this:

buildSnackbar({ isclosed: true });

It won't break in runtime, because the status object has no isClosed attribute and the undefined object is a falsy value, so it will skip the if condition and not call the openSnackbar function. No runtime error. But probably it will behavior different than the expected.

In TypeScript, the compiler will give some hints to make it works properly. First it will show this error:

// Argument of type '{ isclosed: boolean; }' is not assignable to
// parameter of type 'SnackbarStatus'.

isclosed with downcased C is not assignable to the type. It's not defined there. This is the first hint to make you correct your code.

The second is even better:

// Object literal may only specify known properties,
// but 'isclosed' does not exist in type 'SnackbarStatus'.
// Did you mean to write 'isClosed'?

It tells exactly what you probably need to do: rename the isclosed to isClosed.

We can talk a lot of things about the tooling about I think this is the main part.

My suggestion to learn more about this is to just code in TypeScript and "have a conversation" with the compiler. Read the errors. Play with the hover. See the autocompletion. Understand the method signatures. It's really a productive way to code.

Tips & Learnings

As the article is coming to an end, I want to just add some final thoughts, learnings, and tips to help you in your journey learning TypeScript or just applying it in your projects.

• Really read the type error: this will help you better understand the issue and the types.
• strictNullChecks and noImplicitAny can be very helpful in finding bugs. Enable this as soon as possible in your project. Use strictNullChecks to prevent “undefined is not an object”-style runtime errors. Use noImplicitAny to type the source code to give more type information for the compiler.
• Together with the compiler's configurations, I always recommend being very precise about your types. Mainly with the values that occur only in runtime like an API response. Correctness is important to catch as many bugs as possible in compile time.
• Understand the difference between runtime and compile time: types only affect in compile type. It runs the type checker and then compiles to JavaScript. The JavaScript source code doesn't use any type of references or type operations.
• Learn about utility types. We talked more specifically about the Readonly in the immutability in compile time, but TypeScript has a box of helpers like Required, Pick, and many more.
• If possible, prefer letting the compiler infers the types for you. Most of the types and returning types are redundant. The TypeScript compiler is very smart in this area. If not possible, you can always add type annotations. And leave the type assertions as the last option.
• As you're writing code, take a look at the tooling. The design of the tooling provided in an IDE is amazing. The IntelliSense and type checking provide a really good experience.

This post was originally published at TK's blog. And you can find more content like this in my blog at https://leandrotk.github.io/tk.

You can also follow me on Twitter and GitHub.

Resources

I compiled (pun very much intended!) a bunch of resources to help you learn more about programming languages, type systems, and the type mental model.

Also, if you found the examples on this post useful, I added all of them this repository: Thinking in Types. So you can fork and play with it.

Type Systems

• Type Compatibility
• Type Systems: Structural vs. Nominal typing explained
• Learning TypeScript: Structural vs nominal typing systems
• Constraints Liberate, Liberties Constrain — Runar Bjarnason
• Type Narrowing in TypeScript
• TypeScript: narrowing types via type guards and assertion functions
• TypeScript Learnings: Interesting Types

Tooling & Developer Experience

• Advanced TypeScript tooling at scale
• Type Systems & Props Design
• Anders Hejlsberg on Modern Compiler Construction
• TypeScript Compiler explained by the Author Anders Hejlsberg

Compile time vs Runtime

• Compile time vs Runtime
• Compile error vs Runtime error
• Value space and Type space
• A playground tool to play with TypeScript and see the JavaScript output

Best Practices

• TypeScript Best Practices
• Do's and Don'ts for General Types

Books

• Programming with Types Book
• Effective TypeScript: 62 Specific Ways to Improve Your TypeScript Book
• Thinking with Types