The typical Pinia tutorial tells you to write a Load and Store function to manage, well loading and storing your state from and to the server. I have never seen a single one of them mention this approach, they all are some variation of the load() function called in onMounted().

I think that is a complete disservice to new users just discovering Pinia as for the majority of cases, it is not the easiest or simplest solution to be teaching those new to Pinia, and probably Vue as well.

There is a better way for the majority of use cases using the PersistedState plugin.

This plugin provides for configurable persistence of Pinia stores, and provides support for Session, LocalStorage and Cookie persistence out of the box.

It is trivial to provide custom persistence if you design your API calls in a consistent manner.

There are plenty of articles and tutorials on how to use pinia-plugin-persistedstate, so I am not going to go into how to use it, but instead explain how to design your remote api so making using it is simple and secure as possible.

StorageLike

The main thing to know about this plugin is the following Interface, this is what you implement to allow the plugin to do its magic and relieve you of all the boilerplate error prone stuff it does.

/**
 * Synchronous storage based on Web Storage API.
 * @see https://developer.mozilla.org/en-US/docs/Web/API/Storage
 */
export interface StorageLike {
  /**
   * Get a key's value if it exists.
   */
  getItem: (key: string) => string | null

  /**
   * Set a key with a value, or update it if it exists.
   */
  setItem: (key: string, value: string) => void
}

This is what you want your remote api to look like as well, sort of.

Lets say you have a User and you want to load the current User after they authenticate. Here is what you should make your remote API look like.

I am going to use an actual RESTful API over HTTP, because that is what most people will be familiar with and it illustrates the approach the simplest way possible.

GET /user
PUT /user

GET /user

For security you should make these routes require authentication and enforce it in “middleware” or whatever your server calls request pre-processing interceptors.

You already know who the user is, so you do not need to pass in an id to either call. This is the most secure. It is also the simplest way to write the client and server code as well. The request handler is protected and should never receive anything that is not authenticated, and will get the user id to find and return as data that the authentication handler provides.

PUT /user

contrary to what every TODO app tutorial you and whatever chat “ai” code generator you are using tells you, the PUT verb is NOT just for creation of resources.

As per the official documentation;

The PUT HTTP method creates a new resource or replaces a representation of the target resource with the request content.

semantically, you should use PUT for creating and updating resources when you are providing the entire resource. And if you are doing REST, you are providing the entire resource, right? RIGHT?

This is the most efficient way to updating the remote state, providing the entire resource, and is the entire point behind the REST approach. REST stands for Representational State Transfer, if you are not transferring state you are not doing REST. This example is a REST example so we are doing REST.

If you need to do partial updates to a resource for some reason, then PATCH is the correct way to do it, not POST! There may be reasons to do a partial update of a resource, but almost always they should because of some side effect of the business logic on the server side.

The only reasons to submit partial resource updates to the server are functional;

• you do not have the entire resource to submit with the updated part.

• the entire resource is large and it would be inefficient to transmit such a large payload just to change a very small percentage of the data.

• Whatever you are updating will cause some kind of side-effect on the system receiving the update that is not idempotent.

Partial updates by definition are not RESTful. They are basically RPC calls over HTTP. To be pedantic, I know they are not Remote Procedure Calls, but in they are remote calls to a procedure, and they are over HTTP, so semantically they are a form of RPC. Unless, the partial update is treated as a resource, and then it should be transmitted via PUT. This gets into a kind of recursive rabbit hole quickly.

PATCH /user

The PATCH HTTP method applies partial modifications to a resource.

In comparison with PUT, a PATCH serves as a set of instructions for modifying a resource, whereas PUT represents a complete replacement of the resource.

A PUT request is always idempotent (repeating the same request multiple times results in the resource remaining in the same state), whereas a PATCH request may not always be idempotent.

PATCH is not the correct choice to use for implementing your StorageLike server side implementation.

POST /user

The POST HTTP method sends data to the server.

The difference between PUT and POST is that PUT is idempotent: calling it once is no different from calling it several times successively (there are no side effects). Successive identical POST requests may have additional effects, such as creating the same order several times.

POST is not the correct choice to use for implementing your StorageLike server side implementation.

DELETE /user

There is no DELETE in the StorageLike interface, I am not sure how I feel about this, given how I feel about null. There will be a temptation for a lot of you that do not know better to implement DELETE by just setting the store state to null or whatever you want to DELETE to null and handle that as a special case in the setItem(key,value) function. Resist this urge! It will just lead to suffering.

A better approach would be to do your DELETE explicitly. Click button, call DELETE and then update the store state to reflect the server state. The client state should always represent the server state, not the other way around. This eliminates entire classes of bugs and will save you time in the long run.

If at some point in the future, you find out from profiling that you need to make it more efficient, then do that, but initially, stay as close to client represents server state as possible. The easiest way to do that is to mutate the server state and then sync the client state to match the server.

Conclusion

As I stated in already, I wrote this up because this approach is not the mainstream approach to using Pinia and I think it should be. This is my attempt to add to the information that might be found be people new to Pinia and trying to figure out how to best leverage it.

Tony Hoare introduced the concept of thenull reference in 1965 while designing the ALGOL W programming language.

A null reference means that a reference variable does not point to any object.

He has explicitly stated that the null reference was included "simply because it was so easy to implement." In the context of designing ALGOL W, it provided a quick and straightforward way to represent the absence of a value.

"I call it my billion-dollar mistake" - Tony Hoare (QCon London 2009)

Granted in hind sight it has been misused and abused like just about every other feature of every other language or language paradigm. null in and of itself is not “bad”. It is all the people that do not understand why they should not use it in modern code. There are plenty of alternatives that were not available in 1965.

Programs written in 1965 were tiny compared to even the 1980’s. They had to fit in even smaller amounts of RAM and had to use every bit of memory and processing cycle for something relevant. null was a convenient way to signal that lack of data both in time (cycles) and space (bits).

“You fathers null reference, This is a tool of the diligent programmer. Not as haphazard or reckless as a raw pointer; an elegant solution for a more civilized age” - with apologies to Obi Wan Kenobi (and George Lucas)

While the concept ofnull was a valid solution to a real problem of its time, it is an anachronism that has no place in modern programming languages. Relying on null references in 2025 is just lazy and causes more work and harm than avoiding it.

There is no reason to use null in any language

Regardless of the language you are using, there is no reason to use null (or whatever your language calls it). We are not constrained by the memory or processor limitations of 1985. We are also dealing with code bases that are many orders of magnitude larger than they were in 1965.

Avoiding using null should be the default in modern languages, but it persists as something we all have to manually deal with in every popular language that is ubiquitous today.

And Optional types, Maybe or whatever copium you wrap a null with to check a bool value to see if the reference is null is no better than just returning null, because it carries with it no semantic meaning why null was returned.

This Page Left Intentionally Blank

The phrase "this page intentionally left blank" will be familiar to anyone that remembers reading actual physical manuals.

It served a practical purpose rooted in the mechanics of printing and bookbinding. To avoid confusion and prevent readers from thinking that pages are missing, printers include the "intentionally left blank" notice when a page was blank because of layout or formatting.

In important documents, such as legal contracts or technical manuals, a missing page could have serious consequences. The phrase became more standard with the rise of mass printing and the need for unambiguous consistent documentation of the intent of the printer.

This Reference Left Intentionally Unassigned

The problem with null is there is no semantic meaning to it, it just means this variable does not point to any valid data. It tells you there is nothing to read, but nothing more. This is the “mistake” of null. Is there no data because of an error? Is there no data because the data was asked for and not supplied? Or, was it asked for and actively not provided?

Programming is all about unambiguous instructions to be carried out. We need programming languages to be unambiguous as possible, and we need programmers to use them in as unambiguous ways as possible.

In 1965, large programs were only a few thousand lines of code. 10K lines of code were on the high end of what was even possible given the constraints on memory available. This means one person could read through the code and figure out why some data was missing and hopefully a comment would explain why the value was not set.

Null has no default value

The primary misuse of null was to use it as a marker value for a default value. This was propagated to databases and instead of storing default values, they would be converted to null values to save space and the converted back to some default value when they were read and found to be missing.

The problem with this is there is no way to tell if the value was intentionally set to null in the database or it was an error. If it is not an error, what is it supposed to represent down stream?

The source of the data may not even be consistent when converting values to null when storing them and what it converts them back to when they are null when read back from storage.

A null reference to a string is not ””, that would be a valid reference to a string with a length of zero bytes. An empty string without any characters.

History Lesson

I started writing programs in 6502 assembly language, in the early/mid 1980’s. I understand and appreciate the mistakes that we all made when the craft of programming was new. We were all learning, even 20 years after Tony Hoare invented null we still did not have any reason to think it was a problem. Programs were still written on the same scale in terms of lines of code.

In practice back then, the semantics of null vs ”” were not important. They were the same in practice, even if not in concept.

In C a string was an array of bytes terminated with a confusingly named null terminating character.

A null character was the a byte with all the bits set to ZERO, or a zero byte. Almost all numbers in programs that represented data were encoded in hexadecimal back then, and it was easy enough to convert in your head because every computer was only 8 bits. A single byte ranged from 00 to FF. That is 0 to 254 in value.

In C, a string was encoded as an array of one byte per character plus a terminating zero byte to mark the end of the data. “Hello, World!” would be encoded as; 48 6cs theor5 6C 6C 6F 2C 20 57 6F 72 6C 64 21 00 in memory in physical storage. The 00 was the “This Page Left Intentionally Blank” marker to say, no more valid data exists past this point.

In almost every other language since C, the string type is usually represented in memory as a pointer to the array of bytes and the length of the array and the terminating null character is not needed to mark the end of the data. If you with ASCII string values, even with UTF-8 encoded Unicode, storing the pointer to the string data and its length is only slightly more data to store than just the pointer. It just depends on the sizeof the pointer itself. For zero length string representations the space trade off is marginal compared to benefits of eliminating entire classes of errors.

Perversions begat Perversions

With the perversion of Alan Kay’s ideas into “Object Oriented Programming” paradigm of the 1990’s came even more corruption of valid concepts debased into “billion dollar mistakes”, because of lack of reading comprehension skills or just plain laziness. Remember, this was pre-internet brained days still, there was no excuses, not that there should be today either.

OOPy programmers immediately saw the flaws and problems with “OO” languages like C++ and instead of fixing the languages, they created contrivances they called “Patterns” of design.

These work around were were so numerous and common place they filled an entire book written by a gang of four people. These “Patterns” were canonized as sliver bullet solutions for lazy or incompetent programmers and treated as religious truths over three decades later.

One of them was called the “Null Object Pattern”, first documented in "Pattern Languages of Program Design" by James Coplien in 1995.

