551–560 of 561 posts
Earlier quoted context omitted.
You generally want newtypes as proofs that a value has gone through some validation.
And what prevents you using them this way in Go? Just make a package and export a constructor function that does the validation.
I don't understand all the attention these articles are getting. If you don't like it, stop using it. Why are you going to so much effort to complain? You can write bad code in any language. You can write difficult to read code in any language. Every language has pitfalls and downsides. Personally, I work in golang full time, and I adore it. Development is painless, and our codebase feels very easy to read.
Some languages make it much easier to write bad code. Some languages introduce safety checks that eliminate entire classes of bugs. So your claim that all languages are the same is very far away from the truth; not all tools are the same.
The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…
It would've never got to where it's at if it wasn't for Google, that's the most important reason why its successful.
Earlier quoted context omitted.
It’s a big assumption that you can even handle the error at the callsite, or that you will actually handle it correctly there, or just write some low-effort attempt because the overall picture is more important for now, but later on you won’t notice how it is not correct and it will just silently fail. Exceptions are in my honest opinion better on every single front. Checked exceptions would be the panacea but Java’s…
consider this example - one using dynamic code with exception-based handling (ruby), and one using golang's more explicit error handling: ruby: begin res = Net::HTTP.post_form(APIURL, ...) puts res.body rescue e => e # do error handling end go: response, err := http.PostForm(APIURL, url.Values{...}) if err != nil { # handle PostForm error } defer response.Body.Close() body, err := ioutil.ReadAll(response.Body) if err…
Been programming Ruby for 8 years and have never seen anyone do that, so no... If that block of code can really throw so many different types of exceptions (usually - it can't) you can always catch StandardError.
The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…
> The better alternative to Go is Rust Nope, a better alternative is Java/C#/Kotlin/etc. Those offer sum types, async programming, while being more productive than golang, and provide superior tooling and a superior developer experience.
Earlier quoted context omitted.
oxnrtr is in this conversation too. And when describing the length of a document, "pages" universally means the number of printed pages it would occupy, not the number of computer files it's stored in.
There is no sign of anyone else participating in this conversation. Else we'd have heard their input by now. A page referring to a single HTML resource is standard nomenclature. Paper is antiquated technology, not how the Go specification is distributed, and carries no relevance to this discussion.
Earlier quoted context omitted.
And what prevents you using them this way in Go? Just make a package and export a constructor function that does the validation.
I think that was the author's point. You _can_ use them this way but it's a hassle and most people don't do it. The language itself doesn't protect you against zero-initialisation errors, even though it could.
Earlier quoted context omitted.
You can define NonZeroU64 in Go exactly the same way it's defined in Rust – as a struct with a private field. No interfaces required. But I was wondering why you would want an opaque type internally to a package . Presumably not to ensure that the value has passed some validation, since in that case you would want to encapsulate that validation logic in its own package. It's not like Go imposes a tax on packages. Pac…
> But I was wondering why you would want an opaque type internally to a package. You can have a public function (a constructor) returning an instance of a private type. This way you ensure it's not zero-initialised by default (you can't do "var f privateType", you need to call the constructor). But it's annoying to do. For every type you'd ever want to protect against zero-initialisation, you'd need to declare it pri…
To me it seems extremely weird to phrase this kind of criticism by saying that Go lacks proper support for newtypes, which simply isn’t true. If the author’s real complaint is with zero initialization then it would be a lot easier to understand their point if they made this explicit.
> But it's annoying to do. For every type you'd ever want to protect against zero-initialisation, you'd need to declare it private in some other package, and create a constructor.
How is this annoying? You’ll need a constructor anyway if you’re doing validation on the value. Apart from that you’re just complaining about having to make a package, but that’s really simple. I don’t see how Go would be improved by layering additional privacy mechanisms on top of the package system.
The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…
In my experience it is only increased initial development time.
I find that initial development time is frequently conflated with development time overall.
So obviously worse is better languages will be preferred.
Earlier quoted context omitted.
> But I was wondering why you would want an opaque type internally to a package. You can have a public function (a constructor) returning an instance of a private type. This way you ensure it's not zero-initialised by default (you can't do "var f privateType", you need to call the constructor). But it's annoying to do. For every type you'd ever want to protect against zero-initialisation, you'd need to declare it pri…
Zero initialization is a pretty fundamental concept in Go. I can see why people might not like it, but if you are trying to prevent a large number of types from being zero initialized then you are just going against the grain of the language. In most cases you can arrange to make the zero value valid. To me it seems extremely weird to phrase this kind of criticism by saying that Go lacks proper support for newtypes,…
I don't get it. There's nothing particularly special about it other than it being an explicit choice (I suspect Go's developers were lazy and did whatever was easier to implement). If, instead of automatically initializing to zero, the compiler said "error: uninitialized struct field", we wouldn't be having this conversation, and we wouldn't have this class of bugs. I would consider it "fundamental" if there was an obvious benefit from this choice, but I think a more appropriate word is "arbitrary".
> In most cases you can arrange to make the zero value valid.
Valid doesn't mean correct. Corrupting the DB with zero-initialized data can be worse than crashing early due to an unitialized (nil) pointer.
> If the author’s real complaint is with zero initialization then it would be a lot easier to understand their point if they made this explicit.
They did, it's mentioned in several places. E.g.:
---
Go fails to prevent many other classes of errors: it makes it easy to accidentally copy a mutex, rendering it completely ineffective, or leaving struct fields uninitialized (or rather, initialized to their zero value), resulting in countless logic errors.
---
> Apart from that you’re just complaining about having to make a package, but that’s really simple.
In order to prohibit direct struct initialization (which can be a source of unintended bugs) and enforce using the constructors, two types "related" to each other would have to live in different packages. E.g., if a type A's method constructs a type B, you'd segregate them and keep only the constructors public. In the context of a medium-sized project, you will end up with MANY packages. Sure, it's simple to create packages, but it can becomes painful to manage once you need to understand the code. So at the end of the day, people don't do it and instead elect to be "more careful", which isn't a good method of preventing bugs.