251–260 of 481 posts
Earlier quoted context omitted.
same :) maybe also relax rules a bit to allow type elision for structs in function calls to get python like keyword args. foo("blah", {option1: true}) would work better than functional options people use now.
I think they should freeze the language for the next 10 years or so.
Earlier quoted context omitted.
I cannot wait for the Result monad. The state of error handling in Go at the moment is embarrassing at best.
Emulating sum types in languages without pattern matching is extremely awkward, to the point of being almost useless. type Result[T] struct { ok: *T err: error } Great, so how do you work with it? * You can have a `ok()` getter that returns `*T`. Now you you need an `if x != nil` * `isOk()` + `isErr()` * `unwrap() T`, which panics on errors * `split() (*T, err)` that splits into separate values, especially awkward si…
No. You can just feed it to the function (from a library / stdlib) that needs it, or call .fold() in the end.
Earlier quoted context omitted.
In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.
Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…
Additive changes can be breaking changes quite easily, as those additions are adopted within a minor version range, as automated tooling needs to distinguish their presence, as documentation fragments.
My next biggest gripe with semver—that 0.y.z has entirely different semantics from any other major version—may actually be semantically better if adopted wholesale. If your interface changes, major version bump. Else you’re fixing bugs or otherwise striving to meet extant expectations.
Earlier quoted context omitted.
Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…
> Sure, but semantic versioning really is the wrong kind of versioning to use for a language. I don't agree. I usually don't care so much when a particular feature was introduced into a language (and if I do, it's usually a Wikipedia search away). I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler. Semantic versioning can tell me the latter. Making versioning a…
The PR version doesn't even have to be numeric. You can give them proper names.
Earlier quoted context omitted.
Rely more on the map/map_err/or_else/... methods for the Result type. You'll get something like (pseudocode): may_fail_who_knows() .map(use_value) .map_err(some_error_processing) .and_then(another_computation_which_can_fail) .or_else(with_some_error_handling_that_can_rescue) .unwrap_or(a_default_value) Basically, instead of nested match expressions, you get a "pipeline".
This is equivalent to: let x = match may_fail_who_knows() { Ok(y) => Ok(another_computation_which_can_fail(use_value(x))), Err(e) => with_some_error_handling_that_can_rescue( some_error_processing(e)), }; match x { Ok(y) => y, _ => a_default_value, } It's a bit more verbose than using the combinators, but someone coming across it for the first time will understand it immediately because there's less to remember to un…
You just had to write the concrete types (Ok and Err) out. What if these types are changed later on, e.g. to "Some(...)" and "None" or "Ok" and "ManyErrs(...)"?
As you said, it is easier to understand. Because it less abstract. This can be a good thing, but as well be a bad thing - but one thing is sure: while it does the same in the concrete case, the code is not "equivalent" when it comes to refactoring and certain changes.
Earlier quoted context omitted.
Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…
> The major version should represent major language changes, not whether its a breaking change or not Why? Old code still work and unless you are purposefully maintaining an old system you are expected to use the last version anyway. What does it actually change that generics were introduced in version 1.18 rather than 2.0? From now on, Go has generics. As there is no breaking change, it’s not like you had to keep us…
So now that go has generics and modules, is there an up-to-date intro for writing cutting-edge Go code for people who are already pretty familiar with the older styles?
https://www.makeworld.space/2020/11/go_modules.html
Looking for a tutorial on generics myself.
Earlier quoted context omitted.
Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…
I thank Go team, that the major version was not increased. You can't imagine how much wider adoption of generics will be as compared if Go went to version 2.0 There are thousands of under-educated and overly-cautious software development managers who would prevent their teams from upgrading to a major version of Go until it is "proven". When it comes to developers there are two types who read changelogs and would kno…
If semantic versioning is used correctly, like here, that's actually a reasonable-ish attitude.