Even though this was conceived during the height of the “OOP” madness. It is arguable the best solution to the problem of dealing with missing data. At least, to the extent that it semantically shows that data is missing on purpose and not by accident to a point.

No Data Value > Null Object > Optional[T]

A competing concept to the “Null Object” is “Optional[T]” which has its origins in functional programming. Specifically the Maybe type from the programming language Haskell.

In functional programming languages, where Monads work seamlessly in the language, Optional is an elegant solution. In OOPy languages, like that are C++ based syntax; Java, C#, etc and hybrid languages like Go that are not OOPy and not really functional either, they are nothing more than if == null checks with extra steps.

import java.util.Optional;

Optional<String> maybeName = getNameFromDatabase(userId);

if (maybeName.isPresent()) {
    String name = maybeName.get();
    System.out.println("Name: " + name);
} else {
    System.out.println("Name not found.");
}

is nothing more code and more indirection than just doing

String name = getNameFromDatabase(userId);

if (name != null) {
    System.out.println("Name: " + name);
} else {
    System.out.println("Name not found.");
}

This is just functional programming language have better abstractions but I really do not want to learn how to think in an actual functional manner so lets wedge the idea into Java brained stupidity.

The same people that promote Optional as the solution to null problem, are the same ones that complain about performance and think less lines of code means better. They have no internal consistency.

String missingName = "\u0000" // zero byte character; traditionally null terminating character.

String name = getNameFromDatabase(userId);

if (!name.equals(missingName)) {
    System.out.println("Name: " + name);
} else {
    System.out.println("Name not found");
}

Now this is not any fewer lines of code than the raw null check, but it is more semantically rich that it explicitly informs the reader that there was no name returned.

I use the traditional zero byte null character from C, to represent that no data was provided. This value is useful in that if you try and print it out, you do not get an error and you can test for what is a useless value that should not be in any valid data in any real world system.

If for some exceptionally rare case your system does treat a single zero by character (or the Unicode equivalent) as valid data there are literally hundreds (thousands if using Unicode) other characters you can choose from.

Here are some Unicode characters that are specifically suited for use as a marker character for intentionally missing data.

• Null Character (U+0000):

  • As demonstrated in the previous Java example, this is a classic choice. It's explicitly designed to represent "null."

  • However, it can be difficult to display and handle in some environments.

• Unit Separator (U+001F):

  • This is a control character that's rarely used in normal text.

  • It's intended for separating data units, this single character by itself can be seen as analogous to representing the absence of data.

• Object Replacement Character (U+FFFC):

  • This character is often used to represent an unknown or unrenderable object.

  • While not strictly `null`, it can be used to indicate the absence of a meaningful value.

• Zero Width No-Break Space (U+FEFF):

  • While this is often used as a Byte Order Mark, it is also a zero width character, and therefore would not visually show up. It is also very unlikely to be used in normal text.

But how do you communicate why the data missing?

“\u0000” is a better value to use than null to represent missing or no-value data.

It is not perfect, it is will missing the semantics of why the data is missing.

All you have to do is expand on this idea, of invalid printable/invisible characters and you can encode as much information into your missing data as you see fit.

If you look up some data from a data store or external system and the data is missing because it is not found then this would be an semantically appropriate return value.

Object Replacement Character (U+FFFC):

• This character is often used to represent an unknown or unrenderable object.

• This can be used to indicate the absence of a meaningful value.

You can always combine one of the above alternatives with one of the following 6400 values to create as many missing data and here is why reason codes as you need!

• Private Use Characters (U+E000–U+F8FF):

  • These characters are reserved for private use, so you can choose any character within this range.

  • This guarantees that it won't conflict with any standard Unicode characters.

  • This however makes the code less portable.

If you want to get even more clever you can return an entire printable error message up into the Private User Character range by adding 0xF8FF to each character so that none of them a printable and to print out the error message move them back down.

function stringToByteArray(str) {
    const encoder = new TextEncoder();
    const encoded = encoder.encode(str);
    return Array.from(encoded).map(byte => byte ^ 0xF8); // XOR with a byte value
}

function byteArrayToString(byteArray) {
    const decodedBytes = byteArray.map(byte => byte ^ 0xF8); // XOR with the same byte value
    const decoder = new TextDecoder();
    return decoder.decode(new Uint8Array(decodedBytes));
}

function isErrorMsg(byteArray) {
    for (let i = 0; i < byteArray.length; i++) {
        // Basic printable character range (ASCII)
        if (i >= 0xF8FF) {
            return true;
        }
    }

    return false;
}

// Example usage:
const inputString = "Hello, world! 😊";
console.log(inputString);
const byteArray = stringToByteArray(inputString);
console.log("isError:",isErrorMsg(byteArray));
console.log(byteArray);

const decodedString = byteArrayToString(byteArray);
console.log(decodedString);

This outputs the following.

Hello, world! 😊
isError: true
[
  176, 157, 148, 148, 151,
  212, 216, 143, 151, 138,
  148, 156, 217, 216,   8,
  103,  96, 114
]
Hello, world! 😊

This is just an example using the lowly string, you are probably wondering how you would deal with a more complex data type like a Person?

/**
 * string marker value for not being initialized
 * this is more semantically informational that using null or undefined
 * since this shows deliberate intention; ie:This Page Intentionally Blank
 * @type {string}
 */
export const no_string_data = '\u0000';

/**
 * Date marker value for not being initialized
 * since this shows deliberate intention; ie:This Page Intentionally Blank
 * @type {Date}
 */
export const no_date_data = new Date('0001-01-01T00:00:00.000Z');

/**
 * uint marker value for not being initialized
 * since there are only number types, this shows two things, that the variable
 * is intended to represent unsigned integers, by using a negative value
 * this shows deliberate intention; ie:This Page Intentionally Blank
 * @type {number}
 */
export const no_uint_data = -1;

/**
 * this string represents the lack of a boolean value
 * the idea is to union string with boolean as valid values
 * and test for this specific string if the value is a string type.
 * Zero Width No-Break Space - \uFEFF
 * @type {string}
 */
export const no_bool_data = "\uFEFF";

export function isNoBooleanData(value) {
  if (typeof value === 'string') {
    return value === no_bool_data;
  }
  return false;
}

/**
 *
 * @type {{id: string,
           first_name: string, 
           last_name: string, 
           opininated: boolean, 
           birthday: Date, 
           age: number
          }}
 */
const no_person_data = {
    id: no_string_data,
    first_name: no_string_data,
    last_name: no_string_data,
    opinionated: false,
    birthday: no_date_data,
    age: no_uint_data,
}

The one obvious exception to these approaches, and there is always at least one, is the Boolean type.

In this example, I could have done the lazy thing and just set opinionated = false and been done with it, but that would not be the wise choice given that all the other datatypes have no_data alternatives to check for.

With only two values, both of which are equally valid as data how to you deal with missing data.

In languages that are not strongly typed like JavaScript you have alternatives.

Here I have used the no_bool_data value which I set to the Zero Width No-Break Space, the test becomes simple, isNoBoolData() is no more code that == null or isPresent() and much more semantically informational.

Specific No Data Types

In strictly typed languages you can create specific no data types and check for the type or use a language feature to test for missing data. This is just one example of one approach in Go.

package main

import (
    "fmt"
)

type NotProvided string

const firstNameNotProvided = NotProvided("\u0000\uF8FF")
const lastNameNotProvided = NotProvided("\u0000\uF900")


func isNotProvidedType[T string | NotProvided](val T) bool {
    _, ok := interface{}(val).(NotProvided)
    return ok
}


func main() {
    fmt.Printf("data provided: %t\n", isNotProvidedType("this is a test"))
    fmt.Printf("first name provided: %t\n", isNotProvidedType(firstNameNotProvided))
    fmt.Printf("last name provided: %t\n", isNotProvidedType(lastNameNotProvided))
}

this results in this output

data provided: false
first name provided: true
last name provided: true

Language with matching syntax like Erlang make this even easier, but then again functional languages have elegant compositional chaining that procedural languages usually do not.

Strongly Typed Languages

Even though languages like Go have the concept of nil which is effectively a strongly typed null reference and points to that types Zero Value. Which is different depending on the type.

It still suffers from lack of semantic meaning other than, nothing of a type and I find myself using No Data types that I can test against for reasons why something is not returning data.

Go is not the best example either because of its idiom of returning an error value when ever a return value could be nil to explain why it is nil and of course the way to check if there is no error is to check and see if the returned error is nil.

Yet some functions return back a boolean, ok/exists/success type value to signal that a value was returned successfully. As in when asserting an interface{} is of a type, or checking to see if map has a value for a key.

// pre-generics way to test if something is of a type
var val interface{}
if _, ok := val.(string); ok {
   fmt.Println(string(val))
}


// does a map[string]interface{} contain a key
// if the value is a pointer type you could test
// v != nil but that is less informational than exists
m := make(map[string]string)
if v, exists := m["somekey"]; exists {
    fmt.Println(v)
}

Conclusion

There is no reason to compromise your data integrity and code clarity by slinging null all over your code base.

The more important concept is downstream data consumers.

When others access your data they need to know why data is missing so they can feel confident in the validity of the data. Especially if you are the authoritative source of the data.

If you change your rules for what null represents as default when read back in, there is no way for downstream consumers to know about this change. They might have see that null actually means 0 for some datum, but you decide that it actually means -1 now.

This causes confusion and havoc for downstream consumers use the data and forward what is now the wrong data downstream when they replace the null with what they think the default value should be.

When that data comes full circle back to the authoritative source more time and money will be lost than the time and money it takes to avoid the possibility in the first place.

Returns the first N items from a sequence.

// FirstN takes an iter.Seq[int] and returns a new iter.Seq[int] that
// yields only the first 'limit' items without creating intermediate slices.
func FirstN[T any](original iter.Seq[T], limit int) iter.Seq[T] {
    return iter.Seq[T](func(yield func(T) bool) {
        count := 0
        for item := range original {
            if count < limit {
                if !yield(item) {
                    return
                }
                count++
            } else {
                return
            }
        }
    })
}

SkipFirstN

Skips the first N items and returns the rest of the sequence.

This could have been done with a regular push iterator, but it would take an intermediate count to keep up with how many items had been skipped and not be quiet as clear what was happening.

func SkipFirstN[T any](seq iter.Seq[T], skip int) iter.Seq[T] {
    return iter.Seq[T](func(yield func(T) bool) {
       next, stop := iter.Pull[T](seq)
       defer stop()

       for i := 0; i <= skip; i++ {
          _, ok := next()
          if !ok {
             break
          }
       }
       for {
          v, ok := next()
          if !ok {
             break
          }
          if !yield(v) {
             return
          }
       }
    })
}

SkipAndLimit (aka: SubSeq)

