SilverShark @ SilverShark @programming.dev

Posts

0

Comments

10

Joined

1 yr. ago

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.

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'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.

I used to work with a guy who was a tech lead on a project. He was getting constant pressure that he app he lead simply did not work. The problem all came down to a database connection that was being used in multiple threads.

I told him what the problem was. He said, great let's make a meeting to talk about it. I wasn't allowed to solve it just yet. I made the meeting. Everyone understood. The lead told me to then make a prototype, but still not allowed to just fix it. I made the prototype. The lead said we needed a meeting to talk about it. Still not allowed to just fix it.

Meanwhile we still get pressured to make the damn app work, the lead keeps saying that none ever bothered to read documentation and that we need to sit down and talk about how we are going to to solve.

This went on for several weeks. When I was finally allowed to solve the issue (not by him), I took only one day.

I've been promoted into management for over one year now, and I've barely programmed on the job. I find it hard to keep up with the details on the application, but I still make an effort to with news, and do some programming for fun on my on.

I think it's important for manager to still be able to make small contributions to the application. The manager isn't going to own a big new feature that takes several sprints to complete, but he can still debug or solve some bugs, or make smaller changes. He should also have an overview of the code's structure, and know about the technologies used to build the project.

Indeed. The name doesn't follow the conventions of other commands in Windows/Powershell at all. And it is inconsistente too. "sudo" stands for "super user do", but in Windows the notion of super user is called administrator. This will likely also cause confusion with people googling for "sudo" and getting to *nix related pages instead.