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

• Walter Bright (2/2) Feb 28 https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/
• H. S. Teoh (10/13) Feb 28 The most glaring point to me is Phobos' ubiquitous use of string
• Walter Bright (13/19) Feb 28 This is an interesting problem. I don't know about Rust, but in D a stri...
• IGotD- (19/27) Feb 29 In Rust String::from does checks for valid UTF-8 every time, the
• Mark (19/33) Mar 01 A very similar complaint can be found in a recent blog post [1]
• Kagamin (3/11) Mar 05 Et tu, Windows? Honestly, that's just OCD. To think a person with
• Kagamin (1/5) Mar 05 The result was predictable.
• Ron Tarrant (5/8) Feb 29 I tried Go a while back, but when I found that it enforces K&R
• Tove (5/15) Feb 29 Funny, I read the spec, when I realized that I wasn't able to use
• drathier (4/22) Feb 29 It's very interesting that syntax is this important to you when D
• Guillaume (2/6) Feb 29 Same :) I don't want to live in the Go team dystopia.
• matheus (4/13) Feb 29 Even I totally prefer K&R style, on the other hand forcing one
• H. S. Teoh (12/17) Feb 29 For me, the fact the Go didn't (and still doesn't) have generics is a
• JN (9/19) Feb 29 In these kind of languages, you forget about formatting at all.
• Basile B. (5/24) Feb 29 assuming you only push... what if you need to pull after a PR...
• Kagamin (3/3) Feb 29 It's not difficult to break rust path design. It's another go
• Panke (2/5) Mar 01 Could you elaborate?
• Jesse Phillips (12/15) Feb 29 For those wanting to compare D's extensions parsing
• Bienlein (11/14) Mar 05 It is mostly a rant about implementation issues of the Go
• JN (2/8) Mar 05 Not sure if talking about Go or D :)
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
"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

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

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
=?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

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
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
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
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
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
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
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
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
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
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
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
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
"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
=?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
translation of a Turkish saying.)

Ali

Feb 29
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
=?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
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
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
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
=?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
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

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

(I personally feel that the lack of proper exceptions is more of
a problem than generics.)

Mar 01
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

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
=?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

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


Feb 29
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

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