UE5's rendering approach. They finally figured out how to use the GPU to do level of detail. Games can now climb out of the Uncanny Valley.

The Playstation 5. 8 CPUs at 3.2GHz each, 24GB of RAM, 14 teraflops of GPU, and a big solid state disk. That's a lot of compute engine for $400. Somebody will probably make supercomputers out of rooms full of those.

C++ getting serious about safety. Buffer overflows and bad pointers should have been eliminated decades ago. We've known how for a long time.

Electric cars taking over. The Ford F-150 and the Jeep Wrangler are coming out in all-electric forms. That covers much of the macho market. And the electrics will out-accelerate the gas cars without even trying hard.

Utility scale battery storage. It works and is getting cheaper. Wind plus storage plus megavolt DC transmission, and you can generate power in the US's wind belt (the Texas panhandle north to Canada) and transmit it to the entire US west of the Mississippi.

Still don't see fully (fully automated) self driving cars happening any time soon:

1) Heavy steel boxes running at high speed in built up areas will be the very last thing that we trust to robots. There are so many other things that will be automated first. Its reasonable to assume that we will see fully automated trains before fully automated cars.

2) Although a lot is being made of the incremental improvements to self-driving software, there is a lot of research about the danger of part-time autopilot. Autopilot in aircraft generally works well until it encounters an emergency, in which case a pilot has to go from daydreaming/eating/doing-something-else to dealing with catastrophy in a matter of microseconds. Full automation or no automation is often safer.

3) The unresolved/unresolvable issue of liability in an accident: is it the owner or the AI who is at fault.

4) The various "easy" problems that remain somewhat hard for driving AI to solve in a consistent way. Large stationary objects on motorways, small kids running into the road, cyclists, etc.

5) The legislative issues: at some point legislators have to say "self driving cars are now allowed", and create good governance around this. The general non-car-buying public has to get on board. These are non-trivial issues.

My alternative possible timeline interpretation is that two forces collide and make self-driving inevitable.

The first force is the insurance industry. It's really hard to argue that humans are more fallible than even today's self-driving setups, and at some point the underwriters will take note and start premium-blasting human drivers into the history books.

The second force is the power of numbers; as more and more self-driving cars come online, it becomes more and more practical to connect them together into a giant mesh network that can cooperate to share the roads and alert each other to dangers. Today's self-driving cars are cowboy loners that don't play well with others. This will evolve, especially with the 5G rollout.

1) Teslas crash much less often, mostly due to autopilot.

2) Tesla can harvest an incredible amount of data from one of their cars and so they can calculate risk better

Does Tesla see when you speed and increase your premiums?

I want to understand why being in a high-speed steel/plastic box with humans (overrated in some views) controlled by a computer scares you so much. Is it primal or are you working off data I do not have? Please share. I am being 100% sincere - I need to understand your perspective.

To re-state in brief: (individual) autonomous self-driving tech today tests "as safe as" ranging to "2-10x safer" than a typical human driver. This statistic will likely improve reliably over the next 5-10 years.

However, I am talking about an entire societal mesh network infrastructure of cars, communicating in real-time with each other and making decisions as a hive. As the ratio flips quickly from humans to machines, I absolutely belive that you would have to be quantifiably unsane to want to continue endangering the lives of yourself, your loved ones and the people in your community by continuing to believe that you have more eyes, better reaction and can see further ahead than a mesh of AIs that are constantly improving.

So yeah... I don't understand your skepticism. Help me.

Look: I don't want my loved ones in the car that gets hacked, and I'm not volunteering yours, either. Sad things are sad, but progress is inevitable and I refuse to live in fear of something scary possibly happening.

It is with that logic that I can fly on planes, ride my bike, deposit my money in banks, have sex, try new foods and generally support Enlightenment ideals.

I would rather trust a mesh of cars than obsess over the interior design of a bunker.

If all the cars in the area know one of the cars is about to do something and can adjust accordingly then it will be so much safer than what we have now it is almost unimaginable.

It would seem at some point in the future, people are not going to even want to be on the road with a human driver who is not part of the network.

In 2017 AlphaGo could probably give a world champion somewhere between 1 and 3 stones.

From an algorithmic perspective the range between "unacceptably bad" and superhuman doesn't have to be all that wide and it isn't exactly possible to judge until the benefit of hindsight is available and it is clear who had what technology available. 15-20 years is realistic because of the embarrassingly slow rate of progress by regulators, but we should all feel bad about that.

