majoe

Some thoughts on why I think this is wrong:

If no one needs it during the day, they can't sell it. That's not how markets work. Energy that is generated, needs to be consumed or else the grid breaks down. These two facts together mean, that the energy they sell is needed and used. Albeit they could generate and sell even more energy, if the energy could be stored or if the load could be shaped accordingly. The latter is a great way to lower energy costs.

Energy consumption during the night is low. So low, that night time electricity prices, which are lower than the daytime prices, are still a thing.

Heat pumps are an opportunity for load shaping. Buildings can be heated, when electricity is abundant and heated a few degree over the target temperature, if needed. The heat is stored inside the building and needs less heating during the night. That works quite well, especially here in Europe were buildings generally have good insulation and are made of brick, which can store a lot of heat.

I've seen some examples of C++ contracts replacing CRTP, but it used templates, which again, not a fan of.

I think you meant concepts.

C++ Concepts are the right answer in my opinion, if you want compile time polymorphism against an interface.

I don't think, there is a way around templates, they are C++'s way of compile-time polymorphism. Other languages, which allow for compile-time polymorphism, have similar mechanisms with similar constraints. I get where you come from, when you say that you're not a fan of templates, though. At least concepts help with clearer error messages for templates.

One advantage, that concepts have over CRTP is, that only consumers of your interface, not implementers, need to know about your concept.

I recently read about Aptera, a company building a commercial solar car:

https://aptera.us/first-vehicle-off-validation-line/

I think it is quite interesting, because it also tries to be maximal efficient, which increases the "reach" that the panels provide.

Don't get me wrong, this is a enthusiast car, but I think the economics could actually work for a small city car. Currently here in Europe, buying a electric car makes sense for home owners, which can charge their vehicle for cheap at home (especially if you PV). But a lot of people living in cities don't have a cheap charging spot. A car with solar panels, which gains a few percents of charge each day (instead of losing some), e.g. enough for the daily commute to work, may be interesting for such people.

I would love to see a ultra cheap take on this. Maybe an electric tuktuk like someone else suggested, with some solar panels slapped on it.

Yes, that's drive me insane, west which is biggest advocator of climate change and preaches renewable energy has not done as much as a poor country like Pakistan has done.

The "west" is not a single place and I hate that term, because it contains that "we against them" narrative, which is pushed on us from many directions in recent years. France, Germany or the USA all have a very different energy strategy, shaped by the availability of resources and geopolitics.

But for the average Joe, the situation across the globe and also in the "west" is not so different from what was described in other commments about Pakistan: People install solar on their rooftop, backyards, balconies etc. because it is dirt cheap now and amortises in a reasonable amount of time.

EU has to do more and make it easier for them to install solar panels.

I can't speak for all countries in the EU, but at least in Germany, it's already quite easy and became even easier in recent years, e.g. private solar installations are exempt from various taxes.

The effort and money put into renewable energy in the EU is significant. In Germany around 60% of energy now comes from renewable energy [1] (Pakistan for comparison [2]), which was unthinkable 15 years ago. I remember quite well, that the fear mongers foretold, that we never will exceed 20% renewables or if we did, that the grid no longer will be reliable.

That said, you're right that the EU could and should do more. It feels like we're doing the "Energiewende" with one arm tied to the back. Unfortunately, there are many groups working against this goal by influencing the public opinion and it will stay like that for the foreseeable future.

[1] https://ourworldindata.org/grapher/share-electricity-renewab...

[2] https://ourworldindata.org/grapher/share-electricity-low-car...

Had a self hosted nextcloud instance runnning on my homeserver, but migrated away two years ago to a Hetzner Storage share. All in all I'm quite happy with that.

There are some downsides, though:

  - No support for collabora online, so no way for collaborative editing of office files
  - Data is not encrypted

Probably true, but one unique thing about Julia is, that exposes almost all stages of the compilation to the user. From typed IR to native code generation you can customise the compilation in many ways. Together with the power of LISP's metaprogramming features, that's a really fine basis for powerful and performamt DSLs and code transformations.

All those GPU targets are powered by libraries, that are not part of Julia itself (GPUCompiler.jl). The same goes for automatic differentiation. That's remarkable in my opinion.

So you're right, that many programming languages could do it, but it's no wonder, that other languages are lacking in this regard compared to Julia.

