weberc2

Pretty sure all of Netflix runs on AWS and I've got to think that's several orders of magnitude more traffic than Windows updates or xbl.

Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.

> I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.

My point does make sense, you're just missing it.

First of all, my point is that Qt is a poor developer experience--that its interface is bastardized is merely evidence. Further, even if it were not bastardized, it would still be awful because it's C++ (insane build tooling, no package management, poor error messaging, no memory safety, enormous feature matrix, etc etc etc; all of this has been covered elsewhere ad nauseum, no need to repeat those arguments here). There's a long tail of additional issues with Qt that contribute to its unpleasantness, but there's no point in diving into them here.

Secondly, your stateful library functions example doesn't fit my criticism because stateful functions are part of the C++ language spec while signals and slots are not.

C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break.

That's what you get with Qt absent the moc (meta object compiler).

Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.

So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.

As someone who loves the idea of a good cross platform GUI, there simply aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but manageable. You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) or use a leaky Python binding (that still segfaults), but you can build things that don’t look awful. As far as I know, this is the only cross platform GUI tool for which this can be said (except for the browser-based solutions, of course).

VS Code has not been snappy for me. Especially with large screen sizes and lots of widegets. For example, if I close the left-hand pane and shrink the window, performance improves considerably.

"systems programming" is not well defined. While you and I probably prefer a similar definition, comments that criticize TFA for not using our preferred definition are really boring. Let's just say that Go is a fine language for `wc` (and not a very good language for device drivers) and move on.

Yeah, if that figure includes the executable, then it's also probably including the whole runtime (scheduler, GC, etc) since Go programs statically link the runtime by default. In that case, 2MB isn't so bad (especially considering glibc is ~10MB [and with no scheduler or GC!] iirc).

As others mentioned "systems language" isn't well defined. If you want to define a "systems program" as one with hard real-time requirements, then no, Go isn't a very good choice; however, the article defines it differently (such that `wc` satisfies), and demonstrates that Go satisfies that definition.

That said, it's better to use terms that map better to a set of requirements, such as "hard-realtime" or "soft-realtime".

> It's also easy to underestimate the difficulty in mundane technologies. Take bread for instance; this is how you make bread: Grow a grass (cereal crop). Separate the seeds, dry them, and then shell them to get your grains. Now grind it into flour, and then mix it with water, fat, and salt. Let it sit out to grow a yeast infection. Stick it in a fire, and then you get bread. Compare this to typical metalworking: Find the appropriate ore. Stick it in a fire. Depending on the metal, let it melt completely and pour it into a sand cast, or get it red-hot and then bang on it with a hammer.

Your example doesn't support your point. You're simply going into more detail on the baking process than the smithing process. In particular, none of these things are trivial:

* finding the right ore (generally depends on trade and specialization)

* making a fire hot enough to melt metal

* making a sand cast

* alloying the metal

* rooting out impurities such that the finished artifact is useful

* the technical processes of casting and forging

> They're two different approaches, one is quick and "dirty", the other is "enterprise", but the end result is the same: a website.

I would say one is appropriate for simple CRUD websites and the other is appropriate for more complicated web apps. Especially as you scale (your engineering organization or your traffic), things like microservices become increasingly useful.

Moreover, the folks who cry "all news has bias!" to justify explicit propaganda miss the obvious point that bias isn't a binary proposition. A little bit of accidental bias is not the same as deliberately driving an agenda. Real journalism aspires to minimize bias.

Journalism aspires to minimize bias, and that's why people trust journalism as an institution (and why, lately, that trust is rapidly eroding). Using "journalism" to give your biases/agenda the air of objectivity is misleading, immoral, and unethical. If a journalist or editor wants to push their personal agenda, they can use the opinion section like everyone else. That's why it exists.

Hard to say. Our whole team experiences it, there are a dozen related issues in the issue tracker, and the docker-cli and Go bindings work fine while docker-compose is timing out. Based on the issues we’ve had and those files in their issue tracker, there are lots of related issues including some where the docker daemon (or perhaps the docker for mac VM) is unresponsive; we’ve definitely seen that, but as previously mentioned, we’ve also seen this issue while the daemon responds to other clients.

It’s not even dependable for us on local setups; a “docker-compose up” that has to pull images will almost always throw an HTTP timeout exception from inside The Python client.

I’m aware, but it’s irrelevant.

