For what it’s worth, I find comments and articles with assertive predictions like this difficult to take at face value.
I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
Is it really though? Access to information is quicker, but you still need to know what ‘good’ looks like to leverage it effectively. I can prompt my way to a medical diagnosis, but I’d still want to run it by a doctor.
I’ve found it extremely hard to get LLMs to exit the basin of your current knowledge.
One of my tests for new models is to ask about a concept I already know the mathematical model for, but as if I don’t. So far, they all answer the same way:
1. Convoluted explanations about how it kinda-sorta is common terms.
2. If you follow up with the correct mathematical term, it immediately claims that’s correct and the right way to model it.
3. If you ask it why it didn’t use that term for your question, the LLM gives some version of explaining that it tried to match your language.
I have no choice but to assume the model behaves similarly other times — and that I am largely trapped in a basin of my own ignorance, when using LLMs.
If the LLM is wrong and gives you a wrong medical diagnosis you end up hurting your health. If an LLM gives you a wrong debugging answer you've just lost 5 minutes.
Software engineering is the only knowledge work where mistakes are usually inexpensive except for data breaches. Outside for that nobody cares for bugs.
That's not true in most other knowledge jobs. If a lawyer uses AI and hallucinates something there is a legal problem. If someone vibecodes an app and crashes, it can be fixed with more AI and try again
That’s my point though? Debugging a 5-minute problem is in the shallow end of the spectrum, the real complexity sits where they lean on their domain experience. Finance and payments software mistakes can absolutely be expensive.
Well if the management want to get more AI, they gonna get more AI, and no, I am not gonna be running around making sure their dreams work smoothly under my human supervision - I am gonna let it go all the way they want. In the mean time I focus on improving my skills.
This was my reaction as well, a lot of hand-waving and invented jargon reminiscent of the web3 era - which is a shame, because I'd really like to understand what they've actually done in more detail.
What's even more interesting is that if you turn off watch history, they disable the home feed altogether. They just give up trying to show you anything, which has been great for keeping me off YouTube.
That is a very broad generalization. Even if it was 'put into some fund', that equates to a capital investment which can be used to deliver value elsewhere.
Money is complicated - the only way in which I would see it get truly wasted is if you took it out as cash and burnt it. Even then you'll be (marginally) raising the value of all other money left in the system.
Nobody can tell you whether progress will continue at current, faster or slower rates - humans have a pretty terrible track record at extrapolating current events into the future. It's like how movies in the 80's made predictions about where we'll be in 30 years time. Back to the Future promised me hoverboards in 2015 - I'm still waiting!
Compute power increases and algorithmic efficiency improvements have been rapid and regular. I'm not sure why you thought that Back to the Future was a documentary film.
Unless you have a crystal ball there is nothing that can give you certainty that will continue at the same or better rate. I’m not sure why you took the second half of the comment more seriously than the first.
I don't think it is an illusion. It can remove a lot of barriers to entry for some people, and this is probably what you're seeing in the anecdata.
For example, my brother. He is what I'd refer to as 'tech-aligned' - he can and has written code before, but does not do it for a living and only ever wrote basic Python scripts every now and then to help with his actual work.
LLM's have enabled him to build out web apps in perhaps 1/5 of the time it would have taken him if he tried to learn and build them out from scratch. I don't think he would have even attempted it without an LLM.
Now it doesn't 'code everything' - he still has to massage the output to get what he wants, and there is still a learning curve to climb. But the spring-board that LLM's can give people, particularly those who don't have much experience in software development, should not be underestimated.
I went through the process of buying a car recently, and the dealer, before we even begun to negotiate on price, was describing how their pricing system has all 'moved to AI'. I was suspicious, and after querying him about it for a while what he described essentially just boiled down to something a spreadsheet could do.
Now I don't dispute that AI has and will continue to automate jobs away like this. But I do think we are in an era where the lines between 'classic' automation and AI automation are blurred for quite a lot of people and without any concrete details I suspect this case leans more towards the former.
A lot of the "AI automation" videos you see on YouTube are just people creating Zapier or Make workflows connecting different services. Most of it was possible 10 or more years ago, using APIs and a few hundred lines of code.
The difference between 10 years ago and today is now it's cheap to do that. Somehow that makes a lot more people aware of it - even though it could have been done 10 years ago and the ROI would still be positive.
Go and it’s standard library. ‘Elegant’ is pretty subjective, but it’s a treasure trove of learning how things work under the hood. I’ve learned loads about networking, compression, encryption and more by browsing through it, because the code is super easy to read and understand.
What makes it easy to read and understand though? I am seriously having a hard time figuring this out. People tout Go for this all the time, but I don't know of a single codebase in it that I think fits that description. When I look through them they look convoluted and just sort of messed up. Things like awkward error handling, dealing with null, capitalization for public/private, magic functions, and imports, and much, much more all add up and make me abhor the language. I don't think it's good or easy to use at all, but people rave about it.
Speaking for myself, the language itself is simple. There aren't a lot of features, which means you do have to write more and it's more verbose, but learning the entirety of the language's features is very easy to do.
Even with the relative magic of things like init functions that execute on import, there's so much less magic that you have to consider.
IMO it's the easiest to jump into for this reason. Yes, the code itself might be excessive, but reading Go is as simple as can be.
I'll echo this. When I'm looking at a Go codebase that somebody else wrote, it's a minimal effort to understand what it does. Rarely, if ever, do I scratch my head at a particularly clever type derivation or obscure language feature; macros are pretty much non-existent; even user-defined types are easily reduced by the IDE and language server. Patterns are standardized and yes, it's verbose, but predictably so. If something calls for containerization, it's dead simple. Go is a language for getting things done straightforwardly.
I know it's not everybody's cup of tea, and that's fine. There's room for different languages in the world. But I'm knocking out useful utilities that make a difference for my team and business in days or hours, and supremely uninterested in code golf, so I don't personally agree with the criticisms.
Its touted as being so easy that a junior dev can pick it up easily; it's targeted towards average developers. Fine, this is a virtue; when Java said the same thing, it's a horrifying blight.
The other is that people seem to mistake motion for action. "The code flies from my fingers" is one way I've heard it said. And, sure, you have the same error catching boilerplate (which again, in go is a virtue but other languages seems to be considered a sin) 1000x, as if the clicky-clicky of the keyboard is some measure of productivity.
It's got a big "blub paradox" thing going, to my eyes. I don't find it elegant at all, or maybe I mean not very expressive.
Taken ad absurdum, I have a language that only adds 1 to a variable. I can understand that language in milliseconds. But I can't do much with it. Maybe go hits a good balance, I dunno, but I found it quite tedious.
It’s the complete lack of magic. What you see in front of you is pretty much exactly what happens. You don’t have to keep a cathedral of language semantic subtleties in your head when reading someone else’s code.
That’s because JavaScript is an awful language and I just don’t understand why people keep insisting on using it for everything. It even infected infra as code.
That’s because it is easy to use. Maybe you use too much python or Java but go was designed to specifically allow people to memorize the entire syntax, truly.
Want to make a function or variable or field public? Just capitalize it. That’s it.
Error handling? Check if the error isn’t nil and handle it, otherwise move on. No need for silly things like try except.
And there are no magic functions because everything is explicit.
Try except isn't silly it shortens the code a lot. An exception can simply break out of a function, checking for error requires an explicit check at every line of the function and an added return statement to get out of the function.
At my employer we use a subset of C++ and we use Go. We have a process by which when you write code others have to review it and you need to have a review by someone who is an "expert" [0] in the language [1]. You become an "expert" by being ordained by a shadowy committee who reviews code you submit to the code repository. They look for knowledge of the core language, how this language is used within the company, the external and internal libraries, performance, testing, etc. There are many factors and if you demonstrate all of them you get marked as being this type of "expert."
Before I joined this company I had written code which was launched into production in the following languages: Java, PHP, C, C++, assembly (arm + x86), Python, JavaScript (browser + node), and a few more. I would consider myself about average in all of these. I did not write any golang.
After I joined my current job I obtained this "expert" bit for both C++ and Go. It took ~1.5 years to get the C++. It took ~3-5 months for Go.
You can actually see the first golang code I wrote (this was at home when I was experimenting with the language before convincing some team members we should rewrite some of our infra in go): https://github.com/gravypod/gitfs
It has all sorts of mistakes but I didn't read any guides. I just used https://cs.opensource.google to search for examples of things that I thought I would need to do (ex: "how do I do a switch statement").
For C++ I had worked on ~2 projects that used it. My first few PRs were very rough and I had a lot of performance issues that crept into my code. If I didn't already have a lot of C experience I would have also had a bunch of pointer/lifetime stuff the reviewers would have found (I know this from reviewing new team members first lines of C or C++).
I know that to some C++ represents a literal worst case but most people coming from C++ to Go will think it's amazing because it removes all of the common footguns.
> Things like awkward error handling
Yes, it is very clunky and annoying but it's very simple. It's just a normal if statement and doesn't use any special language rules. I think this would still be better if there was dedicated syntax for it (something like throw/try/catch which works the same way but gives it a different syntax) but honestly I don't think it's as bad as it's made out to be. It's basically a "less bad" errno and that worked go-... dece-... ehm fine for many years.
> dealing with null
I've never really had to think about this too much. There are some times it is important but I rarely return nullable things without errors and it hasn't bitten me yet. My code is not provably correct but for the things I'm working on I don't need that guarantee. If I did I'd probably switch to Rust or something with better type safety.
> capitalization for public/private
Yea, this sucks but it doesn't really get in my way much. I don't like it but it isn't actively hurting my usage.
> magic functions
Like `String()`? I don't know if that's the worst think in the world. Python, C++, and Java have things like this.
> and imports
It's not been too bad for me. What I think is unfortunate is that the package of something is unconnected to where it is in most go usages which is annoying but it makes things more terse. This does actually hamper my productivity.
> I don't think it's good or easy to use at all, but people rave about it.
It's pretty easy to use because all of the libraries I've seen share common interfaces for behavior. This makes things feel a lot more cohesive. fuse-go and billy was very easy to use in gitfs because of this.
[0] - This is not an expert as in "knows everything" but more like "has been seen to consistently write efficient, simple to understand, idiomatic code." It basically means that when someone else from this subset of SWEs reviews your code they often do not have many comments. Again, I want to stress, this is not expert as in "knows everything" just as in "good enough".
Well, c++ is literally the most complex language, famously not even Stroustrup would say he knows the whole, so comparing go to that hardly makes it look good.
No, because the different trade-offs they make all have costs and benefits. For example, C’s precise memory management can give better performance compared to PHP, but also requires more expensive programmers to work with it. If all you’re doing is a simple CRUD system, C’s power would be counter-productive, so PHP is a “better” language in that context.
So a “good” language depends on what you’re trying to do with it.
I remember with smug satisfaction a time that I was able to settle a pedantic argument from a so called "security expert" by pasting the code from the library function he was questioning.
Very satisfying to be able to say "nope, it's fine, here's the source".
I find the Golang standard library code annoying to read and understand because of their use of single letter variables or very short abbreviations. I know some people like this but I don’t.
The single letter variable is only supposed to be used within a relatively short function or code block. They should be relatively obvious; I personally find this to work well, but I can understand where sometimes it wouldn't be clear what the author was referring to.
I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.