ZIG programming language.

And that will be the last reason I need to ignore Zig.
Heh.

I certainly feel that language based package managers are a bandage for a broken C-interop system. If Zig does succeed at having acceptable access to C without complex bindings/codegen, then I think *not* having (or needing) a language based package manager is a considerable selling point (and a badge of honor).
 
But what has zig-language that nim-language or crystal-language has not ?
This is a bit apples and oranges, but I'll give it a shot. Nim and Crystal approach the problem differently than Zig does, so they aren't directly comparable beyond they compile to native code.

A big difference that Zig has with other systems langs is that Zig's standard library data structures all require an Allocator param as part of the constructor. This means you can use different memory allocations for different parts of your code and optimize for each use case. This also is nice when testing because the testing allocator will detect memory leaks.

zigcc can be used as a C compiler and is very helpful for doing cross compilation. Several projects use Zig for this exact purpose.

Nim transpiles to C or C++, Zig compiles to native code directly via LLVM. Not that different, but different internals.

Crystal bakes in a runtime which is how it does concurrency with fibers. Zig has a minimal runtime like C, which is nice if you want to use Zig to write a runtime like Roc does.
 
Heh.

I certainly feel that language based package managers are a bandage for a broken C-interop system. If Zig does succeed at having acceptable access to C without complex bindings/codegen, then I think *not* having (or needing) a language based package manager is a considerable selling point (and a badge of honor).
I'm not sure how it is going to exactly end up, but Andrew gave a talk on this exact topic recently.

Stay Together For The Kids - Andrew Kelley - Software You Can Love 2022

The gist is that there are different needs between language package managers and distro package managers. It is nice to see he is at least trying to balance the concerns. Whereas Cargo simply makes everyone work around it.

Right now a lot of the Zig community is simply using git submodules, which is ... okay.
 
A big benefit is that Zig as a language isn't too different than C so you don't have to constantly fight different abstractions.
This 'big benefit' is something that D also has.

I think D has at least two advantages over C++ and Rust.
1. higher productivity
2. higher performance of the final app

D can give you productivity unheard of in C++-land if you are willing to pay the high-price of arguing with everyone about why do you use D.

D performance:
D's compiler dmd is still far ahead of all its competition especially when it comes to default build (standard compilation) performance.

Why program in D

Should one choose C over D for maximum performance?

My answer is an emphatic no, and I bring as evidence the fact that warp is significantly faster than the
preprocessor in my own older Digital Mars C/C++ compiler tool chain, which was already the fastest on the
market, and on which I've spared no effort optimizing and tuning over months and years. Modern compiler
technology working in concert with D language fundamentals (white-box templates, simple object models) takes
high-level compositions of templated code and optimizes it down to code that is virtually indistinguishable
from what a C programmer would write for maximum efficiency.

The neat thing about D is that by separating the code into ranges and algorithms, it becomes easy to keep
trying different range implementations and different algorithms. I tried all sorts of things. Like breeding
racehorses, I kept the profile winners and culled the losers, step by step, through the code. That would have
been a lot more difficult to do in other languages.


Zig is also significantly less productive than D.
In terms of productivity, D is very similar to Ruby and Python.

Serpent OS has already chosen D and this is probably a good idea for FreeBSD as well.
We're amazingly productive when using D lang.
This is not a "Rust vs D" flamebait post - some people are extraordinarily gifted with Rust. I'm not one of those people, and I firmly believe that D is highly underrated and misunderstood. In recent times D has been going from strength to strength, demonstrating itself as a capable systems programming language and adapting to developer requirements. We'd like to be a part of that future.
 
So this thread lasted 10 days, till just now, and FreeBSD did not replace C with Zig. Neither did Google, Microsoft or Apple. They didn't use D either. What went wrong? :rolleyes:
 
The "end-of-FreeBSD-if-no-lts-thread" and the "C/C++-will-be-replaced-by-X/Y/Z-in-a-year-at-most-thread".
I've seen them both for almost a decade now. Neither became true, nor do any of them look more likely to than it ever were to me.
Isn't about time to get over it?
 
