EdiX

> Sound like a typical Rob Pike design

It's actually from APL.

The funny thing is that stalling is probably enough to pay less. He's partially financing the operation by selling tesla stocks, if the market goes back up and takes tesla stock price up with it then buying twitter will cost less money.

My opinion is this is just a stalling tactic, he thinks the market will recover by next year and this is a pretext to wait until then.

> it seems like an unfortunate accident that some of these languages must have not had much printing press and typewriter use

it wasn't an accident, the printing press was banned by the ottoman empire in 1485.

Twitter has operated for 16 years and public for about 10, explosive growth of their userbase is in their past and monetization strategies have already been implemented for years. There is no reason to believe it has the potential for such growth.

This will not compile because the type of the variable is int not Test.

> I find that surprising that Go did not use registers for its (internal) calling convention until 1.17. And I also find it surprising that they only expected a 5% boost from it.

It's because there's no difference for a normal non-leaf function between a stack calling convention and a register calling convention. If 'f' is a non-leaf function either the caller of 'f' will have to put f's arguments onto the stack (stack calling convention) or 'f' will have to save its argument registers onto the stack before doing its calls (register calling convention).

Register calling conventions end up being a big win if you have lots of non-leaf functions that can forward their arguments (rare) or lots of leaf functions that can't be inlined (also rare). Some programs will get a big boost out of it but most will only get a small one.

Sad to be doing that on the same week that a BLM terrorist killed 5 people with a car.

I think that's the famous blogpost that eventually led to the event-stream malware.

Maybe?

First off, how much of this is going to wikipedia editors and how much is going to other stuff? Honest question, I tried looking and I couldn't figure out which grants actually get approved.

Secondly, the number of editors peaked in 2007, as far as I know. Why does the money spent on grants and awards keep going up if the number of editors keeps going down?

How about the 20 million they spend on awards and grants? It doubled between 2019 and 2020, isn't it weird that they spend 10x as much in awards and grants than they spend on hosting everything?

From the same data scientist that concluded non-linear growth from two single data points...

> 20% of the world speaks Mandarin Chinese (not all as a first language tho). And, about the same % as speak English natively, speak Hindi (+ dialects) natively, and again about the same amount speak Arabic, and again about the same amount (all above 300 million) speak French, tho a greater % of those have le français as an nth language.

What are your sources for this because cross checking with wikipedia, which uses Ethnologue as a source, I find several discrepancies. For example the number of people who speak french isn't "the same amount" as native english speakers, it's 53% and that's if you include 2nd language speakers. You make it sound like Hindi and English are comparable but Hindi has very few 2nd language speakers.

In fact looking at [1] the choice of english looks a lot more logical than I would have thought.

[1] https://en.wikipedia.org/wiki/List_of_languages_by_total_num...

This story was told before many times but what I thought was interesting is that this actually tells us the name of the diner where UTF-8 was invented, which still exists today under a different name:

https://goo.gl/maps/d2Ps6WUNESFVtDuj6

Now anyone who wants to take a pilgrimage to the birthplace of UTF-8 can.

Broadly speaking, I agree with you. I was responding to the hysteria about the trim wheel in this thread. I'm getting the impression that some users think the trim wheel, or its behavior under extreme aerodynamic conditions, is a "new" design flaw unique to the 737 MAX when in fact almost every airliner in existence has a trim wheel behaves like that.

The exception being modern fly-by-wire planes that simply don't have an option of manual override.

    The speaker talks about trimwheel behaviour. Pilots train for runaway stabilizer trim, but that's continuous movement of the trimwheel, faulty MCAS looks much like regular speedtrim

Empirically, the Lion Air plane exhibited the same MCAS behavior on its last (successful) flight. So it's at least possible for pilots to recognize it as a runaway trim and act accordingly.

    Obviously you shouldn't take Lion Air, but after this talk Boeing doesn't look safe now either. 

After reading the Lion Air report my conclusion is that the MCAS was poorly designed but it's also an easily fixed problem on an otherwise safe design and there's so much focus on boeing that they will take action and fix it. Meanwhile nobody cares about Lion Air and if they keep flying broken airplanes eventually they're going to kill more people, with or without MCAS.

> The planes are already unmanageable, even if MCAS is fixed: human pilots aren't strong enough to turn the trim wheels manually in an emergency.

Operation of the trim wheel and the forces acting on it are the same as the 737 NG. If this worries you, you shouldn't take any 737.

The wheel in that video can not be turned manually because of the aerodynamic forces acting on it. Pilots are trained extensively to recognize a runaway trim condition and stop it before it gets to that point. At lower angles a roller coaster maneuver can be used to turn the trim manually.

The MCAS was definitely poorly designed but everyone is downplaying the poor pilot response and maintenance issues involved with the crash. Lion Air pilots flew a plane with a stall warning going on for a full hour instead of landing ASAP. Then when the plane got to the ground, the company saw it fit to fill it up with people again and fly it with a critical system malfunctioning due to unknown causes.

They dodged responsibility because boeing had a serious design issue but their behavior was criminal, even more so than boeing. I wouldn't fly any lion air plane.

The trim wheel is the same as in every other 737, and it's one of the safest airplane types ever built.

None of this is true. His "rant" was a well researched memo with extensive links to state of the art research. You should actually read the real thing, once, instead of the maimed version published by the guardian.

But honestly it's better if you don't know, you're better adjusted to living in this world by remaining ignorant. Just keep reading Vox.

Why is John Gruber reprinting anonymous emails that are clearly lying? Richard Stallman was never married so he never had an "open marriage" either. Given that the person writing the email didn't even bother to verify this easily verified detail I suspect the rest is also a work of fiction.

