Hacker News Reader

Comment by danielscrubs | Hacker News Reader

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some great language because they always take the easy way (makes more business sense, see Dart). Academia on the other hand will make great languages that never reaches critical mass.

View on HN

Ian Lance Taylor worked on generics for like a decade, and the final design was heavily based on the Featherweight Go paper, which had formal proofs of the design given a simplified version of the go language. This is a very odd complaint around this feature.

Yes retrofitting is hard. However, "Generics", also known as parametric polymorphism is well understood and goes back to Milners ML from the 70s.

While something may be well understood in an academic sense doesn't mean that the application of that understanding to implementation humans will take a liking to is well understood.

If you look at the programming language landscape I think one wouldn't be unreasonable in pointing out that very little is understood in terms of how you go from good ideas to widely adopted language.

What affects reality is important.

> doesn't mean that the application of that understanding to implementation humans will take a liking to is well understood.

I really like how ML implements it, does that make me somehow less human?

What you like or don't like isn't really the point. The point is that it isn't unimportant when judging how "good" a language is to take into account how many people are willing to use it. It is hard to argue that a language is "good" when a negligible fraction of developers are willing to use it.

As Alan Kay said, the industry is a pop culture, driven by marketing not science. I'm still going to argue for good ideas though.

If one is to come up with an excuse for not understanding people, one should pick something that at least sounds plausible.

Both industry and academia are making languages according to their own incentives and criteria.

Industry language designers are trying to make their users more productive enough to justify the cost to design and build the language. An industry language that doesn't have enough users and doesn't make those users' lives better enough to offset the salaries of the language team is a losing proposition and a bad language.

Academics are trying to publish papers on novel ideas. A language that cured cancer would be considered a bad language if someone had already designed a language that cured cancer the prior year.

These incentive structures a somewhat opposed: the easiest way to make a language easier to adopt is to make it more familiar and less novel. But they are somewhat aligned as well. A language with no new ideas can't be any better than the languages before it.

So there is a natural diffusion process where academia explores the frontier of weird language ideas. Many don't pan out. All of them are weird and unapproachable when they first appear. The ideas worth keeping stick around. Eventually an industry language will add a dollop of those novel ideas and surround them with a familiar framework so that users can actually absorb and use the thing.

> Academia on the other hand will make great languages that never reaches critical mass

Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.

Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1]

> Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is <100ms on average. The BuckleScript author estimates that the build system should scale to a few hundred thousands files in the current condition.

> Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! *

> Most of the messenger core team's new features are now developed in Reason. Dozens of massive refactors while iterating on ReasonReact. Refactoring speed went from days to hours to dozens of minutes. I don't think we've caused more than a few bugs during the process (counted toward the total number of bugs).

In a high-velocity codebase, modularity is the name of the game. And you will be hard-pressed to find languages outside the ML family which are that good at modularity. OCaml is just about the only industrial-ready language in this space.

[1] https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

Don't buy that propaganda, however well-intentioned it is.

At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.

Any moderately complex app is made up of so many moving pieces, I'm amazed that you can pinpoint those failures specifically to the web frontend piece.

I can't find what I wrote at the time, but there were multiple UI/UX issues and logic bugs.

In any case, the point I was making was that languages from academia potentially could scale up in high-velocity and larger teams.

Aren't Reason and ReScript different languages? It's confusing which one they're talking about here.

They are now, at the time the post was written ReScript did not exist and people used to refer to the combination of BuckleScript + Reason as 'ReasonML' for simplicity.

They must have changed how they report bugs, because the number of issues messenger.com experiences is definitely more than 10 a year. Also super slow.

> my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day

Why would they? Many are designed meticulously to address the issues industry has. I've worked on a multi-million line Haskell code base in a financial institution and it scaled better than e.g. C++ or Python. In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

God what's the compilation time of millions of line of Haskell?

> In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

There are plenty of industrial languages with algebraic data types and immutability. Not as many as I would like with purity but I doubt it will take 30 years.

Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.

Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.

Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.

Haskell let's one write fast imperative code when needed or call C functions.

> God what's the compilation time of millions of line of Haskell?

It wasn't compiled with GHC, but a proprietary compiler. It could typecheck the entire lot in a few minutes (in parallel) which was usually enough to detect breaking changes.

> There are plenty of industrial languages with algebraic data types and immutability.

A few do, yes, certainly not plenty. But defaults matter and immutability means more than just "const", e.g. persistent collections.

> Not as many as I would like with purity but I doubt it will take 30 years.

Given that big tech is delivering languages that are basically the same as Algol 60, I honestly think it will take at least 30 years.

http://cowlark.com/2009-11-15-go/

Go's biggest problem is that no one at Google dares to question design decisions. After all, it's Rob Pike and Ken Thompson! What was the last time they had to write and maintain a modern, large software system? Go is great to fool around with, but at scale, it becomes a nightmare. Most of your code, first of all, is error checking. Because new rule - exceptions are suddenly bad (they are not).

It's really hard to know what you are doing right or wrong when you are writing a large program. There are no guidelines for proper layout, logging, and error checking practices, and no matter what you do, it's verbose and error-prone (more code = more bugs). It's all DIY. I referred to HashiCorp code to see how they do things, for example.

As someone here said once - Go is basically improved C, after snoozing through four decades of language development. On one hand Go lets you go wild, and on the other it imposes rules that are seemingly arbitrary, like enforced naming conventions, but only in certain places.

Go is odd in that people constantly complain about what it cannot do or does incorrectly, while having become one of the most prolific languages at the same time.

Makes it seem like we’re living in a bubble while others are getting stuff done, isn’t it?

C++ is wildly prolific, and yet it is under constant criticism. Most people in my experience (even C++ proponents) would agree that much of that criticism is reasonable, even if there's a subset of C++ that can be carefully used to create reliable software.

Go is odd in that its proponents seem to flatly deny any of the very reasonable criticisms levied against it. And they continue to do so right up until the moment that the language authors finally address them.

Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....

True but they didn't have to deal with the complexity of the modern software where a typical project can pull in thousands of dependencies (transitively).

That is taken care by using binary libraries, see Delphi or Eiffel.

Right. My view is: Go brings back a lot of the great traits of languages like Pascal and Modula. Fast compilation speed, a simple static typed language, a modules concept. Adding a few nice things like GC, high order functions and some more.

I feel, programming too often lost productivity with quite a few modern languages. Go brings that back and adds a good amount of modern features, but doesn't get too much distracted by them.

How does it bring back productivity when it has the expressivity of C (at least before generics, it’s a bit better afterwards)

C doesn’t have methods, interfaces, closures, newtypes, packages, map or safe slice and string types, or safe automatic allocations.

What bad faith nonsense.

And before generics it could not even implement maps in the language itself, hence my comment.

I do not think this is true. Async programming via channels in Go is a big win and way more expressive than what any C library can give you. Also, higher order functions and interfaces are good. On top of that they added generics. I think that it is more than enough of a practical language already.

I’m pretty sure Go’s maintainers were aiming for “mere” practical success, as opposed to some theoretical success that only academic languages succeed at.

What's the definition of "success" here? Popularity?

As I understand it, Google's rationale for Go is to enable them to hire a lot of say, good-but-not-great fresh CS graduates with little or no practical experience and produce software at their scale without putting those new hires through a multi-year training programme.

So the definition of success is that Go makes those people productive. If you give these fresh hires C++, now everything is on fire and even experienced people sent in to extinguish the flames end up just saying evacuate the entire site and let it burn itself out because that will be cheaper than diagnosing what's wrong.

This goal means some choices Go makes which I don't like seem more respectable. For example Go specifically warns you not to get clever. This is sound advice for a 22 year old new programmer who still probably thinks "Romeo and Juliet" is about true love, but it'd be very frustrating if you were trying to squeeze the last drops of performance juice out of a system. The answer from Google's point of view is that Go is the wrong language in that case and it's time to rewrite.

Which is ironic given the whole plethora of hiring practices at Google.

Also Go is mostly used externally, Google's key projects are all based on Java and C++, even Kubernetes would have stayed in Java if it wasn't for some Go folks joining the project and pushing for a rewrite.

It is not ironic if you have ever interacted with these people. They suck at everything outside of leetcoding.

> As I understand it, Google's rationale for Go is to enable them to hire a lot of say, good-but-not-great fresh CS graduates with little or no practical experience and produce software at their scale without putting those new hires through a multi-year training programme.

From my discussions with employees at Google, the rationale for Go is to keep a large staff of promising CS graduates busy on dead-end projects (while preventing them from causing too much damage) until something takes off and they need to actually put some of that spare headcount to use.

I think so. I wish OCaml or Clojure had become popular like Go and Rust when they were the fresh thing of the day..

Something like “Optimized for software development in the real world”. Wide adoption is a consequence/indicator of this optimization, not the definition itself.

"Shit show" is a bit imprecise. What would you say are the major shortcomings in Go and how do they manifest as problems in practical reality?

Also, it would be interesting to hear your take on why you think languages that are, as you say, from "a sound theoretical foundation" tend to struggle with adoption?

Could it be that you fail to take into account that the things that make a language appealing in an academic sense may not make the language a particularly practical language?

At least in the case of PLT Scheme, I recall a conference where there was open hostility to the notion that their academic language might (horrors!) become widely adopted.

