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

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

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

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/

On 3/1/20 3:47 AM, Ola Fosheim Grøstad 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 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 especially in the C++ world[1][2] that I didn't want to open that topic. :) Additionally, exceptions are banned in safety-critical embedded sytems[3]; so, even though I find exceptions very useful, I started to have doubts on the topic.

Ali

[1] Herb Sutter: https://www.youtube.com/watch?v=os7cqJ5qlzo

[2] https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf

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

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

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

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.

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.

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