interesting though, that comment directly says that if I tweet in english and my interface is in german then I'll have a serious problem. Which I wouldn't think is so rare. How many people have english as their second language and use it online? It feels like this deboost would hit a lot of people. Or actually, I have my interface in english and I often tweet in german. So that would hit me from both sides.
"One of the user's understandable language" presumably refers to the list of languages in the browser's Accept-Language header. If you are tweeting in English, you'd likely have English in that header.
It may or may not use the Accept-Language header as well, but this is a user setting accessible via the Twitter web UI-- you specify your primary interface language and can specify any number of additional languages that you understand.
There's also a place in Twitter's settings to show languages that Twitter has inferred that you know (e.g. following a German-language account and interacting with it almost certainly means that you know some German).
I also think that there is no reason to assume that AI wouldn't be intelligent enough to hide their attempts to gain more real world control. Every human hacker knows that he has to hide his computer virus but we seem to think that an AI would storm through the interwebs like rambo and start switching on missile silos.
Obviously for now all of this is impossible but lets say we do develop a human-like AI and it runs on cloud computers. Surely it has some disk access, surely it has some freedom to read and ingest new information. Even if it has no disk access, it certainly has network access. I have seen people post crazy projects where they use DNS as a storage system. I don't think it's so absurd to think that an AI finds a way to hide their progress. Why exactly can't it store shell scripts somewhere, learn and even eventually prompt users to execute some shell commands? It's hard enough to secure things against human attackers, imagine an AI that has instant knowledge of all CVEs and can generate shell code to exploit it.
I don't expect this to be fixed for another 5-10 years. I used to drag to extract files almost every single day, it's a core use for me. Simply broken now. I get nothing from Wayland, it was a net downside for me.
From what I'm reading in that bug report, the problem is that file-roller (a GNOME archiving utility) has a hokey homebrewed implementation of drag-and-drop which no longer works under Wayland. This looks like file-roller's fault, not Wayland's -- other GNOME applications have no problems with DnD.
But by definition if a company grows for decades it doesn't 'exit' (=it isn't sold or renamed or repurposed). So I think that the Mittelstand definition should prohibit an exit, maybe not for the individual (=founder/owner) but for the company as a whole. In my opinion this is why in german you don't really use the term for companies anyway except when econonomists look back and analyze your company history.
I begin to think that OP just took the word "Mittelstand" to mean "$10M-$1B", which at least to several other people in the thread is rather confusing.
I'd appreciate it if they could be more upfront about their language support and what this even does for me. Right now this is: "A better gRPC for Go". And I don't know what's better about it without doing much more research. Apparently proto3 has support for json encoding by default. So they somehow give me a better schema validation. That's their claim but I don't see how exactly they do that without going much deeper into it. Meanwhile .proto files are obviously already a schema, so they might be parsing your golang server code to see if it still matches your .proto file. That sounds very brittle to me if true.
I'm not convinced at all from this post and I don't see how this works.
Fair criticism - you're all the first people to see a lot of this writing, so we're taking notes and we'll try to make the next iteration clearer.
Right now, we've got a Go RPC library that's ready for early adopters. In a month or two, we'll have a TypeScript library for web developers. A while after that, we'll probably tackle server-side TypeScript. We're not sure what will be highest-priority after that: could be Swift + Kotlin for mobile, could be Python, could be something else.
We think that `connect-go` is a better choice than Google's gRPC implementations because it's (1) a simpler implementation, (2) interoperates better with the Go HTTP ecosystem, and (3) supports a nicer protocol _in addition to_ the gRPC and gRPC-Web protocols. You get everything that's good about gRPC, very little (hopefully none!) of what's bad, and you get some extra goodies on top. The same is true of the upcoming `connect-web` compared to `grpc-web`, and so on.
Re: JSON, you're right - proto3 defines a Protobuf-to-JSON mapping that everyone uses. What's less obvious is that if you use JSON with the gRPC protocol, you don't actually end up with JSON HTTP payloads. Instead, you get `<5 bytes of binary framing>{"some": "json"}` - which isn't all that useful, because it's no longer JSON. Then consider that gRPC doesn't use meaningful HTTP status codes, even for request-response RPCs, and it requires using HTTP trailers, and it requires HTTP/2. All of a sudden, it's not much like the ubiquitous, un-fussy HTTP APIs that make REST so successful. The `connect-go` library offers you a solution for this by supporting the Connect _protocol_, which fixes these warts.
Obviously I’m self-interested here, but it might be good to take a look at .NET 7‘a gRPC JSON transcoding as it seems like they’re trying to solve a similar problem.
You haven't really actually answered the question except for hand waving and most of it is opinions against things that exist for good reason, without justifications.
I've deployed gRPC and used the Go bindings extensively, and when I read this article I went "yes! finally!" because this directly touches on two of my chronic pain points.
The Go code it generates from .proto files are the first generated bindings I've seen that use Go generics. I always dreaded needing to look in the stock generated code, but I took a peek at the sample Connect-generated code and it's quite readable. Generics do help; a big part of the cognitive overhead for me in reading the existing bindings is how many "synthetic" types it adds that don't correspond to a named type in the .proto IDL. They have a bidirectional RPC in their example, and its generated Go method has a return type of `*BidiStream[ConverseRequest, ConverseResponse]`. In the grpc-go generated code, that would spawn a named interface type like `ElizaService_ConverseClient`. There's less to wade through.
But for me that's a "nice to have", and the big win I see is the unbundling of gRPC. What I've wanted is just a standard way to do Protobuf-defined RPC over HTTP, preferably one that the developers of API's I use have also adopted. gRPC is that, but when I've deployed it, I've deployed it within a service mesh that provides service discovery, load balancing, circuit breaking, backoff and retry behavior, etc. But gRPC clients include all of that, too, and you can't opt out. The gRPC client will think it has one subchannel open to a single service endpoint, when really it's got a localhost connection to a sidecar proxy providing transparent load balancing. I would just hope things ended up OK.
Distributed systems are complex enough, and the fewer state machines I have to internalize, the better I can understand the rest. Connect removes some of the incidental complexity from something that's meant to be a ubiquitous server-to-server protocol. I'm looking forward to TypeScript and Rust bindings being released!
The OP discusses code complexity, bugs, API instability, and incompatibility with the rest of the Go HTTP library ecosystem as issues that it’s aiming to solve.
It's the blue screen of death[1]. I guess it's paying tribute to the time when this used to be a frequent occurrence on Windows, which was contemporary to the early web. But yeah, flashing it that fast would confuse a lot of people.
Doesn't Apple forbid publishing web apps on the app store? How is it then possible that something like ionic framework and react native still work? Unless they literally translate all html features to native components but I seriously doubt it.
Edit: This is a "talk to sales" framework and ionic is 50€ per month as the absolute cheapest option. This is essentially an ad then.
It wasn't only games, but having been there the cambrian explosion following the appstore's release was very much 95% games (much to Jobs' dismay).
> WebOS’s apps were as good as any other platforms apps and were PWAs unless I’m mistaken.
They were built out of "web technologies" (HTML and javascript) but they were not PWAs as they were significantly augmented with native components and concepts, none of which were part of the browser (even as proprietary extensions). That's like calling Firefox a PWA because it's built out of XML and Javascript (or was, not sure that's still the case).
iOS' first draft (pre appstore) was pretty much just web pages you pinned to your springboard (which you can still do). There were a few allowances for removing browser chrome and the like, or providing a few icons, but for the most part it was exactly what you'd run in a browser.
I think it also feels off because you generally drink coffee to get more work done and stay alert. Especially while you are at work. So it's the strangest place to start saving money at.
Interesting site, this might be the first example of neo/brutalism that I like a little. It feels somehow fresh and clean like an interactive piece of glossy magazine paper. Somewhere else somebody posted this site which I would qualify as typical brutalism which is terrible from pretty much all viewpoints: https://secretgeek.github.io/html_wysiwyg/html.html
Yes i was suprised also by the design of the kruidvat website, it refreshing. Kruidvat also is known for cheap stuff so i think part of the “cheapness” of the design is well intentional.
