Domain > hacklewayne.com

More information on this domain is in AlienVault OTX

DNS Resolutions

Date	IP Address
2025-03-31	18.67.0.38 (ClassC)
2026-01-20	3.175.34.17 (ClassC)

HTTP/1.1 200 OKContent-Type: text/html; charsetutf-8Content-Length: 36529Connection: keep-aliveDate: Tue, 20 Jan 2026 01:40:49 GMTApigw-Requestid: Xdd9Hg-pSwMEPDAServer: Rocketx-content-type-options: nosniffx-frame-options: SAMEORIGINPermissions-Policy: interest-cohort()X-Cache: Miss from cloudfrontVia: 1.1 e46509f22800a7c13e2737ab1c5f5990.cloudfront.net (CloudFront)X-Amz-Cf-Pop: HIO52-P3X-Amz-Cf-Id: BnNU1suK56ynb3kJ_GeGgPScNjsUfGl4sYqfJZlJJaCMKEOFM1PaGA

html>    head>        title> The empty type - no values? no problem! | Hackles blog /title>        meta nameviewport contentwidthdevice-width, initial-scale1.0 />        meta namedescription content(This is a section from my upcoming book "Strong Code : designing mission-critical applications")>                !-- Facebook Meta Tags -->        meta propertyog:url contenthttps://hacklewayne.com>        meta propertyog:type contentwebsite>        meta propertyog:title contentThe empty type - no values? no problem!>        meta propertyog:description content(This is a section from my upcoming book "Strong Code : designing mission-critical applications")>        meta propertyog:image contenthttps://s3.ap-southeast-2.amazonaws.com/hacklewayne.com/blog-opg.jpg>                !-- Twitter Meta Tags -->        meta nametwitter:card contentsummary_large_image>        meta propertytwitter:domain contenthacklewayne.com>        meta propertytwitter:url contenthttps://hacklewayne.com/the-empty-type-no-values-no-problem>        meta nametwitter:title contentThe empty type - no values? no problem!>        meta nametwitter:description content(This is a section from my upcoming book "Strong Code : designing mission-critical applications")>        meta nametwitter:image contenthttps://s3.ap-southeast-2.amazonaws.com/hacklewayne.com/blog-opg.jpg>        link relstylesheet hrefhttps://cdnjs.cloudflare.com/ajax/libs/github-markdown-css/2.10.0/github-markdown.min.css />        link relstylesheet hrefhttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/themes/prism.min.css />        link relstylesheet href/static/styles.css />    /head>    body classmarkdown-body>        header>            p>                a classtitle href/>Hackles blog/a>                br>                span classsubtitle>between the abstractions we want and the abstractions we get./span>            /p>            p classlinks>                a href/about>Strong Code - workshop & book/a>            /p>        /header>                            h1>The empty type - no values? no problem!/h1>        p>(This is a section from my upcoming book "Strong Code : designing mission-critical applications")/p>p>There are many ways to understand types and their relationships, but for practical purposes, I find this simple rule of thumb very helpful: count the values. Lets apply this rule to go over some of the less talked about, but very interesting types./p>p>As counting goes, we should start with the type with em>zero/em> value, the "empty" type. This type is typically built-in in languages with modern type systems. When its not, the empty type can come as a bit of a surprise. Therefore, lets start by defining our own to get a taste, before sneaking up to the built-in types./p>p>Defining an empty type is not as easy as it sounds: most types have, and need values to be useful. One definition is through an empty enum, as in the below C# snippet,/p>pre>code classlanguage-C#>enum Empty { }/code>/pre>p>As its name indicates, code>Empty/code> is an enum without any values defined. So, to a variable with the code>Empty/code> type, there is no way to assign a value. How is code>Empty/code> even useful?/p>p>With the exception of type casting that defeats the purpose of type safety, it stands to reason that any use case of code>Empty/code> must take advantage of the emptiness. One very cute use case is to create a type code>null/code>. This is not as silly as it sounds. Although types can be nullable in C#, code>null/code> itself is a value, not to be used directly as a type. But with code>Empty/code>, we can make this happen, see below,/p>pre>code classlanguage-C#>Empty? mustBeNull  null;/code>/pre>p>Try as you may, null is the only possible value for the variable code>mustBeNull/code>. How does it works? Well, much like a simple puzzle,/p>ol>li>any nullable type code>T?/code> accepts any value of code>T/code> or code>null/code>,/li>li>code>Empty?/code> accepts either a value of code>Empty/code> or code>null/code>,/li>li>code>Empty/code> has no value, so code>Empty?/code> can only hold code>null/code>. Therefore, code>Empty?/code> is equal to the type of code>null/code>./li>/ol>p>The cuteness aside, the point of interest is how types and values can be analysed logically, which is no coincidence, because types are effectively propositions, values and programs proofs, as established by the Curry-Howard correspondence./p>p>We shall continue our exploration and analysis with logical rigour. The next experiment is to place code>Empty/code> in the input position, a.k.a. as the type of a parameter to a function. See below,/p>pre>code classlanguage-C#>void UseRestrictedFeature(Empty stopSign){    // feature under development}/code>/pre>p>In this case, the function code>UseRestrictedFeature/code> gate-keeps a feature that is still being worked on, and should not be called yet (but lets assume its valuable to be exposed for the purpose of demonstration or documentation). Conventionally, its reasonable to use stern comments, scary and descriptive naming, or throwing exceptions at runtime to fend off overly eager users; code>Empty/code> simplifies such tasks; it is logically bullet-proof, and almost elegant: there is no way to construct a value for the parameter code>stopSign/code> of type code>Empty/code>, therefore assurance is given that code>UseRestrictedFeature/code> is not callable - despite being right there in plain sight!/p>p>Great. How about using code>Empty/code> as the output type? For example, how can we implement code>MakeNothing/code> below?/p>pre>code classlanguage-C#>Empty MakeNothing(){    // ??}/code>/pre>p>Because there is no way to construct any value of code>Empty/code> to return, code>MakeNothing/code> cannot return anything (not even a bare code>return;/code> that is still em>something/em>, not nothing). However, it doesnt mean code>MakeNothing/code> cannot be implemented. Many programming languages leave some kind of "loophole", usually found in two forms: throwing exceptions, or infinite loops (or recursion), see below,/p>pre>code classlanguage-C#>Empty MakeNothingByException(){    throw new NotImplementedException("Cannot be implemented!");}Empty MakeNothingByInfiniteLoop(){    while (true)    {        // do something...    }}/code>/pre>p>Both implementation are accepted by the type checker. Can you see the commonality between the throwing an exception and looping infinitely? The former jumps away from the current code block, and the latter never terminates; either way, the current function never runs to the point of returning any value, hence the return type of code>Empty/code> is somewhat plausible./p>p>In practice, like many languages, C# allows throwing an exception (or the infinite loop) to fit into any function with em>any/em> return type without upsetting the compiler. So the question is, whats the type of the em>lone/em> act of "throw an exception"?/p>p>The answer usually requires the presence of the built-in "empty" type, which is not available in C#, so we need to look at other modern languages, such as TypeScript, and its code>never/code> type. The choice of TypeScript brings other benefits: its support for structural typing makes code>never/code> more interesting than many other languages. For example, we can "rediscover" the code>never/code> type by manipulating other types to arrive at "emptiness", see below for a few examples,/p>pre>code classlanguage-TypeScript>// the keys of an empty map is also emptytype NoKeys  keyof {}// a union type with all member types excludedtype Reset  Exclude<foo | bar, bar | foo>// an intersection type with no overlaptype NoOverlap  number & string/code>/pre>p>The flexibility of TypeScript may be foreign to some readers, but the logic should be straightforward: each of the three types is equivalent to code>never/code>, because the definition is eventually reduced to the empty type./p>p>Now can see the type of "throw an exception" is actually code>never/code>, as shown below./p>pre>code classlanguage-TypeScript>function sayNever(): never {    throw new Error("never!")}// but this is also accepted!function sayNever(): string {    throw new Error("never!")}/code>/pre>p>OK, the bare act of "throw an exception" is clearly of type code>never/code>; but just like C#, it is also of type code>string/code>, or indeed, any other type, even if the execution em>never/em> gets to the point of returning anything at all! Why?/p>p>Practically speaking, we can make sense of this phenomenon in roughly two complementary ways,/p>ol>li>any attempt to construct a value of code>never/code>, the empty type, must always fail,/li>li>or, conversely, the value-less empty type is the sub-type of any other type./li>/ol>p>Lets start with the easier point. Any function with the power of terminating the current program, or entering an infinite loop, is able to avoid fulfilling the promise made in the return type; in other words, it must fail before returning./p>p>We may use this analogy: if a program is a small universe, then by code>never/code>, a function indicates the universe is collapsing, so it can claim with some credibility, "whats the point of bothering with the return type if the universe is ending?" Usually, compilers and IDEs are happy to acknowledge such claims - code that immediately follows a code>throw/code> statement is typically flagged as "unreachable"./p>p>Another way to make sense of this phenomenon is through sub-typing, namely, the empty type is the sub-type of all other types. Sounds strange? Its actually pretty simple: if type code>S/code> is the sub-type of type code>A/code> and code>B/code>, then the values of code>S/code> should be the intersection of the values of code>A/code> and code>B/code>. Then, whats the intersection of the values of em>all/em> the types in the universe, known and unknown to us? Clearly, it is non-existent; so the sub-type of em>all/em> types can only be empty. Its shown above, we dont need to bring in em>all/em> types to prove this - the intersection of two popular types code>number/code> and code>string/code> is enough to result in code>never/code>, the empty type./p>p>Lets see this through the type annotations. Seeing the exception-throwing function of type code>() -> never/code> is also accepted as code>() -> string/code>, or code>() -> T/code> in any generic code>T/code> (but not the other way around), we can connect the dots to find the "free" casting code>freeCast: never -> string/code>, or code>never -> T/code>; more formally this is stated as code>never <: T/code>, a.k.a. code>never/code> is assignable as any other type./p>p>This function code>freeCast/code> is well known by another name, code>absurd/code>. Its easy to see why: it is a preposterous claim to "make em>anything/em> from em>nothing/em>". More formally, this corresponds to the logical statement "from falsehood, anything (follows)". Or less formally but more interestingly, "when pigs fly, I will give away ten billion dollars". Its easy to make promises that one doesnt need to keep; but doing that too often can be problematic and ruins the fun - as is the case of throwing exceptions too liberally!/p>p>Back to programming reality, the understanding of code>never/code> as the sub-type of all types, is helpful in making sense of many seemingly strange features. For example, in Kotlin, we can use code>TODO/code> to indicate that a function is yet to be implemented, as below./p>pre>code classlanguage-Kotlin>fun sayNever(): Nothing  TODO("never!")fun <T> sayAny(): T  TODO("any!")/code>/pre>p>Newbies to Kotlin may suspect code>TODO()/code> is built-in marker with special treatment. Thats not the case upon a closer inspection: code>TODO()/code> is normal function that returns code>Nothing/code>, Kotlins equivalent to TypeScripts code>never/code>. Guess its implementation? Simply code>throw NotImplementedError()/code>. Just like code>never/code>, code>Nothing/code> is the sub-type of any other type, therefore code>TODO()/code> fits in seamlessly to any function. Its not special at all!/p>p>So far, weve tried to reason with code>never/code> from the angle of values, or lack thereof. Sure, Its satisfying to be able to unify exceptions and infinite loops through sub-typing, but given the ugly nature of these constructs, such unification can feel a bit stretched, or (if I am honest) at least takes a bit getting used to. Luckily, such righteous ugliness is not the only reason to use the empty type; in fact, there are elegant ways to use it to express logical inevitability; this is typically done in combination with other types./p>p>For a start, consider this challenge (well use Kotlin as the segue has been made): given the standard list type code>List<T>/code>, how do we give type to a function parameter, so any accepted argument for this parameter is guaranteed to be an em>empty/em> list?/p>p>There are many value-level methods, such as validation: checking the size of the list, and throw an exception if its 0. Thatll work, but is boring and ugly for the use of exceptions. Taking advantage of the empty type, the expression of the empty list can be simpler, and more sound. Consider the function code>resetState/code> that resets the state (particularly the "rewards") of a game, as below,/p>pre>code classlanguage-TypeScript>function resetState(initialRewards: never): Reward  {    // some reward may be sprinkled on    return newReward, ...initialRewards}/code>/pre>p>Firstly, we know that code>never/code> is assignable to code>Reward/code> because code>never/code> is the sub-type of any other type; but how are we em>absolutely/em> sure code>initialRewards: never/code> must be empty? Well, this is but a simple logical puzzle: for code>initialRewards: never/code> to be non-empty, it must have at least one element, which is required to be of type code>never/code>; however, there is no value to be found of type code>never/code>, therefore, code>never/code> must always be empty./p>p>In other words, while code>never/code> is void of any value, code>never/code> can only have one value, the empty list, which is assignable to any type code>T/code>, or used to build bigger lists, while doing its part to enforce good behaviour, as below,/p>pre>code classlanguage-TypeScript>// The type annotation `never` is necessary, or TypeScript infers `any`.const emptyList: never  ;const emptyListOfRewards: Reward  emptyList;const withNewReward: Reward  newReward, ...emptyListOfRewards;// Argument of type Reward is not assignable to // parameter of type never.ts(2345)// emptyList.push(newReward);/code>/pre>p>We can see while its perfectly logical to build a list of code>Reward/code> from an empty list code>never/code> (through an immutable list concat operation), it remains allergic to mutation such as code>push(newReward)/code> which would violate the type code>never/code>. The type systems does well to ensure the logical consistency, making it difficult to break the guaranteed emptiness. As an aside, we also see (or keep seeing) new bits of evidence how immutability goes hand-in-hand with stronger typing./p>p>Compared to TypeScripts code>never/code>, code>Nothing/code> in Kotlin is essential in the design of sealed interfaces - a flavour of union types. For example, the popular code>Result<V, E>/code> union type can be defined with two member types, code>Success<V>/code> and code>Failure<E>/code>, as below,/p>pre>code classlanguage-Kotlin>sealed interface Result<V, E> {    data class Success<V>(val value: V): Result<V, Nothing>    data class Failure<E>(val error: E): Result<Nothing, E>}val s1  Result.Success(aUsefulValue)val e1  Result.Failure(aHelpfulError)/code>/pre>p>Something clever is on display: the sealed interface code>Result<V, E>/code> does not specify the usage of code>V/code> or code>E/code>, which is deferred to the concrete types, such as code>Success<V>/code>, which implements code>Result<V, E>/code> by selectively using code>V/code> for fields code>value/code>, and sets code>E/code> to code>Nothing/code>. Its meaning? A code>Success<V>/code> value will never contain an "error"; similarly, code>Failure<E>/code> will not have any "success" value. The mutually exclusive em>invariant/em> is guaranteed by the types, instead of making code>value/code> and code>error/code> both nullable, and ensuring the invariant with runtime null checks and throwing exceptions./p>p>You would have guessed, there is no value of type code>Result<Nothing, Nothing>/code>, but thats an inevitability of using code>Nothing/code> twice, but because there is no such member type in code>Result<V, E>/code>; its perfectly fine to add a such a third member type that uses neither of code>V/code> or code>E/code>./p>p>Because code>Nothing/code> descriptively expresses "no value", it leads to a popular pattern of error-modelling, as below,/p>pre>code classlanguage-Kotlin>sealed interface PaymentResult<out T>data class OK(val cfm: Confirmation): PaymentResult<Confirmation>data class Rejected(val reason: Rejection): PaymentResult<Nothing>data class Timeout(val elapsed: Duration): PaymentResult<Nothing>fun makeFakePayment(): PaymentResult<Nothing> {    TODO("this must not succeed")}val notAlwaysSuccess: PaymentResult<Confirmation>  Timeout(TimeoutError)/code>/pre>p>The pattern lies in the choice of code>T/code> in each member type of code>PaymentResult<out T>/code>: only the success type exposes code>Confirmation/code> through code>T/code>, the "failure" types simply pick code>Nothing/code> instead of more specific type of the contained error./p>p>This dichotomy by choice is intention-revealing: by returning code>PaymentResult<Nothing>/code>, code>makeFakePayment()/code> must produce a "failure" type, because success would require the return type to be code>PaymentResult<Confirmation>/code>./p>p>So does code>PaymentResult<Confirmation>/code> always indicate success? Not necessarily. Remember code>Nothing/code> is the sub-type of code>Confirmation/code>, so code>PaymentResult<Nothing>/code> is assignable to code>PaymentResult<Confirmation>/code> (note the "assignability" is enabled by the use of co-variance in code>out T/code>). To precisely indicate success, one must use the code>OK/code> member type./p>p>Despite the popular pattern, its inaccurate and unhelpful to equate code>Nothing/code> to errors. Consider the exercise of modelling how different activities suit different weather and mood, as below,/p>pre>code classlanguage-Kotlin>interface Weatherinterface Sunny : Weatherinterface Rainy : Weatherinterface Moodinterface Dark : Moodinterface Bright : Mood// combination of weather and moodinterface SunnyAndBright : Sunny, Brightinterface RainyAndDark : Rainy, Darkinterface Suits<out T>// each activity suits different weather and mooddata object KiteFlying : Suits<SunnyAndBright>data object Pool : Suits<RainyAndDark>/code>/pre>p>For brevity we use em>empty/em> interfaces to represent different weather and mood, and compose them with more empty interfaces; each empty code>data object/code> (again for brevity) suits different weather and mood. The choice of rainy and dark for pool is largely speaking for myself!/p>p>Then we found there are activities that suit almost any weather, mood, time, companion, or food. Such as watching a movie. How could that be expressed? Of course we can combine all conditions into a single interface, or, we can simply use code>Nothing/code>, as below,/p>pre>code classlanguage-Kotlin>data object Movie : Suits<Nothing>val rainyActivity : Suits<Rainy>  Movieval sunnyActivity : Suits<Sunny>  Movie// Any doesnt work!data object Film : Suits<Any>// initializer type mismatch: expected Suits<Bright>, actual Film.// val brightActivity: Suits<Bright>  Film/code>/pre>p>This works because - now you know as much as I do - code>Nothing/code> is a sub-type of any other type. In this case, it definitely does not indicate errors!/p>p>If you had the thought of using code>Any/code> in the place of code>Nothing/code>, it wont work, although code>Suits<Any>/code> sounds much more intuitive than code>Suits<Nothing>/code>. It is through such seeming contradictions that programming shows its true colours as a logical exercise rather than a literary one./p>                footer>            p>Last updated on 17-Nov-2025/p>            p>                See also                ul>                                            li>a href/singleton-types-not-the-design-pattern-in-c-kotlin-and-others>Singleton types (not the design pattern!) in C#, Kotlin and others/a>/li>                                            li>a href/type-safe-gadt-in-kotlin-who-needs-haskell>Type safe GADT in Kotlin - who needs Haskell?/a>/li>                                            li>a href/dependent-extensible-the-curious-case-of-union-type-in-kotlin>Dependent? Extensible? The curious case of union type in Kotlin/a>/li>                                            li>a href/using-with-are-lame-rust-wins-resource-management>Using, with are lame. Rust wins resource management/a>/li>                                            li>a href/accidentally-coupled-the-worst-coupling-by-loose-coupling>Accidentally coupled! The worst coupling by loose coupling/a>/li>                                            li>a href/scan-is-zip-laziness-and-recursion-strike-again>Scan is Zip? Laziness and recursion strike again!/a>/li>                                            li>a href/your-generics-may-be-different-than-mine>Your Generics may be different than mine/a>/li>                                            li>a href/applicative-and-monad-confusion-in-effect>Applicative and Monad: confusion in effect/a>/li>                                            li>a href/constructive-code-an-aimless-exploration>Constructive code - an aimless exploration/a>/li>                                            li>a href/down-isp-ioc-dependency-rule-and-how-to-stop-lying-code>DOWN, ISP & IoC: dependency rule #1, and how to stop lying code/a>/li>                                            li>a href/functional-programming-choose-haskell-f-because-syntax-matters>Functional Programming: Choose Haskell / F# Because Syntax Matters/a>/li>                                            li>a href/a-square-is-a-rectangle-if-designed-correctly>A Square IS A Rectangle - If Designed Correctly/a>/li>                                            li>a href/state-monad-a-bit-of-currying-goes-a-long-way>State Monad: a bit of currying goes a long way/a>/li>                                            li>a href/extends-in-typescript-inheritance-upper-bounds-conditional-distributive-and-variance>extends in TypeScript: inheritance, upper bounds, conditional, distributive and variance/a>/li>                                            li>a href/convenience-driven-development-a-story-of-two-exceptions>Convenience Driven Development: A story of two exceptions/a>/li>                                            li>a href/convenience-driven-development-the-grandfather-paradox-and-equality>Convenience Driven Development: the Grandfather Paradox and Equality/a>/li>                                            li>a href/composition-over-aggregation-not-just-inheritance>Composition over aggregation, not just inheritance/a>/li>                                            li>a href/libraries-should-not-provide-interfaces-for-dependency-injection-and-stop-asking>Libraries should not provide interfaces for Dependency Injection - and stop asking/a>/li>                                            li>a href/parsing-with-parsec-or-optional-retry-and-back-tracking>Parsing with Parsec: or, optional, retry and back-tracking/a>/li>                                            li>a href/stringly-typed-it-s-not-that-simple>Stringly-typed: it's not that simple!/a>/li>                                            li>a href/one-recursion-for-all-catamorphism-step-by-step>One recursion for all! Catamorphism step by step/a>/li>                                            li>a href/postel-s-law-is-simple-to-fulfil-the-potential-of-your-code>Postel's law is simple - to fulfil the potential of your code/a>/li>                                            li>a href/unions-are-untagged-and-should-be-discriminated-in-typescript-undecidable-collapse-and-anti-patterns>Unions are Untagged, and should be Discriminated in TypeScript: undecidable, collapse, and anti-patterns/a>/li>                                            li>a href/patch-friendly-types-null-confusion-undefined-envy-and-maybe-maybe>PATCH-friendly types: null confusion, undefined envy and maybe maybe/a>/li>                                            li>a href/void-vs-unit-respect-the-honesty-of-void>void vs unit: Respect the Honesty of void/a>/li>                                            li>a href/reflections-broken-promises-and-fake-generics-the-anti-pattern>Reflections, Broken Promises and Fake generics: the anti-pattern/a>/li>                                            li>a href/generics-are-you-keeping-it-generic>Generics: are you keeping it generic?/a>/li>                                            li>a href/abilities-by-birth-separation-of-types-data-and-behaviour>Abilities by birth? Separation of types, data and behaviour/a>/li>                                            li>a href/type-witness-not-yet-typescript-sure-thing-haskell>Type Witness: not yet TypeScript, sure thing Haskell/a>/li>                                            li>a href/on-the-geometric-beauty-of-programming>On the geometric beauty of programming/a>/li>                                            li>a href/not-assignable-a-must-cast-situation-typescript-wise-as-any>Not assignable? A must-cast situation! TypeScript, wise 'as any'/a>/li>                                            li>a href/functions-and-classes-don-t-mix-not-always>Functions and classes don't mix - not always/a>/li>                                            li>a href/readability-misses-the-point-look-instead-at-vocabulary>Readability misses the point - look instead at vocabulary/a>/li>                                            li>a href/is-typescript-turing-complete-not-sure-game-of-life-why-not>Is TYPEScript Turing complete? Not sure. Game of life? Why not!/a>/li>                                            li>a href/golang-error-handling-yes-to-values-no-to-exceptions-a-win-for-the-future>Golang error handling: yes to values, no to exceptions, a win for the future/a>/li>                                            li>a href/typescript-fireworks-union-intersection-and-variance>TypeScript Fireworks: Union, Intersection and Variance/a>/li>                                            li>a href/typescript-convert-union-to-tuple-array-yes-but-how>TypeScript: Convert Union to Tuple/Array, Yes but How?/a>/li>                                            li>a href/types-or-operations-keep-it-closed-or-keep-it-open>Types or Operations: keep it closed, or keep it open/a>/li>                                            li>a href/ad-hoc-polymorphism-same-input-different-output-still-pure>Ad-hoc polymorphism: Same input, different output, still pure/a>/li>                                            li>a href/architecture-you-mean-spreadsheets>Architecture? You mean spreadsheets?/a>/li>                                            li>a href/a-taste-of-rust>A taste of Rust/a>/li>                                            li>a href/your-tests-may-belong-elsewhere>Your tests may belong elsewhere/a>/li>                                            li>a href/dependency-hell-not-if-we-use-functions-for-library-authors>Dependency hell? Not if we use functions! For library authors/a>/li>                                            li>a href/linq-is-lazier-not-by-too-much-just-within-range>Linq is Lazier, not by too much, just within Range/a>/li>                                            li>a href/the-typescript-handbook-optional-parameters-and-postel-s-law>The TypeScript Handbook, Optional Parameters and Postel's Law/a>/li>                                            li>a href/on-accidental-code-deletion-as-reason-for-unit-testing>On accidental code deletion as reason for unit testing/a>/li>                                            li>a href/a-truly-strongly-typed-printf-in-typescript>A truly strongly-typed printf in TypeScript/a>/li>                                            li>a href/literal-type-preservation-with-typescript>Literal type preservation with TypeScript/a>/li>                                            li>a href/dependent-types-in-typescript-seriously>Dependent Types in TypeScript, Seriously/a>/li>                                            li>a href/also-on-comonad-and-conway-s-game-of-life>Also on Comonad and Conway's game of life/a>/li>                                            li>a href/self-referenced-json>Self-referenced JSON?/a>/li>                                            li>a href/plain-and-simple-state-management>Plain and simple state management/a>/li>                                            li>a href/the-constants-file-is-an-anti-pattern-so-is-the-interface-folder-placement-by-functionality-not-technical-concerns>The 'Constants' file is an anti-pattern, so is the 'Interface' folder. Placement by functionality, not technical concerns/a>/li>                                            li>a href/setting-cap-loose-in-real-life>Setting CAP loose in real life/a>/li>                                            li>a href/tuck-away-and-take-one-whatever-it-takes-to-look-declarative>Tuck-away and take-one, whatever it takes to look declarative/a>/li>                                            li>a href/the-diamond-squashed-and-recovered>The Diamond, squashed and recovered/a>/li>                                            li>a href/dependent-types-in-typescript>Dependent types in TypeScript?/a>/li>                                            li>a href/reducer-to-reduce-with-lens-in-oo-flavour>Reducer to reduce, with lens in OO flavour/a>/li>                                            li>a href/nesting-and-positions-in-covariance-and-contravariance>Nesting and positions in covariance and contravariance, /a>/li>                                            li>a href/t-d-d-is-most-practical-data-driven-with-pure-functions>T.D.D. is most practical data-driven with pure functions/a>/li>                                            li>a href/covariance-and-contravariance>Covariance and contravariance/a>/li>                                            li>a href/the-magic-const-identity-and-tuple>the magic Const, Identity and tuple/a>/li>                                            li>a href/out-of-context-string-template-is-an-anti-pattern>Out-of-context string template is an anti-pattern/a>/li>                                            li>a href/types-names-and-type-superstition>Types, names, and type superstition/a>/li>                                            li>a href/types-and-tests-javascript-idris>Types and tests: JavaScript 10, Idris 0/a>/li>                                            li>a href/layer-architecture>2-layer architecture/a>/li>                                            li>a href/don-t-null-check-just-continue>Don't null check, just continue!/a>/li>                                            li>a href/make-unit-testing-a-breeze-by-segregating-complexity>Make unit testing a breeze by segregating complexity/a>/li>                                            li>a href/inject-functions-not-interfaces>Inject functions, not interfaces/a>/li>                                            li>a href/foldl-in-terms-of-foldr>foldl in terms of foldr/a>/li>                                            li>a href/serialize-like-javascript-the-idea>Serialize like javascript - the idea/a>/li>                                            li>a href/serialize-like-javascript-mergejson-in-idris>Serialize like javascript - MergeJSON in Idris!/a>/li>                                            li>a href/my-take-on-unit-testing>My take on (unit) testing/a>/li>                                            li>a href/callcc-in-haskell-and-my-ultimate-monad>callCC in Haskell, and my ultimate Monad/a>/li>                                            li>a href/coding-an-alternative-vect-index-type-driven-development-in-idris>Coding an alternative Vect.index, Type-Driven Development in Idris/a>/li>                                            li>a href/fin>Fin/a>/li>                                            li>a href/lens-really-record-viewer-updater-in-typescript>Lens (really record viewer / updater) in TypeScript/a>/li>                                            li>a href/linq-infinity-laziness-and-oh-my>LINQ, infinity, laziness and oh my!/a>/li>                                    /ul>            /p>            hr>            a href/about>About me and this blog, or get in touch/a>        /footer>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/prism.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-haskell.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-csharp.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-fsharp.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-css.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-javascript.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-typescript.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-kotlin.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-rust.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-go.min.js>/script>        script srchttps://cdnjs.cloudflare.com/ajax/libs/prism/1.14.0/components/prism-python.min.js>/script>        script src/static/prism-idris.js>/script>    /body>/html>

View on OTX | View on ThreatMiner

Data with thanks to AlienVault OTX, VirusTotal, Malwr and others. [Sitemap]

Domain > hacklewayne.com

Is this malicious?

DNS Resolutions

Port 80

Port 443