Go is a high level language, it doesn’t share any quality with C, other than perhaps bad expressiveness.

"C Is Not a Low-level Language Your computer is not a fast PDP-11."

https://queue.acm.org/detail.cfm?id=3212479

That article completely misses the point - assembly (or machine code) might not be how the "metal" works on a modern desktop(-like) CPU, but that is irrelevant when that is the lowest level that said CPUs are exposing. On such CPUs C is at the lower levels possible.

But also C isn't just for Intel, x86 and (some) ARM CPUs, there are other targets it has.

Nothing of that is exclusive to C, please provide an example of a CPU where C is the only compiler toolchain available, and exposes CPU capabilities without using language extensions.

Any example with language extensions to ISO C, allows me to provide a counter example with language extensions.

Any example where only a subset of ISO C is allowed, allows me to provide a counter example with a language subset.

Are you replying to the correct comment? I never claimed anything that would be exclusive to C. What i wrote applies equally to something like, e.g., most Pascal dialects that are around the same "level" as C.

This leaves room for such interpretation "On such CPUs C is at the lower levels possible.".

Sorry if I misunderstood it.

But many microcontrollers are and their toolchains do treat it as such.

Just like other programming languages, C is not a special snowflake.

https://www.f-secure.com/en/consulting/foundry

https://developer.arm.com/solutions/internet-of-things/langu...

What about Rust?

Too complicated. Rust is more similar to C++ than it is to C.

I tried multiple times to grok rust, but it's still too difficult for me to understand and be comfortable. In contrary go other than the struggle of unused variable compile error, I can use it within hours.

Maybe. But it's still closer to C than go is.

What's wrong with that? Rust seems to be fully capable of doing low level things like drivers and kernels, so why would you choose less abstraction and safety instead of more?

In a time where C++ exists, C still gets used. C interop is even easier in C++ than Rust IIRC, so given the choice, C++ would get the nod much earlier I'd imagine.

That said, people use C because it forgoes abstractions and complications. Neither C++ nor Rust provide that experience. I think Go comes the closest, while being a bit nicer to work with overall.

The question is whether they should be foregoing those abstractions and complications.

C is not a language known for high security or reliability, nor is it known for being fast or easy to develop in, so by my guess based on vague anecdotal evidence, it seems that defaulting to the highest level of abstraction unless forced to do otherwise by some specific requirement is a better plan.

C and direct C replacements advertise simplicity, but if the simplicity doesn't buy you any reliability in practice, why bother with it?

C++ is way more complicated than Rust though.

C++ has more features than Rust but you can limit yourself pretty severely and use "simple" features to get far more safety and convenience than C without having to wrap your mind around Rust.

True for your new project from scratch when you already sucked up C++ such that you know what&when.

But at this point you know C++ pretty well (including all what you don't want to use, take a look at the CPP Core Guidelines), and using Rust is almost trivial, since Rust doesn't really introduce anything really new you wouldn't be already familiar with.

At least that was my experience.

> That said, people use C because it forgoes abstractions and complications. Neither C++ nor Rust provide that experience.

There's almost no C code you could write in an effort to "forego abstractions and complications" that isn't also C++.

Due to UNIX clones, and religious cargo cult on some embedded circles.

I’d say zig is closest C replacement.

I agree, and much easier than Rust to get going and then some. Other than playing with Nannou in Rust to 'get' the language, and the Rust book, I started a toy game in Zig without more than the skeleton put together here:

https://github.com/michal-z/zig-gamedev

I like Raylib, and there are bindings for most popular languages, but I like the minimalism I can start with fairly quickly in Zig. I tried Bevy for Rust, but it is a lot more involved, and Rust, so Zig it is for now.

For safety, and high-integrity software, I am sticking with SPARK2014. Rust will get there soon, but Ada/SPARK2014 have such a lead, maturity, and industry take up that I am putting Rust down for another year or more.

I kinda wish SPARK were mainstream. Ada kind of aims for the same things as Rust, but it's been around such a long time. It's amazing how long C has stayed around.

That's a bit debatable. Vlang is right there too. This would all be relative to what people are trying to do. Many people might really be looking for a C and C++ replacement, of which there are a number of viable alternatives (including good old Object Pascal), but then preferences and other factors makes things cloudy.

Rust is the one Torvalds seems most interested in, and I suspect that's a deciding factor.

Zig might be the most direct upgrade from C, but it seems like rust can mostly replace the entire concept of portable assembly, since it has zero cost abstractions.

For some cases that's fine, but go has terrible FFI, which make it unsuitable for some use cases, and being garbage collected makes it unsuitable for others.

Isn't there a danger that go will be cancelled?

I think Go has gained enough fans that it'll survive somehow, in some form, for a long time.

How can a programming language be cancelled?

By accusing it of discrimination against generic classes.

Yet discriminating unions are all fine and nobody speaks up.

Gold

Did you ever hear the tragedy of Perl the wise?

Lmfao

Stop providing security patches, for example.

I thought golang was open source. What am I missing?

You can't literally kill a FOSS project like you can with proprietary, but it can go away if nobody else wants to maintain it.

FOSS projects die all the time. You might want to write a patch here and there, but do you want to do all the DevOps, pay for hosting, manage testing, etc?

Maintaining a project kinda sucks.

Sure, but there are enough huge companies using Go (including organisations like banks for whom a couple of developer salaries are small change) that I’m sure someone would step up to maintain it.

Not at all, as long as Rob Pike is alive, I believe.

Rob Pike is 66 and the average male life expectancy in America is 76 years. Of course I wish him to live happily for many more years, but it would be presumptuous to expect him to work on Go for the rest of his life.

But although google has killed 264 projects so far [1], I believe that Go has too many dependents at Google and in industry to cancel. And even if it should happen anyway, the community will fork it.

[1] https://killedbygoogle.com/

Life expectancy of a 66 year old is 83.

I stand corrected. I also forgot to consider that Rob Pike is Canadian, which further improves his statistical chances.

Must be at least 10y more if you don’t use Java.

Yeah... Exactly. Look at all the stuff Bell Labs came out with in the 60s and 70s that still survives today, without their involvement. Go will live on regardless.