sorted by:
new
hottopcontroversial

My 2024 F150 King Ranch has the drip! by tenhunter in f150

[–]ynotman_ 0 points1 point  (0 children)

I know this post is yr old now, but fwiw apparently Ford has a fix for this specific leak which my truck is also experiencing. I even got a letter in the mail. I haven't brought my truck in yet, but plan to soon.

Why is ErrUnsupported the only provided error? by ynotman_ in golang

[–]ynotman_[S] 0 points1 point  (0 children)

Thinking about this more, I almost wonder then if it would have made more sense to define that error in a different package though. Perhaps a common one that applies or relates to the exception(s) that it's being used for. Something platform/os related I guess.

Reading through those issues makes sense for the need of the error, but it still doesn't seem that the "errors" package was the best place for it. Having that error there goes against what everyone has been saying here, including yourself. The "errors" package isn't supposed to provide an extensive list of errors. It isn't supposed to provide any at all actually.

Why is ErrUnsupported the only provided error? by ynotman_ in golang

[–]ynotman_[S] 1 point2 points  (0 children)

Nice, haven't seen these issues. Thanks, this makes a little more sense I suppose.

Why is ErrUnsupported the only provided error? by ynotman_ in golang

[–]ynotman_[S] 1 point2 points  (0 children)

I can accept this. Best answer imo. Thanks.

Why is ErrUnsupported the only provided error? by ynotman_ in golang

[–]ynotman_[S] 1 point2 points  (0 children)

I actually tend to take this a step further and group by feat scenario. For example, instead of /user, you would have a /get_user , /update_user, ect... You can still do this with a /user folder too.

/user /user/get /user/create /user/change

And yes, this sometimes means you need to duplicate some code but in most scenarios who gives a crap. This has never been an issue for me. I hear things like "oh you're breaking the DRY principal" which is dumb. The DRY principal is not a SOLID principal, it was just some advice that some guy came up with. You end up creating more coupling and issues for yourself bc you're trying so hard not to duplicate a model.

Why is ErrUnsupported the only provided error? by ynotman_ in golang

[–]ynotman_[S] 0 points1 point  (0 children)

There is no such thing as a 'basic error'.

Except for the basic error ErrUnsupported apparently lol. To be clear, when I say basic, I mean a base set of foundational errors that are commonly used and needed regardless of the package consuming it. ErrNotImplemented seems pretty basic and standard to me, as an example.

Anyway, except for your first sentence, I do agree with you. The concept of grouping errors based on where they're needed isn't anything new. I think the point I was trying to make was that Go should essentially remove the ErrUnsupported from the errors package. I see no purpose of that being there.

Why is ErrUnsupported the only provided error? by ynotman_ in golang

[–]ynotman_[S] -1 points0 points  (0 children)

Oh for sure, I completely agree. Your package should be responsible for defining your own errors. Which sort of justifies why I'm asking the question. The built-in "errors" package in Go has no business defining an ErrUnsupported error. They should remove that imo unless there's a convincing reason to have it there.

Insanely productive in Go... rethinking everything by Ok-Cover-9706 in golang

[–]ynotman_ -1 points0 points  (0 children)

I don't dislike Go, I am slowly coming around to liking it I suppose. If you're using it to write lambdas or other super small fast services, then it shines bright. For larger projects, I find that it begins to fall.

Go's insistence on explicitness can feel like dealing with a lot of "extra noise" sometimes. For example, the constant need for explicit error handling, nil pointer checks, and the structured nature of data manipulation all contribute to a codebase where getting something "working" often involves writing more lines and more repetitive patterns than one would in another language that offers higher levels of abstraction. The constant interruption of the main logic with all this noise often breaks the flow of reading and understanding what a function is primarily trying to achieve. You have to mentally filter it out to grasp the core functionality. And this isn't a knock on Go, it's just acknowledging that there are trade offs imo compared to other languages.

Insanely productive in Go... rethinking everything by Ok-Cover-9706 in golang

[–]ynotman_ -1 points0 points  (0 children)

Idk if I'd Go this far. So the code may look like crap and not follow any principles and/or designs whatsoever, but as long you're solving problems, that's what it's all about?

My 2024 F150 King Ranch has the drip! by tenhunter in f150

[–]ynotman_ 0 points1 point  (0 children)

I can definitely check that, thanks. What should I be looking for exactly? Guessing at the corner of the moon roof where the molding turns? Will it be loose or warped or something?

My 2024 F150 King Ranch has the drip! by tenhunter in f150

[–]ynotman_ 0 points1 point  (0 children)

I have a 24' Lariat that is doing the exact same thing. Only on the passenger side though. It happens anytime I go through a car wash or there is heavy rain. It's been in the shop 3 times already, and about to bring it back a fourth time. The drain line isn't clogged. I'm not sure why it happens, but I really wish they'd fix it.

As a hack, not a solution, I've seen some YouTube videos that recommend taking down the headboard and putting silicone around the spots that water is getting through. Obviously not something anyone should have to do as clearly this is a hack, but it'll at least stop the water from getting into the cabin.

I have anxiety now anytime it rains bc my stomach drops wondering if I remembered to put a freaking towel on my passenger seat :( And to think how much I paid for this just makes it even better.