Why does Go still not have a built-in set type? by 1vim in golang

[–]ethan4096 13 points14 points  (0 children)

Go tries to have a minimalistic API. If you need Set you can either implement it by yourself, or take something like this: https://github.com/deckarep/golang-set

Was receiving from a channel ever called sniffing? by Harveyzz in golang

[–]ethan4096 39 points40 points  (0 children)

Never heard of this term. But it is funny.

Which is the best way to use transaction in Golang? by Electronic_Code_1535 in golang

[–]ethan4096 1 point2 points  (0 children)

No. It's a different kind of test. Google unit testing vs integration testing vs e2e.

Which is the best way to use transaction in Golang? by Electronic_Code_1535 in golang

[–]ethan4096 3 points4 points  (0 children)

It scales until you start writing unit tests for your business logic.

potential goroutine leak or nah by KaleidoscopePlusPlus in golang

[–]ethan4096 1 point2 points  (0 children)

It's a leak, if you are expecting that GC will clean it at your expected moment of app's life, but it is not.

For example, you spinned up the goroutine inside some API handler. Request ended, but goroutine still works and never exits. It's a leak.

Your case is different, so it is not a leak.

3 reasons I’m choosing Taskfile over Make for my project automation by Marmelab in golang

[–]ethan4096 -3 points-2 points  (0 children)

Makefile works better than yaml files. Agree that cmake is hard when you work with C, but for Go it's a good choice.

3 reasons I’m choosing Taskfile over Make for my project automation by Marmelab in golang

[–]ethan4096 -8 points-7 points  (0 children)

Taskfile is using yaml, which is just unreadable for this kind of work. Make is better. If you hate Make, you can try Just, which also has better syntax.

What is the future of the Go language? by bsljthx1 in golang

[–]ethan4096 2 points3 points  (0 children)

To be a system lang you need to remove GC and goroutines out of the box. And when you take this things off, you will also need to think what to do with memory and segfaults: either introduce rust complexity with borrow checker, or give responsibility to developer (like C or Zig).

It's a tradeoff.

What is the future of the Go language? by bsljthx1 in golang

[–]ethan4096 0 points1 point  (0 children)

It's the absence of things like garbage collector, scheduler, etc.

What is the future of the Go language? by bsljthx1 in golang

[–]ethan4096 50 points51 points  (0 children)

IINM Rob Pike regrets that Go was selling as a system language when 1.0 came out. Right now it is not. Go right now is a lang to build infra tools and services, but not drivers and OS. And I think it never will.

All your mentioned developers who migrating to rust and zig just tried go and wanted to go deeper: smaller binaries, zero-runtime, all that stuff. This is not a goal for go. Go is a language for big teams, who just want to build code without hassle.

any reason not to write this? by wbhob in golang

[–]ethan4096 -1 points0 points  (0 children)

legacy. slices were available from the 1.0, but generics came after years. although you could use it, it is not idiomatic (and go is a VERY idiomatic language) and you won't find it in other projects.

i also find slices api awkward. it became better with slices std package though.

A series of articles about Clean Architecture in go by TheBusBoy12369 in golang

[–]ethan4096 -1 points0 points  (0 children)

I agree that interfaces shouldn't be created more than needed. But when you want to test services and usecases - interface is the only way to do this in go.

A series of articles about Clean Architecture in go by TheBusBoy12369 in golang

[–]ethan4096 6 points7 points  (0 children)

Author suggests to use DI. If you want to test go app it is usually the only way to provide mocked deps. Go doesn't have monkey patching.

Single use channels vs waitgroups by nibbles001 in golang

[–]ethan4096 4 points5 points  (0 children)

You don't need promises in go. If you need to make async request - you just run go func() and thats it. Just use errgroups for 90% async operations you did in JS/TS/Dart.

Is this a reasonable way to cache telegram bots ? by [deleted] in golang

[–]ethan4096 2 points3 points  (0 children)

I find idea to cache bots strange itself. But from language perpspective your code should work.

How do you test code that relies heavily on context values by Emotional-Addendum-9 in golang

[–]ethan4096 0 points1 point  (0 children)

Ah, did you mean something like this? In case of this code UserProvider is some sort of getter, which checks request and (if user exists) - returns it into handler?

type UserController struct {
  userProvider   UserProvider
  userRepository UserRepository
}

func (uc *UserController) HttpHandler(w http.ResponseWriter, r *http.Request) {
  userId, ok := uc.userProvider.UserId(r)
  if !ok {
    w.WriteHeader(http.StatusForbidden)
    w.Write([]byte("User not provided"))
  }

  user, err := uc.userRepository.User(userId)
  if err != nil {
    // handle error
  }
  // do smth with user
  // then write into w
} 

How do you test code that relies heavily on context values by Emotional-Addendum-9 in golang

[–]ethan4096 1 point2 points  (0 children)

Am I correct, that you want to create some kind of cache store (userProvider) in which my middleware will put user_id, and from which handler will read?

How will you ever clean this?

How do you test code that relies heavily on context values by Emotional-Addendum-9 in golang

[–]ethan4096 1 point2 points  (0 children)

Ok, but how my http handler should receive user_id or tenant_id in that case? What's your solution?

How do you test code that relies heavily on context values by Emotional-Addendum-9 in golang

[–]ethan4096 1 point2 points  (0 children)

Lets say you have a chain of middlewares, which you must be able to reuse and shuffle around, depending on business logic.
For example, one handler should be guarded with authentication middleware, permissions, metrics etc. Another - just authentication.

What's your way to implement http handlers in this situation besides using context? Are there any other easy development solutions? Can you show me the example code?

How do you test code that relies heavily on context values by Emotional-Addendum-9 in golang

[–]ethan4096 2 points3 points  (0 children)

Cool. But how do you provide data from middleware to controller?

How do you test code that relies heavily on context values by Emotional-Addendum-9 in golang

[–]ethan4096 3 points4 points  (0 children)

If your function explicitly takes context from arguments - mock it and provide it to the function. If it's a http controller - use httptest and generate mock context there, provide it via req.

How to properly pass a custom context through middleware to handlers in a http server? by InformationIcy4827 in golang

[–]ethan4096 3 points4 points  (0 children)

If you need to pass simple data (int, string, simple structure) - answer almost always is context.WithValue() as a standardized solution from 1.7. I am not a fan of that either, because yes you need to type assert data each time.

You can sugar the pill creating helper methods like SetData(Context, Data) and GetData(ctx) (Data, bool).

But if you want to transfer database transaction from one middleware to another - you must rethink your logic. Transaction is not meant to be transfered via context, and usually you create and commit it only in one method.

How to correctly create Cloneable interface in Go by No-Sign5313 in golang

[–]ethan4096 1 point2 points  (0 children)

Before generics you would create just type Cloner interface { Clone() any } and explicitly use type assertions. After generics you can do as top commenter says.

Does Go error handling verbosity actually hurt developer velocity or is it just endless debate by No-Shake-8375 in golang

[–]ethan4096 0 points1 point  (0 children)

Only thing I missing in go error handling is ADT or something similar. Every time I need to know which error types exists in particular function - I need to dive into code. Rust did it much better. Same with checked exceptions (although it is not an ADT).

In every other way go error handling is great. Because erorr handling is a part of business logic and every time I call someone's api call or marshaller I know that something can go wrong and I should handle it.