We should be swapping blobs of meat designed for a world of <10kmph for systems that are actually designed to move quickly safely. I've lost more friends to car accidents than any other cause - there needs to be some acknowledgment that humans are statistically unsafe drivers.

I can drive myself home relatively safely in conditions where the computer can’t even find the road. We’re still infinitly more flexible and adaptable than computers.

It will be at least 20 years before my car will drive me home on a leaf or snow covered road. Should I drive on those roads? Most likely not, but my brain, designed for <10 km/h speeds, will cope with the conditions in the vast majority of cases.

https://en.wikipedia.org/wiki/Paris_M%C3%A9tro_Line_14

Fully automated since 1998, and very successful.

I am optimistic about solving those problems. Regulation always comes after the tech is invented. Cars have more opportunity to fail gracefully in an emergency; pull off onto the shoulder and coast to a stop or bump into an inaminate object.

I have driven in snow a few times that I was not sure I was even on the road. Or the only way I knew I was going the right direction was because I could vaguely see the break lights of the car going 15mph in front of me through snow.

That is an easy problem to solve though because I simply should not have been driving in that.

If/when we get fully automated cars, this kind of driverless Uber will become extremely common. Who bears the risk then? This is a complicated situation that can't be boiled down to "Of course the owner is to blame"

Not so in car-sharing pools, and there it's already materializing as a problem. How do you solve that with your 'robo-cab'? Tapping on dirty/smelly in your app, send back to garage? What if you notice it only 5 minutes after you started the trip, already robo-riding along? What if you have allergies against something the former customer had on/around it? Or was so high on opioids, that even a touch of the skin could make you drop? As can, and did happen. How do you solve for that without massive privacy intrusions? Or will they be the "new normal" because of all that Covid-19 trace app crap?

To go contrary to this is to invite outright bans of the tech.

Mmm, this sounds like exactly what people said at the time the PS3 was going to be released, and I can only recall of one example where the PS3 was ever used in a cluster and that probably was not that very useful in the end.

The PS5 and Xbox One X are commodity PC hardware, optimized for gaming, packaged with a curated App Store.

Sony also won’t just sell you hundreds or thousands of them for some kind of groundbreakingly cheap cluster. They will say no, unless you’re GameStop or Walmart.

Everyone with a high-mid-range PC already has more horsepower than a PS5 and it’s not doing anything particularly innovative or groundbreaking.

The PS5 is going to equivalent to a mid-range $100 AMD CPU, something not as good as an RTX 2080 or maybe even an RTX 2070, and a commodity NVME SSD (Probably cheap stuff like QLC) that would retail for about the same price as a 1TB 2.5” mechanical hard drive. It is not unique.

Data center servers optimize for entirely different criteria and game consoles do not make sense for anything coming close to that sort of thing. For example, servers optimize for 24/7 use and high density. The PS4 doesn’t fit in a 1U rack. It doesn’t have redundant power. Any cost savings on purchase price is wasted on paying your data center for the real estate, no joke. Then when the console breaks you have to pay your technician $100/hour in compensation, benefits, and taxes to remove and replace it.

An 8 core 2nd generation Zen chip appears to retail for $290. The PS5 reportedly has a custom GPU design, but for comparison a Radeon 5000 series card with equivalent CU count (36) currently retails for $270 minimum. Also, that GPU only has 6GB GDDR6 (other variants have 8GB) but the PS5 is supposed to have 16GB. And we still haven't gotten to the SSD, PSU, or enclosure.

Of course it's not supposed to hit the market until the end of the year - perhaps prices will have fallen somewhat by then? (Also I don't expect Sony to be making any money off the hardware at those prices, so I agree that they're unlikely to sell them to anyone who won't buy games for them.)

I haven't looked at what a GPU equivalent would be, but by the time PS5 hits the market, I doubt going to be anywhere near 270$.

As long as there aren't any supply chain disruptions (as there are now).

It appears that the real killer is the hardware-accelerated decompression block pulling the data straight from SSD into CPU/GPU memory in the exact right location/format without any overhead, which isn't available on commodity PC hardware at the moment.

I found some historical price data and I'm surprised - the 2700 really was $150 back in January! Vendors are price gouging the old ones now, and the 3700X is currently $295 on Newegg.

As far as the GPU goes, an 8GB from the 500 series (only 32 CU, released 2017) is still at least $140 today. And noting the memory again, that's 8GB GDDR5 versus (reportedly) 16GB GDDR6 so I'm skeptical the price will fall all that much relative to the 6GB card I mentioned.

