joaohaas (u/joaohaas)

joaohaas commented on Google will allow only apps from verified developers to be installed on Android 9to5google.com/2025/08/25... · Posted by u/kotaKat

godelski · 4 days ago

  > What they want is to get rid of apps like YouTube Vanced

I think it is also very telling where they're rolling out first. Brazil, Indonesia, Thailand, and Singapore.

It felt weird that the official press release was quoting entities from these countries, as if it should give confidence to the rest of the world. I can't imagine what these countries would want with apps that can be traced back to a government id...

Vanced and such is more of a First World/Western issue. I don't think you're wrong but I got a strong gut feeling there's other pressures in the works. Just something doesn't smell right...

joaohaas · 3 days ago

>Vanced and such is more of a First World/Western issue

What? I'm from Brazil and Vanced is as big, if not bigger here. In fact, most of my 'first world' friends just pay for YouTube Premium (or whatever it is called), and these kinds of workarounds are mostly used in countries with less purchasing power.

joaohaas commented on The surprise deprecation of GPT-4o for ChatGPT consumers simonwillison.net/2025/Au... · Posted by u/tosh

perlgeek · 21 days ago

GPT-5 simply sucks at some things. The very first thing I asked it to do was to give me an image of knife with spiral damascus pattern, it gave me an image of such a knife, but with two handles at a right angle: https://chatgpt.com/share/689506a7-ada0-8012-a88f-fa5aa03474...

Then I asked it to give me the same image but with only one handle; as a result, it removed one of the pins from a handle, but the knife had still had two handles.

It's not surprising that a new version of such a versatile tool has edge cases where it's worse than a previous version (though if it failed at the very first task I gave it, I wonder how edge that case really was). Which is why you shouldn't just switch over everybody without grace period nor any choice.

The old chatgpt didn't have a problem with that prompt.

For something so complicated it doesn't surprise that a major new version has some worse behaviors, which is why I wouldn't deprecate all the old models so quickly.

joaohaas · 21 days ago

Yes, it sucks

But GPT-4 would have the same problems, since it uses the same image model

joaohaas commented on Modern Node.js Patterns kashw1n.com/blog/nodejs-2... · Posted by u/eustoria

joaohaas · 25 days ago

  try {
    // Parallel execution of independent operations
    const [config, userData] = await Promise.all([
      readFile('config.json', 'utf8'),
      fetch('/api/user').then(r => r.json())
    ]);
    ...
  } catch (error) {
    // Structured error logging with context
    ...
  }

This might seem fine at a glance, but a big grip I have with node/js async/promise helper functions is that you can't differ which promise returned/threw an exception.

In this example, if you wanted to handle the `config.json` file not existing, you would need to somehow know what kind of error the `readFile` function can throw, and somehow manage to inspect it in the 'error' variable.

This gets even worse when trying to use something like `Promise.race` to handle promises as they are completed, like:

  const result = Promise.race([op1, op2, op3]);

You need to somehow embed the information about what each promise represents inside the promise result, which usually is done through a wrapper that injects the promise value inside its own response... which is really ugly.

joaohaas commented on JSON is not a YAML subset (2022) john-millikin.com/json-is... · Posted by u/AndrewDucker

JonChesterfield · a month ago

    YAML.load '[FI,NO,SE]'
    => ["FI", false, "SE"]

Ah yes, I remember that.

    %YAML 1.2

Absolutely no truck with this either. If you want another whitespace obsessed bug farm, you can give it a new name.

Stay with XML. It's fine. I wrote a bunch earlier this evening, even though you're not really meant to edit it by hand, and that was fine too. Emacs totally understands what XML is.

joaohaas · a month ago

YAML sucking is no excuse to keep using XML. JSON, JSON5 and TOML are all great alternatives for projects.

joaohaas commented on There is no memory safety without thread safety ralfj.de/blog/2025/07/24/... · Posted by u/tavianator

munificent · a month ago

I agree with the author's claim that you need thread safety for memory safety.

But I don't agree with:

> I will argue that this distinction isn’t all that useful, and that the actual property we want our programs to have is absence of Undefined Behavior.

There is plenty of undefined behavior that can't lead to violating memory safety. For example, in many languages, argument evaluation order is undefined. If you have some code like:

    foo(print(1), print(2));

