It brought one of my favorite parts about writing numbers in languages such as Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.

While I too like the change, there can be a user cost. For example, it makes using grep across a project slightly more annoying. Much like the flexible identifier rules in nim, it feels great but using common tools suddenly needs more thought.

Would it make sense to have an editor display a number in a more readable fashion while the source code itself has the grep-able version? I'm not a fan of ligatures myself but that is also done purely as presentation logic.

You guys are going to make me cry again that C++ rejected using underscores in favor of... single-quote.

O_o

Only someone with no typographic taste whatsoever would prefer 10_000 over 10'000, so personally I'll rather cry about only C++ getting this right.

Not only C++. Rebol and Red also get this right. And they also allow comma instead of a dot as a decimal separator, oh the horror!

> From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.

1e7

> 1e7

Is a float literal.

Not in Go. Number literals don't have a type until they're assigned to a variable or used in a place that implies a type (e.g. a function argument). For example, the following is valid:

  var u uint32 = 10000000000.0 / 100000

even though 10000000000 overflows uint32 and it's also written like a floating-point literal.

> Not in Go.

Yes in go. `var u = 1e7` gives a float. That means 1e7 is a float literal. You can coerce it to an integer by explicitly typing the target, but it's still a float literal.

`1e7` is an untyped numeric constant with a default type of float64.

https://blog.golang.org/constants

https://golang.org/ref/spec#Constants

Mysterious hacker news downvoting! This my preferred way of writing numbers with lots of 0s as well.

But underscores also work for numbers that don't have lot of zeros. Compare:

    12_345_678
    1.2345678e7

good point.

Kind of realising how much of my daily work could use bytes as the main numeric type

Underscores are nice.

10 * 1000 * 1000 worked pretty well too.

Compile-time integer exponentiation in Go would be neat, e.g. 5 ＊ (1000＊＊4).

I know we have scientific-notation integer literals, but it's not the same thing, especially when trying to calculate e.g. Mebibytes.

In go you can use scientific notation for integers

   var x int = 1e9

You say that, but I find that a lot harder to read (and using `e` notation) than just the number - and readability / clarity is more important than cleverness, especially in Go.

10_000_000 can be read, 5 ＊ (1000＊＊4) and 1e7 has to be decoded. By me anyway, I'm just an average developer that never did well in maths - and you have to write code for the average developer, not for yourself and not for the top 10% smartest people.

Not sure about go, but you can do this in C as a compile-time constant:

  #define foo 1.34E8

Maybe go would benefit from a pre-processor? Though it can be somewhat byzantine in C (and result in very unpredictable final source, if abused), it's very helpful to have a complete functional language available for code transformation. It might help go in some cases, too.

btw, if you have code that currently casts to uint for shifts, you can rewrite it with gofmt:

    gofmt -r 'y << uint(x) -> y << x'

(You'll have to run this multiple times for uint32, uint64 etc. if you shift with those types.)

I was really looking forward to this as well because, at least with `0b`, I get to keep more of my Python muscle memory.

This is immensely reflective of the type of problems you tackle.

Hmm... do you really hardcode big numbers that often?

You mean, do I work with binary constants? Yes.

I think the question was more around how often is 0b1100 useful outside of a block of consts at the beginning? Surely you're not typing out long constants manually that often?

He might be reading them more often, though...