On Thursday, 13 March 2014 at 06:49:35 UTC, Dicebot wrote:
> On Wednesday, 12 March 2014 at 18:05:38 UTC, Etienne wrote:
>> I think this article puts it well. Bypassing the kernel for fibers should be a long-term plan :)
>>
>> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
>
> I have seen one real-world project where it was done. Point is not about specifically fibers though but scheduling as a whole - when all resources of the system are supposed to be devoted to a single service, general-purpose OS scheduling creates problems as it is intended for universal multi-tasking.

I know it would be breaking for other services on the computer assuming it's a desktop, but dedicated servers or embedded devices can make great use of such a feature. I'm sure this implementation could be done without restricting everything to it, especially with functional programming as we have it in D. I assume a demonstrated ten-fold increase in performance by-passing kernel is a radical justification for this.

On Thursday, 13 March 2014 at 18:49:42 UTC, Etienne wrote:
> On Thursday, 13 March 2014 at 06:49:35 UTC, Dicebot wrote:
>> On Wednesday, 12 March 2014 at 18:05:38 UTC, Etienne wrote:
>>> I think this article puts it well. Bypassing the kernel for fibers should be a long-term plan :)
>>>
>>> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
>>
>> I have seen one real-world project where it was done. Point is not about specifically fibers though but scheduling as a whole - when all resources of the system are supposed to be devoted to a single service, general-purpose OS scheduling creates problems as it is intended for universal multi-tasking.
>
> I know it would be breaking for other services on the computer assuming it's a desktop, but dedicated servers or embedded devices can make great use of such a feature. I'm sure this implementation could be done without restricting everything to it, especially with functional programming as we have it in D. I assume a demonstrated ten-fold increase in performance by-passing kernel is a radical justification for this.

In project I have mentioned it was taken to an extreme measure, eliminating kernel completely and sticking to barebone executable for all traffic processing (with customized linux nodes for management tasks). Performance achieved was very impressive (scale of hundreds of Gbps of throughput and millions of simultaneous TCP/UDP flows). Using D for such task has similar issues and solutions as using D for embedded (Adam, I am looking at your DConf talk!)

On Friday, 14 March 2014 at 17:44:36 UTC, Dicebot wrote:
> Using D for such task has similar issues and solutions as using D for embedded (Adam, I am looking at your DConf talk!)

Hmm, I doubt I'll say anything you don't already know though...

Right now, I'm thinking the topics will be along the lines of:

*) Smashing druntime then building it back up to see what does what, so we'll look at TypeInfo, _d????() functions, exception handling, class implementation, etc.

*) Probably my pet topic of RTInfo just because we can

*) naked asm for interrupt handlers (i just think it is cool that you can do it all right in D without hacking dmd itself). I wrote a keyboard handler a couple days ago, nothing fancy but it shows a nice interactive result.

*) a few ABI things and notes about how some constructs work, like scope(exit) on the assembly language level

*) Memory-mapped hardware and struct packing (surely nothing new to anyone who's done low level code before.)

*) And I actually want to bring the garbage collector in too (*gasp!*). It might be bare metal, but it is still overpowered PC hardware, we might as well play with the resources.


But I wasn't planning on even trying to do anything like a network stack, or even getting into particularly fancy D code. tbh my audience is more the reddit crowd that says "D sucks. not real systems level language." just to say "no u wrong" while saying some things D enthusiasts might find interesting than to really expand the minds of embedded D developers or anything like that; hell, odds are you know (a lot) more than me on that anyway.

On Thursday, 6 March 2014 at 17:17:12 UTC, Atila Neves wrote:

There is a thread now on the Go user forum about GoF design patterns in Go: https://groups.google.com/forum/?hl=de#!topic/golang-nuts/3fOIZ1VLn1o Reading the comments by Robert Pike (the Go lead developer) is insightful. Here is one of them:

"A concrete example: The Visitor Pattern.

This is a clever, subtle pattern that uses subtype inheritance to
implement a type switch.

Go has type switches, and therefore no need for the Visitor Pattern."

With type switches he means a case switch on types, see http://golang.org/doc/effective_go.html#type_switch

In other words, Go and OOP: Abandon all Hope! From my side the "Go vs D MQTT thing" is closed. Go will never develop into any thing than C in a modern disguise.

Maybe I now hi-jacked the thread another time. Sorry, but couldn't resist. At least I did resist to post a reply in that thread on the Go user forum. I think it would be plain useless ...

Am 17.03.2014 17:16, schrieb Bienlein:
> On Thursday, 6 March 2014 at 17:17:12 UTC, Atila Neves wrote:
>
> There is a thread now on the Go user forum about GoF design patterns in
> Go:
> https://groups.google.com/forum/?hl=de#!topic/golang-nuts/3fOIZ1VLn1o
> Reading the comments by Robert Pike (the Go lead developer) is
> insightful. Here is one of them:
>
> "A concrete example: The Visitor Pattern.
>
> This is a clever, subtle pattern that uses subtype inheritance to
> implement a type switch.
>
> Go has type switches, and therefore no need for the Visitor Pattern."
>
> With type switches he means a case switch on types, see
> http://golang.org/doc/effective_go.html#type_switch
>
> In other words, Go and OOP: Abandon all Hope! From my side the "Go vs D
> MQTT thing" is closed. Go will never develop into any thing than C in a
> modern disguise.
>
> Maybe I now hi-jacked the thread another time. Sorry, but couldn't
> resist. At least I did resist to post a reply in that thread on the Go
> user forum. I think it would be plain useless ...
>

That is no wonder.

If you search the web for references, you will find that Rob Pike very much dislikes OOP.