I think console hardware cost is generally budgeted at a slight loss (or close to break-even) at the beginning of a console generation, and then drops over the ~7 year lifespan.

The fact that it can stream 5.5gb/s from disk to RAM says otherwise. Commodity hardware, even high end m.2 drives can’t match that.

* it’s my understanding that it directly shares RAM between the CPU and the GPU which means way less latency and more throughput.

I would sure like to see some architectural upgrades like this in PC/server world though: I’d love an ML workstation where my CPU-GPU ram is shared and I can stream datasets directly into RAM at frankly outrageous speeds. That would make so many things so much easier.

No, you pay your minimum wage junior IT assistant to unplug the broken one and plug in a new one. That's the point of commodity hardware - it's cheaper to buy and cheaper to support.

GTA 6 with the hardware in the new consoles will likely be spectacular.

There was significant interest in grid scholar community.

https://en.wikipedia.org/wiki/PlayStation_3_cluster

The only reason that stopped happening was because Sony killed it on purpose:

> On March 28, 2010, Sony announced it would be disabling the ability to run other operating systems with the v3.21 update due to security concerns about OtherOS. This update would not affect any existing supercomputing clusters, due to the fact that they are not connected to PSN and would not be forced to update. However, it would make replacing the individual consoles that compose the clusters very difficult if not impossible, since any newer models with the v3.21 or higher would not support Linux installation directly. This caused the end of the PS3's common use for clustered computing, though there are projects like "The Condor" that were still being created with older PS3 units, and have come online after the April 1, 2010 update was released.

And in case you were wondering, the reason Sony killed was because they sell their consoles at a loss and make up for that through game sales (which indirectly is what made it so affordable for people interested in cluster computing). If the PS3 is merely bought for creating cluster computers they would end up with a net loss (Nintendo is the only console maker that sells consoles at a profit)

Is that the new marketing term for shared VRAM?

And if by “learned”, you also mean “were convinced by Mark Cerny“ (who is still leading design of the PS5), then also yes.

That seems like a straight waste of time for lightly customised hardware you'll be able to get off the shelf. And unless they've changed since, the specs you quote don't match the official reveal of 16GB and 10 teraflop. Not to mention the price hasn't been announced, the $400 pricepoint is a complete guess (and pretty weird given the XbX is guessed for 50% more… for a very similar machine).

The crowd that use C++ needs raw pointers sometimes, and you can't really prevent bad pointers and buffer overflows when they are used. There is a reason why Rust, which goal is to be a safer C/C++, supports unsafe code.

Smart pointers is a very good thing to have in the C++ toolbox, but they are not for every programmer. Game programmers, if I am not mistaken, tend to avoid them, as well as other features that make things happen between the lines, like RAII and exceptions.

The good thing about that messiness that is modern C++ is that everything is here, but you can pick what you want. If you write C++ code that looks like C, it will run like C, but if you don't want to see a single pointer, you have that option too.

https://web.archive.org/web/20041120084657/http://arrakis.nc...

Would love some links to read over weekend. Thanks!

- std::string_view

- std::span

- std::unique_ptr

- std::shared_ptr

