My best litmus test these days is support for multidimensional arrays because it's always needed at some point in general purpose languages. CL and Ada had it right from the start while C++ needed C++23/26 to get std::mdspan and we still need to wrap it to pass the underlying/owned memory pool around (https://rosettacode.org/wiki/Multi-dimensional_array for more).
If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient.
Representing it as 1000 separate 1000-element arrays requires 1000 allocations, and pointer-chasing every time we move from one row to the next.
Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be.
They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array.
Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.
std::array<std::array<T, N>, M> data;
int data[M][N];
Edit:
For the stack at least. On the heap, you'd need to use a single std::vector<int> and do the indices manually, or use mdspan
It works fine in C though, or FORTRAN, or Ada, or ALGOL 60, ...
NVidia has pivoted to design CUDA hardware with focus on C++ back in , and seems to be doing quite well for them.
CppCon 2017: "Designing (New) C++ Hardware”
https://www.youtube.com/watch?v=86seb-iZCnI
They were also the ones sponsoring the ISO work on mdspan, while HPC research labs are pushing for linalg on top.
I would rather be using Ada today, but that isn't how the world moves.
I respect Ada but I would not want to use it. But I have a choice between C++ with hmdspan and C99's arrays, I choose C99 any time.
The std:mdspan proposal came from NVidia employees, alongside AMD and HPC research labs.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p00...
Yeah, I remember discussions on comp.lang.c calling programming with Ada, or even Modula-2, programming with straightjacket.
Meanwhile governments and national security bodies got another point of view.
You mean the C99 arrays Google paid the work to clean from the Linux kernel?
The kernel removed VLAs, I am more talking about vm types. But even for VLA - while I had a small role in that undertaking myself - I think it was a stupid mistake from a security point of view to remove VLAs from the kernel. Google pays for a lot of nonsense...
You can even use unconstrained arrays to provide the same functionality that Optional does in functional-programming, provided the element-type can be an element of an array:
-- Here we define an index-type with one value.
Subtype Boolean_Index is Boolean range True..True;
-- And here we define an array indexed by it, but can also have length 0.
Type Optional(Boolean_Index range <>) of Element;
If it fits on the stack, yes.
Typical code using MD-arrays is scientific code, and the data they manipulate generally do not fit there.
If you try to allocate 10MB on the stack, that's the dev problem if the program fails, it's not the compiler job to guesstimate whether something will fit there or not (and it's impossible anyway, the compiler can't know all the stack sizes a program will ever run on).
I would very much prefer scheme if the different implementations had a working standard. But I can't take my Chez-scheme code and throw it into Guile-scheme.
But pretty good chance I can take my ECL code and throw it into SBCL or LispWorks.
Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown".
The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better".
When I started building a Lisp-based machine learning framework, Guile seemed like the right choice because it provides GOOPS and generic functions, yet I still ended up with a lot of boilerplate to compensate for the lack of a strong type system.
Scheme feels to me like C is to C++: not ergonomic for large-scale application development. Go is one of those languages that has both minimalism and productivity.
-- Greenspun's tenth rule
He had some lack of conviction to scope it so narrowly.
Hopefully next they can add some error handling syntax and controls.
https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right
Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329
And besides Rust's high count of RFCs, there are things like async (I'm not complaining about it, but its an obvious large-scale "change"), module system changes, etc.
(To be clear, I like both languages a lot. But I wouldn't call them slow moving or right from the start.)
I like CL, but I can't agree that a stdlib that doesn't even have a string split function is batteries-included.
Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done.
The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have.
Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.