www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I want off Mr. Golang's Wild Ride

reply Walter Bright <newshound2 digitalmars.com> writes:
https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

This is a very worthwhile read. There's a lot for us to learn here.
Feb 28
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 28, 2020 at 02:50:05PM -0800, Walter Bright via Digitalmars-d wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/
 
 This is a very worthwhile read. There's a lot for us to learn here.
The most glaring point to me is Phobos' ubiquitous use of `string` everywhere for filenames. The fact that strings are assumed to be valid UTF-8 will almost certainly land us in the same complaints as the author had about Go's handling of pathnames. Changing that would be a major code breaker, though. So I'm not sure if we should even attempt to! T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Feb 28
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/28/2020 8:54 PM, H. S. Teoh wrote:
 The most glaring point to me is Phobos' ubiquitous use of `string`
 everywhere for filenames. The fact that strings are assumed to be valid
 UTF-8 will almost certainly land us in the same complaints as the author
 had about Go's handling of pathnames.

 Changing that would be a major code breaker, though. So I'm not sure if
 we should even attempt to!
This is an interesting problem. I don't know about Rust, but in D a string's contents are not guaranteed to contain valid UTF-8. For the string algorithms I've worked on, I always made them to be tolerant of bad UTF, for the simple reason that bad UTF is everywhere and having the program aggressively halt on it is overkill. The only time validity is checked is when decoding is attempted, or *cough* autodecode *cough* is running, which I'd circumvent. So I expect we are in good shape there. Things we must specifically review, however, are: 1. the way stat is dealt with 2. the way file extensions are determined 3. the \ vs / and more generally, follow the principles outlined in the article.
Feb 28
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 29.02.2020 um 06:50 schrieb Walter Bright:
 On 2/28/2020 8:54 PM, H. S. Teoh wrote:
 The most glaring point to me is Phobos' ubiquitous use of `string`
 everywhere for filenames. The fact that strings are assumed to be valid
 UTF-8 will almost certainly land us in the same complaints as the author
 had about Go's handling of pathnames.

 Changing that would be a major code breaker, though. So I'm not sure if
 we should even attempt to!
This is an interesting problem. I don't know about Rust, but in D a string's contents are not guaranteed to contain valid UTF-8. For the string algorithms I've worked on, I always made them to be tolerant of bad UTF, for the simple reason that bad UTF is everywhere and having the program aggressively halt on it is overkill. The only time validity is checked is when decoding is attempted, or *cough* autodecode *cough* is running, which I'd circumvent. So I expect we are in good shape there. Things we must specifically review, however, are: 1. the way stat is dealt with 2. the way file extensions are determined 3. the \ vs / and more generally, follow the principles outlined in the article.
This is why there are UnixPath, WindowsPath and InetPath types defined in vibe.d (with NativePath being an alias to WindowsPath or PosixPath). Typing everything as `string` is a recipe for disaster, unless the library semantics happen to exactly match the handled path type. https://vibed.org/api/vibe.core.path/ I'm still not happy with the way absolute paths are handled in terms of path segments in the current design, I just haven't found a way to improve it without breaking existing code in strange ways. (OT: Can you please quickly check your inbox/spam folder? I've send a mail a few days ago, as well as a copy today, regarding code.dlang.org)
Feb 28
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Saturday, 29 February 2020 at 04:54:22 UTC, H. S. Teoh wrote:
 The most glaring point to me is Phobos' ubiquitous use of 
 `string` everywhere for filenames. The fact that strings are 
 assumed to be valid UTF-8 will almost certainly land us in the 
 same complaints as the author had about Go's handling of 
 pathnames.

 Changing that would be a major code breaker, though. So I'm not 
 sure if we should even attempt to!


 T
In Rust String::from does checks for valid UTF-8 every time, the question if the compiler can optimize away the check if it is known to come from a correct source. I rather have a special constructor or method for creating a string from an unknown source that isn't necessarily proven to be correct UTF-8. I don't think that D should add a check for every constructed string at this point. Also, if the OS service API is done correctly, it should do the check so that is it a valid path/filename. Rust has done mistake with the naming, str and string are too close and can be confused. The article is kind annoying because it is just about Go=great evil, Rust=god sent. Also Rust is just as strict when it comes to formatting as Go. If you depart from the standard code formatting complaining a lot. Cargo is just as annoying and will complain as well.
Feb 29
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Saturday, 29 February 2020 at 04:54:22 UTC, H. S. Teoh wrote:
 On Fri, Feb 28, 2020 at 02:50:05PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/
 
 This is a very worthwhile read. There's a lot for us to learn 
 here.
