The most popular Go dependency is…
https://blog.thibaut-rousseau.com/blog/the-most-popular-go-dependency-is/
| GitHub | https://github.com/Thiht |
| Blog | https://blog.thibaut-rousseau.com |
Thibaut Rousseau
@thiht
- 18 Followers
- 27 Following
- 26 Posts
Hi! I'm a French software developer, and will post mainly about #golang
@nemith @cobratbq @bklimczak Yeah I'll keep doing this. It works and has literally no drawbacks in a microservice monorepo. I wouldn't do it in a public library because it doesn't really make sense, but in a shared company codebase it works.
@nemith @cobratbq @bklimczak that’s an opinion with no great benefit. Declaring an interface on the implementer side makes sense, at least to ensure you define your own contract and don’t ever break it. Consumers can define their own interface if they want to make adapters and not rely on a specific implementation or unused methods, but saying implementers shouldn’t do it is wrong.
@gytisrepecka nowadays you can just use net/http, it works well enough :) the only thing I miss is a helper like "c.WriteJSON", but it’s easy to write your own.
Tim BrayAfter an immense amount of discussion, there’s a full proposal and implementation for a v2 JSON Go library: https://github.com/golang/go/issues/71497
I’m delighted that it stays within the bounds of I-JSON (RFC 7493) and defaults to strict RFC 3339 (i.e. ISO8601) compliance for time/date. I’m sad that there are so very many options and worried that some might combine in unpleasantly surprising ways. Kudos to the people who put the work in.
Also, faster in most cases.
Mitchell HashimotoGhostty 1.1 is now available. Over 250 closed issues from 84 contributors! See the release notes here: https://ghostty.org/docs/install/release-notes/1-1-0 Major highlights include: SSD for Linux, IME improvements, macOS Native (and Better!) Alpha Blending, many Quick Terminal improvements, much much more.
@[email protected] @[email protected] I think I would settle for `foo := fn() ? err`, with "err" being mandatory and user defined. The long form would be:
```go
foo := fn() ? err {
// do stuff
return fmt.Errorf("fn: %w")
}
```
This way at least the variable name is explicit, and I find the short form `? err` more readable and visual than just a bare `?`
It doesn't solve my coverage issue, but I guess it can be solved with tooling
@[email protected] @[email protected] the fact this proposal also implicitly declares (define?) an `err` variable (or `errval` or `erv` depending on the update you read) is also a terrible choice. This goes against everything Go strives to be.
@[email protected] @[email protected] There are valid reasons for not liking this proposal.
For example, think in terms of test coverage:
```go
foo, err := fn()
if err != nil {
return err
}
fmt.Println(foo)
```
This code requires 2 tests to get 100% coverage, which is GOOD. It makes it easy to see if you forgot to test some paths.
```go
foo := fn() ?
fmt.Println(foo)
```
With this, if you only test the happy path, you get 100% coverage.
Less lines of code is not always an improvement, explicitness has value.
@hilyas @melocopon my advice is the opposite, don’t worry too much about ATS but make a great looking CV, like this one. The only important thing is that your CV is actually text, not an image of text (ie. make sure the text is searchable and selectable). I actually worked on an ATS and I can tell you ATS automatic filtering is an urban myth, it doesn’t exist. ATS extract CV data if they can, but they never reject a CV. Recruiters are terrified of missing on a good CV.