Example inline composition of FirstN and SkipFirstN this is just an example.

This is the equivalent of doing [first:limit] on a slice but on an iter.Seq as it is processed as a zero cost abstraction.

// I wrapped this in a function as straw man example just to get the highlighting to work
func SkipAndLimit[V any](it iter.Seq[V],, skip int, limit int) iter.Seq[V] {
    return FirstN[V](SkipFirstN[V](it, skip), limit)
}

// you could just inline the composition like this, but this is not as self documenting
// as calling a function that semantically shows intent  in its name.
subSeq := FirstN[string](SkipFirstN[string](it, skip, limit)

Chunk

creates a sequence of fixed size sequences from the original sequence without creating any intermediate slices or arrays.

This is useful when you are feeding an api data that only accepts N number of items at time. With some work this could be made to work with goroutines and channels to process the chunks in parallel as they are generated.

// Chunk returns an iterator over consecutive sub-slices of up to n elements of s.
// All but the last iter.Seq chunk will have size n.
// Chunk panics if n is less than 1.
func Chunk[T any](sq iter.Seq[T], size int) iter.Seq[iter.Seq[T]] {
    if size < 0 {
       panic(errs.MinSizeExceededError.New("size %d must be >= 0", size))
    }

    return func(yield func(s iter.Seq[T]) bool) {
       next, stop := iter.Pull[T](sq)
       defer stop()
       endOfSeq := false
       for !endOfSeq {
          // get the first item for the chunk
          v, ok := next()
          // there are no more items !ok then exit loop
          // this prevents returning an extra empty iter.Seq at end of Seq
          if !ok {
             break
          }
          // create the next sequence chunk
          iterSeqChunk := func(yield func(T) bool) {
             i := 0
             for ; i < size; i++ {
                if ok {
                   if !ok {
                      // end of original sequence
                      // this sequence may be <= size
                      endOfSeq = true
                      break
                   }

                   if !yield(v) {
                      return
                   }
                   v, ok = next()
                }
             }
          }
          if !yield(iterSeqChunk) {
             return
          }
       }
    }
}

Chunk2

Same idea as Chunk but works on iter.Seq2

// Chunk2 returns an iterator over consecutive sub-slices of up to n elements of s.
// All but the last iter.Seq chunk will have size n.
// Chunk2 panics if n is less than 1.
func Chunk2[K any, V any](sq iter.Seq2[K, V], size int) iter.Seq[iter.Seq2[K, V]] {
    if size < 0 {
        panic(errs.MinSizeExceededError.New("size %d must be >= 0", size))
    }

    return func(yield func(s iter.Seq2[K, V]) bool) {
        next, stop := iter.Pull2[K, V](sq)
        defer stop()
        endOfSeq := false
        for !endOfSeq {
            // get the first item for the chunk
            k, v, ok := next()
            // there are no more items !ok then exit loop
            // this prevents returning an extra empty iter.Seq at end of Seq
            if !ok {
                break
            }
            // create the next sequence chunk
            iterSeqChunk := func(yield func(K, V) bool) {
                i := 0
                for ; i < size; i++ {
                    if ok {
                        if !ok {
                            // end of original sequence
                            // this sequence may be <= size
                            endOfSeq = true
                            break
                        }

                        if !yield(k, v) {
                            return
                        }
                        k, v, ok = next()
                    }
                }
            }
            if !yield(iterSeqChunk) {
                return
            }
        }
    }
}

SeqToSeq2

This function takes a sequence and a key generator function and returns an iter.Seq2 without creating any intermediate slices or arrays.

func SeqToSeq2[K any, V any](is iter.Seq[V], keyFunc func(v V) K) iter.Seq2[K, V] {
    return iter.Seq2[K, V](func(yield func(K, V) bool) {
       for v := range is {
          k := keyFunc(v)
          if !yield(k, v) {
             return
          }
       }
    })
}

Map

Most of you probably think I should have put this one first. It is the most similar to a Monad with the bind and map behavior, it is named Map for a reason.

But that would completely miss the point of the iter package. It is not about functional programing, it is about a idiomatic way to create your own custom iterable types.

This is the closest to Monad behavior by definition, skipping the bind semantics and just applying the map function to the value. If your value object had a field called ID that should be the key, the keyFunc would be as simple as returning v.ID or as complex as calculating a SHA256 hash of the object to use as the key. Or something that is not even a map, like returning FirstName and LastName from Person structs.

The fact that the K value is typed any and not comparable means it is not just for keys from maps.

func Map[T any, R any](it iter.Seq[T], mapFunc func(t T) R) iter.Seq[R] {
    return func(yield func(R) bool) {
        for i := range it {
            if !yield(mapFunc(i)) {
                return
            }
        }
    }
}

Map2

Does the same thing as Map but allows to provide for both a K and V transform function.

A canonical PassThruFunc for the times when I did not want to change the key or value.

Using this instead of writing in inline is better because it shows intent to not do anything with the value. An inline function shows no intent. Much like “This Page Left Intentionally Blank” shows intent to the reader that they are not missing a page by accident. Very important for everyone reading it in the future, yourself included. It could also be used for the value when only the K needs to be transformed.

// PassThruFunc passes thru the value unchanged
// this is just a convience function for times when you do not want to transform the key or value in Map2
// so you do not have to write an inline function and clutter up the code more than it needs to be.
func PassThruFunc[T any](t T) T {
    return t
}

func Map2[K any, V any, KR any, VR any](it iter.Seq2[K, V], keyFunc func(k K) KR, valFunc func(v V) VR) iter.Seq2[KR, VR] {
    return func(yield func(KR, VR) bool) {
        for k, v := range it {
            if !yield(keyFunc(k), valFunc(v)) {
                return
            }
        }
    }
}

DocumentIteratorToSeq

Firestore Document Iterator is one of the many non-standard iterator implementations that abound in Go libraries and clients

Here it is wrapped in an iter.Seq without any intermediate slices or arrays being generated.

// DocumentIteratorToSeq converts a firestore.Iterator to an iter.Seq.
// value is a pointer to the type V
func DocumentIteratorToSeq(dsi *fs.DocumentIterator) iter.Seq[*fs.DocumentSnapshot] {
    return func(yield func(ref *fs.DocumentSnapshot) bool) {
        defer dsi.Stop()
        for {
            doc, err := dsi.Next()
            if errors.Is(err, iterator.Done) {
                return
            }
            if err != nil {
                log.Error().Err(err).Msg("error iterating through Firestore documents")
                return
            }
            if !yield(doc) {
                return
            }
        }
    }
}

DocSnapShotSeqToType

Here we create a semantically named function that represents something that needs to be done repeatedly. Iterator over a collection of DocumentSnapShots and convert them to actual Types.

The seq.Map function I wrote is usually simple enough to inline, but some cases are so common and repeated it makes sense to semantically name them for ease of use. And no naming it not that hard unless you are not a native English speaker or your function is so poorly designed it can not be named semantically specific.

func DocSnapShotSeqToType[R any](it iter.Seq[*fs.DocumentSnapshot]) iter.Seq[*R] {
    return seq.Map[*fs.DocumentSnapshot, *R](it, func(dss *fs.DocumentSnapshot) *R {
        var t R
        err := dss.DataTo(&t)
        if err != nil {
            log.Error().Err(err).Msgf("error unmarshalling Firestore document with ID %s", dss.Ref.ID)
            panic(err)
        }
        return &t
    })
}

DocumentIteratorToSeq2

Same as above but the DocumentSnapShot.Ref.Id is used as the K value as a string in the returned iter.Seq2.

This is short enough to inline, but I need to do this in lots of places in library code over and over again so making a semantically intuitive named function makes my code clearer and more readable for intent.

I make a point of always using string types for document id so this is used everywhere I process collections.

// DocumentIteratorToSeq2 converts a firestore.Iterator to an iter.Seq2.
// doc.Ref.ID is used as the "key" or first value, second value is a pointer to the type V
func DocumentIteratorToSeq2(dsi *fs.DocumentIterator) iter.Seq2[*fs.DocumentRef, *fs.DocumentSnapshot] {
    return seq.SeqToSeq2[*fs.DocumentRef, *fs.DocumentSnapshot](DocumentIteratorToSeq(dsi), func(v *fs.DocumentSnapshot) *fs.DocumentRef {
        return v.Ref
    })
}

Another iter.Seq2 that is useful for Firestore manipulation is [path, DocumentSnapshot] which is easy to inline as the following and probably warrants its own function if it gets used often enough.

pathDocumentSnapshot := seq.SeqToSeq2[string, *fs.DocumentSnapshot](DocumentIteratorToSeq(dsi), func(v *fs.DocumentSnapshot) string {
    return v.Ref.Path
})

Imports

Here is a list of the imports used in the code examples above.

I started using ZeroLog long before slog was added to the standard library and I have gotten spoiled by its features. Most of I rarely use, but when I do need them they are important and not in the slog implementation.

I do not want to have to maintain mixed logging APIs. I had to deal with that in the Java world where sometimes 4 or more different logging libraries were used in a code base and adapters and all that were a nightmare. So, it is easier to just stick with ZeroLog rather than convert all the dependencies I use that I have written to slog.

Errorx is also something I have come to rely on heavily, it makes it really easy to have semantically specific type safe errors so when things breaks in a server with dozens of nested calls in the tree it is not a mystery where, what and why something happened.

import (
    "iter"
    "slices"
    "strings"

    fs "cloud.google.com/go/firestore"
    "google.golang.org/api/iterator"
    "github.com/rs/zerolog/log"
    "github.com/joomcode/errorx"
    errs "github.com/jarrodhroberson/ossgo/errors"
)

These new function definitions are much more flexible that they might first look. I am writing wrappers around all the non-standard iterator like collection or streaming data access that I deal with daily and decided to share my solutions with you.

This is what the definitions of these functions look like.

The first one is for iterating over a stream of single return values. In Go this means slices and arrays.

The great thing is now you can define your own “Collection” types and provide an idiomatic iterator for them now.

// Seq is an iterator over sequences of individual values.
// When called as seq(yield), seq calls yield(v) for each value v in the sequence,
// stopping early if yield returns false.
// See the [iter] package documentation for more details.
type Seq[V any] func(yield func(V) bool)

The implementation of these seem to be confusing a lot of people. Some people think it is too complicated, some people think is it too simple.

I really want to say you are iterating over a list of items, but that is not correct, it might not be a list, so I will use the term sequence because that is the most semantically correct.

I think they reached a very good balance with minimal complexity for maximum functionality. Is this implementation as powerful as the iteration in functional languages. No, but it does 80% or more of what they do and pretty close to 100% of what the majority of people actually use day to day for minimal complexity.

Here is a non-contrived example that is short enough to be written inline if you need to generate a simple range of numbers. I put it in a function for some testing I was doing to generate data for more complex adapters and wrappers to use as contrived test data.

This does just what it says in the name of the function, it generates a sequence of ints from start to end inclusive.

func IntRange(start int, end int) iter.Seq[int] {
    return func(yield func(int) bool) {
        for i := start; i <= end; i++ {
            if !yield(i) {
                return
            }
        }
    }
}

// here is how you would use it
ints := seq.IntRange(0, 99)

for i := range ints { 
    fmt.Println("%d", i
}

The great thing about these new iterator functions is you do not have to allocate a bunch of memory to process sequences of data that is being dynamically generated. Whether that is from an algorithm or from some I/O operations it makes everything “look” the same in the code.

This way of iterating a sequence is considered a “Push” method. It is very much like .Each()/.ForEach() would be in other languages. The implementation is very much like generators in Python. They even share the yield keyword. There are similar in some ways and different in others.

The most important difference is that the Go implementation is a specific function definition, not just a keyword you can put in any function.

Monadish composition

The most powerful thing about this new feature is you can chain them in a very Monadish manner.

This function takes any thing with a .Stringer() interface and returns the value of .String() in a lazy generative manner. It only does the processing when it is required.

func ToString[T fmt.Stringer](it iter.Seq[T]) iter.Seq[string] {
    return func(yield func(string) bool) {
        for i := range it {
            if !yield(i.String()) {
                return
            }
        }
    }
}

This basically wraps another iter.Seq and transforms the data as it requested. You can chain like this to filter things out or add things in very clearly and concisely.

This is one of the most important things to know about these new functions. They were designed for composition. If you do not understand Monads and you can learn how these functions work, then you are actually about 90% of the way there.

Go is not a functional language, and as we know with the attempts to shoehorn functional programming paradigms where they do not fit; Java, JavaScript. Go is no exception, but these iterator functions do not feel forced or out of place. They fit naturally into the idiomatic code that you have been writing for the last ten years.

iter.Seq2

iter.Seq2 is the map-like iterator. It is not limited to maps and is not even specifically tied to the map[] type. If you read the source, the two values it returns are labeled K,V but the k type is any and not restricted to comparable like map[] would limit keys.

Therefore you can use it to iterator over sequences and expose their unique ids as the K and the actual item in the list as the V. There is a good argument to make that iter.Seq2 could be more useful in almost every case where you are dealing with a sequence of Entity type data (data that has an identity). iter.Seq would still be the best semantic choice for sequences of scalar/value objects.

In this next example I create a iter.Pull wrapper around an inline iter.Seq that simply generates an integer one more than the last one. Do not worry about the iter.Pull I will explain it next, it is very simple to understand.

Then I pass that as a function to seq.SeqtoSeq2 to use as a key generator for the values from ints.

    func SeqToSeq2[K any, V any](is iter.Seq[V], keyFunc func(v V) K) iter.Seq2[K, V] {
        return iter.Seq2[K, V](func(yield func(K, V) bool) {
            for v := range is {
                k := keyFunc(v)
                if !yield(k, v) {
                    return
                }
            }
        })
    }

    // key generator sequence
    next, stop := iter.Pull(func(start int) iter.Seq[int] {
        index := start
        return iter.Seq[int](func(yield func(int) bool) {
            for {
                if !yield(index) {
                    return
                }
                index++
            }
        })
    }(0)) // creates an infinitely increating counter generator

    ints := seq.IntRange(0, 99)

    intMap := seq.SeqToSeq2[int, int](ints, func(v int) int {
        k, ok := next()
        if !ok {
            stop()
            return -1
        }
        return k
    })

Now I can get the index of each item in ints as a key with iter.Seq2 and the indexes are generated as they are needed and the stop() discards the key generator sequence when the wrapped sequence is done. No intermediate slices or array buffers are generated during this conversion.

iter.Pull

iter.Pull is the inverse iterator paradigm of iter.Seq. iter.Seq is called a push iterator. It pushes you the next value of the sequence during the iteration loop.

iter.Pull is obviously a pull iterator, or the opposite of push. You have to ask for the next() value when you want it and you have to test for the end of the sequence by looking at the value of ok and ending the iteration when ok is false.

In the above key generator sequence you could not do an infinite series of data without resorting to making the code much more complex with goroutines and channels to manage the key generator function and dispose of it when done with the data.

iter.Pull makes this very easy with the stop() function that it provides.

the push iterators are going to do the job for the majority of iteration needs. The pull iterators are there to cover the times that the push iterators just will not work.

The original ReST idea, which is supposedly spelled out in the abbreviation, gets lost in the abbreviation.

It was simple, transfer a typically full representation of the state of your data in its entirety to every system that needs it to enable loose coupling and stateless distributed processing.

The idea behind ReST was perverted for the same reason that “Object Oriented” was perverted from the original meaning that Alan Kay, the creator of the term, used it for.

“I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind” -- Alan Kay, OOPSLA '97

People just did not understand that it was just that simple and wanted to make it more complex, or they realized it was that simple, but it was more complex to implement so they just decided to say it meant something else. What is now known as OOPy.

Inevitable Perversions

ReST became RPC over HTTP with JSON as the line format but using more than POST for extra steps. Throw in misusing PUT/POST and embedding versioning into the identifier as hold my beer extra points.

GraphQL is a reaction to so many people getting ReST so wrong for so many years. It is understandable, but I think that GraphQL had good intentions but did not learn from any of the REST mistakes in communication of the idea.

People getting microservices and ReST wrong at the same time and making way too many calls because they got the granularity of the calls and the data modeling wrong. Domain Driven Design and Behavior Driven Development are two of the most important reasons that microservices granularity is wrong, because both of those things were flawed, misinterpreted ideas and became more consultant dogma for billing hours than ideas for flexible approaches.

The idea behind GraphQL is sound for some solutions, the misinterpretation and implementation of it as a general query language for public api consumption is the problem. It is basically the flip side of the ReST/Microservice problem. It is the pendulum swung too far the other direction. Naïve implementations are no better than letting every end user submit adhoc SQL to an RDBMS.

History Ignored is History Repeated

In practice GraphQL seems to be a not invented here syndrome implementation of OData. Maybe they created it without knowing about OData?

OData was a reaction to address the same things that GraphQL was supposed to and does it in a fairly declarative fashion. GraphQL is the Facebook “not invented here” imperative version of OData.

I think that a combination of OData being an “extension” specification for RESTful paradigm, and more importantly, philosophical and/or political reasons for people picking GraphQL over OData or vice versa when they evaluate a protocol for their service.

It is more important to know what both of them do not support or at least make supporting extremely difficult than what they are supposed to do. I find fault with both specifications for many of the same reasons, they include too much kitchen sink functionality as “MUST” type behavior, they leave too much behavior as ambiguous to the point that implementations are not compatible.

Bad Idea in the 1990s.

We did this in the 1990s before the internet with server side “dynamic SQL” generation and ORMs. It was a bad idea then and a worse idea by the early 2000s when the Internet became ubiquitous.

My experience reading “in the wild” accounts of implementations and at my employer was that GraphQL was implemented by inexperienced developers as a naive way to just let the “front end” ask for what they wanted in an adhoc manner instead of providing a way to narrow down or expand the Representation of the data they were requesting as needed.

At my employer, this caused complete chaos for the “legacy RDBMS” teams when applications were generating ad-hoc SQL that was far from optimized, grinding the servers to a halt with a single call from a single client, and in a few cases crashing the server down to the OS level repeatedly.

In a couple of these cases, I had argued against it just for this very reason, and like Cassandra, was ignored. The reason was “the UI” will restrict what is requested. Nobody told the developers writing the UI this and they put selections that contradicted each other or created what were effectively cartesian joins from recursion. When asked why this did not come up in testing, they admitted there were so many fields that could be combined in so many permutations that there was no way to test it in a person's lifetime.

Incompetent People misusing things

Incompetent people misusing things and not being able to read for comprehension is not a reflection on ReST or GraphQL as good or bad.

ReST and GraphQL can both be done correctly. Understanding how not to do ReST or GraphQL is probably more important, since every other way is correct, even if not the most correct.

GraphQL leans into the community that did ReST as RPC with extra steps with JSON and POST/PUT wrong with a single endpoint and RPC semantics. This allowed an immediate comprehension, even if it is naive and at the expense of GraphQL being misinterpreted the same way the theory behind REST was.

Rearranging Deck Chairs

The initial implementation of GraphQL servers was to act as a facade over existing RESTful microservices which did nothing to alleviate the “too many calls at the wrong granularity” level problem, it only moved aggregation of them to the server side network.

It also made these implementations “reference” implementations by default, which misrepresented the correct implementation of GraphQL which was to parse the request and only query the data source for all the data that was needed at the same time not requesting the data that was not needed. Many GraphQL servers to this day just use a naive ORM to generate a query that requests all the data from all the entities and then filters out unwanted fields or entities during the serialization process. It just moves the problem to a potentially more expensive location.

Why should you decide to use something?

This is more important than any other decision you make in a project. If you pick the incorrect technology, the rest of the project is at best going to be a slog and slop in production or at worst doomed to failure.

It should be very easy to choose the correct technology to use what you know.

This is a trap that many people fall into. The proverbial "to a hammer everything looks like a nail " trap.' Just because you "know" something does not mean it is the correct tool for a given problem, and if you really "know" your tools, you know when this is true.

The actual problem is too many people do not really know their tools to the depth they need to honestly evaluate them, and thus themselves for using them.

How we got here.

You only really "know" something when you know what it either can not do or is completely unsuited for a given problem.

JavaScript is the current perfect example of this idea and people trying to use it for everything, even things it is the absolutely wrong choice because that is all they know.

NodeJS is almost 100% the reason for this. Previously it was Perl and before that it was Shell Scripting, mostly Bash. Ruby tried to replace Perl but failed as Python beat it out in mindshare and rightly so.

I leave off Python from this list of shame because Python was designed as a support language for other languages, specifically C and C++. The community has mostly stuck to its intended design and very open about writing performance oriented code in more appropriate languages and then calling that code from Python.

When NodeJS first came out, I saw it for what it was. A framework already existed in Python called Twisted, that did every thing NodeJS did. I was unimpressed. I knew it was not going to scale horizontally, the JS runtime it used was single threaded, just like CPython, which was the only production grade Python runtime at the time.

Much like Python, Twisted worked great for what it did. You got exactly what was promised. The problems started when you had to stray past these capabilities. Twisted was a solution to the problem that CPython was, and still is, single threaded.

Twisted introduced an async facility that allowed it to appear that Python was not single threaded and provided features for you to manage this illusion fairly well. With these new features, came new complexities but if you knew you needed to use Twisted, you should be able to understand these new concepts fairly quickly.

When I saw the hype around NodeJS and researched it a bit I realized that NodeJS was the same solution to the same problem with the same limitations, but in JavaScript. And JavaScript was not as capable as language as Python at the time.

NodeJS is a more appropriate technology to use than Python/Twisted in 2024 simply because it is the VHS of single threaded language async solutions. Twisted is the Beta, first to market and at the time a much superior solution in almost every way, but NodeJS rode the JavaScript hype mindshare wave and has more documentation, more support and extensions/features because of it.

Things work until they do not anymore.

Note: Replace Python/Twisted with JavaScript/NodeJS and Hardware/Cloud in the following and you have the same problem and almost the same outcome for 2024.

It was about 2007 and our Python/Twisted project worked really well for what it was intended to do, on the hardware we intended it to run on. Then a Sun sales representative took someone at the company golfing and to an expensive dinner and all of a sudden we were switching from relatively beefy Intel Xenon W5590 based servers that easily scaled vertically to relatively weak Sun Niagara T2 servers that were supposed to scale horizontally.

So when were were scheduled to go to production, we had a bunch of them available because they were not suitable for any of our existing applications. All new applications were required to be provisioned on all these idle servers. This should tell you everything you need to know about what the immediate problem was.

Our application was an I/O bottlenecked application. It just read some data from an RDBMS on first access and then cached that data and updated the server occasionally. It easily scaled vertically, just add more RAM and you can service more clients since most of them were idle. These Intel Xenon machines only had 4 cores and 8 thread but that was plenty, they just needed fast I/O and lots of RAM since the CPU was extremely fast for the time.

The Niagra servers were designed to be web servers, which in many ways were appropriate for our task. Lots of sporadic short lived connections that were I/O bound. The ones we had were about the same cost as the Intel machines were had been using, but were speced with less RAM. This and the fact that each core was approximately as powerful as a Pentium Pro 200 made them the absolutely wrong choice for our Twisted/Python application.

These machines were designed to scale horizontally. A single threaded application no matter how async only scales vertically. These machines were a terrible choice for this application.

I did what any reasonable Principal Engineer would do, I improvised.

The RPM already deployed a start, restart, stop script to the was modified to use a script that started one instance of the app per core on the current machine. This was an incredibly hacky way to solve this problem, but we were not given any time to devise a better solution before it had to go to production. We told ourselves, "this is fine" it will get replaced soon with some more appropriate, I had just gotten comfortable with Erlang at the time and figure, porting this simple app would be a good exercise.

It was, I re-wrote the application in Erlang, it preformed orders of magnitude better and only one instance was required. When we tried to get this version moved to production after testing it reality set in. Management told us we were correct "this is fine", the hacky solution was another teams problem now and we were not allowed to deploy the Erlang version until what was in production broke. It never did, it had 100% uptime for the almost 3 years that application was in service.

I just did not know enough Erlang to write the application eight weeks earlier or I would have just written it in Erlang to begin with. The fact that the other Principal Engineers I worked with tried to convince management that the Python version would never work and after they said that Erlang was a bad choice. They wanted to use C or Java and estimated a 6 - 9 month design and architecture timeline and about as much development and testing. I wrote 2 versions, in series, while running and overseeing three other projects in a span of about six weeks, eight if you include two weeks of learning Erlang.

Constraints are your friend

What it will not do are constraints that actually free you up to come up with better solutions most of the time. Novel solutions, not "clever" ones, that you come up with from working around arbitrarily imposed constraints or limitations forces you to approach problems from directions you would normally not consider.

This is how technology gets used for things they were not designed for, hopefully in a good way. It also forces you to re-think your ideas about what you "know" about solutions to similar problems with slightly different constraints in the future.

What programming languages you need to know.

You must know Java!

Note that I did not say you must write Java, but you must know it. Just like in the early 2000's, I knew CORBA but I did not write CORBA, it got me plenty of work, porting CORBA "Orbs" from C++ to Java. I also knew C++, but at the time I only wrote C++ for game mods/side projects.

The world runs on Java today, like it or not, trillions of lines of code have been written in Java since 1.2 was released in 2000. You will have to deal with a Java system at some point, and you may need to integrate with an existing Java system so you will have to read through JavaDoc to know how it works. You may need to port Java source code to a new language. Just like those that came before you had to know COBOL to port a COBOL application to Java, this is the way.

You also must know Java to write Groovy, Scala or Kotlin because it all ends up in the JVM so you must know how the JVM works and what it does not do.

I have not written any significant Java code in about 7 years. I wrote a good bit of Groovy code about 6 years ago, but the most significant amount of code I have written in the last 6 years has been Go, JavaScript and Rust.

You must know JavaScript!

The web runs in a browser and the browser runs JavaScript.

You also must know JavaScript if you want to write programs for the browser in languages other than JavaScript for the same reasons you must know Java and I had to know COBOL. You still must interact with it at some non-trivial level to not use it.

If you want to use Web Assembly instead of JavaScript you still need JavaScript to load the Web Assembly to begin with.

You use another language that cross compiles to JavaScript, you still need to know JavaScript to debug why the cross compiled code is breaking and map it back to whatever you cross compiled from.

I really like using JavaScript for actual scripting the last few years. NodeJS and its other runtime competitors as well as having mature dependency management tools.

ZX is the obvious conclusion for every developer that already has to deal with JavaScript in their toolchain.

Even if you are not doing JavaScript development directly, some tooling or support tool you rely on is going to be written in JavaScript, which means you are going to have to have NodeJS install and all the tooling around it, so ZX is just one more package to install, is managed and updated by your package manager. Why bother with switching to Python when you must already deal with JavaScript.

You should know Go!

You must know a relevant general purpose programming language.

Go is an obvious choice for a modern, relevant general purpose programming language in 2024. There are plenty of articles about why Go an S tier general purpose language so I do not need to waste time or space writing about that here.

You should know Rust!

If you must know a relevant programming language to do high performance, resource constrained or system level programming. You should know Rust.

Rust is an obvious choice for a modern, relevant high performance, low level, purpose programming language in 2024. There are plenty of articles about why Rust an S tier modern language for all the constraints listed above, but also as a general purpose programming language, but you still must know C++.

C++ has not lost its relevance and will not for a significant number of years for the same reasons that Java will not. The trillions of lines of code and the momentum that goes along with that kind of mindshare. C++ continues to be developed and adopt more modern approaches to its language and runtime libraries, this is what keeps it relevant. It is not going anywhere anytime soon.

Rust would not be my first choice for DOM manipulation in the Browser, but for network libraries for accessing a server endpoint, a Rust based Web Assembly client would not be the worst choice. It would be more work than JavaScript, but if it needed to do some advanced high performance operations it is the S tier language for Web Assembly.

Conclusion

I ignored platform specific languages because if you are writing for iOS or Android you know what your options are already. The same is true if you are targeting Windows only applications, you have that constraint and your options are limited or obvious for them.

Regardless of your platform, to be a well rounded programmer, you must know a good general purpose language, Go is my platform agnostic recommendation. You must know JavaScript if you want to do anything browser related or work with any JavaScript based tools in your toolchain. You should know at least one low level systems language like, Rust is my platform agnostic recommendation. C or C++ will be the obvious winner in some cases which will be obvious.

The first is easy the second hard that is why everyone ignores it.

Group your packages by types and the functions that manipulate those types. More functional organization means looser coupling and high cohesion.

This is the project directory layout I have adopted for all my projects. It is intuitive, semantically rich and most importantly it is loosely coupled and highly coherent.

Context

This is a project that is deployed to Google Cloud Platform.

Specifically Google App Engine. But this project layout works equally well for command line only tools and stand along desktop apps so far.

Each package is a specific domain or feature. Do not get caught up on the the term "domain", there is some "domain driven design" ideas but none of the dogma associated with it.

Specifically having a models package that has all the models in it. I started trying to do that and it was just a tightly coupled incoherent mess to navigate around, even in the awesome Goland IDE from Jetbrains.

So I inverted that idea and put all the code supporting a specific type(s) together like you would do in most functional languages and this worked very well.

The filenames are semantically descriptive and should be self explanatory to anyone that checks out the code base for the first time. They should be able to intuitively find what they are interested in very quickly without a lot of searching.

For a particular domain/feature/functionality package the files that are most common are going to be. They are detailed after the example tree.

├── account
│   ├── functions.go
│   ├── handlers.go
│   ├── tasks.go
│   └── types.go
├── cuid2
│   └── cuid2.go
├── gcp
│   ├── auth
│   │   ├── functions.go
│   │   ├── handlers.go
│   │   ├── middleware.go
│   │   ├── tasks.go
│   │   └── types.go
│   └── secrets
│   ├── functions.go
│   └── types.go
├── go.mod
├── go.sum
├── main.go
├── server
│   ├── functions.go
│   ├── middleware.go
│   ├── must_functions.go
│   └── types.go
├── timestamp
│   ├── functions.go
│   ├── functions_test.go
│   ├── types.go
│   └── types_test.go
└── youtube_service
 ├── errors.go
 ├── datastore.go
 ├── functions.go
 ├── handlers.go
 ├── secrets.go
 ├── service.go
 ├── tasks.go
 └── types.go
└── stripe_service
 ├── errors.go
 ├── datastore.go
 ├── functions.go
 ├── handlers.go
 ├── secrets.go
 ├── service.go
 ├── tasks.go
 └── types.go

Files that will be in most every package:

types.go

This file contains all the types for the package, both exported and non-exported.

For most packages both interfaces and structs and any struct receiver functions are all in the types.go file.

In rare cases the types.go file may need to be split up into an interfaces.go and a structs.go just because the number of interfaces and structs ends up becoming cumbersome. This should make you take pause of your package and see if it is overly generalized, or the types are too granular, or that you are just doing it wrong.

I have a well rounded background in functional and imperative programming languages and I find that I use receiver functions very sparingly in Go. If your types look like Java classes then you are doing it wrong.

My types in Go usually only have interfaces that make sense on the type, like Stringer or Marshal/UnmarshalJson or Marshal/UnmarshalBinary and Marshal/UnmarshalText

Instead of putting a AsTime() time.Time receiver function on my custom Timestamp type, I would rather have it a stand along func AsTime(ts Timestamp) time.Time function. It makes my Timestamp type loosely coupled to the time.Time type and still maintains high cohesion/locality. It also limits interface explosion. You can also pass the function into other functions if you need a different implementation for some reason as long as the signature is func(ts Timestamp) time.Time.

functions.go

This file contains all the functions for the package, both exported and non-exported.

These are functions that are actually functions, not receiver functions, those should be in the same file as the struct they are on for high cohesion.

Exceptions:

There are always exceptions!

For the cuid2 package there is only one type and a handful of functions, so I just put them all in a single file with the same name of the package. This indicates that everything is self contained in this single file. If that file should grow to be more complicated or unwieldy from size it would then be refactored into types.go and functions.go at the minimum.

This is in service to the high cohesion principle. If everything can easily be in a single file, then it should be.

You will also notice there are no packages or files with names like util or common.go or helper, those names might as well just be djjsdfiyhfye, they are actually worse; they do not convey anymore more useful information than line noise, but since they are words you infer what they mean without actually knowing what the intent was. They are misinformation at best, where as random characters would at least tell you immediately that those files were suspect and obfuscations at best.

Web Applications / APIs

app

The app package is a horizontal cross cutting package that should not import any of the application specific packages but be imported by many of them to access high level application specific functionality. This would commonly be named utils or common or some other lazy unimaginative and non-descriptive name.

server

When I am working on web service and it gets even the least bit complex, I introduce a server package and put the server implementation in that package. I usually use gin so this is where the gin instance(s) get initialized and configured instead of in main.go.

must_functions.go

This file is functions that must not fail, and will stop the server if they do. In most cases these are functions that are either critical to the server and errors are unrecoverable, or they are wrappers around things in functions.go that are processing known good data that if an error does occur it is because of major data corruption and should stop the server.

Things like must_parse_time(s string) time.Time where you know the format of the string is valid because it came from a know source or has been previously validated in the code path.

I put functions that do not return errors and that panic or os.exit in this file. This makes it extremely clear that these functions will stop your application if they encounter errors of any kind.

handlers.go

This is where exported API handler functions would be found, and any non-exported support functions that might be specific to these handlers.

middleware.go

This is handlers that are middleware that support the package they are in. Server wide middleware would be in the server package. authentication middleware would be in the authentication package. You get the idea, loosely coupled and highly coherent.

???_service.go

This particular project access the YouTube Data API V3 so there is a youtube package. The service.go file contains all the functions to actually make the calls to the youtube API. These could be stand alone functions or a struct with receiver functions that implemented the calls so they could share construction and pooling of an API specific client object and its creation.

It also uses stripe so there is a stripe_service package, naming them XXX_service.go tells you what they do an removes import collisions inside the package when the service package name would conflict without the _service suffix. There are other naming conventions you could use, just be consistent.

secrets.go

This file contains package specific functions and types to access the Google Cloud Secrets Manager API calls that are in server/secrets.go. That file contains general abstractions over the secret manager client and calls, like creating a secret, adding a version and enabling it and disabling/deleted previous versions all in one transaction.

datastore.go

This project stores data in the Google Cloud Datastore. This could be called repository.go, and it was, I decided that was to generalized and did not convey enough semantics. datastore.go tells you it is a datastore implementation in the context that this is a Google Cloud Platform application.

If I was going to support multiple storage implementations I would put that interface into repository.go and the specific stores in datastore.go, postgres.go, redis.go, etc.

tasks.go

This file contains the functions to create Google Cloud Tasks submissions. If they take specific structs that are only used in the task functions to create the tasks, then I make then non-exported and put them in the tasks.go file, if they are used elsewhere I put them in types.go. Cohesion over rote consistency.

errors.go

I am experimenting with custom error structs in the on package in this project, that is what this file contains, the error types and the functions to create new instances.

I have toyed with making this a sub-package, but since Go does not support sub-package namespaces (pet peeve of mine) and flatter packages are idiomatic Go, I am doing it this way for right now. This is an experiment, it may change depending on how successful it is.

gcp/auth gcp/secrets

I am still debating these nested packages. This is a Google Cloud Project application and these packages contain Google Cloud Project specific authentication and secrets manager code.

I initially put all the code just under gcp package, but mixing the authentication functions and types with the secrets manager functions and types go messy very quickly. Tightly coupling the disparate features to each other in location if nothing else. And weakening cohesion at the same time, because it was hard to see what was related and unrelated with both features mixed in the same types.go and functions.go files.

I am satisfied with this right now, but still not completely. Putting an auth and secret package in the root of the project would lose the information that the outer gcp package conveys semantically, so it stays until I have a better solution. There may not be one.

There is no one correct project layout:

There are ones that are more correct and this is the most semantically rich, intuitive and idiomatic one I have seen anyone come up with so far.

• It is adaptable but consistent and predictable.

• It is simple but scales out to more complex cases when needed.

• It is minimal without being terse and expressive without being verbose.

• It is opinionated without being dogmatic.

This took me to long to figure this out

After almost two decades of doing technical interviews I have been able to distill a technical interview down to just two questions. And my "technical" interviews, I mean, does someone really know the subject they claim to know and how well they actually know the subject. I can end an interview with someone that claims to be an "expert" quicker than someone that claims "intermediate/competent" or "beginner".

This is the hardest question you can ever ask someone.

What do you like most about [insert technical skill here]?

The only wrong answer to this question are non-answers. Answers that do not directly specifically answer the question with an opinion are non-answers. These are answers that do not offer an opinion because they apply to anything.

Here are some examples of non-answers:

• "I like everything about ..."

• "I like it because it is popular/easy to find work in/etc"

• "I like it because it is easy to use"

These types of answers are immediately disqualifying. But just to to make sure they are not just being shy or evasive because they do not want to come across argumentative or insult something that I might not agree with I prompt them for something specific.

Like "Why do you think it is easy to use", "Why do you think it is popular", at least those answers give you something to follow up on and see if they are just bad at giving opinions and expressing themselves and actually have a opinion in there somewhere.

Granted, you can have too much of a "weak personality", just as you can have too much of a "strong personality". That is not about technical interview stuff, that is more about, person than what the person knows or does not know about something.

If I still get a non-answer, after some leading follow up chances I move on to the next question, which should be guaranteed to draw out an answer for everyone. And like they Daily Double on Jeopardy gives them a chance to dig themselves out of the hole they have dug.

This is the most softball question you can ask someone.

What do you like least about [insert technical skill here]?

A strong answer here can rescue the interviewee from a non-answer from the first question. And give them another chance to revisit the first question in the context of this answer.

Now everyone has something they hate about everything, especially things they are extremely knowledgeable about, even beginners have stuff they hate. Every Java programmer hates the original Date class, regardless of their experience level. Same with the boilerplate verbosity. Every new Go programmer starts off hating error handling in Go. Even most intermediate and a few experts hate on it, even though they understand it and realize it is a reaction to try/catch and is a better solution.

Ask a couple about what they like/love about their partner and you will get some generic stuff or one or two specific things. Ask them what drives them bonkers and they hate about their partner and you will get an "ok you can stop at any time list". And the longer the relationship the love/like list does not change in length, but the hate list will have grown.

A non-answer here is pretty much "That's it man, Game over man, game over." I am going to wrap up the interview as quickly and politely as possible.

What the answers mean.

Here is how to score the answers. You are looking for opinions, the more experienced they are the stronger their opinion needs to be, and the better they should be able to articulate why your opinion is what it is.

Whether you are agree or disagree and to what extent is irrelevant at this point. On a scale of 1 to 10, with a non-answer being a 0 and a really passionate opinion with a well thought out and reasoned argument supporting that opinion, even if you think they are absolutely wrong, should score a 10.

I weight the "like/love" question higher than the "dislike/hate" question. Simply because negative feedback is always easier to solicit than positive feedback. The reason this is such a powerful and effective approach to technical interviews is it gets you to the "I know enough that I do not need to know anymore" point very quickly.

It gives you a platform to get some back and forth engagement with the other person and see how they think and why they think what they think. It is easier to dig into someone that you disagree with their opinion than when you agree, so even if you agree with their opinion on what they like/dislike and why, you should still take the contrary side and play the part of someone that disagrees with them.

This gives you detailed insight to their thought processes, but it also gives you some insight into their personality; how someone argues tells you a lot about how they will fit into the team. You want experts that can argue persuasively and effectively, you need them to help drive growth in the less experienced members of the team as well as use them to convince peers and higher ups why what they want you to do is not the way something needs to be done.

Even if someone is not a very senior expert personal technically, if they have opinions that means they are learning and if they can argue effectively and persuasively they are way more valuable than someone who is an expert level but is ineffective a arguing their position, or worse someone who can win an argument but lose the respect of everyone in the discussion in doing so.

If you do not believe me

The brilliant thing about this approach is, it does not matter if you are an expert in the technical subject, you can find out if the other person is just by their answers.

Call up a friend, tell them you want to practice some new interviewing approach, but do NOT tell them what it is. Ask, them to self assess if they are an "expert", "intermediate" or "beginner" in the subject. This is like question zero, usually resumes will tell you what the person thinks their skill level is, or it is implied by "years of experience", which is a false measure, but that is an entirely another article.

Then ask them these two questions I detailed above in order. The order is important, just like I presented them.

The "Like" question and then the "Dislike" question.

If they give you non-answers, that is ok, it gives you a chance to practice the follow up, redirect approach questions I mention.

You can get to what someone actually knows or does not know with these two simple questions and some trivial follow up conversation.

Name your Interface what it is. Truck. Not ITruck because it isn't an ITruck it is a Truck.

An Interface in Java is a Type. Then you have DumpTruck, TransferTruck, WreckerTruck, CementTruck, etc that implements Truck.

When you are using the Interface in place of a sub-class you just cast it to Truck. As in List<Truck>. Putting I in front is just crappy hungarian style notation tautology that adds nothing but more stuff to type to your code.

All modern Java IDE's mark Interfaces and Implementations and what not without this silly notation. Don't call it TruckClass that is tautology just as bad as the IInterface tautology.

If it is an implementation it is a class. The only real exception to this rule, and there are always exceptions, could be something like AbstractTruck. Since only the sub-classes will ever see this and you should never cast to an Abstract class it does add some information that the class is abstract and to how it should be used. You could still come up with a better name than AbstractTruck and use BaseTruck or DefaultTruck instead since the abstract is in the definition. But since Abstract classes should never be part of any public facing interface I believe it is an acceptable exception to the rule. Making the constructors protected goes a long way to crossing this divide.

And the Impl suffix is just more noise as well. More tautology. Anything that isn't an interface is an implementation, even abstract classes which are partial implementations. Are you going to put that silly Impl suffix on every name of every Class?

The Interface is a contract on what the public methods and properties have to support, it is also Type information as well. Everything that implements Truck is a Type of Truck.

Look to the Java standard library itself. Do you see IList, ArrayListImpl, LinkedListImpl? No, you see List and ArrayList, and LinkedList. Here is a nice article about this exact question. Any of these silly prefix/suffix naming conventions all violate the DRY principle as well.

Also, if you find yourself adding DTO, JDO, BEAN or other silly repetitive suffixes to objects then they probably belong in a package instead of all those suffixes. Properly packaged namespaces are self documenting and reduce all the useless redundant information in these really poorly conceived proprietary naming schemes that most places don't even internally adhere to in a consistent manner.

If all you can come up with to make your Class name unique is suffixing it with Impl, then you need to rethink having an Interface at all. So when you have a situation where you have an Interface and a single Implementation that is not uniquely specialized from the Interface you probably don't need the Interface in most cases.

Many of these "Patterns" are even considered anti-patterns and poor design choices in every language (Singleton), but you insist on flexing your new found Go knowledge less than 20 hours after writing your first hello world by posting about "Patterns in Go - Singleton" and embarrassing yourself.

1. Almost every one of these “patterns” are not idiomatic for Go.

2. They are not even Object Oriented Patterns, but people keep posting them as they are.

3. And even if they were, as it is very easy to discover, Go is not an Object Oriented language; or is it?

What is Object Oriented then?

The language decisions that were made when the Go syntax was created were a direct reaction to the the wasteful verbose boilerplate of C++ (and ironically inheritance of the same things in Java ).

Object Oriented programming is actually not even about the Objects it is about message passing.

"I regret the word 'object'. It gets many people to focus on the lesser idea. The real issue is messaging. Messaging is the abstraction of the communication mechanism. It's what allows different parts of a system to interact without knowing anything about each other. That's the power of objects, and it's what makes them so useful."

— Alan Kay in an interview with Peter Seibel for Dr. Dobb's Journal in 1997.

So why are C++ and Java called “Object Oriented”?

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind

— Alan Kay, OOPSLA '97

If C++ is not what you should think about when hearing “Object Oriented” then neither is Java. Especially since Java does not have “message passing”.

"Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS." — Alan Kay in an interview with Peter Seibel for Dr. Dobb's Journal in 1997.

Guess what does? Go. Specifically goroutines, and they were inspired by Erlang processes.

Does that make Go “Object Oriented” by the creator of the term. Not by itself, but it does make it considerably more “Object Oriented” than C++ or Java.

Way more, if you consider other statements he made on the definition later. Lets look for more evidence to support my argument.

So what should C++ and Java be called? Well that is enough for another article or more, but anything else would be a way better term, given what the inventor of the term says.

I personally think “Class Type Oriented” would be semantically more appropriate considering Alan Kay focuses on the term “class” even less than “object” and C++ and Java are all about classes and type systems first and foremost.

So what does Alan Kay think defines an “Object Oriented” language in his own words?

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

— Alan Kay from an email to Stefan Ram on 2003-07-23

How would you do that in Go?

Make every struct field non-exported (starts with a lowercase letter in its name) and have nothing but exported functions that work with the hidden data. Make every function take an Interface and return nothing but struct that implements an exported Interface .

To spell it out:

• only messaging: Export only functions and Interface which is just a collection of function signatures that are public, so you are effectively passing functions or collection of functions to functions, thus messaging.

• local retention and protection and hiding of state-process: non-exported struct fields meets all these criteria outside the package level, package == local.

So what languages are “Object Oriented” as per clarifying statements by the originator of the term?

The one that I am most familiar with because I have written real world production applications with is Erlang. I learned it because it was created for real world scenarios that needed 9 “nines” uptime. I learned it because the thing I needed to create, it needed similar uptime. I am sure that other Functional languages will be mentioned in the comments, but it is the only one I have first hand experience with in a deployed commercial production environment.

As a former Java main, it is embarrassing …

Please stop pushing “Object Oriented Pattern Implementations” on Go like you are informing the ignorant and unwashed masses that have been using Go for the past 10+ years and saving them from themselves. It is embarrassing, I say that as a former Java main myself.

What you are pushing is not even “Object Oriented” it is a perversion of it to the point that it is not even recognizable.

It is especially embarrassing when your implementation does not even begin to use Go idioms and ignores go specific things that were implemented specifically to do the thing you think you are being “informative” about.

What triggered the compulsion to post this article.

Let us take the most beloved Gang of Four Pattern of all time. Especially to the Java faithful. The one most people have their first epiphany with when introduced to “Patterns Of Reusable Design”; probably because it is the easiest to comprehend. Singleton.

Just to make sure my point is not misinterpreted this is not about Singleton!

My point is about the articles that are nothing more than terrible ideas in Java ported to Go syntax.

For this example:

Let us ignore the fact that it was a terrible anti-pattern when it was first documented, because it is by definition global state and the #1 goto Java pattern. “Singleton Considered Harmful” has been a thing for decades. See what I did there; goto, singleton …

Let us also ignore the fact that in the JVM you can not even implement Singleton correctly because by design the JVM can not guarantee that one and only one instance of a class is ever created. Here is a hint to the all the self professed Java experts that are about to write a comment about how I am wrong; Multiple Classloaders.

If you see someone post “Patterns in Go - Singleton” first look at the implementation they post; if you do not see sync.Once() anywhere in the code.

That is what you should call them out on, their promotion of misinformation. The hubris in posting a “teaching” article about something they barely know the basics on. That is a malicious disservice to those that know even less than they do.

The rest of the internet has already proven all the other points, that is why I prefaced this with “Let us ignore …” caveats.

I tried to research everything in this article for factual accuracy, but I am sure the internet will tell me what their opinion about it is. If there are any factual inaccuracies, and you want to point them out in the comments, provide the source and I will correct them. Otherwise, do not waste everyone else’s time. If it is important enough to correct, it is important enough to site sources like I did for the quotes and technical specs.

I would pedantically always used the collection type that was most appropriate semantically correct for the data it was collecting. If I was storing a list that only contained unique items, I would always use a Set, usually a TreeSet so I would get insert order iteration. Same for non-unique item collections, I would use a List instead. This had the advantage of documenting intention to anyone reading the code months later, usually me, so they would get that extra bit of context and information about what and why the data was being used.

When I became a Go main

I chafed at not having all these distinctly semantically rich type safe collections. I chafed at not having type safe collections; I went Go main well before Generics were added.

I searched for the reasoning behind the omission of the set type as a built in. I mean if you look at the Set implementation in Java, it is Map all the way down just like the recommended way of doing it Go.

Except, it "looks ugly" to have to "repeat yourself" to "twist a map into a set" in Go. I searched for Set implementations, I never found one that really resonated with me and Go.

All of them were not very "Goish". They were either copies of the Java Set interface, or littered with receiver methods for all the different set operations, which in Go should be normal functions that just take two sets and do the operation on them.

I will not even get into all the Java/C++ iterator implementations that are so rejected by the Go community and for good reason.

So I build my own

I did what every self respecting, at least until they have done this, programmer does, I wrote a set implementation that I thought was the most idiomatic Go way of doing a set.

Then, I never actually used it

That is not entirely true but it is accurate. I did use it, just like I "used" all the ones I found on github.com, and I ripped them all out shortly after I put them in.

I mean, I used my implementation, until I ripped it out as well. I found that I did not really need to enforce uniqueness in a list of things, often enough to warrant having to look up how this thing worked the few times I used it.

I work with unique lists of things all the time, I just do not need to pedantically enforce the uniqueness at creation and modification, because I found out I really never modified them after creation.

I created them once and just referred to them many times. Think enums and looking them up by string. These cases end up being both rare enough and similar enough to in a common way to just create a "Live Template" in GoLand to generate the boilerplate for their creation on a keystroke.

No "AI" generation required. If I am actually needing to process some data dynamically where uniqueness needs to be guaranteed as the data is added to a container, it is going to have space and or time requirements for me to use some numerical library that does this for me anyway.

It took a few years to finally come to this realization

I did not really come to this realization that quickly. It took a few years and thousands of lines of Go and dozens of applications, servers, cli, desktop, etc, for this to reach this epiphany.

I still want a proper set type in Go.

But, I do not want it as a module you import. Not for silly reasons about "too many dependencies". It is about it being a "first class citizen" as a Go built in just like slice, map and channel. The syntax I want is:

s := make(set[string],0,7)
s = append(s, \"Sunday\")
// you get the idea
s = append(s, \"Saturday\")

I intentionally picked acomparabletype so I can ignore that issue entirely. But,setwithout support forstructs that do not conform tocomparableis pretty useless.

What I wanted was a native solution

I want a slice that has enforced uniqueness, I do not want a map[string]interface{}, even if I get more functionality out of the map by being able to associate a value (abbreviation, or whatever) with the unique day of the week name.

It is illogical, but I really like the semantic of a unique array or slice being just that, not "keys in a map".

Pedantic reason, I am Autistic, I own it.

I was digging through the Go compiler source map.go

If you look at makemap, makeslice and makechan and it would be fairly easy to add makeset and update the parser to support a native set type that is actually a slice and support setsorted.

I am not sure it is worth the effort, especially since the non-trivial comparable issue needs to be solved. I will probably try to add it just as an exercise to get to know the Go runtime source better. I assumed until I saw the source that make() was some native code or something embedded into the runtime, but it is just plain Go code.

Stop with the "Stop using Else" and other nonsense!

This is a very concrete example of advice that is at best ignorance and at worse malicious misinformation.

If you google "stop using else" you will get pages and pages of articles written mostly by people that only have passing experience in a single language, usually JavaScript, and have never had to maintain a program with total lines of code greater than 10K, espousing this nonsense as if it was a revelation of some new gospel.

Its not, it is an ancient screed from the Cult of the Lines of Code Gospel or the Followers of the Optional Braces disciples repeat these mantras and have no experience with what they are saying in the larger picture.

Explicit Is Better Than Implicit!

This is from PEP 20 - The Zen of Python but it applies to all higher level languages and is knowledge that was learned from working with previous languages that were dominated by the "Cult of the Lines of Code" acolytes, this cult still preaches such things as the First 80 Columns are the only holy columns fallacy in 2022 as well.

This statement should be self explanatory and non-controversial. Program code that is explicit is unambiguous in its intent on what its behavior is expected to be.

That is not to say that its behavior is correct, it is just that it is not a mystery what the desired output of any input is expected to be. Executable Code should be the definitive source of logic, and comments are not executable even if they are semantically code.

Else is explicit, its absence is intentional obfuscation!

The same cult that is espousing this nonsense now is the same cult that exposed the nonsense of leaving off {} from if statements and for the exact same reasons.

The most popular ones are, "they are not needed", "they increase lines of code or keypresses", "they are more to read", etc. All of them are backed by logical fallacies as why they are correct.

Leaving off an else statement never adds any information, it removes information about what the code is intended to do. Anything that removes information in this case is harmful.

Some languages are harmed more than others!

Leaving off the else block in languages like Python are even more harmful than the languages most of these authors are using to justify their ideology. Go and JavaScript I am looking at you.

The lack of block characters, or leaving off block characters (which is worse), makes these types of logic bombs even harder to reason about when they explode and you can not see where the issue is just looking at the code. Especially, when they cause intermittent bugs because the bad logic only triggers occasionally based on some state machine that is not defined and impossible to reason about when the application is running much when you are looking at the source.

Garbage In/Garbage Out

This stop using ??? advice is primarily predicated on bad advice that the reader does not comprehend as bad advice because of lack of comprehension from lack of experience.

These same people will mindlessly espouse concepts like DRY and SOLID, avoid side-effects and completely ignore that this advice introduces implicit logic solely based on side effects.

The reasoning in this case is basically some form of "else is just fluff and adds nothing useful" and then follows with "you should code theif clause and return inside it and then do whatever the else is without the else statement and return there". There is a Luke Skywalker quote from a terrible movie that applies to this but I will not subject you to here.

This is terrible practice and it immediately introduces an impossible to detect bug into the logic of the code. Maybe not one that causes incorrect output immediately, but one that can the very first time someone adds any code outside that initial if block.

All logic is special case!

The misinformation is that the if statement is a special case in some way and that the else is the default/non-special case and does not need special treatment or demarcation.

The fact that you can transpose this specialness just by changing the initial if to if not tells you this is a flawed reasoning.

if not somethingSpecial:
    doSomethingElseNotSpecial()
doSomethingSpecial()

_{Note that there is something even more fundamentally wrong with one of these pseudo-code logic above other than the missing} else _{but that is another religious argument where the zealots are wrong as well.}

Not Just One Billion Dollar Mistake!

null has been called a Billion Dollar Mistake by its creator. It is arguable that he was off by at least an order of magnitude initially, multiple orders by 2022 standards.

It was just one of many terrible ideas that language creators implement because most of them were not trained in formal logic or even trained in writing computer languages or they are trying to design for flexibility in the future.

Necessity is the Mother

Many popular programming languages were created out of some need as a tool as a means to a very specific end, until C. C was created to be a general purpose language, and as such includes a kitchen sink of bad ideas that are only obvious in hind sight, sometimes even with 50 years of hindsight they are still obvious to some people.

One of the most subtle bugs in C is the one line if statement, that leaves off the {}. If someone comes along and just adds another line of code below the initial line in the if statement, what were their intentions?

Usually their intention was to add that line to the if statement, but that is not what happens. It is just executed regardless, which introduces can be an extremely subtle bug that can decimate data in an very quiet way that may not become apparent for hours, days, weeks or even months later.

Leaving off the else introduces the same class of bug, if not always the same level of subtly.

Languages like Go that are planned and designed for a reason just as a reaction to some problem leave a lot of these organic mistakes behind.

Unfortunately Go has as many opinion based mistakes baked into them to replace the mistakes they avoided. Which personally I think is worse, because these mistakes are based on intention instead of accident. They become dogma immediately, no matter how bad they reveal themselves to be.

This dogma becomes a defining aspect of the language that drives away adoption because it is expected to be adopted by everyone; regardless of how bad an idea it actually ends up being, instead of cautionary tale features that are accepted as being avoided.

_{NOTE: I do not hate Go, I have moved to using Go over all the previous languages I usually reached for before I learned Go. Go is a great compromise that can completely replace Java and Python at the same time. Instant compiles of even huge programs means it can be used for rapid development scripting type tasks, cross platform single executables with robust libraries and frameworks ticks the Java boxes. It is great, but not perfect.}

New ideas are not always new or correct!

One of the most offending languages right now to this is Go. There is a preponderance of effort into pushing the idea that else is not needed, and if it is your code is not structured enough or some other hand wavy non-sense that is your failing and not the failing that it is a terrible practice.

Another, idiom of Go is the normalization of negative Boolean checks in if statements.

This is the idiom in Go, and it is terrible for many reasons.

First off, the general and correct consensus is that the initial if statement should be not be testing for a negative because it forces more processing on the organic computer that is parsing and interpreting the intent of the logic.

Who in their right mind would let the following type of code construct into an application that was used for anything non-trivial?

if x != true && y != false && z == true {
    // do something for some reason
}

Yet, I have seen thousands of lines of such checks in 20+ year old Java code that the original author insisted was "best practices" 20+ years later. Lucky for me that IntelliJ idea was able to automatically convert them all to something easier to reason about using structural search and replace.

We still had to reason about the multiple checks and normalize that, but it did save time and make writing tests for this code possible.

The Go idiom is not exactly the same, but is in the same class of obfuscated logic for the sake of brevity, even if you consider it less harmful than the Java example. Less harmful is not harmless.

Religious Arguments Codified As Idioms are Dogma

Go codifies the "multiple return" religious argument dogma by making it an idiom. It does not solve the argument, it justifies it as "everyone says so", which is just a logical fallacy.

It does this, by making this the idiom in all the official Go source code.

This also has the side effect of justifying that else is never needed and thus it is idiomatic as well to always leave it out.

Leading many people to twist otherwise clear logic in obfuscated knots and write spaghetti code to be able to leave it out.

This Page Left Intentionally Blank

Documents that had important information that needed to be unambiguous in their facts and intention always have blank pages that say THIS PAGE LEFT INTENTIONALLY BLANK, on them in huge block letters. That way no one would wonder if that blank page was supposed to be blank and missing information? Was it a printing error? Is there missing information that could be a cause a serious error? No one would argue these semantic place holders were redundant or not important in the explicit context that they provide.

The else in the if/else symmetry serves this same semantic function. It says explicitly, THIS AND ONLY THIS is what is supposed to happen if the other thing is not true and leave no ambiguity.

It says, if you want something to happen if that special case is not true put it here. If you want something to happen regardless of that space put it outside here.

// something that might return an error
if err != nil {
    return err, nil
}

// something ELSE or something unrelated to the previous if we 
// have to look and parse to know that might return an error
if err != nil {
    return err, nil
}

return nil, somethingNotNil

is what most would consider idiomatic the following is not wrong but is preferable because of it is explicit and unambiguous to the expected behavior

if err != nil {
    return err, nil
} else {
    return nil, somethingNotNil
}

the needlessly laconic idiom version saves an entire 7 characters, but is introduces the possibility of endless subtle bugs as unattended side effects, incorrect logic and just bad output.

Thankfully, even this idiomatic structure is being challenge by the new/late comers to Go, but in an early enough stage and by enough seasoned developers that it can hopefully be corrected as harmful dogma from early zealots.

The fact that if err != nil is well considered to be just copy paste boilerplate with dozens of macros, libraries, frameworks, and code generator solutions to this should tell you it was never a good idea.

Ignore advice that makes the world worse!

It is very simple:

If the advice in any way makes your code less explicit, introduces any kind of possibly ambiguousness or obfuscation to the intent of the logic expressed as code, then ignore that advice.

This should tell you that all these stop using else articles just as bad for the industry as the same arguments espoused on Usenet in the 1980s promoting omitting optional braces in C for the same incorrect reasons.

The truth hurts!

The amount of insult you are feeling is inversely proportionally to how much you know that you they are probably correct, at least more correct than wrong. You might not even know why they are correct, but you know it hit a nerve and you are angry.

Experience taught me this!

I originally went to study art after high school, commercial art to be specific. Apple introduced the laser writer the end of my freshman year, and I saw the writing on the wall. Let the #ageism comments begin.

The hardest part of commercial art, mechanicals, had just been completely commoditized and I added a video production/animation major as insurance. Which was a good idea, I was right about commercial art salaries cratering, video took another couple decades.

But, how did I end up writing software professionally for almost 40 years.

I wrote my own 3D animation modeling and rendering and machine control automation software as a means to an ends. Long story short, I realized I like working with machines more than people.

Why is all this relevant?

Well the first thing they teach you in art school is how to give and take criticism. Both constructive and non-constructive. It is crucial to your growth as an artist and growing your career.

Everyone has an opinion about art, and you have to learn to consider all of them. So you can separate the constructive from the non-constructive.

Even the ones that insult you the most, especially those. Understanding why they insult you the most is very important to your growth as a person if nothing else.

More importantly you have to learn how to give constructive criticism.

Anyone can yell "you are wrong" to the void. Those with experience can tell someone they need to change and back it up with logic and reason without resorting to Begging the Claim and other logical fallacies or ad hominem attacks.

There are four types of criticism.

There are four types of criticism and you need to learn how to tell the difference between them. Because, only two of the types are worth your time considering.

There is positive and negative criticism, and there is constructive and non-constructive. Thus you can have four distinct types.

Which types do you consider and which do you ignore?

Constructive criticism should always be considered, both positive and negative. Non-constructive criticism, which is the majority of what you will get from random anonymous internet is easy to disregard, but can be hard to ignore. Especially about things that are empirical and not just opinion based.

How do you tell the difference.

Constructive criticism does not just tell you that it agrees or disagrees with you, but why and gives an alternatives to whatever is being criticized in a measured informed manner that sticks to the topic and is not littered with logical fallacies.

This is the big differentiating factor.

If someone agrees or disagrees with you and their reasoning is based on one or more logical fallacies then you should realize very quickly it is a waste of your time and ignore it and move on.

But with publishing on the internet, it gets really hard to just ignore misinformation, especially misinformation that can make your peers make mistakes and by extension make your life harder and your chosen career worse.

I think we all have a responsibility to correct or at least call out misinformation that makes the internet worse.

Critical thinking, Debate, and formal Logic is no longer taught to the general public.

Public schools used to have debate clubs. Teachers used to teach how to learn, how to think about things objectively and logically and identify logical fallacies. Not only in others debates or reasoning but in your own.

I think that is why the Dunning/Kruger Effect seems to be on the rise.

It was always there, but putting a name on it and how to identify it formally makes you more cognizant of it.

Now they just teach how to take and pass tests. DotCom bubble certification farms proved that is worse than worthless to our industry.

I did my own research!

The massive audience and scope of the internet has made a lot of the problems with people that do not have these skills much worse.

The populist idea that everyone has an equal weight opinions about subjects that require formal study, are extremely complex, and nuanced or require years if not decades of experience in them to understand, much less master is a huge problem.

Doing "your own research" usually means, "I read a few things on the internet that confirm what I am already thinking", confirmation bias is extremely seductive.

So, this is a criticism of criticism, which kind is it?

If you made it this far, then I hope I made it Constructive, if your receive it as positive or negative, is probably up to confirmation bias more than anything else. So this is my attempt at a solution

So before you leave a comment

Re-read this entire article for comprehension, then write your comment, but before you publish it. Delete it. Then re-read this entire article again, write your comment. Delete it. Re-read this, and then consider if you really have something to unique to contribute that has not already been said. Re-read this article.

You get the idea, when and if your comment becomes constructive, publish it. If it isn't constructive and just a salad of logical fallacies with populist dressing, you are not making the internet (and the world) a better place.