Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why static languages suffer from complexity

hirrolot.github.io

Post reply on HN
Print view View original

231–240 of 306 posts

Re: Why static languages suffer from complexity

#231

Post by hiptobecubic »

skybrian wrote: post #130
Zababa wrote: post #113

Earlier quoted context omitted.

> Go has a minimal type system, and is able to do much of Google's internal server side work. Isn't it stil mostly Java and C++? That's what I hear all the time here. Also, I'm not sure what point you're trying to make. You start by saying that fascination with types systems is not useful in practice, and end with an example where it is useful (Rust). While Go can stick a GC to avoid most of the issues that Rust is t…

It's been a while since I worked there, but the trend at Google at the time was that the amount of code written in each popular language was rapidly growing, and the number of popular languages was also slowly growing. (Despite a lot of resistance to introducing new languages.) I'm out of touch, but I would expect that there is a lot more Go code by now, and it also didn't catch up with C++ or Java.

This is pretty accurate I would say. Although, Go is more popular outside of Google than inside it and the original dream of "Replace all Python and most C++ and Java with Go" is laughably dead. Google used to require SRE teams to explain why they weren't using Go for new projects and they abandoned that because it was ridiculous and no one took it seriously.

There are quite a few internal projects written in Go, but it feels like any time one of them gets big enough to matter, someone ends up reimplementing the important parts in C++ for performance reasons.

Re: Why static languages suffer from complexity

#232

Post by sanderjd »

gordaco wrote: post #204
amelius wrote: post #178

Earlier quoted context omitted.

They are especially useful when refactoring, or as a documentation tool. However, without a type checker, choosing your names wisely will get you a long way. I think anyone advocating type systems should spend a year working in a dynamic language, to get out of their echo chamber and form a more objective opinion.

I was a mild advocate of static type systems. Then I spent about two years working on dynamic languages, mostly Python, on two jobs with otherwise very different code bases. I am now fully converted: after that experience, I strongly, strongly, strongly advocate static typing, so much that I will leave any job that requires me to use languages that lack them. I don't know if I was just unlucky, but I found that exper…

Yeah, you have to work so hard to write maintainable code in "dynamic" languages. It's also super hard to debug them. It's easier to write the first thing that runs, but that's not enough.

Re: Why static languages suffer from complexity

#233

Post by sanderjd »

Zababa wrote: post #113
Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…

> Go has a minimal type system, and is able to do much of Google's internal server side work. Isn't it stil mostly Java and C++? That's what I hear all the time here. Also, I'm not sure what point you're trying to make. You start by saying that fascination with types systems is not useful in practice, and end with an example where it is useful (Rust). While Go can stick a GC to avoid most of the issues that Rust is t…

Go has definitely gained more mindshare more quickly outside Google than inside, in my experience.

Re: Why static languages suffer from complexity

#234

Post by sanderjd »

preordained wrote: post #105

Having used Clojure for a while now, I will say having 90% of things be a primitive, map, or vector goes a long way in and of itself. A lot of types concocted in a more conventional language just don't need to exist, IMO, and they create so much baggage around themselves.

I have the exact opposite experience. I can't think of anything I got more sick of than every freaking method in every rails project having `params = {}` where you have no idea what keys are required or expected or ignored. Easily 90% of these should have been named structures instead of these arbitrary data grab bags.

Re: Why static languages suffer from complexity

#235

Post by [deleted] »

yakshaving_jgt wrote: post #181
spinningarrow wrote: post #174

Earlier quoted context omitted.

If your data is not position-dependent a tuple doesn’t sound like the correct choice. In the price example you provided, a map would be much better. As for how you know what’s in there - you should only know whether what’s relevant to your function is in there and not care about the rest of the world. For the former, tools like clojure.spec are helpful but ultimately good design helps the most (something that typed l…

> If your data is not position-dependent a tuple doesn’t sound like the correct choice. That's kind of the problem though. Software is written by humans, and humans are fallible. We don't always make the correct choices. Also, there are economic pressures, deficiencies in specification, and changes in business requirements. Personally, I believe businesses should accept the aforementioned reality and optimise for cos…

[deleted]

Re: Why static languages suffer from complexity

#236

Post by bcrosby95 »

sanderjd wrote: post #234
preordained wrote: post #105

Having used Clojure for a while now, I will say having 90% of things be a primitive, map, or vector goes a long way in and of itself. A lot of types concocted in a more conventional language just don't need to exist, IMO, and they create so much baggage around themselves.

I have the exact opposite experience. I can't think of anything I got more sick of than every freaking method in every rails project having `params = {}` where you have no idea what keys are required or expected or ignored. Easily 90% of these should have been named structures instead of these arbitrary data grab bags.

If you had a generic params map, you would likely destructure it and the keys would be obvious. Destructuring in Clojure also gives you a way to specify defaults for each key right there.

Re: Why static languages suffer from complexity

#237

Post by darthrupert »

Verdex wrote: post #192
amelius wrote: post #178

Earlier quoted context omitted.

They are especially useful when refactoring, or as a documentation tool. However, without a type checker, choosing your names wisely will get you a long way. I think anyone advocating type systems should spend a year working in a dynamic language, to get out of their echo chamber and form a more objective opinion.

What you appear to be saying is that people who like type systems must be ignorant because with experience you suspect they would think differently. This seems to me to be extremely uncharitable point of view. But let's roll with it. I advocate type systems. I've also worked in several non-trivial projects in lua. Several non-trivial projects in python. Several trivial projects in common lisp. Several trivial project…

Common Lisp has a type system, if I understood your meaning right.

Re: Why static languages suffer from complexity

#238

Post by halpert »

DonaldPShimoda wrote: post #109
Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…

> Fascination with type systems does not seem to be all that useful in practice. > ... > The Rust borrow checker is an invariant enforcer. [...] This is real progress in programming language design, and is Rust's main contribution. I'm so confused by your stance here. You essentially say "type systems are not useful" and then "oh but this most recent advance in type systems — that one is useful." Do you find type sys…

Rust's borrow checker isn't a type system. It's a static analyzer that tries to determine if it can figure out when to free your allocation.

Re: Why static languages suffer from complexity

#239

Post by EdwardDiego »

acchow wrote: post #128
Zababa wrote: post #113

Earlier quoted context omitted.

> Go has a minimal type system, and is able to do much of Google's internal server side work. Isn't it stil mostly Java and C++? That's what I hear all the time here. Also, I'm not sure what point you're trying to make. You start by saying that fascination with types systems is not useful in practice, and end with an example where it is useful (Rust). While Go can stick a GC to avoid most of the issues that Rust is t…

> Isn't it stil mostly Java and C++? That's what I hear all the time here. Go's type system is much weaker and less expressive than either Java's or C++'s. C++ in particular has parametric polymorphism, type constructors, and dependent types. Go has none of those.

Question from genuine interest, how is Go's type system weaker than Java? Is it just the (until recently) missing generics.

I know that casting to interface{} is the equivalent of casting to Object, but Go 1.18 should hopefully avoid most of that.

Just wondering what else you're thinking of, asking as someone who knows Java well and Go okay.

Re: Why static languages suffer from complexity

#240

Post by earleybird »

sanderjd wrote: post #227
Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…

It's not a fascination, it's just easier and better to have good static analysis when programming. That doesn't have to be a type system, but I think there is a lot of reason to think that a type system is the lowest hanging fruit for useful static analyses.

I think this sums up the pragmatics well. Brian Cantrell discusses in one of his talks what they did at Sun to ensure they were writing safe C. This was a substantial amount of tooling they had to build up. Type systems bring you this tooling in a well founded, logical way. And as you say, it's a good place to start, even if it's just to know how the puzzle pieces of your code fit together.
Post reply on HN