brokencode

You have to use your best judgement. If you are confident in your approach, then I think it makes sense.

You are then also owning this decision, and would have to face more consequences for it going awry. So I don't think it "places a ton of pressure on your coworkers" as you say. It relieves them of pressure since they don't have to decide and won't be held accountable.

But if you think an action will be controversial or are unsure, then you need to make sure you are getting feedback and buy in from other stakeholders before proceeding.

This is not only to make sure you are making the right decision, but also spreading accountability for this potentially bad decision to other members of the team. This accountability will put more pressure on your coworkers, but it is needed to help make the right decision.

> “I appreciate the time and effort the author put into breaking this down.”

Let’s be honest. The author was probably playing cookie clicker while this article was being written.

But the whole point of these “deep research” models is to.. you know.. do research.

LLMs by themselves have not been good at this, but the whole point is to find a way to make them good.

If you’re trying to build a team from scratch, you probably want to hire devs with relevant experience.

But I think it’s a sign of an unhealthy or immature team if it is unable to onboard and train new developers.

You are right that a new developer could easily make a lot of mistakes, but it is the responsibility of the senior developers on the team to give feedback and review the code of less experienced members.

I think it’s better to have somebody who has a deep understanding of all layers of the application rather than only one part.

If a developer is already an expert in the back end using Go, then great. Maybe they’ll bring a different perspective when they work on the front end. And they will probably enjoy a new challenge.

Web development is not so hard that a good developer can’t learn the basics in a couple months, especially with some mentoring.

I think companies are way too worried about hiring developers based on their specific technology they’ve previously worked with.

Unless maybe you are doing something radically different, like web development to graphics drivers or something.

Development skills are typically very transferable between languages, libraries, etc. And I think it’s healthy for developers to branch out and try new tech stacks from time to time.

I’d be more worried about a developer who doesn’t have the versatility to pick up something new. Because they probably also haven’t invested the time and effort to really understand what they’ve worked on in the past.

Theoretically customers can give their money to some other company, but we have seen massive consolidation across most industries over the course of decades. Many important markets are dominated by only a few large companies.

The free market works when there is actual competition. If we want a healthy free market, then we need vigorous antitrust action to block mergers and break up companies that get too big.

No, it’s not the only route they have at all. There is a long history of companies screwing over their own customers to make money. I can’t honestly believe that you aren’t aware of this.

Just look at how Wells Fargo a while back was opening up accounts and charging fees to customers who never authorized it.

Or Purdue Pharma that gave kickbacks to doctors to prescribe opioids and misled the public about how addictive they were.

Or payday loan companies that suck people into vicious cycles of debt. Or the numerous companies that profit from gambling addiction.

Or the big banks that gave out dubious mortgages and lied about risks to investors, which precipitated in a global housing meltdown and recession in 2007.

Or how cigarette companies lied about the dangers of smoking, leading to countless deaths.

Companies will lie, cheat, and scam their way to profits if they have to. Not all of them, and not all of the time, but the endless quest for more money is always corrupting.

> “That's why any and every corporation exists, to benefit it's customers.”

That is an incredibly optimistic belief you have about the purpose of corporations. In reality, corporations only have the responsibility to benefit their shareholders.

Making sure your customers are happy and keep giving you business is certainly one route. And I think most companies at least start out this way.

Though it’s funny you use Apple as an example, since they’ve been widely criticized in recent years due to the parasitic App Store practices enabled by their stranglehold over the smartphone industry.

Government does get corrupted by money, but that money ultimately comes from rich corporations. Eliminating government involvement could just make corporations abuse their power in other ways.

In what ways does government involvement cause problems?

And what actions do you think companies might take to benefit customers if not for government involvement?

Sure, it's a good idea to have something like that just in case. But crashing is really not desirable and could cause all kinds of problems, even if you do have recovery mechanisms in place.

A crash in a web server could result in data loss, timeouts and performance issues on clients due to the response never coming back, crashes on poorly written clients, cascading failures in poorly written services, etc.

And for a client application, imagine if your web browser would just randomly crash sometimes. Do you think it would make it much better if the browser would detect the crash and relaunch itself? And what if it relaunches itself and then crashes again for the same reason?

Yup, that would be the fix. It is a logical error to even try to be dividing by zero, so your code should handle it. Regardless of whether there is a panic, this is what you'd want to do.

But the problem is that people make mistakes or forget every once in a while, and as you get more people working on large programs, these mistakes happen more often.

So you have to assume that it'll most likely happen in your production software sooner or later. Crashing the whole program is a fairly catastrophic outcome in my opinion, and should be reserved for only truly unrecoverable problems like hardware failures.

The situation in Rust seems to be a bit complicated. But I did find that panicking within a thread you spawn kills just that thread and not the whole program. And it seems that Tokio has the same behavior.

https://github.com/tokio-rs/tokio/issues/2002#issuecomment-6...

And web frameworks like Tower provide standard ways of handling panics and turning them into error responses.

https://docs.rs/tower-http/latest/tower_http/catch_panic/ind...

So I don’t think panics are necessarily meant to be program-killing in Rust, even if Result types are heavily recommended instead.

All error handling is messy in one way or another. I am personally a fan of the exceptions in C#. It’s good enough for me and doesn’t make me add a bunch of error types to all my methods.

I also like the Erlang philosophy of letting the lightweight process crash as soon as any problem occurs and having a supervisor decide what to do.

Programs have all kinds of bugs for all kinds of reasons. That’s why you need unit testing, functional testing, performance testing, usability testing, accessibility testing, etc.

