majoe

> C++ is also surprisingly good, but you pretty much have to tell the LLMs to treat it like Go and don't use any of the dangerous features for normal code.

For existing codebases I made the experience, that LLMs are very good at replicating their style.

At work most of our C++ codebases use a fairly consistent style and subset of C++ features and to my initial surprise specifying style conventions etc explicitly turned out to be mostly superfluous.

Of course, we also have some legacy projects originally, written in ANSI C, which only received a few changes in the last 15 years to compile with a C++ compiler. Here a style guide is helpful, bit I consider it more like a temporary instruction for refactoring.

Your post sounds like there is some strange rule regarding taxation of solar installations, but it is (or rather was) just treated as any other income from commercial operation.

- If you have any income from commercial operation (selling stuff) you are required to declare that, when doing your taxes.

- When selling electricity you're not so much classified as an energy company, but fall under similar taxation rules as a company. This also means you can get the VAT back, you paid when buying panels, inverters etc.

- Since 2023 solar installations smaller than 30 kWp are completely exempt from this taxation scheme. This means you're not paying any VAT, when buying equipment for your solar installations and don't have to declare the revenue.

- You can get around the 30 kWp limit under some circumstances by having multiple separate installations.

- Parent post is talking about an off-grid installation, which would be exempt anyway, because there is no revenue from selling electricity.

The tax exemption from 2023 was a very welcome move by SPD and the Green party to reduce bureaucracy regarding solar installations and I think the 30 kWp is pretty reasonable

Would be interesting to see, how other countries are handling this.

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.

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

Hetzner also has classical web hosting offerings, which are cheap as well. I'm using that for email and a website of mine.

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 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.