- std::weak_ptr (non owning reference to shared_ptr, knows when the parent is free'd)

- ranges

- move semantics

- move capture in lambdas

- std::variant

- std::optional

To be honest, learning rust has made me a better c++ programmer as well. Having to really think about lifetimes and ownership from an API perspective has been really neat. It's not so much that I wasn't concerned about it before, more that I strive to be more expressive of these conditions in code.

However I feel like most of the heavy lifting features came with C++11. Span, optional, variant and string_view are nice additions to the toolkit but more as enhancements rather than the paradigm shift of C++11 (move, unique_ptr, lambdas et-al).

It's funny, because while it's certainly become more influential lately, that subculture existed as a niche in the C++ world before Rust and before C++11. So much so that when I first heard about Rust I thought "these are C++ people."

"string_view" is a borrow of a slice of a string. Since C++ doesn't have a borrow checker, it's possible to have a dangling string_view if the string_view outlives the underlying string. This is a memory safety error.

Rust has educated people to recognize this situation. Now it's standard terminology to refer to this as a borrow, which helps. Attempting to retrofit Rust concepts to C++ is helping, but often they're cosmetic, because they say the right thing, but aren't checked. However, saying the right thing makes it possible to do more and more static checking.

Sure C++ doesnt have a borrow checker but these types encourage the idea of "reifying" lack of ownership rather than keeping it ad hoc

Unfortunately there is no string view, so you need to copy the substrings or use pointers/indices. I tried to build a string view, but the freepascal compiler is not smart enough to keep a struct of 2 elements in registers.

So excited for this as a PC gamer, hardware prices are going to have to plummet. I don't think supercomputers a likely, the PS2 was a candidate because there was [initially] official support for installing Linux on the thing. Sony terminated that support and I really can't imagine them reintroducing it for the PS5.

They have zero incentive to subsidize supercomputers. They're in the business of trading hardware for royalty, store, and subscription payments.

A cynic would say they wanted to boost sales on newer displays, but it seems more likely that a bug of some kind came up in a driver (I was unaware of any problems, but that's hardly proof of anything) and they just decided it was easier to cut support of those displays than to fix the problem.

Support forums filled with complaints by the dozens of pages, but Sony didn't care, because why should they? I'm sure somebody did the calculation that said we weren't a big enough demographic to matter.

Anyway you can jailbreak ps4 to 5.0.5 firmware and there are unpublished exploits in existence that are waiting for ps5 to be released.

I am running home server (100% self hosted including emails) with J1900-itx motherboard with 20Tb of disk space (zraid) for years. No need to bother with ps4/5.

Jailbreaking could be nice for other <wink> unnamed purposes.

So I learnt very recently that the PS5 has a cool approach where all memory is shared directly between the CPU and the GPU (if this is wrong someone please correct me). I would be really interesting to see how well the GPU in this could handle DL specific workloads, and if necessary, could it be tweaked to do so?

Because if so, that could be an absolute weapon or a DL workstation. If it does turn out to be feasible, I think it could be very easily justifiable to buy a few of those (for less than it would cost you to buy a major cloud provider GPU equipped instance for a couple of months) and have a pretty capable cluster. Machines get outdated or cloud provider cost comes down? Take them home and use them as actual gaming consoles. Win win.

This is also useful in computers since adding more RAM also adds more VRAM

As for C++ safety; I find modern C++ hard to read - are they going to be able to do safety but end up with something that's actually harder to use/read than Rust?

My GPS can hardly navigate most of the world I'm not really excited and if the only criteria of self driving car is self driving on a high way then color me uninterested.

I don't think self driving cars will be able to traverse majority of the world's traffic anytime soon. The road is just too difficult to maintain for human free driving with the exception of few major block cities on America which makes the whole ordeal pretty boring.

https://medium.com/ghost-blog/the-long-ignored-most-obvious-...

https://medium.com/ghost-blog/the-future-of-transportation-i...

8 CPU cores at 3.2GHz each?

https://www.youtube.com/watch?v=1cSw4fXYqWI&feature=emb_logo

And it's not contrived since we've seen situations of Telsa Autopilot behaving weirdly when it sees people on the side of billboards, trucks etc.

Andrej Karpathy's most recent presentation showed how his team trained a custom detector for stop signs with an "Except right turn" text underneath them [0]. How are they going to scale that to a system that understands any text sign in any human language? The answer is that they're not even trying, which tells you that Tesla is not building a self-driving system.

[0] https://youtu.be/hx7BXih7zx8?t=753

Even so, it is quite possible to train for this in general. Some human drivers will notice the sign and will override autopilot when it attempts to stop, this triggers a training data upload to Tesla. Even if the neural net does not 'understand' the words on the sign, it will learn that a stop is not necessary when that sign is present in conjunction with a stop sign.

LiDAR also isn't a silver bullet. Similar attacks are possible such as simply shining a bright light at the sensor overwhelming the sensor as well as more advanced attacks such as spoofing an adversarial signal.

Going from 3 nines of safety to 7 nines is going to be the real challenge.

Also we have a pattern and object detection computer behind our eyes that nothing on this planet even remotely comes close to.

Mantis shrimp have us beat when it comes to quickly detecting colors since they have twelve photoreceptors vs. our three.

Insects have us beat when it comes to anything in the UV spectrum (we're completely blind to it). Many insects also cannot move their eyes but are still have to use vision for collision detection and navigation.

Birds have us beat when it comes to visual acuity. Most of them also do not move their eyeballs in spacial directions like we do but still have excellent visual navigation skills.

Human color detection is about six orders of magnitude greater than mantis shrimp's.

Not defending those who say that LIDAR isn't useful/important in self-driving cars, but this assertion is only marginally true today and won't be true at all for much longer. See https://arxiv.org/pdf/1706.06969 (2017), for instance.

I suspect if you crunch the numbers, accidents are going to be above normal for a while after Covid-19 reopenings.

Anecdotally, I'm seeing people doing mind-blowingly stupid things on the roadways right now. It seems like people have forgotten how to drive. I suspect the issue is that people rely too much on other cars to cue them how to behave and the concentration is too low.

(It could also be that a constant accident rate cleans off the worst of the drivers with regularity as they get into accidents and then wind up out of circulation. I really hope that isn't why ... that would be really depressing.)

And we know we shouldn't drive tired or angry or intoxicated but obviously it still happens.

As soon as you get experience-sharing - culture, as humans call it, but updateable in real time as fast as data networks allow - you can build an AI mesh that is aware of local driving conditions and learns all the specific local "map" features it experiences. And then generalises from those.

So instead of point-and-hope rule inference you get local learning of global invariants, modified by specific local exceptions which change in real time.

I am so upset with the state of the auto market when it comes to pricing.

Manufacturing margins are enormous when it comes to cars.

The F150 is no different.

A two seater (effectively) vehicle stamped out of metal and plastic should never cost as much as those things do.

I hate car companies and their pricing models.

It's interesting in a bunch of ways, and I think it might end up having a wider impact than anyone has really realized yet.

It's an ISA that looks set to be adopted in a pretty wide range of applications, web browsers, sandboxed and cross platform applications, embedded (into other programs) scripting, cryptocurrencies, and so on.

It looks like it's going to enable a wider variety of languages on the web, many more performant than the current ones. That's interesting on it's own, but not the main reason why I think the technology is interesting.

Both mobile devices, and crypto currencies, are places where hardware acceleration is a thing. If this is going to be a popular ISA in both of those, might we get chips whose native ISA is web assembly? Once we have hardware acceleration, do we see wasm chips running as CPUs someday in the not too distant future (CPU with an emphasis on Central)?

A lot of people seem excited about the potential for risc-v, and arm is gaining momentum against x86 to some extent, but to me wasm actually seems best placed to takeover as the dominant ISA.

Anyways, I doubt that thinking about this is going to have much direct impact on my life... this isn't something I feel any need to help along (or a change I feel the need to try and resist). It's just a technology that I think will be interesting to watch as the future unfolds.

I remember the first Unity demos appearing on these orange pages at least 4 or 5 years ago, and promptly blowing me away. But, after an eternity in JavaScript years, I still dont know what the killer app is, technically or business wise. (Side note - I encourage people to prove me wrong, in fact I'd love to be! Thats whats so engaging about discussions here. I'd love to see examples of what WebAssembly makes possible that wouldn't exist without it.)

Obviously very serious chess players will still want to install a database and engine(s) on their own computer, but for casual players who just occasionally want to check what they should have done on move eleven to avoid losing their knight it's a game changer.

[1] https://lichess.org/analysis

If it's not, I'd be interested to see a speed and feature comparison between the two.

Example of WASM being used in a major product:

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

You can infer from this that it's making them 3x faster than anything a competitor can make, and probably inspired a lot of those 'Why is Figma so much more awesome than any comparable tool?' comments I remember reading on Twitter months back.

I use WebAssembly for a few cross-platform plugins. E.g. An AR 3D rendering engine in C++ and OpenGL. With very little effort it is working in browser. No bespoke code, same business logic, etc. Saved a lot of time vs creating a new renderer for our web app.

For me it allows a suite of curated plugins which work cross-platform. The web experience is nearly just as nice as the native mobile and desktop experience. This in turn increases market growth as more of my clients prefer web vs downloading an app (which is a large blocker for my users). I also enjoy the code reuse, maintainability, etc, :)

Another:

This year Max Factor (via Holition Beauty tech) won a Webby award for in-browser AI and AR. This was used to scan a users face, analyse their features, advise them on what make up, etc, would suit them, after which the user can try it on. This would have been impossible without WebAssembly.

This tech is also used by another makeup brands beauty advisors (via WebRTC) to call a customer and in real-time advise them on their make up look, etc.

Is this tech necessary? Probably not, but it is a lot nicer than having to go to a store. Especially when we are all in lockdown :)

1) https://www.holitionbeauty.com/

2) https://winners.webbyawards.com/?_ga=2.215422039.1334936414....

3) https://www.maxfactor.com/vmua/

