rbehrends

First of all, yes, labor is taxed much higher in Germany than in the US (PPP adjustment already takes VAT on prices into account, so that doesn't matter in this case). In fact, Germany has one of the highest taxations of labor in the world.

What makes this analysis tricky is disposable vs. discretionary income. The US clearly comes out on top when it comes to disposable income (labour is taxed too much in Germany compared to capital income and wealth).

The picture gets more complicated when you look at discretionary income, which also accounts for regular bills, such as rent, college tuition, out of pocket expenses for health care, childcare, and such. All the taxes you pay in Germany do also pay for something, after all. There is unfortunately very little data for this type of comparison.

American workers still get higher salaries than elsewhere in the OECD and growth in such industries isn't out competing those same industries in other OECD countries.

I used to think that also, probably because FAANG salaries had skewed my perception, but after looking at the data, this does not seem to be actually true, at least not in general.

For example, Germany has a somewhat higher annual median gross salary for full-time employees than the US (PPP-adjusted, BLS/DESTATIS salary data, OECD PPP values).

Of course, this is the median salary. America absolutely offers higher salaries at the top end (and I mean much higher, often by a factor of 2-3 for highly qualified professionals, such as software engineers and doctors). But that also means correspondingly lower salaries at the low end. And of course, labor is taxed heavily in Germany, so discretionary/disposable income may look different in the end on a case-by-case basis.

It means that this is a cabinet decision, not (yet) legislation. It still has to go through the Bundestag. Given the opposition within the SPD and the idea being very unpopular among voters, it is not yet clear whether this will actually become law.

It is still very worrying and the unfortunate result of a lot of things going wrong at the cabinet level.

I am not sure I'm buying this. The raison d'être for our existing software engineering methods is that humans make mistakes and we needed to contain the effects of these mistakes; and without an appropriate methodology to do that, software defects will just accumulate over time. Worse, once they show up, nobody understands the code well enough to do anything about them, or at least not without considerable time investment.

This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software.

Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate.

This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects.

Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.

My concern with most of these visual benchmarks, popular as they are, is that they are likely more indicative of knowledge (i.e. how comprehensive the training data is and how well it can be retrieved from the model) than of reasoning ability. I don't see in particular how a model would construct a CoT that mapped somehow to a representation of the cube geometry and its animations in latent space without a large chunk of that being pre-existing information.

I mean, Western providers such as Fireworks AI/Microsoft Foundry (US) or Tensorix (EU) already are offering many of these models on their own hardware with all the typical compliance boxes ticked through a standard API. Either as open weight models or through partnerships with Chinese firms, or both. DeepSeek etc. do not have to do anything here other than making their models available to Western partners (either as open weights or through a licensing agreement).

For instance, OP's definition H = Var[G] / Var[P] seems to bypass the issues you mentioned:

No, this is exactly the definition I am talking about. The problem is that while theoretically you could work with Var(G)/Var(P) even if Cov(G, E) ≠ 0, studies are not designed to capture that.

In fact, the standard ACE model [1] used in twin studies explicitly assumes among other things that there is no gene-environment correlation. This means that it gets silently added to one or more of the ACE components; not because of any ill intentions, but simply because if you included covariance, the resulting system of equations would be underdetermined and could not be solved [2].

But to make matters worse, gene-environment correlation/interaction itself is disproportionately absorbed by the A and C components rather than E. All this can lead to inflated heritability estimates.

And to clarify, I am not making any pronunciations about how much relevance or magnitude that effect has; for all I know, this could in the end be a minor effect. My point here is that there is a lot of mathematical handwaving going on with very limited testability of the modeling.

[1] https://en.wikipedia.org/wiki/ACE_model

[2] If you want to be precise, you need to actually distinguish between gene-environment correlation and interaction and use P = G + E + (G x E), but that makes the system even more underdetermined, because now we have both Cov(G, E) and Var(G x E) to worry about.

That matches what I assumed it meant, and it seems like OP and the post are arguing that that is some kind of surprising interpretation.

The unintuitive part is that in quantitative genetics, heritability is defined in terms of variance in traits at the population level, not as the passing of traits from parents to offspring (that would be heredity [1]). Of course, I may have misinterpreted what you said in your OP when you cited the wiktionary definition of "[g]enetically transmissible from parent to offspring", and if so, I apologize, but at the time it seemed to me that you were talking about heredity.

Uhm, no. That is exactly what I (and I think most people) would expect the answer to be.

What the article is talking about is that if you fix Var(E) = 0, then Var(P) = Var(G) in the standard heritability model, i.e. all phenotypic variance is explained entirely by genotypic variance (because in that model, Var(P) = Var(G) + Var(E)).

Fun fact (even if only tangentially unrelated): In Western countries, wearing glasses is a highly heritable trait, because wearing glasses is a strong proxy variable for refractive error [2], such as nearsightedness, which is highly heritable. It is often brought up as another example of how the quantitative genetics definition does not match conventional use of the word.

[1] https://en.wikipedia.org/wiki/Heredity

[2] https://en.wikipedia.org/wiki/Refractive_error

Heritability has a very specific meaning in quantitative genetics [1], which in many ways is not what your intuition would suggest [2]. It is this usage that the article talks about that.

That said, there are plenty of critiques of this definition of heritability, and not just because it is different from what a layperson would expect it to mean.

For example, the way it is used also usually has a big problem in that the standard formula assumes that Cov(G, E) = 0 (or at least is negligible), whereas in practice that is not actually true [3, 4].

This definition of heritability is also mathematically flawed in that it assumes (without evidence) that P = G + E, or at least can be reasonably approximated this way. Given that human development is the result of a feedback loop involving genetic and environmental factors, one would expect a model closer to something like a Markov chain. Proposed justifications of a simple additive model as an approximation (e.g. via the central limit theorem for highly polygenic traits) have to my knowledge never been tested.

More recent genome-wide association studies [5] have actually shown a considerable gap between heritability estimates from genotype data and heritability estimates from twin studies, known as the "missing heritability problem".

[1] https://en.wikipedia.org/wiki/Heritability

[2] https://en.wikipedia.org/wiki/Genetic_variance

[3] https://en.wikipedia.org/wiki/Gene%E2%80%93environment_inter...

[4] https://en.wikipedia.org/wiki/Gene%E2%80%93environment_corre...

[5] https://en.wikipedia.org/wiki/Genome-wide_association_study

No, the problem is that when logging in, the provider's website can provide an authentication shell command that OpenCode will send to the shell sight unseen, even if it is "rm -rf /home". This "feature" is completely unnecessary for the agent to function as an agent, or even for authentication. It's not about it being the default, it's about it being there at all and being designed that way.

I am more concerned about their, umm, gallant approach to security. Not only that OpenCode is permissive by default in what it is allowed to do, but that it apparently tries to pull its config from the web (provider-based URL) by default [1]. There is also this open GitHub issue [2], which I find quite concerning (worst case, it's an RCE vulnerability).

[1] https://opencode.ai/docs/config/#precedence-order

[2] https://github.com/anomalyco/opencode/issues/10939

There is the Parliament's legislative train website [1]. However, it only tracks actual legislative steps, not the intra-Council negotiations, so the proposal's page appears to be have been largely inactive since 2024 [2].

[1] https://www.europarl.europa.eu/legislative-train/

[2] https://www.europarl.europa.eu/legislative-train/theme-a-new...

The shell, perl and python are likely for scripting and not used during runtime.

Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.

Of course the member states drafted and agreed to those and that's why pressure should be on governments to stop hand over the keys to Brussels.

What specific example are you thinking of where additional power was handed to Brussels through an amendment of the treaties?

That's in addition to the constant Commission push for more power...

If you are worried about the executive trying to expand its power (and something that should be kept in check), may I suggest that the US is not actually a great example right now for how to avoid that?

The EU does not so as time passes the EU's power keeps creeping up.

Actually, the EU has the same concept of enumerated powers (called "competences" in the case of the EU). They are listed in articles 2-6 TFEU [1]. You may argue over whether the EU has too many competences or (in some areas) too little, but it's the same principle. The EU cannot legislate outside areas where power has been expressly conferred to it by the treaties.

This is in fact one point of contention over the "chat control" legislation. It is supposed to be enacted under the "internal market" competence, but similar to the US commerce clause, there is a legal debate over whether that competence is actually sufficient to enable such legislation or whether it is legal cover for encroachment on competences reserved to the member states.

This would of course be up to the ECJ to decide, just as the US Suprement Court would have to decide if any given US federal legislation is covered by the commerce clause.

In addition, there is the Charter of Fundamental Rights, and the ECJ could also strike down EU legislation (as it has done before) if it violates the rights protected by the Charter.

[1] https://en.wikisource.org/wiki/Consolidated_version_of_the_T...

What you are proposing would amount replacing the current bicameral legislature (with the European Parliament as the lower house and the Council of the EU as the upper house) with a unicameral legislature. That would actually make it easier for bad laws to be passed, especially as the supermajority required in the Council is currently the biggest obstacle for this kind of legislation.

I'll also note that nothing here is per se undemocratic. Both the Parliament and the Council are made up of elected members. The members of the Council (as members of the national governments) are indirectly elected, but elected all the same. Direct election is not a requirement for a democracy (see election of the US president or the US Senate prior to the 17th amendment or the Senate of Canada right now).

That does not mean that there isn't plenty of valid criticism of the EU's current structure, but claiming that it is not "actually democratic" falls far short of a meaningful critique.

Aside from the often cited nullability issue, here is an (incomplete) list of important things that Kotlin still does better than Java:

- First class, fully functional closures. - Non-abstract classes and methods are final by default. - Named parameters. - Easy to write iterators via sequence { ... } - First class support for unsigned types.

The same argument would apply to any non-compacting allocator, because the worst case memory blowup due to external fragmentation is huge. But such cases are extremely rarely observed in practice, so people use e.g. standard malloc()/free() implementations or non-compacting garbage collectors without being concerned about that.

In addition, there are plenty of cases where memory usage is unbounded or excessive, not because of allocator behavior, but because of programming mistakes. In fact, memory can sometimes blow up just because of large user inputs and very few systems are prepared for properly handling OOM conditions that happen legitimately.

Case in point: Both CRuby and Apple's JavaScriptCore have garbage collectors that use conservative stack scanning and are widely used in production systems without the world ending.

That said, you're probably not going to use conservative stack scanning because of collection speed alone. There are other trade-offs between conservative stack scanning and precise stack scanning that weigh more heavily.

I'll add the caveat that I would be very cautious about using a conservative GC on 32-bit systems, but on 64-bit systems this is about as much of a concern as memory fragmentation.

What happens under the hood is that a `sequence {}` call creates an instance of `SequenceScope`, which has `yield()` and `yieldAll()` methods. When executing the block, `this` will reference that particular instance and `yield()` is essentially `this.yield()` and will call the method on the scope instance.

The actual functionality is then provided by the coroutine system, though a lot of the heavy lifting is done by the optimizer to eliminate all or most of the runtime overhead.

As somebody who uses and likes both Kotlin and Python (and quite a few other languages), I'd be cautious with using a subjective term such as "more expressive", too, but I can possibly shed some light on where such feelings come from.

Personally, I see Kotlin as the closest thing to a statically typed Smalltalk that we have among major languages, and that's a major draw.

A key part here is that Kotlin closures are fully-featured equivalents of Smalltalk blocks (up to and including even non-local returns [1]), whereas in many other languages that falls short. Java does not allow mutation of local variables and Python restricts lambdas to normal expressions.

I find code whose behavior can be parameterized by code to be an essential feature of modern-day programming and this should be as frictionless as possible.

This is also a situation where syntax matters, and while it isn't quite as nice as Smalltalk, Kotlin's syntax (esp. with trailing closures) make such code as readable as possible in a brace-style language with minimal additional syntactic noise.

In a similar vein, the functionality of Smalltalk's cascades is offered through scope functions [2], especially `.run {}`.

But ultimately, fully-featured closures (and the fact that they are widely used in the standard library) power a lot of the things that people seem to like about Kotlin.

That does not mean that there aren't downsides. The limitations of running on the JVM are one (e.g. while Kotlin has workarounds for the JVM's type erasure, they're still workarounds), and then Gradle is arguably Kotlin's weakest point (which apparently even JetBrains are seeing, given their investment in Amper).

That said, personally I'd say Kotlin's static typing and performance would be the primary reasons for me to reach for Kotlin over Python, not necessarily expressiveness. Type annotations in Python + mypy etc. just aren't the same experience, and writing performance-sensitive code in Python can be very tricky/hacky when you can't delegate the hot paths to numpy or other existing C/C++/Rust libraries.

Conversely, Python often has a leg up when it comes to fast prototyping and scripting, even with Kotlin Worksheets in IntelliJ IDEA and with kscript.

[1] Which, to be clear, are a nice-to-have thing, not essential, but still impressive that even that was covered, when previously Ruby was the only major language I know of that did it.

[2] https://kotlinlang.org/docs/scope-functions.html

Like this?

  sequence { for (x in 0..<10) for (y in 0..<10) yield(x*y) }.toList()

On the other hand, you're not limited to for loops/ifs inside such a generator, but can use fairly arbitrary control flow.

the 'yield' keyword

Am I missing something here?

  $ cat fib.kts
  fun fib() = sequence {
    var a = 1; var b = 1
    while (true) {
      yield(a)
      a = b.also { b += a }
    }
  }

  println(fib().take(10).joinToString(" -> "))
  println(fib().first { it >= 50 })
  $ kotlin fib.kts
  1 -> 1 -> 2 -> 3 -> 5 -> 8 -> 13 -> 21 -> 34 -> 55
  55

Note: I wasn't criticizing the paper. I was criticizing the comment, which claimed "it’s better" to view these as special cases.

I didn't assume you were. My note about it being a good paper was just a general "this is worth reading" recommendation.

"Can handle" is quite the hedge. You "can" walk across the continent too, but at what cost?

It's not a hedge. You claimed that (tracing) GC can handle cycles, while RC was "the opposite", which I read to mean that you believe it cannot.

While we are at it, let's go through the basics of trial deletion.

Trial deletion first looks at possible candidates for objects involved in a cycle (in the original algorithm, those were objects whose RC got decremented without reaching zero). Then, you do a recursive decrement of their children's (and their children's children's, and so forth) reference counts.

Unlike with regular reference counting decrements, you visit children even if the reference count doesn't reach zero. The net result is that reference counts are reduced only along internal paths, but that objects that are still reachable from external paths have reference counts > 0 after that.

Thus, any object with a reference count of zero after this step must be part of an internal cycle and can be deleted. All other objects have their original reference counts restored.

Because trial deletion operates on reference counts differently, it's not something that you can easily implement as a library, which is why you don't see it much except when a language implementation chooses to go with reference counting over a tracing GC.

You're saying Python uses RC to handle reference cycles, and doesn't need a GC for that? If so please ask them to update the documentation, because right now it specifically says "you can disable the collector if you are sure your program does not create reference cycles". https://docs.python.org/3/library/gc.html

This is a terminology thing. Python uses a variant (generational) trial deletion approach [1]. It's not a traditional tracing GC, and it's also not inaccurate, because GC can mean more than using a traditional tracing GC.

Nobody said "real time". I just said "hard guarantee".

I was not sure what you meant, so I answered both, as you may have noticed.

[1] https://github.com/python/cpython/blob/796b3fb28057948ea5b98...

First of all, I recommend giving the paper a read, because I think you're misunderstanding the claim (plus, it is a very good paper). The claim is not that they are equivalent, but that tracing GC and reference counting are dual solutions to the same problem, two ends of the same spectrum if you will, with hybrid solutions existing in between.

Second, what you seem to consider to be fundamental characteristics of tracing GC and RC is not in fact so fundamental.

For starters, RC absolutely can handle cycles (e.g. through trial deletion). Such implementations may be difficult or impossible to implement as pure library solutions, but there is nothing that says it can't be done. The most prominent example of a programming language that uses such an approach is probably Python.

Nor does the claim that tracing GC cannot provide hard performance guarantees in the general case (while RC does) hold up under closer examination. Leaving aside the problem that it's already non-trivial to provide hard real time performance guarantees for malloc()/free() and ignoring the issue of cascading deletions, it doesn't hold under the more relaxed assumptions discussed downthread.

For starters, we have such predictability only for the single-threaded case, not for arbitrary multi-threaded situations. And even in the single-threaded case, there are real use cases where predicting performance becomes functionally intractable. Examples are implementations of binary decision diagrams or certain persistent data structures, where the presence of shared subgraphs of arbitrary size make predicting performance of individual deallocations impractical.

In contrast, in the single-threaded case we can absolutely bound individual operations of a tracing GC by either a constant or (in the case of arbitrarily sized allocations) make them linear in the number of bytes allocated (e.g. Baker's treadmill).

What is true is that in the absence of cycles, (naive) reference counting will free memory at the earliest opportunity, which is not something we can say for tracing GC.

You can express immutability simply by making all instance variables private and not providing any methods to modify them.

Delaying deletions can result in significant memory overhead [1].

TANSTAAFL, as they say.

[1] https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

It may not be a problem in a language like Rust, where the compiler understands the concept of immutability. But most (if not all) mainstream languages except Rust don’t. Your object may be immutable in January but in February someone makes a change in a class used 10 layers below and suddenly your class is no longer immutable. Add invisible sharing to that and your code explodes.

No offense, but this strikes me as a strawman argument. What software design methodology leads to immutable types suddenly being made mutable? Outside of dynamic languages, where is support for immutability not there?

Note that any language with proper information hiding can expressly do immutability (literally going back to the days of Modula-2), plus of course several mainstream languages that have first-class language features to represent immutability for added convenience.

Finally, this is only one example. One underlying problem is that if all reference counts need to be capped at one, you have to either switch to full reference counting or to copy the underlying data.

You can see this play out in the std::collections::HashSet interface. Operations like intersection, union, difference, and symmetric difference return iterators rather than sets. While there are also operators that do return sets, such as bitor, that's implemented as follows.

    fn bitor(self, rhs: &HashSet<T, S>) -> HashSet<T, S> {
        self.union(rhs).cloned().collect()
    }
    

Abstractions understood as „I can change only X without changing Y” (aka GoF OOP patterns or most Clean Code OOP patterns) are overrated anyways. Readability and understandability of code is more important than ability to add something without changing something else. If code is readable and constraints are enforced by the compiler, it is easy and safe to change.

So, you never work with third-party libraries where you do not control the API and have never written libraries to be consumed by other teams/third parties?

That is a niche case not a common one though.

It was an example meant as an illustration. The general case of "collection of objects" is hardly niche.

This attitude of non-systems programmers is why people argue garbage collection is slow.

I started programming writing Z80 assembler in the 1980s, counting T-states in order to make hard realtime code work. I wrote a graphics driver for Atari ST/TT hardware not to soon after. I think I have a pretty good idea what working in a real-time and/or resource-constrained environment means.

This attitude of non-systems programmers is why people argue garbage collection is slow.

That is an incorrect generalization. In fact, I see plenty of inefficient code in C++ and Rust (e.g. because a lot of the workarounds for not having GC require additional copying).

Sure they are not leaking memory, but garbage collection is not enough more efficient than reference counted as to make up for thousands of destruction's when the more complex reference counted version only had a couple.

This is some really unclear statement. If you're trying to make a connection between absence of (tracing) GC and having value types, they are not inherently related. You can have tracing GC and value types (e.g. C#) or reference counting and a lack of value types (e.g. Python).

What is true is that in general memory allocation is relatively expensive, so you want to avoid unnecessarily allocating objects, but that's true regardless of whether you use malloc()/free() or a garbage collector and the strategies for dealing with that are the same in both cases.

Yes the code is more complex, but it is also faster and that is a trade off I'll take.

Again, this is an untrue generalization.

Still no, because STW GC can pause innocent code in arbitrary unexpected moments.

Well, yes, that's the problem, isn't it? And that's the point I was making. Pauses in the main thread absolutely count for latency purposes. Note that in most stop-the-world GCs you also can have pretty good control over when the GC is invoked, and that doesn't make things better.

The idea that you can always predict when cascading deletes happen in RAII code is also misleading. They can easily be hidden behind an abstraction barrier. Do you exactly know what's happening under the hood in all third-party libraries that you use, just for an example?

If you’re pausing the thread because the thread is doing some work eg calling into system to do I/O, this is not considered a pause

In real-time scenarios (soft or hard), it absolutely is. "Regular" operations are absolutely part of your latency budget, and if "regular" operations can exceed it, you absolutely have a problem. See e.g. pretty much any of Gil Tene's talks on the subject.

This is not a problem if the returned object is immutable. If you're returning mutable objects, then that already needs to be documented as part of the AI and not an incidental discovery from the object being reference counted.

In any event, that is hardly the only case of manual memory management breaking abstractions.