DEV Community: Alex Pliutau

Different ways of working with SQL Databases in Go

Alex Pliutau — Mon, 23 Sep 2024 09:50:02 +0000

Read the original article on packagemain.tech

Different programming languages have their own ways of working with relational databases and SQL. Ruby on Rails has its Active Record, Python has SQLAlchemy, Typescript — Drizzle, etc. Go, being a language with quite diverse standard library which includes well-known database/sql package, has its own libraries and solutions for working with SQL, that suit different needs, preferences and teams.

In this article, we’ll explore and compare most popularly used Go packages with hands-on examples, pros and cons. We will also briefly touch on the topic of database migrations and how to manage them in Go. You’ll get the most out of this article if you already have some experience with Go, SQL and relational databases (doesn’t matter which one).

Demo Schema

For the purpose of this article, we’ll use a simple schema with three tables: users, posts and blogs. For simplicity we’ll be using SQLite as our database engine, choosing another database engine should not be a problem, as all the libraries we’ll be exploring support multiple SQL dialects.

Here is our database schema in SQL:

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE
);

CREATE TABLE blogs (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    url TEXT NOT NULL UNIQUE
);

CREATE TABLE posts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    user_id INTEGER NOT NULL,
    blog_id INTEGER NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE CASCADE,
    FOREIGN KEY (blog_id) REFERENCES blogs (id) ON DELETE CASCADE
);

And here is its Entity-Relationship Diagram (ERD):

Raw SQL and database/sql

Let’s imagine your application needs to perform the following action:

Find the users who have posted at least two articles, along with the total number of posts they’ve made.

In pure SQL that could be translated into the following query:

SELECT u.name, COUNT(p.id) AS post_count
FROM users AS u
JOIN posts AS p ON u.id = p.user_id
GROUP BY u.id
HAVING post_count >= 2;

A brief explanation of this query: we JOIN the users and posts tables, then GROUP by user_id, the HAVING clause filters the results to only include users who have posted at least 2 posts, and COUNT aggregates the amount of posts.

As mentioned above, Go provides a built-in package database/sql with the necessary tools for working with SQL databases. It was developed with simplicity in mind but supports all the necessary functionality such as transactions, parameterized queries, connection pool management, etc.

As long as you’re comfortable writing your own queries and handling errors and results, it’s a great option. And some would say that it’s the best option, as there is no hidden logic and you can always copy the query and analyze it with EXPLAIN.

Here is how you can get the results of the query above in Go code using database/sql (some parts like connection is omitted):

type userStats struct {
  UserName  sql.NullString
  PostCount sql.NullInt64
}

func getUsersStats(conn *sql.DB, minPosts int) ([]userStats, error) {
  query := `SELECT u.name, COUNT(p.id) AS post_count
FROM users AS u
JOIN posts AS p ON u.id = p.user_id
GROUP BY u.id
HAVING post_count >= ?;`

  rows, err := conn.Query(query, minPosts)
  if err != nil {
    return nil, err
  }
  defer rows.Close()

  users := []userStats{}
  for rows.Next() {
    var user userStats
    if err := rows.Scan(&user.UserName, &user.PostCount); err != nil {
      return nil, err
    }
    users = append(users, user)
  }

  if err := rows.Err(); err != nil {
    return nil, err
  }

  return users, nil
}

In this code we:

Use the raw SQL query with unnamed parameter, and pass the value of this parameter in conn.Query()
Iterate over returned rows and manually scan each row into a struct userStats defined above. Note that the struct uses sql.Null* types to handle nullable values properly.
We need to manually check for possible errors and close the rows to release the resources.

Pros:

No additional abstraction/complexity added. Easy to debug raw SQL queries.
Performance. The database/sql package is quite performant.
Provides a good enough abstraction from different database backends.
Cons:
The code becomes a bit verbose as there is a need to scan each row, define proper types and handle errors.
No compile-time type safety.

You can find the full source for this article in our Github Repository.

Raw SQL and sqlx

Now let’s have a look at some external packages which are popular in Go community.

If you’re already familiar with database/sql and like its simplicity, you may enjoy working with sqlx, which is built on top of standard library and just extends its features. It is very easy to integrate existing codebases using database/sql with sqlx, because it leaves the underlying interfaces such as sql.DB, sql.Tx, etc. untouched.

The core features of sqlx are:

