sacado2 (u/sacado2) - Readit News

sacado2 commented on GCC 16 considering changing default to C++20 inbox.sourceware.org/gcc/... · Posted by u/pjmlp

suby · 3 months ago

I think if you were to poll people, a significant portion would be repulsed by this catgirl aesthetic, or (though this isn't the case for Anubis) the cliche inappropriately dressed inappropriately young anime characters dawned as mascots in an ever increasing number of projects. People can do whatever they want with their projects, but I feel like the people who like this crap perhaps don't understand how repulsive it is to a large number of people. Personally it creeps me out.

sacado2 · 3 months ago

What? She's wearing a hoodie and a tee-shirt, how is that inappropriate? And how being young is inappropriate?

sacado2 commented on Go's Sweet 16 go.dev/blog/16years... · Posted by u/0xedb

liveoneggs · 3 months ago

You also need a version of the go compiler, possibly one new enough to handle some //go:magic:comments.

I agree that static linking is great and that python sucks but I was trying to say I can, very easily, mkdir new-py-program/app.py and stick __main__ in it or mkdir new-perl-program/app.pl or mkdir my-new-c-file/main.c etc.

For 2/3 of the above I can even make easy/single executable files go-style.

sacado2 · 3 months ago

Nowadays, with uv (and probably some other tools too) it's pretty easy to ship a python program on a machine that doesn't even have python on it, so it's pretty much a solved problem today (in most cases). But 5 or 10 years ago it was a real hassle that go solved elegantly. Yes you can make python executables but they are like 100 Mb even for a simple hello world. It's a last resort solution.

I don't understand your comment on magic comments. You don't need them to cross-compile a program. I was already doing that routinely 10 years ago. All I needed is a `GOOS=LINUX GOARCH=386 go build myprog && scp myprog myserver:`

sacado2 commented on Go's Sweet 16 go.dev/blog/16years... · Posted by u/0xedb

liveoneggs · 3 months ago

I personally like Go and appreciate its simplicity and tooling and everything but the example given is "making a folder" and "putting a ... main() func" in it. But, like, this is exactly as easy with every single other language that I can think of.

The second part "Running go install at the root ./.." is actually terrible and risky but, still, trivial with make (a - literally - 50 year old program) or shell or just whatever.

I get that the feelz are nice and all (just go $subcmd) but.. come on.

sacado2 · 3 months ago

> "making a folder" and "putting a ... main() func" in it

You can't do that with python for instance. First, you need a python interpreter on the target machine, and on top of that you need the correct version of the interpreter. If yours is too old or not old enough, things might break. And then, you need to install all the dependencies. The correct version of each, as well. And they might not exist on your system, or conflict with some other lib you have on your target machine.

Same problem with any other interpreted language, including Java and C# obviously.

C/C++ dependency management is a nightmare too.

Rust is slightly better, but there was no production-ready rust 16 years ago (or even 10 years ago).

sacado2 commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp

feoren · 4 months ago

> Should it be memory-efficient? Fast? Secure? Simple? Easy to formally prove? Easy for beginners? Work on old architecture? Work on embedded architecture?

What do any of these have to do with guarantees of long-term compatibility? I'm not arguing that there should be One Programming Language To Rule Them All, I'm asking about whether we can design better guarantees about long-term compatibility into new programming languages.

sacado2 · 4 months ago

The biggest source of incompatibility isn't in the programming languages. It's either in the specifications ("hmm maybe one byte isn't enough after all for a character, let's break all those assumptions") or in the hardware ("maybe 16 bits isn't enough of address space").

sacado2 commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp

feoren · 4 months ago

> Mathematical notation evolved a lot in the last thousand years

That is not counter to what I'm saying.

    Mathematical notation <=> Programming Languages.

    Proofs <=> Code.

When mathematical notation evolves, old proofs do not become obsolete! There is no analogy to a "breaking change" in math. The closest we came to this was Godel's Incompleteness Theorem and the Cambrian Explosion of new sets of axioms, but with a lot of work most of math was "re-founded" on a set of commonly accepted axioms. We can see how hostile the mathematical community is to "breaking changes" by seeing the level of crisis the Incompleteness Theorem caused.

You are certainly free to use a different set of axioms than ZF(C), but you need to be very careful about which proofs you rely on; just as you are free to use a very different programming language or programming paradigm, but you may be limited in the libraries available to you. But if you wake up one morning and your code no longer compiles, that is the analogy to one day mathematicians waking up and realizing that a previously correct proof is now suddenly incorrect -- not that it was always wrong, but that changes in math forced it into incorrectness. It's rather unthinkable.

Of course programming languages should improve, diversify, and change over time as we learn more. Backward-compatible changes do not violate my principle at all. However, when we are faced with a possible breaking change to a programming language, we should think very hard about whether we're changing the original intent and paradigms of the programming language and whether we're better off basically making a new spinoff language or something similar. I understand why it's annoying that Python 2.7 is around, but I also understand why it'd be so much more annoying if it weren't.

Surely our industry could improve dramatically in this area if it cared to. Can we write a family of nested programming languages where core features are guaranteed not to change in breaking ways, and you take on progressively more risk as you use features more to the "outside" of the language? Can we get better at formalizing which language features we're relying on? Better at isolating and versioning our language changes? Better at time-hardening our code? I promise you there's a ton of fruitful work in this area, and my claim is that that would be very good for the long-term health and maturation of our discipline.

sacado2 · 4 months ago

> When mathematical notation evolves, old proofs do not become obsolete! There is no analogy to a "breaking change" in math.

I disagree. The development of non-euclidean geometry broke a lot of theorems that were used for centuries but failed to generalize. All of a sudden, parallels could reach each other.

> Can we write a family of nested programming languages where core features are guaranteed not to change in breaking ways, and you take on progressively more risk as you use features more to the "outside" of the language?

We could, the problem is everyone disagrees on what that core should be. Should it be memory-efficient? Fast? Secure? Simple? Easy to formally prove? Easy for beginners? Work on old architecture? Work on embedded architecture? Depending on who you ask and what your goals are, you'll pick a different set of core features, and thus a different notation for your core language.

That's the difference between math & programming languages. Everyone agrees on math's overall purpose. It's a tool to understand, formalise and reason about abstractions. And mathematical notation should make that easier.

That being said, the most serious candidate for your "core language guaranteed not to change and that you can build onto" would be ANSI C. It's been there more more than 35 years, is a standard, is virtually everywhere, you can even write a conforming compiler for a brand new architecture, even an embedded microchip very easily, and most of not all the popular languages nowadays are build on it (C++ of course, but also C#, java, javascript, python, go, php, perl, haskell, rust, all have a C base), and they all use a C FFI. I'm not sure ANSI C was the best thing that ever happened to our industry, though.

sacado2 commented on Python 3.14 is here. How fast is it? blog.miguelgrinberg.com/p... · Posted by u/pjmlp

feoren · 4 months ago

You hope it doesn't?

> [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features

This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness.

There's no reason we can't be writing code that lasts 100 years. Code is just math. Imagine having this attitude with math: "LOL loser you still use polynomials!? Weren't those invented like thousands of years ago? LOL dude get with the times, everyone uses Equately for their equations now. It was made by 3 interns at Facebook, so it's pretty much the new hotness." No, I don't think I will use "Equately", I think I'll stick to the tried-and-true idea that has been around for 3000 years.

Forget new versions of everything all the time. The people who can write code that doesn't need to change might be the only people who are really contributing to this industry.

sacado2 · 4 months ago

> There's no reason we can't be writing code that lasts 100 years. Code is just math. Imagine having this attitude with math: "LOL loser you still use polynomials!? Weren't those invented like thousands of years ago? LOL dude get with the times, everyone uses Equately for their equations now. It was made by 3 interns at Facebook, so it's pretty much the new hotness." No, I don't think I will use "Equately", I think I'll stick to the tried-and-true idea that has been around for 3000 years.

Not sure this is the best example. Mathematical notation evolved a lot in the last thousand years. We're not using roman numerals anymore, and the invention of 0 or of the equal sign were incredible new features.

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

AlecSchueler · 6 months ago

Generally it's poor business to give a big chunk of your users am incredibly visceral and negative emotional reaction to your product update.

sacado2 · 6 months ago

Unless you want to improve your ratio of paid-to-free users and change your userbase in the process. They're pissing off free users, but pros who use the paid version might like this new version better.

sacado2 commented on Man trapped inside driverless car as it spins in circles bbc.com/news/videos/c70e2... · Posted by u/ksec

ajross · a year ago

> In a potentially life or death situation

Which, once more, was not happening here. The car was lost, not out of control. And the built-in solution was applied, and worked.

What do you really want here? You've never been in a Uber that took a wrong turn? Never argued with a cab driver about a route? Never been stuck in an airliner at the end of a runway waiting for clearance? Vehicles do things their occupants don't like all the time, and no one freaks out on the internet about it.

sacado2 · a year ago

I'm not saying it was happening here, I'm just taking this anecdote as food for thought. I'm appalled to learn that those vehicles don't have an emergency stop system. A real emergency stop. Not some remote-controlled or AI-assisted stuff. A low-tech, last-chance emergency stop, like the one you have in trains or on any industrial machine.

> You've never been in a Uber that took a wrong turn? Never argued with a cab driver about a route?

If a cab driver keeps cricling on a parking lot, again and again and again, never finding the obvious exit, I'll get a bit concerned and eventually tell him "OK, never mind, I'll find another way, just drop me there". If he refuses to let me off, and locks the doors, and keeps circling, I'll be extremely anxious. This is horror movie material.

sacado2 commented on Man trapped inside driverless car as it spins in circles bbc.com/news/videos/c70e2... · Posted by u/ksec

ajross · a year ago

There was no emergency! The car wasn't "spinning", it was just driving around a parking lot and failing to find a location to stop. This was a navigation failure, not a control failure. And the solution is to call the human operators who can control it remotely. Which is what happened, and they did. Pulling an "emergency stop" level would have made things worse and not better.

Is it embarassing for Waymo? Sure. But the BBC basically lied to you here, and you bought it. The circumstance you're imagining is not what happened. Just watch the video.

sacado2 · a year ago

> the solution is to call the human operators who can control it remotely

Sounds like a recipe for failure, to be honest. In a potentially life or death situation, the last thing I want is to rely on a remote human being. Plus, if the device entered an erroneous state, I certainly don't trust it to correctly interpret a remote "emergency stop" signal.

If the machine goes crazy (and there is no world where driving around a parking lot until the end of time is the rational expected behavior), the only safe option is a big, red, cut-circuit emergency stop button.

sacado2 commented on Some Go web dev notes jvns.ca/blog/2024/09/27/s... · Posted by u/tosh

voigt · a year ago

> In general everything about it feels like it makes projects easy to work on for 5 days, abandon for 2 years, and then get back into writing code without a lot of problems.

To me this is one of the most underrated qualities of go code.

Go is a language that I started learning years ago, but did't change dramatically. So my knowledge is still useful, even almost ten years later.

sacado2 · a year ago

As a teacher, I have a program I've been using for the last 8 years or so. I distribute the compiled version to students for them to compare their own results with what's expected. The program's written in go. I update it every other year or so. So I'm exactly in the case you describe.

I never had any issue. The program still compiles perfectly, cross-compiles to windows, linux and macos, no dependency issue, no breaking change in the language, nothing. For those use-cases, go is a godsend.