> 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.
I'm not deeply familiar with Rust borrow checker, but my understanding is that Swift will in the near-future support move only types. Are those not somewhat similar to what Rust has?
What the heck is 'bar' and 'baz'? So there's no docstring? And the actual variables are that random and indecipherable? Sounds like the problem is that you're tasked with looking at code written by someone who is either inexperienced or fundamentally careless. When dealing with reasonably maintained codebases, this kind of situation would seem pretty rare. In modern python we now have type hints of course, which have…
Coming from any statically typed language to Python or JavaScript codebases this plagues me. Virtually every project I have seen suffers from this. Function names and doc comments describe behavior, not argument and return types.
Our main codebase is in PHP, but we enforce type hinting for all new code, so it feels more like a static language at this point in practice. However, there are chunks of old code without type hinting or types in PHPDocs. Whenever I have to deal with that code (especially if it's unknown code), my productivity decreases considerably. I have to click through many layers of functions to figure out the data flow to understand what the implicit contract of a function is. In static languages, all you need to care about is a contract, the rest is implementation details. In the dynamic portions of the codebase, there's just too much cognitive load because I have to look at implementation details to get it. PHPDocs and dynamic checks seem to be pretty error-prone, because a dev often forgets to update both the code and the annotations/type checks (and type checks are often ad hoc and random), leading to even more cognitive load. Having static analyzers in the pipeline to have some control of the situation leads to longer build times, so in the end it feels like PHP builds slower than all our Go projects combined.
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…
I'm working in Python. I agree with you. Refactoring is much harder, especially with large code bases
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.
Common Lisp also has a system for OO coding but Common Lisp is not an OO Language.
I didn't see the article touch on the "why" explicitly, but: zig really has the chance to square this circle for low level languages, since there is duck-typed type-inferenced-coercion in places where it makes sense. Completely correct about zig not necessarily being good for higher level stuff, but I think (dynamic) HLLs have been converging on dealing with this using static typechecking, with varying levels of succ…
I spent a couple of days with Zig. Thought the language was great but the tooling (on Windows) just killed it for me. I hope that gets better 'cos I'd like to give it another go
I think the comparison between printf in Idris and Zig is a little off, since the Idris version defines an intermediate datastructure, and hence requires extra parsing and interpreting functions for it. That's a nice approach, but the Zig version is operating directly on characters, so it's a bit apples-to-oranges. We can get a more direct Idris implementation by inlining the parser (toFmt) into the interpreter (Prin…
Would printf even exist if C had sane strings?
printf exists in Java. Because its so bloody useful.
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…
> and is able to do much of Google's internal server side work. You mean, one of the companies with the largest number of developers on the world, paying one of the highest average salaries for them is able to use the language? That means absolutely nothing.
Go has been used by way more successful startups than Rust, Haskell and others of their kind combined.
At least so far. Rust might change that in the future.
Almost all software running the world is written in statically typed languages. This is not by accident or because developers don’t know better. Every few months on HN somebody will make some new claim about why dynamically typed languages are somehow better. But the truth is that statically typed languages have won in the market place for real world software. And I don’t see anything changing that.
Today I learned that python, javascript and php are statically typed languages.
The problem I find with static typing is that it so easily leads you over-specifying the requirements / constraints. In fact, it makes such a virtue out of that over-specification that many people would consider it a best practice to do so. For example, perhaps my `calculate_price` function only depends on 2 attributes of the order which has 65 attributes. Am I creating a 2-element data type for that function to proc…
Typescript can do exactly what you ask for, “static duck typing”. Just define the input argument to be a interface with the 2 relevant attributes, any struct having at least these 2 attributes are now allowed, even if there is no explicit inheritance to it. This can be done inline in the function signature so doesn’t contribute to bloat.
Python can do the same using what they call Protocol. Here protocols need to be defined upfront.
This is usually called Structural typing, as opposed to nominal typing where classes inherit from a base.
> 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. Which is exactly what a type error is! > The Rust borrow checker is an invariant enforcer. It explicitly does automatic global analysis, and reports explicitly that what's going on at point B is inconsistent w…
Rust has affine types, and uses them extensively: types that own memory, as opposed to borrowing it, are generally affine. In principle you could implement a form of borrow check with linear types (I don’t think affine is good enough), but the ergonomics would be horrible.