DEV Community: dean

Semicolon Rules in JavaScript are weird...

dean — Mon, 17 Sep 2018 18:22:34 +0000

I'd like to preface this with that I really do like JavaScript. It has quirks, although most of them are edge cases that you won't encounter. But I just found one that I'm still confused, and I'd rather not look up the JavaScript spec just to figure this out...

My original function:

function cubicBezier(x, u0, u1, u2, u3) {
    return
        u0 * (1 - x) * (1 - x) * (1 - x) +
        u1 * (1 - x) * (1 - x) * x +
        u2 * (1 - x) * x * x +
        u3 * x * x * x;
}

Some of you seasoned JavaScript experts might see this and go "it will always return undefined", because the return is interpreted as return; since nothing else follows. This got me wondering about semicolon rules in JavaScript.

My favorite programming language is Go, which also has optional semicolons. The semicolon rules are extremely simple in Go:

When the input is broken into tokens, a semicolon is automatically inserted into the token stream immediately after a line's final token if that token is

an identifier

an integer, floating-point, imaginary, rune, or string literal

one of the keywords break, continue, fallthrough, or return

one of the operators and punctuation ++, --, ), ], or }

By the way, Go's rules can be interpreted a lot easier like this:

A semicolon is placed if the line ends with:

a letter or number

a closing punctuation mark (aka ], ), }, and closing "/')

++ or --

I thought that JavaScript Semicolon rules were just as simple as Go's when I saw the function return undefined. After all, nothing appears after the return, so a semicolon was placed afterward. It is that simple right?

Well, I looked into it further.

So I made a few functions for adding 1 to an integer to see what JavaScript did.

function addOneNormal(x) {
    return x + 1
}

function addOneWeird(x) {
    return x
        +1
}

function addOneUndefined(x) {
    return
        x + 1
}

We know what addOneNormal and addOneUndefined end up being. addOneNormal adds one to x, and addOneUndefined hits the return and returns undefined. So what does addOneWeird do?

(sidenote: in Go, this is very simple, as return x ends with a letter, so a semicolon is placed. The next line, +1, results in a compile error as +1 is not being assigned to anything)

Well, some people would expect it to be the same as return x + 1;, although some people (like me) see it as return x; +1;, where the +1 is a 1 with a unary plus operator before it.

The result

So what was the result? addOneWeird(5) => 6. It added 1 successfully. That's weird... isn't it? That statement looked at the next line, even though a bare return didn't.

Unfortunately these rules cannot be made more consistent, as backward-compatibility is a requirement in JavaScript.

Anyway, could someone explain why the + operator ended up being interpreted as a binary plus rather than a unary plus in this case? If the addOneUndefined function resulted in undefined, It seems more logical foraddOneWeird to be interpreted as return x; +1;.

Go 2 Draft: Generics

dean — Fri, 14 Sep 2018 20:36:22 +0000

Go 2 is being drafted.

If you haven't heard, there will be a few major language changes coming to Go 2. The Go team has recently submitted a draft of these changes, and as part of a 3-part series, I've been going through each part, explaining it, and state my opinion on them! This is the second part of the series. Last time I did error values, and this time I will be discussing generics!

Remember that these are just drafts. They will most likely be added to the language, but there is still a chance that it won't. Also, remember that these drafts are not final, of course. The syntax will probably be a bit different from what it is right now.

These may not also be the only changes to the language, but these will probably be the only major changes.

So, Go is getting generics?

Well, maybe... remember that these are only drafts, and may not be implemented in this way, or even at all!

But before we discuss why we would want to have generics, we need to figure out what is wrong with not having them.

Interfaces

So, Go has a unique way of using interfaces. This allows us to not really need generics in many cases, as the values passed in don't need to explicitly implement the interface, they only need to have the required methods!

There are certain things that interfaces can't solve though. Particularly when it comes to channels, slices, maps, and other primitive types.

Why we need generics

Generalized functions like the following cannot be written without generics:

// Returns the keys from a map
func Keys(m map[K]V) []K

// Merges multiple channels into a single channel
func Merge(chans ...<-chan T) <-chan T

Those are just a couple examples. The only type-safe way to implement those would be to write a new function for each type you want it implemented for, which is the opposite of Go's goal of reducing code duplication.

Goals of Generics in Go

So, what does Go want out of generics?

Go wants to add a way to "abstract away needless type detail", such as the Keys and Merge functions in the previous section.
They do NOT want to target things such as special implementations, like their example of having a general Vector<T> and a special case of Vector<bool> which has bit-packing.
They do NOT want turing-complete templates (like C++) or type erasure (like Java), or weird cases that reveal how the generics system works internally. The generics implementation should fit smoothly into the language (looking at Java again with generic array types...).
Generic type information should be accessible in both the compile-time AND run-time.

Proposed syntax

Well, types in Go are always declared, and generic types should be no different. While they cannot be declared at the package keyword, they should be prefixed with type.

// A list implementation based on an internal slice.
type List(type T) []T

// A keys function which returns all keys of a map in a type-safe way.
func Keys(type K, V)(m map[K]V) []K

Hey, that's some good progress!

