Fuchsia Programming Language Policy

652 views
Skip to first unread message

Jon Conradt

unread,
Feb 25, 2020, 12:22:11 PM2/25/20
to golang-nuts
The Fuchsia Programming Language Policy gives some insight into the experience the Fuchsia team has had with Go, and it doesn't sound good.

"The Fuchsia Platform Source Tree has had negative implementation experience using Go. The system components the Fuchsia project has built in Go have used more memory and kernel resources than their counterparts (or replacements) the Fuchsia project has built using C++ or Rust."

The Fuchsia Platform Source tree is defined as "The Fuchsia Platform Source Tree is the source code hosted on fuchsia.googlesource.com."

Their conclusion, and each language has some issues is pretty severe.
  • Go is not approved, with the following exceptions:
    • netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
  • All other uses of Go in Fuchsia for production software on the target device must be migrated to an approved language.
 That's a shame. I was hoping that Fuchsia would provide a way for Go to have a nice GUI.

Two of the issues listed as cons include the toolchain producing 'large binaries' and the related issue of their being a 'substantial runtime.' It seems to me that both of these issues can be addressed through some of the techniques used to build tiny Docker images from Go, but I suspect they would like to have a much simpler route, e.g. a go build flag.

Jon

Mohamed Yousif

unread,
Feb 25, 2020, 12:53:40 PM2/25/20
to Jon Conradt, golang-nuts
It seems they are betting high on Dart/flutter and their front end is already written with flutter. The assessment seems to be pretty much the same as for Dart.

Dart won with the ui side, while go was competing with C. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7778a387-f1f5-4ed0-8453-5b811bac4a6d%40googlegroups.com.

Michael Jones

unread,
Feb 25, 2020, 1:21:00 PM2/25/20
to Mohamed Yousif, Jon Conradt, golang-nuts
Actually, you should read the whole note -- it's fun. Half of the languages are bad because of memory leaks, the other half are bad because of having GC; half are bad because of difficult asynchronism, the other half are bad because of having a runtime. etc. 

It reads like an imperiously-worded tautology about safety/power/convenience coming at a cost.



--
Michael T. Jones
michae...@gmail.com

Manlio Perillo

unread,
Feb 25, 2020, 4:05:18 PM2/25/20
to golang-nuts
And the one that is good at both memory management and concurrency has properties of the language that are not yet well-understood.


Manlio


On Tuesday, February 25, 2020 at 7:21:00 PM UTC+1, Michael Jones wrote:
Actually, you should read the whole note -- it's fun. Half of the languages are bad because of memory leaks, the other half are bad because of having GC; half are bad because of difficult asynchronism, the other half are bad because of having a runtime. etc. 

It reads like an imperiously-worded tautology about safety/power/convenience coming at a cost.

On Tue, Feb 25, 2020 at 9:51 AM Mohamed Yousif <mmb...@gmail.com> wrote:
It seems they are betting high on Dart/flutter and their front end is already written with flutter. The assessment seems to be pretty much the same as for Dart.

Dart won with the ui side, while go was competing with C. 
On Tue, 25 Feb 2020 at 7:22 PM, Jon Conradt <j...@theconradts.com> wrote:
The Fuchsia Programming Language Policy gives some insight into the experience the Fuchsia team has had with Go, and it doesn't sound good.

"The Fuchsia Platform Source Tree has had negative implementation experience using Go. The system components the Fuchsia project has built in Go have used more memory and kernel resources than their counterparts (or replacements) the Fuchsia project has built using C++ or Rust."

The Fuchsia Platform Source tree is defined as "The Fuchsia Platform Source Tree is the source code hosted on fuchsia.googlesource.com."

Their conclusion, and each language has some issues is pretty severe.
  • Go is not approved, with the following exceptions:
    • netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
  • All other uses of Go in Fuchsia for production software on the target device must be migrated to an approved language.
 That's a shame. I was hoping that Fuchsia would provide a way for Go to have a nice GUI.

Two of the issues listed as cons include the toolchain producing 'large binaries' and the related issue of their being a 'substantial runtime.' It seems to me that both of these issues can be addressed through some of the techniques used to build tiny Docker images from Go, but I suspect they would like to have a much simpler route, e.g. a go build flag.

Jon

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

andrey mirtchovski

