SilverShark

It was a while ago indeed, and readability does play a big role. Also, it becomes easier to just type it out. Of course auto complete helps, but it's just easier.

We had it because we needed to compile for Windows and Linux on both 32 and 64 bit processors. So we defined all our Int32, Int64, uint32, uint64 and so on. There were a bunch of these definitions within the core header file with #ifndef and such.

The link to the -rc2 announcement is down?

Might be that I'm so used to the status quo, but I like the current way Go handles errors very much.

I do understand that there is a lot of code repetition, and many lines of code in a function will go for error handling instead. But I also feel that when we don't focus too much on happy path and do handle errors, we end up with a lot more work on it then on the happy path anyway, so the number of lines that go for error handling do correlate with the amount of effort we take there anyway.

I think in errors, a thing that might be improved is what to return on the "normal/happy path" side when there is an error. Suppose a string that returns a string and an error. If there is no error, I get some string and nil on the error. But if there is an error, I still need to return a string (an empty one, but still). If it's a struct being returned without being a pointer, then it still needs to be returns. Many feel this is a weird aspect about the language.

Yes, true. Having it built in in the compilation would be nice. Or at least having errcheck as a tool which already comes packed with Go.

Go has changed over time to include more things like this. Maybe one day this will be addressed.

Taking a short break to do something else for a few minutes is a wonderful way to stay productive and not stuck on some issue.

I remember specifically one day in university times I was stuck for almost 4 hours in a problem. I started working shortly after 8:00 and I went for lunch with some buddies, came back, and instantly knew the solution. This is how I learned how to have lunch at 9:00

Used to be that when you had a problem you would just through a Neural Network at it and called it something like Deep Learning. Not much has changed.

The stdlib I actually find quite complete. Especially for http projects. You really don't need third party libs for that for example.

The errors were super strange to me at the start, but I've come to really like it over exceptions. It is similar to old error codes, but I feel that this makes one always have to be mindful of error handling and the non happy path (thinking of large Python projects where no one cares about exceptions).

A lot of people tend to compare Go and Rust, but I feel that the languages are just too different. Rust is good for a variety of things which don't overlap with the things Go is good for.

I don't disagree with this, and honestly I would probably support just using bash like you said if I was in a team where this was suggested.

I think no matter how simple a task is there are always a few things people will eventually want to do with it:

• Reproduce it locally
• Run unit tests, integration tests, smoke tests, whatever tests
• Expand it to do more complex things or make it more dynamic
• Monitor it in tools like Datadog

If you have a whole project already written in Python, Go, Rust, Java, etc, then just writing more code in this project might be simpler, because all the tooling and methodology is already integrated. A script might not be so present for many developers who focus more on the code base, and as such out of sight out of mind sets in, and no one even knows about the script.

There is also the consideration that many people simply dislike bash since it's an odd language and many feel it's difficult to do simple things with it.

due to these reasons, although I would agree with making the script, I would also be inclined to have the script temporarily while another solution is being implemented.

I've had a look at this page. To the other days as well. I think it's really an awesome tutorial!

I would say the only thing that I feel is missing is a day about the shell. Maybe proposing a shell different then the default bash would be a bit too much, but editing it's .bashrc file would be cool. Especially on the topic of aliases for commands. This could be also an introduction to having such files in the home directory, like .vimrc.

Using git grep os one of the most practical things I do. Whether to look for definitions, usages, or getting a list or overview of endpoints on an api, I use it for all. It's ubiquitous, works everywhere.

Yes, other tools exist that give you this information in a clear way. But the practicality of grep is amazing.

This seems like a nice feature. Python has sets like this too, and it's super useful.