In some languages, it's undefined as to whether "1" is printed before "2" or vice versa. But there's no way to violate memory safety with this.

I think the only term the author needs here is "memory safety", and they correctly observe that if the language has threading, then you need a memory model that ensures that threads can't break your memory safety.

Go lacks that. It seems to be a rare problem in practice, but if you want guarantees, Go doesn't give you them. In return, I guess it gives you slightly faster execution speed for writes that it allows to potentially be torn.

joaohaas · a month ago

Your example does not classify as 'undefined behavior'. Something is 'undefined behavior' if it is specified in the language spec, and in such case yes, the language is capable of doing anything including violating memory safety.

joaohaas commented on (On | No) Syntactic Support for Error Handling go.dev/blog/error-syntax... · Posted by u/henrikhorluck

dcow · 3 months ago

Where there’s a will there’s a way. Swift is almost universally compatible with objective-c and they are two entirely different languages no less. If an objective-c function has a trailing *error parameter, you can, in swift, call that function using try notation and catch and handle errors idiomatically. All it takes is for one pattern to be consistently expressible by another. Why can’t Result/Either types be api-compatible with functions that return tuples?

joaohaas · 3 months ago

As I mentioned, it's the same method Rust uses, and there are multiple reasons on the papers linked on why that is not desired.

joaohaas commented on (On | No) Syntactic Support for Error Handling go.dev/blog/error-syntax... · Posted by u/henrikhorluck

hu3 · 3 months ago

> Go cannot solve the single problem everyone immediately has with the language...

What? Survey says 13% mentioned error handling.

And some people actually do prefer it as is.

https://go.dev/blog/survey2024-h1-results

joaohaas · 3 months ago

This doesn't mean the rest of the 87% enjoy it. Honestly, I'd rather the next survey included a question "are you satisfied with the current error handling approach"

joaohaas commented on (On | No) Syntactic Support for Error Handling go.dev/blog/error-syntax... · Posted by u/henrikhorluck

codedokode · 3 months ago

Golang is also ugly, for example some fields start with a capital letter and some do not.

Also I don't understand how to implement transparent proxies in Go for reactive UI programming.

joaohaas · 3 months ago

If you don't care about field access just always write fields with uppercase. Any APIs you're using only expose uppercased variables as well, so it'll stay consistent.

The public/private stuff is mostly useful for publishing modules with sound APIs.

joaohaas commented on (On | No) Syntactic Support for Error Handling go.dev/blog/error-syntax... · Posted by u/henrikhorluck

yusina · 3 months ago

It fascinates me that really smart and experienced people have written that page and debated approaches for many years, and yet nowhere on that page is the Haskell-solution mentioned, which is the Maybe and Either monads, including their do-notation using the bind operator. Sounds fancy, intimidating even, but is a very elegant and functionally pure way of just propagating an error to where it can be handled, at the same time ensuring it's not forgotten.

This is so entrenched into everybody writing Haskell code, that I really can't comprehend why that was not considered. Surely there must be somebody in the Go community knowing about it and perhaps appreciating it as well? Even if we leave out everybody too intimidated by the supposed academic-ness of Haskell and even avoiding any religios arguments.

I really appreciate the link to this page, and overall its existence, but this really leaves me confused how people caring so much about their language can skip over such well-established solutions.

joaohaas · 3 months ago

It was not forgotten. Maybe/Either and 'do-notation' are literally what Rust does with Option/Result and '?', and that is mentioned a lot.

That said as mentioned in a lot of places, changing errors to be sum types is not the approach they're looking for, since it would create a split between APIs across the ecosystem.

joaohaas commented on (On | No) Syntactic Support for Error Handling go.dev/blog/error-syntax... · Posted by u/henrikhorluck

ivanjermakov · 3 months ago

No one here mentioned Zig approach there, so I'll share: https://ziglang.org/documentation/master/#try

Zig has try syntax that expands to `expr catch |e| return e`, neatly solving a common use case of returning an error to the caller.

joaohaas · 3 months ago

Zig 'error types' are a sum type, while Go ones are just values.

And even then this is just the same as the '?' operator Rust uses, which is mentioned in the post.