Nix devShells works quite well for Python development (don't know about JS) Nixpkgs is also quite up to date. I haven't looked back, since adopting Nix for my dev environments.

I struggled with remote deployment + secret management, too. Like a lot of folks, my nix-config grew over the years as I added secrets management, user management etc ad hoc.

I recently found clan.nix [1] and am quite pleased. It's kind of a framework for writing nixos configurations with a focus on multiple devices. It bundles secrets management and remote deployment into a convenient CLI.

It has the concept of "services", which are e.g. used for user management and VPNs. Services define roles, which can be assigned to machines, e.g. the wireguard service has a controller and a peer role. That feels like the right abstraction and it was very easy to set up a VPN with zerotier like that, something I struggled doing myself in the past.

It's a rather young project, but I converted my nix-config repo after a short evaluation phase to use clan. It's worth taking a look for sure.

[1] https://clan.lol/

Kartoffel is the standard German word.

Erdäpfel is used in many dialects and has plenty of variants.

Actually the various different words for potatoe and their distribution across Germany, Swiss and Austria is linguistically quite interesting (see this map [1]).

The legend is in German and roughly translates to (from top to bottom):

- Potatoes

- Ground pears

- Earth apples

- Earth pears

- Hearth apples

[1] http://stepbysteplingue.com/wp-content/uploads/2019/02/karto...

I tried different LLMs with various languages so far: Python, C++, Julia, Elixir and JavaScript.

The SOTA models come do a great job for all of them, but if I had to rank the capabilities for each language it would look like this:

JavaScript, Julia > Elixir > Python > C++

That's just a sample size of one, but I suspect, that for all but the most esoteric programming languages there is more than enough code in the training data.

nowadays Element is actually on a more economically sustainable path

Good to hear. Keep up the good work.

That's not correct. For ordinary computers there is Landauer's principle, which gives a theoretical lower limit for the energy needed for computation [0].

I say "ordinary computers" because other comments mentioned "reversible computers" for which this limit doesn't apply.

According to the linked wikipedia page, this theoretical limit is around a billion times smaller than current computers use for an operation, so you may call me pedantic.

[0] https://en.wikipedia.org/wiki/Landauer%27s_principle

I came to like auto over the years, although I also use it sparingly. Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators:

auto it = some_container.begin();

Not even once have I wished to know the actual type of the iterator.

Damn, I always thought Fuchsia is just a colour, but today I learned

  - Fuchsia is a flower
  - which is named after a German botanist (Leonhart Fuchs)
  - Fuchsia in English is pronounced completely different than in German. 
  - Google is surprisingly bad at naming their products

Thing is that you need a complex JIT like Julia's or stuff like https://github.com/marcoheisig/fast-generic-functions to offset the cost of constant dynamic dispatch.

Julia is always the odd one out, when talking about dynamic vs. static dispatch, because its JIT compiler acts more like an Ahead-of-Time compiler in many regards.

In the best case, types are statically decidable and Julia's compiler just produces a static dispatch and native code like e.g. a C compiler would.

In the worst case, there are a big (or unlimited) number of type candidates.

The grey area in between, where there are a limited number of type candidates, is interesting. As far as I understand, Julia does something similar to the link you provided. Based on some heuristics it will compile instances for a "sealed" number of candidates and fallback to a fully dynamic dispatch, if there are two many type candidates.

At JuliaCon 2025 there was an interesting talk about this topic: https://m.youtube.com/watch?v=iuq534UDvR4&list=PLP8iPy9hna6S...

For the worst case scenario, Julia chooses what's in my regard the nuclear option: If the types are not decidable, it just ships the whole compiler with your code and tries again at runtime. But I guess, that's not the only possible solution. Presumably, it would also be possible to fallback to a Julia interpreter for dynamic code. That would be more similar to what JavaScript is doing, just the other way around. Instead of interpreting the majority if the code and optimising hot paths with a JIT, our alternative Julia would compile most code statically and use the interpreter for the dynamic parts.

V2G is a pipe dream.

Seems a bit early to come to this conclusion, but I would also suspect, that the value of a parking garage full of EVs is not in providing energy to the grid but as a large scale consumer for load shaping.

I went through a similar journey recently for the local development environment of my team.

I couldn't figure out yet, whether there is a reasonable and safe way to authenticate at an AD inside a GitHub Action. Anyone done that?

Counterintuitively Julia recommends the use of immutable data types for performance reasons, because immutability enables more flexible compiler optimisations

An immutable variable can be savely shared across functions or even threads without copying. It can be created on the stack, heap or in a register, whatever the compiler deems most efficient.

In the case, where you want to change a field of an immutable variable (the use case of lenses), immutable types may still be more efficient, because the variable was stack allocated and copying it is cheap or the compiler can correctly infer, that the original object is not in use anymore and thus reuses the data of the old variable for the new one.

Coming from the C++ world, I think immutability by default is pretty need, because it enables many of the optimisations you would get from C++'s move semantics (or Rust's borrow checker) without the hassle.