The most glaring point to me is Phobos' ubiquitous use of `string` everywhere for filenames. The fact that strings are assumed to be valid UTF-8 will almost certainly land us in the same complaints as the author had about Go's handling of pathnames. Changing that would be a major code breaker, though. So I'm not sure if we should even attempt to! T
A very similar complaint can be found in a recent blog post [1] about Mercurial's transition from Python2 to Python3: "Perhaps my least favorite feature of Python 3 is its insistence that the world is Unicode. In Python 2, the default string type was backed by bytes. In Python 3, the default string type is backed by Unicode code points. As part of that transition, large parts of the standard library now operate in the Unicode space instead of the domain of bytes. I understand why Python does this: they want strings to be Unicode and don't want users to have to spend that much energy thinking about when to use str versus bytes. This approach is admirable and somewhat defensible because it takes a stand on a solution that is arguably good enough for most users. However, the approach of assuming the world is Unicode is flat out wrong and has significant implications for systems level applications (like version control tools)." [1] https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey-to-and-reflections-on-python-3/
Mar 01
parent reply Kagamin <spam here.lot> writes:
On Sunday, 1 March 2020 at 15:07:38 UTC, Mark wrote:
 https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey-to-and-reflections-on-python-3/
 In cases like Python refusing to accept bytes for things like 
 HTTP header names (which will just be spit out over the wire as 
 bytes), Python's pendulum has swung too far towards Unicode 
 only.
 For example, POSIX (Linux) tends to use char * for everything 
 and doesn't care about encoding and Windows tends to use 16 bit 
 character types where the encoding is... a can of worms.
Et tu, Windows? Honestly, that's just OCD. To think a person with OCD can write in a dynamic language.
Mar 05
parent Kagamin <spam here.lot> writes:
 The reality here is that it is impossible to abstract over 
 differences between operating system behavior without 
 compromises that can result in data loss, outright wrong 
 behavior, or loss of functionality.
The result was predictable.
Mar 05
prev sibling next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
I tried Go a while back, but when I found that it enforces K&R style to the point of issuing errors if I used Allman-style curly braces, I just lost interest. Yeah, it doesn't take much. :)
Feb 29
next sibling parent reply Tove <tove fransson.se> writes:
On Saturday, 29 February 2020 at 08:56:36 UTC, Ron Tarrant wrote:
 On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright 
 wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
I tried Go a while back, but when I found that it enforces K&R style to the point of issuing errors if I used Allman-style curly braces, I just lost interest. Yeah, it doesn't take much. :)
Funny, I read the spec, when I realized that I wasn't able to use Allman, I instantly ditched GO, didn't even try Hello World to this day. I thought I was alone.
Feb 29
parent drathier <forum.dlang.org fi.fo> writes:
On Saturday, 29 February 2020 at 10:42:57 UTC, Tove wrote:
 On Saturday, 29 February 2020 at 08:56:36 UTC, Ron Tarrant 
 wrote:
 On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright 
 wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
I tried Go a while back, but when I found that it enforces K&R style to the point of issuing errors if I used Allman-style curly braces, I just lost interest. Yeah, it doesn't take much. :)
Funny, I read the spec, when I realized that I wasn't able to use Allman, I instantly ditched GO, didn't even try Hello World to this day. I thought I was alone.
It's very interesting that syntax is this important to you when D has one of the most complex syntaxes of any language I've written in :)
Feb 29
prev sibling next sibling parent Guillaume <fristname.lastname gmail.com> writes:
On Saturday, 29 February 2020 at 08:56:36 UTC, Ron Tarrant wrote:
 I tried Go a while back, but when I found that it enforces K&R 
 style to the point of issuing errors if I used Allman-style 
 curly braces, I just lost interest.

 Yeah, it doesn't take much. :)
Same :) I don't want to live in the Go team dystopia.
Feb 29
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Saturday, 29 February 2020 at 08:56:36 UTC, Ron Tarrant wrote:
 On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright 
 wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