But let's say we want to have a IndexedSet(type T), not everything in Go is comparable (for instance, functions and maps are not currently comparable in Go), and the values must be comparable in order to check if it's already in the Set!

That's where we get contract. Contracts look a lot like functions, but instead of executing code, they specify restrictions on types.

Let's make a contract called Equal for our Set(type T).

contract Equal(t T) {
    t == t // assert that t must be able to use the `==` operator.
}

And now, we can implement our IndexedSet!

// T must satisfy the `Equal` contract. This is shorthand for (type T Equal(T))
type IndexedSet(type T Equal) []T

// Returns the index of x in our IndexedSet, or -1 if
// x is not in the set.
func (s IndexedSet(T)) Find(x T) int {
    for i, v := range s {
        // both `v` and `x` are type T, which satisfies our
        // `Equal` contract
        if v == x {
            return i
        }
    }
    return -1
}

Sweet, so now we can represent a set of values, and access each value by an index!

So we have shown that we can use generics on a data structure so that we can generalize it to work on almost any type. But data structures aren't the only thing that can have generics, remember that we have functions too!

Let's make a Sum function, which sums all of the values inside of a slice of any summable type.

contract Add(t T) {
    t + t
}

// (type T Add) is shorthand for (type T Add(T))
func Sum(type T Add)(x []T) T {
    var total T
    for _, v := range x {
        total += v
    }
    return total
}

Now, we have a function which sums up all of the values in a slice, and returns the result. Let's look at how to call it!

func main() {

        // =================================
        // Running `Sum` with ints
        // =================================

    var w []int
    wSum := Sum(int)(w)


        // =================================
    // Same as above, but with type inference
        // =================================

    var y []complex128
    ySum := Sum(y) // very familiar syntax!


        // =================================
    // Super clear as to how this works
        // =================================

        var foo func([]float32) float32
    foo = Sum(float32)

    var z []float32
    zSum := foo(z)


        // =================================
        // Compile error!
        // `Sum` may not be referenced without
        // defining its generic types.
        // =================================

    bar := Sum
}

Now that we've covered what they are pretty sure they want, let's talk about some stuff they aren't sure about.

Open Questions

So there are some issues about generics that the Go team is still unsure about.

1. Implied Constraints

// Maps must have the `==` operator defined on their keys.
// Then the question begs, should the following function compile properly?
// Or should we be required to make a contract for K?
func Keys(type K, V)(m map[K]V) []K

// alternatively...

contract Equal(t T) {
    t == t
}

// Now, we apply the Equal contract to K
func Keys(type K, V Equal(K))(m map[K]V) []K

2. Dual Implementation

Since a generic type's real type is available at compile time and run time, there is an issue when we want to have a generic method on a type. The issue is kinda hard to explain, so let's use an example:

// A set of values
type Set(type T Equal) ...

// Calls the function `f` on each value in Set(T),
// and then returns the results as a Set(U)
func (s Set(T)) Apply(type U)(f func(T) U) Set(U)

This is extremely useful, but it has consequences...

Consider that Set(int).Apply(int) evaluates to a separate function from Set(int).Apply(string).

What would the following code print?

func main() {
    v := reflect.ValueOf(Set(int){})

    fmt.Println(v.NumMethod())
}

Since Set(int).Apply(int) and Set(int).Apply(string) are separate, then v.NumMethod() would have to be, well, equivalent to the number of defined types (theoretically infinite).

On the other hand, the Apply method can still be written as a top-level function, but because of the restriction, it can't be a method on Set(T).

func Apply(type T, U Equal(T))(s Set(T), f func(T) U) Set(U)

3. Contract Bodies

Essentially, they want to know if contract bodies should be allowed to have any code, or if they should be restricted to a subset of go code.

For instance, should we allow the following?

contract C(t T) {
    if t == t {
        for i := 0; i < t; i++ {
            t = t + t
            t = t * t
        }
    }
}

(Side-note: the code in a contract never gets executed)

When really, the contract would be much more readable in the the following form:

contract C(t T) {
    t == t       // T is comparable
    0 < t        // T is relational to integers
    t = t + t    // T is assignable and has a + operator
    t = t * t    // T is assignable and has a * operator
}

My opinions

Semantics

I love the semantics. I really love the idea of f(int) evaluating to a function which uses an int as its generic type. It looks like a function call that returns another function, which is really nice.

Syntax

While the semantics behind f(int) is really nice, it comes with a huge drawback.

So. Many. Parentheses.

The current function declaration syntax would now be something similar to the following:

func (Receiver) FuncName(Generic Type List)(Argument List) (Return Value List)

Contracts

I don't like contracts. I feel like they could have done a better job, and I have already submitted feedback to their wiki about it. I got a response, which is cool. Might need to adjust my feedback though because

Overall

I really like Generics. Personally, I don't think Go really needs them, but I would like them. My only issue is that I feel like Go is settling a lot, which really isn't good.

Straight from the generics draft overview:

Polymorphism in Go must fit smoothly into the surrounding language, without awkward special cases and without exposing implementation details.

If that's what you want, then why do we have to deal with that awkward special case with not having generic functions with receivers?

