I think a large part of the problem was that standard Pascal wasn't really that great of a language other than for teaching. It only became useful when heavily extended as Turbo Pascal had done. Turbo Pascal was very successful and eventually morphed into Delphi which was also successful.

In the meantime standard K&R C was ubiquitous and anyone taking a CS degree would likely have learnt and used it. C's "close to the metal" approach was a good fit for the under-powered CPUs of the day.

"What killed Pascal?"

Where I worked, it was nothing in particular about the language (or at least the variant we used) itself. What happened was exactly what another comment said, quote:

"And then Unix happened. Every Unix system had a C compiler; and C ate Pascal's lunch. C was the cross-platform language of its day, more so than any other language that was available. And, from my point of view at the time, that's what killed Pascal."

For us, is was about a major product we had which we re-hosted to newer, much faster hardware. The original system was mostly written in Pascal, on a minicomputer. Or Fortran-77, for a (math-heavy) subset. There was nothing problematic with the Pascal code we used, but we couldn't use that on the the SGI hardware we moved to so we decided to port everything to MIPS-C, actually ANSI C (we limited features to the latter). Even the Fortran code. And from then on, everything we wrote was mostly in C, until C++ etc. became a thing. No new Pascal code was written on Unix.

It evolved in two directions. On the one side, Turbo Pascal which constantly updated the language, added OOP later on. On the other side the development of the successors by Wirth, like Modula and Oberon. All of those were quite popular here in Europe. But especially the US rather trended into the direction of C and later on C++. C was percieved a "fast" language, though there were good performing implementations of the Pascal family too. Fun fact: on the Amiga, the Modula-2 implementation even performed better than the C compilers awailable back then.

On this matter, it is especially interesting to look at Go. While it takes the syntax mostly from C, it actually draws most features from the Wirth family of languages. Which is no surprise as one of the co-creators, Robert Griesemer worked together with Wirth in the past.

Oddly enough, I bet the farm on Pascal. I learned Pascal in high school after taking a course in BASIC, and I read about C -- maybe in Byte Magazine. To me, Pascal seemed much more elegant and readable, and pointer arithmetic seemed like a bug factory. I was supremely confident, like any teenager, that I knew my ** and that Pascal would win out over C.

The most popular implementation (by Borland) being closed source and unavailable on Linux during the rise of the FOSS and Linux revolution.

the way i see it, it was competing with C# and Java, both pushed by large orgs, and in the open source world, it was C, C++ or Python and Ruby

So i think for most devs, the alternatives made more sense

I think the main reason, pascal still get some mentions, is that even today, creating a desktop UI is not as easy as it should be, most RAD tools are commercial and open source

I think where Pascal still stand a chance today, is to be used to create a GUI RAD tools for Line of Business application, this area, even today have no clear winner

Also, even for that domain i would wish for Tcl/Tk, if Tcl makes a serious come back, it should be it

Pascal is a great easy language with strong typing. It was great at protecting you from yourself. It was a great language for students. It had strong typing that was very solid. You could not easily subvert it. (This is the original, standard Pascal; I'll talk about Turbo later.)

You couldn't even run past the end of an array, because the size of an array was part of the type. You couldn't even compile code that tried to access past the end of an array.

But that was a huge problem. The type system was too strict. Take those arrays, for example. You could not have a variable-sized array, because the size was part of the type, so there was no possible type for that array to have. You literally could not talk about such a thing.

This bit me, for example, where we we trying to do a numerical simulation of EM wave interference patterns on a 2D grid, with the user specifying the size of the grid. We literally were not allowed to create a 2D array with size determined at runtime. So the initial implementation simulated it with a doubly-linked list of allocated points. That solved the type issue, but it had at least two negative results. First, in a node, the next and previous links took as much memory as the actual node data, so it was very memory inefficient. Second, having to walk a pointer to N nodes further to refer to the point directly below you on the grid was both inefficient and error-prone.

We finally improved it by allocating a fixed-sized 2D grid that was as big as we could allocate (we knew at compile time how much memory was available on the machine we were running on) and only using the part that was within the bounds the user specified, but that was also wasteful.

The runtime gave you certain functions that would deal with variable-length strings, but if you found those functions inadequate, you could not implement your own, because you could not talk about variable-length arrays.

And it wasn't just arrays. You could write only the things that fit within Wirth's vision of what you should be allowed to write. Writing your own memory allocator? What's going to be the returned type? Writing to memory-mapped hardware? No way, not allowed.

To write to memory-mapped hardware, we literally had to call a subroutine written in assembly - at which point, we lost all type safety. In the name of the language being as safe as possible, we were forced to do something completely unsafe in order to be able to work at all. (That lack of type safety caused a crash when something changed.)

That was the original Pascal. Everyone who used it seriously saw that it was inadequate for real work, so it got extended in order to be usable. But the problem is that everyone extended it in different ways. Turbo Pascal had extensions, but they weren't going to compile on other compilers - at least not until Turbo became the dominant compiler, which took a while. Code written using other compiler extensions would not compile on Turbo unless Turbo adopted their extensions - which never happened, at least so far as I know. You could not write portable software that did anything outside the standard Pascal straightjacket. (Of course, if you're writing to memory-mapped I/O, you're probably not portable to any other hardware anyway...)

For a more extended discussion of this, read "Why Pascal Is Not My Favorite Programming Language" (https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...). It's by Brian Kernighan (yes, that Kernighan), but it's not a hit piece. He wrote a book called "Software Tools" with P. J. Plaugher, in Ratfor (a Fortran pre-processor). After Pascal came out, he re-wrote the book using Pascal, and then he wondered why it was so hard. Pascal should have been far easier to write in that Ratfor. Why wasn't it? The article is trying to answer that question. It's still an interesting read if you want to know why Pascal didn't really catch on.