Merovius

10 ms·

91.
Persistent datastructures with Go(blog.merovius.de)
3 points by Merovius 9y ago|0 comments
92.
What even is error handling? (2018)(blog.merovius.de)
2 points by Merovius 9y ago|0 comments
93.
Generating entropy without imports in Go(blog.merovius.de)
1 points by Merovius 9y ago|0 comments
94.
by Merovius 9y ago
> Except you're having to implement them yourself. This is plainly wrong. All components I mentioned exist in the stdlib. You have to glue them together yourself, sure, but that's the point of having components with separated c
95.
by Merovius 9y ago
> In this case, I suppose my specific complaint is that I'm unable to make `range` work transparently with an arbitrary type. Sure, fair enough. But note that you've now shifted the criticism from "I have to import 4 packa
96.
by Merovius 9y ago
> Here's how I, at least, would like it to work: I still don't get what your problem is. It seems what you want is to just take an io.Reader and pass that to bufio.NewScanner, solving your problem and letting your caller figure
97.
by Merovius 9y ago
I hate this kind of "if only you'd write large programs and not just toys, you'd understand how bad Go is". I write Go at work. I haven't counted in a while, but I guess the code of my team comprises significantly m
98.
by Merovius 9y ago
> you end up having to frequently write type-switches which are checked at runtime to do any sort of generic code. This baffles me. I think I basically never use any type-switches, with the exception of interfaces being used as a sum-typ
99.
Monads are just monoids in the category of endofunctors(blog.merovius.de)
3 points by Merovius 9y ago|0 comments
100.
by Merovius 9y ago
Sure. It's an easy problem to fix, now that the team is aware it. I'm pretty sure they'll solve it for Go 2. In the meantime, it would break the compatibility promise, so it's just a kludge we have to live with. I basica
101.
by Merovius 9y ago
> It just feels like I basically never want it to be a copy, but you do frequently want to modify the element you're iterating over. Feels differently to me :) > It actually pushes you to design things in ways you might otherwise
102.
by Merovius 9y ago
No, not really, it's a natural and unintended consequence of how the spec scopes variables in loops/switches/conditionals: https://golang.org/ref/spec#Blocks The problem you are trying to solve is, that
103.
by Merovius 9y ago
> Hypothetically, if the language defined for i, x := range xs to have x repeatedly be a new reference to each of xs members, it seems like we'd avoid 2 gotchyas I'm not convinced. I believe what you'd end up with is that
104.
by Merovius 9y ago
> they are far too trivial. You'd have thunk I didn't have to make them than. But I did, judging from literally every argument I had about this.
105.
by Merovius 9y ago
Sorry, you are right, of course. I fell victim to one of the internet's classic blunders: Skimming a long comment thread and not carefully read what I reply to in the end :)
106.
by Merovius 9y ago
> It is impractical to expect go’s designers to have foreseen the best trade off for every codebase. Which is not the argument made by anyone. Indeed, I explicitly acknowledge that there is a certain fraction of use-cases not covered by
107.
by Merovius 9y ago
The fact that maps/slices/channels already exist generically is what puts Go into the sweet spot. You have generic containers for the vast majority of use-cases, so the value-added consideration of being able to cover more use
108.
by Merovius 9y ago
> I think the OP is fundamentally right about the sweet spot being pretty far from either extreme, I just disagree slightly about where exactly :) And I think an important take-away should be, that this perception is entirely subjective
109.
by Merovius 9y ago
The article makes two main points: a) static typing has a cost and b) thus, any benefit it brings should be examined against that cost. I am sorry, but I don't really see how you stating more benefits of static typing really counters e
110.
by Merovius 9y ago
> For example I can prove my my string reverse works in Idris ( https://www.stackbuilders.com/news/reverse-reverse-theorem-p... ). This article basically demonstrates GP point, though. It proves that `reverse` is self
111.
by Merovius 9y ago
> The author of the article implicitly equates "statically verified code" with "bug-free code". Not at all. First, the statements as put here are discrete (boolean even) while I present both "statically verified
112.
by Merovius 9y ago
It does (though admittedly not very explicitly), it just rolls it into the "benefit" (i.e. not shipping broken code is a benefit) and the "weight given to stability". If a bug discovered in prod (or even qa/canary
113.
by Merovius 9y ago
> Well, the easy answer is that dependently-typed languages like Agda and Idris aren't very mature yet. It's also self-evidently wrong. Agda was first released in 1999, ten years before Go. If you use a wallclock interpretation
114.
by Merovius 9y ago
> I used that to segue into quite a rant about how I lamented the lack of complexity in software. A software that does the right thing for everyone without any settings is several orders of magnitude more complex than a software that jus
115.
Diminishing returns of static typing(blog.merovius.de)
6 points by Merovius 9y ago|1 comments
116.
by Merovius 9y ago
> Here, both x and y are conceptually nil, but y cannot be compared to nil. I disagree with the "conceptual nilness" of y. x is a perfectly fine and usable implementation of io.Closer. It doesn't even panic. Having a nil-c
117.
by Merovius 9y ago
Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Contrast that with void-pointers, which make that so easy as to be a common bug-source. It's not statically type-checked, yes. That
118.
by Merovius 9y ago
> I said "it's unsafe", not "it's not safer than void ". I'm sorry, but then you're simply in the wrong thread. You where replying to a interface{} vs. void comment, so that's what you shoul
119.
by Merovius 9y ago
> Golang can have less keywords, because it has less features. So, you are saying… because it's less complex?
120.
by Merovius 9y ago
I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

More ›