1. I'm not a driver, much less in a country with toll roads. But is it common to have per-vehicle customized toll prices? I would expect to pay a fixed per-car, per-use fee.
2. How is this dependent on privatization? Every car is registered. So it seems pretty easy to enforce taxes on cars. And to do so based on model, weight, whatever you want.
In other words, from what I can tell, making people pay their fair share seems simpler in a public system, if anything. It certainly doesn't require privatization.
FWIW I have little skin in the game, as I said, not a driver, so I would probably benefit both by having to pay less tax and by reducing overall car usage.
> But, like, this is exactly as easy with every single other language that I can think of.
I mean, not exactly. Rust (or rather Cargo) requires you to declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`. It's a lot more ceremony and it has actively annoyed me whenever I tried out Rust.
> The second part "Running go install at the root ./.." is actually terrible and risky but, still, trivial with make (a - literally - 50 year old program) or shell or just whatever.
Again, no, it is not trivial. Using make requires you to write a Makefile. Using shell requires you to write a shell script.
I'm not saying any of this is prohibitive - or even that they should convince anyone to use Go - but it is just not true to say that other languages make this just as easy as Go.
> declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`.
It does not. Those are the defaults. You can configure something else if you wish. Most people just don’t bother, because there’s not really advantages to breaking with default locations 99% of the time.
I think one other major part is that, compared to e.g. make the build process is more-or-less the same for all Go projects. There is some variation, and some (newcomers I want to think) still like to wrap go commands into Makefile, but it's still generally very easy to understand and very uniform across different Go projects
> Bluesky's architecture was pretty much dictated by the premise that anyone needs to be able to see any post on the entire system, regardless of whether they have any connections with the author. That algorithmic entertainment-style feeds need to exist. You do need that firehose and other expensive infrastructure for that, there's no going around it.
Exactly this (that people want it at least - I don't think that means it needs to exist). And I think there would be a lot less frustration in the discourse of ActivityPub vs. ATproto, if we could collectively agree that you can't get this in a decentralized system. In a dense network, the number of edges scales with the square of the number of nodes. It's just not feasible to have a network that is both dense and has a large number of nodes.
I think "I prioritize virality, recommendation engines and network density, thus accept giving control over the network to a centralized and profit-oriented entity" is an entirely reasonable tradeoff to make. I just don't understand why BlueSky users don't seem to accept that it's the tradeoff they are making.
absolutely. it’s even in the design paper, when they discuss the AppView the authors say it’s “less decentralized than alternatives” and yet you can’t say that without bsky fans getting mad.
Uhm correct me if I'm wrong, but… you can sell your stake and leave at will, with zero exit tax? So really, the only thing that the exit tax prevents is the company leaving the country. And you know, every time someone brings up taxing the rich, people object that this would cause capital flight. Well, capital flight is exactly what the exit tax prevents. The capital stays in the country.
And likening that to the Berlin wall, where people literally got shot dead, is honestly pretty disgusting.
> You could, of course, sell or wind down your company, which would solve all problems outlined here. But this is not an option for most entrepreneurs.
Yes, it is literally an option, you dunce. There is no law requiring you to keep ownership of a business. You might not like that option very well, but it is an option, which is infinitely better than the denizens of the GDR got.
Man, this post got my blood boiling with its callous stupidity.
> AI is really good at generating repetitive patterns, like plain types, or code that implements a certain interface. If you reduce the cost of creating the verbose code [at write time] we can all enjoy the benefit of reduced complexity [at read time] without resorting to generics.
Though humans are very bad at reviewing repetitive patterns. I'd much rather review a single generic implementation, than 10 monomorphic ones, that look the same, but where I can't be sure and actually have to check.
So unless you are making the argument that generated code doesn't require review (compliance auditors would disagree) I would personally still much rather have generics.
> Maybe when you have code that works with the `interface{}` a lot (e.g. unknown JSON data) you'll have a use case for it.
I think in those cases, generics are specifically kind of pointless. Because you will inherently need to use `reflect` anyways. Generics are only helpful if you do know things about your types.
Generics are most useful for people who write special-purpose data structures. And hence for people who need such special-purpose data structures but don't want to implement them themself. The prototypical example is a lock-free map, which you only need, if you really need to solve performance problems and which specific kind of lock-free map you need depends very heavily on your workload. `sync.Map` is famously only really useful for mostly write-once caches, because that's what its optimized for.
The vast majority of people don't need such special-purpose data structures and can get by just fine with a `map` and a mutex. But Go has reach the level of adoption, where it can only really grow further, if it can also address the kinds of use-cases which do need something more specific.
I don't disagree that Go's generics are pretty limited. But I find it a strange complaint, when contrasted with C++ templates. Which, as I understand, are literally not part of the type system and thus there seems to be a far stronger case, that they can not be called generics.
The main difference between Go's generics and C++ templates (and where some of the restrictions come from) is that Go insists that you can type-check both the body of a generic function and the call to it, without one having to know about the other. My understanding is, that with C++ templates (even including concepts), the type checking can only happen at the call-site, because you need to know the actual type arguments used, regardless of what the constraints might say.
And this decision leads to most of the complaints I've heard about C++ generics. The long compile times, the verbose error messages and the hard to debug type-errors.
So, if you prefer C++ templates, that's fair enough. But the limitations are there to address complaints many other people had about C++ templates specifically. And that seems a reasonable decision to me, as well.
> the type checking can only happen at the call-site, because you need to know the actual type arguments used, regardless of what the constraints might say.
No longer true after C++ 20. When you leverage C++20 concepts in templates, type-checking happens in the template body more precisely and earlier than with unconstrained templates.
In the below, a C++ 20+ compliant compiler tries to verify that T satisfies HasBar<T> during template argument substitution, before trying to instantiate the body
As I said in the other comment, I'm not a C++ user, so I'm relying on cargo-culting and copy-paste. But I think gcc disagrees - otherwise this would not compile, as line 14 is provably invalid: https://godbolt.org/z/P8sWKbEGP
> You need to have something that uses those templates.
Exactly. That is what I said:
> because you need to know the actual type arguments used, regardless of what the constraints might say.
It is because type-checking concept code is NP complete - it is trivial to check that a particular concrete type satisfies constraints, but you can not efficiently prove or disprove that all types which satisfy one constraint also satisfy another. Which you must do to type-check code like that (and give the user a helpful error message such as “this is fundamentally not satisfiable, your constraints are broken”).
And it’s one of the shortcomings of C++ templates that Go was consciously trying to avoid. Go’s generics are intentionally limited so you can only express constraints for which you can efficiently do such proofs.
There are common solutions for the library issue. Authors of libraries for example can force instantiations for a dummy type that checks their concepts.
template void foo(Dummy);
This can be done at the consumer side as well. I don't see a big deal of this. Dummy checks are common in Go too. For example, to check if a type satisfies an interface.
var _ MyInterface = (*MyType)(nil)
var _ SomeInterface = GenericType[ConcreteType]{}
After all, Go checks that a type implements an interface only at the point where you assign or use it as that interface type.
Thanks for your blog post. Unfortunately, the intentional limitations make the design space a massive headache and many times lead to very convoluted API. I would actually make the argument that it explodes complexity - for the developer, instead of constraining it.
> There are common solutions for the library issue. Authors of libraries for example can force instantiations for a dummy type that checks their concepts.
But that just ensures that the code type-checks for `Dummy`. It doesn't ensure that the code type-checks for any type you can put into `foo`. And that's the point of type constraints: To give you the necessary and sufficient conditions under which a generic function can be used.
That is simply not the case with C++ templates and concepts. That doesn't mean you can't still like them. I'm not trying to talk you out of liking C++ or even preferring it over Go. I'm just trying to explain that C++ concepts where something that we looked at specifically and found that it has properties that we don't like. And that - to us - the fact that Go generics are limited in comparison is a feature, not a bug.
And let's not forget that despite specifically reducing the safety of concepts in this way, the design ended up being NP-complete anyways and you can make a compiler use functionally infinite memory and time to compile a very small program: https://godbolt.org/z/crK89TW9G
For a language like Go, that prides itself on fast compilation times it is simply unacceptable to require a SAT solver to type-check. Again, doesn't mean one has to dislike C++. But one should be able to acknowledge that it is reasonable to choose a different tradeoff.
> I would actually make the argument that it explodes complexity - for the developer, instead of constraining it.
The title is a pun. Because it is about the computational complexity of checking constraints.
> But that just ensures that the code type-checks for `Dummy`. It doesn't ensure that the code type-checks for any type you can put into `foo`
Sure, that is C++ specific design decision. Just like Go made the design decision of not type checking interfaces leading to tens-of-thousands of lines of dummy checking concrete types against interfaces in popular Go repos.
I understand the design thinking even if I don't fully agree as a standard user of Go. Thanks for the detailed explanation in the blog.
Minor nitpick: It isn't all that difficult to come up with type structural/generic edge cases for ANY language compiler where compilation takes forever and times out in a playground. Here is a small program of ~100 lines leveraging Go Generics: https://go.dev/play/p/XttCbEhonXg
This will build for several minutes on your laptop if you use `go build`. It can be easily extended to several hours with a few modifications.
> Minor nitpick: It isn't all that difficult to come up with type structural/generic edge cases for ANY language compiler where compilation takes forever and times out in a playground. Here is a small program of ~100 lines leveraging Go Generics: https://go.dev/play/p/XttCbEhonXg
Just to clarify why this is a problem: it’s possible for foo and bar to be defined in different libraries maintained by different people. Potentially several layers deep. And the author of the foo library tests their code and it compiles and all of their tests pass as and everything is great.
But it turns out that’s because they only ever tested it with types for which there is no conflict (obviously the conflicts can be more subtle than my example). And now a user instantiates it with a type that does trigger the conflict. And they get an error message, for code in a library they neither maintain nor even (directly) import. And they are expected to find that code and figure out why it breaks with this type to fix their build.
Or maybe someone changes one of the constraints deep down. In a way that seems backwards compatible to them. And they test everything and it all works fine. But then one of the users upgrades to a new version of the library which is considered compatible, but the build suddenly breaks.
These kind of situations are unacceptable to the Go project. We want to ensure that they categorically can’t happen. If your library code compiles, then the constraints are correct, full stop. As long as you don’t change your external API it doesn’t matter what your dependencies do - if your library builds, so will your users.
This doesn’t have to be important to you. But it is to the Go project and that seems valid too. And it explains a lot of the limitations we added.
"Compile time" is not the right distinction. This is about "instantiation time". Go's implementation specifically allows to type-check the body and the call separately. That is, if you import a third-party package and call a generic function, all the type checker needs to look at to prove correctness is the signature of the function. It can ignore the body.
This is especially relevant, if you call a generic function from a generic function. For C++, proving that such a call is correct is, in general, NP-complete (it directly maps to the SAT problem, you need to prove that every solution to one arbitrary boolean formula satisfies a different boolean formula). So the designers made the conscious decision to just not do that, instead delaying that check to the point at which the concrete type used to instantiate the generic function is known (because checking that a specific assignment satisfies a boolean formula is trivial). But that also means that you have to (recursively) type-check a generic function again and again for every type argument provided, which can drive up compilation time.
A demonstration is this program, which makes gcc consume functionally infinite amount of memory and time: https://godbolt.org/z/crK89TW9G (clang is a little bit more clever, but can ultimately be defeated using a similar mechanism).
Avoiding these problems is a specific cause for a lot of the limitations with Go's generics.
> Look at Haskell type classes or Rust's traits for some classic examples of how to 'type' your generics. (And compare to what Go and C++ are doing.)
Yes, those are a different beasts altogether and the differences between what Go is doing and what Haskell and Rust are doing requires different explanations.
Though it's illustrative, because it turns out Rust also intentionally limited their generics implementation, to solve the kinds of performance problems Go is worried about. Specifically, Rust has the concept of "Dyn compatibility" (formerly "Object safety") which exists because otherwise Rusts goal of zero-cost abstractions would be broken. Haskell doesn't have this problem and will happily allow you to use the less efficient but more powerful types.
(All of this should have the caveat that I'm not an expert in or even a user of any of these languages. It's half-knowledge and I might be wrong or things might have changed since I last looked)
This is not really true after C++ 20. C++ templates can leverage concepts that specify compile-time constraints and type checking on template parameters during template argument substitution
Yes, concepts are the fix to that duck typing. Not sure how widespread they are in the wild yet (nor how good compiler support is already at the moment.)
reply