From the contracts draft:

Why not use interfaces instead of contracts?
The interface method syntax is familiar. Writing contract bodies with x + x is ordinary Go syntax, but it is stylized, repetitive, and looks weird.

It is unclear how to represent operators using interface methods. We considered syntaxes like +(T, T) T, but that is confusing and repetitive. Also, a minor point, but ==(T, T) bool does not correspond to the == operator, which returns an untyped boolean value, not bool. We also considered writing simply + or ==. That seems to work but unfortunately the semicolon insertion rules require writing a semicolon after each operator at the end of a line. Using contracts that look like functions gives us a familiar syntax at the cost of some repetition. These are not fatal problems, but they are difficulties.

TL;DR: They couldn't figure out a good syntax to define operators for interfaces... is that really a good reason?

In the end, I feel like they settled quite a bit in order to get this proposal out, which just doesn't seem like Go. Not that this is a terrible proposal, or that I'd be sad to have this in the language, but I feel like it can be made a lot better.

Go 2 Draft: Error Values

dean — Mon, 03 Sep 2018 07:04:47 +0000

Go 2 is being drafted.

If you haven't heard, there will be a few major language changes coming to Go 2. The Go team has recently submitted a draft of these changes, and as part of a 3-part series, I've been going through each part, explaining it, and state my opinion on them! This is the second part of the series. Last time I did error handling, and this time I will be discussing error values!

These may not also be the only changes to the language, but these will probably be the only major changes.

I thought you already discussed errors!

Well, the first part was about error handling, and a new syntax which aides in handling errors. This part is about the improvements to the error interface and the errors package. There's some really good improvements that may be coming!

Okay, so what's wrong with the errors package?

There's two main issues: Inspecting errors, and Formatting errors.

Inspecting errors

Currently, there is no way to get context for an error without a custom implementation. So there's no provided way to provide context to an error you are returning, or to see if there was a cause for an error that you've received.

To fix this, the following may be defined in the errors package:

package errors

// Describes an error which wraps another error
type Wrapper interface {
    Unwrap() error
}

// Reports whether err or any of the errors in its chain is equal to target.
function Is(err, target error) bool

// Checks whether err or any of the errors in its chain is a value of type E.
// If so, it returns the discovered value of type E, with ok set to true.
// If not, it returns the zero value of type E, with ok set to false.
func As(type E)(err error) (e E, ok bool)

// NOTE this uses the syntax from the generics draft:
// https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md

Wrapper is an interface which describes an error which wraps another error. This forms a singly-linked list (or "chain") of errors, with the head as the most general error ("could not initialize config") and the tail as the root cause of the error ("file not found").

Is is the equivalent of the old if err == pack.ErrSomething, but it checks the entire chain of errors. This way, you could do if errors.Is(err, os.ErrNotExist) and it would tell you if at any point the error was caused by a file not existing.

As is the equivalent of the old smth, ok := err.(pack.ErrSomething), but it also checks the entire chain of errors. Notice that the As function uses generics, which I will cover in my next blog post.

