111–120 of 481 posts
After generics (coming soon), a proper sum type and then I'll shut up.
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.
Earlier quoted context omitted.
Well it's better than most language with exceptions. People makes it a big deal, in reality it's not.
An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.
Earlier quoted context omitted.
Lol so true, go a little overboard with fancy language features and people think you’re a cowboy coder
I was in an interview not long after format strings in Python came out (for example, print(f”Hello, {name}”) rather than print(“Hello, %s”, name)) and the interviewer thought I was confusing languages and features, asserted this fact strongly, and was pretty surprised when it worked, but I think overall I lost points because the interviewer lost face. C’est la vie.
Earlier quoted context omitted.
Doesn’t it? Is this new?
As far as I know this was always possible since modules were introduced. You just have to prefix the version tags for Go with the subdirectory in the repo: "my/sub/directory/vX.Y.Z"
Earlier quoted context omitted.
Typescript is stricter and safer while also being less obtrusive than Go
Any language based on JS can't be safer than Go. The end result of TS is JS which is a dynamic language.
Their code is full of things like: type fileOps []any // []T where T is (string | int64) Go does not have neither generics nor union types. So people have to do this kind of thing :( I feel sorry for them. Reminds of Java 4 (15 years ago or something) where code was full of this crap: List /* */ values; Map /* */ map; Some devs spent a whole week doing nothing other than removing those commented out generic type decl…
> I feel sorry for them. Oh good grief. There are 32,768 programming languages. People are free to pick the ones they want to use and nobody wants your pity.
Ball is in your court now typescript-on-the-serverside ppl!
I didn't realize there was a "war" going on between the two groups. If there is, I imagine it's not among the type of people who you'd want leading technical decisions at your company.
And before people identify me as a TS fanboy, I'm not, I'm a go hater.
I'm not sure I like this change. I liked interface{} since it just works out naturally from Go's relatively simple type system, and anyone could come to the conclusion without actually being told "use interface{} to represent any possible value" just by having an understanding of that type system. Adding what is simply a type alias, multiple words for the same underlying concept, to me just feels like jargon. I admir…
The baseline is that constraints aren’t best expressed as interface literals in situ. Unlike exceptional use of ‘interface{}’, ‘any’ will be a more naturally invoked constraint.
Also, some of the uses of constraints rely on a unification involving an ‘any’ term that cancels out. Here, the use of ‘interface{}’ is not incorrect but maybe indirect.
Earlier quoted context omitted.
Typescript is stricter and safer while also being less obtrusive than Go
Any language based on JS can't be safer than Go. The end result of TS is JS which is a dynamic language.