Yet another reason to love Go: math/rand/v2

With the recent explanation of how math/rand evolved into math/rand/v2 I got reminded why I first fell in love with Go. Design decisions are not always made to match what every body else is doing, but rather what is the better decision. By some definition of better that I happen to agree with.

Go for C# developers: defer is not IDisposable

When using an IDisposable object in C# you have some pretty clear expectations on when that object is disposed. While the same thing is technically true with defer in Go, I've seen a lot of people misunderstand when exactly the deferred method is called.

Testing a periodic worker

I came across somebody that was asking about how to test their code. They had a function that would do certain work at short intervals and then some other work after a longer period of time. They provided a simplified version of the code and it looked something like this. They had coverage for the short period work (I guess functions foo and/or bar in the simplified example had some side effect they could test for.

Go for C# developers: LINQ

When I worked in C# I loved LINQ. I also probably used it more than I should have. I have recently looked into some options to bring LINQ to a Go project so let me share some observations.

TL;DR: I don't think we'll see much use of LINQ in idiomatic Go. Nor should we desire it.

Go for C# developers: Unicode strings

 There are a few gotchas with strings in Go if they contain unicode characters.

Go for C# developers: Using keywords as identifiers

It doesn't happen very often but sometimes there is a variable name that makes sense that happens to be a reserved word in the language. In C# when this happens you prefix it with "@" so you get @new as a variable name. Not quite as clean with the prefix, but clear what is going on. Go takes a different approach.

Go for C# developers: functions vs methods

I must admit that I often use the words function and method interchangeable. Probably because I was once taught that a method is a function that does not return anything. In the Go vocabulary however there is a clear difference and a nice method gotcha!

Go for C# developers: Parsing and Formatting time

Time for something that really boggled my mind in the beginning; the choice of how time formats are created in Go.

Go for C# developers: Polymorphism

One of the things I miss the most in Go is polymorphism. I must confess that the lack of polymorphism is one of those things that still annoys me sometimes.

Go for C# developers: Go is not a functional language

Last week covered a lot of ground but that articled linked last week did not cover another aspect of Go that might bite you.

Go for C# developers: 50 things you should know

Once again I can just lean back and relax as somebody else already did my work.

Go for C# developers: All your async are belong to us

Learning how to write "good" go code (in some definition of good) sometimes mean you need to unlearn old habits. This is especially true when it comes to asynchronous code if you have a C# background.

Go for C# developers: Where to define interfaces

When writing Go code the general guideline is not to create interfaces unless it is really needed. A good example would be an interface with only one concrete implementation. Now for the mind boggling part; in C# we would probably create that interface if the type needs to be faked in some test while in Go you wouldn't. Or actually you would. But in a different place...

Go for C# developers: Closures, loops and pointers

As a seasoned C# developer you should be familiar with the common pitfalls of closures where a variable in a lambda function is not always what you think it is. Go's pointers can easily introduce a similar problem even without the use of lambdas.

Go for C# developers: Go for Java developers

Ok, so I was lucky. Somebody else already covered the basics and I share the first impressions covered in this article. Since Java and C# (at least compared to Go) are pretty much the same, this is a good first read if you are in the C# world and want to explore the Go world. However there are two things I would like to point out.

Go for C# developers: Unit testing

Let’s talk about unit testing and Go. The fact that unit tests typically are placed side by side with the code (in the same package as the code under test) and how Go deals with exposing functions outside of a package leads to some interesting things.

Go for C# developers: Interfaces that are never nil

This was a funny feature I came across when i was learning Go. I was working with an API that used interfaces and was surprised that some of my code did not behave the way I expected.

Go for C# developers: the foreach is not what it seem to be

If you are learning Go you know there is no foreach nor while in Go - just for with a few different ways of setting it up. There is a nice gotcha if you are doing what you think is a foreach though.

Go for C# developers: Introduction

When I first started to learn Go a few months ago I compared a lot of things to things that was familiar to me; C#. And I decided to make a series of posts explaining some go-isms in C# (or .Net) terms as well as high-light some of the differences that are important to know about.

Go, maps and randomization

A couple of years ago it was very easy to DoS attack .Net web services as the headers were added to a dictionary. Back then the hash of the key was predictable so using a bunch of machines in azure and a few days it was possible to generate enough strings that resulted in the same hash value that you then could make a fake request with a lot of headers (a few hundred is typically enough) that caused the web server to spend 100% of CPU searching and updating the header dictionary. Since I recently started doing some work using go (aka golang) I immediately started to wonder how this worked in this language.