When I jumped into Go as of the language's announcement, was due to the language influence of Oberon.

However with time, I came to realize my time is better spent with other language communities that enjoy modern features instead of a remake of Limbo.

I still check gonuts, every now and then, though. Just don't bother posting anything.


--
Paulo

On 3/17/14, 9:16 AM, Bienlein wrote:
> On Thursday, 6 March 2014 at 17:17:12 UTC, Atila Neves wrote:
>
> There is a thread now on the Go user forum about GoF design patterns in
> Go:
> https://groups.google.com/forum/?hl=de#!topic/golang-nuts/3fOIZ1VLn1o
> Reading the comments by Robert Pike (the Go lead developer) is
> insightful. Here is one of them:
>
> "A concrete example: The Visitor Pattern.
>
> This is a clever, subtle pattern that uses subtype inheritance to
> implement a type switch.
>
> Go has type switches, and therefore no need for the Visitor Pattern."
>
> With type switches he means a case switch on types, see
> http://golang.org/doc/effective_go.html#type_switch
>
> In other words, Go and OOP: Abandon all Hope! From my side the "Go vs D
> MQTT thing" is closed. Go will never develop into any thing than C in a
> modern disguise.
>
> Maybe I now hi-jacked the thread another time. Sorry, but couldn't
> resist. At least I did resist to post a reply in that thread on the Go
> user forum. I think it would be plain useless ...

That's fine - the man doesn't like OOP and that influences the design of his language. I also suspect he's not conversant with the various modularity-related aspects of Visitor, given the glibness of the answer.

And that all is fine. Walter and I also have various lacuna, and that does influence the design of D. The same goes about virtually all programming languages.


Andrei

On Monday, 17 March 2014 at 17:02:06 UTC, Paulo Pinto wrote:
> That is no wonder.
>
> If you search the web for references, you will find that Rob Pike very much dislikes OOP.

All right, but what is then the solution to encapsulate things? A type switch breaks encapsulation: If you change some inner works of component A you might have to extend the type switch in Component B. I understand the argument that dynamic binding is a high price to achieve this, but a type switch as in Go that simply breaks encapsulation is not very convincing.

> When I jumped into Go as of the language's announcement, was due to the language influence of Oberon.

Do you have some affiliation with the ETHZ? Oberon didn't spread much outside of it. I played with Oberon many years ago and I also recognized similarities of it in Go. Just read about it again to recap and it was striking to see how much the Oberon WITH statement resembles a Go type switch. I guess Niklaus Wirth would like Go ...

On Monday, 17 March 2014 at 20:39:21 UTC, Andrei Alexandrescu wrote:

> That's fine - the man doesn't like OOP and that influences the design of his language. I also suspect he's not conversant with the various modularity-related aspects of Visitor, given the glibness of the answer.

Yeah, it's usually the story about Dr.Johnson's dog ... ;-).

On Monday, 17 March 2014 at 21:24:53 UTC, Bienlein wrote:
> On Monday, 17 March 2014 at 17:02:06 UTC, Paulo Pinto wrote:
>> That is no wonder.
>>
>> If you search the web for references, you will find that Rob Pike very much dislikes OOP.
>
> All right, but what is then the solution to encapsulate things?

To do it all manually with function variables, of course, just
like in C.

Am 17.03.2014 22:24, schrieb Bienlein:
> On Monday, 17 March 2014 at 17:02:06 UTC, Paulo Pinto wrote:
>> That is no wonder.
>>
>> If you search the web for references, you will find that Rob Pike very
>> much dislikes OOP.
>
> All right, but what is then the solution to encapsulate things? A type
> switch breaks encapsulation: If you change some inner works of component
> A you might have to extend the type switch in Component B. I understand
> the argument that dynamic binding is a high price to achieve this, but a
> type switch as in Go that simply breaks encapsulation is not very
> convincing.
>
>> When I jumped into Go as of the language's announcement, was due to
>> the language influence of Oberon.
>
> Do you have some affiliation with the ETHZ? Oberon didn't spread much
> outside of it. I played with Oberon many years ago and I also recognized
> similarities of it in Go. Just read about it again to recap and it was
> striking to see how much the Oberon WITH statement resembles a Go type
> switch. I guess Niklaus Wirth would like Go ...

A spiritual affiliation if you will.

I learned Pascal via Turbo Pascal before I got to learn C and it spoiled me never to enjoy pure C, although I like C++.

A few years later when I discovered I could not use Turbo Pascal on UNIX, did I realize how basic plain ISO Pascal was. The improved ISO Extended Pascal was being ignored as Pascal compiler vendors tried to be compatible with Turbo Pascal.

This was around the early 90's, when I started to interest myself for language design, which meant trying to learn as much as possible from all sources of information. Mostly books and OOPSLA papers, not much Internet on those days.

The university library had lots of cool books, including many about Modula-2 and Oberon. So given my appreciation for Wirth's work I devoured those books and discovered in addition to Turbo Pascal a few more languages that could be used for systems programming.

Around this time ETHZ started to support using standard PCs in addition to the Ceres hardware. So I got to install it on my computer.

I was playing with the idea of creating a compiler for Oberon in GNU/Linux, which never came to be for a few reasons, although I did write an initial lexer and grammar for it.

https://github.com/pjmlp/Oberon-2-FrontendTools

You might find a few posts from me in comp.compilers archives from those days.

The system impressed me for trying to provide a similar experience to Smalltalk, which I already knew and showing me that having a full blown OS done in a GC enabled systems programming language was possible.

Since then, I have tracked Wirth's work, collecting all his publications and books.

I also had the pleasure to be with him when CERN organized an Oberon day back in 2004, when I was still there.

--
Paulo