Anyway, As's usage would look something along the lines of errne, ok := errors.As(*os.ErrNotExist)(err). I personally don't like the double-parentheses syntax for generics (to be honest, I don't like generics that much in general...)

If generics are not yet in the language, a good substitute would be

var errne *os.ErrNotExist
errors.AsValue(&errne, err)

Formatting errors

Also, when viewing printed errors, there is often very little information! Printing the error gives something like "can't read config" or "invalid path ", and no good way to get more detail.

To address this, the following may be added to the errors package:

type Formatter interface {
    Format(p Printer) (next error)
}

Formatter is an interface that describes an error which may be formatted. Printer is an interface which contains the functions Print and Printf, along with a Detail function. The Printer is provided package that is printing the error (usually fmt if printing via fmt.Print...()).

Then, fmt.Errorf() could then be improved to return an error implementing Formatter. It is also suggested that if the format string ends with : %v or : %s that it should return a Wrapper as well, thus improving the returned error even more.

Errors with custom formats could look like:

// Implements error and errors.Formatter
type ConfigError struct {
    File     string       // A human-readable name for this config
    Source   string       // The source file and line this error occurred on
    CausedBy error        // The error this was caused by
}

func (e *ConfigError) Init(file string, cause error) {
    e.File = file

    if _, file, line, ok := runtime.Caller(1); ok {
        e.Source = fmt.Sprintf("%s:%s", )
    } else {
        e.Source = "error source unavailable"
    }

    e.CausedBy = cause
}

func (e *ConfigError) Format(p errors.Printer) (next error) {
    p.Printf("error reading config %s", e.File)
    if p.Detail() { // if printing with `%+v` rather than just `%v`
        p.Printf("Perhaps incorrect file name or invalid format?")
        p.Print(e.Source)
    }
    return e.CausedBy
}

func (e *ConfigError) Error() string {
    return fmt.Sprint(e) // `fmt` will call the new Format function
}

And then when it's printed, it'll be something like...

fmt.Printf("%v", err)

error reading config MyConfig

===

fmt.Printf("%+v", err)

error reading config MyConfig:
    Perhaps incorrect file name or invalid format?
    github.com/deanveloper/config:1337
--- file does not exist

Nifty!

Putting these both together

Now, let's add one more function to our ConfigError in order to complete it. Let's add our Unwrap function so that we can use errors.Is and errors.As with it!

// Implements error, errors.Wrapper, and errors.Formatter
type ConfigError struct {
    File     string       // A human-readable name for this config
    Source   string       // The source file and line this error occurred on
    CausedBy error        // The error this was caused by
}

func (e *ConfigError) Init(file string, cause error) {
    e.File = file

    if _, file, line, ok := runtime.Caller(1); ok {
        e.Source = fmt.Sprintf("%s:%s", )
    } else {
        e.Source = "error source unavailable"
    }

    e.CausedBy = cause
}

func (e *ConfigError) Format(p errors.Printer) (next error) {
    p.Printf("error reading config %s", e.File)
    if p.Detail() { // if printing with `%+v` rather than just `%v`
        p.Printf("Perhaps incorrect file name or invalid format?")
        p.Print(e.Source)
    }
    return e.CausedBy
}

func (e *ConfigError) Unwrap() error {
    return e.CausedBy
}

func (e *ConfigError) Error() string {
    return fmt.Sprint(e) // `fmt` will call the new Format function
}

And now we can use this error (note, I am using syntax from the "error handling" Go 2 proposal. I have a blog post on that one already)


func main() {
    handle err {
        if cfgErr, ok := errors.As(*config.ConfigError)(err); ok {
            if errors.Is(err, os.ErrNotFound) {
                // Nice, clean output if we couldn't find the file
                log.Fatalln("Could not find config file %s", cfgErr.File)
            }
        }
        // Hmm, let's get a more verbose output.
        // Maybe a parsing error?
        log.Fatalln("%+v", err)
    }

    check config.Create("MyConfig")
}

My Suggestions

In terms of errors.Is, I'd really like a way to check multiple errors.

Perhaps instead of errors.Is(root, cause error) bool we could have errors.IsAny(root error, causes ...error) error (terrible name, but the semantics are what's important), which we could then use a switch err on. It's very frustrating to not have an efficient way to check multiple types without looping ourselves.

Also, I think this is adding a lot of complexity to error values. To me, one of the things special about Go was that errors were simple. I like the Wrapper idea, along with errors.Is and errors.As, but the Formatter I think is a bit much. Maybe add a type Detailer interface { Detail() string } to errors and let fmt take care of the actual formatting, as pretty much all Format functions will be pretty similar...

func (e *MyErr) Format(p errors.Printer) (next error) {
    p.Print(/* short error string */)
    if p.Detail() {
        p.Print(/* details */)
    }
    return /* caused by */
}

Wait a second, all the things I wrote placeholders for could just be functions!

If Go just had an errors.Detailer interface, then our ConfigError would look like...

// Implements error, errors.Wrapper, and errors.Detailer
type ConfigError struct {
    File     string       // A human-readable name for this config
    Source   string       // The source file and line this error occurred on
    CausedBy error        // The error this was caused by
}

func (e *ConfigError) Init(file string, cause error) {
    e.File = file

    if _, file, line, ok := runtime.Caller(1); ok {
        e.Source = fmt.Sprintf("%s:%s", )
    } else {
        e.Source = "error source unavailable"
    }

    e.CausedBy = cause
}

func (e *ConfigError) Detail() string {
    return "Perhaps incorrect file name or invalid format?\n" + e.Source
}

func (e *ConfigError) Unwrap() error {
    return e.CausedBy
}

func (e *ConfigError) Error() string {
    return "error reading config " + e.File
}

And then fmt would be able to print each error in the chain.

All in all...

I think these are welcome changes, and my changes are a bit nitpicky. I'm fine with the Format function, even though I think that just adding a Detailer interface would be better. I will be making that as a suggestion to the Go team.

Go 2 Draft: Error Handling

dean — Wed, 29 Aug 2018 16:14:31 +0000

Go 2 is being drafted.

If you haven't heard, there will be a few major language changes coming to Go 2. The Go team has recently submitted a draft of these changes, and as part of a 3-part series, I want to go through each part, explain it, and state my opinion on them! This is the first part of the series. After Error Handling, we will talk about Error Values, and then we can get to the big kahuna... Generics!

These may not also be the only changes to the language, but these will probably be the only major changes.

So, what's the big deal with Error Handling?

Currently, if you want to check an error, you need to do if err != nil { .... The construct is nice, but when you're working with any kind of I/O, your code starts to look something like this... (using the example from the draft)

// From the draft
func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

We had to write fmt.Errorf("copy %s %s: %v", src, dst, err) three times, and w.Close() and os.Remove(dst) twice... and this is a pretty small function. So how can we fix this?

Introducing: `check` and `handle`!

check and handle will be new keywords, and you can kind-of think of them as a panic-defer-recover, but for use within a single function.

The format for check is check <expression>, where <expression> is either an error or a function call, where the last return value is an error. These are also expressions themselves, if the error is nil, then it returns all of the other arguments (ex: f := check os.Open(fileName)).

If the error value is not nil, then check will jump to the handle blocks. To see what I mean, let's look at a simple example.

Go 1:

type Parsed struct { ... }

func ParseJson(name string) (Parsed, error) {

    // Open the file
    f, err := os.Open(name)
    if err != nil {
        return fmt.Errorf("parsing json: %s %v", name, err)
    }
    defer f.Close()

    // Parse json into p
    var p Parsed
    err = json.NewDecoder(f).Decode(&p)
    if err != nil {
        return fmt.Errorf("parsing json: %s %v", name, err)
    }

    return p
}

Okay, so let's simplify this with check and handle!

type Parsed struct { ... }

func ParseJson(name string) (Parsed, error) {
    handle err {
        return fmt.Errorf("parsing json: %s %v", name, err)
    }

    // Open the file
    f := check os.Open(name)
    defer f.Close()

    // Parse json into p
    var p Parsed
    check json.NewDecoder(f).Decode(&p)

    return p
}

How about that? We've trimmed down a lot of our boilerplate!

But what about that example from earlier... It had a lot more error handling! We had to clean up our files if they didn't copy properly... So how do we handle that? Let's take a look at the draft!

// From the draft
func CopyFile(src, dst string) error {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    handle err {
        w.Close()
        os.Remove(dst) // (only if a check fails)
    }

    check io.Copy(w, r)
    check w.Close()
    return nil
}

If you have multiple handle blocks, they will be executed from the bottom-most one to the top-most. This allows you to have more clean-up when an error occurs as a function flows.

Of course, this construct also works in functions which do not return errors, as noted in the draft!

// From the draft
func main() {
    handle err {
        log.Fatal(err)
    }

    hex := check ioutil.ReadAll(os.Stdin)
    data := check parseHexdump(string(hex))
    os.Stdout.Write(data)
}

What do I think?

I think this is a really good change! My only real issue with it is that now check and handle become keywords, which are both variable names that aren't uncommon. I used to like the idea of collect (as illustrated in my previous blog post), although I think my view on collect changed after I wrote it. It just seemed like try-catch and didn't have a very intuitive syntax.

check-handle is still quite a bit like try-catch, although it is much more powerful. It allows more clean-up as the function progresses without adding more indentation. Every error check is also explicit, so you know where the exit points of the function are at a very quick glance.

The draft also contains a lot of details about what inspired this decision! They took a lot of inspiration from both Rust and Swift, which both have errors that must be checked explicitly (unlike Java, C++, Python, etc. which have implicit unwrapping of the stack).

This change also works really well with the new error idioms... but that's for the next post in the series!

My Favorite Go 2 Proposals

dean — Tue, 14 Aug 2018 13:28:04 +0000

As some gophers may have heard, Go 2 may be coming soon! It's still in the planning phase though, and the Go team is still working on what features should and shouldn't be in the language.

One of my favorite things about Go is its lack of syntactic sugar, it really feels like I'm problem solving, rather than writing tons of gibberish. The Go team doesn't want to have yet another feature-bloated language, which is why I really enjoy it.

Anyway, there's over 7 pages of Go 2 proposals, and I've been searching through them, so I thought I'd list some of my favorites.

Interface Literals #25860

This one is a bit hard to understand at first, but once you understand it, it becomes much simpler to read.

So let's say you want to sort a slice of strings... This is now simplified with sort.Strings and sort.Slice, but for the sake of example, let's pretend sort.Sort is all we're able to use. This function takes an interface (called sort.Interface) which has 3 methods defined, so in order to use it, you must make sure those 3 methods are defined for your type:

But with this proposal, we can make it look like this instead!

Essentially what we have done is to use an interface literal instead of needing to make a new type! This means that the code that you use to sort can now be put where you actually do your sorting.

Add `collect` statements to the language #25626

This one is really nice, actually. They want to add a statement called collect to the language. It's hard to explain with words (in my opinion), so let's do it with an example!

Here is some valid Go code, with some error handling of course:

And as my Computer Science professor said, if you're repeating code, you're doing it wrong! But in Go, there's no good way to really handle the err != nil repetition problem here, so how could we help this? The collect statement helps fix this issue!

So let's have the same code, but with the collect statement.

So what does this do? Well the collect err indicates that we are going to collect into a variable err. Then, each time we assign to _!, it assigns that value to err, and checks if err != nil. If the assigned value is not nil, it exits the collect statement, and then the error handling can be done afterward.

My main issue with the proposal is that the syntax is a bit confusing (I personally don't like the _! syntax, I made a suggestion to use err! instead, which makes it a bit more clear).

Fix casing issues #1187

This one is quite a bit simpler than the last one. The os package has a lot of confusing casing, it's not always clear if the correct function call is os.Chdir or os.ChDir, or if it should be os.Tempdir or os.TempDir. I'm hoping the proposal to fix these casing issues gets accepted!

There are TONS of Go 2 proposals. Go has some really strong views on what should/shouldn't be in the language, the Go creators definitely don't want to make another C#, JavaScript, or other feature-bloated language. While I really like the idea of a collect statement, I'm not sure if the Go creators would like it, as it may be seen as an unnecessary feature (which I understand).

What do you think about the proposals? Do you have any you want to add? Let me know, Go is one of my favorite languages out there, and I'd love to have more insight as to what its future may look like!

The Gopher is NOT dead!

dean — Thu, 03 May 2018 02:07:19 +0000

So the new Golang logo has sparked a lot of controversy. People love the Gopher. How couldn't you love him?

The new logo has been concerning a lot of people. They don't want the Gopher to be replaced. But what if I told you... he won't!

In fact, according to the very blog post that announced the new logo, we see this:

"Rest easy, our beloved Gopher Mascot remains at the center of our brand."

Remember that there is a difference between a logo and a mascot. In fact, you might not have even SEEN the old logo:

I know I've only seen it in one place... it appears in the Windows Installation Wizard for the language.

So sure, the new logo is really generic, but luckily the gopher will live on.

I hope you enjoyed the blog post, and all of the Gopher images :)

Let's Have a Talk About App Permissions

dean — Wed, 25 Oct 2017 18:04:17 +0000

Not long ago, I saw this tweet. It got me thinking, do people really not know the purpose in App permissions? I've always been careful with app permissions, I don't want Facebook using my microphone in the background while I have the app open.

The Problem

After all, we give apps permissions all the time. It makes sense to give Twitter permission to my photos, I wanted to tweet out the awesome selfie I took! But now Twitter has access to all of my photos, not just the one I wanted to share.

Just as a bit of a scare, let's go over everything that an iOS app can do when it gets certain permissions.

Camera Access
- Access to record you or what you're looking at whenever the app is running
- Access to upload taken pictures wherever they want without your knowledge
- Run scans on said images with facial recognition
- Figure out your current mood based on facial recognition
Photo Access
- Access to all of your photos
- Access to upload every one of your photos/videos
- Access to scan photos with facial recognition
- Access to photo metadata, including where the photo was taken
- Get basic information such as where the user lives through data analysis with photo location

You probably get the point by now, but here's a few more for fun. Feel free to skip these!

Microphone Access
- Access to your microphone while the app is running
- Record any conversations you have while the app is running
- Run speech-to-text software on conversations you have
Location Access
- Access your current location
- Access to tell if you are home or not (after some data analysis)
- Figure out where you work or go to school
- Figure out your approximate speed
- Depending on the level of access, all of these even when the app is not in use
Twitter/Facebook Access
- Access to the name of your Facebook/Twitter accounts
- Access to gather information from your Facebook/Twitter accounts (depending on Facebook/Twitter privacy settings)
- Your name
- Your mother's name
- Your mother's parent's last name (aka your mother's maiden name)
- Your SO's name
- Your job, education, etc
- Your friends' names
- Your preferences
- Your friends' preferences
- Your photos/videos
Contact Access
- Access to view all of your contacts
- Access the contact information of your contacts
- The ability to contact your contacts
- Collect information on your friends based on your (and other people who have your friends as contacts) preferences
HomeKit Access
- Access to turn on/off lights
- Access to turning heat up/down
- Access to unlock your front door
- This is just all-around bad
Accelerometer (gyro) Access
- All apps can use this without asking the user
- Even web apps can use this without asking
- Through data analysis with the accelerometer, the app can tell vaguely as to what the user is doing.

Finding a Solution

So now comes the question, how do we limit app's access to such services, without limiting what we want them to do? After all, it's really convenient to be able to take pictures inside of Facebook and instantly share them, I just don't want them taking pictures whenever they want.

Use built-in apps which do not have permissions associated with them
- This is convenient for the user as they wouldn't need to answer yet another pop-up.
- Allow access for a built-in camera app which only takes pictures when the user wants to.
- Allow access to select a single contact (or group of contacts) through a built-in app.
- Similar things for stuff like photos, microphone, etc.
- Perhaps even let the app provide a custom format or color scheme for the camera/photos/whatever app.
Temporary permissions
- Allow access for some amount of time, rather than once-and-forever.
- Could also be for the current session (revoke permission when the user exits the app).
- ie: Allow Google Maps to use my location (even in the background) for a few minutes/hours.
- Give access for the app to request more time from the user if needed.
Warn the user
- Tell the user what the app can do with the permissions it wants.
- Of course don't go into the detail like I did earlier, just something along the lines of "can take photos whenever it wants while using the app" (with better wording of course).

Conclusion

Apps can do more than what the user wants to do with given permissions. While you might want to just take a picture for your new Facebook profile picture, Facebook now has permissions to take pictures whenever it wants, as long as the app is open. Ever used Facebook on the toilet?

(This post was originally on my personal blog, check it out!)

Why Password Length is so Important

dean — Sun, 17 Sep 2017 04:33:06 +0000

What if I told you how to make a password that is 400,000 times more secure, and easier to remember? Let me introduce you to passphrases. You have probably heard this before from countless people. XKCD talks about passphrases and how they are much better than passwords. It explains why passphrases are better, but doesn't really get into how simple the math really is. We won't talk anything about entropy here, since that's useless anyway if you know the math. We will be discussing brute-forcing passwords and dictionary attacks, and making some quick scripts to figure out just how secure passwords vs passphrases are.

Short, Complex Passwords

So, let's say you have a password, around 12 characters. It has numbers and symbols. This means, assuming you're limited to the characters on a keyboard, 26 (lowercase) + 26 (uppercase) + 10 (numbers) + 10 (numbers + shift) + 10 (extra symbols) + 10 (extra symbols + shift). This brings us to 92 possible characters, and let's round up to 100 to be generous, and to make the math easy.

For a single character password, there are 100 possibilities. Two characters makes it 10000 + 100 = 10100. Many of us are programmers here, so let's write a quick python program to describe the number of possibilities that a password of length length or less can have.

>>> def password(length):
...   if length < 0:
...     return 0
...   return 100**length + password(length-1)

And just to test it out (note, the program also allows for an empty password, so it is 1 larger)

>>> password(1)
101
>>> password(2)
10101

So how about a 12 character password? Let's try putting that into our function.

>>> password(12)
1010101010101010101010101

That's a huge number! That's a bit over a billion-billion-millions. But let's try taking a bit of a different approach to this...

Long, Simple Passphrases

Now instead of a password, let's talk about a passphrase. Passphrases are much longer and simpler, and harder to guess than passwords are. Each passphrase is made up of words, of course. In order to keep it easy to remember, we won't even include any numbers or symbols in it. Just the 26 letters, the spacebar, hyphen, and underscore. That brings us to a total of 29 characters.

Let's make a new python function to describe the same pattern, but for passphrases.

>>> def passphrase(length):
...   if length < 0:
...     return 0
...   return 29**length + passphrase(length-1)

And give it a couple test values.

>>> passphrase(1)
30
>>> passphrase(2)
942

So just how hard are passphrases to brute-force? Well, let's say our passphrase is "what is the length of the average sentence", which is 42 characters. Let's put that into our function.

>>> passphrase(42)
27287005492884718602602534825004439917772077566939113764846271

That number is very, very large. According to python, around 2.7e+37 times larger than the number of possible 12-character passwords! On the other hand, this does assume that they are cracking the password via brute-force, trying random letters out until a correct sequence comes up. Instead of a brute force, let's try looking at a dictionary attack.

Dictionary attack try words at a time instead of letters. This means that they are much better at cracking a passphrase. The rarest words in that passphrase are "length" (ranked 1151), and "sentence" (ranked 4675) (source). So, let's say our attacker is looking for the 5000 most common English words.

So, of course, let's make a function to describe this!

>>> def passphrase_dictionary(words):
...   if words < 0:
...     return 0
...   return 5000**words + passphrase_dictionary(words-1)

And test it

>>> passphrase_dictionary(1)
5001
>>> passphrase_dictionary(2)
25005001

And finally, let's take a look at how many possibilities an 8-or-less word passphrase would have.

>>> passphrase_dictionary(8)
390703140628125625125025005001

As you can tell, it's quite a bit less than brute-forcing, as expected. But comparing it to the original value...

>>> passphrase_dictionary(8) / password(12)
386796.10922184435

Our passphrase is much easier to remember, and nearly 400,000 times more secure than our 12-character password. Also, choosing less common words in your passphrase drastically increases the security of the password! The words in the passphrase that I used were all fairly common, although it is still more secure than a randomly-generated 12 character password.

Conclusion

Passphrases are easier to remember than passwords, while also being a lot more secure. They take a bit longer to type, sure, but you are also typing in actual words and not needing to constantly reach for that shift key. The (very) simple, easy to remember passphrase used in this example was 400,000 times more secure than a randomly-generated 12 character password. The only thing that keeps us from using passphrases everywhere are character limits, which are sometimes imposed on websites, in which case you may need to use a plain-old password. But if there's no limit, go for a nice, long passphrase.

Date Formats

dean — Sun, 18 Jun 2017 16:12:25 +0000

Date Formats

In the real world, date formats come in many shapes. The two major ones are usually MM-DD-YYYY and DD-MM-YYYY. (ie 06-18-2017 and 18-06-2017). But the trouble with these date formats is that they don't sort well alphanumerically.

DD-MM-YYYY

This is often the most logical date format to use, as it puts the numbers in order of significance. Days are short, years are long. But lets take a list of several dates and sort them alphanumerically in this format. Here's what it would look like:

Well, that's definitely not sorted very well. We can see this just in the first two dates, where 05-07-2017 is coming before 18-06-2017, despite 18-06-2017 coming first in the calendar. This is because the day is listed before the month, so it has more significance in an alphanumerical sorting algorithm.

MM-DD-YYYY

This is often the common date format to use in the United States, as to why, I am not sure. But if we take a look at what happens when they get sorted alphanumerically, it might turn out closer to what we would expect.

This seems like it sorted much better than before, although there is still a small problem. This is showing that 12-30-1917 is the last date in the list, despite it being first of all of them in the calendar. To fix this issue, we need to use a date format that may seem irregular.

YYYY-MM-DD

This format is pretty uncommon, although it is the most logical of the three. The year is the most significant number, so it comes first in the format. What happens when this format is used when sorting?

Interesting, they are sorted by when they come in the calendar now! How did this happen? It's because the most significant number comes first, so it has a higher priority in an alphanumerical sorting algorithm.

Why not use a Custom Sorting Algorithm?

There isn't always control over what sorting algorithm is used. Sometimes it is handled by the browser, by a library, or by a file system. Media files often take the default name of the date they were created. If the file is named with the YYYY-MM-DD format, then it will sort well in the file system, with the oldest images appearing first, and the newest ones appearing last. In a sortable table, some browsers or libraries may not give control as to how dates are sorted, and always sort it alphanumerically.

The moral of this really isn't about date formats at all. It's a reminder that there isn't always control over what happens to everything that we write. We can't always expect everything to happen the way we want it to, and we might need to change our code to make sure that it conforms with other libraries. Sorting dates is probably the easiest example, although if anyone else has other examples that they would like to contribute, I'd love to hear!

The Problem with Interfaces, and how Go Fixed it

dean — Sat, 13 May 2017 03:44:22 +0000

Interfaces are great

They're honestly brilliant. Interfaces allow for simple, elegant programming. Let's use Java to get a quick idea of how to use interfaces.

package mypackage;

public interface Edible {
  public void eat();
}

Now, a Burger class to implement Edible.

package mypackage;

public class Burger implements Edible {
  public void eat() {
    System.out.println("Burgers, yum!");
  }
}

This means that we can use our Burger class wherever we see Edible, such as in method arguments!

The problem with interfaces

But let's say that we are using a library, and that library has a class called Salad. Here's what Salad looks like:

package theirpackage;

public class Salad {
  public void eat() {
    System.out.println("I'm being healthy!")
  }
}

So Salad has an eat() method, but because the other library doesn't even know about Edible interface exists, it obviously can't implement it. This problem has definitely been encountered before, so let's talk about how Go has fixed it.

How Go fixes interfaces

With how Go interfaces work, you don't need to declare an interface implementation. If you implement the proper methods, you implement the interface. This is very prominent in Go, and is a key feature. Let's use our previous example.

First, let's remake our Edible interface.

package mypackage

type Edible interface {
  Eat()
}

Now, let's make a Burger struct that implements Edible.

package mypackage

type Burger struct {}

// How to define a method in Go
func (b Burger) Eat() {
  fmt.Println("Burgers, yum!")
}

Notice that we never acknowledged Edible anywhere while we made the Burger struct. This is because any type that has an Eat() method associated with it is considered Edible. This means that even types from other libraries can be Edible, as long as they have an Eat() method!

This means that even this Salad struct from a different package is Edible.

package theirpackage

type Salad struct {}

func (s Salad) Eat() {
  fmt.Println("I'm being healthy!")
}

This shows just how awesome Golang is. I highly recommend watching their video, A Tour of Go, which shows all of the brilliant features that Go has to offer.

EDIT: I really like the discussion on this post! One of the key things that I didn't mention here is that interfaces in Go should be used to describe simple patterns. Here is a clip from A Tour of Go that should hopefully describe how interfaces in Go should be used compared to how they're used in OOP.

Hi, I'm Dean Bassett

dean — Sun, 12 Mar 2017 19:30:37 +0000

I have been coding for 5 years.

You can find me on Twitter as @Deanveloper

I live near Minneapolis, but I am currently going to college at Michigan Tech, which is way up in the Upper Peninsula.

I don't work for anyone as of yet, although Summer is coming up!

I mostly program in Kotlin and Java, although I also dabble in web development.

I am currently learning more about Golang, it seems like an extremely nice language.

Feel free to introduce yourselves to me, this seems like a really nice community! ðŸ˜„

public void test() {
    System.out.println("ok");
}

DEV Community: dean

Semicolon Rules in JavaScript are weird...

Well, I looked into it further.

The result

Go 2 Draft: Generics

Go 2 is being drafted.

So, Go is getting generics?

Interfaces

Why we need generics

Goals of Generics in Go

Proposed syntax

Open Questions

1. Implied Constraints

2. Dual Implementation

3. Contract Bodies

My opinions

Semantics

Syntax

Contracts

Overall

Go 2 Draft: Error Values

Go 2 is being drafted.

I thought you already discussed errors!

Okay, so what's wrong with the errors package?

Inspecting errors

Formatting errors

Putting these both together

My Suggestions

All in all...

Go 2 Draft: Error Handling

Go 2 is being drafted.

So, what's the big deal with Error Handling?

Introducing: check and handle!

What do I think?

My Favorite Go 2 Proposals

Interface Literals #25860

Add collect statements to the language #25626

Fix casing issues #1187

The Gopher is NOT dead!

Let's Have a Talk About App Permissions

The Problem

Finding a Solution

Conclusion

Why Password Length is so Important

Short, Complex Passwords

Long, Simple Passphrases

Conclusion

Date Formats

Date Formats

DD-MM-YYYY

MM-DD-YYYY

YYYY-MM-DD

Why not use a Custom Sorting Algorithm?

The Problem with Interfaces, and how Go Fixed it

Interfaces are great

The problem with interfaces

How Go fixes interfaces

Hi, I'm Dean Bassett

Introducing: `check` and `handle`!

Add `collect` statements to the language #25626