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).
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. :)
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?