Solarsail
Your fastest open-cycle resource usage is water. If you can recycle your water, you've got much slower mass-growth per unit of time in free flight. This could make the difference between 8 hour spacewalk capabilities and 8 day spacewalks.
Pegasus (company's first try overall), Antares, all of the Minotaurs, Atlas 3 and 5 might count as new... Epsilon, H-2 (new?), Vega, Ariane 1, 3 & 4... And the Ariane 1 is both totally new on a systems level and an institution's first attempt at building one. Long March 5, 6 & 7.
Of the investor-backed launch startups, I think it's either no company got it first try... or Orbital Sciences counts as making it first try with Pegasus. Not sure if they count as an investor backed startup.
Almost any reminder that people are having conversations there (especially politics / social commentary)... or forming thought about the world there, makes me fear humanity.
Basically I just keep it around since some (like here on HN) think that it's valuable to prove you exist using an established account.
...I might outright have an alternate history of the entire '10s "Culture War". Or I might have gone paranoid. Of course I can't prove any of it. I'd love an answer to your first question myself.
Were either of these two the ones you were thinking of?
The UK's NNL prototyped out a process for volume manufacture of Am-241 in 2013. http://www.nnl.co.uk/news-media-centre/news-archive/space-ba... And a few notes about the Americium-RTG effort more generally: http://www.planetary.org/blogs/guest-blogs/2015/0423-can-a-n...
NASA has also studied use of solar power beyond Jupiter's orbit: (PDF link) https://www.lpi.usra.edu/opag/nov_2007_meeting/presentations...
(Edit: Fixed a link)
(Apologies if this is me-too ism)
Discussed here, for example: https://news.ycombinator.com/item?id=9297665
Ivan Goddard's descriptions of the branch predictor sounds quite simple that I can remember; The predictor itself is completely detached from the compiler, outside of the instruction layout falling into EBBs. A point that (I think is on the Mill forum somewhere) they've said about the prediction algorithim itself, is that they're doing simulations with nearly the simplest known prediction algorithm, and getting something like 90% success rates from that compared to the 98% the state-of-the-art sees. The difference is entirely in what data is carried by the prediction. (I believe this is in the forum thread on Switch statements, referenced in this video) What the predictor stores and delivers as output is the logical equivalent to an instruction pointer, and where in the EBB they exit, instead of a boolean (or an entire exit table). Which is more state, but not replacing the entire state of the processor. And, as explained in this presentation, the impact of having (effectively) an instruction pointer from the branch predictor is you know what to prefetch from memory. And that pointer, being associated with some other EBB that the predictor might know about, is also enough to ask the predictor for the next prediction, get a second prefetch, and so on.
That also has implications to a point Goddard made in this presentation, in that some entire Switch statements have only one "EBB" (although that's loose terminology itself), and thus only one prediction associated with it. The prediction is to where the block will exit, not whether any specific prediction will succeed, thus there is no case where the processor will stall multiple times before finding the correct control flow. It can only fail once before it determines the correct exit to the block (in general, at least...)
Which is I believe how they are expecting good results, rather than anything peculiar about how they determine the prediction from history.
Edit: I suppose I could note, some of the Youtube personalities who (I have heard) supported the movement are currently staunchly anti-feminist. I'm not certain how central they were to the movement at the time, but they may be relevant to the comments others have made involving the impact of the group.
If we assume some sort of object orientation, or first class functions are available, affine types become (I think) impossible; If a value T with lifetime 'a is handed to a completely unknown method on an unknown object, or to an arbitrary lambda, we can't prove that the method will not destroy T in the middle of lifetime 'a. In otherwords, if typechecking is ruled out, we cannot do borrowchecking either.
This tread for example, talks about instruction density of Mill programs. Mill does somewhat poorly, with a pre-alpha quality compiler doing the codegen; https://groups.google.com/forum/#!topic/comp.arch/RY3Bk7O61u...
Comparing several ISAs on the simple program in the first post, a Mill Gold CPU binary weighs in at 337 bytes (and 33 instructions), compared to:
* powerpc: 212 bytes, 53 instructions * aarch64: 204 bytes, 51 instructions * arm: 176 bytes, 44 instructions * x86_64: 135 bytes, 49 instructions * i386: 130 bytes, 55 instructions * thumb2: 120 bytes, 51 instructions * thumb: 112 bytes, 56 instructions
Note: I've tried to use scriptcs, but the extent of my C# knowledge consists of pretending it's Java. But people do seem to compare it to LINQPad, so maybe it fits.
Some other anti-PC things, like use of the term "black people" in preference to "people of color" or "african-americans"; Or describing men and women in drastically different terms, or painting them as inevitably vastly different (to avoid papering over the differences or making them look non-existent) are their own kind of cultural sensitivity. Or in some cases, even a similar sort of language policing that has long been attributed to political-correctness, just on avoiding terms that people view as originating from it.
I tried building a compiler for one particular computer, the RedGame 2. Which in practice meant an assembler + installer, lol. Somebody else also built an emulator and the other assembler for that computer. Also remember Ohm's computer, a 16-bit machine which was... practically vertical. There were lanes for 16 bits side by side, all of the ALU functions were stacked one above the other, and all of the registers were likewise stacked beside the ALU. It also had an assembler, and an emulator (in Bash, IIRC).
Among the interesting / odd things about Redstone computers, is just how slow signals propagate down wires compared to the gate speed. By in large, small is the only form of speed. That, and small is kindof necessary, via the sheer space constraints imposed by being inside a game. The one 64 bit ALU I saw once... was sufficiently wide that you had to stand close to the middle to keep the entire thing in simulation range. Corollary to that, is the low speeds can make the operation of the chip substantially intuitive. With the RedGame 2, a few times I would try to follow ROM reads, instruction decode, register reads, ALU ops, and right back to the condition in time to select the next instruction. That was a bit of an oddity of the RedGame, every instruction contained a conditional branch. You would use... 2 or 3 bits as an operand for what condition to check, list out two (!) instruction numbers to branch to on true/false.
I've (much more) recently mulled over building my own CPU, tho it'd be a couple months worth of work. Most recent sketch was of something of a Mill-alike. It'd be an 8-bit, with 8 belt positions, one ALU, 12 bit instructions with ~30 ops available, and maybe 128 program instructions in ROM. Not sure I could actually fit any RAM, tho... With RAM being positively huge, and any mildly compact part-analog storage taking around 5-10 seconds per read. I'm also not sure something so small it can only fit one ALU really benefits from a belt architecture, rather than a 3-operand register machine. For that matter, most Redstone computers use quite wide program ROMs instead of a Von Neumann architecture, so instruction bits are practically the cheapest part of these computers.
Not sure if that's more informative than making a more-capable ISA and writing an emulator in C.