Other Zig lang programming language

S

sidetone

Zig seems like a near ideal combination of C++, D and Rust. Ziglang:
  • works around C
  • has many safety and checking features of Rust
  • syntax is C like and is simpler than C++ and Rust
  • made for portability
  • dependencies are simple: cmake, llvm12, ninja
  • MIT licensed
Hopefully lang/zig or something with its features becomes the successor to other mainstream programming languages. A feature this programming language lacks is macros. Why Zig When There is Already C++, D, and Rust?

https://hackaday.com/2021/10/05/need-a-new-programming-language-try-zig/ is where I first learned about it. https://ziglang.org/.

Zig relies on llvm, which is in C++. There is work being done for a zig compiler to compile it in its own language [https://kristoff.it/blog/zig-new-relationship-llvm/], and on a zig compiler in C.

An early (2019) mention of it on the forums:
stratact said:
At the moment, I'm playing around with the Zig programming language and trying to get it Tier 1 support for FreeBSD as best I can.
Click to expand...
Zig has been available in ports a few months before this.

(Port of the development version: lang/zig-devel)
 
Alain De Vos said:
And there is also,
Click to expand...
[Vlang]
Jose said:
Just another garbage-collected language.
Click to expand...
github.com

GitHub - peregrine-lang/Peregrine: A blazing fast language for the blazing fast world

A blazing fast language for the blazing fast world - GitHub - peregrine-lang/Peregrine: A blazing fast language for the blazing fast world
github.com github.com
Peregrine is a compiled language which its syntax is similar to Python. It's written in V, and it doesn't have a garbage collector. Peregrine is under the Mozilla Public License.

dev.to

The Peregrine programming language - A Python-like language that's as fast as C.

Hey guys! I'm Ethan, I'm one of 10 Peregrine developers. This post is gonna be about some updates...
dev.to dev.to
 
sidetone said:
[Vlang]
github.com

GitHub - peregrine-lang/Peregrine: A blazing fast language for the blazing fast world

A blazing fast language for the blazing fast world - GitHub - peregrine-lang/Peregrine: A blazing fast language for the blazing fast world
github.com github.com
Peregrine is a compiled language which its syntax is similar to Python. It's written in V, and it doesn't have a garbage collector. Peregrine is under the Mozilla Public License.

dev.to

The Peregrine programming language - A Python-like language that's as fast as C.

Hey guys! I'm Ethan, I'm one of 10 Peregrine developers. This post is gonna be about some updates...
dev.to dev.to
Click to expand...
Sounds like they're doing machine-generated C
You can consider it to be a superset of C which compiles to clean C. So valid C code is also valid Peregrine code (the language is named Peregrine).
Click to expand...
I've had to debug machine-generated code before. No thanks.
 
Jose said:
Sounds like they're doing machine-generated C

I've had to debug machine-generated code before. No thanks.
Click to expand...
This uses a transpiler similar to how Nim works by the sounds of it. I actually think it can be a great concept, it works well for C-ASM transformations in C compilers, but naturally some languages will carry more overhead than others, and translating that into C can be difficult.
 
drhowarddrfine said:
And every day you'll find programmers using the same languages everyone has used for the past 25 years as most of the new ones fade into obscurity.
Click to expand...
Yep! Sometimes they get picked up by a large organisation, used for a couple of years and then dumped when the next big thing comes by. Becoming someone's legacy mess in ten years ?. If they don't they become 'research' languages no one really uses, and at this point there are hundreds.
 
Something's going to replace C and C++. These are two languages which are often used together. The replacement may be Ziglang, or it likely won't be any of these languages. Whatever it is, it's going to use the strengths of them, and be C like. Better programming compatibility and better planned design will be benefits of it.

Julia is already the default compiled math and science programming language for these dedicated tasks. The reasons, because it's already designed for this, and what they've been looking for. Python is the default mathematical and scientific scripting langauage. If Python gets replaced, it will be by a scripting language with Julia's syntax, and it will endorsed by Julia prigrammers. It will only be different, because it's not compiled, and it will be slower, but for use on computers that aren't to math and science programming. It could also be a converted language from Julia that only converts into Python or other mathematical scripting language.

Swift will be the default MacOS programming language, because they sell those computers and i-products. This language will only be useful for programming, if there's at least one MacOS on a local or virtual network. Opensource computers can be used for writting programs, but at least one MacOS desktop will be required for these computers to be linked to on a LAN for Xcode, maybe for Cocoa, for submissions to Apple, and for checking/testing.

For a C and a C++ replacement for PC's, there's no clear winner yet among the current modern languages, or it hasn't been designed yet. It's not Rust, which may exist for some time, but it will take a few of Rust's strengths and yet be simpler and better designed. The language will eventually be backed by those who are mainstream of the C and C++, but this support may be 10 years away. If it's designed by them, it will come sooner.
 
You forgot to mention "go". And there is "nim" with almost no object-oriented support like C++.
For the moment i go for the compiled "crystal language", with for instance good bindings to sql & gtk libraries.
 
There's a few modern languages.

Go will be gaed (went). It's too niche, that it will be around for Android. Vlang also takes up Go's niche, except for not being Android specific. Android is also tailored to the Internet, so the language would also have to apply to web applications on PC, ios, or Mac.

For overall web applications that don't involve scripting nor Android, Go will be replaced by a subset or library of whichever language replaces C and C++. Go's replacement will be similar what C++ is to C: the comparison for C++ would be only what applies to web development, and the C comparision is for whatever eventually replaces C. The compiler for the subset will be on top of the main part of the language, and the webpart will instead be a subset of that language. A web based programming language would take parts from Vlang or Go, and from other languages for their strengths.
 
I think language developers are getting more on the right track compared to the decades wasted with VM languages in the past. Plan 9 is great but Alef and Limbo really sent everyone off on an unsustainable tangent!

For example native systems-level languages like Rust had not often come up before. Where it fails compared to C++ however is it can't consume C system headers directly without bindings (this drags in binding generators and thus language level package managers like crates.io which are a non-starter).

Google's Golang had a good approach of having a simple C compiler as part of the toolchain to almost natively consume C headers (with the preamble stuff). Unfortunately the language is garbage collected and thus a little naive as to use-case.

So whilst neither of these languages can compete with C++ (and ultimately C) in the industry. They are much closer than, yet another Java clone or some user-friendly interpreted language.

Bolt a C frontend onto Rust and drop that crates.io nonsense and I think it will be a serious contender. Unfortunately I just don't think we have that kind of "language expertise" to manage something like that anymore.

I also think Objective-C has some good lifespan left once Swift has run its course and disappeared.
 
Rust is the predecessor to what will be. Vlang or Ziglang are closer, and took strengths from Rust. These may or may not be it. They're getting closer.

Rust will likely be niche, until a better replacement comes about.

Whatever it is, it will be well written because of insight from these mainstream and modern programming languages. It will also be something that doesn't need two programming languages that overlap on purpose, except for a subset where there is a niche.

It won't matter if it needs LLVM and with C++, as in the future, it can be built on itself using its own compiler. This is especially for new languages that are a small startup. As long as it's built in itself with its own compiler by version 1.0 of that language.
 
sidetone said:
Vlang or Ziglang are closer, and took strengths from Rust. These may or may not be it. They're getting closer.
Click to expand...
Agreed. Looking at the Zig website:

Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box.
Click to expand...
They are starting to realize that augmenting and building upon C rather than trying to replace it is the only direction likely to yield lasting results.

In some ways, this is where Microsoft's impressive experience with EEE could have been a benefit to the industry. C++/clr was a fantastic approach to their .NET technology. If they pushed a little harder with it and released an open-source compiler for it, I could actually see .NET being a much stronger competitor to Java on non-consumer platforms.
 
sidetone said:
It will still have to replace C and C++ for it to be ideal or optimal.
Click to expand...
If Zig truly was a drop in compiler. Whether the C++ standards committee introduced some superfluous feature or if Zig did, I don't think it would make much difference. People would start to choose one "code snippet from StackOverflow" or the other. This might just muddy the water enough for it to start chipping into C++'s user-base.

Especially if the Zig snippet was shorter than C++24's then it would be onto a winner.

Of course C89-C99 purists would be a very hard bunch to win over. I don't think it will ever happen in our lifespan to be honest :)
 
Replacing C might be a non-starter anyway, as John Baldwin pointed out in a recent FreeBSD article:
"One of the things I work on is a project at Cambridge called CHERI (Capability Hardware Enhanced RISC Instructions) that allow us to push special memory safety into the processor itself, so that you're able to have a much safer version of C itself.

"And that will compose well with languages like Rust. It means we can take the safeness of the language and enforce it further down the stack than we currently can. So my personal bias is I think CHERI is going to be a better solution. FreeBSD is largely written in C and we were able to run the whole base system on CHERI. So we have all of that C code running as a safer C. I think that's the more likely future way to get memory-safe systems."

However Linux are actually experimenting with Rust kernel modules, so perhaps we will see more of an interest in languages being used in areas like device drivers.

I personally think a C replacement is partially missing the mark, C is good because of its small runtime, lack of contextual complexity (compared to C++), and power to directly interface with hardware components.

In user space not many applications are written in C these days (excluding GNOME) and replacements for C will be pointless here.
 
Cheri is a patch to cover for something not in C by design.

Rust had potential to replace C, but it is too complicated, and has its own package distribution. Crates needs to be specific to OS, and not be one set for various operating systems. If a language comes out, it's because it took strengths from mainstream and modern languages. Such a language will knock off Rust because it will be seen as better, before it can contend with C and C++. Ironically, it will be because of Rust and other languages that there will be strengths for a newer language to be modeled from.

C and C++ fans will also put up artificial resistance.

Zig could knock off C++ sooner, while staying with C. Maybe it could be something else modeled on Zig.
 
dlang was not a bad idea.
A good idea of dlang is that you have object-orientation but only just as much as you need for most cases.
But i could not replace C. I don't kow where the language went wrong.
And there is also the exotic "pony language"
 
Alain De Vos said:
A good idea of dlang is that you have object-orientation but only just as much as you need for most cases.
But i could not replace C. I don't kow where the language went wrong.
Click to expand...

Likely the Garbage Collector was an instant turn off. This causes too many problems with C API's because the GC can't perfectly scan raw heap or stack memory without more contextual information (is that chunk an integer, float, pointer or an array of chars?).

I think there are only a few D compilers around too. Not exactly the languages fault but it is unlikely developers want to tie themselves down to single vendors these days. That is extremely old fashioned behavior.
 
You must log in or register to reply here.
Back
Top