HN user

sacado2

1,470 karma

Developer, teacher, storyteller.

Posts5
Comments514
View on HN
Go's Sweet 16 8 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:`

Go's Sweet 16 8 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).

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").

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.

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.

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.

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.

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.

This is so true. If I was only allowed to keep a single electrical device at home, it would be my washing machine. If I want to exercise, I'll go for a walk while the machine magically washes my clothes, thank you very much.

clock in, and eat it at my desk

But then you're eating during your worktime. I'm pretty sure your "check out, order, take it, bring it back, eat it" routine takes more than 30 minutes total time. Your employer might be OK with that, and I don't know if that's common in the US, but in France, that's illegal (many people still do it, though). You're not supposed to take your lunch break while working (or else it wouldn't be a "break" in the first place).

"0 people live within 5 km of Warsaw." (actual value is close to 2 millions).

"80.000 people live within 0 km of Paris." (ditto, 2 millions live there).

There are many other cities where the numbers are absurdly wrong. Don't take this tool too seriously, if at all.

The issue is that intelligence itself is an ill-defined concept, and an unofficial but broadly-shared rough definition is "what separates humans (and some animals) from unanimated things". So, as soon as a machine can do something (whether it's having good memory, proving things, playing chess, translating texts, drawing a picture, driving a car, anything) it no longer belongs to "intelligence". Using that very definition, AI is an oxymoron.

It's often a modeling issue. Modeling languages are so abstract and general they give up a part of the problem's structure.

The most famous example is the pigeonhole problem, when given to SAT solvers. Definition of the problem is: I have n pigeons and m pigeonholes, with n = m + 1. Can I put all n pigeons in a different pigeonhole? The answer is obvious to a human. If I have 20 pigeons and only 19 pigeonholes, I won't make it. But even state of the art SAT solvers will fail at solving this in a reasonable amount of time. Because of the way the problem is represented (a conjunction of boolean clauses). With just a slightly more expressive modeling language (such as pseudo-boolean representation / reasoning), you solve it with the blink of an eye.

We humans are efficient because we recognize the underlying structure of the problem. You'll solve the pigeonhole problem in a split second. But if I encode the problem in CNF (the language of SAT solvers) and give it to you without more information, you won't be able to do it anymore.

If you do that, malicious writers will have bots buy their books, get the precious "verified review" badge (and bumping the book's ranking at the same time), and give the book raving reviews. At that point, it just becomes an expense, probably more efficient than buying an ad. In the meantime, legitimate readers whos didn't buy the book by themselves won't be able to comment on it.

Not sure it would really improve the signal to noise ratio.

Average return is a metric, but it's not the only one. If you really want the biggest possible CAGR and don't care at all about volatility, you won't beat a 100% stocks allocation.

Browne allocation's Sharpe ratio (0.67) is better than yours' (0.60). They serve different purposes and cater to different investors.

I personally wouldn't use Browne's because I'm still young(ish) and have a very, very stable income and will get a pension from my government, so I can stomach the volatility and better take the best average return. But if I were a freelance of some sort in my late fifties or older, I'd get closer to Browne's allocation.

I myself tend to lean toward stock-heavy allocations, but this is not something I'd recommend to everyone. I don't know if you remember the 2008-2009 period, or if you even were an investor back then, but those were... interesting times, to say the least. Almost-retired and newly retired didn't sleep well back then.

Your portfolio lost 26% of its value that year, and losing 1/4 of your life's saving isn't something most people are ready to stomach, especially when they need it the most (year just before or just after retirement, typically).

At the same time, Browne's allocation lost less than 1%. Since 2007 it had just one really bad year (2022, -13%, and even then it wasn't as bad as the above allocation), other than that, it was always positive or close to zero.

A simple portfolio that almost never loses money and still has a decent, yet significantly smaller than its competitors, CAGR. That's a pretty good option for very conservative investors, IMO.

When is the right time to "re-balance" to more cash?

When you look at your balance at the end of the year and your cash proportion happens to be below 20% instead of 25%.

Rebalancing is pretty much standard practice nowadays, nothing magical there. Any financial advisor will tell you to rebalance your portfolio from time to time.

Cash is there to be used when everything else goes to hell. The point is to always have enough money at hand to buy low (and to reduce the overall volatility of the portfolio). Browne's portfolio doesn't make sense until you start to look at it as an allocation that maximizes the effect of volatility (the other 3 assets are very volatile, by design) and rebalancing.