And understandably so!

Wide adoption means certain academy-hostile rules: backwards compatibility, a lot of user pressure towards certain directions, etc. Academics need freedom, and adoption is not about freedom.

Haskell seems to have muddled through catering to both, though! Not sure whether they see Racket as still in that researchy space.

Does Haskell make it through your filter, with its multi-disciplinary foundation and mix of industrial and academic sponsors?

> start making a language from a sound theoretical foundation and then implement it

ADA may be up your alley. it was fully designed and specified before a single line was written.

It sounds like: one of those is constrained by reality, the other ain't

For the working programmer do you really want theoretical soundness? Though I have background in formal mathematics, when it comes to day to day, and what pays the bills, what I might need to operate in anger, I much much more care about legibility, debuggability, inspectability, easy to implement X (without a stdlib if need be), easy to test, no footguns, PL respects programmers (btw go fails most of these)

In my experience go is great at all of these, but then again I’m coming from c and then erlang…

I personally do. At my company we recently finished adding types to some libraries that were a core part of our system but were deemed "untypeable" by the maintainers of the libraries themselves (we're contributing back), and only band-aids existed. We needed several advanced typing features in our languages for that that weren't available for us a couple years ago.

Each time we added more advanced typing to new sections of the system, new bugs and security issues were found. At the end there were over 100 places that were being used incorrectly. This is something that linters and the library itself failed to catch for years, but with proper typing we got there.

That's not theoretical soundness, that's actual correctness. I'm mostly talking about things like io monads.

If your code can run IO operations synchronously and branch on the result of previous operations, you've already got an IO monad. The point of being explicit about that is that it allows you to check that a given piece of code can't do those things. Keeping database calls out of the render loop, for instance, is very much a matter of actual correctness.

In most languages with an io monads your power of proving that x can or can't be done comes at the cost of hiding the business data inside of the monad type (that wraps it) which severely impacts debuggability and in many cases, code legibility and understandability of the data you care about -- because there might be a business logic error elsewhere that you need to track down that no amount of formal correctness will save you from.

The decades-old solution for that is to not mix the business and IO code in the first place. If you do, that's entirely on you. This works exactly the same and has the same goals as in popular OOP architectural patterns like Clean Architecture, Hexagonal Architecture or Onion Architecture.

With the difference that with a better type system it becomes significantly harder to do this kinda thing to begin with, and that's a GREAT thing. Your business code is extremely simple, reusable, isn't intertwined with IO stuff and is 100% testable with minimal effort, without needing mocks or anything of the sort.

If you don't care about this kind of correctness, then fine, but don't pretend this is something that's not sought after by both OOP and FP practitioners.

Where did you get the idea that I practice oop? I exclusively use FP, and I use hexagonal-ish fp design. But question. Suppose you discover you have a logic bug and you write a pure logic test for it. But perhaps the path through the business logic was written by someone else, who has since left the company. It's a tax rule so you have to navigate through several layers of abstractions that are sometimes specialized for different countries, sometimes generalized. Maybe they didn't write all the tests that you'd like to see. You have one hour to deploy a patch because 9-5 customers are entering their work hours on a different continent whose tax rules are what you need to fix. How do you introspect the data that are moving through the code?

Where did I say you practice OOP? I'm just making a comparison to another paradigm in my reply to demonstrate that this is not an FP problem alone, continuing the train of thought started by hither_shores. Not everything is about you, friend.

About the "IO monad in business" issue: there's ways to solve it without having to pass IO through business layers or having to break architectural constraints. In the OOP architectures alone there's lots of patterns to avoid doing it already, and if you're doing it should all be in place, probably by passing a repository down to the business layer. In FP there are similar patterns to avoid needing a monad down in business code, passing down a repository-analog is enough. If you can't solve it without a "hack", then it's fine: that's just technical debt. That's on you to fix later. Or not, it's your work. About the question: gotta need more context for that, that's the vaguest thing someone asked me lately.

It's however one's own choice to decide how to deal with that. I prefer using constraints imposed by the typing system. You're free to do otherwise, but don't imply nobody wants it like you did in your first post, as there's people who find it useful. Once again, not everything is about you and you alone.

I don't see why you're assuming we did something different, I even said "advanced typing features". We have several effect-related types, including IO.

I’ve completely lost any confidence that FANG will be able to make some great language because they always take the easy way (makes more business sense, see Dart).

I've found Dart to be perfectly adequate. Like Go it doesn't try to be overly clever; unlike Go it doesn't consider verbosity to be a feature, and believes you're capable of using advanced techniques like ternary expressions responsibly.

If you consider conditional expressions an “advanced technique”, that explains a lot…

Reply on news.ycombinator.com