I want to see generics and real enums (I.e., Rust enums, not C/Java enums) added to Go, but as far as it being unsafe or inefficient, these concerns are overblown for many apps. People who levy this criticism are often fine with Python and/or JS for similar categories of applications, even though they are far less safe and less performant than Go. We should be clear when we criticize Go that we’re talking about addressing the last 1% or so of type-related bugs and/or extending the performance ceiling a bit higher. We should also give Go credit for permitting a high degree of safety, performance, and productivity when other languages make you choose one.

There are other factors in engineering besides CPU. For many applications, CPU is the cheaper resource (e.g., compared to developer time / opportunity cost).

That's fine that you see it that way; let's have a debate about that. Why do we punish people for being skeptical, for example, that discrimination is the principle cause for disparities in tech employment or the wage gap? Why is it fundamentally sexist to _merely consider_ the possibility that there are population level differences between men and women--even when those differences leave men and women equal on average (e.g., Damore)?

How can we resist racism/sexism without a basis in knowledge? And if we have that basis in knowledge, how can we verify if verification is itself racist/sexist?

Most moderates are fine with consequences for racism/sexism/etc, but we object to willfully misinterpreting one's political opponents as espousing racism/sexism/etc in order to justify their persecution. It's the weaponization of those consequences that we object to.

To your point, the left's treatment of Trudeau's blackface is an interesting case study.

> these translations are still useful as a starting point, not a destination.

This was the case for the Go compiler (automatic translation from C to Go), and it has worked out well in practice. There are still some vestiges, but it's moving more and more toward idiomatic Go all the time.

Good to know. I'll have to check them out. My ~2015 Lenovo touchpad is utterly abysmal.

If that’s true, I haven’t found it when I’ve shopped for a laptop to install Linux onto. This wasn’t always the case, but right around the time of Windows 8 when everything needed a touchscreen and chromebooks were eating the low end of the market, good affordable hardware seemingly disappeared. I would have to spend $1500 to get something in the same ballpark as an entry level MacBook and it would still have profoundly terrible touchpad (whether running Linux or Windows, it never mattered), a mediocre keyboard, a plastic body, and noisy fans.

Chromebooks do offer better hardware per dollar than other computers, but you are (or perhaps were) pretty locked-into the ChromeOS, or at least none of the workarounds seemed palatable. So if you like ChromeOS then there is better value hardware out there, but Mac is it for the rest of us.

I'm particularly interested in a world where wasm binaries replace (or supplement) containers (or even VMs?). I'm specifically imagining Kubernetes or AWS Lambda but with direct wasm execution (instead of wasm-in-container or wasm-in-VM). I'd be curious if anyone has put more thought into this and what possibilities they envision.

It matters a whole lot. There's lots of code written in various languages and it's often prohibitive to use it in your own project because making the languages speak with each other (especially if you have performance concerns) is a lot of work. I don't expect WASM to make this trivial, but to say that it doesn't matter is patently wrong.

> Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data

How does Java preclude plugins exfiltrating data?

Downvoters: I’m not trying to be sacrilegious; I genuinely don’t know the answer.

Go’s GC pauses are on a microsecond scale. If you absolutely need to minimize latency at all costs, I’d be more worried that the Go compiler doesn’t optimize as aggressively as C/C++/Rust.

> The crucial difference I point is "persist on disk" vs "do it in memory", not in the "binary representation". Both running programs and DBs have one, but one absolutely needs to be persisted on disk, whereas live program memory doesn't.

Right, I agree, and my point was it doesn’t matter. Disk vs memory is a red herring. The same principles apply to both and the fact that disk is slower applies as much to product types as it does to sum types. In fact, sum types are represented as product types, but the system enforces invariants about the structure.

> There's also the fact that it might not be a problem just an easy cop-out from the user.

That’s a nope from me. Tools exist to solve problems. If a tool purports to solve a problem but only does it halfway, it warrants criticism or observation.

> In which case it's better to force your users into the more formal and rigid structure, and have them rethink their model, than turn the DB into an "anything goes anywhere" store.

RDBMSs are literally forcing their users into a less formal structure. You can’t rethink your model and make them go away (they are fundamental data modeling primitives), you can only find ways to hack product types to represent them, but you have to do all the work to make them fast and you probably just have to give up on verifiable safety altogether.

And how do you get from “sum types” to “anything goes data store”? Are you sure you understand the debate?