4 ms·

Rust is actually quite easy to compile. Ada is easy to compile. ML-like languages are easy to compile. Oberon is trivial to compile.

by sklogic 11y ago

nickpsecurity 11y ago
I've never heard anyone say Ada was easy to compile. Also, I heard its uptake was slowed by how hard it was to get the early compilers working. So, where did you see an easy one? Seriously, because Ada still needs a CompCert (or at least FLINT) style certified compiler. An easy Ada compiler would be a nice start on that.
- pizlonator 11y ago
  I always thought that Ada was easy to compile in the backend (i.e. the moral equivalent of what B3 does) but challenging on the frontend because of how large the language is. Could be wrong though. The frontend is usually the hard part IMO. In WebKit, we have 100,000 lines of code for our "frontend" (i.e. the DFG compiler) and 50,000 lines of code for our "backend" (i.e. B3). That split is really interesting.
  - nickpsecurity 11y ago
    It's what I thought, too. The split may come from the fact that the front-end is more complex, richer in information, harder to analyze, and harder to transform. The more you can do with it the more code it takes to represent. That's my hypothesis. Far as Ada, I figured it would be difficult due to the large number of language features and complexities of analyzing a program for safety w/ all its rules. And any interactions that might emerge in that between features and rules. Could be easier than I think but my default belief is that it's not easy.
- sklogic 11y ago
  I am talking about the backend optimisations, not the frontend parts. Ada frontend got tons of sweet static information for the backend to consume.
  - nickpsecurity 11y ago
    That makes more sense. Did you ever work on any Ada compiler I might have heard of?
    - sklogic 11y ago
      Nothing fancy, I was simply implementing a subset of Ada for fun. I find it is the quickest way to learn or explore a language - write a compiler for a subset of it. Frontend was awful and I never finished it, but the LLVM-style backend wad very easy to build.
killercup 11y ago
You are probably right, assuming input programs are correct. Rust (and Haskell) is not easy to _type-check_ though.
- eddyb 11y ago
  You can't compile Rust without types and inside functions, most types come from inference and coercions, so "type checking" is really "type resolution".
- bluejekyll 11y ago
  I don't understand this perspective. Is the point that JavaScript just works such that you don't have to worry about it compiling at runtime? To me this is the difference between knowing that your program will probably work after it compiles, vs not knowing until after its deployed. What I think people really enjoy in dynamic languages like JavaScript is the instant feedback, just reloading the browser. This can be accomplished with decent IDEs for most statically typed languages.
  - geofft 11y ago
    I don't believe anyone's arguing that the overhead of static checking is not worthwhile, merely that it involves serious work on the part of the compiler developers that should not be dismissed.
- chriswarbo 11y ago
  > Rust (and Haskell) is not easy to _type-check_ though. Is that really the case? It seems to me that a Prolog-like resolution system, coupled with a constraint solver, would get most of the job done with little effort. There are certainly many rules to keep track of, but in some cases the newer rules are strict generalisations of the older rules. For example, Haskell's original type classes are just a special-case of modern multi-parameter, flexible instances/contexts, etc. type classes. Likewise, we can implement constraint kinds, type class instance resolution and type equalities using one constraint solver.
  - 11y ago

Rust is actually quite easy to compile. Ada is easy to compile. ML-like languages are easy to compile. Oberon is trivial to compile.

by sklogic 11y ago

Rust is actually quite easy to compile. Ada is easy to compile. ML-like languages are easy to compile. Oberon is trivial to compile.

nickpsecurity 11y ago

I've never heard anyone say Ada was easy to compile. Also, I heard its uptake was slowed by how hard it was to get the early compilers working. So, where did you see an easy one? Seriously, because Ada still needs a CompCert (or at least FLINT) style certified compiler. An easy Ada compiler would be a nice start on that.

pizlonator 11y ago
I always thought that Ada was easy to compile in the backend (i.e. the moral equivalent of what B3 does) but challenging on the frontend because of how large the language is. Could be wrong though. The frontend is usually the hard part IMO. In WebKit, we have 100,000 lines of code for our "frontend" (i.e. the DFG compiler) and 50,000 lines of code for our "backend" (i.e. B3). That split is really interesting.
- nickpsecurity 11y ago
  It's what I thought, too. The split may come from the fact that the front-end is more complex, richer in information, harder to analyze, and harder to transform. The more you can do with it the more code it takes to represent. That's my hypothesis. Far as Ada, I figured it would be difficult due to the large number of language features and complexities of analyzing a program for safety w/ all its rules. And any interactions that might emerge in that between features and rules. Could be easier than I think but my default belief is that it's not easy.
sklogic 11y ago
I am talking about the backend optimisations, not the frontend parts. Ada frontend got tons of sweet static information for the backend to consume.
- nickpsecurity 11y ago
  That makes more sense. Did you ever work on any Ada compiler I might have heard of?
  - sklogic 11y ago
    Nothing fancy, I was simply implementing a subset of Ada for fun. I find it is the quickest way to learn or explore a language - write a compiler for a subset of it. Frontend was awful and I never finished it, but the LLVM-style backend wad very easy to build.

killercup 11y ago

You are probably right, assuming input programs are correct. Rust (and Haskell) is not easy to _type-check_ though.

eddyb 11y ago
You can't compile Rust without types and inside functions, most types come from inference and coercions, so "type checking" is really "type resolution".
bluejekyll 11y ago
I don't understand this perspective. Is the point that JavaScript just works such that you don't have to worry about it compiling at runtime? To me this is the difference between knowing that your program will probably work after it compiles, vs not knowing until after its deployed. What I think people really enjoy in dynamic languages like JavaScript is the instant feedback, just reloading the browser. This can be accomplished with decent IDEs for most statically typed languages.
- geofft 11y ago
  I don't believe anyone's arguing that the overhead of static checking is not worthwhile, merely that it involves serious work on the part of the compiler developers that should not be dismissed.
chriswarbo 11y ago
> Rust (and Haskell) is not easy to _type-check_ though. Is that really the case? It seems to me that a Prolog-like resolution system, coupled with a constraint solver, would get most of the job done with little effort. There are certainly many rules to keep track of, but in some cases the newer rules are strict generalisations of the older rules. For example, Haskell's original type classes are just a special-case of modern multi-parameter, flexible instances/contexts, etc. type classes. Likewise, we can implement constraint kinds, type class instance resolution and type equalities using one constraint solver.
- 11y ago