7 ms·

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.

halpert 5y ago
The default Go http server is 1.1, no?
- ferdowsi 5y ago
  The default Go server supports HTTP/2. https://pkg.go.dev/net/http https://pkg.go.dev/net/http > Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS.
linkdd 5y ago
> If you use Go or gRPC 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.
- topicseed 5y ago
  > I have an irrational hatred for the Go language Do you mind sharing why?
  - serverholic 5y ago
    Not the same person but I share his sentiment. Go is terribly designed from a language perspective. It's weird and doesn't follow normal language conventions. The tooling and package manager is terrible. Eventually I think it'll be seen as the next PHP. A language that people love to hate.
    - eyelidlessness 5y ago
      I haven’t written any Go, but having read through some tutorials I find this a little hard to believe. Besides, Node has already been the next PHP, in terms of reputation and ridicule, for almost its entire lifespan. I do expect Go will become more esoteric over time, but mostly because it’s a Google thing (with all the unpredictability that implies), and because it overlaps a couple rapidly evolving use case targets.
      - azurelake 5y ago
        It's not. For the niche it has found success in (infra type backend stuff), it's by far the best option available. `if err != nil` is a godsend in that world.
        ciupicri 5y ago
        What's so great about `if err != nil` ?
        linkdd 5y ago
        In theory: explicit error handling. 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.
        eyelidlessness 5y ago
        From a pragmatic perspective, the theoretical advantage is real (typed exceptions are better than not having them, just as explicit nullables are better than implicit). Theoretically Result and Option are just recognized names, which I don’t mean to discount but they’re effectively union types with pattern recognition privileges.
        dmitshur 5y ago
  - linkdd 5y ago
    My biggest annoyance is that the Go language is full of implicit conventions/behaviors: - 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 - ... This is painful because when you read a single file, you need to know about the rest of the code. This makes it very hard to get started with a new codebase, especially a huge codebase. 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).
    - yzmtf2008 5y ago
      > interface implementation is implicit Fun fact: this is true for python too! https://stackoverflow.com/questions/40764347/python-subclasscheck-subclasshook https://stackoverflow.com/questions/40764347/python-subclass...
    - iljya 5y ago
      > VS Code still does not support Go projects in subdirectories 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.
      - linkdd 5y ago
        Unpractical for me, my "devel" folder is organized as follow: |-+ orga (github, gitlab, other) | |-+ domain (infra, business, research, ...) | | |-+ repo-name VS Code do not support hierarchies of projects in a workspace, so I would just have a huge list of `project-name` where project-name would be manually renamed to `orga/domain/repo-name`.
- eyelidlessness 5y ago
  I don’t know what’s common for serving BEAM web services, but unless I’m mistaken nginx is still a safe assumption for Python. If you’re using nginx for either, transitioning to HTTP/2 should be a couple small config changes away.
  - linkdd 5y ago
    I deploy on Kubernetes, so it will be behind an Ingress controller (NGinX, Istio, ...) if it needs to be exposed to the outer world. 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 :)
    - eyelidlessness 5y ago
      > Istio 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.
      - linkdd 5y ago
        There is a difference between switching protocol, and: - not migrating to broadband from 56k modem - not upgrading to a browser version which supports HSTS - not trying anything with new features at all HTTP/1.1 still serves its purpose, successfully, without any impact on performance/usability. I'm not Google, I'm not serving a webpage to 8 billions devices at the same time. 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.
- tokumei 5y ago
  Elixir/Phoenix used to be my go to as well. I’ve since switched to Rust with actix-web for backend web projects. I’m really happy with the transition.

halpert 5y ago

The default Go http server is 1.1, no?

ferdowsi 5y ago
The default Go server supports HTTP/2. https://pkg.go.dev/net/http https://pkg.go.dev/net/http > Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS.

linkdd 5y ago

> If you use Go or gRPC 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.

topicseed 5y ago
> I have an irrational hatred for the Go language Do you mind sharing why?
- serverholic 5y ago
  Not the same person but I share his sentiment. Go is terribly designed from a language perspective. It's weird and doesn't follow normal language conventions. The tooling and package manager is terrible. Eventually I think it'll be seen as the next PHP. A language that people love to hate.
  - eyelidlessness 5y ago
    I haven’t written any Go, but having read through some tutorials I find this a little hard to believe. Besides, Node has already been the next PHP, in terms of reputation and ridicule, for almost its entire lifespan. I do expect Go will become more esoteric over time, but mostly because it’s a Google thing (with all the unpredictability that implies), and because it overlaps a couple rapidly evolving use case targets.
    - azurelake 5y ago
      It's not. For the niche it has found success in (infra type backend stuff), it's by far the best option available. `if err != nil` is a godsend in that world.
      - ciupicri 5y ago
        What's so great about `if err != nil` ?
        linkdd 5y ago
        In theory: explicit error handling. 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.
        eyelidlessness 5y ago
        From a pragmatic perspective, the theoretical advantage is real (typed exceptions are better than not having them, just as explicit nullables are better than implicit). Theoretically Result and Option are just recognized names, which I don’t mean to discount but they’re effectively union types with pattern recognition privileges.
        dmitshur 5y ago
- linkdd 5y ago
  My biggest annoyance is that the Go language is full of implicit conventions/behaviors: - 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 - ... This is painful because when you read a single file, you need to know about the rest of the code. This makes it very hard to get started with a new codebase, especially a huge codebase. 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).
  - yzmtf2008 5y ago
    > interface implementation is implicit Fun fact: this is true for python too! https://stackoverflow.com/questions/40764347/python-subclasscheck-subclasshook https://stackoverflow.com/questions/40764347/python-subclass...
  - iljya 5y ago
    > VS Code still does not support Go projects in subdirectories 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.
    - linkdd 5y ago
      Unpractical for me, my "devel" folder is organized as follow: |-+ orga (github, gitlab, other) | |-+ domain (infra, business, research, ...) | | |-+ repo-name VS Code do not support hierarchies of projects in a workspace, so I would just have a huge list of `project-name` where project-name would be manually renamed to `orga/domain/repo-name`.
eyelidlessness 5y ago
I don’t know what’s common for serving BEAM web services, but unless I’m mistaken nginx is still a safe assumption for Python. If you’re using nginx for either, transitioning to HTTP/2 should be a couple small config changes away.
- linkdd 5y ago
  I deploy on Kubernetes, so it will be behind an Ingress controller (NGinX, Istio, ...) if it needs to be exposed to the outer world. 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 :)
  - eyelidlessness 5y ago
    > Istio 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.
    - linkdd 5y ago
      There is a difference between switching protocol, and: - not migrating to broadband from 56k modem - not upgrading to a browser version which supports HSTS - not trying anything with new features at all HTTP/1.1 still serves its purpose, successfully, without any impact on performance/usability. I'm not Google, I'm not serving a webpage to 8 billions devices at the same time. 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.
tokumei 5y ago
Elixir/Phoenix used to be my go to as well. I’ve since switched to Rust with actix-web for backend web projects. I’m really happy with the transition.