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

I believe there are many top level chess masters that consider chess an art. Same for programmers, to many of the best, it is an art form or at least a craft that they take very seriously. And many would disagree that programming is solved. "Boring and standard" can be a sign of quality, but it also applies to those code bases that don't solve any interesting problems and just drown in boilerplate, kept alive by dozens or hundreds of programmer drones just working to collect their paychecks.

"Russian schoolboy chess" as Bobby Fisher would have called it, and while he detested this style of approach, it is far closer to how chess is played, where the moves come from rigorous analysis and application of engine discovery than by the beauty of the game (which is ofc why there is Fisher-chess because he felt it kept the artistic side)

This is interesting, but now explain why Germany has both the highest electricity prices in Europe as well as a relatively high CO2 footprint from electricity? Germany is buying not only nuclear but also coal energy from neighbouring countries.

Will this be fixed at some point or is the German model not actually as good as you imply?


The main reason why electricity is expensive in Germany is because it's taxed to oblivion. Even when wholesale prices are negative, electricity costs about three times as much as gas.

Now you might ask why electricity is taxed to oblivion. Some don't like nuclear or coal. Some prefer oil or gas. In the end, there's a majority that wants electricity to be expensive.


I was under the impression that the taxes are going into infrastructure and grants for renewable energies, meaning those energy prices are maybe way higher than advertised. Funny thing is we are constantly being told how cheap reneweables are to produce but apparently there are other costs involved.

FTR and for the inevitable downvoters, I am not a fan of fossil energy. I am merely a fan of well presented arguments, and downvotes aren't that.

Well, that impression is wrong. The german word for "Taxes" is "Steuer". And they go to one of the 3 levels of our government: Federal level, the 16 states, municipalities / communes.

And yes, we pay VAT (19%) and electricty tax (0.0205 € / kWh).

But we also pay other things, like Konzessionsabgabe, KWKG-Umlage, AbN and Offshore-Netzumlage. They have various reasons:

AbN is used to make electricity artificially cheaper for ecenomically important companies that have a high usage of electricity. So this doesn't go to government, it's no tax.

KWKG (Kraft-Wärme-Kopplungs-Gesetz) is payed to keep the oil and gas power plants in operation. We now have so much renewable energy, they it wouldn't be economically feasible to operate them -- they have quite low duty cycles these days. They are however important for the quality of the whole network. So this doesn't go to government, it's no tax.

Konzessionsabgabe could perhaps counted as tax. The lines of the electric grid go over public property. Or they use the area below the pedestrian sidewalks. And so they have to pay for it. So this doesn't go to government, it's no tax, more a rent.

Offshore-Netzumlage is because we have sooooo much electric wind power in the north and baltic sea, but most bigger industry is in the south. It is used to pay for the new electric trasses. So this doesn't go to government, it's no tax.

Also, electric power in Germany is both cheap and expensive. The internal price is often cheap. But the price to end-customers is often expensive. One part of that is that many end-customers don't switch their electricity power. In history, we had local power distributors, often in the hand of the city or the county. But since perhaps 20 years one can now just select anyone, whoever has the lowest price. However, the majority of the germans stay (due to lazyness?) with their local providers. Which are usually on the more costly side.

Source so far: https://strom-report.com/strompreis-zusammensetzung/

Also we should not forget that Germany has one of the best electric grids in Germany. We can take the SAIDI and compare electric grids of regions or countries. And in Europe, Germany has the lowest SAIDI of all large industrial countries. Some have a lower SAIDI, but they are tiny-states.

So, what is SAIDI? The System Average Interuption Duration Index --- or how long per year and customer the power is out. And here we're better than e.g. Austria, France, Belgium, Sweden ... but also MUCH better than the USA, which seem to have exceptional shaggy electric grids.

So price is one thing... but that you can depend on the electric power in Germany, but maybe not abroad, is another thing.

Source for SAIDI: Germany and english language Wikipedia, Bundesnetzagentur


Good to point out the difference between taxes and other tariffs, but I have a hard time understanding why you have to call what I said "wrong"? What you went to explain in detail is exactly what I alluded to, that also matches the previous posters "electricity [...] taxed into oblivion".

Another point: 3.3% of federal tax income, or 1.7% of all taxes paid by citizens, goes directly into "Klima- und Transformationsfonds" i.e. gets pumped into energy transformation. And the state even pumps more money into that, by means of "Sondervermögen" (taking additional debts). Measured as a percentage of federal state tax income, seems like Germany is pumping more than 7% total into energy transformation. Quite a lot I think, and even if this is not directly a tariff on electricity, it's easy to imagine how this can result in general price inflation.


