321–330 of 534 posts
Earlier quoted context omitted.
Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."
It's a bit Pascale-y, which may be a turn off to some. I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?
Haskell, I feel, needs no explanation.
Earlier quoted context omitted.
I get you point. I'd probably go float/double precision for that task.
Then you can lose precision that you might actually need - a bug that's even more annoying to track down than straight overflow.
Earlier quoted context omitted.
> they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.
I don't understand what you mean, sorry
Earlier quoted context omitted.
Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT then I'll use a math library of some sort.
There have been 1,543,530,695,158 milliseconds since epoch.
I typically wouldn't be passing around milliseconds since epoch as an raw number, but then that's C#, I guess you might do that in other languages for performance or out of necessity.
Earlier quoted context omitted.
I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.
Because you want to represent errors. For example a find() function that returns the index of some element: you want to return -1 when the element doesn't exist.
Earlier quoted context omitted.
Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? As a long-time Racket and Scheme user, I'd say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithme…
> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.
It's generally nice when you can do simple things with the language's built-in standard library. I tend to prefer languages with more powerful standard libraries because it means that you can more easily move across codebases since they'll all be the same. If commonly used data types like rationals, hashes, maps, strings, etc., aren't defined in the stdlib, then there'll be any number of different libraries to use them, and you'll have to potentially re-learn a lot of different unnecessary things when working on different codebases.
I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.
int (*f)(int x);
var f func(int x) int
var f func(int x)
In C++ it's also a bit inconsistent,
int f1(int x) { return x + 5; }
std::function f2;
auto f3 = [](int x) -> int { return x + 5 };
int x = 3;
auto x = 3;
var x int = 3
var x = 3
In fact I think the way C/C++/C#/Java do it, with the type at the beginning, is actually somewhat rare.
Earlier quoted context omitted.
Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt). It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.
I can get used to something and still dislike it.. with Go it's mostly the bracket style, or put differently, the inability to turn off automatic addition of semicolons before parsing. I'd actually rather "have to" put semicolons manually, but no, I have to suffer so others don't have to put an additional line into their style guide.
Earlier quoted context omitted.
Because you want to represent errors. For example a find() function that returns the index of some element: you want to return -1 when the element doesn't exist.
Shouldn't idiomatic go return an error instead? Magic number ranges for errors always seemed a bit old-fashioned.
Earlier quoted context omitted.
It's a bit Pascale-y, which may be a turn off to some. I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?
Rust is probably the least weird of those I listed. I find its syntax "too busy", similar to C++. Haskell, I feel, needs no explanation.