That phrase suggests more that the author believes this is done for spectacle, knowing that it will attract attention to the researcher far more than a nice-looking painted statue would. Basically he seems to be accusing these researchers of doing flame-bait for clicks, like those kitchen-top meal TikTok videos designed to get engagement by making people angry.

The problem is not a lack of naturalism, it's obvious mistakes in the way the naturalistic poses are attempted. Many of Rublev's icons have obvious mistakes in the way joints are painted, for example - but not all of them or the exact same thing; it's not a style, it's simply a limitation of his skills. Many later painters who were inspired by him have corrected this mistake, not sought to reproduce it.

Not to mention, Rublev lived at the end of the Medieval period, and well into the Renaissance - the period where painterly skill in Europe was revitalized.

Again, I’m not sure why it matters. Henri Rousseau couldn’t draw for shit and yet people adore his art. The represented idea and its aesthetic execution are what people mostly respond to, not how realistic a figure’s joints happen to be. (And FWIW, a large number of Renaissance painters clearly have no idea what a female body looks like.)

While that would be miles better, there's still plenty wrong with it. Most advertising is designed to trick people into either buying something that they don't need at all (e.g. consuming more soda instead of drinking water, or getting some gadget, or more clothes than they need), or into buying the an objectively worse option (e.g. buying a more expensive fridge that will actually last less time). This is the goal of B2C advertising: tricking people to behave less rationally in their consumption behavior.

The only way to avoid this is to just block ads - even unobtrusive content-relevant ads. You may think ads can't trick you, but that has been shown time and time again to be false.

That second link says it all about how wise it would be to try:

> This guide provides instructions for building WebKit on Windows 8.1

It's not impossible that people would pay Firefox that much yearly to keep their current user-base from using ad blockers. However, what is impossible is to imagine Firefox would have anything close to their current user base if people were prevented from using ad blockers. Most likely they would shrink to almost 0 users overnight if they did this. There are very few reasons to use Firefox over Chrome or Safari (or even Edge) other than the much better ad blocking (or any ad blocking, on mobile).

That doesn't explain the apparent market share of 2--3%, which is still quite large if you think about.

I believe most non-techie users are just lingering, using Firefox just because they used to. Since Firefox doesn't have a built-in ad blocking and the knowledge about adblocking is not universal (see my other comment), it is possible that there are a large portion of Firefox users who don't use adblockers and conversely adblocking users are in a minority. If this is indeed the case, Mozilla can (technically) take such a bet as such policy will affect a smaller portion of users. But that would work only once; Mozilla doesn't have any more option like that after all. That's why I see $150M is plausible, but only once.

Of course, I don't know the actual percent of FF users that use ad block. But I think it's far more likely that it is a majority of current FF users, rather than it being a negligible minority. I think 2-3% of web users is not an implausible approximation of how many people use ad block overall on the web. It's not an obscure technology, it's quite well known, even if few people bother with it.

Edit: actually I'm way off - it seems estimates are typically around 30-40% of overall users on the web having some kind of ad blocker. So, the Firefox percentage being 60-80+% seems almost a given to me.

Ad-blockers are the most used extensions on firefox. Origin itself has 10m installs, there are others with 3m and few with 1m installs.

Depending on escape analysis, the array underlying the slice can get allocated on the stack as well, if it doesn't escape the function context. Of course, in this case, because we are returning a pointer to it via the slice, that optimization isn't applicable.

Agreed that it could in principle. But I can't immediately get it to do so: https://go.dev/play/p/9hLHattS8cf

Both arrays in this example seem to be on the heap.

Taking the address of those variables makes them escape to heap. Even sending them to the Printf function makes them escape to heap.

If you want to confirm, you have to use the Go compiler directly. Take the following code:

  package main
  import (
    "fmt"
  )
  type LogEntry struct {
    s string
  }
  func readLogsFromPartition(partition int) []LogEntry {
    var logs []LogEntry // Creating an innocent slice
    logs = []LogEntry{{}}
    logs2 := []LogEntry{{}}
    fmt.Printf("%v %v\n", len(logs), len(logs2))
    return []LogEntry{{}}
  }
  func main() {
    logs := readLogsFromPartition(1)
    fmt.Printf("%p\n", &logs[0])
  }

