I have very similar thoughts after working with Cursor for a month and reviewing a lot of “vibe” code. I see the value of LLMs, but I also see what they don’t deliver.
At the same time, I am fully aware of different skill levels, backgrounds and approaches to work in the industry.
I expect two trends - salaries will become much higher, as an individual leverage will continue to grow. At the same time, demand for relatively low skill work will go to zero.
Neighbours have always attacked en masse: in 1948 they attacked en masse and lost and a Jewish state was established, in 1967 they attacked en masse and lost and Israel gained Judea and Samaria / West bank, in 1973 they attacked en masse and lost. Plus various combinations of Iran, Hamas and Hezbollah attacking since, and losing.
Dear, past performance does not predict the future one. Israel hasn't done anything to build good will, on the opposite, they are increasingly negatively viewed, at least in Europe.
I think the general move is towards more monochromatic interface and I for one welcome it. It will take a while to adjust, but I think we might end up with much more "peaceful" interface. I'm tired of icons jumping at me.
1. Fair, but at the same time - OTP is the only sane concurrency framework. To the point I still struggle to comprehend why it wasn't copied.
2. Fair.
3. I am not aware of a single language doing OTP abstractions, especially implementing preemptive scheduler for green threads.
4. Possibly, but I haven't seen a single instance of a company choosing between the two.
I think marketing is a way better explanation to be honest. Jose lives in Poland, was very active and a lot of Ruby shops moved to Elixir.
There have been multiple attempts in various languages to implement Erlang-like processes and claims of parity, Erlang processes remain unbeaten at what they do.
From the Elixir's developer perspective, this is insane. The issue is solved in Erlang / Elixir by functions commonly returning {:ok, result} or {:error, description_or_struct} tuples. This, together with Elixir's `with` statement allows to group error handling at the bottom, which makes for much nicer readability.
Go could just add an equivalent of `with` clause, which would basically continue with functions as long as error is nil and have an error handling clause at the bottom.
From all available evidence, there is no chance in hell Go could adopt a `with` statement.
Go is fascinating in how long it holds out on some of the most basic, obviously valuable constructs (generics, error handling, package management) because The Community cannot agree.
- Generics took 13 years from the open source release.
- 16 years in there isn’t error handling.
- Package management took about 9 years.
There’s value to deliberation and there’s value to shipping. My guess is that the people writing 900 GH comments would still write Go and be better off by the language having something vs. kicking the can down the road.
We already have languages that ship features. Go is a lone lighthouse of stability in a sea of fancy languages. I'll play with your fancy languages, but I build my own projects that I actually use in Go because I can trust that it will keep working for a long time and if/when I need to go back to it to fix something in a couple of years I don't need to re-learn a bunch of crap that might have seeped through dependencies or the stdlib.
> My guess is that the people writing 900 GH comments would still write Go and be better off by the language having something vs. kicking the can down the road.
My guess is they will still write Go even if error handling stays the same forever.
Go's multiple return is in itself insane from my perspective. You cannot 'do' anything with a function that has multiple return types except assign them to a variable.
The saddest part is that Go's designers decided to use MRV but pretty much just as bad tuples: as far as I can tell the only thing Go uses MRV for which tuple wouldn't be better as is post-updating named return values, and you could probably just update those via the container.
Common Lisp actually does cool things (if a bit niche) things with MRVs, they're side-channels through which you can obtain additional information if you need it e.g. every common lisp rounding functions returns rounded value... and the remainder as an extra value.
You can pass multiple return values of a function as parameters to another function if they fit the signature.
for example:
func process[T any](value T, err error) {
if err != nil {
// handle error
}
// handle value
}
this can be used in cases such as control loops, to centralize error handling for multiple separate functions, instead of writing out the error handling separately for each function.
for {
process(fetchFoo(ctx))
process(fetchBar(ctx))
}
What else would you want to do with them? Maybe in rare cases you'd want to structure them into an array or something, but the inverse isn't possible either [e.g. func f(a, b, c int) -> f(<destructure array into arguments>)] so it isn't like it is inconsistent.
Perhaps what you are really trying to say is that multiple function arguments is insane full stop. You can pass in an array/tuple to the single input just the same. But pretty much every language has settled on them these days – so it would be utterly bizarre to not support them both in and out. We may not have known any better in the C days, but multiple input arguments with only one output argument is plain crazy in a modern language. You can't even write an identity function.
But then why accept multiple input arguments? Why not limit to a single argument, accepting a tuple where multiple arguments are necessary, for input too?
Where multiple input arguments are present, not having multiple output arguments is just strange.
What would you need syntax sugar for? If you are going to support multiple arguments you may as well do it properly or don't do it at all. A poor bandaid because you fucked up tuples is not a quality that is to strive for.
Haskellers and Rust fans think they own sum types, and people read their comments and blog posts and believe them, and decide they don't want sum types because they don't want to go down the horrifying Hindley-Milner rabbit hole.
But meanwhile it's just perfectly idiomatic Erlang and Elixir, none of that baggage required. (In fact, the sum types are vastly more powerful than in the ML lineage - they're open.)
I should've been more clear that my claim was only about the ability to post messages, have them stored in a database, and then have a tree-view that displays and edits the posts. That's 99% of what users do right? That entire functionality could be done by an AI Agent nowadays in about 10 minutes.
Doesn't matter. You could replicate the basic functionality of Hacker News in a single Coding Agent Prompt. Sorry, I'm not wrong.
I've been writing web apps since 1998. Just today I implemented a similar tree view, with ability to create, edit, rename, move files and folders in a TypeScript react web app, and my app that I wrote today is a vastly more sophisticated GUI than Hacker News. lol.
It _does_ matter as those edge cases would be the difference between a working product and something that's trivial to topple over with `"; find . -exec shred -f {} \;` if your agent is used for the backend. There's also a lot of boring problems to solve backend wise (migration, failure mitigation, suitable performance, etc) that need to be considered for a site with significant traffic even for "basic functionality" (a service that's down cannot serve it's users).
The frontend of HN doesn't need to be complex and I'd even argue that it's better for being simple as it's then easier to parse, takes less effort from the client to render, certainly less battery on mobile, and so on. Web applications don't _need_ to be more complex than the problem at hand where the frontend itself is just enough of to display content in a comfortable enough format for human consumption.
Unrelated to the topic but related to the thread: if you edit a message then please keep the original message around to keep context for others that read this thread if that edit would change how the message was interpreted at the time of the reply. Non-functional edits (e.g spelling corrections) are fine without notice.
What I meant by "doesn't matter" is that your original quip didn't prove me wrong. You just want to talk about all these other things to insinuate somehow I'm unaware of them, despite having 3 decades of web dev exp. lol. I already made it perfectly clear what I said is about 2 days of work, and I'm not wrong.
I have very similar thoughts after working with Cursor for a month and reviewing a lot of “vibe” code. I see the value of LLMs, but I also see what they don’t deliver.
At the same time, I am fully aware of different skill levels, backgrounds and approaches to work in the industry.
I expect two trends - salaries will become much higher, as an individual leverage will continue to grow. At the same time, demand for relatively low skill work will go to zero.