Hacker Newsnew | past | comments | ask | show | jobs | submit | yvdriess's commentslogin

> Hard to make a better wheel.

Pet peeve: stupid analogy seeing how wheels kept being improved throughout the millennia with every new technology. The only thing in common is that it's round.

Similarly, DRAM in any way you see it has been improving to the point of barely being recognizable since the 70s.

That said, DIMMs and the whole bus idea is in dire need of getting a new type of bearing.


Seems like a pretty good analogy as you admit there have been advancements while the basic structure has remained the same. Not sure why you have a pet peeve when it is highly analogous.

The ultimate shape of DRAM is the same, the main thing that's changed is the materials and techniques to produce it. Making it very impressive, but none the less completely recognizable by someone who was familiar with DRAM in the 70s.

The wheel is the same. Pluck someone from 1000 years ago and they'll be able to correctly identify a modern wheel even though they've never seen any of the composites that go into it. The function of the wheel is identical to how they used it.


> That said, DIMMs and the whole bus idea is in dire need of getting a new type of bearing.

IBM has been using their own memory bus technology for both their POWER and Z machines. IIRC, it’s somewhat reminiscent of CXL, trading latency for bandwidth and size.


The latency of a DRAM cell has barely budged since the 1990s.

Just to highlight: in contrast with fossil fuels, at least nuclear waste is something we can capture, creating a storage problem.

*if everything works as planned

If everything works as planned fossil fuel power plant emmits CO2 and pollutants.

Gladly, you don't need to use them

not if you read fraunhofer ise decarbonization pathways report. If you dont like nuclear and have no hydro, it basically means fossils

I don't know how you read this out of the report

When we already talk about Fraunhofer, they with a few other institutes, have been sketching out various pathways over the years for Germany for transitioning to a renewable energy system multiple times, see https://langfristszenarien.de/enertile-explorer-wAssets/docs...

While Germany has some hydro, it's just a tiny amount


I'm talking about this one https://www.ise.fraunhofer.de/en/publications/studies/paths-...

In pessimistic economy growth scenario about 80GW of gas are needed or more otherwise. The hope is to sometime replace it with hydrogen which looks like a gamble https://ieefa.org/resources/germanys-gas-and-hydrogen-gamble


> I'm talking about this one https://www.ise.fraunhofer.de/en/publications/studies/paths-...

again my remark: I don't know how you read this out of the report:

> If you dont like nuclear and have no hydro, it basically means fossils

The report doesn't even aim to make claims about feasibility of energy systems without nuclear, natural gas and hydro power.

> In pessimistic economy growth scenario about 80GW of gas are needed or more otherwise.

1) during the specific paths of which there are infinitely many ... (including the ones I linked)

2) seldom usage

3) replaced over time (when extrapolating there would be no natural gas usage )


The ones you linked too do use gas firming... And the goal there too is to sometimes replace it with hydrogen if ever possible which is more a pipedream than doing a messmer plan over entire EU today

natural gas usage is or is almost (used for a tiny amount of heating) non-existent in the scenarios

AmbientTalk did this. I used it for a demo where I dragged a mp3 player's UI button to another machine, where pressing play would play it back on the originator's speakers. Proper actor programming in the veins of E and Erlang.

https://soft.vub.ac.be/amop/


Tournament parallelism is the technical term IIRC.


somethingaweful forums are still very much alive


Anyone else clicked on this expecting an article about Go Generics?


Ignoring the snark for a second. It's not because you are unfamiliar with the go toolchain that it's inherently bad, nor does it put you in a good position to give accurate criticism.

- "tea" is an explicit alias that was added to the import statement in the tutorial examples, which you did not reflect in your snippet:

    import tea "charm.land/bubbletea/v2"

- The following also just works as you expected, but directly assumed wouldn't work:

  import github.com/charmbracelet/bubbletea
The only surprise here is that the repository authors decided to change the name of the module between v1 and v2 of the package. The git branch tagged v2 contains a module named 'charm.land/bubbletea', earlier v1 branches are named 'github.com/charmbracelet/bubbletea'. That's on them for breaking convention and surprising users, the go toolchain does not factor into, this beyond supporting versioning by naming convention.


I would be fine with a chaotic bubbly mess of an outside presentation, if the libraries were more robust and foundational. At the moment the underlying code, when you scratch the surface, have the feel of things thrown together to be replaced at later date.

I bounced off of bubble tea not because of the aesthetics and the unhelpful naming, but because of the programming model: a MVC-architecture cribbed from the Elm language. Why? It completely takes over and rips apart my CLI structure. A CLI is not a DOM or System.Windows.Forms, MVC is scattering around logic and adding indirection layers needlessly.

I am still using huh? and vhs, but their libraries have the feel of looking really good in demo and in the provided examples, but break down quickly when coloring just outside those intended lines.


Everything that was old will become new again. Content/structural version control used to be a research field. Pharo still uses one afaik https://scg.unibe.ch/archive/papers/Nier13bMonticello.pdf


Yeah I am actually super excited for these new kind of innovations.

These things are genuinely not letting me sleep these days.


Yeah. It's telling that this story is about their discord channel, not Teams.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: