
G.E.R.T: Golang Embedded Run-Time - ingve
https://github.com/ycoroneos/G.E.R.T/blob/master/README.md
======
gok
Previous discussion:
[https://news.ycombinator.com/item?id=14590847](https://news.ycombinator.com/item?id=14590847)

------
bsaul
Maybe i'm wrong, but i really feel that keeping go minimal is enabling lots of
experiments with it, as well as providing very powerful tools _around_ the
language. I'm not sure what design "school" it is following (maybe unix single
purpose command, but maybe there's something more relevant), but authors of
the language really made an interesting point by sticking to their initial
feeling, and delivering.

Although i wouldn't use go for "high level" development (that is, end-user
apps or web services), it has really proved to be a great tool for middleware
/ technical layers.

~~~
Numberwang
Why would you not use it for things like web services? That's one of the main
goals of the language.

~~~
bsaul
User-facing applications or web services often deal with business logic. That
is, logic that models real-life processes and entities, such as "Customer" or
"Purchase". In order to model those kind of processes you often need powerful
modelling abilities (such as subclassing, or generic programming), which go
really lacks. I don't have a proof of that just my personal experience, but
i'd say Object Oriented Programming is the de-facto standard in "enterprise"
software for that reason.

The reason go fits the "technical layer" best, is that technical layer deals
with things closer to the machine, so the number of different types you need
to manipulate is much lower, and is for the most part of the language (it
doesn't go further than numbers and strings).

All of this is just my personal opinion of course.

EDIT: i know composition (which go provides) and subclassing provide the same
possibilities in term of modeling, in theory. However in practice, not beeing
able to say things like "An Electric Car, is a kind of Car, which is a kind of
Vehicle" may make things cumbersome. So is not being able to simply create a
function such as "sortByMileage" that applies to all kinds of Vehicle (and
just that), but remain type safe.

To sum-up : relying on interfaces and composition only is IMHO not as powerful
as having interface, composition, inheritance and generics (which most
"enterprise" language have).

~~~
oelmekki
Actually, not having inheritance is what I love the most about go. When I
write ruby code, I keep wondering "where does this method come from?" and have
to grep my codebase.

"Composition over inheritance" is not a new trend, that was actually mentioned
in first chapter of Gang of four's Design Patterns in 1995 [1]. In that
regard, I feel like we mostly failed to ever use OOP properly (although,
"fail" is probably too strong a word).

I'm actually annoyed that embedded types exist in go because it re-introduces
the same problem (but I have an easy fix for that: I don't use them).

But really, what you're describing is a data structure problem. This can be
solved without OOP, and structs are especially good at it.

[1]
[https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2...](https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2C_Chapter_1)

~~~
criddell
> When I write ruby code, I keep wondering "where does this method come from?"
> and have to grep my codebase.

Sounds like a shortcoming of your tools. I spend a lot of time in Visual
Studio working on native C++ and even there I can ctrl-click on something and
jump to the declaration or definition. I bet there's something even better for
Ruby.

~~~
oelmekki
Yeah probably, I don't use any IDE feature for ruby code. It's still a problem
that all methods available in current scope are not immediately obvious,
though. And if you try to inspect available methods on an object in a REPL
console using `#methods`, there usually are hundredth of them, especially when
using rails (although to be fair, it's not all due to inheritance, there are
also a lot coming for mixins). I suppose ruby IDEs have the same problem.

When I write go code, I have a lot of static analysis tools, but I'm still
glad it's easy for me to know what I can call without stopping for inspection.

------
rkangel
My instinctive response is "but it's garbage collected, so what use does that
have on embedded?". Most of the stuff I'm doing is fairly soft real time
though.

Am I being too closed minded and a garbage collector that ran quickly enough
would still allow for a useful design space?

~~~
pjmlp
Yep a bit closed minded. :)

Have a look at Project Oberon, Mesa/Cedar at Xerox PARC, Modula-3 at
DEC/Olivetti, Singularity/Midori at Microsoft

[https://en.wikipedia.org/wiki/Oberon_(operating_system)](https://en.wikipedia.org/wiki/Oberon_\(operating_system\))

[http://www.ocp.inf.ethz.ch/wiki/Documentation/Front](http://www.ocp.inf.ethz.ch/wiki/Documentation/Front)

[https://en.wikipedia.org/wiki/SPIN_(operating_system)](https://en.wikipedia.org/wiki/SPIN_\(operating_system\))

[https://archive.org/details/bitsavers_xeroxparcteCedarProgra...](https://archive.org/details/bitsavers_xeroxparcteCedarProgrammingEnvironmentAMidtermRepo_13518000)

[http://joeduffyblog.com/2015/11/03/blogging-about-
midori/](http://joeduffyblog.com/2015/11/03/blogging-about-midori/)

[https://www.infoq.com/presentations/csharp-systems-
programmi...](https://www.infoq.com/presentations/csharp-systems-programming)

All of them produced workable graphical workstations that were used for a
couple of years until the projects were shutdown for political/monetary
reasons.

Oberon GUI is the genesis how Plan 9/Inferno GUIs work, specially the ACME
text editor.

For something with more constraints, Real-Time Java implementations are
powering battleship weapons tracking systems, here two examples

[http://www.military.com/equipment/aegis-weapon-
system](http://www.military.com/equipment/aegis-weapon-system)

[http://www.marketwired.com/press-release/ibm-raytheon-
delive...](http://www.marketwired.com/press-release/ibm-raytheon-deliver-
technology-solution-ddg-1000-next-generation-navy-destroyers-nyse-
ibm-719837.htm)

Having said this, of course there are environments where not having a GC at
all is a better approach for the use case being solved.

What many in the anti-GC crowd don't realise it that these GC enabled systems
languages also allow to switch off the GC on critical code sections, or make
use of manual memory management in unsafe code.

So it it not necessary to throw away the productivity to get the full benefit
of performance, if the language offers the necessary knobs.

~~~
themihai
Go doesn't allow you to switch off the GC on critical code sections. The
switch-off is only for debug/dev purpose.

~~~
pjmlp
True, Go still needs some help, but there are ways even with the current set
of language features.

1 - Use a memory profiler to ensure the memory usage is kept on constant
level;

2 - Reduce GC pressure by manually managing memory at Go level;

3 - If still not enough,

3.1 - if there is an OS underneath call its allocation/release APIs directly,

3.2 - running on bare metal, implement a manual allocator with a mix of
package _unsafe_ and Assembly for CPU register access

It is not the same as using untraced references in Modula-3, but it does the
job.

Also I should note that even ANSI C requires use of Assembly in libc to
implement _malloc()_ / _free()_ on bare metal.

~~~
themihai
>> manually managing memory at Go level

What exactly do you mean? Go doesn't allow you to manage memory. At most you
can give some hints to the compiler but they may or may not work depending on
the compiler/version.

>> 3.1 - if there is an OS underneath call its allocation/release APIs
directly, 3.2 - running on bare metal, implement a manual allocator with a mix
of package unsafe and Assembly for CPU register access

That seems to require some patches to the runtime and compiler not to mention
that you start to depart from what you might remember as being Go
language/development. You create more problems to fix the GC problem. I
believe a real solution would be an opt-in subset of Go using Rust-like memory
model. Swift(Apple) seems to work on a such solution.

~~~
pjmlp
Sure it does, you just have to do it like in the good old days.

The easy way is to make use of object pooling via _sync /pool_.

The hard way is to declare a static array allocated as global variable in a
package for the set of data that one needs to manage and make use of pointers
to free slots.

What patches to runtime and compiler?

You are mixing up programming language and implementation.

There are no pure ANSI C compilers for bare metal programming, 100% of them
require language extensions.