Named parameters.
Easier rows scanning into structs with embedded struct support.
Better separation between single and multiple rows by using methods Get() and Select().
Ability to bind a slice of values as a single parameter to an IN query.

Here is how you can get the results of the query above using sqlx:

type userStats struct {
  UserName  string `db:"name"`
  PostCount string `db:"post_count"`
}

func getUsersStats(conn *sqlx.DB, minPosts int) ([]userStats, error) {
  users := []userStats{}

  query := `SELECT u.name, COUNT(p.id) AS post_count
FROM users AS u
JOIN posts AS p ON u.id = p.user_id
GROUP BY u.id
HAVING post_count >= ?;`

  if err := conn.Select(&users, query, minPosts); err != nil {
    return nil, err
  }

  return users, nil
}

In this code we use Select() method which handles scanning of the rows. It also closes the rows automatically so we don’t have to deal with that. The code became much shorter than the database/sql version, but can hide some implementation details from us. For example, be aware that Select loads the whole set into memory at once.

Pros:

Not that different from database/sql. Still easy to debug raw SQL queries.
A bunch of great features to reduce code verbosity.

Cons:

Same as database/sql

ORMs

Object-relational mapping (ORM) is a technique (some call it a design pattern) of accessing a relational database by working with objects without having to craft complex SQL statements. It is very popular in object-oriented languages, Ruby on Rails has its Active Record, Python has SQLAlchemy, Typescript — Drizzle, etc.

And Go has GORM. In a nutshell it lets you write queries as Go code by calling various methods on objects, which are then translated into SQL queries. But not only that, it has other features like database migrations, database resolvers and more.

You may need to spend a bit of time initially setting up your GORM models, but later it can reduce a lot of boilerplate code.

Our simple schema and query example may not be the best to visualize the strengths and weaknesses of GORM, but should be enough to demonstrate how we can run a similar query and scan the results:

type User struct {
  gorm.Model
  ID    int
  Name  string
  Posts []Post
}

type Post struct {
  gorm.Model
  ID     int
  UserID int
}

type userStats struct {
  Name  string
  Count int `gorm:"column:post_count"`
}

func getUsersStats(conn *gorm.DB, minPosts int) ([]userStats, error) {
  var users []userStats

  err := conn.Model(&User{}).
    Select("name", "COUNT(p.id) AS post_count").
    Joins("JOIN posts AS p ON users.id = p.user_id").
    Group("users.id").
    Having("post_count >= ?", minPosts).
    Find(&users).Error

  return users, err
}

The SQL query generated by gorm will be roughly the same as the one we wrote manually in the database/sql variant.

To summarize the code above:

We declared our User and Post models and extended it with the default gorm.Model struct. Later we can use these two models to build any queries we want by using gorm methods.
We also defined our small result type userStats
We used methods such as Select(), Joins(), Group(), Having() to produce the query we want.

With such easy example it’s hard to see the potential issues, everything looks just right. However, when your project becomes more complex you will most definitely encounter some issues with that. Just look at StackOverflow questions marked with go-gorm.

It’s good to be careful about using ORMs in performance-critical systems or where you need a direct control over database interactions, as gorm uses a lot of reflection and can add overhead and sometimes obscure what’s happening at the database level. Any project where the functionality is wrapped in another huge layer gets the risk of increasing the overall complexity.

Pros:

Abstraction from different database backends.
Big feature set: migrations, hooks, database resolvers, etc.
Saves quite a bit of tedious coding.

Cons:

Another layer of complexity and overhead. Hard to debug raw SQL queries.
Performance drawbacks. May not be as efficient for some critical applications.
Initial setup can require some time to configure all the models.

Generated Go code from SQL using sqlc

This nicely brings us to another unique approach of generating Go code from SQL queries using sqlc. With sqlc you write your schema and SQL queries, then use a CLI tool to generate a Go code from it and then use generated code to interact with databases.

It ensures that your queries are syntactically correct and type-safe and is ideal for those who prefer writing SQL but are looking for an efficient way to integrate it into a Go application.

sqlc needs to know your database schema and queries in order to generate code, therefore it requires some initial setup. Our schema and query above can be added to the files schema.sql and query.sql and using the following config we can generate the Go code:

version: "2"
sql:
  - engine: "sqlite"
    queries: "query.sql"
    schema: "schema.sql"
    gen:
      go:
        package: "main"
        out: "."

We also need to name our query in query.sql and mark the parameters:

