Hacker News new | past | comments | ask | show | jobs | submit login

>Usually I need a specific, and waste time making a genetic

Often times in large code bases you'll have short mathematical expressions used in multiple places.

     fn error<T:num>(real:<T>, test:<T>)-> <T>
     {
          return ((real-test)/real)*100;
     }
Now instead of typing the same thing over and over and over again I call a function (literally what they're designed for), and it works for floats, doubles, AND ints.

>no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function.

Overloading is normally done a per-data type basis to avoid exactly what you state. But yes, it is a big mathematical/scientific point. It can really simplify your life working with some data structures.

>Yes, nil exists. Big deal.

No that's the problem. Its existence is a bug. And has no use existing, as you said yourself its rare, you never see it, you hardly use it... So why even include it?!

>[...] immutable

Immutability is more of a programmer hack, not a language hack. Rust and Haskell make me ask myself 'will I actually change this value' when declaring a new variable. And addes an extra mental step and self check of your own code when programming.




Re nil:

He said he rarely sees code fail because of nil dereferences, not that he rarely sees it. "if err != nil {" is probably the most commonly written line of Go code by a large margin. Nil fits well with the language's zero defaultness of values. It may not be theoretically sound, but in practice it fits within Go very well and rarely causes the problems it tends to in other languages with null.


Yep. A zero value is very handy. Not having it would make a lot of code needlessly complex just to avoid the boogeyman of nil/null.


Null boogeyman? It's inventor doesn't seem to think so:

http://www.infoq.com/presentations/Null-References-The-Billi...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: