I think it's probably confusing until you understand interfaces, which coming from other languages you might not be familiar with (my guess for what happened in this blog post). If you don't know what an interface is then maybe you assume err.Error() is some kind of string, without realizing Error() is just a required function but the err could be whatever type.
My understanding is that using `error` as a return type performs type erasure and that the only information given to the caller is the value of the `e.Error()` function. I now understand that this isn't the case.
Correct me if I'm wrong, but the Error interface means you can display the error as a string, but you don't have to? Like the err.Error() is idiomatic if you just want to display something, but you could also use the error itself
Also "In Go, errors are values. They just aren’t particularly useful values"
...sometimes user mistakes are due to the language being too complicated, maybe for no benefit, but I don't think that's the case here. It's a very good thing that you can just slap .Error() on any error to print it quickly, and not too crazy complex to say an error can be any normal type that you can use, as long as it also can print Error()
My guess is that the author hasn’t fully frocked how go interfaces work yet. Go errors implement the error interface, but that just makes them interoperable, it doesn’t mean that’s all they are.
Correct me if I am wrong, but does it not mean that they are type-erased though? The whole point of returning an interface is to perform type-erasure.
If I have
struct S { X int }
func (s *S) Error() string { ... }
but I return it as an error:
func DoStuff() error
Then all the caller gets is an error interface. Without downcasting (`.(T)`/`errors.As`), you can only compare it to other instances (if the library author provided them) or see the string representation.
Yes, that's correct. The interface limits what guarantees the caller has about the type without runtime introspection. I don't think that really makes it any harder to handle expected error conditions though, since type assertions return a boolean. eg:
if myErr, ok := err.(MyError); ok {
// handle MyError case
}
...
But you should always expect that there could be errors you don't expect to exhaustively handle with special logic.
Tangential point but why is it that so often these leaving the cloud posts use the word "beefy" to describe the servers? It's always you don't need cloud because beefy servers handle pretty much any bla bla bla
i don't know how "worldwide" is the distribution of Chef "Boyardee" canned spaghetti (which today is not too good), but the founder's story is fairly interesting. He was a real Italian immigrant chef named Ettore Boiardi and he gets a lot of credit for originally evangelizing and popularizing "spaghetti" and "spaghetti sauce" in America when most people had never tried it.
Because the server types you get for the price of a single Heroku dyno are incredibly beefy. And suddenly you need a lot less dynos. Which is quite important if you start managing them yourself.
Because that is a casual word in the English language to describe an object with substantial power?
If you would suggest a word that would make a better substitute in this case, that could move the conversation forward, and perhaps you could improve the aesthetic quality of posts about leaving the cloud.
Well, I wouldn't say I have a beefy car or a beefy sword: there's some historical bit of linguistic connection that seems to have caused people to describe a server with the adjective "beefy", rather than "powerful", "hefty", "stacked", or... "chonky" ;P. Coming up with some options, I think my favorite might be "cranked"?
The first definition for beefy from Merriam-Webster is: heavily and powerfully built .
As someone who's had to rack some pretty heavy servers with lots of GPUs, CPUs, NVMe drives, and RAM, that turned out to be quite powerful, I'd say "beefy" is accurate.
Side note edit: hefty and chonky don't tell me much about power. Stacked is usually more about a team or group of things (and for individuals, I'd rather not see it).
I feel like Go is a very natural step from Python because it's still pretty easy and fast to start with.
(and if you want to embrace static types, the language starting with them might get advantages over an optional backwards compatible type system)
You may have read this already but the biggest surprise one of the Go creators had was Go was motivated by unhappiness with C++, and they expected to get C++ users, but instead people came from Python and Ruby: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
I like the "does the problem justify the solution's complexity" question. The deserialization performance improvement seems like an actually important benefit though.
Forcing you to read through your 500 line view controller does have the side effect of you learning a bunch of other valuable things and strengthening your mental model of the problem. Maybe all unrelated to fixing your actual problem ofc, but also maybe helpful in the long run.
Or maybe not helpful in the long run, I feel like AI is the most magical when used on things that you can completely abstract away and say as long as it works, I don't care what's in it. Especially libraries where you don't want to read their documentation or develop that mental model of what it does. For your own view, idk it's still helpful when AI points out why it's not working, but more of a balance vs working on it yourself to understand it too.
Well, the old Java model, where you have dozens of small files, for even the simplest applications, may be better for humans, but it's difficult to feed that to an LLM prompt. With the way I work, I can literally copy and paste. My files aren't so big, that they choke the server, but they are big enough to encompass the whole domain. I use SwiftLint to keep my files from getting too massive, but I also like to keep things that are logically connected, together.
Judge for yourself.
Here's the file I am working on: [0].
The issue was in this initializer: [1]. In particular, this line was missing: [2]. I had switched to using a UIButton as a custom view, so the callback only got the button, instead of the container UIBarButtonItem. I needed to propagate the tag into the button.
There's definitely a balance. Someone told me years ago that when they'd look for one bug to try and fix it, they'd realize a bunch of other stuff about their code along the way. You learn a lot by struggling with a problem exactly when it feels unproductive. On the other hand, there are cases when maybe it's better to get an answer today than spend a week really learning something. For example if you don't care about how a library itself works, AI helps abstract the details away and maybe there really is no cost to that as long as you can see it works.
although the playground is a much gentler introduction than installing gleam+erlang+rebar3
reply