- ghosty141 parentYes because users don't appreciate this enough to pay for the time this takes.
- Because from my experience using codex in a decently complex c++ environment at work, it works REALLY well when it has things to copy. Refactorings, documentation, code review etc. all work great. But those things only help actual humans and they also take time. I estimate that in a good case I save ~50% of time, in a bad case it's negative and costs time.
But what I generally found, it's not that great at writing new code. Obviously an LLM can't think and you notice that quite quickly, it doesn't create abstractions, use abstractions or try to find general solution to problems.
People who get replaced by Codex are those who do repetitive tasks in a well understood field. For example, making basic websites, very simple crud applications etc..
I think it's also not layoffs but rather companies will hire less freelancers or people to manage small IT projects.
- In my opinion you must have function coloring, it's impossible to do async (in the common sense) without it. If you break it down one function has a dependency on the async execution engine, the other one doesn't, and that alone colors them. Most languages just change the way that dependency is expressed and that can have impacts on the ergonomics.
- > It's not black and white here. While the European market is appealing to some people, the US market is preferable to others.
I agree with that, it's a very individual topic. I'd say for high paying "high performance" jobs the US model definitely has an advantage but for low-wage jobs it's quite the opposite.
- The "just" was more in the sense that it technically is not that hard to get together, there is nothing directly preventing that.
I honestly think it's just people who don't mind these problems and are fine working under those conditions, or they just quit once they are too annoyed. Change is way harder just than just leaving, I think that's also part of the reason why this keeps going on.
- I don't think unions are the right thing here, you just need to get together as a team and talk with your higher ups, that's a far smaller scope than where unions normally come in.
But I totally agree, I think people are too compliant and fear banding together to have influence on higher ups. I'd argue in most places the engineers have far more power than they realize since they are in high demand due to shortages of qualified personnel. (at least in many countries in Europe)
There are tons of factors in play though that I believe contribute to this like some employees being friends with their higher ups not wanting to hurt their careers, not wanting the tough discussions, the repercussions if management says "no" etc..
- You don't have to fire "low performers" you just have to be realistic about their skillsets and use them that way.
If you see an engineer is out of his depth then change his position, no need to fire them since like others have pointed out, that can have severe consequences in their personal lives and most of the time they can still be useful if they get more adequate work.
- > I don't like unions because one bad hire can destroy a whole team, and the option to remove that hire is worth more than any benefit a union can give me.
In MANY other countries there is already WAY more regulations regarding layoffs and firing employees that has nothing to do with unions.
In Germany there is a probationary period in which you can just fire somebody for no reason basically. That time can be like half a year (in my case) and in most cases it becomes clear if the new hire fits your team or doesn't.
All unrelated to unions though. The big unions in Germany for example have a lot of power and if you are just a simple welder for example you'd have no chance getting anything done without a union.
- > C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program
This is true for MANY other languages too, I don't see how this makes c++ different. With gdb its quite the opposite, handlig c++ types with gdb can be a nightmare and you either develop your own gdb glue code or write c-like c++.
> C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards.
In times of constant security updates (see the EU's CRA or equivalent standards in the US) you always gotta update your environment which often also means updating tooling etc. if you don't wanna start maintaining a super custom ecosystem.
I don't see this as a positive in general, there is bit rot and a software that is stuck in the past is generally not a good sign imo.
> C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc).
Sanitizers are not C++ exclusive too and with rust or C# you almost never need them for example. Yes C++ has extensive debugging tools but a big part of that is because the language has very few safeguards which naturally leads to a lot of crashes etc..
I think the idea of using only a small subset of C++ is interesting but it ignores the problem that many people have, you don't have the time to implement your own STL so you just use the STL. Ofc it gives me more control etc. but I'd argue most of the time writing orthodox c++ won't save time even in the long run, it will save you headaches and cursing about c++ being super complicated but in the end in modern environments you will just reinvent the wheel a lot and run into problems already solved by the STL.
- This is generally the right approach imo (when it comes to codex).
In my experience Codex is pretty "bad" at spotting conventions or already existing code. Yesterday I told him a feature to implement (maybe 40 loc?) and he 1. did added unnecessary atomics and 2. he kinda reimplemented a function that already existed that he should've just reused.
I told him that and he fixed it but these are the things that kinda hold AI back by a lot. It's MUCH harder to read code than to write it, and if he writes the code I must 100% understand it to have the same confidence in it as if I did it myself. And that to me is mentally almost more taxing than doing it myself.
If you just let codex write the code while instructing him exactly what you want in terms of logic and architecture it works really well and saves a on of typing.
- There are some games yes but in my opinion right now the best VR experiences are simulators. Assetto Corsa, iRacing, DCS, MSFS etc.
I bought a Bigscreen Beyond 2 + 5090 gpu basically just to play DCS (Digital Combat Simulator, a flight sim with full fidelity figher jets that you can even fly in PvP multiplayer) and it's the coolest thing VR has to offer for me. All my relatives and friends who tried it were stunned too.
- I'm super curious how they will implement it, if it's a general api in steam vr that headsets like the Bigscreen Beyond could use or if it's more tailored towards the Frame. I hope it's the first as to me it sounds like all you need is eye input and the two streams, the rest could be done by steam-vr.
- I have the Bigscreen Beyond 2 which is OLED + pancake fine. But only if you have the perfect light seal that the BSB face gasket ensures. Your eyes just adjust to it and I never thought about it while using it. The upside of having perfect blacks is sooooo worth it in my opinion. Flight sims in VR at night are an amazing experience
- I wasn't even born back then but I love those amber crts. I had the luck of finding a Zenith ZVM-1220-EA composite display in pristine condition on ebay (I live in Germany where it's way harder to find nice amber crts) and it looks fantastic.
But there is one thing, the noise. I very much hear that super high pitched sound and it makes running it just as a 2nd monitor almost impossible.
Also I haven't quite found a good way of integrating it into my setup yet, raspi+tmux+ssh is the easiest but it'd be much cooler having it as an actual 2nd display.
- Then don't? In C you would just implement everything yourself, so go do that in Rust if you don't want dependencies.
In C I've seen more half-baked json implementations than I can count on my fingers because using dependencies is too cumbersome in that ecosystem and people just write it themselves but most of the time with more bugs.
- Absolutely spot on in my opinion.
Also things often just don’t compose well. For example if you have a nested class that you want to use in an unordered_set in its parent class then you just can’t do it because you can’t put the std::hash specialization anywhere legal. It’s just two parts of the language which are totally valid on their own but don’t work together. Stuff like this is such a common problem in c++ that it drives me nuts
- > variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic.
Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself.
Example:
Also optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.match(foo, [](Foo&) { }, [&](Bar& bar) { }, [&](const auto& mode) { // catch all });