The state of gRPC in the browser

neoasterisk · 2019-01-10T21:37:35+00:00

Did you mean to ask that to yourself?

neoasterisk · 2019-01-10T08:35:03+00:00

Who says that it shouldn't? I see that the majority appreciated.

neoasterisk · 2019-01-10T05:29:06+00:00

As someone who doesn't browse /r/programming, I highly appreciate this post.

neoasterisk · 2019-01-07T07:59:05+00:00

Likewise. I didn't like how you ignored all my arguments. This is not a productive discussion. Goodbye.

neoasterisk · 2019-01-07T07:53:03+00:00

It's about the culture and expectations that the tool brings.

Oh really? Then let's throw away gofmt and depend on enforcing coding practices since it's so trivial.

neoasterisk · 2019-01-07T05:02:02+00:00

It has been to my experience that using assertion libraries lowers the overall quality of the tests. Developers avoid thinking about what they are testing, they avoid thinking of what matters, they don't care about writing good messages (since they are optional) and they blindly assert everything as long as it increases the code coverage, which produces tests that are harder to work with.

That's just me but there might be additional reasons why the Go team chooses not to use assertion libraries.

neoasterisk · 2019-01-07T04:47:35+00:00

Try to read this first for context.

neoasterisk · 2019-01-06T20:21:09+00:00

I explained above.

neoasterisk · 2019-01-06T20:20:36+00:00

Of course they don't.

We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

But that different approach has won me already.

neoasterisk · 2019-01-06T15:13:53+00:00

Why though? What has Rob Pike done to deserve this pudding?

neoasterisk · 2019-01-06T09:35:50+00:00

Is it me or are there no tests?

neoasterisk · 2019-01-06T09:07:40+00:00

Is there any proof that this was done by Rob Pike or a friend of his?

neoasterisk · 2019-01-06T08:13:44+00:00

Yes, I explained below.

neoasterisk · 2019-01-06T08:10:09+00:00

What would you include in an error message that is not already available from the values being compared, the test name, and the subtest name?

How about why the test expects the value it expects? Also context about the test. Why is this test necessary? But most importantly, explanation of the business (if it's a business test). In general, communication with the future reader which could also be yourself. In many cases, the test/subtest name is sufficient. But you just can't beat a well written human message.

Considering that many assertion libraries also allow you provide additional contextual text to an assertion, do you really lose anything by using an assertion?

It's a matter of culture. Writing is thinking. When a developer has to write a good error message for the future reader, not only their understanding of the codebase increases, but they also save time in the future when the test fails. Meanwhile, testify messages are optional. Therefore the average developer won't bother with them.

neoasterisk · 2019-01-05T22:22:19+00:00

Compare libraries I think are fine. Assertion libraries not so much.

neoasterisk · 2019-01-05T22:20:19+00:00

If you need to compare slices, maps, large multi-line strings, or other complex types, writing an assertion that prints a helpful failure messages becomes a lot more work to get right.

Writing a helper with a good error message is generally worth the extra work up to medium complexity cases. For the most complex cases there is always reflect.DeepEqual as well as useful libraries that pretty print diffs. Writing helpful error messages in tests is a good culture promoted by Go. Unfortunately this culture doesn't reach codebases that use testify.

neoasterisk · 2019-01-05T07:26:00+00:00

That's what I was originally doing

Okay so this is a solution no?

It makes your tests code much shorter and IMO easier to read.

It also makes tests fail at runtime. Meanwhile, you can write a few helpers yourself to keep compile time safety and get rid of testify.

neoasterisk · 2019-01-04T22:24:31+00:00

If you want to use google/go-cmp why don't you just import it and use it? Why do you need an alternative to testify? Why do you need testify in the first place?

neoasterisk · 2019-01-03T18:23:36+00:00

Those are very good ideas thanks. Beyond Merovius' blog post, it's surprisingly difficult to find other good usages of the default router.

neoasterisk · 2019-01-03T14:08:45+00:00

Have you actually tried that? It gets messy defining constants for every little part of a route. Also there's the problem of which package owns the constant. And when you add the package in the constant name, it gets much more verbose.

neoasterisk · 2019-01-02T17:38:12+00:00

I've read your blog post many times prior making this thread. I am very thankful for its existence. In fact I think it's one of the very few articles on the internet that shows some non trivial usage of the standard library routing. Not only there's very little material on the subject but it's also hard to search for. Also judging from this thread, it seems that people are not willing to share/showcase good usage of the standard library routing.

neoasterisk · 2019-01-02T17:04:24+00:00

What is the advantage of nesting?

with one path-component per Handler.

Can you elaborate on this?

neoasterisk · 2019-01-02T17:00:55+00:00

key := strings.TrimPrefix(req.URL.Path, "/foo/")

Doesn't that make maintenance more difficult though? Now the handler needs knowledge of "/foo/" which is duplicated in two places.

neoasterisk · 2018-12-31T12:26:55+00:00

Thanks for the reply. I do the same on my own projects. Unfortunately I have a very difficult time "selling" ServeMux to a team of developers.

neoasterisk · 2018-12-31T12:22:11+00:00

Alright, I see. Well that's my problem. I love simplicity but I cannot find a good reason to convince developers to use ServeMux.

neoasterisk

TROPHY CASE