weberc2

That certainly seems like an interesting system, and at the moment I'm open to ideas, although it's essentially impossible that my country will adopt a new system.

I think I fully agree, although to expound on (1) I don't think that is the kind of software that any company should want to depend on for anything remotely important. I'm sure there are counter examples where you get a high quality project that doesn't require or accept donations, but I think these will be exceedingly few and far between. It seems like it's in the company's best interest to make sure the development for a dependency isn't going to go away for lack of funding?

I'm of the opinion that large companies should be paying for the software they use regardless of whether it's open source or not, because software isn't free to develop. So assuming you're paying for the software you use, you still have the problem that you are subject to your internal procurement processes. If your internal procurement processes make it really painful to add a new seat, then maybe the processes need to be reformed. Open source only "fixes" the problem insofar as there's no enforcement mechanism, so it makes it really easy for companies to stiff the open source contributors.

I don't think this is entirely true. A system of government could dramatically limit the power of the executive or make it easier to remove a president or make it harder for the legislature to make moves (essentially just limit the damage until the cult effect wears off).

> Are you claiming that the Army anniversary date being on DJT's birthday ISN'T a coincidence? That must take some crazy mental gymnastics...

You should read the post you're responding to. It clearly addresses this very question.

> though some aren't real either

I think you mean, "though I'm not familiar with some of those cases"--otherwise a citation is needed.

The US doesn't keep biometric data on every citizen or lawful resident, and the government can trivially lie or make a mistake about whether they did the database/ID check. This isn't a hypothetical, many legal residents and some citizens have been swept up, and without due process they have no ability to say, "I'm a legal resident" or "I'm a US citizen". They can just be shipped off to an El Salvadoran prison camp where the president can claim, "oops, I can't get them back because they're not in our jurisdiction any more".

> And no country gives whatever it is you're calling due process to illegal immigrants.

Virtually every European country gives due process, even in illegal immigration cases. And probably more importantly, the US Constitution requires due process even for cases of illegal immigration.

> Obama deported hundreds of thousands without any legal hearings

But they had due process. He didn't round people up in the streets without the ability to contest government claims of illegal immigration.

Yeah, they're actually simple enough that they're kind of a perfect way to learn a new language... You get to try something that is pretty familiar (transforming some source files into some destination files), small enough that you can actually build the thing in a weekend, and big enough that it isn't just a toy program--it will give you a tour through the standard library, the build tooling, the package management / ecosystem, etc.

You can also use it to play around with different programming paradigms--I recently rewrote mine from Rust to Go and played around with a maximally parallel architecture (what I thought would be a fun throw-away experiment quickly became my production SSG): https://blog.weberc2.com/posts/efficient-ssg-with-csp.html

> Isn't the hype more about the relative difference (I don't think most people are claiming NL is a utopia)?

We're talking specifically about self-designated "anti-car" people. I doubt there are any surveys, so we're all just conjecturing, but the rhetoric I see definitely holds NL and Europe generally up as a car-less utopia. For example, the first post on r/anticar is titled "cities built for people rather than cars are so beautiful" and it shows an idyllic picture of a German street. https://www.reddit.com/r/Anticar/comments/mp6t4p/cities_buil...

> The amount of miles driven per capita in the US is twice as much as that of the NL. The percent of trips on bike is 25% in the NL vs 2% in the US. About half of all trips made in the NL are on bike, transit or walking. The other half of trips are made with cars.

I don't see how this is relevant? I don't think anyone in this thread disputes that cycling is more prevalent in NL versus US, and none of this refutes the toplevel claim that NL is a car country nor supports the anti-car rhetoric which suggests that NL is a car-free utopia. Like many "non-anti-car" Americans, I would like to see American transit become more multi-modal, but that's not what we're debating at present.

> However, I am sure that the NL could still make many changes to reduce car ownership if it really wanted to.

Sure (the obvious/extreme example is banning cars by legislation), but this seems circular, because we're implicitly interested in why doesn't the NL public want fewer cars (on the contrary, car ownership was increasing as of 2016)? Like in the US we can plausibly argue that Americans haven't experienced the Dutch cycling/pubtransit system and thus doesn't know what they're missing out on, but that's a much harder argument to make about the Dutch. :)

Relatedly, I found this out the hard way yesterday evening: https://stackoverflow.com/questions/66631251/overflow-evalua...

Me too: https://weberc2.github.io/

I'm also curious what problems this presents and what platform the OP thinks we ought to use and why.

EDIT: Interestingly, I just Googled `"github is not a blog"` and the only hit was https://news.ycombinator.com/item?id=22910089 also from the OP 3 months ago where he also didn't support his position.

The great thing about Go is that you don't need to think about allocations or lifetimes until you care about performance. Memory management is optimization in Go, while in C, C++, Rust, etc it's required to get a program to compile (of course you can "opt in" to easy memory management in those languages by using some kind of GC library, this is vanishingly rare--presumably developers would rather just use a language that was designed for GC). If you're at the point where your Go code is so performance sensitive that you're optimizing memory more often than not, it probably makes sense to be using Rust, but these cases are rare for the kinds of applications I tend to write (which is sad because I actually really enjoy using Rust).

Right, but as previously mentioned, Go's multiple return values are already "generic" and already signal developer intent. If you have a library method that returns (int, err) every single Go developer will check the err first before using the int. User-defined generics don't improve this use case.