-- name: GetUsersStats :many
SELECT u.name, COUNT(p.id) AS post_count
FROM users AS u
JOIN posts AS p ON u.id = p.user_id
GROUP BY u.id
HAVING post_count >= ?;

After we run sqlc generate we can use the following generated types and functions which makes our code type-safe and quite short.

func getUsersStats(conn *sql.DB, minPosts int) ([]GetUsersStatsRow, error) {
  queries := New(conn)

  ctx := context.Background()
  return queries.GetUsersStats(ctx, minPosts)
}

What makes sqlc special is that it understands your database schema, and uses that to validate the SQL you write. So your SQL queries are actually being validated against the actual database table and sqlc will give you a compile-time error if something is wrong.

Pros:

Type safety with generated Go code.
Still easy to debug SQL code.
Saves quite a bit of tedious coding.
Performance.

Cons:

Initial configuration setup for database schema and queries. Not perfect static analysis. Sometimes you need to explicitly set the parameter type, etc.

If you’re good with SQL statements and prefer not to use much code to express your database interactions, this is your package.

Database Migrations

Since we’re on the topic of SQL databases here, let’s briefly review the database migrations in Go. The schema of the database almost always evolves over time and no one wants to do these changes manually, therefore there are tools developed to help with that.

The main goal of a database migration tools is to ensure that all environments have the same schema and developers can easily apply the changes or rollback them.

We mentioned above that GORM can do the migrations as well if you project uses it as ORM. If you use database/sql, sqlx or sqlc you’ll have to use separate projects to manage them.

The most popular projects are:

golang-migrate — one of the most famous tools for handling database migrations. It supports many database drivers and migration sources, it takes a simple and direct approach for handling database migrations.
goose — another solid option when choosing a migration tool. It also has support for the main database drivers and one of its main features is support for migrations written in Go and more control of the migrations application process.

You can then integrate these tools directly into your application or in CI/CD. However, running them properly in CI/CD requires some setup (for example in case of deploying to Kubernetes), and we want to dive deeper into that in our upcoming articles.

Conclusion

There are many well-written, tested and supported database packages for Go that can help with faster development and cleaner code. There is also a very powerful database/sql included into standard library that can do most of your daily work.

However, whether you should use it or not depends on your needs as a developer, your preferences and your project. In this article, we tried to highlight their strengths and weaknesses.

You can find the full source for this article in our Github Repository.

I’ll end this article with this famous meme:

Resources

My first experience with OCaml

Alex Pliutau — Thu, 19 Sep 2024 11:38:19 +0000

Recently I've been motivated to learn more about functional programming and the name OCaml came up quite a few times. I have seen some praise about it from the people I follow on social media and decided to give it a try. I finally finished a small project in OCaml and would like to share my first impressions while the memory is still fresh.

Please keep in mind that I am relatively new to functional programming and mainly develop in Go nowadays, previously PHP, Python and Javascript. Therefore I will try not to make any conclusions but rather share my perception.

Resources

I started with the official documentation, which was enough to get an overview of the language and its type model, install the development tools and compile a small "hello world" application. However as I dove deeper I discovered other resources as well, such as Real World OCaml, OCamlverse, OCaml Operators where I could find the information I couldn't find on the official page.

It all gave me a feeling that there is a need for better-structured resources (especially for newcomers), which should probably live on the official website. Ideally with some interactive step-by-step language tour.

Program

My idea was to build a daemon that receives a Yaml configuration with the list of websites and monitors them concurrently, the results are stored in SQLite database afterward.

websites:
  - url: https://ocaml.org
    interval: 20
  - url: https://dune.readthedocs.io/en/stable/
    interval: 10

You can find the full source code here.

Installing OCaml

OCaml comes with two compilers: one translating sources into native binaries and another turning sources into a bytecode format. It offers a great runtime performance and has always been exceptionally reliable and stable.

To start compiling/running our program we need to install the opam package manager, which also installs the OCaml compiler.

I am using macos, so the commands for me were the following:

brew install opam
opam init
eval $(opam env)

This worked without any issues on my machine, and then I was able to install some platform and build tools, such as dune and utop.

opam install dune utop

utop is an interactive REPL which you can run in your terminal. Honestly, I haven't used it much during the development time and just built my program with dune.

When it comes to dune, I spent some significant time understanding how it works and battling with different dependencies errors. Generally it felt not intuitive to work with multiple dune files spread across your codebase.

dune init proj websites_monitoring

