51–60 of 93 posts
> Andrei Alexandrescu (creator of D) Andrei didn't create D; he's been influential in it, especially w.r.t. D's metaprogramming story, but the language was created and is primarily maintained by Walter Bright.
D1 was created by Walter Bright, but D2 was primarily created by both Walter Bright and Andrei Alexandrescu.
Earlier quoted context omitted.
Have you looked at Chapel?
Not yet, thanks. How does it compare to Julia?
Chapel is a strongly typed language designed from the ground up to replace C++ and Fortran for HPC programming in cluster environments, while removing the typical unsafe features from C and C++.
Initially designed by Cray, Intel has also given an helping hand.
My experience is only from language geek point of view, reading the papers.
Chapel Implementers and Users Workshop 2018 papers
A systems programming language can run on bare hardware by itself, or nearly so. It is acceptable to require a very small amount of assembly code, for example to implement something like memcpy or bcopy, or to provide atomic operations. A language is disqualified if it requires an OS or if it requires code written in a different non-assembly language. Cheating, by adding that as a huge (impractical) amount of assembl…
So then C is cheating by your definition, because it is impossible to implement ANSI C standard library without using Assembly or compiler extensions.
C is not cheating, the compiler assumes you work on user level stuff. Want to write bare metal (kernel) then you need to tell the compiler.
Irrespective of language and framework, if the code needs to be aware of underlying hardware then it is systems programming. ex. kernel code, user-space drivers, databases, portions of cloud or server code which need to be hardware aware, etc. What golang targets, I think, should be more of middleware or service-level programming, whether its containers or servers.
Alan Perlis has a thoughtful way of expressing this: “a programming language is low level when its programs require attention to the irrelevant.” At first I thought it was poking fun; now I see it as a comment about what is relevant at a given level of abstraction.
When discussing the suitability of different programming languages I always point to the problem at hand and identifying the abstraction level the problem is at. What your problem requires you to care about and pay attention to gives this.
Ideally, solving your problem would be a one-liner in an already existing DSL created for your specific problem (domain). In reality, this rarely happens and you must have your pick beteeen everything from niche DSL:s to assembly, but the key really is identifying that problem abstraction level.
I work in a mainly C/JS shop whereas I privately prefer Rust/ReasonML. Rust would be a great fit at work, but Go would also work nicely for tons of things we do. Alas, the inertia of organizations.
But I disagree with this:
> Companies like Dropbox were able to build surprisingly large and scalable systems on just Python.
Many of Dropbox’s services are written in Go, and Magic Pocket is written (partly, at least) in Rust. Earlier in their development, Dropbox relied on S3, which is obviously not in Python.
Fundamentally, I think the important part of the “production” aspect of “systems programming” is that it’ll be used a lot. That’s what drives the requirement for efficiency: if you’re 10-100x less efficient, someone else will be more cost effective / solve bigger problems.
As an additional example, GitHub was written in Ruby, but that’s fine because the underlying Git and filesystem manipulation is all in C. The same thing is sort of true of Facebook’s world of PHP: PHP is mostly a wrapper around C libraries. Until it got complex enough that they rewrote the language.
tl;dr: I don’t think systems programming needs to be “low level”, but production systems do need to be efficient. More powerful computing just moves that further to the right!
System programming is definitely a bit overloaded these days though I believe it is now widely understood to be languages like C/C++ that can be used for OS, kernel, and embedded development. I would agree though that the language ecosystem is shifting a lot in the last few years. IMHO there are now a few languages that are becoming proper full stack languages in the sense that they scale from embedded all the way to…
Earlier quoted context omitted.
Alan Perlis has a thoughtful way of expressing this: “a programming language is low level when its programs require attention to the irrelevant.” At first I thought it was poking fun; now I see it as a comment about what is relevant at a given level of abstraction.
I like that line of thinking. When discussing the suitability of different programming languages I always point to the problem at hand and identifying the abstraction level the problem is at. What your problem requires you to care about and pay attention to gives this. Ideally, solving your problem would be a one-liner in an already existing DSL created for your specific problem (domain). In reality, this rarely happ…
I like thinking about the practice of programming as creating a DSL in a language to solve your specific problem.
Earlier quoted context omitted.
Not yet, thanks. How does it compare to Julia?
Different goals. Chapel is a strongly typed language designed from the ground up to replace C++ and Fortran for HPC programming in cluster environments, while removing the typical unsafe features from C and C++. Initially designed by Cray, Intel has also given an helping hand. My experience is only from language geek point of view, reading the papers. Chapel Implementers and Users Workshop 2018 papers https://chapel-…
sounds like Julia to me ...
> ... in cluster environments
this is where it may be differentiating itself, AFAIK Julia has not been very focused on clustering from start, but I'm assuming it's now getting better.
> You should be able to forge a number into a pointer, since that’s how hardware works. It's a C-centric view of the world and I wonder what old school FORTRAN77 people or lispers would think of this. Anyway, I think the right to do this should be a privilege of the compiler. As soon as you claim this right, you abandon all possible support she can give you in battling all kinds of silly mistakes.
I don’t know. Seems like a lot of kernels do extra things so driver writers can write fairly normal looking C and produce fairly safe drivers without just arbitrarily assigning pointers addresses from numbers. And even if you use C as your comparison, those helpers will often be written with some assembly language (read C isn’t completely good enough for the task all by itself) I don’t know of it existing but a kernel in go with ref counting GC and a handful of cgo primitives seems very possible and maybe even delightful to work on.