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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020