The following command created a project directory which looks similar to this:

websites_monitoring/
├── dune-project
├── bin
│   ├── dune
│   └── main.ml
├── lib
│   └── dune
├── test
│   ├── dune
│   └── test_websites_monitoring.ml
└── websites_monitoring.opam

As you can see there are 3 dune files, one dune-project file and one websites_monitoring.opam file, all of them responsible for building and managing dependencies. It felt like extra work when I had to change lib dependencies, I had to add them to both lib/dune and dune-project files as well as run dune build @install which updates websites_monitoring.opam.

Once I added some pseudo code it was time to build an executable:

dune build
[ERROR] No switch is currently set. Please use 'opam switch' to set or install a switch

This didn't work for me because there was no default switch installed, even though the documentation say that there should be one. Switches are isolated OCaml environments, similar to Python's virtualenv. I didn't dive into this much and just chose some switch from the list of available options:

opam switch create ocaml-base-compiler

Now I was able to compile and run my program, the binary is located in ./_build/install/default/bin/monitoring.

All in all, it seems that dune is an interesting tool, but I also think it needs a better documentation and simplified developer experience.

Language Syntax and Types

OCaml is type-safe and statically type language, which means it detects type errors at compile time. But what's cool is that there is a type inference, so you do not have to write type information everywhere. The compiler automatically figures out most types. This can make the code easier to read and maintain.

For example in my code I have this function to get a config filename from the environment variable:

let get_config_filename: string =
  try
    let path = Sys.getenv "CONFIG" in
    path
  with Not_found ->
    "./websites.yaml"

I could omit : string part and compiler still understands that it returns a string:

let get_config_filename =
  (* ... *)

There are user-defined types in OCaml such as variants, records and aliases. Here is the example of custom website type that corresponds to the yaml configuration of my program:

type website = {
  url: string;
  interval: int;
}

type websites = {
  websites: website list;
}

The language has lots of operators, and it took me some time to understand how they work. This webpage helped me a lot.

Preprocessors and PPXs

Preprocessors are programs meant to be called at compile time, so that they alter the program before the actual compilation.

In my case they've been really helpful to decode a Yaml file into a custom type after I spent few hours to do the same without them. I used ppx_deriving_yaml for that:

type website = {
  url: string;
  interval: int;
} [@@deriving yaml]

type websites = {
  websites: website list;
} [@@deriving yaml]

let get_websites_from_file(config_filename: string) : website list =
  let f = Yaml_unix.of_file Fpath.(v config_filename) in

  let yaml_value = match f with
  | Ok value -> value
  | Error `Msg e -> raise (Invalid_argument ("Unable to open/parse yaml file: " ^ e))
  in

  (* preprocessors are doing the magic of making websites_of_yaml *)
  match websites_of_yaml yaml_value with
  | Ok t ->
    t.websites
  | Error `Msg e -> raise (Invalid_argument ("Invalid config format: " ^ e))

Concurrency & Parallelism

Since I have the list of websites I wanted to process each website concurrently with some interval between runs. I couldn't use Domains for that, because the amount of websites could be larger than the amount of cores available.

It seems there are many libraries to implement concurrency or parallelism in OCaml and it's not obvious what to use. I think that it's the case with OCaml in general, the stdlib is quite minimal and there are many small independent libraries. Which is not an issue maybe, but hard to navigate especially for newcomers.

So I went with domainslib library:

let rec run_async (website: Config.website) () =
  (* crawl website and store the result in the db *)
  let res = Crawler.crawl_website website in
  Database.insert_website res;

  (* wait for the next interval *)
  let _ = Unix.sleep website.interval in
  run_async website ()

let main () =
  let websites = get_config_filename |> Config.get_websites_from_file in
  Printf.printf "Websites found in config: %d\n" (List.length websites);

  let num_domains = Domain.recommended_domain_count () - 1 in
  Printf.printf "Number of domains/cores: %d\n" num_domains;

  (* create a pool and process each website concurrently *)
  let pool = T.setup_pool ~num_domains:(num_domains) () in
  T.run pool (fun _ ->
    List.iter (fun website ->
      let _ = T.async pool (run_async website) in
      ()
    ) websites
  );
  T.teardown_pool pool;

  print_endline "Exiting..."

I actually spent a lot of time battling the segmentation fault error because the crawl_website function used cohttp-lwt under the hood. After I switched crawl_website to be synchronous everything worked well.