Most of Europe became rich under imperialist, authoritarian governments not with their current system

Europe prospered under democratic governments after the second world war. My particular region of Germany was rural, agrarian and piss poor before the war. Now it is an industry hub and one of the richest regions in Germany, all thanks to a democratic government, which prioritised development of rural areas.

The wealth we now enjoy is incomparable to what we had under authoritarian rule before.

Let's also not forget, that the Cold war divided Europe in two halves, one with democratic governments and one under authoritarian rule, an A/B test so to say. The end result was, that they needed a wall in Berlin to keep the people from fleeing to the west.

Look around the world and see how many countries managed to achieve similar success using the same liberal principles

Beside the whole of Europe, Japan, Canada, Australia, New Zealand, South Korea, Uruguay and Taiwan come to mind. Taiwan has a per capita GDP 2.5x that of mainland China.

This lead me done a rabbit hole on wikipedia:

Advent calendars in their earliest forms were invented approx. 80 years ago.

The four week advent period goes back to the 7th century and was introduced by pope Gregory I..

I was pleasantly surprised, that a recent update for plasma fixed the fingerprint reader for my thinkpad t15. It previously had an issue, where it didn't work after waking from suspend.

I disagree for Julia, but that probably depends on the definition of static typing.

For the average Julia package I would guess, that most types are statically known at compile time, because dynamic dispatch is detrimental for performance. I consider, that to be the definition of static typing.

That said, Julia functions seldomly use concrete types and are generic by default. So the function signatures often look similar to untyped Python, but in my opinion this is something entirely different.

You can define your own concepts. What is your point?

I haven't seen an example yet, where concepts weren't simpler and easier to read/understand than SFINAE shenanigans.

"Just read the scripture" is not enough. Catholics are supposed to use the historical critical method, when interpreting texts from the bible. There are other Christian groups, which take the bible verbatim, but Catholicism is none of them.

For that and other reasons there are plenty of things presented in the old testament as sins, which Christians don't consider to be sins. The most obvious example is probably rules around kosher food.

If time were running against the arrow of entropy, nobody could perceive or measure it, right? Remembering something is per se an increase in entropy, so the universe could run in negative time direction, but we would simply forget, what had happened.

That said, I personally think such thought experiments are futile and the nature of time has to be understood by its connection to causality and information.

Reasons I can think of:

- Wrapping all objects in shared pointer is annoying. - If you stick to that convention, you have to do it on every call side, while you only have to implement RAII once. - You can enforce invariants of your class with RAII, that you can't with a plain shared_ptr - Regarding efficiency: It has the overhead of reference counting plus you have to store all objects on the heap instead of the stack. In hot loops this may hurt cache locality.

This is the answer.

Interestingly, wind/storm loads are oftentimes the limiting factor for the configuration height of a crane.

This is because, when adding another tower segment, not only the total area increases but also the wind forces. The other loads stay roughly the same

This is the reason why bottom-slewing cranes, which are commonly used for small buildings, sometimes are built with solid walls. Top-slewing cranes, which are used for high buildings, always use a steel framework.

Working for a crane manufacturing company. While raw material costs are maybe not that drastic, we consider material efficiency the most important metric for cost and a lot of brain power was spent to optimise the amount of steel used. There are multiple reasons for this. The ones I can think of are:

  * The margins for cranes are thin and steel is expensive.
  * Thicker steel is harder to work with, increasing manufacturing cost.
  * Each kg of dead weight may decrease the performance of your product, e.g. max. Live load. This is especially true for the jib.
  * More weight at the top of the crane may necessitate a sturdier structure below, amplifying cost even more.
  * More weight may require more ballast blocks, which are costly (especially transport)
  * More weight means higher transport costs
  * More weight means more wind area, which is the critical factor for high constructions.

I see, where you're coming from, but in that particular case, the "intuitive" explanation (walk on a graph) is far less intuitive for me than the proper explanation, that a Markov process is memoryless. That said, I used MCMC in the past to do physics simulation, where the Markov property also applies to the underlying physical process. So maybe it's just me.

1qq