[SBArbeit]

Now that I'm a PowerShell expert, the idea of dropping down to a *nix shell that only knows how to pass text around is appalling. Like, "the 1970's called, they want their shell back" kind-of appalling. And so what if it's a few extra characters to script stuff in it? I can make aliases for whatever I want, there's tab-completion for everything, everything is self-discoverable, there's Get-Help and Get-Command (alias gcm) to find everything that's available to me, and, by the way, it's all just a language projection on top of .NET... it's all great.

It's like any other language... until you bite the bullet and really learn it, you don't know. And the idea that Windows isn't built for scripting is from the 1990's. For the last 15 years, there's (almost) nothing that Microsoft ships that can't be automated/scripted/controlled from a command-line.

[lottin]

C is from the 1970's. Lisp from the 1950's. Just because something is old it doesn't mean it's bad. And likewise, new doesn't imply better.

[IshKebab]

Well, C is pretty bad, compared to modern languages. It's full of buffer overflows, undefined behaviour, etc. Just because something is popular doesn't mean it is well designed.

[jstimpfle]

Man, will this sentiment ever die... You know Stroustroup, there are only two kinds of languages: The ones everybody bitches about and the ones nobody uses.

Please guys, demonstrate a better way. Make that better language.

There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share". Man, these people make tons of scripting and DDL languages to get their game done. If they knew a better (more practical) approach than using C in the critical places, they would do it.

Yes, you get buffer overflows and memory management bugs. Much more so if you are a beginner, but also if you're very experienced. But people just haven't found a practical alternative.

How would you even be able to define what a valid buffer region is, if so many functions are basically custom allocators, declaring a certain sub-slice of the buffer they were given (taking pointers / indices), and handing it to the next function? It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping.

[IshKebab]

> Make that better language.

Rust, Go, Swift, etc. Even C++.

> There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share".

The only thing that is still pretty much all C is kernels. Game engines are usually C++ (a much safer language). Databases are written in all sorts of languages. Sure the big old ones are C or C++, but that's because they are old!

> But people just haven't found a practical alternative.

They have. Garbage collection works in a lot of cases. Rust has its lifetime & borrowing system. C++ has proper smart pointers (finally).

> It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping.

I take it you haven't used Go. It has slices. They work fine. No buffer overflows.

[jstimpfle]

> Rust, Go, Swift, etc. Even C++.

If you carefully read my post, you noticed C here means actually C(++). And a great majority of developers from these domains actually write C++ like this: C(++).

Rust, Go, Swift. Show me the serious kernels, databases, AAA games. Rust hasn't even descended the hype train.

Garbage collection is a bit like exceptions. It works for some cases, but not for serious engineering of long-lived applications. If you have ever written a Java application with millions of little objects, you know what I mean. For starters, we can not even afford to pay for the extra memory overhead that comes with each object. For the advanced, at some point we want the application to do exactly that: advance, instead of doing GC only.

> I take it you haven't used Go. It has slices. They work fine. No buffer overflows.

These slices all come with the (huge) overhead of adding a reference to the original runtime object, and on top of that each array access is checked. Correct?

[burntsushi]

> but not for serious engineering of long-lived applications

Oh come on. Does Lucene (or Solr or Elasticsearch built on top of it) not qualify as serious engineering? Elasticsearch is quite successful, and is indeed intended to be used a long-lived application!

Does this mean that the likes of Lucene don't run into GC issues? Of course not. I've certainly diagnosed problems in Elasticsearch related to GC (which, more often then not, is a symptom of something else going wrong), but saying it's not qualified for "serious engineering" is just patently ridiculous.

And that's only one example. There are loads more!

> These slices all come with the (huge) overhead of adding a reference to the original runtime object

Huh? This is the representation of a slice: https://golang.org/pkg/reflect/#SliceHeader --- It's pretty standard for a dynamically growable region of memory.

[metaobject]

Maybe it's just me, but the capitalization of the commands is really annoying.

[gruez]

why? it's all case insensitive anyways. plus tab completion puts in the correct case.

[sigsergv]

Perhaps because one need to hold shift too often.

[detaro]

again, it is case insensitive, no need to use the shift key.