9rx

175 ms·

2701.
by 9rx 2y ago
While that would certainly impact production, it would be a bit strange for development environments to be stateful in the same way. Those not immediately involved in dealing with the stateful issue seemingly should be able to continue with
2702.
by 9rx 2y ago
React v1 solved a real problem, but perhaps didn't really need 17 subsequent major revisions with another on its way? But that's the different cultures around this discussion. The Javascript community generally seems to subscribe
2703.
by 9rx 2y ago
How else could it be read?
2704.
by 9rx 2y ago
> Why is bringing up the minority use case helpful in these discussions? It was presented as a challenge to the status quo. As you point out, a majority of developers don't ever think twice about including everything and the kitch
2705.
by 9rx 2y ago
> We don't want to do meta programming where we have another language living as a string in our web app. Strings are fine in theory, but the trouble with SQL is that, while too high-level in all the wrong places, it is also too lo
2706.
by 9rx 2y ago
> but it would not be okay for so many ORM people to actually have properly bound SQL in-place. It's okay... sometimes. But, as what the article is about, more often than not you need to start composing that SQL. SQL does not deal
2707.
by 9rx 2y ago
> With conclusion I meant you claiming that go returns multiple values because a function also takes multiple values. That remains the most reasonable explanation. There is no legitimate reason for functions that accept multiple argume
2708.
by 9rx 2y ago
> Sorry but I haven't really seen this pattern anywhere, care to give some examples? The standard library provides examples, including a "storage" example. > All libraries that I recall ever using always export a sin
2709.
by 9rx 2y ago
> I don't think that's the right conclusion It is the "right" conclusion in general. Multiple input arguments without multiple output arguments is frustratingly awkward. I can understand the appeal of your suggestio
2710.
by 9rx 2y ago
That is the beauty of engineering: There is no universal truth, just different tradeoffs. Meaning that you don't need to agree, nor should you even seek agreement. You can and should forge your own path if different tradeoffs are warra
2711.
by 9rx 2y ago
> The pragmatically "right" choice is to have some tuple type built-in. Perhaps, but in practice we end up with these ill-conceived languages that support tuples but end up not embracing them. Consider, for example, this Rust
2712.
by 9rx 2y ago
The stdlib would remain 100% backwards compatible, but the implication was that he would want to see certain existing features of the stdlib amended with modified versions that leverage the new tagged unions. He imagined that modification w
2713.
by 9rx 2y ago
Actual code is always better, but based on the description it seems a bit strange that there would be a single package that exports multiple implementations. Presumably each distinct implementation should be its own package. None of these p
2714.
by 9rx 2y ago
> I'm saying that this tenet is misleading. Doesn't that go without saying? There is no tenet that isn't misleading when presented to a general audience. Fair that if you come from a position where you understand the ful
2715.
by 9rx 2y ago
I see it used often, even in languages that don't formally support multiple return arguments – with some hacked up array/object single value return to try and emulate what would be better represented as multiple return arguments.
2716.
by 9rx 2y ago
A function that passes tuples, or multiple arguments as they are more commonly referred to as, is not particularly weird, and has pretty much been the norm since the addition of functions to programming languages. But you are right that lan
2717.
by 9rx 2y ago
The actual first paragraph states: > This page collects common comments made during reviews of Go code, so that a single detailed explanation can be referred to by shorthands. This is a laundry list of common style issues, not a compreh
2718.
by 9rx 2y ago
Technically, Go v2 signified the transition away from Google control to the project being directed by the community. That happened several years ago. Go v2 is already here and has been for a long time. The stdlib is also at v2 now (e.g. mat
2719.
by 9rx 2y ago
> The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface. To be fair, that expression came from a blogger who often wrote about Go. It is not a tenet held by the Go project. In f
2720.
by 9rx 2y ago
> Useless: the server was written in Go and the logs had no information about where the error was originating. [...] In a language with exceptions there'd have been a stack trace that pinpointed exactly where the error originated
2721.
by 9rx 2y ago
Checked exceptions may be implemented as a sum type. Traditional exceptions are more likely to be a single type that wraps up a context object alongside stack trace information.
2722.
by 9rx 2y ago
> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language Go functions also accept a tuple on input. While theoretically you could p