...is not IMHO. There needs to be a much smaller, simpler, "better C" language than Rust to replace C. Something like zig, or C2, even C99 almost feels like a new language.
I'm not convinced you can be much simpler than Rust while maintaining memory safety without GC (including reference counting) while still having standard heap allocation and deallocation. If you throw out memory safety, then sure, you can be simpler.
I'm looking forward to exploring this space in the next 1-2 release cycles of Zig. I have some ideas that will make debug and release-safe builds of zig code actually safe with regards to use-after-free and related memory issues.
The programmer will still be required to adhere to C-like manual memory semantics, with the difference being the language runtime catches safety mistakes. And then of course in bottlenecks the safety checks can be omitted.
If I accomplish my goal, the difference between safety/performance trade-off of Rust and Zig will be that Rust's release mode is both safe and fast, whereas Zig code has the simplicity but the programmer has to choose between performance and safety per scope.
I would still put Go into the "better C" language group because of its elegance and simplicity, even if it can't be used for all scenarios C can be used for (because of the GC).
To me at least, Rust looks like an obvious attempt to fix C++'s problems for large scale software development, but at the cost of being a big and complex language, similar in scope to C++. "Modern C" is a much simpler and elegant language, even though there's some decades old cruft, overall it remained a lot cleaner than C++ because there hasn't been so much stuff added in the first place which would be a burden now.
I sincerely can't fathom how Go can be considered a "better C". It's like comparing cars to sheet metal (or some better analogy).
Go is fundamentally incompatible in most contexts C would be your go-to. A moderately heavy runtime with both a scheduler and a GC unable to compile down to a ".so"? C++ and Rust can both do those things readily.
Languages aren't just syntax/semantics, they're ecosystems within ecosystems. They fill niches with particular their capabilities.
A more appropriate comparison is Go to Java. Distict approaches to "half batteries included" robust application and service development.
Not even. Golang lacks the expressiveness and vast standard library in Java (e.g. nothing even close to what java.util.concurrent has), not to mention the very diverse ecosystem, tunable high performance GCs, and management capabilities of the JVM.
I'm not sure they are. golang was force fitted into writing applications it was not meant for. It was made to be a C++ replacement, but it ended up anything but (basically ended up as a Python and NodeJS replacement).
I can see golang being useful in smaller tools that have some networking capability (and with GraalVM+AOT, Java fills in that niche as well). However, with anything slightly more complex (including REST APIs), and it falls way short. So it shouldn't be compared to Java.
Python/NodeJS/Java/Ruby/Go all have a solid presence in the "I need to spin up a REST/SOA/gRPC/glue service wherever" niche. They each have a range of performance, expression, resource optimality, and ecosystem tradeoffs; but they're all still heavyweights in this particular domain. They each have a presence in other "types" of programming but I think it's also fair to compare them within this one.
Go has a few things which make it especially nice in this field out of the box. Goroutines + channels + select help solve the same class of problems that made reactor patterns, work stealing fork-join pools, listenable/completable futures so popular in Java-land. Go's sockets give you epolling for free where we'd use Netty in Java land.
In fact, they each if those language ecosystems struggle with that class of problem in this field: Good kernel thread utilization in the presence of very mixed cpu + network I/O load. What's why they all have a handful of the same approaches: Ruby/Python/NodeJS all do the reverse proxy on top n processes of of libuv/gevent/whatever event loops (reactor pattern). Java and Go are actually similar in that they actually try to use threads well within a single process.
I say this as an obsessive Java fanboy. I'm jealous of a few Go things I can't have: Goroutines (green threads) and flatter struct+array memory allocations. I can't wait for Loom and Valhalla.
You said it yourself. Once Java gets those, there isn't really much reason left to use golang. And with probably better performance as well (I know the techempower benchmarks have their issues, but if you noticed, golang's standard lib is towards the bottom of the list).
C/Unix is generally largely credited to Brian Kernighan, Dennis Ritchie, and Ken Thompson. Although Ken Thompson did contribute to Go, he appears to have retired early in the life of the project (I can't find any contributions of his that don't pre-date Go's 1.0 release in 2011), and credit for Go instead tends to lean toward Rob Pike and Robert Griesemer, the former of whom worked at Bell Labs, but appears to have joined in time to have more of an impact on Plan 9 than on Unix. In particular Go bears very striking resemblance to Pike's two earlier languages, Limbo and Newsqueak.
https://tour.dlang.org/ is the D tour site, similar to the one for Go and some other languages nowadays; you can run some D example programs right from the site, without installing the language on your machine.
On my blog, I have a handful (12-13) of exploratory D programming posts, that may also be of interest. They explore various basic but interesting features of D via some simple D command-line programs:
This is a misrepresentation of the facts. Zig can use libcurl just as much as C can. Unlike other languages, zig does not need bindings to use C libraries. It's one of the main features.
The issue you linked is saying tht zig standard library will not introduce a dependency on libcurl.
Comments
C++ -> Rust
...is correct, but
C -> Rust
...is not IMHO. There needs to be a much smaller, simpler, "better C" language than Rust to replace C. Something like zig, or C2, even C99 almost feels like a new language.
PS: ...and I forgot the fairly obvious C -> Go :)
I'm not convinced you can be much simpler than Rust while maintaining memory safety without GC (including reference counting) while still having standard heap allocation and deallocation. If you throw out memory safety, then sure, you can be simpler.
I'm looking forward to exploring this space in the next 1-2 release cycles of Zig. I have some ideas that will make debug and release-safe builds of zig code actually safe with regards to use-after-free and related memory issues.
The programmer will still be required to adhere to C-like manual memory semantics, with the difference being the language runtime catches safety mistakes. And then of course in bottlenecks the safety checks can be omitted.
If I accomplish my goal, the difference between safety/performance trade-off of Rust and Zig will be that Rust's release mode is both safe and fast, whereas Zig code has the simplicity but the programmer has to choose between performance and safety per scope.
I'm not familiar with the C-family languages, but given that Go is GC, wouldn't Rust be a better "C 2.0"?
I would still put Go into the "better C" language group because of its elegance and simplicity, even if it can't be used for all scenarios C can be used for (because of the GC).
To me at least, Rust looks like an obvious attempt to fix C++'s problems for large scale software development, but at the cost of being a big and complex language, similar in scope to C++. "Modern C" is a much simpler and elegant language, even though there's some decades old cruft, overall it remained a lot cleaner than C++ because there hasn't been so much stuff added in the first place which would be a burden now.
I sincerely can't fathom how Go can be considered a "better C". It's like comparing cars to sheet metal (or some better analogy).
Go is fundamentally incompatible in most contexts C would be your go-to. A moderately heavy runtime with both a scheduler and a GC unable to compile down to a ".so"? C++ and Rust can both do those things readily.
Languages aren't just syntax/semantics, they're ecosystems within ecosystems. They fill niches with particular their capabilities.
A more appropriate comparison is Go to Java. Distict approaches to "half batteries included" robust application and service development.
Not even. Golang lacks the expressiveness and vast standard library in Java (e.g. nothing even close to what java.util.concurrent has), not to mention the very diverse ecosystem, tunable high performance GCs, and management capabilities of the JVM.
But those are all great, directly relevant, appropriate points of comparison. And they work because those two language operate in a similar niche.
I'm not sure they are. golang was force fitted into writing applications it was not meant for. It was made to be a C++ replacement, but it ended up anything but (basically ended up as a Python and NodeJS replacement).
I can see golang being useful in smaller tools that have some networking capability (and with GraalVM+AOT, Java fills in that niche as well). However, with anything slightly more complex (including REST APIs), and it falls way short. So it shouldn't be compared to Java.
I gotta agree to disagree with you on this.
Python/NodeJS/Java/Ruby/Go all have a solid presence in the "I need to spin up a REST/SOA/gRPC/glue service wherever" niche. They each have a range of performance, expression, resource optimality, and ecosystem tradeoffs; but they're all still heavyweights in this particular domain. They each have a presence in other "types" of programming but I think it's also fair to compare them within this one.
Go has a few things which make it especially nice in this field out of the box. Goroutines + channels + select help solve the same class of problems that made reactor patterns, work stealing fork-join pools, listenable/completable futures so popular in Java-land. Go's sockets give you epolling for free where we'd use Netty in Java land.
In fact, they each if those language ecosystems struggle with that class of problem in this field: Good kernel thread utilization in the presence of very mixed cpu + network I/O load. What's why they all have a handful of the same approaches: Ruby/Python/NodeJS all do the reverse proxy on top n processes of of libuv/gevent/whatever event loops (reactor pattern). Java and Go are actually similar in that they actually try to use threads well within a single process.
I say this as an obsessive Java fanboy. I'm jealous of a few Go things I can't have: Goroutines (green threads) and flatter struct+array memory allocations. I can't wait for Loom and Valhalla.
You said it yourself. Once Java gets those, there isn't really much reason left to use golang. And with probably better performance as well (I know the techempower benchmarks have their issues, but if you noticed, golang's standard lib is towards the bottom of the list).
The creators of C/Unix are the creators of Go.
C/Unix is generally largely credited to Brian Kernighan, Dennis Ritchie, and Ken Thompson. Although Ken Thompson did contribute to Go, he appears to have retired early in the life of the project (I can't find any contributions of his that don't pre-date Go's 1.0 release in 2011), and credit for Go instead tends to lean toward Rob Pike and Robert Griesemer, the former of whom worked at Bell Labs, but appears to have joined in time to have more of an impact on Plan 9 than on Unix. In particular Go bears very striking resemblance to Pike's two earlier languages, Limbo and Newsqueak.
From the GoPL (The Go Programming Language book, by Donovan and Kernighan), page xii, part of the genealogy is:
CSP (Hoare, 1978) -> Squeak (Cardelli & Pike, 1985) -> Newsqueak (Pike, 1989) -> Alef (Winterbottom, 1992) -> Go (Griesemer, Pike and Thompson, 2009).
Not at all.
Did anyone have experiences with ATS lang [1] as C replacement?
[1] http://www.ats-lang.org/
There's always "D as better C".
Right. For anyone who wants to get a feel for D:
https://dlang.org/ is the main site.
https://tour.dlang.org/ is the D tour site, similar to the one for Go and some other languages nowadays; you can run some D example programs right from the site, without installing the language on your machine.
On my blog, I have a handful (12-13) of exploratory D programming posts, that may also be of interest. They explore various basic but interesting features of D via some simple D command-line programs:
https://jugad2.blogspot.com/search/label/DLang
Particularly D's stripped down "better C" mode.
C -> Zig
I like Zig, but it doesnt even have a HTTP client yet:
https://github.com/ziglang/zig/issues/2007
granted neither does C, but C has cURL, and Zig doesnt (and wont) have cURL binding:
https://github.com/ziglang/zig/issues/2056
This is a misrepresentation of the facts. Zig can use libcurl just as much as C can. Unlike other languages, zig does not need bindings to use C libraries. It's one of the main features.
The issue you linked is saying tht zig standard library will not introduce a dependency on libcurl.
Andy, you are a really smart and talented person
but surely you know the difference between FFI and binding?
They are not the same thing, and Zig doesnt (and wont, according to you) have cURL binding.