[flagged]
Oracle over Google is debatable, but piss up a rope sideways is pure gold.
Most of us are running openjdk, not Oracle Java, openjdk, which is ... open...source.
Better HTTP server routing in Go 1.22
141–150 of 236 posts
Re: Better HTTP server routing in Go 1.22
#142Earlier quoted context omitted.
What common use-cases does it not support?
The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database. You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework. This feels…
The two routes `/foo/bar` and `/foo/*` are not ambiguous and would be allowed by the router
Re: Better HTTP server routing in Go 1.22
#143Earlier quoted context omitted.
In my experience most developers are not connected to the development processes of their dependencies. Maybe they should be, I think there's an argument for it, but with so many dependencies there's only so much time and attention. I think any migration such as this should be done on the assumption that most people won't know it's happening.
It's a bit of a catch-22: 1. I want to send a PR! 2. Project doesn't seem very active, so never mind. Plus I'm not checking if any of my dependencies need help every day. I took over fsnotify after it was archived because I just didn't know they needed help. Last guy spent about 5 years looking for someone to take it over. I wouldn't have minded doing it before, but ... you do need to know about it.
How much time do you spend working on fsnotify if i may ask.
Re: Better HTTP server routing in Go 1.22
#144Earlier quoted context omitted.
That’s not a breaking change.
How is "this api usage was allowed before and now panics" not a breaking change?
Which specific API usage was allowed before and now panics? As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice, which in my books is just a bug.
Certainly it's technically a breaking change, but there's huge difference between making all existing usage of the mux interface incompatible with the new changes, and only making obviously incorrect and buggy usages of the interface incompatible.
Re: Better HTTP server routing in Go 1.22
#145Earlier quoted context omitted.
> Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. The panic is the tooling. It ensures that you can’t write code that becomes ambiguous and hard to reason about, or become dependent on something random like the order code is initialised in, which…
> It’s pretty trivial to write a handler that accepts the base path, and then routes to a different set of handler functions. Then the routing is clear and explicit. It seems a little pointless to have route handling functionality that requires more route handling for pretty normal cases.
Almost all the examples provided as "pretty normal cases" of having overlapping path registrations are already handled without panicking by the path precedence rules. All the cases where you have a wildcard path + handlers for specific variants of the wildcard values, are handled as expected without panics. Only the rather extreme corner case of having two wildcard paths, with wildcards in different locations, but still matching the same path, results in a panic.
Honestly if you're running into the second case above, I would question the wiseness of whatever it is you're attempting to do, because reasoning about the behaviour is unlikely to be clear and obvious if registration order is the only differentiator.
Re: Better HTTP server routing in Go 1.22
#146Earlier quoted context omitted.
No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing. It means that the code is readable only to those who have spent a lot of time working with that framework. And it is one thing to be able to guess what is going on, if you are only superficially familiar with the framework. It is another thing entirely to know enough to be able to debug the code or to…
> No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing Are you in the habit of hiring people without experience? Developers had to spend months (years) learning javascript before they learned any frameworks. Would you rather switch to point and click programming so that your developers don't need to actually learn to code? > It means that the code is rea…
> Are you in the habit of hiring people without experience?
I hire people who I believe can produce quality code as part of a team. I've hired people with zero experience and with 35+ years of experience. I've probably hired somewhere around 200 people. I have no idea how many people I've interviewed.
I have both hired people with decades of experience who turned out to be poor hires, and I've hired people without any experience who went on to make critical contributions to billion dollar projects.
If your hiring criteria are "has experience with X" you are limiting the size of your hiring pool to people who are heavily invested in "X". That is probably not the most brilliant hiring strategy. For one it means you can never hire people who have newly graduated.
> All frameworks will place limitations on how you express yourself.
True, but some frameworks will more severely limit your future options and be harder to move away from. The more of you application is affected by the framework, the more expensive it is to move away from it. This is an important reason why the Go community tends to discourage creation and use of large frameworks.
I can understand that you are defensive if you have spent years making this investment and someone suggests you have made a poor choice. But I think it would be time well spent to try to understand why many companies are moving away from the "big framework" approach.
> I question your judgment [...]
That's fine.
> It would indicate, to me, your lack of experience in writing or reading code [...]
You're free to make that assumption. Even though it makes you look a bit silly since you are making assumptions about something you lack data on.
Re: Better HTTP server routing in Go 1.22
#147As I commented[1] I think the syntax is flawed in the proposal. You need to weirdly create a magic string to define your handler. Why not make it an actual argument, then using already existing constants is easier. [1] https://github.com/golang/go/issues/61410#issuecomment-16580...
But isn't it a magic string already, because of the {parameter} parsing? I don't really see an issue in treating it as if it was just `Request-URI` (in RFC2616 terms) with some parameter magic, and became a Request-Line-resembling `[ Method SP ] Request-URI`, which is fully backwards-compatible and isn't exactly surprising to anyone. I think it's pretty much obvious what it does even if one never sees the documentati…
> And given that `Method` is either one of a few predefined constants
The compiler via a method call or parameter can capture this constraint in a pretty straight forward way. I'm not sure why an API would give that up
Re: Better HTTP server routing in Go 1.22
#148Go is not my main tool but I've used Gin which goes like this: router.GET("/", func(context *gin.Context) { ... } And it seems to be no different than many other languages/frameworks. Are there more examples that use the "GET /path/" way ?
Most likely not because there's no reason to do it this way other than backwards compatibility ...
I haven't read the article, but I would guess it's because the http header literally starts like that. You could match that against the first line, instead of having to break it into components.
It does sound like a micro-optimization.
Re: Better HTTP server routing in Go 1.22
#149Earlier quoted context omitted.
I believe it allows `/foo/bar` and `/foo/{id}` as the first one is more specific and has precedence. This looks fine to me. Looks like it will panic in case you have `/foo/{id}/delete` and `/foo/bar/{action}`. /foo/bar/delete will match both, none is more specific so it panics. Feels reasonable. Having a first one wins precedence might be better though.
It's a 404 Not Found or 500 Server Error. HTTP server panicking is never reasonable
The panic happens at handler registration i.e. binary startup, not while performing path matching. Having literally any tests in your application, literally anything that executes your binary before you ship it, will tell there's a problem. Your code simply won't be able start serving traffic if there's path routing ambiguity.
If you've managed to ship code that panicked during execution due to path routing ambiguity, then honestly your code is probably so riddled with bugs this is going to be the least of your issues.
Re: Better HTTP server routing in Go 1.22
#150Earlier quoted context omitted.
> You can still do service injection in JavaScript I know that angular is really good at this, but I'm not sure what pure js frameworks would allow a service to be defined as an interface first, and then injected into the constructor of a controller (or even a handler function) based on the implementation method selected somewhere else. I just haven't seen it happen.
tsyringe is a popular library that does this in TypeScript
Yeah I use nestjs for my backend at my company and it also has a good DI framework, but it depends on typescript interfaces to work well