541–550 of 559 posts
Earlier quoted context omitted.
Option types as error handling works but it requires proper syntax. Haskell can do it with do-notation and Rust has its special ? operator. Go has boiler-plate.
Honest question - do you think there's a better way to do it?
Earlier quoted context omitted.
Well we are in a discussion thread about a language that does just that :) I see two issues with the `?` operator: 1. Most Go code doesn't actually do return nil, err but rather return nil, fmt.Errorf("opening file %s as user %s: %w", file, user, err) that is, the error gets annotated with useful context. What takes less effort to type, `?` or the annotated line above? This could probably be solved by enforcing that…
For the first point, there are two common patterns in rust: 1. Most often found in library code, the error types have the metadata embedded in them so they can nicely be bubbled up the stack. That's where you'll find `do_a_thing().map_err(|e| Error::FileOpenError { file, user, e })?`, or perhaps a whole `match` block. 2. In application code, where matching the actual error is not paramount, but getting good messages…
I'm a huge fan of keeping things simple; my experience has shown me that complex things have lots of obscure failure points, while simple things are generally more robust.
Earlier quoted context omitted.
> Go is a very opinionated language from it's inception. True. > We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. This is part of the story that Rob Pikes uses to justify how opinionated Go is, but it's a bit stupid given that most language do fine and I've never seen any debates about the code formatting after the very beginning of a project (where it's a…
> most language do fine No, they don't. Most languages turn dealing with code formatting, into an externality foisted upon either: • the release managers (who have to set up automation to enforce a house style — but first have to resolve interminable arguments about what the given project's house style should be , which creates a disincentive to doing this automation); or • the people reviewing code in the language.…
Really, they do: there a millions of us coding in those other languages just fine, and automatic formatting has been a thing for decade, and I'm not aware of a single language out there that doesn't have such a formatting tool.
The only exception with Go is that you cannot change the default settings. But that's it. In any other language you can use a code formatter with the default settings and the “speedbump in the way of automating formatting” you talk about doesn't exist anywhere but in your mind.
> where it can be relied upon to be present and so used in pre-commit hooks
You know that a failing git hook aborts the commit? So that with any language, if the formatter isn't installed in the machine, the commit cannot be performed, which means that the formatter can actually be relied upon anyway. In practice, the hardest part is making sure people all have the git hook installed (that's not that hard but that's the hardest part).
As I said before, Go has many useful properties, but automatic formatting is definitely not what makes Go relevant, and the endless stream of Gophers who argue this are just ridiculing themselves in front of everybody else.
Earlier quoted context omitted.
> Secondly, the Go team were never against generics, the three early designers agreed the language needed generics but they couldn't figure out a way to add it orthogonally. This is a PR statement that has been introduced only after Go generics landed, for years generics were dubbed “unnecessary complexity” in user code (Go has had generics from the beginning but only for internal use of the standard library). > Go h…
70% of cloud tools on CNF are built with Go; Kubernetes is just one of many. Also, since Kubernetes was originally started as a Java project you should consider whether the team was trying to code more with Java idioms than with Go ones. Nodejs has been more successful than Go in cloud?
Yes, that's what's called an ecosystem effect. But k8s has been the biggest open source codebase for a while, so it's far from insignificant.
> you should consider whether the team was trying to code more with Java idioms than with Go ones.
Turns out generics, the “Java idiom” in question, was eventually added to Go after many years, so maybe it was in fact useful and it's not just k8s devs who where idiots following “java idioms”…
> Nodejs has been more successful than Go in cloud?
Nodejs has been more successful than Go in pretty much everything except in orchestration tools (because of the ecosystem effect mentioned above) which is a tiny niche anyway. Go is a very small language on terms of use compared to Nodejs, or PHP, which are arguably language with a terrible design.
Earlier quoted context omitted.
Honest question - do you think there's a better way to do it?
Better than Go? Yes Rust, Haskell, OCaml all do it better. Better than those? Probably - the design space has hardly been explored!
Earlier quoted context omitted.
> Source? To which language? > `enum` is a "true" enum, while an `enum class` somehow isn't? No. Enums are used in both cases. The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. This differs from Rust. Rust does not use enums. It relies on the type itself to carry all the information. C++ enum classes could have done the same, so it is not cl…
> To which language? I mean more in the sense of "where did you get this definition from." > The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. I'm still not seeing a difference, mainly because when I went to see how c++'s `enum class` and rust's `enum`, they both seemed to work the same. #[repr(u8)] enum Words { Foo = 0, Bar, Baz, } const _:…
In other words, you want to have a conversation with someone else by proxy? If that's the case, why not just go talk the other people you'd really prefer to talk to?
> I'm still not seeing a difference
There is no difference. I recant what I said. This (strangely, undocumented in the above link) functionality does, in fact, provide use of enums.
Curious addition to the language. Especially when you consider how unsafe enums are. When would you ever use it? It is at least somewhat understandable in C++ as it may be helpful to "drop down" to work with the standard enum construct in some migratory situations, but when do you use it in Rust?
Earlier quoted context omitted.
> I think it even makes sense for go purists, like you need to handle errors or get panicked. You think wrong. Go preaches that zero values should be useful, with means in the common (T, error) scenario, T should always be useful even if there is also an error state. Worst case, you will get the zero value in return, which is still useful. This means that the caller should not need to think about the error unless it…
> T should always be useful even if there is also an error state. I disagree with this blanket assertion. In a limited set of cases would I ever expect a result to be valid if there was also an error. Also, when you disagree with what someone thinks, there are different ways to respond and using "You think wrong" is probably one of the most confrontational ways of responding.
You have to return something for T. Go does not allow you to return nothing. Why would you return garbage when you can just as easily return the zero value, that of which should always be useful? Yes, you technically could return garbage, but why? There is absolutely no justification. Consider,
func GetUser() (*User, error) {
return nil, ErrNotFound
}
What's the alternative?
func GetUser() (*User, error) {
return &User{
Name: "No User",
Email: "not@found.com",
Role: DoesNotExist,
}, ErrNotFound
}
> Also, when you disagree with what someone thinks, there are different ways to respond and using "You think wrong" is probably one of the most confrontational ways of responding.
Imagine thinking that the output of software is being confrontational or exhibiting of any kind of output that congers this kind of change in "emotional state". As nonsensical as the random number generator outputting three consecutive 6s and then concluding that it must be the work of the devil. So strange.
Earlier quoted context omitted.
For the first point, there are two common patterns in rust: 1. Most often found in library code, the error types have the metadata embedded in them so they can nicely be bubbled up the stack. That's where you'll find `do_a_thing().map_err(|e| Error::FileOpenError { file, user, e })?`, or perhaps a whole `match` block. 2. In application code, where matching the actual error is not paramount, but getting good messages…
It might just be me, but I find both of those to be massively less readable. More terse is not the same as more readable (in fact, I find the reverse). I'm a huge fan of keeping things simple; my experience has shown me that complex things have lots of obscure failure points, while simple things are generally more robust.
> More terse is not the same as more readable (in fact, I find the reverse).
I generally agree, but I also find that "all explicit" also hinders readability because it tends to drown the nitty-gritty details. As always it's a matter of balance :) And I think that neither go nor rust are great in this matter as one is verbose and the other falls in the "keyword soup" with the chain call, the closure, and the format macro. I'm pretty sure something in between could be found.
Earlier quoted context omitted.
> To which language? I mean more in the sense of "where did you get this definition from." > The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. I'm still not seeing a difference, mainly because when I went to see how c++'s `enum class` and rust's `enum`, they both seemed to work the same. #[repr(u8)] enum Words { Foo = 0, Bar, Baz, } const _:…
> I mean more in the sense of "where did you get this definition from." In other words, you want to have a conversation with someone else by proxy? If that's the case, why not just go talk the other people you'd really prefer to talk to? > I'm still not seeing a difference There is no difference. I recant what I said. This (strangely, undocumented in the above link) functionality does, in fact, provide use of enums.…
sorry, I didn't mean to be so argumentative or negative. (The "You'll have to ask the Rust community. Rust lacks enums." did get me a little annoyed :p)
> This (strangely, undocumented in the above link) functionality does, in fact, provide the use of enums.
That link was from "the rust book" which is primarily is for learning rust. For more technical info the referenced is used https://doc.rust-lang.org/reference/items/enumerations.html
> When would you ever use it?
I assume (like you said for c++) a good reason would be for c/c++ interoperate, but it also probably makes things like serialization easier. Sometimes you just need a number (e.g. indexing an array) and it's simpler to be able to cast then have a function that goes from enum -> int.
> Especially when you consider how unsafe enums are.
Do note though, going from int -> enum is an unsafe op which would require `std::mem::transmute`.
Earlier quoted context omitted.
> I mean more in the sense of "where did you get this definition from." In other words, you want to have a conversation with someone else by proxy? If that's the case, why not just go talk the other people you'd really prefer to talk to? > I'm still not seeing a difference There is no difference. I recant what I said. This (strangely, undocumented in the above link) functionality does, in fact, provide use of enums.…
> Why not just go talk the other people you'd really prefer to talk to? sorry, I didn't mean to be so argumentative or negative. (The "You'll have to ask the Rust community. Rust lacks enums." did get me a little annoyed :p) > This (strangely, undocumented in the above link) functionality does, in fact, provide the use of enums. That link was from "the rust book" which is primarily is for learning rust. For more tech…
Thanks, but I had no reason to think that the output of software has human qualities.
> That link was from "the rust book" which is primarily is for learning rust.
Learn Rust by keeping features of the language a secret? Intriguing.
> a good reason would be for c/c++ interoperate
I'm not sure that's a good reason. C++ doing it is questionable to begin with, but at least you can understand how a bad idea might have made it in many years ago when we didn't know any better.
> it also probably makes things like serialization easier.
It would, except you would never want to serialize the product of an enum as it means your program becomes forever dependent on the structure of the code. I mean, sure, you can remove the enum later if you are to change the code, so you're not truly stuck, but that kind of defeats the purpose. You may as well do it right the first time.
Enums are inherently unsafe. That you have to be explicit about converting the union to an integer at least gives some indication that you are doing something unsafe. It is not so unusual that Rust allows some kind of "escape hatch" to get at the actual memory. What is interesting, though, is that it also allows manipulation of what values are assigned by the enumerator as a first-class feature, which suggests that it promotes this unsafe behaviour. This is what is surprising and what doesn't seem to serve a purpose.