I moved on from that a decade ago but it was a neat project at the time.

But I deployed my first integration of WASM about a month ago for PaperlessPost.com. It is a custom h264 video decoder that renders into a canvas that manages timing relative to other graphics layers over this video. This code works around a series of bugs we've found with the built in video player. It went smoothly enough that we are looking into a few other hot spots in our code that could also be improved with WASM.

One avenue for WASM might be simply polyfilling the features that are not consistently implemented across browsers.

Ten years ago I did the same but in Java and JOGL (before Apple banned OpenGL graphics within Java Applets embedded within a webpage). Was used for AR Watch try on within https://www.watchwarehouse.com and Ebay. The pain of Flash and Applets still wake me up at night.

I'm also building something very similar but with the ability for custom codecs (https://www.v-nova.com/ is very good). Probably the same issues too! Could I know more about your solution?

I think WebAssembly is more used than it appears, just difficult to see/tell.

A few years ago I actually tried integrating AR via WebAssembly with Amazon. We couldn't get the approval due to poor performance on Amazon fire devices (which have low end hardware). It is a shame but it is what it is.

What is disappointing/annoying is - as a CTO - it is near impossible to hire someone with WebAssembly skills. It requires an extra curious Engineer with a passion for native and web. Training is always important for a team but when going down the WebAssembly route you need to extra focused and invest more than what a typical Engineer would be allocated (E.g. Increase training from 1 day a week to 2-3). I suppose this may put people off?

