I am not in LinkedIn anymore💔

Early years of my career, I was interested in writing articles, doing streams. But now everyone will use LLM instead of searching and learning something. LLM is developing reduced attention span among engineers as like TikTok, Instagram does. Hope everything should be ok🫠

And I do not have any ideas what about to write

Using primitive types is shooting yourself in the foot. One missing check and you will loose your all logic🤧🤧🤧

Even with Haskell or Rust's strong type system, you will end up with dynamic language (JS or PHP) like result.

So, parse, do not validate guys

For example:

package users

type Repo interface {
    GetByID(context.Context, int, int, int) (User, error)
}

Can you predict which argument is used as id of the user? Or what for responsible another arguments?

In Go's idiom, there are usual two ways:

– using a struct to pass these arguments. But there is a problem. How do you require to fill all fields of struct? Will you return runtime error? So you will end up production failure in your services.
– using named arguments. Kind of works, but you will not read always any documentation or function definition, so messing up with this also easy.

So, let's add third way to our idiom:

// types package
package types

// phantom types
type (
    User struct{}
    Customer struct{}
)

type constraint interface {
     User | Customer
}

type ID [T constraint] int64
type Offset [T constraint] int64
type Limit [T constraint] int64


// users package
package users

type Repo interface {
    GetByID(context.Context, types.ID[types.User], types.Offset[types.User], types.Limit[types.User]) (User, error)
}

In the last solution, a caller can not misuse any arguments, they will get compile time error whenever they changed order of the arguments. But there is a trick again thanks to Go's explicit type casting😐. You just easily convert types.ID into types.Offset because of their underlying data types. For this, one can use a struct instead of int64 as underlying type. But it will be so overcomplicated.

When external service is not working and you finally can see your memory leaks in your code

You are suffering from colors without knowing them at all

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Which Megamind did this first time?) I never thought about this kind of attack🤷‍♂️

https://en.wikipedia.org/wiki/Timing_attack

The modern software engineering team

Being smart is hard
Being not smart is also hard
Picking one of them also hard

So just be yourself and do not let AI to choose a way for you

How different languages handle the impossible states or errors?

Java/Python/PHP/C++ - throws an exception middle of the execution whenever developer wants
Go - panics like idiot everywhere or checks fucking error interface in every line of code
Haskell/Rust - if you use partial function panics and stops execution, but show warnings while compilation. If not, the compiler just not let you write impossible state

How other methods are there? Do you know?

When AI is behaving itself like your teamlead

Let’s pause here for a second, because there’s something very cool that’s easy to miss: we can control what a valid API looks like by NOT writing instances for HasLink. For example, it doesn’t make sense to create a link to something involving :<|>; for example, left :<|> right is for composing endpoints left and right into an API, but there’s no link that makes sense for left :<|> right itself. Well, if we don’t write an instance HasLink (a :<|> b), we’ll never be able to construct a link to a malformed endpoint, because toLink won’t compile! We’ve transformed the runtime error (Left "...") from our function endpointLink above, into a compile-time error. How awesome is that?!

Haskell has a mind-blowing power but we are not ready to use this power :)

Link