All of Germany's neighbours, from which it buys electricity, are decarbonising so yes obviously it inevitably gets "fixed at some point".

Germany's wholesale prices are similar to many other European countries, the worst is easily Ireland because of their geography, small, northern, coastal, they often need to import power, and that import has to come from Britain, which is between them and the continent, so their prices will almost always be higher than Britain's already not-great prices - we're obviously not going to sell the Irish £89 per MWh electricity and then charge our own users £119 per MWh for the same product.


What I am saying is that those spot prices may not represent all of the reneweables' marginal costs. Question is, will the end consumer prices ever go down, and by how much?

> Question is, will the end consumer prices ever go down, and by how much?

No, electricity is not likely to become a deflationary product. It hasn't been in my lifetime and I don't see that changing. Products which do that are weird and they don't tend to do it for very long.

There was a period (last century, more than fifty years ago) when Oil was deflationary in the US, as the very easily extracted Saudi Oil came online and US import bans ended - you'd pay the same dollar price to fill a car with gasoline in one year as the next and of course wages continued to grow so that oil is getting cheaper in real terms. But that's a long time ago, a time when gasoline was 30 cents per gallon.

Solar PV is just straight up cheaper than any fossil power. Solar Farms the UK agreed to subsidise in 2022 came online early last year and even in those more normal times (before Trump started a war in the Middle East) the "subsidy" amounts they were paying us totalled a few million quid a year because the fossil power was so expensive. Once Trump got into it, we were being paid like £3-4M per month in "subsidy" because of course the fossil fuel costs more now but sunlight is still free.

But that does not translate into lower prices for consumers, at most it means their prices might not rise as quickly.


The prices of so many things have gone down with times due to increased efficiencies. Why not electricity? If solar PV is cheaper than fossils, I would, naive as I am, expect prices to go down.

(I acknowledge fossils have been going up for various reasons, and have become more scarce, and energy demands are rising)


There's a situation like with Amdahl's law here, which I'm guessing you're familiar with since this is HN but if not then I'm sure you can read about it. Consumer prices - the thing you're experiencing - have multiple inputs, and wholesale price is the only one that's subject to this change by generation technology so that dilutes the consequence of any such change for consumers.

If you're paying 25 cents per kWh and and the wholesale price was $100 per MWh then 10 of those 25 cents were for wholesale electricity, but you're paying 15 cents per kWh for "other things". Maybe a huge improvement to generation technology reduces that wholesale price to $90 per MWh, amazing, but alas general inflation increases your suppliers other costs to 16 cents per kWh and so you pay... 25 cents still.

If that wholesale price somehow halved and it was all passed on (good luck with that) your 25 cents per kWh goes to 20 cents, only a 20% drop.

The learning curve for solar is shallowing, and while it's steeper for offshore wind and especially floating offshore wind, those are both way more expensive than solar, so you'd need much more price decrease for them to be cheaper than say, coal.


Nuclear does not produce CO2. Nuclear energy is green energy.

Why I said not only... but also.

Not following Omarchy, not even sure what it is trying to be compared to existing distros (other than an incredibly hyped up product). Not hating on DHH. But hasn't he become famous for developing a web framework (20 years ago), rather than for his technical prowess as a systems-level engineer? Seeing these kinds of bugs is not exactly unexpected.


It has nothing special compared to Arch. In fact, I would argue its just dotfiles for Arch.


I suspect his pitch here is that he knows UX and is technical enough to make it happens, rather than that this is a serious server OS.


How do you judge "better" if you don't understand the LLM output?


By quantifying the result.


What are you talking about?


You want to solve a family of problems using some tool. You measure the relevant solutions performance metrics.

Now, you or someone else vibe-coded a new tool. You created new solutions and measure again.

You have just quantified the result of using the new tool.


How do you measure them if you don't understand what you're doing? A shitty benchmark or small test suite is not how solid software gets made.


You measure results, you benchmark what you care about. It works often enough to be useful


Good, you achieved a 10% speedup for a particular workload that some users said they care about. But how do you find out that was really the feature that should have been built next? How do you prevent adding badly factored code? How to make sure you don't pile on top of existing tech debt in the codebase, that you are solving the most fundamental issues first?


> some users said they care about

But how could they possibly know what they should care about if they don't understand the code?