I've been playing with WebAssembly lately and the moment where it clicked for me how powerful it was was building an in-browser crossword filler (https://crossword.paulbutler.org/). I didn't write a JS version for comparison, but a lot of the speed I got out of it was from doing zero memory allocation during the backtracking process. No matter how good JS optimization gets, that sort of control is out of the question.

I also think being able to target the browser from something other than JS is a big win. 4-5 years is a long time for JS, but not a long time for language tooling; I feel like we're just getting started here.

One thing I haven't heard much about is the packaging of wasm runtimes. For example, instead of including all of the .net runtime as scripts that need to be downloaded, we could have canonical releases of major libraries pre-installed in our browsers, and could even have the browser have pre-warmed runtimes ready to execute, in theory. So if we wanted to have a really fast startup time for .net, my browser could transparently cache a runtime. Basically like CDN references to JS files, but for entire language runtimes.

This would obviate the need for browsers to natively support language runtimes. It's conceptually a way to get back to something like Flash or SilverLight but with a super simple fallback that doesn't require any plugin to be installed.

I'm cautiously optimistic about blazor, it definitely makes streaming data to the Dom much easier

People are already whining about JS bundle size and even the small .net runtimes are >60kb.

Yew on the other hand seems to fit right into what WebAssembly was made for.

It is the first time you can develop a full stack application (client and backend) in one language in one debugging session. For C# that was possible with Silverlight.

Small companies (like mine) that deliver applications and have full stack engineers can have some amazing productivity!

So for my needs I'm really excited with something like Blazor, and this was only the first release.

I just don't think it's a good idea in general.

I remember being really excited at the concept. Of /course/ we needed Java co-processors!

That's a pretty big difference.

Also, a lot of computer use is via mobile these days and I doubt too many people are using the web interface on mobile for gmail.

And point about conversations moving to post-email protocols, but email is certainly still up there with HTTP as a bedrock standard that everyone eventually touches.

Without pushing JavaScript and a full featured web client, it's fair to say Google wouldn't have grown as quickly and be nearly as dominant today.

As for their move to full mobile app, I think it's a bit of a different calculation when you happen to own the OS that powers ~75% of all mobile phones [2]. ;)

Suffice to say, I don't think Google has the same troubles as other developers. (Exception to security policy, for my first party app? Sure!)

[1] https://www.statista.com/chart/17570/most-popular-email-clie...

[2] https://www.statista.com/topics/3778/mobile-operating-system...

Web Assembly is one of the more misunderstood technologies in terms of it's real, practical application.

At its core, it crunches numbers, in limited memory space. So this can provide some 'performance enhancements' possibly for running some kinds of algorithms. It means you can also write those in C/C++, or port them. Autodesk does this for some online viewers. This is actually a surprisingly narrow area of application and it still comes with a lot of complexity.

WA is a black box with no access to anything and how useful really is that?

Most of an app is drawing 'stuff' on the screen, storage, networking, user event management, fonts, image, videos - that's literally what apps are. The notion of adding 'black box for calculating stuff more quickly' is a major afterthought.

At the end of the day, JS keeps improving quite a lot and does pretty well, it might make more sense to have a variation of this that can be even more optimized than building something ground up.