The "end-of-FreeBSD-if-no-lts-thread" and the "C/C++-will-be-replaced-by-X/Y/Z-in-a-year-at-most-thread".
I've seen them both for almost a decade now. Neither became true, nor do any of them look more likely to than it ever were to me.
Isn't about time to get over it?
If you analyze the last 20 years, it is just clear that there will probably be a successor to C, C++, or both in the future. C has dropped from 20.77% to 13.35%.
C++ once had over 16% popularity, and in Dec 2017 it had 4.7% popularity.
C++ was in a strong trend of extinction 6 years ago and it could have died out because D is an improvement in almost all areas (and a huge improvement in some areas).
I think C++ is a typical programming language for companies that have monopolies in their market. They no longer innovate.
What you see is that once Microsoft, Google, Facebook, AWS, Oracle and Apple have become dominant, innovation in computer science has greatly diminished.
In the late 80s, programming languages were spawning one each month on average, and so far, about 9,000 programming languages have been developed. But strangely, in the past three years, only three notable languages have come up, namely — C++20, Microsoft Power Fx, and Carbon. That makes the average nosedive to one language a year from one a month!
You're facing several problems right now because of these companies. Google is the market leader and doesn't even bother to provide updates for many smartphones for more than 2 years.
Microsoft do little else than degrade the same games and then offer them for a very high price, abuse privacy and offer paid software that is many times less energy efficient than other (free) software. Facebook haven't really known how to proceed with their company for years and have invested a lot of money in some of the most ridiculous projects ever.
Oracle is (technologically) completely obsolete by PostgreSQL, Dragonfly Data Store, MongoDB, Redis etc.
There are also thousands of programmers in these companies, so you can guess that these programmers are usually no longer brilliant minds if they are trapped day after day in these types of companies.
Now it has pulled the same trick again—twice. Using a new version of AlphaZero called AlphaDev, the UK-based firm (recently renamed Google DeepMind after a merge with its sister company’s AI lab in April) has discovered a way to sort items in a list up to 70% faster than the best existing method.
What I understand from this is that the numerous group of C++ programmers will not have discovered in 2023 how to sort items efficiently.
I think there are strong threats to C++ right now such as D, jai and Mojo.
The team claims it is 35000X faster than Python.
Mojo may be the biggest programming language advance in decades
Porting 58000 lines of D and C++ to jai, Part 0: Why and How
As the AI industry booms, what toll will it take on the environment?
A Computer Scientist Breaks Down Generative AI’s Hefty Carbon Footprint
We are currently in a moment where hardware has become little more efficient in recent decades, but AI adoption will continue to increase rapidly for several more decades.
C++ requires a lot of energy for compilation, which D and jai, for example, do not require, so it can be a good idea anyway to replace C++ with a language that compiles faster.

C++ will remain popular as long as big tech companies are allowed to use completely pointless 'solutions' such as offsets and are not forced to take the most basic measures.
 
You know there is nothing stopping you alternative language programmers from building a clone of the FreeBSD Operating System in your favorite language.
 
The only programming language mentioned here that I'm interested to learn is D.
Even so, I'm still skeptical about this "C++ falling in misuse" paranoia. Nor do I make sense of it as a C and C++ programmer.
Many points supposed to be weak are arguably so.

People worry too much with the so-called "end-user" these days. Following that logic, we'd better use Microsoft Windows. "UI/UX", yadda-yadda...

It reminds me of how I live a sedentary lifee. Now I have this childhood friend, who teaches Brazilian Jiu-Jitsu for competition. And he's as healthy as can. As for myself, I told you already. Knowing what would be better didn't change an inch, granted, but at least I know what would be better. Even If I do the opposite.

I spent several years in the College, obtaining a major BSc in Computer Science. This friend of mine is as clueless about CS as I am about Phys. Ed. C'Est la vie. And since hear, in this forum, we are in majority qualified scientists, engineers, and technicians, I see no need to present arguments based on how X/Y/Z are easier to operate, even to your average layman. Likewise, many people already explained how possible it is to perform maintenance in so-called "production systems", and keep them up-to-date with our current distribution model without need for LTS

Plus, I noticed how things like "popularity" and "market share" sometimes sounds as if were either the only that matters or that which matters most. Allow me to disagree. Maybe I take this stance because that's what I learned, but what should matter most are features like performance (well-measured, I don't trust benchmarks for one), security, fault tolerance...

Both C and C++ are still a couple of microseconds ahead, especially C. I use C++ to work, for its plethora of resources combined with the freedom for even low level operating, if you so desire. And here there's a good question: aside from D, do any of ZIG, Nim, or Crystal, or even Python, Perl or Ruby, offer those kind of features like C and C++?

In the end of the day, "UI/UX" is exactly like my overweight: I'm well-aware of it, even have a good friend wanting to lend me a hand, still life remains sedentary at least for the time being. The point here being: I'm not trying to sell it is something good I shoud be proud of. I'm here saying the bare truth: a sedentary life is not good --- it could even be dangerous! Then again, Computer Scientists are expected not to fret just because operating FreeBSD and programming in C or C++ ain't, perhaps, the easiest learning curve out there.