> how do you find out that was really the feature that should have been built next?

Phew right they don't know. Only the devs understand what software should do.


I actually explained well enough why this requires to a large degree a competent developer to judge.


I think a sufficiently smart non-competent developer can still do this to great effect, but it definitely helps if someone is both a competent developer, smart, and a seasoned user of LLMs.


Just because AI is not yet a god that is better than all humans at creativity and product decisions and design does not mean it is not a huge accelerant right now.


Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.


Reflection is likely useful for a lot of things, but I agree serialization need a better framework.


Yes -- I can see good use for runtimes. For example, compiler can autogenerate good runtime error messages. Thinking about it, debuggers make use of reflection. Debuginfo formats have some kind of reflection built in.


It isn't actually that flat in the spec, though modern machines' address spaces are. So in a sense it is merely an accident of a specific implementation that you can smash stacks.


Yes, you are right in that programs are not supposed to point outside of allocated blocks into other regions, that's UB. As in, pointer arithmetic that computes pointers outside of (but not even accessing!) an allocated block is UB. Annoying, pointers can legally be put into integers, looked at (e.g. printed out as a hex value), and then reinterpreted back into pointers, so it more-or-less dictates flat addressing. E.g. it's basically not possible to make an implementation that would run most programs where pointers are unforgeable, relocatable things, because of this. All of this spec is post-hoc, so it's a nasty retcon job that papers over the old folk understanding of one flat address space that's more or less still there in every implementation.


Casting integers to pointers is implementation-defined as far as I know. Even if weren't, I'm not convinced that you have to interpret C's address space as flat just because it is finite or because pointers are representable as integers. In any case, machine's address spaces are flat (the physical memory mapped into them not so much), and working with real machines is what I'm interested in.


But I assume that both on compiler and on machine, the evaluation is still conforming to the semantics of the C abstract machine?


You are again misreading even the most clearly put statement. Compared to e.g. Javascript, C is "closer" to the hardware, gives you "more control" of it. It would be completely ridiculous to deny this fact.

And if you move to e.g. C# / Java or similar, if you squint, and you try to be a smart-arse, then you could deny that C is closer to the hardware than C#, because C# probably has everything you need to control it, to the same degree that C allows you to. But if you work in these languages for a while, and look at the code that you ended up producing, then again you will absolutely find that it would be ridiculous to not admit that C gives you better control.