Why single out just a few types of bugs to crash the whole program? Let me catch it and decide what to do.

If it’s in a single request to my web server, I’d like that single request return an error code. I would not like all other concurrent requests for all other users to fail as well.

Thats fair, and it’s your language to design how you think is best. Just throwing out my two cents here based on my personal experiences.

I have 2000+ developers at my work, many of them making changes on a single huge web application. Compile/publish of the testing servers takes several hours and happens regularly throughout the day. There are thousands of testers all testing many different workflows all the time.

If one developer makes a mistake in a dark corner of the code one day, it seems bad to have the whole server crashing and disrupting all the other testing that’s going on for multiple hours while we wait for a fix and another build.

Quality and fix prioritization is in the hands of project teams for usability problems, performance problems, functional problems, etc. Uncaught exceptions should be logged somewhere, and it’s ultimately up to the team to decide whether they care enough to fix them.

How is it knowing to panic if it isn’t checking? It seems like I am paying the cost of doing the checking either way, at least in terms of performance. So it should give me the ability to handle the error somehow.

As a C# and Typescript developer primarily, this concept of killing the whole program due to a bug anywhere in any part of the code is very foreign to me.

I’d expect that to only happen if you ran out of memory, had a hardware failure, or other such catastrophic error. To me, dividing by zero is a problem, but not worse than pretty much any other type of logical error that doesn’t panic.

Inko is an interesting language, though the handling for panics sounds disturbing. Based on the documentation, panics abort the whole program and are not recoverable.

Things like dividing by zero or accessing an index outside of the bounds of an array will panic.

While these aren’t incredibly common, I would never want my whole production web server to go down because some random, infrequently used endpoint had a bug in some edge case.

The language seems heavily inspired by Erlang, which is very resilient to programmer errors in comparison.

In Erlang, the philosophy is to let a lightweight process crash and restart it when there is a problem. This doesn’t need to have any effect on other lightweight processes that are running.

I’m assuming the previous commenter thought you were referring to Roc being pre v1 and not Zig.

There are probably some risks to it. And I think that you wouldn’t want to release a Roc v1 before Zig v1 as well.

But if things are working well now, you could always stay on an older version of Zig while you rewrite things for breaking changes in a newer version.

Still potentially a pain, but Rust is post v1 and they ended up deciding to rewrite anyway, so there are no guarantees in any approach.

Or maybe they’re doing it because Starlink is by far the best and fastest growing satellite internet network in the world?

I dislike Elon Musk as much as the next guy, but right now, SpaceX is really the only game in town for anything space related.

What a stretch. One Chinese model makes a breakthrough in efficiency and suddenly China has all the best people in the world?

What about all the people who invented LLMs and all the necessary hardware here in the US? What about all the models that leapfrog each other in the US every few months?

One breakthrough implies that they had a great idea and implemented it well. It doesn’t imply anything more than that.

Subjectively, I find the Shop app to be quite nice and speedy. It works well enough that I’d never have guessed it is using any kind of cross platform framework.

It’s easy to get caught up on numbers, but at the end of the day the user experience is all that matters. And I very much doubt that performance is a concern for their users.

Fair enough, maybe my perceptions of .NET performance are mostly based on old versions of .NET without all the tiered compilation and other features to make JIT warmup less of an issue.

We are only just now wrapping up the conversion at work to .NET 8 from 4.8, so it will be interesting to see the performance numbers once that is complete.

Our .NET application has millions of lines of code, so JIT compilation time in particular in the old .NET could be very painful.

That's specifically an example of an application that I think is slow. It's slow to load and often slow to respond. The support for Git has to be amongst the slowest of any professional application in the world. But I'm pretty sure it has a deeply flawed architecture compared to VSCode.

I don’t have a lot of experience with this, but that’s mainly because there’s no way to compile my company’s application with Native AOT. At least not without a significant amount of work.

This is because there are many limitations in what can be compiled this way, and most C# applications and libraries were never built with such limitations in mind.

Do you have some examples of large and complex C# applications with really good performance?

I’m hard pressed to think of any Microsoft software at all that I think feels really nice. Except for VSCode, which is of course built on Electron and not .NET.

The only thing that comes to mind is Paint.NET, which doesn’t seem like all that big of an application. It’s very nicely done, but I think it’s only got like a single dev working on it, so couldn’t be that big.

As much as I like C# the language, I honestly think that it and .NET are fundamentally flawed when it comes to performance.

Native Windows apps just never seem load that fast or work that great. It’s kind of crazy how much better the basic OS apps feel in macOS compared to Windows.

I wish Microsoft would have gone in a direction more similar to Apple, with an AOT compilation and reference counting.

JIT and garbage collection sound great in theory, but in practice I’ve found them both to be loaded with footguns that more than eliminate any benefits. At least with .NET, that is.

They make money from lots of random stuff that they advertise in Windows.

The Edge browser for instance, which pushes Bing.

Also, office applications like Word, OneNote, and OneDrive.

They’ve got an app store as well, which is not much used, though probably does bring them some money.

I think they show ads by default in the start menu. Pretty sure it even comes with certain third party applications, like Netflix, which they are no doubt paid for.

Oh yeah, I was talking from my perspective as somebody more established in the industry.

I definitely think that if you’re just getting started, especially if you don’t have the typical college degree and internships, side projects are a great way to demonstrate your skills.

Personally, I avoid all side projects at home because they turn into a huge distraction for me at work. It’s hard for me not to think about them all day.

So the whole “program for fun to get a job” thing has always felt pretty dumb to me. Companies should only care about what I get done at work. What I do at home is my business.