WASI - the standard WA interface is a neat project, but I feel it may come along with some serious security headaches. Once you 'break out of the black box' ... well ... it's no longer a 'black box'.

WA will be a perennially interesting technology and maybe the best example of something that looks obviously useful but in reality isn't really. WA actually serves as a really great Product Manager's instructional example to articulate 'what things actually create value and why'.

It will be interesting to see how far we get with WASI.

For 5 years we've been hearing about how great they are, except nobody is really using them.

So now, it's 'the next thing' that will make it great? Except that next thing isn't there, not agreed upon or implemented, we don't know so many things about it?

Like I say, this is textbook example of tech-hype for things probably not as valuable as they appear.

If (huge if) WASI were 'great, functional, widespread, smoothly integrated' - I do agree there's more potential. But that this will really happen is questionable, and that even if it does happen, it will be valuable, is questionable.

JITs may approach native performance in theory - but the battery consumption and memory consumption are not very good. ("Better than JS" is a low bar).

As hardware becomes stronger, I would like to do more with it, and when it comes to portable devices, I want more battery life. Nothing justifies compiling same code again and again, or downloading pages again and again like "web apps" shit.

I understand where developer productivity argument comes from. But we can have both efficiency and developer productivity - it is a problem with webshit-grade stacks that are used today that you can't have both.

I personally think flutter model is future. You need not strive for "build once - run anywhere". You can write once and build anywhere a cross platform HLL and that's better.

As for sandboxing, maybe it is that your OS sucks (I say this as linux user); Android / iOS have sandboxing with native code. You shouldn't need to waste energy and RAM for security. IMO enforcing W^X along with permission based sandboxing is better than webassembly bullshit that is pushed.

And webassembly itself seems to be a rudimentary project with over ambitious goals. JS bridge being so slow and not having GC support ("To be designed" state) make it unusable for many purpose. Outside HN echo chamber, not many web people want to write in rust or even C++.

Without WebAssembly I wouldn't have been able to ship 2 products pro-bono within intensive care units and operating theatres directly helping with COVID.

I understand your dislike towards WebAssembly (albeit Web stack trends / flavour of the month esque development). I am not the largest fan of modern web development. Nevertheless love for WebAssembly is not due to developer productivity. After shipping 20+ WebAssembly products (alongside native counterparts) I am yet to meet an Engineer who enjoyed the WebAssembly/Emscripten/Blazor pipeline. However what WebAssembly has achieved for me is: Do people use your app? and within certain markets it allowed me to grow, do good, and say yes. This is the only real reason why someone should go down this route.

Wasm is like the JVM or CLR in that regard. It's not the future - it's the past.

If you read about the Baseline protocol (EY, Microsoft, SAP etc building neutral interconnections between consortiums), ENS/IPFS, or digital identity systems you might find something that interests you and is more relevant than the mindless hodl ancaps. It's actually a pretty exciting field to be in as a computer scientist with almost no end of boundary pushing experiments and cryptographic primitives to play with and build on top of.

Similarly, someone is developing a patch for postgres that implements incrementally updating/materializing views[1]. I haven't tried it so I can't speak of its performance or the state of the project, but according to the postgres wiki page on the subject [2] it seems to support some joins and aggregates, but probably not something that would be recommended for production use.

[1] https://www.postgresql-archive.org/Implementing-Incremental-... [2] https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...