And you could even extend this to Rust, because the language encourages you to use high-level prefabricated components. It discourages you from doing low-level things, at least a little bit I think (I'm not a Rust user).

I think what you are doing all the time, is you are being a smart-arse, nothing else. What interesting low-level performant things have you actually programmed lately?


> But if you work in these languages for a while, and look at the code that you ended up producing, then again you will absolutely find that it would be ridiculous to not admit that C gives you better control.

I disagree somewhat. C gives you better control, and you have to accept that gift to get anything done. The likes of (modern) C# give you better control, but you can reject the gift if you want, and program in higher abstractions. You can also accept it in some places and reject it in others.

With C, you can reject the control, too, but then, you have to use third party libraries (or write them yourselves), and using those, your code looks less nice because it cannot escape C’s syntax (yes, macros help a bit there, but having real syntax beats it)


Mind you, the "you can use this other way as you see fit" idea often isn't practical (like combining GC'ed and non-GC'ed parts). You generally want a whole codebase to be structured according to shared idioms. Otherwise the interfacing cost becomes too high.

I have doubts that you can program easily in a C-style way in C# without adding lots of annotations everywhere in many places. But don't know, maybe I'm wrong, I did a search for a simple C-style arena allocator in C#, and it looked acceptable, it was quite close. The most annoying thing was maybe keyword boilerplate.


Smart-arse is comparing C versus JavaScript, instead of C vs C++, for example.

And then coming with such lengthy ad hominem.

Let make a fun exercise for the audience, given your performance remark.

Paste a random C code that I should replicate in whatever language I feel like.

There is one rule.

If the sample code is pure ISO C, then I will only use what is in the standard of whatever language I pick up.

If the sample code makes use of single language extension not part of ISO C, then I will have the freedom to also pick whatever language extensions I feel like.


So do you want to "rewrite" some C code in C++ to think you made a point? I think you should do C# or Java.

What about you do xxHash? Should be quite basic, not a lot of complicated structures. https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h

Or what about you do an audio or video codec? Or an operating system?

Not going to paste any of my own code, because any non-trivial stuff is hundreds to thousands of lines. But one more example (that I recently did myself): Create a block allocator (power of two blocks) with bookkeeping in shadow memory (administered in individually committed zones representing virtual memory regions of 64 MB (2^26)). Any used memory has bookkeeping support for being sub-allocated at any and all levels up from 64 KB (2^16) to 64 MB (2^26), and even higher (by joining committed regions). Individual blocks are collected (using intrinsic linking, because no memory allocation) in a hierarchy of pools of same-sized chunks that have the same parent, and can be recursively sub-allocated on any smaller chosen power-of-2 level, and finally be consumed in linear fashion (arenas). Blocks are pooled with a moderate retain policy (watermark system) to allow subsystems to almost completely avoid any system calls and avoid inter-thread synchronisation. The memory overhead must be below 1% even though it's totally flexible (as said has metadata for all levels from 64 KB up).

The bookkeeping should function on 32-bit systems (small virtual space, occupancy range from megabytes to 3 GB) as well 64-bit systems (2^48-2^57 bytes of virtual address space, occupancy range from megabytes to hundreds of gigabytes) with reasonable overhead compared to actual usage.

This requires intrusively linked lists, occupancy bitmasks, bit-counting and bit-prefix counting, OS syscall access (virtual memory), pointer arithmetic (alignment needed to address shadow bookkeeping memory) and thread synchronisation. The reference code is >> 95% pure ISO C++11 (could be C99 with few changes), with a little platform code glued in. It works on Windows but it could be ported to Linux in a few hours. It supports a mostly-immediate-mode GUI with hundreds of thousands (maybe millions?) of small variable-sized allocations per second. Allocation has almost completely disappeared from the CPU profile, well below 1% of CPU usage.


I said any systems programming language, and stated the rules, so I gather you don't want to play this game after all.

> Or what about you do an audio or video codec? Or an operating system?

There are already plenty of examples out there, Claude can probably help you there regarding history of such products not written in C, or where C required help from Assembly code.

You can start by researching IBM i, z/OS, OS 2200, Xerox Alto, DirectX and Metal (C++ for the most part, and Objective-C++ on the 2nd)

> This requires intrusively linked lists,....

And the C99 version is impossible to be written in Ada95 because?


Who uses Ada95 or whatever? You are fighting strawmans, nobody has made the claims you imply. My personal opinion is just that low-level access is essential to make interesting and performant programs. Object-type fluff doesn't help with that, it's getting in the way.


> Smart-arse is comparing C versus JavaScript, instead of C vs C++, for example.

Using C++ as your other comparison point when arguing that C isn't low level is by far the most smartass idea in this thread.


Not at all, because for C heads, C++ can't do what C does, for whatever imaginary reasons.


I challenge you to find one random person making that claim and to present it with a straight face. What kind of ghosts are you fighting?


Yeah, I see plenty of people complain that C++ can't be simple because devs will keep reaching into the cookie jar, but that's not the language being unable to do something C can.

The only complaint I see about C++ not being capable is the correct observation that more platforms have C compilers than C++.

Either way, C++ spans a big range that goes just as low level as C. Even if these complaints are real they don't make it a reasonable comparison point for the "C is actually high level" argument.


Requesting a block of system memory, by address, and writing to it.

This is common with C, when interfacing with hardware.


Define how you want to write to that system memory without OS syscall.

What exact C code did you had in mind?

So that the counter example is close enough to it in exposing the same semantics.


> If the sample code makes use of single language extension not part of ISO C

What are you even arguing right now? (Btw -ansi compiler flag)

> Smart-arse is comparing C versus JavaScript

I chose JavaScript to make the idea of a spectrum clearer using extremes. I can do C++ if you like. The machine doesn’t care about destructors, move, concepts, initializer lists, virtual methods, launder, or inheritance. You are programming against an abstract model further divorced from how x86 CPUs work.


That many features are not ISO, and any language can have extensions just like C, nothing special there.

To me choosing JavaScript as example against C, feels like the Tiger Beetle guy that initially chose JavaScript and then went to Zig because JavaScript did not deliver, go figure.

So many systems languages to chose from since 1958.


This responds to nothing in my comment.


Many other languages only have one compiler available to start with.

Each additional compiler supported by a project means variance in functionality and thus additional work for the project. That work could make the codebase more robust. Or it could be a ton of useless work. Or anything in between. Depends on the context of the project.


_You_ do that. All the time. And then you fight these strawmans.


And you reply to that all the time with the C bias as well, oh well.


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

Search: