C# is a good example of a language that combines safety and productivity quite nicely, compared to e.g. JavaScript or Python. It's just about as expressive as those languages, albeit slightly more verbose than Python, yet its types provide more safety.

And that's just a start. I'm told that you don't need that much practice to get really productive with Haskell, while enjoying just about all kinds of safety that a language could provide.

In the case of M#, I believe that they want to add contract based programming to the core language to provide extra safety. That would mean that you can choose to use those features at those places where you think safety is very important, and choose to let them fly where productivity matters more.

I would not agree, that C# is nearly as productive as Python. Have you ever programmed in Python? I doubt that!

There's a blog post I've been meaning to write that challenges your belief about C#, but comparing C# to Ruby. The problem is that idiomatic C# looks like Java, even though the language and .NET library allows you to code like idiomatic Ruby and Python. It's just that most people don't naturally code C# that way, even though you can.

Could be. But there is the crux: A language should guide the programmers to good use of the possibilities of that language. If it does not, what worth are they?

You also must define "idiomatic Python" or "idiomatic C#" first. I would recommend, that you first write your post and than commence with the discussion.

> "safety" means a bit more than "remember to use ===

yes, it means "type safety", i.e. strong typing.

Including the compile-time safety net that c#, python, Java et all have over c - you never pass a value typed as "void * *"; and that they have over over JavaScript - your code never gets an untyped object that you just have to hope has the expected methods or properties.

I don't think you mean "python" in this list. Anyway, you're right most of the time, though you can end up in the same situation with "optimistic downcasting" (eg, get an Object as parameter, and downcast it to whatever it is you hope the concrete object is an instance of).

You may be right about python, I don't know it as well as the others.

> though you can end up in the same situation with "optimistic downcasting" (eg, get an Object as parameter

You can, though it doesn't happen much in practice. The complexity of the type systems (generics, interfaces, etc) are aimed in part at always allowing there to be a strong type.

Using void* in C/C++ is to explicitly disable type checking for something like byte buffer i/o. Another circumstance is in a broad interface such as a callback method that will pass along an argument. In the latter case a top-level interface like 'object' is essentially the same thing and in both languages you can create APIs that don't have these catch-alls. What's the wisdom behind wanting to be protected from this construct?

> have to hope

If you need hope, you're doing dynamic languages wrong.

If anything, I'd think that C#/Java would be "safer" than JavaScript simply because they provide compile time guarantees that JavaScript does not.

Yeah exactly. I can't count the number of times I ended up with a broken web page and unhelpful error messages when the cause turned out to be some type error.