The way I see it, FreeBSD is not perfect but have way too many qualities which overwhelms its flaws, the same holding for the C and C++ "imbroglio". I see both cases as whining of some people, nothing deserving more attention than what was already dispensed.
 
Other languages can be interesting also. I learned D & Kotlin & F# & Ocaml.
C++ tends to be overcomplicated so languages like D, nim , crystal have a light implementation of object orientation.
 
When you deal with languages that aren't C, you end up having to deal with bindings. I try to avoid that like the plague.

C++ is the closest to solving the issue by being a very close superset. Along with Objective-C and D, I think that is pretty much it.

The thing about commonly cited binding generators (i.e Rust bindgen, Swig) is that they only do 90% of the work and then you are left with a mess.

A good example is the Swift community for ages saying that it has "direct access to C via its generation approach". I disagreed and also Apple *itself* decided to only recently bring out a better approach (i.e this). And *now* the Swift fans say that they have "direct access to C via its generation approach". I still disagree. You end up spending more time writing glue than actually solving the problem.

Bolt a C front-end onto the Rust compiler, shove half of the Rust community down a deep hole, develop around 10 more standardized implementations and then you might have a serious contender to C.

That said, I do like Lua. But admittedly it is more of a config file parser than a language where binding all the different config options is expected if you keep in this mindset.

</opinionated_ramble>
 
Bindings are important. I had very difficulty using Kotlin together with a mariadb database.
Bye the way D-language has very good bindings to GTK3. It works like a charm.
FYI, https://gtkdcoding.com/
a Programming language is part of an eco-system.
 
I am currently investigating several languages for calling C libraries. So far, Go is the only other language I've tried that includes C headers directly and doesn't require you to re-define the headers in the language (aka bindings).

I have two toy libraries right now - one that prints "Hello, $lang!" and another that upcases a string in place. The next things to explore are how easy it is to inadvertently produce memory leaks [1], concurrency, and overall ergonomics.

There's still plenty of work to do, so I am reserving judgment for the time being. My general hunch is that there's not a whole lot of difference among the languages, at least when it comes to calling C.

[1] According to cgo docs, if you allocate a C string, you have to free it also. My test shows that the garbage collector frees that memory. It's entirely possible that I'm just doing it wrong.
 
I recently programmed nim-language I must say it has some good ideas. And the vscode-language-server works fine.
Julia actually started development 4 years later than Nim, yet Julia is currently much more popular according to both Stack Overflow and GitHub.
Nim usually has better performance than Julia: https://gist.github.com/sdwfrost/7c660322c6c33961297a826df4cbc30d
My impression is also that Nim can be used for many more purposes than Julia.
Julia has its specific niche (exploration, scientific computing, AI and data science) and Nim does not collide with this niche.
Nim is more of a general language by far. How do you actually explain that Nim has remained less popular than Julia?

Perhaps Nim does not have a company behind it, and it is mainly the commercial tactics, education and marketing that make a programming language popular?
I really think that this determines more than 90% of the popularity of a programming language in reality.
Unfortunately, what the big companies impose is usually simply adopted by all the rest of the programmers in most companies. Kind of a bandwagon effect.

But it is clear that a programming language like Zig has a lot of competition from the following languages:
1. jai
2. Nim
3. D
4. Crystal
Future:
5. Red language
6. Mojo

Zig does have an advantage over other languages that has been little or not mentioned in this discussion:
Zig is better at using C libraries than C is at using C libraries.

Purely in terms of syntax and expressiveness, the Red language is on a different level than all other 'high-performance programming languages'.
Of course it is not easy to make Rebol perfectly multi-threaded and to approach C execution speeds.
But the Red language is by far my favorite of all programming languages in terms of concept. It seems as if this language is still in full development at the moment:
 
Zig does have an advantage over other languages that has been little or not mentioned in this discussion:
Zig is better at using C libraries than C is at using C libraries.
I hear this a lot. But looking through the docs, I just don't see how all that boilerplate could be easier:

https://ziglearn.org/chapter-4/

For example this wrapping example may look easier than i.e Java JNI but it is still a massive waste of time when you could just use C or C++ and avoid this time consuming, error prone step entirely. I must be missing something because Zig does embed a C compiler in it, it just doesn't seem to use it well?

I am currently investigating several languages for calling C libraries. So far, Go is the only other language I've tried that includes C headers directly and doesn't require you to re-define the headers in the language (aka bindings).
Go (cgo) with its "pramble" stuff is very very close. It is probably the only "non-C" language that is approaching it from the correct angle (i.e bolting a C compiler onto the language).

Where bindings tend to still appear (though more lightly than other languages) is to wrap structures (i.e in case of non-opaque APIs) and to integrate with its garbage collector.
 
Back
Top