Hacker News Reader

Comment by gwd | Hacker News Reader

> Are there go-specific reasons for that?

In general, the reason you use a compiled / typed language like golang at all (instead of, say, perl) is to "left shift" your bugs: A bug caught when you first spin up your application is better than a bug caught after a corner case acts up in the wild, and a bug caught when you compile is better than a bug caught when you first spin up your application.

I recently ran a cross a bug in a side project of mine (using gorilla/mux) where I had accidentally made overlapping routes. If the router had panic'ed instead of running, I would have been nudged to refactor the URLs and completely avoided the bug.

View on HN

Wouldn’t the “left-shift” be a compiler error instead of a panic?

This particular issue is undecideable at compile-time in the general case, so panicking on registration (ie, preventing the process from starting at all) is the next-most visible and noisy error option.

That's where the focus usually is, but aborting at startup is the next best thing. It's an undervalued technique.

Go as a language is generally not sophisticated enough to do that sort of thing.

A counter- and/or example of this is what Service Weaver does to try to bomb builds when generated files are older than their dependencies.

I'm having trouble thinking of a mainstream production language with a stronger type system that could make a compile error out of the string argument passed to an HTTP router; can you think of one? Or of a non-string-typing for routes that solves the same problem, again in something people ordinarily use to deploy to production?

Most languages with macro or templating should be able to define this behavior as a library. Rust and C++ come to mind, for example.

Can you provide an example of a Rust HTTP routing library that can generate a compile-time error for overlapping routes?

I don't know of one, but you seemed to doubt not that it's actively being done, but that it's even possible, which is a very different proposition.

Remember C++ actually implements checks at compile time for the modern std::format function. That is, if you mess up the text of a format string so that it's invalid, C++ gives you a compile time error saying nope, that's not a valid format.

You might think that's just compiler magic, as it is for say printf-style formats in C, but nope, works for custom formats too, it's (extremely hairy) compile time executed C++.

I'm inclined to suggest the typescript could make compile errors of ambiguous routes, though I don't see any obvious reasons way without an explicitly referenced agreggate type for existing routes. So perhaps not if routes are initialised implicitly like this.

Template type strings with inference would also allow you to parse the strings in the type system.

I cannot imagine wanting to build my routes table implicitly through import graph rather than having a specific place to aggregate.

> that could make a compile error out of the string argument passed to an HTTP router

For example, Phoenix Verified Routes in Elixir: https://hexdocs.pm/phoenix/Phoenix.VerifiedRoutes.html

Typescript's type system is known to be turing complete and people have implemented things such as sorting/tree-walking just using types (i.e. during compile time) [1].

I'd imagine something like this should be possible as well, but I'm not sure it would be worth it, considering the effort it would take to implement.

[1]: https://twitter.com/anuraghazru/status/1511776290487279616

OCaml can definitely do it (for example, you get a compiler error if you pass the wrong arguments to a `printf` where the format string specifies, say a number, but you pass in a string).

Rust can very likely do it by leveraging their `build.rs` stuff to parse and validate call sites of the registration and parameters.

Zig can probably do it with their comptime stuff.

In theory, Go could do the same (but that would mean special-casing the `net/http` handler registration in the compiler). At least `go vet` is smart enough to yell at you about wrong format string arguments.

Ideally.

But that's impractical, so the next soonest time is at startup.

It can not be decided on compile time but it provides the basis for a build time "error". It's enough to have a testcase that registers your routes and the bug is descovered even before you commit potentially.

> "left shift" your bugs

<< bug

Am I doing it right?

Reply on news.ycombinator.com