Go missed a big opportunity to be Rust when we needed Rust more than anything. I have long since moved on from Go and C#/.NET is widely available nowadays and in many respects less held back by some strange political choices when it comes to DevEx (I am of course talking about generics).
Rust is the older project of the two, kicking off in 2006. Go, which set sail in 2007, duplicating the work of Rust would have been pointless. We already had Rust.
Go's objective was to become a faster Python. Which was something we also desperately needed at the time, and it has well succeeded on that front. Go has largely replaced all the non-data science things people were earlier doing with Python.
If you saw the early presentations, they complained about the slow compile times and high complexity of C++. It seems that they were targeting that, not Python.
I did see the early presentations. And since you did too, you will recall that one of the primary priorities was for it to "feel like a dynamically-typed language". You know, because it was trying to be a faster Python.
What you might be confusing that with is that their assumption was that Google services were written in C++ because those services needed C++ performance, not because the developers wanted to write code in C++, and that those C++ developers would jump at the chance to use a Python-like language that still satisfies them performance-wise. It turns out they were wrong — the developers actually did want to write C++ — but you can understand the thinking when Google was already using Python heavily in less performance-critical areas. Guido van Rossum himself was even on the payroll at the time.
For what it is worth, Google did create "Rust" after learning that a faster Python doesn't satisfy C++ developers. It's called Carbon. But it is telling that the earlier commenter has never heard of it, and it is unlikely it will ever leave the heap of esoteric languages because duplicating Rust was, and continues to be, pointless. We already had Rust.
I wonder if this will get RISC-V adoption on the roadmap of competitors. We had a thread in the last 24 hours over how slow as molasses it is, but honestly x86 isn’t the way to go. I like that the AMD x64 literature tries to push down on the legacy cruft but some of it is evident in the ISA which is harder to ignore, like default behaviours of registers and other things that are left over for backwards compat and as such everything around it suffers in a thousand broken windows sort of way.
nb I haven’t delved too deep into RISCV but I am under a general impression it did away with all this. My concern is the layers that are added will turn it into a CISCV over time.
Real talk: who is this guideline going to stop? People are already doing this and they will continue. Even if you find them, they’ll just make more accounts and continue.
Say what? It’s a genuine question. What is the actual repercussion for not following this?
It came up a few weeks ago. Show HN is already disabled for new accounts as of this week I think(?), but IMHO stricter measures need to be placed for account creation otherwise there’s no real enforcement.
I don’t quite get the amount of supposed subtext that others see in this piece, so the flippant attitudes here are off putting. Geohotz has already commented here that people are putting words into his mouth.
I agree with what is being said: AI will consolidate otherwise nonsensical jobs/roles/companies into fewer (probably more profitable?) ones, so if there’s a time to jump ship from one of these (assuming worst case scenarios), do it while you’re employed and you can land somewhere else that’s hopefully more stable.
This to me is a fairly no-nonsense piece over all. AI itself and tools like LLM are damn good though, limitations aside. We get to do a lot of things we haven’t had time to do before.
