If you use Go or gRPC, then you're probably using HTTP/2. I've seen both used, at least somewhat, by every company I've done work for in the last 5-6 years.
I'm not. My go-to web frameworks are Elixir/Phoenix, Python/Django, NodeJS/ApolloServer.
I have an irrational hatred for the Go language, but still use it to develop quickly some CLI tools.
Do you mind sharing why?
Eventually I think it'll be seen as the next PHP. A language that people love to hate.
An error should be taken care of immediately, or propagated with some additional context. Returning the error instead of throw/catch makes this explicit and forces the developer to think about it.
In practice: a lot of boilerplate code.
Rust does this better with the Result type and the ? operator.
But the result is that today, the ecosystem is huge. Implementing a kubectl plugin in Go is far easier than in other languages. Many things are in fact simpler with Go thanks to its vast stdlib and ecosystem.
I hate it, and yet... It's still useful to me.
Yes, true. But so is Erlang/Elixir.
At work we have a split code base between rust and go, using go to interface with the world due to better ecosystem while using rust for the heavy lifting of business logic in an extremely concurrent implementation.
Even though the rust side is more complex it is much easier to work with and refactor leading to fewer bugs. The language simply gives so much for free, when you get over the first humps of a slow start.
The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical.
> The language simply gives so much for free
> The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical.
My view of "free" in the comment is correctness. Concurrent code simply keeps on working through refactors to suit the business needs. Most of the time the tests pass the first time the code compiles again after a refactor of core pieces. That is something I haven't experienced in any other language. I simply do not feel scared touching, changing or removing anything to get the most lean code base possible.
Compare this to Python where I want to have the mental model of the entire "world" for every change I do and then simply hope that the tests will catch any errors. Go is better when kept simple, but still a lot of implicitness and conventions leading to easy shooting yourself in the foot.
> Isn't that the workflow of any minimum viable product development paradigm?
Definitely, Rust simply gives more tools for it. For example through sum types and traits to enforce invariants. Say comparing to the awful iota hacks to get "enums" in Go, accidentally having a meaningful default value or run time verification because somewhere you ended up with an interface{}.
In rust for the "make it work stage" simply throw expects everywhere and choose to panic on errors, or just bubble to the top without caring. It never silently simply works unless you've explicitly chosen how to deal with the possibilities which is very reassuring.
Go has some of that feel, but actually doing something useful with errors more than logging I have never seen a good paradigm for yet. Errors as/is kind of works but still puts most of the work on the user to figure out the correct thing. Maybe I haven't dove deep enough though.
For some info on how far you can take error handling in Rust forcing correctness on the users see this blog post from Sled (an embedded KV database) http://sled.rs/errors.html
Interestingly, the example code on the Tokio github page use the antipattern described in the Sled article, regarding the try operator.
Maybe this is a key ingredient in successful languages. Just warty and anachronistic enough that users learn a lot of unique patterns that keep them glued to the language.
- interface implementation is implicit
- "export" is based on the function/type/member name (first letter uppercase)
- private functions/types/members are private within a package not a single file
- ...
The other annoyances I have are just petty, like "if err != nil", zero-values, or the fact that VS Code still does not support Go projects in subdirectories (I like to open my whole "devel" folder).
Fun fact: this is true for python too! https://stackoverflow.com/questions/40764347/python-subclass...
This is annoying, but there is a workaround: add each folder with a go.mod file individually starting with the most nested ones first. So add each project separately, then add the root dir.
|-+ orga (github, gitlab, other)
| |-+ domain (infra, business, research, ...)
| | |-+ repo-name
If I was deploying to baremetal, I would either have a HAProxy/Keepalived reverse-proxy, or a load balancer that most probably supports it.
But HTTP/1.1 have not yet failed me, so I have not yet considered the migration.
If it's not broken, don't fix it :)
Also looks like a trivial config change. I’m not familiar with it but I don’t see any red flags.
> If it's not broken, don't fix it :)
This seems exceedingly myopic in this context. Why migrate to broadband from 56k modem? That modem connects to the internet too! Why upgrade to a browser version which supports HSTS? You can just manually type https in the location field. Why try anything with new features at all? You can just never have new features if they work.
I’m not saying there’s never a trade-off with any of these things. But you’ve preemptively ruled out any benefit without exploring them… or whether they even have any meaningful (to you) cost. “Cutting off your nose to spite your face” is the phrase my family uses for this.
- not migrating to broadband from 56k modem
- not upgrading to a browser version which supports HSTS
- not trying anything with new features at all
Sure I can try HTTP/2 (and I did), and HTTP/3 (and I will). But when it comes to distributing an application/service to customers, I'll automatically choose the battle-tested 30 years old technology which is supported by everyone and every device.
In my case it's monitoring security issues like h2 to h1 header smuggling and the security implications in complex environments where front end proxies may talk to both h1 and h2 applications.
> Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS.