8 ms·

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 syntac

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.

truffdog 4y ago
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.
- grumpyprole 4y ago
  Yes retrofitting is hard. However, "Generics", also known as parametric polymorphism is well understood and goes back to Milners ML from the 70s.
  - bborud 4y ago
    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.
    - grumpyprole 4y ago
      > 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?
      - bborud 4y ago
        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.
        grumpyprole 4y ago
        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.
        bborud 4y ago
        If one is to come up with an excuse for not understanding people, one should pick something that at least sounds plausible.
phlakaton 4y ago
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.
- vkazanov 4y ago
  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.
  - phlakaton 4y ago
    Haskell seems to have muddled through catering to both, though! Not sure whether they see Racket as still in that researchy space.
texaslonghorn5 4y ago
Does Haskell make it through your filter, with its multi-disciplinary foundation and mix of industrial and academic sponsors?
throwawaymaths 4y ago
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)
- cyberpunk 4y ago
  In my experience go is great at all of these, but then again I’m coming from c and then erlang…
- ratww 4y ago
  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.
  - throwawaymaths 4y ago
    That's not theoretical soundness, that's actual correctness. I'm mostly talking about things like io monads.
    - ratww 4y ago
      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.
    - hither_shores 4y ago
      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.
tester756 4y ago
It sounds like: one of those is constrained by reality, the other ain't
orangecat 4y ago
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.
- xigoi 4y ago
  If you consider conditional expressions an “advanced technique”, that explains a lot…
throwaway894345 4y ago
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.
- mcronce 4y ago
  What's the definition of "success" here? Popularity?
  - tialaramex 4y ago
    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.
    - stouset 4y ago
      > 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.
    - 4y ago
sangnoir 4y ago
> 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.
- yawaramin 4y ago
  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-reason https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
  - dmitriid 4y ago
    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.
    - yawaramin 4y ago
      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.
naikrovek 4y ago
> 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.
munificent 4y ago
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.
pjmlp 4y ago
Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....
- kgeist 4y ago
  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).
  - pjmlp 4y ago
    That is taken care by using binary libraries, see Delphi or Eiffel.
- _ph_ 4y ago
  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.
  - kaba0 4y ago
    How does it bring back productivity when it has the expressivity of C (at least before generics, it’s a bit better afterwards)
    - morelisp 4y ago
      C doesn’t have methods, interfaces, closures, newtypes, packages, map or safe slice and string types, or safe automatic allocations. What bad faith nonsense.
      - kaba0 4y ago
silisili 4y ago
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.
- stouset 4y ago
  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.
- mayormcheeseman 4y ago
  Makes it seem like we’re living in a bubble while others are getting stuff done, isn’t it?
bborud 4y ago
"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?
papito 4y ago
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.

truffdog 4y ago

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.

grumpyprole 4y ago
Yes retrofitting is hard. However, "Generics", also known as parametric polymorphism is well understood and goes back to Milners ML from the 70s.
- bborud 4y ago
  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.
  - grumpyprole 4y ago
    > 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?
    - bborud 4y ago
      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.
      - grumpyprole 4y ago
        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.
        bborud 4y ago
        If one is to come up with an excuse for not understanding people, one should pick something that at least sounds plausible.

phlakaton 4y ago

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.

vkazanov 4y ago
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.
- phlakaton 4y ago
  Haskell seems to have muddled through catering to both, though! Not sure whether they see Racket as still in that researchy space.

texaslonghorn5 4y ago

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

throwawaymaths 4y ago

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)

cyberpunk 4y ago
In my experience go is great at all of these, but then again I’m coming from c and then erlang…
ratww 4y ago
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.
- throwawaymaths 4y ago
  That's not theoretical soundness, that's actual correctness. I'm mostly talking about things like io monads.
  - ratww 4y ago
    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.
  - hither_shores 4y ago
    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.

tester756 4y ago

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

orangecat 4y ago

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.

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

throwaway894345 4y ago

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.

mcronce 4y ago
What's the definition of "success" here? Popularity?
- tialaramex 4y ago
  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.
  - stouset 4y ago
    > 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.
  - 4y ago

sangnoir 4y ago

> 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.

yawaramin 4y ago
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-reason https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
- dmitriid 4y ago
  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.
  - yawaramin 4y ago
    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.

naikrovek 4y ago

> 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.

munificent 4y ago

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.

pjmlp 4y ago

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

kgeist 4y ago
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).
- pjmlp 4y ago
  That is taken care by using binary libraries, see Delphi or Eiffel.
_ph_ 4y ago
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.
- kaba0 4y ago
  How does it bring back productivity when it has the expressivity of C (at least before generics, it’s a bit better afterwards)
  - morelisp 4y ago
    C doesn’t have methods, interfaces, closures, newtypes, packages, map or safe slice and string types, or safe automatic allocations. What bad faith nonsense.
    - kaba0 4y ago

silisili 4y ago

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.

stouset 4y ago
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.
mayormcheeseman 4y ago
Makes it seem like we’re living in a bubble while others are getting stuff done, isn’t it?

bborud 4y ago

"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?

papito 4y ago

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.