Hacker News Reader

Comment by dvanduzer | Hacker News Reader

The keyword here is "Enterprise" Python. The Enterprise is a place where you have "decision makers" which are often people who don't understand type systems, and have absolutely no incentive to do so.

Paypal is a large organization which needs to hire Python programmers. Everyone reading this now has a reminder that Python is popular at Paypal. We also know that endless PLT arguments are probably not common in the workplace.

View on HN

Fortunately, there are other large organisations employing decision-makers which understand the business value of type systems.

Apple: https://developer.apple.com/swift

Facebook: http://flowtype.org + http://hacklang.org + http://hhvm.com

Microsoft: http://fsharp.org + https://haskell.org + http://typescriptlang.org

Mozilla: http://rust-lang.org

Google: The jury is out on this one.

Can you clarify what you mean about Google?

Most likely a quip about how Go's type system is uninspiring.

Ironically, Go being uninspiring is its greatest strength.

For one, both Dart and Go repeat Hoare’s Billion Dollar Mistake, by admitting null references instead of implementing option types.

In a previous HN discussion, I wrote to one of the Go designers:

> I disagree with you on the relative complexity of type systems, and, as someone passionate about my craft, I despair Go is merely good not great, due to what appears to be uninformed design decisions.

> You may prefer to write in Go, but you don't work in a vacuum. Your creation is out there, gaining mindshare, and propagating mistakes made half a century ago. As a language designer, you have the power to shape human thought for years to come, and the responsibility to remain intellectually honest. This is the meaning of Hoare's apology. He didn't know better. You have no such excuse.

https://news.ycombinator.com/item?id=5822545

Well said. Your comment on that link was quite insightful as well. I'll quote it here below:

"So, Go has message passing. Just like Erlang, since 1986.

Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake.

But it's not enough to scorn the industry; Go's designers also look down their noses at academia.

A modern, ML-derived static type system? Generics, which would enable the unwashed mashes to write their own `append`? Ain't nobody got time for that — wait, what? Oh, Rust does?

Go's tooling is fantastic, and its pragmatism is commendable, but ignoring the last 30 years of programming language research is not."

I think in both cases, they are allowing pragmatism to win out over correctness. The underlying systems that Dart & Go try to interface with embrace NULL with a kind of oblivious joy that can't be replicated.

I find the idea that optionals aren't pragmatic pretty bizarre. Of all the features that "advanced" type systems give you, optionals are some of the most straightforward. I still haven't heard a convincing argument for why they should not be in Go (e.g., someone pointed out that all types in Go have a default value, but there is a very obvious candidate for a default value for optionals--None; "in practice these issues don't come up"--doesn't that just mean people don't use null much? Why allow it to inhabit every type, then?).

Anyway, neither Dart nor Go is particularly "close to the hardware" as they both have fairly substantial runtimes. We're not talking about a macro assembler here, we're talking about a typed programming language. What the compiler does under the hood is largely irrelevant in any language that doesn't make a distinction between register, stack, and heap allocation.

It’s an example of the “New Jersey approach” to programming language design.

> Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

http://www.jwz.org/doc/worse-is-better.html

If the underlying interface (JavaScript or POSIX as the case may be) is using NULL's up the wazoo, then you need a way to represent that. You can try to represent it as optionals, but that creates impedance, which ultimately may cost you more complexity (and performance).

And yet, both C# and Swift somehow manage to do it…

http://www.matt.digital/comparing-c-nullable-types-and-swift...

https://developer.apple.com/swift/blog/?id=25

It doesn't have to cost performance (not even compiler performance!) or create impedance. You just represent the None variant as null in the compiled output. I realize this sounds suspiciously easy and it seems like there must be something I'm glossing over, but there honestly isn't, as long as you never introduce null to your own language in the first place. Once you've done that, though, it gets harder, because you have to differentiate between Some(null) and None, which means they can't both be compiled to null. But this is a completely self-imposed problem; it is not an issue when you create a language from scratch, only if you want to retrofit optionals onto an existing language.

> I realize this sounds suspiciously easy and it seems like there must be something I'm glossing over, but there honestly isn't, as long as you never introduce null to your own language in the first place.

Yeah, having done this before, it isn't that easy. You basically have to map NULL to something else, and if that mapping is so direct and straight forward, you actually haven't improved your engineering one bit.

It is literally that easy. This is how it is done in Rust, for instance. You have improved your engineering by (1) requiring exhaustive match on anything that is potentially null, and (2) eliminating the need to check for null anywhere else. I don't understand why people take it as an article of faith that this must be difficult. In fact, the sheer simplicity of it is why I believe it should be in Go, and am confused about why it is not.

Null is much less of a problem than having no static type system at all.

A "billion dollar" mistake is a mistake Google can affod to make :-/

Google, Apple, Facebook are the tech companies.

Even though they are enterprises, the term enterprise software often refer to the other companies, who use tech as an aid to run their main businesses.

Think about Box, MobileIron, and many such companies targeted to enterprises and who their consumers are. That is the enterprise software market.

Reply on news.ycombinator.com