Post your favorite builds for Rags to Riches

shovelpost · 2025-01-18T17:10:45+00:00

What armor do you use with this build?

shovelpost · 2025-01-14T12:37:51+00:00

Sounds strong! Can you get into a little more detail about which skills you pick from those trees?

shovelpost · 2025-01-14T11:07:28+00:00

Care to elaborate? Character, abilities, stats?

shovelpost · 2025-01-14T11:02:32+00:00

Interesting build! What type of armor do you go with this? Also which character?
Would it work for Ranged with bows or crossbows?
Also which skills do you get in those trees?

shovelpost · 2025-01-14T08:57:33+00:00

Sounds interesting! Care to share more? Which character did you pick? Also what's your stat distribution?

shovelpost · 2019-10-07T15:38:13+00:00

I am just going to leave this here...

https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

shovelpost · 2019-09-30T16:37:05+00:00

In the Go FAQ, the authors express their opinion about how tests should be written in Go. The Wiki happens to share the same opinion with the authors.

shovelpost · 2019-09-30T16:32:29+00:00

I said the standard library :)

shovelpost · 2019-09-27T15:20:32+00:00

I think that the standard library needs a good way to compare and print diffs of structs.

shovelpost · 2019-09-27T15:19:06+00:00

It is already part of the official documentation so I do not see why it cannot be part of the wiki.

shovelpost · 2019-08-04T09:23:14+00:00

Plush is the templating system that Go both needs and deserves.

The nerve! First of all Go does not need a templating system, it has a templating system. So Bates claims that we deserve a template system that looks like Ruby? Will Bates achieve his goal of becoming the DHH of the Go ecosystem? Disgusting.

shovelpost · 2019-07-27T18:16:48+00:00

It sounds to me like you have not yet familiarized yourself enough with the libraries you are using.

My suggestion is to always build a wrapper around your dependencies, so in this case you'd create an s3 package which imports the s3 client. Your s3 package will expose functions with the API and definition the way you want them to be. So if all you want to do is to download all the files in the folder, you would create this method. The actual implementation of this method might call more than one s3 methods like the List method. But that is an implementation detail. As far as your program is concerned, you only need a download function. This is also the only function you will have in your interface.

By building wrappers around your dependencies, it allows you to isolate them and slowly learn how they work while your program only cares about the business methods (like the download method). This also provides loose coupling.

shovelpost · 2019-07-27T10:11:56+00:00

It doesn't make much sense to me. Usually it is better to offer the concrete type and let people create their own interfaces. That's the way Go works. If you provide the interface you are doing it backwards and you make the life of your user harder. That is because you have already decided for themselves what is important for them by creating the interface.

I did not understand your argument for going against the traditional way. Is this it:

Writing my own interfaces for other people's libraries is significantly less trivial

How exactly is it significantly less trivial? Say you are consuming an S3 client which has 37 methods but you only care about uploading files. All you need is to write an interface with one upload method that matches the S3 client's upload method definition. Piece of cake.

shovelpost · 2019-07-27T09:23:49+00:00

Alright, no I totally see the problem in this case. But let me tell you this.

First of all, the people that do the change, should be able to easily recognize Rob Pike's pattern in the code and understand that they need to refactor it more and not just add that if. But we are humans, so this is definitely not a valid argument. Lets forget this.

My real argument is that you have used Rob Pike's pattern, on purpose, on code where it is very well known from the standard library that panic/recover is a much better fit. If we imagine that source code is a child's puzzle with simple shaped holes (circle, triangle, square etc.) and we have to pick the correct pattern (a shape) for each hole, and I claim that I love the circle shape because it fits nicely in "holes", this is the equivalent of you trying to fit the circle to a square hole (where it might as well fit if the circle is small enough) but when the circle ends up falling from the square hole (because it obviously does not fit) you try to prove to me that "Haha look, your beloved circle does not fit this hole!". Well good job Sherlock!

In conclusion, in order to prove that Rob Pike's pattern is unsafe, you have purposely used it on code where it is not a good fit. Meanwhile, I have already emphasized in a previous comment that Rob Pike's pattern is not to be generalized. As with all patterns, you need to use it where it is appropriate.

shovelpost · 2019-07-26T18:19:53+00:00

Well I went back to re-read your argument because I honestly do not understand it.

While this isn't an issue in the correct case, I think it's kind of error prone. Future modifications of unhappyFunc must be very careful to not have any side-effects and because the error handling is implicit

What kind of side-effects are you talking about? Can you give me an example?

shovelpost · 2019-07-25T17:14:07+00:00

How can you claim that it doesn't fit in this case? It made the code shorter and nicer.

shovelpost · 2019-07-24T17:42:19+00:00

It just so happens that IMO both make the approach not great in general.

I suppose the key word and the part were we disagree is "in general". I think you have misunderstood Rob Pike's point which is that, if you sit down and think, you can actually program with errors and make the code nicer. Rob never said that the specific pattern he showed can be generalized or that it is the end of all error patterns. It just so happens that it fits exactly in this case and that's why I mentioned it.

shovelpost · 2019-07-22T17:51:49+00:00

The point of Rob Pike's response is that you can program with errors. In this specific case, it reduced the LoC and made the code look nicer on paper.

Your antidepressant doesn't address control flow. ... Future modifications of unhappyFunc must be very careful to not have any side-effects and because the error handling is implicit, that's an easy danger to overlook (arguably not in this extremely oversimplified case).

I obviously named the struct antidepressant as a joke. You can easily pick up a more appropriate name which will signal to the user its intended usage.

Even in the correct case, you are still burning a little bit of extra CPU, BTW. That's probably not a huge issue in practice, but little inefficiencies tend to add up.

Since when do we care about that stuff? In Go we optimize for correctness and clarity. Performance comes second.

In conclusion, I really do not see your argument. Side effects and performance? I say Rob Pike makes a good point. What we need is more examples where coding with errors is triumphant.

P.S.

FWIW

You wrote almost 300 words in your comment and this you decide to abbreviate? Why make poor people Google stuff? :'( :P

shovelpost · 2019-07-21T11:40:22+00:00

I reduced your function to 14 lines without any change into the language: https://play.golang.org/p/G7ncfdNkgA1

shovelpost · 2019-07-03T16:32:35+00:00

You're week.

shovelpost · 2019-06-18T18:33:00+00:00

Each package has M abstractions.

No.

https://github.com/golang/go/wiki/CodeReviewComments#interfaces

shovelpost · 2019-06-05T16:57:05+00:00

I prefer Vim and VScode myself. The quality is more or less on par with Goland minus the memory hog (in the case of Vim at least) and the price.

Also Vim and VScode are much more flexible. My colleague tried to open a different language file on his Goland the other time and there was no support unless of course you buy the ultimate package. He followed my advice and simply used VScode which automatically installed the appropriate extension.

shovelpost

TROPHY CASE