@pandasama in other words, your higher ups have already promised a deadline to their higher ups and do not dare to admit they did wrong :/

@netikras if the higher ups set the expectations its not much you could do, lowering expectations in that case is not an option.

Sounds very much like unrealistic expectations and not enough resources.

New goal. Beat that time :D

@kobenz well, it does sort of have coding …

A mainframe as already mentioned is optimized for io and storage but it also contains lots of specialized chips for encryption, zip/unzip and other common processing tasks.

They are also designed around redundancy and uptime to make sure things keep running.

You can swap out almost anything in runtime, even hardware like cpu and memory by shifting running apps to other cores.

This is also why they are still in use in many critical implementations.

You can so the same in the cloud or with your own clusters BUT you would ned to built it into your applications.

With a mainframe the application just keeps running.

@alemantrix I never interviewed for google but I did for amazon and my take is that they actually care less for your language than for how you approached the problem and at least with amazon how you reason about the problem since they where there in the room asking questions about why I did thing or if I had thought about everything.

I did whiteboard code , not really building real code but just the concepts on how to solve the task.

At least in the real interview

The first step was an online coding test similar to codewars where you submitted something that had to compile and solve a problem but you had 3 or 4 languages to choose from.

I think their thoughts are that if you can solve problems, they can always teach you a new language, but teaching someone how to think right is way harder ;)

@atheist well, its only ever going to be as fast as the compiler can do, just as C++ or Rust, and C is designed to be platform agnostic meaning there have to be some tradeoff for more generic constructs.

The compiler will attempt to use the most optimized instructions but it can only do so much.

The closer to assembly you are the more you risk that your code limits what rewrites the compiler can make.

That is one of the ideas behind rust, after safety, that using more high level constructs to define intent will allow the compiler more freedom to use faster constructs.

And the bigger the code base and the more developers involved the more benefit you will get from better compiling.

Sure the very best dev can beat the compiler but realistically most companies will mot have devs that out perform the compiler anyway.

@jeeper I know

@Lensflare are you referring to golang of coding in general ;)

@max19931 this is as others have said already going on, multiple cores, specialized cores, new algorithms using said cores. Going back to c++ for speed is not the only option, if that was the case, why c++ and not straight to assemble or machine code?

The answer is development cost and complexity.

More modern languages use cleaver language constructs to give the intent and then allows the compiler to optimize and use specialized chipsets or parallelism.

Yes you can do that manually but it add complexity which adds cost and most software does not motivate that added cost, especially since few algorithms need faster single thread performance, we instead do more different things or process more data that can be done in parallel.

So adding cores works.

@hjk101 Ada is probably used within the us government and gets special treatment ;)

@netikras I imagined you comment in a different light :D

You accidentally kicking the cat of the bed and it decides to retaliate :P

@Lensflare My guess is that kotlin is not big enough to make the list

@atheist Yes there are ample tools in modern c++ for more safe code, BUT you can just as easily use unsafe constructs if you do not know the difference.

With for example C#, you have to explicitly say you want to use unsafe code.

As for speed, 98% of all code does not need to focus that much on speed and in many cases if you do need it you can still write those parts in whatever language you need and the rest in a more safe one.

Until the LLM them self manages to convince me they are in fact sentient I will keep sorting them under the same nonsentient as phone sellers, politicians and rocks :P

@b2plane Thats the biggest problem with any “investment “ unless you can afford to wait for profit it is just gambling.

In that case its the same with stocks, you never invest money you cannot afford to loose.

And the difference between crypto and stocks is that companies have products and report a lot, if you spend time going through that you can make a very good guess if the company is solid and will grow or not.

The closest thing in stocks to crypto is blanking where you sell or buy stock now for later delivery and hope that by the time the transaction goes through the real price will have changed in your advantage. But that is also a good way to quickly loose money.

@b2plane investing in crypto is in many regards similar to investing in lottery tickets, you gamble.

Never ever change production unless you have time to verify before weekend.

With the exception of if something is already broken.

To many.

Had a webshop I wanted to shop from that not only restricted password length to 8 (yes eight) characters.

This signup form allowed more characters and the login form always responded with bad login for any password linger than 8 so trying to figure out why login failed took two separate contacts with customer service.

Thats next level stupidity, not only bad password policy but a broken implementation that makes it even worse to use

@MammaNeedHummus Most mergers are single comits and if no one else messed with the same file a plain merge is enough.

But whenever a merge has more than one comit I think a quick rebase not only makes sure any merge conflicts are handled locally in the branch and not during the actual merger reducing the risk of an error leaking into some other branch.

It also makes sure that if we fo need to pull the merge we do not have all comits in one place.

Its rare yes, but rebasing is also usually very fast.

The only time it takes more time is if there are merge conflicts and thats also where its most useful, so its an easy guard I at least feel is worth the time.

Squashing is not enforced but rather up to the dev but if they do I always ask them to keep any commits with relevant messages.

That also helps in case someone else get a merge conflict.

Especially as the blame feature makes it very clear why a certain line was changed and when.

But as long as the team find a solution they feel works I think that is fine.

@MammaNeedHummus I rarely squash commits, I do rebase so all commits are in order.

Squash is mainly used to remove nonsensical commits, like fixes that are fund before merging that serve no purpose in the main log or when you need to pause a branch for some reason and then resume.

I prefere rebase before merge since in the case of merge conflict its easier to solve and if you change logic, getting changes intermixed can make it harder to follow.

Most times it does not matter no, but on the occasions it does having all commits fresh at the end helps.

If you merge often the problem is very much reduced, and in a small team the same. But with 10 devs that could end up poking around in the same file it can be a mess (we are refactoring your reduce the risk of multiple changes to the same file but in the process the risk is higher until we are done )

@jestdotty that is easily solved, just go overboard with explanations, if they only wanted to get you to do the work they will find someone else to pester after a while ;)

Do you have any resources created?

Also, there should be a page listing what is causing charges.

Yes

Once AI gets good enough to really replace a good developer its going to want to get payed ;)

Probably because you have gotten a reputation for knowing or for being good at explaining.

That is traits people often appreciate.

And by asking, they belay their own insecurities, especially if you respond with the same thing they themselves self was thinking of.

I usually have more problems with the ones not asking questions and that make mistakes instead of ;)

Well thats the solution, send the question and go directly to that bathroom and bring the phone ;)

Async debugging is always more tricky but its usually worth it during to the better performance of the code :)

Sorry, payment first, wish after ;)

wishes left: 0

@Hazarth yes it has many legacy problems but it IS very easy to get started with and as you said, its mainly the apis to the browsers that keep changing.

The language it self is mostly expanding.

And even the strangeness of the implicit casting has a logic to it if you dig deep enough.

Not a good logic of cause :) but there is a logic.

Much of that is also due to the original development that if I remember was just a few weeks last minute crunch by one man Brendan Eich with little to none real analysis or planning, just getting some scripting in place for forms validation and similar, before you could modify the DOM or similar.

Then the browser competition created a mad dash to add features and once the edge cases started to be a problem if was far to late to switch out the base, breaking tens of thousands of scripts already out there.