They're marketing it in the OLAP space right now, but at some point I'd like to try integrating it with a web framework I've been working on.[1][2] It'd be a more powerful version of firebase's real-time queries. Firebase's queries don't let you do joins; you basically can just filter over a single table at a time. So you have to listen to multiple queries and then join the results by hand on the frontend. Doesn't work if you're aggregating over a set of entities that's too large to send to the client (or that the client isn't authorized to see).

[1] https://findka.com/blog/migrating-to-biff/ [2] https://github.com/jacobobryant/biff

Initially we went for the metaphor of "what if you could keep complex SQL queries (e.g. 6-way joins and complex aggregations, the kinds of queries that today are essentially impossible outside a data warehouse) incrementally updated in your application within milliseconds? What would you build?

We're moving away from that metaphor because it seems it's more confusing than helpfuL. Tips always appreciated!

My suggestion would be consider comparing it to firebase queries. Firebase devs are already familiar with how incrementally updated queries can simplify application development a lot. But, despite Firebase's best marketing attempts, the queries are very restrictive compared to sql or datalog.

Making it easy here would be absolutely fascinating.

https://www.datomic.com/

Would be huge if materialize supports this out the box. I believe it's a very useful middle ground between CRUD overwriting data and eventsourcing. I still want my source of truth to be a rdbms, but downstream services could use data stream instead

Change data capture allows you to stream database changes to a message bus or stream which has much better support for backend service requirements. Example: if a downstream service goes down, how would it retrieve the missed events from Hasura? Using Kafka or a buffered message bus, you'd be able to replay events to the service.

Nevermind having to support websockets in all your services :/

https://oxide.computer/

“True rack-scale design, bringing cloud hyperscale innovations around density, efficiency, cost, reliability, manageability, and security to everyone running on-premises compute infrastructure.”

Corey Quinn interviewed the founders on his podcast "Screaming in the Cloud", where they explain the need for innovation in that space.

https://www.lastweekinaws.com/podcast/screaming-in-the-cloud...

Basically, on-premises hardware is years behind what companies like Facebook and Google have in-house, it may be time to close that gap.

They also have a podcast, "On The Metal", which is such a joy to listen to. Their last episode with Jonathan Blow was really a treat.

https://oxide.computer/podcast/

It's mostly anecdotes about programming for the hardware-software interface, if that's your thing ;).

https://news.ycombinator.com/item?id=23089999

8/10 is cost related.

This probably would've accomplished the same goal, with a lot less overhead.

WASM - Mostly as a compile target for Rust, but I think this changes the way software might be deployed. No longer as a website, but as a binary distributed across CDNs.

ZK-SNARKS - Zero knowledge proofs are still nascent, but being able to prove you know something while not revealing what it is has specific applicability for outsourcing computation. It's a dream to replace cloud computing as we know it today.

Lightning Network - A way to do micropayments, if it works, will be pretty interesting.

BERT - Newer models for NLP are always interesting because the internet is full of text.

RoamResearch - The technology for this has been around for a while, but it got put together in a interesting way.

Oculus Quest - Been selling out during COVID. I sense a behavioral change.

Datomic - Datalog seems to be having a resurgence. I wonder if it can fight against the tide of editing in-place.

You can stop the tape right there. You know it doesn't and it can't.

https://news.bitcoin.com/hidden-lightning-network-bug-allowe...

https://news.bitcoin.com/mishap-sees-user-lose-30000-btc-on-...

The bug has already been patched, and had a limited userbase. The user who supposedly lost all his Bitcoin ended up not being true, vast majority was recovered. It's also worth noting that the user also deliberately went against various UI warnings that funds may be lost.

https://github.com/lightningnetwork/lnd/issues/2468

Three days ago: https://news.ycombinator.com/item?id=23232978

Just checked out the website, how is it any different from Dynalist or Workflowy?

Workflowy is strictly an outliner. It's like Gopher--hierarchical, unlike the Web, which is a graph.

Feature-wise, Roam is more like a graph. You can really easily link to other concepts, and rename pages (and everything renames). It also has a page generated daily, for things you want to write down.

Feeling wise, you get to write things and collect them and organize them later. I think it's more condusive to how people think and research. You might have a piece of data, but you're not sure where to put it yet. Most other note taking systems forces you to categorize first.

Perhaps you may be interested in Golem project devoted to distributed computing: https://golem.network/

It's hard to explain how big nanopore sequencing is if a few (hard) kinks can be figured out. Basically, it has the potential to completely democratize DNA sequencing.

Here is an explanation of the technology - https://www.youtube.com/watch?v=CGWZvHIi3i0

[0] https://store.nanoporetech.com/us/flowcells/flongle-flow-cel...

You cannot effectively sell this kind of device under $25K--support costs simply eat your profit margin.

This is a constant across industries. You either have a $250 thneed (and you ignore your customers) or a $25K thneed (and you have shitty customer support) or a $250K thneed (and you have decent customer support).

To give you a sense, you can buy one for 1k and do as much detection as a 64k device, and it’s small enough to fit in a backpack. One device should be able to do 500-1000 tests per 24hrs at a cost of about $10 per test, not including labor.

You can visit with the beaker browser, or share it through dat so it won't ever go down.

You can also visit it at http://www.nanosavseq.com/ (DNS is not up yet, http://167.172.195.83/book/index.html is direct)

It's embarrassingly barren right now, mainly since I've encountered some big problems with getting my DNA quantifier out of storage to start doing a lot more experiments. I'm getting that on Tuesday, so will be updating site then.