I actually kind of like the error handling. Code should explain why something was a problem, not just where it was a problem. You get a huge string of “couldn’t foobar the baz: target baz was not greebleable: no greeble provider named fizzbuzz”, and while the strings are long as hell they are much better explanations for a problem than a stack trace is.
a desperate fear of modular code that provides sound and safe abstractions over common patterns. that the language failed to learn from Java and was eventually forced to add generics anyway - a lesson from 2004 - says everything worth saying about the language.
The language was designed to be as simple as possible, as to not confuse the developers at Google. I know this sounds like something I made up in bad faith, but it’s really not.
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike
The infamous if err != nil blocks are a consequence of building the language around tuples (as opposed to, say, sum types like in Rust) and treating errors as values like in C. Rob Pike attempts to explain why it’s not a big deal here.
Having a Result[T, Err] monad that could represent either the data from a successful operation or an error. This can be generalised to the Either[A, B] monad too.
Its how rust does error handling for example, you have to test a return value for “something or nothing” but you can pass the monadic value and handle the error later, in go you have to handle the error explicitly (almost) all the time.
Here’s an example (first in Haskell then in Go), lets say you have some types/functions:
type Possible a = Either String a
data User = User { name :: String, age :: Int }
validateName :: String -> Possible String
validateAge :: Int -> Possible Int
then you can make
<span style="color:#323232;">mkValidUser :: String -> Int -> Possible User
</span><span style="color:#323232;">mkValidUser name age = do
</span><span style="color:#323232;"> validatedName ← validateName name
</span><span style="color:#323232;"> validatedAge ← validateAge age
</span><span style="color:#323232;"> pure $ User validatedName validatedAge
</span>
for some reason <- in lemmy shows up as <- inside code blocks, so I used the left arrow unicode in the above instead
in Go you’d have these
(no Possible type alias, Go can’t do generic type aliases yet, there’s an open issue for it)
In the Haskell, the fact that Either is a monad is saving you from a lot of boilerplate. You don’t have to explicitly handle the Left/error case, if any of the Eithers end up being a Left value then it’ll correctly “short-circuit” and the function will evaluate to that Left value.
Without using the fact that it’s a functor/monad (e.g you have no access to fmap/>>=/do syntax), you’d end up with code that has a similar amount of boilerplate to the Go code (notice we have to handle each Left case now):
<span style="color:#323232;">mkValidUser :: String -> Int -> Possible User
</span><span style="color:#323232;">mkValidUser name age =
</span><span style="color:#323232;"> case (validatedName name, validateAge age) of
</span><span style="color:#323232;"> (Left nameErr, _) => Left nameErr
</span><span style="color:#323232;"> (_, Left ageErr) => Left ageErr
</span><span style="color:#323232;"> (Right validatedName, Right validatedAge) =>
</span><span style="color:#323232;"> Right $ User validatedName validatedAge
</span>
Swift and Rust have a far more elegant solution. Swift has a pseudo throw / try-catch, while Rust has a Result<> and if you want to throw it up the chain you can use a ? notation instead of cluttering the code with error checking.
The exception handling question mark, spelled ? and abbreviated and pronounced eh?, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can’t do foo()?.bar()?.baz()? in Haskell so it’s only theoretical purity which is half-arsed, not ergonomics.
It’s not a half-arsed copy, it’s borrowing a limited subset of HKT for a language with very different goals. Haskell can afford a lot of luxuries that Rust can’t.
It’s a specialised syntax transformation that has nothing to do with HKTs, or the type system in general. Also HKTs aren’t off the table it’s just that their theory isn’t exactly trivial in face of the rest of Rust’s type system but we already have GATs.
It actually wouldn’t be hard writing a macro implementing do-notation that desugars to and_then calls on a particular type to get some kind of generic code (though of course monomorphised), but of course that would be circumventing the type system.
Anyhow my point stands that how Rust currently does it is imitating all that Haskell goodness on a practical everyday coding level but without having (yet) to solve the hard problem of how to do it without special-cased syntax sugar. With proper monads we e.g. wouldn’t need to have separate syntax for async and ?
Note: Lemmy code blocks don’t play nice with some symbols, specifically < and & in the following code examples
This isn’t a language level issue really though, Haskell can be equally ergonomic.
The weird thing about ?. is that it’s actually overloaded, it can mean:
call a function on A? that returns B?
call a function on A? that returns B
you’d end up with B? in either case
Say you have these functions
<span style="color:#323232;">toInt :: String -> Maybe Int
</span><span style="color:#323232;">
</span><span style="color:#323232;">double :: Int -> Int
</span><span style="color:#323232;">
</span><span style="color:#323232;">isValid :: Int -> Maybe Int
</span>
and you want to construct the following using these 3 functions
<span style="color:#323232;">fn :: Maybe String -> Maybe Int
</span>
<span style="color:#323232;">class Chainable f a b fb where
</span><span style="color:#323232;"> (?.) :: f a -> (a -> fb) -> f b
</span><span style="color:#323232;">
</span><span style="color:#323232;">instance Functor f => Chainable f a b b where
</span><span style="color:#323232;"> (?.) = (<&>)
</span><span style="color:#323232;">
</span><span style="color:#323232;">instance Monad m => Chainable m a b (m b) where
</span><span style="color:#323232;"> (?.) = (>>=)
</span>
and then get roughly the same syntax as rust without introducing a new language feature
though this is more general than just Maybes (it works with any functor/monad), and maybe you wouldn’t want it to be. In that case you’d do this
<span style="color:#323232;">class Chainable a b fb where
</span><span style="color:#323232;"> (?.) :: Maybe a -> (a -> fb) -> Maybe b
</span><span style="color:#323232;">
</span><span style="color:#323232;">instance Chainable a b b where
</span><span style="color:#323232;"> (?.) = (<&>)
</span><span style="color:#323232;">
</span><span style="color:#323232;">instance Chainable a b (Maybe b) where
</span><span style="color:#323232;"> (?.) = (>>=)
</span>
restricting it to only maybes could also theoretically help type inference.
I was thinking along the lines of “you can’t easily get at the wrapped type”. To get at b instead of Maybe b you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they’re awkward in a monadic context) whereas Rust will gladly hand you that b in the middle of an expression, and doesn’t force you to name the point.
Or to give a concrete example, if foo()? {…} is rather awkward in Haskell, you end up writing things like
<span style="color:#323232;">foo x y = bar >>= baz x y
</span><span style="color:#323232;"> where
</span><span style="color:#323232;"> baz x y True = x
</span><span style="color:#323232;"> baz x y False = y
</span>
, though of course baz is completely generic and can be factored out. I think I called it “cap” in my Haskell days, for “consequent-alternative-predicate”.
Flattening Functors and Monads syntax-wise is neat but it’s not getting you all the way. But it’s the Haskell way: Instead of macros, use tons upon tons of trivial functions :)
It’s not. The default sorter does that, because that way it can sort pretty much anything without breaking at runtime. You can overwrite it easily, though. For the example above you could simply do it like this:
I said ESLint. Not Javascript. ESLint is a linter for JavaScript. That’s why I put JavaScript in brackets. Some people don’t know what ESLint is. I’m talking about ESLint the whole time. Its not JavaScript specific but it’s mostly used for JavaScript
You yourself are talking about ESLint. You said that ESLint won’t prevent me from creating unused variables and functions when it clearly does. It won’t even run and throw an error
Edit: ohh it’s a Lemmy bug. The comment didn’t update yet. Originally I said “ES6” then I changed it to “JavaScript” and then I changed it to “ESLint (JavaScript)”
What the post is about is compiler based clean code enforcement. JS doesn’t do this, but your editor in combination with ESLint prevents you from running the program. However this isn’t a general JS thing, just the way your setup works.
Just saw your edit, and yeah, that makes sense as to the confusion.
Either way, your comment enquired as to whether it was “the same” and it still isn’t because for Go it’s a language feature and ESLint is not a language, it just allows you to create similar behaviour for JavaSvript which, by default, does not exhibit that behaviour.
Also Go: exceptions aren’t real, you declare and handle every error at every level or declare that you might return that error because go fuck yourself.
It is better than in most languages with exceptions, except from languages like Java, that require you to declare that certain method throws certain error.
It’s more tedious in Go, but at the end of the day it’s the same thing.
When I use someone else’s code I want to be sure if that thing can throw an error so I can decide what to do with it.
Java doesn’t have to declare every error at every level… Go is significantly more tedious and verbose than any other common language (for errors). I found it leads to less specific errors and errors handled at weird levels in the stack.
It’s better than “invisible” exceptions, but it’s still the worst “better” version. The best solution is some version of the good old Result monad. Rust has the BEST error handling (at least in the languages i know). You must handle Errors, BUT they are just values, AND there’s a easy, non-verbose way of passing on the error (the ? operator).
A quick “find all references” will point out it’s not used and can be deleted if it accidentally gets checked in but ideally, you have systems in place to not let it get checked into the main branch in the first place.
Or a linter. Or code reviews. Or anything else. The nice thing is that if the compiler doesn’t demand something, it can be given to the engineer as an option. The compiler should have the option to do it. The option could even be defaulted on. Afaik there is no way in Golang to disable that error (this is the line that does it: github.com/golang/go/blob/…/stmt.go#L67-L69). like --no-pedantics or such. Golang’s compiler openly refuses to give engineers more choices in what they think is the best system to handle it.
If it is a pure value, I’d assume yes, but if it is tied to a side effect (E.g. write its value to a file), then it would be not used but still could break your app if removed.
I’m not familiar with rust language specifically, but generally that’s what could happen
I prefer for it to be just a warning so I can debug without trouble, the build system will just prevent me from completing the pull request with it (and any other warning).
If only there was some way the compiler could detect unused variable declarations, and may be emit some sort of “warning”, which would be sort of like an “error”, but wouldn’t cause the build to fail, and could be treated as an error in CI pipelines
Let’s not pretend people acknowledge warnings, though. It’s a popular meme that projects will have hundreds of warnings and that devs will ignore them all.
There’s a perfectly valid use case for opinionated languages that don’t let you get away with that. It’s also similar to how go has gofmt to enforce a consistent formatting.
You can, if you want, opt into warnings causing your build to fail. This is commonly done in larger projects. If your merge request builds with warnings, it does not get merged.
In other words, it’s not a bad idea to want to flag unused variables and prevent them from ending up in source control. It’s a bad idea for the compiler to also pretend it’s a linter, and for this behaviour to be forced on, which ironically breaks the Unix philosophy principle of doing one thing and doing it well.
Mind you, this is an extremely minor pain point, but frankly this is like most Go design choices wherein the idea isn’t bad, but there exists a much better way to solve the problem.
Jennifer is a lesbian. Her wife, now husband, who she’s proudly supportive of, is FtM, with 3 previous children that Jennifer adopted. Jennifer has never had penetrative sex with a man.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.