majoe
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.
They seem to create a dynamic nix derivation per compilation unit, which would be very similar to what you describe as manifests in your post as it also creates a hash of all inputs.
Would be interesting to here your opinion on that approach
- 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.
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 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.
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.
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...
There are some downsides, though:
- No support for collabora online, so no way for collaborative editing of office files
- Data is not encrypted
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.
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/
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...
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.
Good to hear. Keep up the good work.
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.
auto it = some_container.begin();
Not even once have I wished to know the actual type of the iterator.
- 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 productsJulia 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.
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 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?
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.
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.
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..
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.
I haven't seen an example yet, where concepts weren't simpler and easier to read/understand than SFINAE shenanigans.
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.
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.
- 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.
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.