News for hackers. Stuff that matters.
Re:Go 2, here we come by usrusr on Thursday November 29, 2018 @04:46PM (#18564376)
It's like building in special handling for a string type, exactly one instead of a catalog of library options.

I'd say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of "minimalism" would be providing tools to allow libraries to define what other languages can only support as special builtins. C++ and Scala went down that road, they minimize builtins by empowering libraries to replace them. That's also a form of minimalism, but not the one chosen by Go.

Tangent: now I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type it inherited from Java or if just reimplements those syntax extras in the standard library using implicits.

Re:Go 2, here we come by dtech on Friday November 30, 2018 @06:51AM (#18568418)
> I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type

Scala uses Java's String exactly, but does define a few extra methods using its extension method functionality (called implicit class in Scala)

Templates like s"This is a string with a $variable", are part of the language, but `s` is a stdlib feature.

   xxx"First $a $b Second"
will be translated by the compiler to

   new StringContext(Array("First ", " ", " Second")).xxx(a, b)
The standard library defines `StringContext.s`, but there's no restriction. Several SQL Libraries for example define `StringContext.sql`, to allow you to safely and type-checked embed SQL queries directly inside the code.