It was actually hard to find a library that does synchronous HTTP calls, everything uses LWT or Async.

Tests

There seem to be different ways of defining your tests, but I went with a simple approach of running the tests manually in let():

open Monitoring

let test_get_websites_from_file () =
  let websites = Config.get_websites_from_file "test_websites.yaml" in
  assert (List.length websites = 2);

  let first = List.hd websites in
  assert (first.url = "https://ocaml.org");
  assert (first.interval = 20)

let () =
  Unix.chdir "../../../test/";
  test_get_websites_from_file ();

And then I could run:

dune runtest

Containerization

ocaml/opam Docker image works well and I was able to quickly put my application into a container. I don't plan to deploy this app, so didn't worry much about multi-stage builds for now, just wanted to make sure it works.

FROM ocaml/opam:alpine AS init-opam

RUN sudo apk add --update gmp-dev sqlite-dev linux-headers openssl-dev curl-dev libcurl curl

FROM init-opam AS ocaml-app-base
WORKDIR /home/opam/websites_monitoring
COPY . .
RUN opam install . --deps-only
RUN opam install dune
RUN opam exec -- dune build

ENTRYPOINT ["/home/opam/websites_monitoring/_build/install/default/bin/monitoring"]

Conclusion

Will I be confident deploying this program to production? Probably not. But it kinda works. I would like to understand the domainslib better and maybe try few other approaches. And probably run some performance tests.

Was my journey learning OCaml and doing first steps easy? Probably not. I wish the documentation was easily accessible for the newcomers and structured better. Ideally in one place.

But definitely it was enjoyable and I am 100% sure I will be continuing playing with OCaml and maybe publish some libraries.

You can find the full source code here.

Resources

Rust for Gophers

Alex Pliutau — Thu, 18 Jul 2024 13:24:57 +0000

Read the original article on packagemain.tech

Should you Rust, or should you Go? Which language is better, and does that question even make sense? Let’s talk about Go versus Rust in 2024, with our special guest, John Arundel. John is the author of For the Love of Go, Cloud Native DevOps with Kubernetes, and many other books. He also teaches both Go and Rust, so it’ll be interesting to hear his perspective. Here’s the interview!

John, we seem to be hearing more and more about Rust these days. Can you give us a quick introduction? What is Rust for, and why does it exist?

Sure, that’s easy. Rust is a language for controlling elevators.

Are you kidding?

Not at all. Graydon Hoare, the originator of Rust, got frustrated when the elevators in his building kept breaking down due to software problems. He thought “Surely we can do better than this!” And the rest is history.

We can’t prevent all bugs, but we can at least use a programming language that eliminates some major categories of bugs, such as buffer overflows, data races, and “use after free” issues. So from the very beginning, Rust’s focus has been on building reliable software, automating many of the safety checks that good programmers do anyway, and helping to catch mistakes before they reach production.

That sounds like a good idea, but I get the impression that Rust is a hard language to learn—especially compared to Go. Is that fair, and if so, why?

Go and Rust are both trying, in different ways, to solve the same problem: it’s hard to write software at scale in traditional languages like C and C++, because the programmers have to be very experienced and knowledgeable to avoid making mistakes. Even experts can slip up from time to time, and it takes a long time to train programmers to become experts.

Go tackles this problem by radically simplifying the language: compared to something like C++, it has a lot less syntax to learn. So programmers can spend their time learning to write programs well, rather than mastering a big, complex language. Go is lean, but effective.

To use an analogy, it’s easier to learn to drive a tractor than to fly a spaceship. The tractor may be a humble, pragmatic machine, but it does its job perfectly, and it’s actually a better choice than the spaceship for many tasks: ploughing a field, for example.

I like your analogy. I guess Rust is the spaceship?

Yes, Rust is big, complicated, and powerful, combining many of the best ideas from traditional imperative languages like C with functional programming concepts borrowed from languages like Haskell and Lisp.

There’s more to learn in Rust than there is in Go, but then it does more! If you want to fly to Mars, a spaceship is a better choice than a tractor. Of course, it takes a little longer to train an astronaut than a tractor driver.

Go has built-in garbage collection, which is great for simplicity. How does memory management work in Rust, and is it a big challenge to learn?

Yes, garbage collection means you don’t have to worry about allocating and freeing memory yourself, as you do in languages like C++. That makes programming easier and eliminates all sorts of memory-related bugs. On the other hand, you need a relatively complex runtime, and garbage collection affects performance.