I tried Go a while back, but when I found that it enforces K&R style to the point of issuing errors if I used Allman-style curly braces, I just lost interest.
Even I totally prefer K&R style, on the other hand forcing one style in a language is a mistake for me. Matheus.
Feb 29
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 29, 2020 at 08:56:36AM +0000, Ron Tarrant via Digitalmars-d wrote:
[...]
 I tried Go a while back, but when I found that it enforces K&R style
 to the point of issuing errors if I used Allman-style curly braces, I
 just lost interest.
 
 Yeah, it doesn't take much. :)
For me, the fact the Go didn't (and still doesn't) have generics is a showstopper for me. I just can't imagine writing / maintaining code of any non-trivial size without generics of *some* sort. I'm the kinda guy who's into heavy meta-programming, so having no generics whatsoever is just ... unpalatable. With D, though, I'm in metaprogramming heaven with templates, static if/foreach, CTFE, and string mixins. :-P T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Feb 29
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/29/20 7:15 AM, H. S. Teoh wrote:> On Sat, Feb 29, 2020 at 
08:56:36AM +0000, Ron Tarrant via Digitalmars-d wrote:

 For me, the fact the Go didn't (and still doesn't) have generics is a
 showstopper for me.
I coded in Go for one year for a microservice security company. After cursing for about two weeks I settled down and went along with whatever idioms Go wanted me to write in. I don't mean lack of features was not important; what I mean is, we humans can adapt any situation. The fact that Go does not have generics (or templates) is an indication to me of the engineering skills of Go's creators. It's almost advocating "don't use the computer, write it again and again." Well, if they haven't understood the utility of templates, they first need to open their minds and then eat multiple bakery-fulls of bread. (Bad translation of a Turkish saying.) Ali
Feb 29
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 1 March 2020 at 01:43:26 UTC, Ali Çehreli wrote:
 On 2/29/20 7:15 AM, H. S. Teoh wrote:> On Sat, Feb 29, 2020 at 
 08:56:36AM +0000, Ron Tarrant via Digitalmars-d wrote:

 [...]
generics is a
 [...]
[...]
The company you work for, is Go a customer requirement or what blocks the usage of D? Kind regards Andre
Mar 01
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/1/20 12:28 AM, Andre Pany wrote:

 The company you work for, is Go a customer requirement or what blocks
 the usage of D?
The company I used to work for used Go because the CTO had decided to use Go. To his credit, Go shined in "glue programming": Everything that a mircoservice security company would need was already written by someone else. (If not, you were sure that it would be written next week, which happened a couple of times.) You would simply import and use that feature and be happy. Of course you had to trust and accept all other dependencies that were sneaking to your project. (The linked original article mentiones this "issue".) Interestingly, we did use D in one part of the product not because of me but because of another employee who had used D at Weka. Unfortunately, it had to be rewritten in C++ both because that person was leaving the company and both because there were issues with D's threadAttachThis() and threadDetatchThis(). (I have an abandoned PR which potentially fixes at least some of the issues.) Ali
Mar 01
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 1 March 2020 at 15:03:05 UTC, Ali Çehreli wrote:
 On 3/1/20 12:28 AM, Andre Pany wrote:

 [...]
what blocks
 [...]
The company I used to work for used Go because the CTO had decided to use Go. To his credit, Go shined in "glue programming": Everything that a mircoservice security company would need was already written by someone else. (If not, you were sure that it would be written next week, which happened a couple of times.) You would simply import and use that feature and be happy. Of course you had to trust and accept all other dependencies that were sneaking to your project. (The linked original article mentiones this "issue".) [...]
Thanks a lot for the explanation. In case there is no bug report, could you create one and reference your pr? Thanks:) Kind regards Andre
Mar 01
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/1/20 8:55 AM, Andre Pany wrote:

 In case there is no bug report, could 
 you create one and reference your pr?
https://issues.dlang.org/show_bug.cgi?id=18063 https://github.com/dlang/druntime/pull/1989 Ali
Mar 01
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 1 March 2020 at 01:43:26 UTC, Ali Çehreli wrote:
 I coded in Go for one year for a microservice security company. 
 After cursing for about two weeks I settled down and went along 
 with whatever idioms Go wanted me to write in. I don't mean 
 lack of features was not important; what I mean is, we humans 
 can adapt any situation.
