What I like about go is that I can go full unsafe.Pointer if i want to, and do whatever I want.

The other thing I really like, is that they did such a good job discouraging it that i frequently hear people complain about go having pointers but not even letting you have fun with them.

The problem isn't that go doesn't give you enough control, the problem is that it's garbage collected. And you'd need to work around the GC. It's doable and people have done it though. Good idea? Maybe not.

Still waiting for someone to make "go but with ownership and borrow checker"

I'm no a systems programmer unless you count hobby microcontroller projects, but my understanding is that, when a systems programmer is talking about control, they tend to be talking first and foremost about keeping tight limits on memory usage. Pointers and suchlike just happen to be key tools that help you do that.

https://www.withsecure.com/en/solutions/innovative-security-...

That would have interested me more a few years ago, but I'm deeply invested in Rust these days.

Is that all you'd change about Go? One of the reasons I moved was the error handling and lack of generics. Go has fixed the latter, but I can't stand not having Result<> and Option<> these days. The '?' is awesome too.

No, go has plenty of warts, like every language (ever formatted a date in go?). I just don't like kitchen sink languages.

Leaving aside the GC, until Go has a real FFI it's hard to to imagine it being a really great fit for systems programming when the systems are all not written in Go.

I’m not bashing Go though. I appreciate the focus on readability among other things. It’s a fine language for the use cases it was actually designed for, like pushing petabytes of ad data to serving clusters all around the world with acceptable latency and reliability.

I guess the Genera, Xerox PARC, ETHZ, Microsoft folks are borderline dishonest.

Writing compilers is not systems programming in the sense that it requires a systems programming language, no. One could easily write a C compiler in Ruby, but we don't consider Ruby to be a systems programming language.

Thus, obviously, Go, despite not being a systems programming language, could be used to write the compiler for a systems programming language. I guess that is what Tamago is? I'm not going to read through the source to find out and the web page you linked is boring marketing copy.

[1] https://go.dev/dl/

TamaGo is a bare metal runtime for unikernels, whose main use is a commercial product for secure USB keys, sold by F-Secure.

Back on my youth, writing compilers was considered systems programming, in parity with kernel drivers, how things change.

I guess writing userspace drivers in hybrid kernels is also not considered systems programming.

Possibly related, building against foreign objects and manually setting up the FFI call: https://words.filippo.io/rustgo/.

What was good for C while it was gaining adoption, surely is good enough for Go.

https://en.m.wikipedia.org/wiki/Small-C

https://github.com/trcwm/smallc_v1

Wouldn’t this be just a lesser version of rust then? If someone makes a new language and wants it to catch on, it needs new ideas. Not just nice simple syntax mixed with something someone else is already doing.

That depends if you consider C++ an upgrade over C :)

Many flamewars have been had on this topic and i think it's just a matter of personal taste.

I'm firmly in the less is more camp.

Are you saying the reason Rust is now being integrated into the Kernel instead of Golang is because of the success of evangelists, not because of the merit of the language itself?

I'm not involved in Kernel development myself, but if I was, I'd see your statement as a big hit in the face that we don't know what we're doing, if they (Kernel developers) are being sold to use Rust because of marketing, not because of the value of the language.

For example, the arguments against namespaces and function overloading, high context dependency, easy of understanding and in favour of C's simplicity in general.

My guess (it's just a guess) is that his position has shifted over time to consider a higher-abstraction, higher-complexity language, as development methods and the complexity and professionalising of the kernel have changed since then.

The person you’re replying to is either deeply misinformed or trolling

You see how parties completely unrelated to the fight got Linus ousted? That was not based on technical merit, it was due to the changing tide regarding outcomes when people are offended/mistreated. Rust has significant overlap with the community that gave way to this, don't think it is 100% open arms and welcomes, because that is not the case.

Every day we stray further from God.

Compare and contrast Rust, where the code I write will usually just work. I don't need to be extra careful with it because the compiler is strict. You can say that this is indicative of some flaw in my character or whatever, but, uh, I don't care.

Rust for Linux relies on the fact that Rust is deliberately structured in layers so that the bottom layer doesn't need that infrastructure, this was needed to make embedded Rust practical, but it's also important for Linux. Actually, Linux needs even more than Rust had initially, but that's driven further improvements to Rust itself.

You could add a layer to do all this lifting (that's what e.g. a Java OS does) but that's not going to fly in Linux, which is one reason why Go for Linux isn't a thing whereas Rust for Linux is.

What does that mean? Isn't GC a fundamental part of Go?

OTOH, if the differences are minimal, then the benefits are likely to be correspondingly minimal. And either way, the compiler/interpreter for a relatively new language will by definition be much less battle-tested.

Practically speaking, I think if a new language is going to compete with C, it needs to offer more than a few incremental improvements.