Generics aren't the gap (multiple return values are already generic), but rather sum types. Sum types are what allow you to express that this is either None/Sum(T) (Option) or Ok(T)/Err(E) (Result) or Nil/Cons (List) or etc.

I agree that there are semantic issues with pointers, but my point was to illustrate that you need sum types in Go to get any real benefit out of an Option type. If you need an option type and you aren't content with a pointer, you can use `(T, bool)`, but this is still a far cry from a real Option type.

This doesn't add anything. You get the same protection in Go with pointers. For example, a `*T` can't be passed to a function taking a `T` without explicitly dereferencing it. The problem of course is that the type system doesn't guarantee that the pointer isn't nil when you go to dereference it, similarly your `Option<T>` doesn't guarantee that the option.Value is set correctly. You need sum types to provide this substantial guarantee.

> In comparison, you can happily ignore `err` in Golang and continue with an invalid `value`.

I'm struggling to envision a Result type that requires you to be more explicit than `foo, _ := fallible()`. Seems like `fallible().Ok()` and similar are strictly less explicit.

Yeah, I have considerable experience with Go and Python, and my experience with Go has been consistently positive for all of the problems we're facing with Python; however, my org is not interested in considering other languages presumably because of the beliefs that it will take years to come up to speed on a new language and even then a statically typed language will be inherently slower to iterate with than a dynamically typed language (these assumptions are probably overfit to senior engineers' experiences with C++/Java in college or early in their careers).

I was just measuring the size of Terraform earlier today--it's a program with 733 dependencies and it weighed in at 63 mb without stripping symbols or compressing when compiled with go 1.13. I was comparing it to our Python executable bundle that weighed in at 260mb with only 104 dependencies and had become too big to run in a lambda, and I found myself jealous of everyone who is fussing over their 10mb Go binaries. Anyway, I rebuilt Terraform and it's now I'm 6mb more jealous of everyone fussing over their Go binary sizes.

EDIT: If I compress the Terraform binary and the Python lambda, they become 14mb and 250mb respectively. At least Python is fast, right?

Whoa, the author of Caddy is from Dubuque? That's so cool!

Jesup here

Any statically types, general purpose programming language would do the trick—just generate YAML. I’ve been playing with typed-Python and it works really well. The only issues are that Python’s type system is pretty immature (can’t represent JSON, can’t constrain generic types to a particular interface/protocol a la Rust traits, type annotations in a class share the same namespace as member variables, etc). I would like to try Go for this, but it would be a fair bit more imperative.

I think the problems are mostly around configuration that is so complex and redundant that we need programmatic abstractions to deal with it—we need something like a general purpose programming language to DRY up and simplify that configuration, but the powers that be are clinging desperately to YAML (despite encoding a shitty, half-baked AST on top of it a la CloudFormation or “generating” YAML with text templates a la Helm) as the human/configuration interface presumably because the “it’s as easy as YAML!” is such a good marketing schtick.

A certain amount of configuration complexity will always be there, but there’s still a lot of incidental complexity that could be cut away if we just generated these config a with a general purpose language.

Seems like one could craft policy that treats social media giants differently than relatively small forums, no?

Governments aren’t homogeneous. In the US there’s plenty of energy (especially among conservatives) to restrict social media giants’ right to censor, at least with respect to political censorship.

That’s a good question. Presumably you could draw some line to distinguish between small communities and enormous ones (tens of millions of monthly active users, for example), or distinguish between social media and forums.

This is a cool project and I like your point about resetting expectations wrt performance. I work in an all-Python shop and it’s maddening that people are relatively okay with builds (mostly installing dependencies) in the tens of minutes, CLIs that take ten seconds to print —help, and requests that take tens of seconds at the median and timeout at p95, not to mention at least 5x more spend on our cloud bill.

With something like Go, it would take us a little up front effort to learn the language and we would easily get a 1-2 order of magnitude improvement in most of these metrics (and any productivity difference is well within the margin for error). This is our shop, but it’s also a microcosm of the broader Python community (e.g., takes half an hour to resolve dependencies for medium sized projects). It would be really cool if the broader community would rally around PyPy and improve its support or if CPython would move be willing to concede some backwards compatibility on its extensions interface in order to allow for more optimizations.

Fixing the quote format so people can read it:

> At Mondragon, there are agreed-upon wage ratios between executive work and field or factory work which earns a minimum wage. These ratios range from 3:1 to 9:1 in different cooperatives and average 5:1. That is, the general manager of an average Mondragon cooperative earns no more than 5 times as much as the theoretical minimum wage paid in their cooperative. For most workers, this ratio is smaller because there are few Mondragon worker-owners that earn minimum wages, because most jobs are somewhat specialized and are classified at higher wage levels. The wage ratio of a cooperative is decided periodically by its worker-owners through a democratic vote.

You misunderstand the point of formatters. They aren’t meant to automate your personal preference; they automate a standard format so your team doesn’t have to waste time deciding on and enforcing a coding standard and so you don’t have to manually implement the standard. Implicit in using a code formatter is the decision to stop navel gazing and put the team first.

I’m honestly fine with putting the dict in the function call in most cases. It’s not a big deal either way. As for your exceptions, you can just do

    raise ValueError(
        "Lorem ipsum dolor sit amet, consectetur adipiscing elit. "
        "Maecenas vel ligula nec eros finibus metus."
    )

No need for the extra variable.