And compile it with

  $ go build -gcflags '-m' main.go
  # command-line-arguments
  ./main.go:15:12: inlining call to fmt.Printf
  ./main.go:21:12: inlining call to fmt.Printf
  ./main.go:13:19: []LogEntry{...} does not escape
  ./main.go:14:21: []LogEntry{...} does not escape
  ./main.go:15:12: ... argument does not escape
  ./main.go:15:27: len(logs) escapes to heap
  ./main.go:15:38: len(logs2) escapes to heap
  ./main.go:16:19: []LogEntry{...} escapes to heap
  ./main.go:21:12: ... argument does not escape

However, if you return logs2, or if you take the address, or if you pass them to Printf with %v to print them, you'll see that they now escape.

An additional note: in your original code from your initial reply, everything you allocate escapes to heap as well. You can confirm in a similar way.

The point the GP was making was that the following Go snippet:

  func foo() {
    x := []int { 1 }
    //SNIP 
  }

Could translate to C either as:

  void foo() { 
    int* x = malloc(1 * sizeof(int));
    x[0] = 1;
    //...
  }

Or as

  void foo() { 
    int data[1] = {1};
    int *x = data;
    //...
  }

Depending on the content of //SNIP. However, some people think that the semantics can also match the semantics of the second version in C - when in fact the semantics of the Go code always match the first version, even when the actual implementation is the second version.

The semantics are clearly defined as being the same as the C code I posted earlier. Why would one try to complicate the situation by thinking that it would somehow magically change sometimes?

Because people hear that Go supports value types and so is more efficient than Java because it can allocate on the stack*, and so they start thinking that they need to manage the stack.

* Of course, in reality, Java also does escape analysis to allocate on the stack, though it's less likely to happen because of the lack of value types.

I don't see the difficulty here. The slice is to be thought of as value type, as demonstrated in the C version. Just like in C, you can return it from a function without the heap because it is copied.

The confusion begins the moment you think Go variables get allocated on the stack, in the C sense. They don't, semantically. Stack allocation is an optimization that the Go compiler can sometimes do for you, with no semantics associated with it.

The following Go code also works perfectly well, where it would obviously be UB in C:

  func foo() *int {
    i := 7
    return &i
  }

  func main() {
    x := foo()
    fmt.Printf("The int was: %d", *x) //guaranteed to print 7
  }

Is that the case? I thought that it would be a copy instead of a heap allocation.

Of course the compiler could inline it or do something else but semantically its a copy.

A copy of what? It’s returning a pointer, so i has to be on the heap[0].

gc could create i on the stack then copy it to the heap, but if you plug that code into godbolt you can see that it is not that dumb, it creates a heap allocation then writes the literal directly into that.

[0] unless Foo is inlined and the result does not escape the caller’s frame, then that can be done away with.

ok, I'd agree with you in that example a go programmer would expect it to work fine, but a C programmer would not, but that's not the example the writer gave. I stand by my statement that the example the writer gave, C programmer would expect to work just fine.

I think the writer had multiple relatively weird confusions, to be fair. It's most likely that "a little knowledge is a dangerous thing". They obviously knew something about escape analysis and Go's ability to put variables on the stack, and they likely knew as well that Go slices are essentially (fat) pointers to arrays.

As the author shows in their explanations, they thought that the backing array for the slice gets allocated on the stack, but then the slice (which contains/represents a pointer to the stack-allocated array) gets returned. This is a somewhat weird set of assumptions to make (especially give that the actual array is allocated in a different function that we don't get to see, ReadFromFile, but apparently this is how the author thought through the code.

US colleges have a very open curriculum, where you have wide leeway in what classes you actually take, especially in the early years of study. If you're coming from more European-style universities, this is vastly different to the relatively rigid course set you'd take (with a few electives here and there).

They can't. Biological neural networks have no resemblance to the artificial neural networks of the kind used in LLMs. The only similarity is based on a vague computational abstraction of the very primitive understanding of how brains and nerve cells worked we had in the 50s when the first "neural network" was invented.