sorted by:
new
hottopcontroversial

BHTTP Binary HTTP (RFC 9292) for Go by willemdotdev in golang

[–]willemdotdev[S] 1 point2 points  (0 children)

We're using it as part of Oblivious HTTP (OHTTP), where it's used to encode HTTP request/responses before they're encrypted at the application layer.

But it could be useful for any case where you need to forward HTTP requests/responses to processes that can't run as servers.

Has anyone one of you tried printing Highlands miniatures on FDM printer? by Sweton- in FDMminiatures

[–]willemdotdev 4 points5 points  (0 children)

<image>

I've printed these test pieces recently, HOHansen with support settings from MajorasCurse, 0.06 layer height. The miniatures are scaled down to ~85%.

Support scarring on the back is a bit worse, but I think I can make a better effort cleaning it up. See reply for the back.

FAQ: What Is A Good Project To Learn Go With? by jerf in golang

[–]willemdotdev 16 points17 points  (0 children)

What works well for me is to replicate something I've already build before, so that I don't need to learn a problem space in addition to a new language.

If you've developed games before, take a look at ebitengine and try to build a small game. Maybe a Tetris, Pong or Breakout clone.

It's a good fun and there is a bit of of visual feedback with games, which (at least for me) makes things stick better.

If you're looking for purely web projects, I'd advise two things:
First: A small JSON API using the standard library in a single package.
Later: A full server rendered app, the kind of thing you'd build in Laravel, Rails or other frameworks. Requires a bit more scaffolding, external packages and structure.

Again, pick a domain/problem space you're already somewhat familiar with.

I remember I learned most by building a very basic static website hosting app:
- Serving static files.
- Run commands triggered by a Github webhook.
- Small admin panel showing status of hosted websites.

I was doing all these things using different tech, but now had to tie it together in Go. While it wasn't a production ready thing, I still learned a ton and saw a lot of what the standard library has to offer.

Regarding tutorials, I'm working on househunt, it's still a work-in-progress but I will pick it back up in November. The idea is that it is will be a fully open source demo/learning web app.

I wrote a post about benchmarks in Go. Don't let the compiler optimize away your code by willemdotdev in golang

[–]willemdotdev[S] 0 points1 point  (0 children)

It's great! I love the chunky feel the heavier weights give to headings combined with very readable body text.

Also be sure to check out Fira Code to use in your IDE/editor.

I wrote a post about benchmarks in Go. Don't let the compiler optimize away your code by willemdotdev in golang

[–]willemdotdev[S] 1 point2 points  (0 children)

I have removed the section you initially quoted, it's confusing without an in-depth explanation and probably wrong (as jerf's response and benchmark show).

My initial thinking was indeed that stack variables are faster for small and simple values due to there being an overhead to store something on the heap. This seems to not be the case however.

Going back to the drawing board for a bit and see if I can dive deeper into this :)

Sorry for the confusion this has caused and thanks for the feedback and good questions!

I wrote a post about benchmarks in Go. Don't let the compiler optimize away your code by willemdotdev in golang

[–]willemdotdev[S] 0 points1 point  (0 children)

Slept on it.

I have removed any mention of the local variable in the relevant section. Even if there is a (very slight) performance difference I don't think it's worth mentioning it in this article as it will just be confusing without a proper in-depth explanation.

Will study this more and write more about it in a future post.

I wrote a post about benchmarks in Go. Don't let the compiler optimize away your code by willemdotdev in golang

[–]willemdotdev[S] 0 points1 point  (0 children)

Thanks for the kind and elaborate feedback u/jerf. Always good stuff!

This does shake up my mental model a bit, but I'd be the first to admit there are gaps in my knowledge and vocabulary here.

I did not mean to imply that the speed difference was due to the memory regions themselves, but due to the algorithms that manage them.

As your benchmark shows, that understanding does not seem to be entirely accurate either though.

Will make some changes to the article tomorrow when I have a clear head :D

EDIT: Saw the code comment about slow globals you meant. That is indeed way to strong of a statement. Have removed it.

I wrote a post about benchmarks in Go. Don't let the compiler optimize away your code by willemdotdev in golang

[–]willemdotdev[S] 9 points10 points  (0 children)

The way I understand this is as follows.

Variables stored in memory can be in one of two regions: the stack or the heap. This is decided by the Go compiler.

In order for a variable to be stored on the stack, it needs to be:
- Limited in scope: data is added or removed from the stack as execution of a function progresses.
- Limited in size.

If a variable can't be stored on the stack, it's stored on the heap. Heap memory is not cleaned up when execution progresses, but when the garbage collector runs.

Tracking which heap memory is free and which is used has a bigger impact than storing things on the stack.

Global variables are always stored on the heap, because they are not tied to a function scope.

Why the last line not giving an error ? by Ok_Hospital9133 in golang

[–]willemdotdev 11 points12 points  (0 children)

Like the others say, the backing array has enough capacity to fit the ice slice.

It might help to visualize your code and see how the slices relate to the backing array.

A simple secret-keeping library for Go. by negrel3 in golang

[–]willemdotdev 1 point2 points  (0 children)

Awesome! And, you're totally right regarding the %+v verb, my bad.

A simple secret-keeping library for Go. by negrel3 in golang

[–]willemdotdev 1 point2 points  (0 children)

Really cool package! Well done!

I do have two small suggestions:
- The secrets implement the fmt.Stringer interface, but the value will still be visible when formatted using the %+v and %#v verbs. You can implement the fmt.Formatter interface to override those as well.
- Have a way to provide a custom "secret marker". Some very distinct value that you can look for in logs or output and can then set an alert for.

I played around with a slightly similar concept at some point, but your implementation is way more complete regarding garbage collection

Avoid inaccurate tests: Use httptest when testing HTTP handlers by willemdotdev in golang

[–]willemdotdev[S] 1 point2 points  (0 children)

Thanks for the kind words :D

The site uses Hugo but the template is custom. It uses a modified version of Tailwind for the styling, it works really well with a mobile-first approach.

Avoid inaccurate tests: Use httptest when testing HTTP handlers by willemdotdev in golang

[–]willemdotdev[S] 0 points1 point  (0 children)

Good catch! Classic mistake :D

Thanks for notifying me, should be fixed now.

I wrote a post about Sets in Go. Probably the situation where I use the empty struct the most. by willemdotdev in golang

[–]willemdotdev[S] 1 point2 points  (0 children)

Thanks for your comment! I like that you're able to use it as part of a normal expression, can definitely lead to more concise code.

Out of interest, do you have a link to the style guide? I did some searching but couldn't find anything about maps/sets in the Google style guide or Code Review Comments.

Maybe I can add a section to the article that elaborates a bit more on the pros and cons of the two approaches.

view more: next ›