> I don't get it. A linker's task should be straightforward.

In Go the linker also generates DWARF, does deadcode elimination and a bunch of other stuff described in the associated document.

> And how can it be that a binary called "cmd/compile" has 170k symbols (that's like, global definitions, right?). Not that that's a huge number in terms of today's computing power, but how many millions of lines of source code does that correspond to?

As described in the link each global function actually ends up producing 4 symbols.

> Shouldn't 1 or 2 secs be sufficient?

On my system linking cmd/compile takes 1.3 seconds. The problem is that object files get cached so if you have a hot cache (let's say you made a few changes inside a single package and then recompile) compiling takes almost no time and linking accounts for nearly 100% of the build time.

> Kennedy

Glad to finally know that cancer actually has a name. Kennedy made me stop using Google Reader and the GMail web UI.

I think the cave and torch metaphor is underselling me on my editor's ability to have split windows.

The sad part is that it's not better in the app. I tried it.

If I didn't make any mistakes 20 quadrillions are equivalent to 20000 TFLOPS. Wikipedia says you can get 12 TFLOPS with a high end graphics card for 1200$. 4000$ inflation adjusted is 6000$ which means you can get 5 of those for a total of 60TFLOPS which means he's off by a factor of 300. If you used CPUs instead (which is probably what he meant at the time) you can get 225 GOPS (integer operations, not floating point) for 374$ with a Core i7-9700K (source: wikipedia). With 6000$ you buy 16 of those for a total of 3.6 amazing TOPS, which makes Ray off by a factor of 5000.

You check out the dependency you want to change and add a replace directive in go.mod. Either a temporary one to a file system path or a permanent one to a forked repository.

> Why are vendor directories a bad habit ?

They aren't, not having them is.

> Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that.

This is not true. If you pass -mod=vendor, or place it in $GOFLAGS, go will build something outside of GOPATH, in module mode, using the vendor directory exclusively. I wish it was the default, but only because it encourages people to not use vendor directories (which is a bad habit), not because it can't be worked around easily.

What makes this the first "True" Word Processor? Looking things up on Wikipedia I find that IBM's Expensive Typewriter, a computer program for the PDP-1, existed in 1961, several years before the Redactron Data Secretary. Both the IBM Expensive Typewrite and the Redactron Data Secretary used an IBM Selectric as input/output device.

Almost contemporary to the Redactron Data Secretary was the vastly more advanced NLS (from Engelbart's demo) which used a CRT for output and keyboard and mouse for input. The mother of all demos was given in december 1968, I couldn't find the exact date that Redactron was incorporated but the interview of Berezin by CHM gives it as "the end of 1968".

The Data Secretary might have been the first successful Word Processor but it appears that it's hardly the first one, but claiming that "Without Ms. Berezin there would be no Bill Gates, no Steve Jobs, no internet, no word processors, no spreadsheets; nothing that remotely connects business with the 21st century." seems incredibly hyperbolic.

I hate that every time I hear "first person to do X was a woman" I'm immediately skeptical because, if I look into it, most of the time is at minimum using a bunch of misleading definitions.

>This is said every single time when "JIT" is mentioned but I've never heard an argument how that might be possible

I'll explain it but you have to pretend that we are in the 90s, so before you continue reading click on this link:

https://www.youtube.com/watch?v=_JphDdGV2TU

"Modern" CPUs achieve some of their speed by executing multiple instructions in parallel, using a pipeline: the first stage fetches an instruction from memory, hands it to the second stage that decodes it but while the decoding is taking place the first stage will have already started fetching the next instruction from memory. Conditional jump instructions of course ruin everything, because you need to know the result of their evaluation, before you can decide which instruction is the "next" one.

"Modern" CPUs work around this by always assuming that the jump is never taken and then, if it turns out that the jump does get taken, rolling back the partial work that they did.

As it turns out the vast majority of conditional jumps in a program always go the same way, i.e. any given conditional jump is either always taken or never taken. If the compiler knew which way the condition went it would be possible to lay out the program in a way that jumps are almost never taken, for maximum performance.

A static compiler can't do this but with a JIT you can run the program in bytecode a bunch of times and then use the information you gathered to lay it out in the best way possible.

All that I've said is 100% true and empirically verifiable. The reason this didn't work out is that in the early-2000s all x86 CPU manufacturer started adding this specific optimization directly inside the CPU. They started keeping branch counters and using them to guess which way conditional jumps were more likely to go.

There's other optimizations that a JIT compiler can do and a static compiler can't, but the story is similar. Big x86 manufacturers can do almost anything a JIT compiler can do and that's why the technology is essentially obsolete.

There's still some value in distributing a single binary that executes at near-native speed everywhere, but that's basically it.

This is amazing. Not even their own examples work. I tried "blocks until the server has shut down", which they suggested, and it gave me 3 results, none of which were code blocking until the server shut down.

I'm surprised they are showcasing a feature that works this poorly and I'm not looking forward to having github search return results that are even less relevant to my query than they are now.

I can think of 10 features, off the top of my head, to add to github search that would make it unambiguously better, none of them is training a deep learning neural network to find things when I'm not sure what I'm looking for.

How about implementing ctags/cscope? How about when I click on a result opening it in a new window by default? How about highlighting all the matches when I open a file?

And that's not even getting into parts of github that actually matter, like the PR review interface.

I guess this must be it. IRC could in theory do everything Slack does but setting up a server is a pain and shiny clients are rare...

I wonder about the rest of the competition, for a while everybody was using hipchat, I never used it myself, I wonder why nobody talks about it anymore.