Rust takes a different approach. It reclaims memory automatically, but without having to pause the program. It can do this by keeping track of all the references to a particular piece of data that exist. When no part of the program can refer to the data any more, Rust knows that bit of memory can be safely recycled straight away.

Yes, I’ve heard Rust has a strong focus on ownership and borrowing. How do these concepts compare to working with pointers in Go, and what are some good ways to wrap my head around them?

Well, I have good news—if you’re already used to pointers in Go, then references in Rust work basically the same way, only safer. If you create a mutable reference to a variable, it works just like a Go pointer: you can pass it to a function, or store it somewhere.

But, unlike in Go, as long as that mutable reference exists, it has exclusive access to the data: no one else can modify it, or even read it. In Go terms, it’s like having an automatic mutex lock. And when a function doesn’t need to modify the data, it can instead borrow a shared reference, which is read-only, and lots of them can exist at once.

Rust also keeps track of the original data: when it goes out of scope, any references to it are no longer valid. So the compiler can detect many kinds of dangling pointer bugs where you try to use a reference to a value that doesn’t exist any more. That results in undefined behaviour, which is a nice way of saying that something horrible will happen, and part of Rust’s value proposition is “no undefined behaviour—ever”.

In Rust, then, we have to figure out a way to write our programs so that references to data are always valid, and only one mutable reference ever exists at a time. That takes some getting used to (Rust programmers call it “fighting the borrow checker”), but the resulting programs are more reliable, and more likely to be correct.

For example, all Go programmers are familiar with data races, where two or more goroutines try to access some shared data at the same time, with unpredictable results: at best, the program will crash, and at worst, it will continue with corrupted or invalid data.

In Rust, a program like this won’t compile! The ownership and reference rules mean that two mutable references to the same thing can’t exist simultaneously. You just have to solve the problem a different way.

That brings us neatly on to concurrency. I like Go’s concurrency features with channels and goroutines. How does Rust handle concurrency, and are there any similarities I can leverage from my Go experience?

Yes, goroutines and channels are great: a super-lightweight task abstraction that’s very cheap compared to traditional multithreading. On the other hand, Go only gives us the fundamental building blocks: it’s up to us to make sure we use them safely, avoiding data races or deadlocks. And that can be hard to do!

Rust doesn’t have goroutines, but it does have async tasks, which are much like goroutines, only with the usual Rust safety guarantees. There are also some excellent third-party frameworks such as Tokio and Rayon that can just take a bunch of data and automatically figure out the most efficient way to crunch it in parallel.

So, while concurrent programs will always be difficult to write well, if you can do it in Go, you’ll find those skills transfer well to Rust, too.

I like to learn by doing. Are there any good hands-on exercises or projects you’d recommend for a Go programmer getting started with Rust, like the Tour of Go, for example?

Rustlings is a great place to start: it’s a set of interactive bite-size exercises that guide you through all the language fundamentals. If you want to get feedback from a real live human, check out the Rust track on Exercism. There’s also Rust by Example, which is a terrific resource for working example snippets.

It sounds like you’re a fan of both languages. Which do you prefer, and would you recommend that someone who already knows Go should also try learning Rust?

Yes, Go and Rust each appeal to different parts of my brain. I like the radical simplicity and pragmatism of Go: it does a lot with very little, and solves most problems pretty well.

Rust, on the other hand, neatly fills the gaps where Go isn’t an ideal choice: kernels, firmware, embedded devices, and safety-critical applications such as medical devices, industry, aerospace, and so on.

And elevators, of course.

Naturally! So I like that aspect of Rust, and it’s also just a really fun and expressive language. I think it’s well worth anyone’s time to have a play with Rust, and stick with it long enough to get over the initial unfamiliarity of the syntax, and the struggles with the borrow checker.

Even if you decide that Rust isn’t for you, you’ll learn some interesting new ways of thinking about problems, and it also helps you understand more about the different trade-offs that Go makes.

From a career point of view, both Go and Rust will be very valuable skills for the foreseeable future. I think that pretty soon, instead of “Go versus Rust”, we’ll be talking about “Go and Rust versus everything else.”

John, thanks for being our guest, and giving us your perspective on Go and Rust. Where can people find out more about you—for example, if they’re interested in your books or training courses?

It’s my pleasure! Do drop by my website at bitfieldconsulting.com if you’d like to know more, or get in touch—I’ll be happy to chat.