True, did you also adopt the very noisy Go-pattern of manually propagating all errors or did you use their ad-hoc take on "exceptions"? I've only used Go for tiny front ends, but plan to use it for something larger and I really want the more maintainable code you get with "exceptions" even though Go coders avoid it. Do you have some conclusions on that topic based on what you experienced?
 The fact that Go does not have generics (or templates) is an 
 indication to me of the engineering skills of Go's creators.
I don't think they all are against generics, but didn't want to add it to the language until they fully understood how the language would be used in the real world. E.g. figure out the limits of their interface semantics first? Not sure, but they are adding generics now. (I personally feel that the lack of proper exceptions is more of a problem than generics.)
Mar 01
next sibling parent bachmeier <no spam.net> writes:
On Sunday, 1 March 2020 at 11:47:43 UTC, Ola Fosheim Grøstad 
wrote:
 I don't think they all are against generics, but didn't want to 
 add it to the language until they fully understood how the 
 language would be used in the real world. E.g. figure out the 
 limits of their interface semantics first? Not sure, but they 
 are adding generics now.
They were also concerned about compilation speed. Here's a HN comment from Russ Cox, and a blog post he references in that comment: https://news.ycombinator.com/item?id=9622417 https://research.swtch.com/generic
Mar 01
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/1/20 3:47 AM, Ola Fosheim Gr=C3=B8stad wrote:

 True, did you also adopt the very noisy Go-pattern of manually
 propagating all errors or did you use their ad-hoc take on "exceptions=
"? We used C-like error propagation, which was not bullet-proof: There were = a few bugs related to propogation mistakes. (I think by simply=20 forgetting to check or propagating the err variable from an outer scope, = etc. I don't remember now.) I don't even know what ad-hoc Go exceptions are. :)
 (I personally feel that the lack of proper exceptions is more of a
 problem than generics.)
I agree but there is so much talk these days on the cost on exceptions=20 especially in the C++ world[1][2] that I didn't want to open that topic. = :) Additionally, exceptions are banned in safety-critical embedded=20 sytems[3]; so, even though I find exceptions very useful, I started to=20 have doubts on the topic. Ali [1] Herb Sutter: https://www.youtube.com/watch?v=3Dos7cqJ5qlzo [2]=20 https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministi= c_C_exceptions_for_embedded_systems.pdf [3] One problem I learned last year was the fact that even though there=20 can be one exception in flight, there can be unlimited number of=20 exception objects that are in caught but not yet destroyed state: try (foo()) { // ... } catch (const Exception & e) { bar(); } bar() may throw and handle another exception, which would normally be=20 fine. However, note that 'e' of this block is still alive until bar()=20 returns, which means there can be unlimited number of objects, which=20 does not fit with "allocate all your memory up front" philosophy of some = embedded systems. This was news to me until the end of last year.
Mar 01
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 1 March 2020 at 15:25:48 UTC, Ali Çehreli wrote:
 I don't even know what ad-hoc Go exceptions are. :)
panic/recover! :-)
 [3] One problem I learned last year was the fact that even 
 though there can be one exception in flight, there can be 
 unlimited number of exception objects that are in caught but 
 not yet destroyed state:

 try (foo()) {
   // ...
 } catch (const Exception & e) {
   bar();
 }

 bar() may throw and handle another exception, which would 
 normally be fine. However, note that 'e' of this block is still 
 alive until bar() returns, which means there can be unlimited 
 number of objects, which does not fit with "allocate all your 
 memory up front" philosophy of some embedded systems. This was 
 news to me until the end of last year.
I think this to a large extent is a problem with separate compilation and standard C++ development suites. For embedded you'd rather have statically determined stack-depth and and one should be able to do the same statically for exceptions, but as long as exceptions are deemed unsuitable for embedded then there is no market for such static checks so.... egg and chicken... :-/. Not an inherent trait of exceptions, but... programming culture and common patterns makes change difficult. I guess.
Mar 02
prev sibling parent reply JN <666total wp.pl> writes:
On Saturday, 29 February 2020 at 08:56:36 UTC, Ron Tarrant wrote:
 On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright 
 wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
