What kind of content is actually interesting to people?

Community
1

I’ve been thinking about @NobbZ’s post about the forum’s decline. It’s a shame because there are a lot of really smart people here that I’ve enjoyed interacting with.

What kind of content is interesting to people? I personally find it fun when somebody has a real-world problem and we can help them solve it and send a newer gopher down the right path (like get them in the mindset of benchmarking/testing). Is there anything else that might be interesting to you all?

Also - I’m piggybacking on this with something slightly interesting (to me). I somehow completely missed this announcement:

How many of you are using log/slog?

2 Likes
2

I can only speak for myself. As using Go for web development, I find few threads about this subject. And web development is not only focused on Go, but the foundation is Go.

For now I am not using slog. Just a simple text file. Tell me more…

func init_log() {
	// Open or create the log file
	log.Println("Log start...")
	var err error
	log_file, err = os.OpenFile("log.txt", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
	if err != nil {
		log.Fatal(err)
	}
	log.SetOutput(log_file)
}
1 Like
3

Real world Problems is a solid basis, but I think many of them are using LLMs or Stack Overflow to find answers.

One nice point could be to discuss proposed changes in the language or the standard library. There are some open issues and proposals which are very actively discussed in the go repository, but I find them not very approachable to interact (aside from putting some likes on good ideas) - the forum could be a nice place to discuss topics like this with a wider audience.

1 Like
4

So - structured logging is interesting for things like observability and the ability to query your logs in a machine-readable way. Right now - most log files are really important for troubleshooting issues, but they are written in a very ad-hoc way (like log.Println("Something unexpected happened")). For the “why”, read more here and here.

Structured logging is more consistent (as the name implies) and actually abstracts away some of what is written away from the developer. From the docs:

A log record consists of a time, a level, a message, and a set of key-value pairs, where the keys are strings and the values may be of any type.

So - consider this message with one key/value pair and the output:

slog.Info("Hello structured logging", "Current User", "Dean")
// Output:
// 2025/09/04 13:43:29 INFO Hello structured logging "Current User"=Dean

We are choosing what to log, but we are just passing key/value pairs and we don’t really care or know about what it’s outputting. So, for example, we can change all of our log entries to be JSON if we want to query them later in that format:

var programLevel = new(slog.LevelVar) // Info by default
h := slog.NewJSONHandler(os.Stderr, &slog.HandlerOptions{Level: programLevel})
slog.SetDefault(slog.New(h))
slog.Info("Hello structured logging", "Current User", "Dean")
// Output:
// {"time":"2025-09-04T13:46:57.539335-07:00","level":"INFO","msg":"Hello structured logging","Current User":"Dean"}

And you can write your own handlers to output whatever you want. So - main idea is make it so all logs are uniform and thus machine-readable. And make it to where developers don’t have to think about it so much.

1 Like
5

Yeah - the proposed changes to error handling was one of those issues where it was so popular on GitHub it melted my web browser every time I opened it. I agree it’s cool to discuss them on the forum but if you want your opinion to matter in the proposals it’s probably better to comment on GitHub, etc.

1 Like
6

Could this be a way to create a “performance deviation log” by measuring each path in the router?

func router() {
	start := time.Now()
	// executing the query etc...
	duration := time.Since(start)

	if duration > 200*time.Millisecond {
		slog.Warn("slow operation",
			"duration", duration,
			"path", r.URL.Path,
			"method", r.Method,
		)
	}
}
1 Like
7

Log whatever is useful to you. The point of slog is that it makes the log entries easier to parse with code.

8

Yeah - but if you make things machine-readable and queryable you might just log all operations in that context and you can then decide what is “slow” when you later are querying your logs for information later (might also be useful to know that like 99% of your requests are completing in 30ms or under for example).

But yes. The whole idea is to create structured logs so it’s not just you (a human) parsing hundreds of thousands of lines of logs to find useful information. I once was using Vim to search a 10gb non-structured log file (I inherited this API from some prior devs who didn’t understand the importance of log file rotation!) and it was… quite difficult to say the least.