On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
> On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:
>> Russel Winder:
>>
>>> The whole point of Go is to replace C,
>>
>> I didn't know this.
>>
>> Bye,
>> bearophile
>
> Because it's no longer true at all. It was the goal at the beginning, but it's no longer, they've said that Go is not a system programming language (in the sense that you can construct an OS with it).

Even though I rather use D than Go, every time I read that, I am tempted to prove people wrong. If I had the time for it, that is.

Go offers the same mechanisms for systems programming as Oberon does. If ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why cannot one do an OS with Go?

--
Paulo

On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:
> On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
>> On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:
>>> Russel Winder:
>>>
>>>> The whole point of Go is to replace C,
>>>
>>> I didn't know this.
>>>
>>> Bye,
>>> bearophile
>>
>> Because it's no longer true at all. It was the goal at the beginning, but it's no longer, they've said that Go is not a system programming language (in the sense that you can construct an OS with it).
>
> Even though I rather use D than Go, every time I read that, I am tempted to prove people wrong. If I had the time for it, that is.
>
> Go offers the same mechanisms for systems programming as Oberon does. If ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why cannot one do an OS with Go?
>

Well I can't see a GC work well in a heavily concurrent kernel. BTW the latest incarnation of Oberon includes non-GC'ed pointers. But hey, what do I know...

On Friday, 20 December 2013 at 10:26:09 UTC, Araq wrote:
> On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:
>> On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
>>> On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote:
>>>> Russel Winder:
>>>>
>>>>> The whole point of Go is to replace C,
>>>>
>>>> I didn't know this.
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> Because it's no longer true at all. It was the goal at the beginning, but it's no longer, they've said that Go is not a system programming language (in the sense that you can construct an OS with it).
>>
>> Even though I rather use D than Go, every time I read that, I am tempted to prove people wrong. If I had the time for it, that is.
>>
>> Go offers the same mechanisms for systems programming as Oberon does. If ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why cannot one do an OS with Go?
>>
>
> Well I can't see a GC work well in a heavily concurrent kernel.

Well AOS is concurrent, maybe not heavy concurrent but it does support parallel tasks.

> BTW the latest incarnation of Oberon includes non-GC'ed pointers. But hey, what do I know...

Go also has them in the unsafe package. You can convert a pointer to an uintptr via the unsafe package. That is how you convert pointers between Go and C world, for example.

I think the whole discussion about GC based OS is like JavaScript. No one in the mainstream considered scripting languages fast, until Google released V8. Although Self implementation was already quite fast and used for Hotspot.

Now we have Julia already achieving C like speeds in some areas, although the implementation is still quite young.

So until a big company does something into this direction, people will keep ignoring what has been achieved so far in the academia.

--
Paulo

pjmlp:

> Now we have Julia already achieving C like speeds in some areas, although the implementation is still quite young.

Julia compiles using LLVM, that is mature. But I think Julia uses light optimization parameters (I don't know if the optimization level can be changed).


> So until a big company does something into this direction, people will keep ignoring what has been achieved so far in the academia.

Lot of programmers ignore what academia does, this is a big problem.

Bye,
bearophile

> Lot of programmers ignore what academia does, this is a big problem.

Because these programmers are not to be convinced by some arcane academic argument but by success stories of 'industrial' projects. I don't think that's too bad, somehow the bad academic ideas need to be filtered.

But now you have a chicken-egg problem and a academic world that has no reason to push it's work into industry. How to change this?

On 2013-12-20 16:12, bearophile wrote:

> Lot of programmers ignore what academia does, this is a big problem.

Unfortunately the opposite is true as well. I read some article that here in Sweden the universities and other schools examines around 1000 people in the area of game development. At the same time the industry only needs around 300 new people.

-- 
/Jacob Carlborg

On 2013-12-20 08:03, Paulo Pinto wrote:

> Even though I rather use D than Go, every time I read that, I am tempted
> to prove people wrong. If I had the time for it, that is.
>
> Go offers the same mechanisms for systems programming as Oberon does. If
> ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why
> cannot one do an OS with Go?

When developing an OS, for somethings these languages are not enough, including C, Go and D. You need to use assembly. D has the advantage of supporting inline assembly.

-- 
/Jacob Carlborg

On 20.12.2013 22:05, Jacob Carlborg wrote:
> On 2013-12-20 08:03, Paulo Pinto wrote:
>
>> Even though I rather use D than Go, every time I read that, I am tempted
>> to prove people wrong. If I had the time for it, that is.
>>
>> Go offers the same mechanisms for systems programming as Oberon does. If
>> ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why
>> cannot one do an OS with Go?
>
> When developing an OS, for somethings these languages are not enough,
> including C, Go and D. You need to use assembly. D has the advantage of
> supporting inline assembly.
>

Until all D compilers provide the same support for inline assembly, it is better we don't use that as language feature.

Currently I rather write assembly with an external assembler than using a separate syntax per D compiler.

However you do touch a nice point, even ANSI/ISO C needs to rely on external assemblers to be useful at systems level. This is something developers forget when they equate language == what my compiler supports.

--
Paulo

On Fri, 2013-12-20 at 22:05 +0100, Jacob Carlborg wrote: […]
> When developing an OS, for somethings these languages are not enough, including C, Go and D. You need to use assembly. D has the advantage of supporting inline assembly.

C, C++, Go, D have the advantage of using separate files with the assembly code in.

Inline assembly language is a huge disadvantage in many (most?) case.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2013-12-21 07:26, Paulo Pinto wrote:

> However you do touch a nice point, even ANSI/ISO C needs to rely on
> external assemblers to be useful at systems level. This is something
> developers forget when they equate language == what my compiler supports.

You will most likely not be able to rely only on standard ANSI/ISO C. Be it either languages extension, using some pragma/attribute or some special flag. Things like force inline, placing data structures in special sections and so on.

-- 
/Jacob Carlborg