I tried Go a while back, but when I found that it enforces K&R style to the point of issuing errors if I used Allman-style curly braces, I just lost interest. Yeah, it doesn't take much. :)
In these kind of languages, you forget about formatting at all. You just set "go fmt" to run on each save in your IDE and then you can put braces however you want and the formatter will set them up in an expected way. For D I also run dfmt on save and don't really argue with it. I used to be in the "let people code how they want" camp, but nowadays I'm more for consistent formatting, because it's one less barrier when reviewing code from others.
Feb 29
parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 29 February 2020 at 15:58:28 UTC, JN wrote:
 On Saturday, 29 February 2020 at 08:56:36 UTC, Ron Tarrant 
 wrote:
 On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright 
 wrote:
 [...]
I tried Go a while back, but when I found that it enforces K&R style to the point of issuing errors if I used Allman-style curly braces, I just lost interest. Yeah, it doesn't take much. :)
In these kind of languages, you forget about formatting at all. You just set "go fmt" to run on each save in your IDE and then you can put braces however you want and the formatter will set them up in an expected way. For D I also run dfmt on save and don't really argue with it. I used to be in the "let people code how they want" camp, but nowadays I'm more for consistent formatting, because it's one less barrier when reviewing code from others.
assuming you only push... what if you need to pull after a PR... formatting does not work. If you collaborate on FOSS you have to follow the style on a per repo basis.
Feb 29
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
It's not difficult to break rust path design. It's another go 
fanboy moved to the next hot thing. Strange why it's not node.js, 
maybe because he started with node.js.
Feb 29
parent Panke <tobias pankrath.net> writes:
On Saturday, 29 February 2020 at 20:56:35 UTC, Kagamin wrote:
 It's not difficult to break rust path design. It's another go 
 fanboy moved to the next hot thing. Strange why it's not 
 node.js, maybe because he started with node.js.
Could you elaborate?
Mar 01
prev sibling next sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
For those wanting to compare D's extensions parsing - / - /. - /.foo - /foo .txt - /foo.txt - /foo.txt/bar - C:\ . - C:\. .txt - C:\foo.txt .txt\bar - C:\foo.txt\bar
Feb 29
parent reply asdfasdfasdf <asdfasdfasdf asdf.asdf> writes:
On Saturday, 29 February 2020 at 21:42:09 UTC, Jesse Phillips 
wrote:
 For those wanting to compare D's extensions parsing

           - /
           - /.
           - /.foo
           - /foo
      .txt - /foo.txt
           - /foo.txt/bar
           - C:\
         . - C:\.
      .txt - C:\foo.txt
  .txt\bar - C:\foo.txt\bar
This makes me sad.
Feb 29
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 29 February 2020 at 23:01:57 UTC, asdfasdfasdf wrote:
 On Saturday, 29 February 2020 at 21:42:09 UTC, Jesse Phillips 
 wrote:
 For those wanting to compare D's extensions parsing

           - /
           - /.
           - /.foo
           - /foo
      .txt - /foo.txt
           - /foo.txt/bar
           - C:\
         . - C:\.
      .txt - C:\foo.txt
  .txt\bar - C:\foo.txt\bar
This makes me sad.
Why? If I was reading his tables correctly it matches close to Rust behavior (we don't provide Some() or None). I didn't run this on Windows to see if behavior changed.
Feb 29
prev sibling parent reply Bienlein <jeti789 web.de> writes:
On Friday, 28 February 2020 at 22:50:05 UTC, Walter Bright wrote:
 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/

 This is a very worthwhile read. There's a lot for us to learn 
 here.
It is mostly a rant about implementation issues of the Go library. What annoys me the most is the design of it: It looks like it were modeled after C standard library with a large extent of free functions where related things are placed in various packages, e.g. operations on strings are in a t least 3 different packages and are all free functions. Ruby is to me really a really well done nice language, but the big winner is Python. With CSP in Go there is good CPU usage and scalability and people are quite productive with it. So that makes people choose Go. That's the way the of the world.
Mar 05
parent JN <666total wp.pl> writes:
On Thursday, 5 March 2020 at 09:00:11 UTC, Bienlein wrote:
 It is mostly a rant about implementation issues of the Go 
 library. What annoys me the most is the design of it: It looks 
 like it were modeled after C standard library with a large 
 extent of free functions where related things are placed in 
 various packages, e.g. operations on strings are in a t least 3 
 different packages and are all free functions.
Not sure if talking about Go or D :)
Mar 05