unread,
Feb 25, 2020, 4:51:18 PM2/25/20
to Manlio Perillo, golang-nuts
my take:
- c++ programmers are going to c++ program. film at 11 (rob pike had a
talk about that)
- dart has UI
- rust is fashionable, but scary (if you've done rust you'll know why)

yes, go was touted as a systems programming language, but it meant
"distributed systems". had that been made clear from the beginning all
this strife would've disappeared. u-root.org shows that go can be used
at firmware level quite handily.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a5227da6-c1ee-4754-95c4-c6bb1dd2d40f%40googlegroups.com.

Jesper Louis Andersen

unread,
Feb 25, 2020, 6:14:57 PM2/25/20
to Jon Conradt, golang-nuts
On Tue, Feb 25, 2020 at 6:22 PM Jon Conradt <j...@theconradts.com> wrote:
The Fuchsia Programming Language Policy gives some insight into the experience the Fuchsia team has had with Go, and it doesn't sound good.

"The Fuchsia Platform Source Tree has had negative implementation experience using Go. The system components the Fuchsia project has built in Go have used more memory and kernel resources than their counterparts (or replacements) the Fuchsia project has built using C++ or Rust."


This shouldn't be unexpected. It is the trade-off you make with a garbage collector.

However, it should also be quantified. 33%-40% extra memory usage is likely. 800% isn't, and would suppose there are structural problems with the program.

If it is merely a qualitative assessment, then it falls into the category of subjective opinion. This may be relevant, but it isn't healthy goal setting. It would have been better if you had "Go programs we wrote routinely use 200% of the memory of comparable C++ programs. This is too much, and we can only accept an increase of 20%." Because then the whole thing is actionable.

The Go garbage collector's pause times is a good example of such an approach. Start with a conservative goal. Achieve that. Then improve it over time.

Any program has a bar resource-wise. If you can jump over it, you should accept the win. Moving the bar continually is usually a bad sign, in my opinion, since the rules are now up for interpretation outside of your direct control. So once you demonstrate you can jump high enough, it will just be moved up a tad so you can't. "Der Prozeß" comes to mind :)

G Shields

unread,
Feb 25, 2020, 11:21:44 PM2/25/20
to golang-nuts
They made a political decision,
Not supporting GO in the new OS or a GO GUI is a show stopper.

After Unladen Swallow and others https://killedbygoogle.com/

I am, No longer interested in GO

Ian Lance Taylor

unread,
Feb 25, 2020, 11:45:34 PM2/25/20
to Jon Conradt, golang-nuts
To be clear, the Fuchsia project has decided to not use Go in the
development of Fuchsia itself. You can still run Go programs on
Fuchsia. See https://fuchsia-review.googlesource.com/c/fuchsia/+/367414
which tries to clarify this. That said I haven't seen much recently
about adding the Go port of Fuchsia to the main Go repo.

Ian

Jon Conradt

unread,
Feb 26, 2020, 12:25:13 AM2/26/20
to golang-nuts
It is nice to see the clarification. I can understand not using a GC language in the OS, but the previous wording did sound like it was unwelcome in their user land tools. 

Progress in getting their port of Go into the CI system would be encouraging. 

Jon

David Skinner

unread,
Feb 26, 2020, 12:29:58 PM2/26/20
to golang-nuts
I quite understand their critic.
  • GC sometimes causes me problems that result in me writing part of my code in C++ or ASM. But over the last 10 years the GC seems to be mostly improving and that is rarely a problem for me.
  • I used to write engineering, accounting, and legal apps that ran on 4k RAM on dual tape drives. Go is a real memory hog. But memory is cheap and plentiful and my time has value and Go lets me be three times as productive as C++.
  • I have written some real dog programs in Go, my son Daniel had to profile, clean up, refactor, and get things to where it was faster, used less memory and did not suffer delays. Just because Go is easy to use does not mean that novices can always create high-quality code using Go.
I understand why they would make this decision for their use case but I do think that they are somewhat short-sighted and flawed in thinking only about certain specific details that can easily be overcome with profiling, optimization, and additional programmer training. Using Go may seem easy but after using it for ten years, I find that I am still learning how to use the language, but the investment of time is yielding very real dividends. If you want instant gratification and gotta have it now, then maybe Go is not your best choice, it is more of a long term investment.
Reply all
Reply to author
Forward
0 new messages