dullgiulio

> But it's not going to be Unix as we know it.

Right, that's Plan9.

No shortcuts.

Errors reach end users, and they cannot read stack traces.

Every shortcut makes for bad errors, bad troubleshooting and unhappy users.

Errors document code (you literally write, in English, what you were trying to do but failed, at each level of your program.)

Errors report to the user the clear intent that failed and why.

Errors are a huge differentiator in quality. There is no shortcut to quality.

Please no. I am still fighting the battle of adding contextual information to the error using fmt.Errorf.

I am tired of seeing

SocketException: hostname.com

as full error message.

Readable but not comprehensible. CSV is hard to beat in that sense, being somewhat "natural" like a table written on paper.

No, a normal light switch on the wall is all you need.

No, it failed because it acts on the wrong side. If you don't want to be tracked you shouldn't send cookies in your request.

This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features.

Google does have a problem with management and the org-chart, but not the way you think.

Most probably all these names just indicate market day...

That's the Go runtime.

You have to implement UnmarshalJSON. Between each attempt to deserialize into a possible struct, be careful to return on errors that are not JSON serialisation errors (for example caused by reading from the underlying Reader, etc.)

It's ugly and verbose but there is no need to use empty interface.

No, that SIMD is good for string matching and Rust regex crate (written by burntsushi for 'ripgrep') makes very good use of it and is thus a nice library for implementing quick matchers.

And is Go so hard to upgrade for your application?

Go the language is really best in class when it comes to keeping backwards compatibility.

Redirection is not a parameter, meaning that would still not work with this Q tool.

Another reason for people trying too look overly confident is when they are overly exposed over a certain topic.

For example, if you have very narrow job titles and roles in a team ("he is our DevOps, she is our architect"...) everyone will have to defend their role, often trying to sound infallible.

If instead you make the whole team responsible for all team tasks, everyone will be more open to leveraging everyone else's suggestions.

Tangentially, the adage "strong opinions, weakly held" is nonsense. If you have a strong opinion, you look like a fool if you change your mind when evidence is shown to you.

It is much better to just stay humble. Show your insecurities and lack of knowledge openly and early, you'll be surprised to see how people reactions change from hostile/confrontational to outright helpful.

I really cannot agree with the "just use GET" suggestion. GET must not be used for actions that modify the data server-side. Also, POST and PUT means some action is or is not idempotent.

Using different methods than GET is easy in the browser (easier than JSON-P) and avoids a huge class of problems that come with abusing GET.

Correct, "per difetto" means flooring a number.

I have been using double tap to select (and simply drag) on Linux for years, never had to click. And my touchpad is far from magic...

Again, disabling features is a feature given to the site developer, not to the visitor, who's actually running the code.

It would be so much better if browsers were User Agents and respected user settings before the will of the site creator.

Languages that to green threads don't do them for memory savings, but to save on context switches when a thread is blocked and cannot run. System threads are scheduled by the OS, green threads my the language runtime, which saves a context switch.

That sentence is very misleading. Nobody checks the Close() error because the right thing to do is to call Err() like with the text.Scanner.

I suspect the right github code search would reveal way less buggy code.

https://golang.org/pkg/database/sql/#Rows.Err

salsa20 was added in 2012, the warning file was added into the repository in 2016 the earliest (it is not clear when--which is vary bad for security and also shows the move was not advertised.)

Incompetence is a strong word on the wrong target...

Of course it is up to the application to decide case-by-case.

Just keep in mind that if your query is started by a user request, but does not need to terminate in the context of the user request that triggered it, you can move the query to a separate goroutine and decouple it completely from the triggering user request.

Also, aborting a query is safe: the transaction gets rolled back, removing unwanted side effects. You cannot do harm by cancelling, bu you can do harm if you don't cancel.

Perl# basically.

Nope, this is a strawman argument you're making.

Parent is asking for granular access control over these very advanced and double-edged features, which is a perfectly valid request.

Having permissions is the norm for native apps on mobile, and it's slowly becoming the norm also on desktop, finally.

Browsers are the new OS, they have to implement permissions too without anything enabled by default.

It's not "they", it's Daniel J. Bernstein. That's the reason :)

(If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)

Go follows the Plan9 system call name instead of the UNIX one. Dial is much more powerful than the UNIX dance of "getaddrinfo"+struct sockaddr init+connect(2).

It might not seem much (and higher level languages usually abstract away the craziness that UNIX sockets are in C), but that's what the OS still gives you in 2020...

Go does not have exception (exactly because of this problem.)

For passing information, you use channels, which can pass more than one value back to the caller.

The big thing is not running tasks in the background but the tight integration of channels and runtime scheduler that allows having an invisible event loop on top of what is synchronous programming.

I don't think this is a matter of hype cycle at all. There are two things that changed:

1. Threading got much faster and lightweight. This is what Java was initially trying to work around, until it didn't have to any more.

2. The problem moved to handling as many sockets concurrently as possible. Even lightweight system threads are too heavy for scaling linearly with the number of connections (too much context-switching overhead, too much space for stack, etc.)

Green-threading has become a good idea again because we now have a kernel API that is used to multiplex a lot (but not all) I/O systemcalls.

Today Go runtime uses epoll/kqueue to read from a big bunch of sockets, whenever something new happens to any of them. This takes one system thread only.

The API model of epoll/kqueue implies some way to handle concurrency in your user code: this can either be callbacks (or async/await syntactic sugar) or green threads and CSP (channels and so on.) This is why green threading is having a comeback.

(Sorry for implying you did not read the article!)

As the article explains (I know it's hard to comment after actually reading), Java moved away from using several green threads on top of a single system thread.

What Loom and Go do is to schedule green threads on a bunch of system threads and spawn more system threads when they get blocked doing synchronous system calls.