9 ms·

Hegel – An advanced static type checker for JavaScript

96 points by kuramitropolis 4y ago

WFHRenaissance 4y ago
What motivated the name choice?
- xoac 4y ago
  "it's like, deep and stuff"
- pxc 4y ago
  I can't find any indication from the author, but: (Post-)Kantian epistemology/metaphysics is about trying to see what we can know of the structure and behavior of the world prior to (without) making empirical reference to it. Intuitively, the distinction between static analysis and dynamic analysis seems to parallel the relationship between rationalist/idealist/a priori epistemology and empiricist/materialist epistemology. Hegelian philosophy has also been taken up by some mathematicians and 'formalized' in terms of type theory and category theory. Lawvere did some work on 'categorifications' of Marx and Hegel, and I guess some HoTT people have also recently taken an interest in Hegel. You can find a little bit of background and references to other sources here: https://ncatlab.org/nlab/show/Hegel%27s+%22Logic%22+as+Modal+Type+Theory https://ncatlab.org/nlab/show/Hegel%27s+%22Logic%22+as+Modal...
  - qualudeheart 4y ago
    Will we soon have formalizations of Nick Land and Marc Fisher? I imagine machine learning techniques could be of use here.
- naet 4y ago
  A huge pet peeve of mine is libraries appropriate existing topics as their name. Eleventy is a great name. When I search it I get nearly 100% Eleventy related results. Hugo is a not great name; if I search it and I get Hugo the movie, Hugo boss the fashion line, Hugo insurance company, etc. Next.js is an okay name, at least they explicitly include .js in the name and branding and all over their website to make it a bit more notable and manageable. Hegel is not a great name IMO. The search space is dominated by the well renowned philosopher, and if the library does get very popular, it begins to take away from what people are usually searching for with "Hegel". Hegel.js would be a slight upgrade, but it is only referred to as "Hegel" in the main repo and website.
  - runarberg 4y ago
    I usually just append js to my search and get exactly what I want
  - jhanschoo 4y ago
    I search npm <insert library here>, to bring me to official documentation.
deleted 4y ago
[deleted]
TheRealPomax 4y ago
I understand why marketing would insist, but "Hegel attempts to prevent runtime TypeErrors with a strong type system" sounds like "we haven't been paying attention to the JS landscape for the last few years and didn't know TypeScript already existed"? And if it's just a better TS tool chain... that'd be worth calling out.
- sergiomattei 4y ago
  I thought the same thing, but they have a page that explains it pretty well — TypeScript v. Hegel Turns out Hegel makes it a goal to be provably correct in respect to types, whereas TypeScript makes tradeoffs for productivity.
- andrewmcwatters 4y ago
  https://github.com/JSMonk/hegel#benefits-over-typescript https://github.com/JSMonk/hegel#benefits-over-typescript
  - TheRealPomax 4y ago
    Hmm... const numbers: Array<number> = []; // HegelError: Type "Array<number>" is incompatible with type "Array<number | string>" const numbersOrStrings: Array<string | number> = numbers; The very first example is already an odd choice, given that <number> is type-compatible with <string|number>. Errors should be flagged once we try to call functions on the elements, with calls on number[...] validated based on <number>, and calls on numbersOrStrings[...] validated based on the shared API between <string> and <number> (which is a tiny API surface, but there is one). numbersOrStrings[1] = "Hello, TypeError!"; Why is this not an error based on the incorrect assignment we already had? "HegelError: cannot assign to alias numberOfStrings of numbers, numbers is of type <number>". // HegelError: Property "toFixed" does not exist in "Number | undefined" numbers[1].toFixed(1); Heck even this error is weird: we declared numbers as an array of <number>, not an array of <number|undefined>. If you're going to be that strict, track list sizes and go "HegelError: Property numbers[1] is undefined, which is type-incompatible with <number>".
    - 4y ago
lucideer 4y ago
I noticed that the syntax choices differed ever so slightly from Typescript - given the project is 4 years old & TS is 10, this seemed an odd choice for some of the more arbitrary syntax decisions. But then I realised it seems to follow Facebook's flow syntax a little more closely. I wonder if there's any shared heritage.
- thayne 4y ago
  The syntax is simpler. Less operators and keywords. That has benefits for the implementation, and I think better compatibility with the type annotations proposal for ecmascript. It might also be easier to learn if you aren't already familiar with typescript.
xoac 4y ago
Terrible name
kamilafsar 4y ago
Smart move to be compatible with TypeScript’s declaration files. Not sure if this provides me enough benefit to move from TS. On the contrary it removes “non JS” features like enums. I can’t live without enums..
- brundolf 4y ago
  In TS, enums can be safely replaced with string unions. At my company we treat TS enums as an anti-practice
  - kamilafsar 4y ago
    Interesting, we’re the opposite: use enums where possible. We think it adds more clarity to the reader. Besides, sometimes number values make more sense then string values. Especially when you want to do bitwise operations, which are not possible on string unions.
    - brundolf 4y ago
      That's an interesting point about using number values- I have to say I've never needed to do a bitwise operation in JavaScript, though I know some high-performance projects like physics engines and the TypeScript compiler itself use them Still, I'd prefer: const MyNumericEnum = { One: 0b001, Two: 0b010, Three: 0b100 } as const type MyNumericEnum = typeof MyNumericEnum[keyof typeof MyNumericEnum] Just for explicitness. But that's my subjective opinion
  - zdragnar 4y ago
    Enums aren't simply strings, though they can be reified as such in JS if you assign string values to them. It's more appropriate to think of them as symbols (from a type perspective)- seeing `Direction.North` is a whole lot more semantically meaningful than the string "north" in code. More than that, refactoring tooling Just Works with enums. On the other hand, if you're passing strings around everywhere and attempt to refactor a type that is a union of strings, there's plenty of cases where refactoring tooling can't help you, and you get to manually clean up the errors.
mberning 4y ago
I’ll wait for Schopenhauer to come out.
- Eupraxias 4y ago
  Hear hear - elegance over verbosity!
  - runarberg 4y ago
    It has been argued that JS started out as Wittgenstein, with its prototypical approach objects instead of the Platonic ideal classes.
llamaLord 4y ago
I think the problem trying to build a new type system for JS in the current ecosystem is that so much of the value of the current solutions are provided by their deep IDE integration. Having a great type checker is great, but if I don’t get any of the IDE functionality etc, it’s losing half the value.
- lf-non 4y ago
  They seem to have a functional lsp server already.
gajus 4y ago
What's really missing is a seamless ability to add runtime checks to TypeScript. Otherwise, between Flowtype and TypeScript, static type checking is a solved problem in JS. Hegel is basically a less mature version of Flow. I preferred Flow over TS for the longest time, but let's face it – TS won in terms of absolute adoption, with very little prospect for anyone to take over.
- hermanradtke 4y ago
  Ya, something like zod needs to be part of the language.
  - eyelidlessness 4y ago
    It is! Zod is great. I don’t mean to undersell its value. But it’s more of a reference manual of how to effectively use the language features it uses, than something novel filling in gaps in the language.
    - lf-non 4y ago
      I don't understand what this means. Any sufficiently valuable general purpose library (which zod is) is a candidate for first-class inclusion in the language if it is useful for a sizeable majority of the language's audience. Zod is filling a gap in the language - runtime type checking. It is not the only one doing so, but the fact that there are several such solutions clearly indicates that there is a general need for it.
      - eyelidlessness 4y ago
        > I don't understand what this means. Any sufficiently valuable general purpose library (which zod is) is a candidate for first-class inclusion in the language if it is useful for a sizeable majority of the language's audience. The language doesn’t have, or at least makes not having a primary goal, any runtime. “The” language is JavaScript. TypeScript is just annotations of it. Really good annotations. So good that you can build them out of reliable runtime checks which are type guards, without even writing a single type definition except to infer from them. Zod is filling a gap in JavaScript. TypeScript is facilitating that.
throwawy9233342 4y ago
unfortunately, the project is on pause for the time being [1] [1]: https://github.com/JSMonk/hegel/issues/355#issuecomment-1075389775 https://github.com/JSMonk/hegel/issues/355#issuecomment-1075...
- manunamz 4y ago
  So...If we achieve world peace...We get strongly-typed/static-checking for javascript?
elif 4y ago
Is it because types in JavaScript are essentially ideological convention? Is that the hegel joke?
lf-non 4y ago
I wonder if this will be something that functional libraries like Ramda [1] or Sanctuary [2] will be able to benefit from. One of the reasons these libraries don't work so well with TS is that it doesn't have ML-style whole program inference and hence doesn't work so well with patterns like currying. Hegel seems more capable in that regard. [1] https://ramdajs.com/ https://ramdajs.com/ [2] https://github.com/sanctuary-js/sanctuary https://github.com/sanctuary-js/sanctuary
lacasito25 4y ago
Done in js, so guaranteed to be slow for large projects. What a shame
fbn79 4y ago
It's funny how this is project was submitted 5 times last couple of years and never got attention till now. https://news.ycombinator.com/from?site=hegel.js.org https://news.ycombinator.com/from?site=hegel.js.org Unfortunately the was in Ukraine stopped the developer to work on the project
thenerdhead 4y ago
Might be a fun tag line for a type checker to bring homage to Hegel's "to negate, preserve, and elevate." regarding the code analysis.

WFHRenaissance 4y ago

What motivated the name choice?

xoac 4y ago
"it's like, deep and stuff"
pxc 4y ago
I can't find any indication from the author, but: (Post-)Kantian epistemology/metaphysics is about trying to see what we can know of the structure and behavior of the world prior to (without) making empirical reference to it. Intuitively, the distinction between static analysis and dynamic analysis seems to parallel the relationship between rationalist/idealist/a priori epistemology and empiricist/materialist epistemology. Hegelian philosophy has also been taken up by some mathematicians and 'formalized' in terms of type theory and category theory. Lawvere did some work on 'categorifications' of Marx and Hegel, and I guess some HoTT people have also recently taken an interest in Hegel. You can find a little bit of background and references to other sources here: https://ncatlab.org/nlab/show/Hegel%27s+%22Logic%22+as+Modal+Type+Theory https://ncatlab.org/nlab/show/Hegel%27s+%22Logic%22+as+Modal...
- qualudeheart 4y ago
  Will we soon have formalizations of Nick Land and Marc Fisher? I imagine machine learning techniques could be of use here.
naet 4y ago
A huge pet peeve of mine is libraries appropriate existing topics as their name. Eleventy is a great name. When I search it I get nearly 100% Eleventy related results. Hugo is a not great name; if I search it and I get Hugo the movie, Hugo boss the fashion line, Hugo insurance company, etc. Next.js is an okay name, at least they explicitly include .js in the name and branding and all over their website to make it a bit more notable and manageable. Hegel is not a great name IMO. The search space is dominated by the well renowned philosopher, and if the library does get very popular, it begins to take away from what people are usually searching for with "Hegel". Hegel.js would be a slight upgrade, but it is only referred to as "Hegel" in the main repo and website.
- runarberg 4y ago
  I usually just append js to my search and get exactly what I want
- jhanschoo 4y ago
  I search npm <insert library here>, to bring me to official documentation.

deleted 4y ago

[deleted]

TheRealPomax 4y ago

I understand why marketing would insist, but "Hegel attempts to prevent runtime TypeErrors with a strong type system" sounds like "we haven't been paying attention to the JS landscape for the last few years and didn't know TypeScript already existed"? And if it's just a better TS tool chain... that'd be worth calling out.

sergiomattei 4y ago
I thought the same thing, but they have a page that explains it pretty well — TypeScript v. Hegel Turns out Hegel makes it a goal to be provably correct in respect to types, whereas TypeScript makes tradeoffs for productivity.
andrewmcwatters 4y ago
https://github.com/JSMonk/hegel#benefits-over-typescript https://github.com/JSMonk/hegel#benefits-over-typescript
- TheRealPomax 4y ago
  Hmm... const numbers: Array<number> = []; // HegelError: Type "Array<number>" is incompatible with type "Array<number | string>" const numbersOrStrings: Array<string | number> = numbers; The very first example is already an odd choice, given that <number> is type-compatible with <string|number>. Errors should be flagged once we try to call functions on the elements, with calls on number[...] validated based on <number>, and calls on numbersOrStrings[...] validated based on the shared API between <string> and <number> (which is a tiny API surface, but there is one). numbersOrStrings[1] = "Hello, TypeError!"; Why is this not an error based on the incorrect assignment we already had? "HegelError: cannot assign to alias numberOfStrings of numbers, numbers is of type <number>". // HegelError: Property "toFixed" does not exist in "Number | undefined" numbers[1].toFixed(1); Heck even this error is weird: we declared numbers as an array of <number>, not an array of <number|undefined>. If you're going to be that strict, track list sizes and go "HegelError: Property numbers[1] is undefined, which is type-incompatible with <number>".
  - 4y ago

lucideer 4y ago

I noticed that the syntax choices differed ever so slightly from Typescript - given the project is 4 years old & TS is 10, this seemed an odd choice for some of the more arbitrary syntax decisions. But then I realised it seems to follow Facebook's flow syntax a little more closely. I wonder if there's any shared heritage.

thayne 4y ago
The syntax is simpler. Less operators and keywords. That has benefits for the implementation, and I think better compatibility with the type annotations proposal for ecmascript. It might also be easier to learn if you aren't already familiar with typescript.

xoac 4y ago

Terrible name

kamilafsar 4y ago

Smart move to be compatible with TypeScript’s declaration files. Not sure if this provides me enough benefit to move from TS. On the contrary it removes “non JS” features like enums. I can’t live without enums..

brundolf 4y ago
In TS, enums can be safely replaced with string unions. At my company we treat TS enums as an anti-practice
- kamilafsar 4y ago
  Interesting, we’re the opposite: use enums where possible. We think it adds more clarity to the reader. Besides, sometimes number values make more sense then string values. Especially when you want to do bitwise operations, which are not possible on string unions.
  - brundolf 4y ago
    That's an interesting point about using number values- I have to say I've never needed to do a bitwise operation in JavaScript, though I know some high-performance projects like physics engines and the TypeScript compiler itself use them Still, I'd prefer: const MyNumericEnum = { One: 0b001, Two: 0b010, Three: 0b100 } as const type MyNumericEnum = typeof MyNumericEnum[keyof typeof MyNumericEnum] Just for explicitness. But that's my subjective opinion
- zdragnar 4y ago
  Enums aren't simply strings, though they can be reified as such in JS if you assign string values to them. It's more appropriate to think of them as symbols (from a type perspective)- seeing `Direction.North` is a whole lot more semantically meaningful than the string "north" in code. More than that, refactoring tooling Just Works with enums. On the other hand, if you're passing strings around everywhere and attempt to refactor a type that is a union of strings, there's plenty of cases where refactoring tooling can't help you, and you get to manually clean up the errors.

mberning 4y ago

I’ll wait for Schopenhauer to come out.

Eupraxias 4y ago
Hear hear - elegance over verbosity!
- runarberg 4y ago
  It has been argued that JS started out as Wittgenstein, with its prototypical approach objects instead of the Platonic ideal classes.

llamaLord 4y ago

I think the problem trying to build a new type system for JS in the current ecosystem is that so much of the value of the current solutions are provided by their deep IDE integration. Having a great type checker is great, but if I don’t get any of the IDE functionality etc, it’s losing half the value.

lf-non 4y ago
They seem to have a functional lsp server already.

gajus 4y ago

What's really missing is a seamless ability to add runtime checks to TypeScript. Otherwise, between Flowtype and TypeScript, static type checking is a solved problem in JS. Hegel is basically a less mature version of Flow. I preferred Flow over TS for the longest time, but let's face it – TS won in terms of absolute adoption, with very little prospect for anyone to take over.

hermanradtke 4y ago
Ya, something like zod needs to be part of the language.
- eyelidlessness 4y ago
  It is! Zod is great. I don’t mean to undersell its value. But it’s more of a reference manual of how to effectively use the language features it uses, than something novel filling in gaps in the language.
  - lf-non 4y ago
    I don't understand what this means. Any sufficiently valuable general purpose library (which zod is) is a candidate for first-class inclusion in the language if it is useful for a sizeable majority of the language's audience. Zod is filling a gap in the language - runtime type checking. It is not the only one doing so, but the fact that there are several such solutions clearly indicates that there is a general need for it.
    - eyelidlessness 4y ago
      > I don't understand what this means. Any sufficiently valuable general purpose library (which zod is) is a candidate for first-class inclusion in the language if it is useful for a sizeable majority of the language's audience. The language doesn’t have, or at least makes not having a primary goal, any runtime. “The” language is JavaScript. TypeScript is just annotations of it. Really good annotations. So good that you can build them out of reliable runtime checks which are type guards, without even writing a single type definition except to infer from them. Zod is filling a gap in JavaScript. TypeScript is facilitating that.

throwawy9233342 4y ago

unfortunately, the project is on pause for the time being [1] [1]: https://github.com/JSMonk/hegel/issues/355#issuecomment-1075389775 https://github.com/JSMonk/hegel/issues/355#issuecomment-1075...

manunamz 4y ago
So...If we achieve world peace...We get strongly-typed/static-checking for javascript?

elif 4y ago

Is it because types in JavaScript are essentially ideological convention? Is that the hegel joke?

lf-non 4y ago

I wonder if this will be something that functional libraries like Ramda [1] or Sanctuary [2] will be able to benefit from. One of the reasons these libraries don't work so well with TS is that it doesn't have ML-style whole program inference and hence doesn't work so well with patterns like currying. Hegel seems more capable in that regard. [1] https://ramdajs.com/ https://ramdajs.com/ [2] https://github.com/sanctuary-js/sanctuary https://github.com/sanctuary-js/sanctuary

lacasito25 4y ago

Done in js, so guaranteed to be slow for large projects. What a shame

fbn79 4y ago

It's funny how this is project was submitted 5 times last couple of years and never got attention till now. https://news.ycombinator.com/from?site=hegel.js.org https://news.ycombinator.com/from?site=hegel.js.org Unfortunately the was in Ukraine stopped the developer to work on the project

thenerdhead 4y ago

Might be a fun tag line for a type checker to bring homage to Hegel's "to negate, preserve, and elevate." regarding the code analysis.