TypeScript at Google - <AUTHOR> http://neugierig.org/software/blog/2018/09/typescript-at-google.html <comment><USER4> > The first tempting option is to just abandon this ruined planet and settle a > new one that doesn't even involve JavaScript. If only we invested more in > GWT (a Google project that compiles Java to JavaScript) or Dart (a Google > project that compiles a new language to JavaScript) or WASM or [insert your > favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry > about JavaScript at all!

I thought about this for quite a while when we started on TypeScript at Google (I work on this with Evan). I've convinced myself that using a different language cannot solve the problem that we're looking at.

The argument goes like this: if you use a different language than JavaScript for front end development, you're (hopefully) doing it for a reason. That is, you (a) want the other languages semantics (e.g. bounds checks on array accesses, runtime types, method dispatch, you name it), or you (b) might want the programming languages ecosystem - editors, IDEs, etc; but most importantly libraries and frameworks. Most likely, you're looking for a combination of (a) and (b).

The problem with (a) is that the more different the runtime semantics of your programming language are, the more emulation code you need. Emulation code is costly in code size, performance, interop with JS, and often understandability (at some point you will need to debug the output, believe me).

The problem with (b) is that you typically opt into a large ecosystem that was originally written for a very different environment. This was a big issue with GWT: people would pull Java libraries, but those libraries, amazing as many are, were not written for the web or with code size in mind. This meant using a common library like Guava required a lot of engineering effort to keep code size in check. This also applies to WASM, possibly even more so.

These mechanisms work together to make it very hard to hit the sweet spot between performance, developer experience, and interoperability. And ironically, the better you get at the goals you're aiming for (different semantics, different ecosystem), the farther you get away from a working solution.

I don't think it's impossible to achieve a transpile-to-JS language that works really well with enough investment, but keeping in mind the other reasons Evan lists (mind share, existing code base), incrementally improving JavaScript where needed is IMHO the much more promising approach.

<comment><USER5> This is a super interesting perspective. It seems to me that another way to strike this very tricky balance is to design a language with it in mind - <USER2> that you can choose semantics with the emulation trade-off explicitly taken into account - and invest very heavily in its ecosystem - so that you can catch up on the library, framework, and IDE front. Arguably both Dart and TypeScript (among others) are doing the first part of that, but only TypeScript is doing the second part. I guess there's a third important part too: choosing a really good set of semantics based on that trade-off. I think TypeScript has really nailed that one. I like Dart and Elm too, but TS is definitely in the sweet spot for me.

<comment><USER6> Unfortunately, to take this approach you generally need it to be a _new_ language, so it doesn't have existing ecosystem baggage to carry along, which means it is less likely to win on another axis you often care about: developer familiarity.

This is why the candidates in this space are only the upcoming ones like Dart, Elm, and maybe Kotlin. The other "compile to web" approaches that use more established languages (like emscripten for C++ or GWT for Java) tend to produce larger binaries due to carrying along their ecosystem.

This is restating GP's point, but to say it again, this tradeoff is kind of inevitable -- half the reason to want to transpile is to reuse knowledge and libraries, but then by reusing those libraries you kill your binary size.

(This dynamic reminds me of all the people who hoped they'd be able to reuse their existing web apps on mobile but ended up with bad mobile apps. I think it's possible to make a good web-based app work on mobile but it's often a rewrite from an existing web site, at which point you're often rewriting anyway and might as well use a mobile-native language.)

</comment></comment></comment><comment><USER7> I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious.

My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.

<comment><USER8> Have you spent any real time with Flow?

As I'm starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn't look like the React ecosystem has really decided which way to go.

TypeScript is popular. But flow was developed by Facebook and so it's obviously heavily used by some of the top people.

I've only been reading about them, I haven't chosen to use one yet. But I've been leaning on flow since it's developed by the React team at Facebook.

<comment><USER9> Although it's clear that Facebook's libraries, among which React, favour Flow, there's strong community demand for TypeScript even around React. Thus, the type definitions that are available for React are excellent, Redux even includes its type definitions natively, and most of the large tools in the React ecosystem work pretty well with TypeScript.

The main large project you're likely to use that does not really play well with TypeScript yet is create-react-app. There's a TypeScript fork [1] which works reasonably well, but "reasonable" is not really what you'd hope.

That said, the strong community push means that they're at least considering it. [2]

[1] [https://github.com/wmonk/create-react-app- typescript](https://github.com/wmonk/create-react-app-typescript) [2] [https://github.com/facebook/create-react- app/pull/2815](https://github.com/facebook/create-react-app/pull/2815)

<comment><USER10> We're actually looking at removing the type definitions from the Redux core and punting them over to DefinitelyTyped, because neither of us primary maintainers use TS ourselves and we don't have the experience to maintain the type definitions.

Also, the CRA-TS fork runs, but the one time I played with it was when I tried to help another team set up their project, and that's when I found out it has _ridiculously_ restrictive default linting rules. Every lint error is a compile error, and it flags things like using arrow functions in render methods, which is absurd (see discussion at [https://github.com/wmonk/create- react-app-typescript/issues/...](https://github.com/wmonk/create-react-app- typescript/issues/333) ).

<comment><USER11> The first thing I do in a new CRA-TS project is make the tslint.json rules default to warnings instead. Or just disable them completely. After that, it's great! I'm actually surprised that they still haven't loosened the rules after Dan called it out a month or two ago. Seems like an easy enough fix to at least make them warnings until they choose better defaults.

</comment></comment></comment></comment></comment><comment><USER12> _> If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all!_

I'm on the Dart team. I don't know if the author intended this, but you could read this as saying that Google isn't investing much in Dart, which isn't true.

Flutter and Fuchsia are the high profile projects that use Dart. AdWords is also built in Dart. The Dart team itself is as large as its ever been and growing. (I'd give more precise numbers, but Google generally shies away from publicly stating personnel details.) We have a ton of internal and external code written in Dart, and it's growing at a nice clip.

Different projects have different needs. If you have a large existing JS corpus that's providing a lot of value for you, then an incremental migration to TypeScript makes sense.

If you're looking to rewrite a lot of code and pay off technical debt anyway, then moving to a new language that doesn't have all of JavaScript's baggage can be a smarter choice. Dart has a cleaner object model and fewer warts like "===", etc. Making a bigger break from JS means that Dart's type system can be simpler than TypeScript's and is sound. That in turn means the compiler can rely on types for optimization and minification.

<comment><USER13> I mostly know Typescript, but I'd like to learn more about Dart... particularly where the type system differs in theory. Do you have a good recommended article on that?

The other question is the community one: if Dart requires type bindings (like TS .d.ts files) to the large community of JS projects, how does it plan to solve the kickstart problem. It's taken TS community many years to over just the popular js libraries out there. Imho, I'd make a utility to convert/translate TS definitions into Dart wrappers... but that would require to support TS primitives almost 1:1.

None of this is meant to sound critical, I'm just genuinely curious on the process of language development.

<comment><USER12> _> Do you have a good recommended article on that?_

I don't, but I agree it would be useful. We're not where I wish we were in terms of docs right now.

 _> if Dart requires type bindings (like TS .d.ts files) to the large community of JS projects, how does it plan to solve the kickstart problem._

We actually have a tool that will generate the proper Dart interop bindings given a TypeScript .d.ts file:

[https://github.com/dart-lang/js_facade_gen](https://github.com/dart- lang/js_facade_gen)

 _> It's taken TS community many years to over just the popular js libraries out there._

Dart is different from TypeScript in that we are deliberately a more batteries-included system. We wrote and maintain a full set of core libraries (collections, async, etc.) and Google has a well-funded team to ship and maintain a full-featured web framework (AngularDart).

So we aren't _as_ stuck needing to rely on the JS ecosystem as TypeScript is. There is still tons of useful functionality that's available in JS and not yet Dart, which is why interop is important, but we have a lot of customers that can get by without needing much or any JS interop.

</comment></comment></comment><comment><USER14> Google has enough resources for someone to write a transpiler that can take annotated JS and convert most of it to TypeScript. It's certainly much more pleasant than having to type random comments everywhere, which kinda makes syntax highlighting way less useful. Oh, and last I checked there were no editor plugins for linting Closure Compiler annotated code.

Another option would be to add TypeScript support to Closure Compiler, although it doesn't seem likely since there's no spec to guarantee compatibility.

I'd love to see Facebook, Google, and Microsoft team up in this space, instead of creating 3 separate but very highly similar tools.

Also, while we're talking about Closure, let's take a moment to appreciate its amazing UI toolkit [0]. I'd still consider many of their widgets to be the gold standard. It's written with desktop clients in mind and is incredibly feature-complete. I believe it also has pretty good accessibility, although I haven't personally tried that out. Oh, and don't forget the i18n as well! The closure library definitely has a lot of quirky aspects to it, but it's still quite amazing if you consider its age and how much stuff it supports. It's worth taking a few minutes to browse through their docs [1].

[0] [https://google.github.io/closure- library/source/closure/goog...](https://google.github.io/closure- library/source/closure/goog/demos/index.html)

[1] [https://google.github.io/closure- library/api/](https://google.github.io/closure-library/api/)

<comment><USER15> [http://www.syntaxsuccess.com/viewarticle/closure-compiler- vs...](http://www.syntaxsuccess.com/viewarticle/closure-compiler-vs-rollup-vs- webpack) \- interesting article about how closure enables smaller bundle sizes.

I agree, it would be cool for someone to do the same thing for Typescript, I seem to remember a repo a while back on Github that said someone was experimenting with it - cant for the life of me remember where though!

<comment><USER15> didn't read the other comment on this - [https://github.com/angular/tsickle](https://github.com/angular/tsickle) was the repo

</comment></comment></comment><comment><USER16> I feel like this sort of organic growth (for typescript) is a very healthy sign for a project.

ES6 (or whatever we're supposed to refer to it as now) is good enough for many things, but when you see it used heavily with, for example, proptype hints... you get the feeling that there really is a trend these days towards flavoring static type checking and the error checking that offers.

I think its an interesting shift, with python and javascript both being poster child dynamic languages, but people who use them seriously going... 'yeah, type checking is actually pretty handy...'.

<comment><USER17> Sorry if this is a well known term but what is a "proptype hint" in this context? I can't seem to find any references for '"proptype hint" "javascript"' or any variations that come to mind on Google.

Edit - changed previous sentence to "proptype hint". I originally erroneously read the parent as saying "prototype hint" which I couldn't find results for, but even after correcting my reading error my question still stands.

<comment><USER16> github.com/facebook/prop-types is the 2nd google search result for this term, and is what I was referring to, although the first result (devhints.io/react#property-validation) is arguably a better summary.

Ie. 'lite' type checking, used in react.

(did you perhaps see the results for 'javascript prop type hint' as a google autocorrect suggestion or something? This _is_ a well known term, but I'm pretty amazed two seconds of google didn't discover what it was...)

<comment><USER18> I read it and thought you were referring to something related to some proptype based code completion. The use of 'hinting' threw me off completely, especially when you're talking about _checking_ & _validating_.

</comment></comment></comment></comment><comment><USER19> I wonder if it's worth migrating from Flow to TypeScript?

Flow has been great, but I've just tried to update to the latest version and I'm dealing with a flood of indecipherable errors, especially from the react- dnd library. Looks like no-one is really maintaining the flow types so I'm on my own, and I don't even know where to start.

I also haven't been able to track down some errors, like "Cannot read property 'foo' of undefined". Flow thinks that this variable can never be undefined, and I have no idea how it's happening. It might even be a bug in Immutable.js, but I have no idea.

So if TypeScript is more popular and has a bigger community, then maybe it's worth migrating just so I can get more help with these issues. And maybe TypeScript will catch more cases as well.

<comment><USER20> That's what I did. I switched to TypeScript after two years of being both heavily invested in Flow and advocating it.

The reason I initially chose Flow was the fact that their goals were more ambitious (trying to build a sound type system for example). And there were features that Flow had and TypeScript didn't (tagged unions for example).

The reason I ultimately switched to TypeScript was that after a couple of years, it had simply caught up and surpassed in the one area it was behind Flow (i.e. expressiveness of the type system and type-level programming), and that it had widened the lead in the areas that it was always better at, like much better tooling, bigger community, core team being more engaged with the community, releasing RCs to smooth out the rough edges, etc.

So yes, I switched to TypeScript, and I see that I'm spending less time working around the type system's quirks and more time getting things done. I'm also very much enjoying the fact that I can express types in TS that I never could in Flow. So my codebase has much better type coverage in TypeScript than it did with Flow.

[0] [https://www.typescriptlang.org/docs/handbook/advanced- types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)

<comment><USER21> > much better tooling

If you have the time, would you mind commenting specifically on this?

I'm using Flow, rather than TS, for a bunch of reasons you are probably familiar with, but over time I'm just wondering more and more if switching to TS might be worth it just for the tooling.

With Flow in VS Code (via the flow-for-vscode plugin), whilst things have slowly and steadily improved over the last 2 years it is still quite a way from 'just works'. I get the _impression_ that the story for TS with VS Code is a lot different, and everything would just work out the box (intellisense, auto import, meaningful error messages tied to line numbers, etc) though I simply haven't yet found the justification to invest the time in migrating just to check this. If I'm wrong and it's the same or only very slightly better, it would obviously have been a time sink for not really much benefit.

Do you have any insights or advice on this? Even if you're not a VS Code user, what tools _do_ you use that _are_ better with TS than Flow?

<comment><USER20> Well, we had a 50K sloc codebase written in Flow. We had invested heavily in the type system for quality control, so we had types everywhere. This made it riskier for us to switch to another type system, which is why we stuck with Flow for longer than we should have.

The way I finally did it was that I tried out TS on a side-project that I wrote from scratch. I did expect better tooling with TS, but I was still surprised by how better the experience was.

Auto import just worked. Same with code navigation. And they made me work much faster. Intellisense was also much better. And the error messages more readable. (And they've gotten even better since)

All of these things work to some extent in flow+vscode, but the experience with TS was incomparably better.

I was still hesitant to switch the larger project to TS though, mainly because we were using some of Flow's more advanced features to type-check a function like `wrap()` in this code:

      const obj = {foo: true, bar: {baz: 2}}
      const wrappedObj = wrap(obj)
      wrappedObj.get('foo') // returns true
      wrappedObj.get('bar').set('baz', 'some string') // type error. baz must be a number

This was almost possible to do in Flow using `$ElementType<>` and `$Call<>`, but TS had no counterpart for `$Call<>`. Luckily though, TS soon came up with conditional types, which turned out to be a much more reliable way to handle these cases.

That's when I decided to switch the codebase to TS. It took about 5 days. It wasn't straightforward, but in the end, it gave us a much smoother developer experience.

</comment></comment></comment></comment><comment><USER22> We're going through a similar process at my company - how do we refactor the decade old startup-style JS without 1) spending a year rewriting everything from scratch generating little business value and potentially introducing regressions in the process 2) continuing to build stuff on that shaky house of cards. It looks like the solution we've kind of settled on has also been TypeScript. At this point it's probably sub-5% of our prod code that's TS source, and it's daunting given how much we have to change and how many years it will take at our current pace, but it is the middle ground moderate way and probably the right way to approach things like this.

<comment><USER23> In my experience old JS code suffers from lack of structure and discipline much more than type safety. Can you provide an example where that isn't the case in your codebase?

<comment><USER22> Nope, that's absolutely the issue. But we figure we can do both at the same time, and type safety hasn't hurt anything.

</comment></comment></comment><comment><USER24> I haven't used it in a while. Does it play nice with plain-JavaScript libraries from npm yet?

I quit using it a few years back because it was a _nightmare_ having to write d.ts files for everything or be unable to use noImplictAny for your own files. `AllowJs` wasn't even a thing when I started using it, but even after its addition, this problem continued to be absolutely disastrous for my project. I remember being very disillusioned with it because all of their materials (website, docs) kept hammering on how effortless and incremental it was to use with JavaScript, yet `AllowJS` wasn't even a thing for the longest time...

I also had very severe issues with its importing of npm modules, even ones that supported TypeScript. Sometimes it would double-parse bundled d.ts files resulting in a huge error output. Other times it would just completely fail to resolve import paths no matter what I tried.

I remember various workarounds like having to define empty modules for each plain-JS import, or using `///` imports for certain files, and it was a nightmare (and I found many similar issues on StackOverflow that were unsolved). The maintainers at the time considered these terrible workarounds as valid solutions, and thus would almost not even entertain reports regarding these problems.

<comment><USER9> It's got to the point where, for me, TypeScript support is an important feature of a library that influences my decision whether to pick that library over another. Luckily, most of them these days either ship with their own definitions, or have them available.

Bottom line: I never write my own definitions for other projects.

</comment></comment><comment><USER15> Real big fan of TS, like anything though you just have to be disciplined when using it. Type absolutely everything and set the transpiler to the most aggressive checks possible... If you're being lazy and putting : any everywhere and then complaining about how good it is...you're doing it wrong

In our project I've found we make a lot less mistakes than with pure JS and there's a lot less pointless type check unit tests due to the guarantee's it gives us. io-ts ([https://github.com/gcanti/io- ts](https://github.com/gcanti/io-ts)) around rest endpoints checking json input as well has been a godsend.

<comment><USER25> I always use it with

> "compilerOptions": { "strict": true }

But given the huge number of other options I worry that like GCC's '-Wall', that doesn't actually give you the strongest possible type checking. Anyone know about that? My aim with Typescript is to turn JS into OCaml.

<comment><USER26> You might like [https://bucklescript.github.io/](https://bucklescript.github.io/) Facebook use it in Messenger.

</comment></comment></comment><comment><USER27> The author says they contemplated an "abandon this ruined planet" option, mentioning Haxe/Clojure/Elm as alternatives. I'd love to read their follow-up post to learn what kept them on planet JavaScript/TypeScript.

The alternatives to TypeScript seem increasingly compelling to me.

It was good to see Haxe mentioned even in passing; I really enjoy using it and — as others have noted[1] — it feels like a "better" TypeScript.

Haxe has great features both at the language-level (pattern matching, algebraic data types, array comprehensions, and more[2]) and tooling-level (cross-compilation to JavaScript, native code and dynamic languages, a fast compilation server[3], good VS Code support in Haxe 4, and a bunch of cross- platform game frameworks[4]). I wish more people would try it! [https://haxe.org/](https://haxe.org/)

Reason is also compelling; it will be better still once Bucklescript's Belt library is out of beta and some warts in Reason/OCaml are smoothed out — lack of ad-hoc polymorphism[5] and lack of unicode support without BuckleScript string literals being two examples.

[1]: [https://news.ycombinator.com/item?id=10009290](https://news.ycombinator.com/item?id=10009290)

[2]: [https://haxe.org/documentation/introduction/language- feature...](https://haxe.org/documentation/introduction/language- features.html)

[3]: [https://haxe.org/blog/nicolas-about-haxe- episode-1/](https://haxe.org/blog/nicolas-about-haxe-episode-1/)

[4]: [https://haxe.org/use-cases/games/](https://haxe.org/use-cases/games/)

[5]: [http://ocamllabs.io/doc/implicits.html](http://ocamllabs.io/doc/implicits.html)

<comment><USER6> The mastermind behind our TypeScript project commented on this topic here:

[https://news.ycombinator.com/item?id=17896925](https://news.ycombinator.com/item?id=17896925)

I used to tinker a lot with OCaml around 13 years(!) ago. It's neat to see people are still working on fixing some of its problems. It would be fun to find a reason to use it again.

</comment></comment><comment><USER28> [Irony on] It's somehow reassuring that Google engineers also " _check StackOverflow for answers_ ". Helps me to raise my low self-esteem. :D I thought all what Google engineers do is writing code from scratch in brainfuck all day long.[Irony off]

Of course I am just joking. Well, the author faced the same dilemma that we all face when instead of joining the next-to-be-unicorn startup we join an established company which has been operating for more than one decade. Namely legacy code.

They should pick up a copy of 'Working effectively with legacy code'. They might extrapolate some of those advices and apply to their situation.

</comment><comment><USER29> Isn't Reason/Ocaml a better direction than Typescript? I believe that TS is a step forward but I'm afraid that we are still in _a muddy path_.

<comment><USER30> I hear ya, but the author of the article needed something that could be adopted _incrementally_. JS is a subset of TS. Throwing some typing onto a JS file is often trivial. Reason would be a whole different story. Learning curve alone...

</comment></comment><comment><USER31> As somebody migrating a React codebase from JS to TS, I can't believe how popular TS is.

It seems like something that only exists due to the popularity of Angular, where I can only assume the experience is significantly better than with React.

The type system is frankly disappointing, and the errors the compiler spits out at you (besides the most obvious ones) are almost always useless or gibberish and at times even more harmful than helpful.

It's better than nothing I guess, but I can't help but feel extremely underwhelmed with it given how many people use it. Are all of the people in this thread Angular developers or something?

<comment><USER32> I can believe how popular TS is and it is super useful. I would not write a React application of any noticeable size without TS (and just FYI I would never willingly write an Angular app). The reason that I get far superior code completion and meaningful warnings / errors is sufficient to add a few annotations here and there.

Many people are doing TS wrong. They add types everywhere. Honestly, you should write as many types as necessary, but not more. Use type inference which works remarkably well.

<comment><USER33> At least add them on function return types and annotate types on common objects so that you don't have objects lingering with wrong property name/type or redundant properties that would be confusing to review.

It helps to create a type reference for your database schema, so you don't try to insert something weird or insert with missing columns.

</comment></comment></comment><comment><USER34> > But that's what we engineers do: we make interesting compromises that > attempt to balance different concerns.

I like this :)

</comment><comment><USER35> After a few years with both TS and JS my verdict is that TypeScript definitely _helps_ , but mostly with type-related bugs - with proper testing you don't get many of those.

What I would like to have in TS is a more expressive type system - the current is somewhat basic(e.g. you can't have a Symbol as a dictionary key - interesting given that it's possible in JS. Also you can't mix dictionary fields with regular ones in one class/interface).

EDIT: typo.

<comment><USER36> The point of type checking isn't so much to prevent bugs in production, but to speed up your development loop by catching many errors before you've even saved your file. Its much faster to see a red squiggly right after you've written a line of code, and fix it, rather than figure out whats gone wrong 10 minutes later looking at a stack trace in your test suite.

<comment><USER37> Doesn't this 100% on your personal develop workflow? I for one have been forced to use typescript in the past, and am personally very happy that I don't have to anymore.

</comment></comment></comment><comment><USER38> Google Maps definitely made JavaScript cool at a time when it was not much in favor - people still thought Java Applets or Flash were going to rule the web.

</comment><comment><USER39> I wish they would make a JS/TS-based version of the Closure compiler. I suspect a lot of apps would benefit from the compilation and we'd see much smaller bundle sizes. But the Java dependency is a burden to bear.

<comment><USER40> Isn't there already one? I seem to recall that it mostly works, just much more slowly than the java version

Edit: here you go: [https://www.npmjs.com/package/google-closure- compiler](https://www.npmjs.com/package/google-closure-compiler)

<comment><USER39> Nice! Didn't realize this was a thing. I suspect they could make even more aggressive optimizations if they made a TS version.

<comment><USER6> This idea is probably worth a post of its own. I believe that because TypeScript's type system is effectively advisory rather than guaranteed ('unsound'), you cannot rely on it for optimization unless you're willing to unpredictably break programs.

<comment><USER41> Hey, that's an interesting thought!

If you go all the way and make it sound with variance annotations, banning asserts & under specified types, etc. then you end up with a language that sucks to use in practice.

If you go to the other extreme, you don't have static types at all.

If different parts of your code are typed to varying degrees, or you use a lot of unsound types/inferences, maybe there's a way to assign a confidence score to every type to indicate how accurate you think it is. Maybe there's a clever way to statically compute that score, or you can instrument some % of prod traffic at runtime to observe types with lower confidence (Node has this, or see MonkeyType or Reticulated Python). Then take that info and feed it into Closure compiler.

<comment><USER42> > If you go all the way and make it sound with variance annotations

Variance annotations aren't quite what would make the language (in strict mode) sound. Specifically, what makes it unsound is the `any` type (generally) and the lack of enforced variance on methods, non-function properties, and index signatures. It doesn't need annotations to determine variance - <USER3> parameter variance can be inferred from where in a type a type parameter is used. It already does so for functions (that's the strict flag's strictFunctionTypes subflag). The real issue is that far, far too many people rely on, eg, unsound array assignments (array aughta be invariant over what it contains but it's often treated covariantly), for it to be reasonable to be a default. However it could always be changed (or added) in the future - that's what the strictness flags are for, ideally; providing ways to ratchet up the safety such that it won't permanently break longtime users of the language.

<comment><USER6> As far as I understand it, every sound language eventually has to fall back to runtime checks to maintain soundness in tricky cases. For array covariance I know that Java/Dart eventually use runtime checks on array accesses to verify the types work out.

However, it's kind of against the spirit of TypeScript to insert runtime checks. For example because the type system models 'undefined', to model out of bounds array accesses you'd either need to make every array access have type T|undefined or insert bounds checks that throw. (I believe Dart does the latter.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> I love typescript as a JavaScript developer, but having used go for personal projects, I find the type system complex (maybe necessarily so). Having said that, I cannot thank TS enough for how it's made life easier when working on and refactoring large codebases.

<comment><USER44> I don't know what you find complex about the type system, but I actually find it slightly limiting. They keep improving it, so it can express about 95% of what I want, but I still hit situations where I can't tell the compiler everything.

<comment><USER41> What sorts of things do you have trouble expressing with the type system?

<comment><USER44> I can't think of something off the top of my head, but it's usually related to generics. I'll type something that makes sense, but the compiler doesn't like it.

Another issue is that handling of string literals as types can be wonky when they're being compared against the type "string", which they should always satisfy but sometimes don't.

<comment><USER41> I'd love to see examples for those, maybe drop a comment when you run across a specific issue.

</comment></comment></comment></comment></comment><comment><USER45> I think the most fascinating thing here is that Google are turning to a language developed and maintained by Microsoft.

<comment><USER33> It's come to a time that discriminating MS was an old thing.

<comment><USER45> Or maybe it's about Microsoft's continued influence, especially in the Open Source community.

</comment></comment></comment><comment><USER46> Web shouldn't end up this way. Web was designed for sharing documents. Webs and webapps now are sluggish and take soooo much RAM. I have a pretty fast computer with 16GB RAM but running all these webapps with Megabytes of javascript is bringing back -5years experience and can fill up my RAM. I know it is still improving but webapp developers are also quick with abusing every performance gain often for unwanted and unneded functionality. For example CSS animations for every mouse over, material clicking highlights are terrible, terrible design decisions which occassionally even spin up my laptop fan.

</comment><comment><USER47> > Gmail engineers had to worry so much about Internet Explorer's poor garbage > collection algorithm that they'd need to manually hoist string literals out > of for loops to avoid GC pauses.

What does this mean in practice? I know about variable hoisting and function scoping, but not about old JS GC algos.

<comment><USER8> My read was that Internet Explorer couldn't realize that a string variable could be reused over and over so each iteration of the loop it was allocating a new one, using it, and then garbage collecting it. Basically tons of unnecessary overhead.

Having the programmer define a variable before the loop and then reuse it each iteration meant that all that allocation and garbage collection wasn't necessary during the passes of the loop.

<comment><USER6> That is exactly right.

</comment></comment></comment><comment><USER48> I switched from Flow to TypeScript. Flow has some type-declared libraries, but it's fewer than TypeScript type-declared libraries. The excellence of VSCode also helps me.

</comment><comment><USER49> > it's likely if you use Google products you've interacted with some > TypeScript code

Transpiled Typescript code I expect, so?

</comment><comment><USER50> So... I love Typescript, but...

"Because TypeScript already mostly works — that's part of the reason to adopt it"... c'mon

</comment><comment><USER51> I'm still reluctant to use TypeScript given that it has a serious type narrowing bug that is two years old! You'd think Microsoft could have sorted this out by now.

[https://github.com/Microsoft/TypeScript/issues/9998](https://github.com/Microsoft/TypeScript/issues/9998)

</comment><comment><USER52> What js in browser is missing is something that golang provided on the server - fast, simple (and more standard) way of writing and executing code, including large code bases.

Typesafety is a small part of it and I'm not sure whether switching or choosing entire dev tooling based on just that is worth it. Just structure your code better and use react prop types and most of type issues go away, in react code bases.

<comment><USER53> Prop-types is for runtime, TS does static type checking. Prop-types are terribly verbose and only work with React (what about utils files, external libraries, etc?).

</comment></comment><comment><USER54> I always wonder why people think typescript is a fix for bad code.

We primarily do JavaScript, and I see no issues with it when you set up governance in how to use it.

I don't think building your own libraries is really a bad thing either, in fact I think you should do so often instead of relying on 3rd party packages of quality you typically judge on how many times they've been downloaded if you're being honest.

I think typescript is silly. It works with legacy code, sure, but if you're refactoring you might as well rewrite your JS or if you're compiling to JS you might as well chose Dart which is vastly superior to typescript.

I don't really see type safety as an issue. I can't remember when it was a problem for us, and we operate millions of lines of code, but they are all written with governance. Want a number? Then call your argument numWhatever and check your input. It's really as easy as that.

I mean, sure type checks will prevent shitty code from compiling, but really, just don't write shitty code. I know that sounds silly to some people, but 95% of what you write is about shifting data around through simple mechanics, it really shouldn't be so hard to do it right.

You won't see an engineer go "oops that support beam in your building wasn't right, my bad" and programmers really shouldn't get that luxury either. If they write shitty code then figure out why, maybe they need more time, maybe they need training, maybe they need governance or maybe they need to be replaced.

But hey, feel free to fix your shitty code with code that's only less shitty because your compiler protects you. Just know that typescript comes with a different set of risks, once you need your JS codebase to move forward in a way that isn't supported by JS.

<comment><USER55> > fix your shitty code with code that's only less shitty because your compiler > protects you

I mean... Yes? That's exactly what it's for. That's all it's for. That's all I want out of it, and that's what it does. I'm not really sure what you're railing against here.

<comment><USER54> My point is that I don't think it fixes your shitty code.

Especially not if you're not converting your entire project to typescript, and if you're converting the entirety of it, then why not use a better language?

I think typescript is popular because it's very java/c# like and I think it's dangerous because it allows you to write bits of your program with the safety it provides and other bits without it.

So you'll have programmers thinking they are safe, when they are really not.

<comment><USER44> TypeScript has structural (not nominal) typing, which makes it very different from Java/C# in practice.

Also, it doesn't fix shitty code. It just lets the compiler warn you when you're either making a mistake or misunderstanding some other part of your code base.

You should really try it before you say it doesn't help.</comment></comment></comment></comment>


Ransomware developers ask for help with CryptoAPI from security researcher - <AUTHOR> http://www.bleepingcomputer.com/news/security/ransomware-developer-asks-security-researcher-for-help-in-fixing-broken-crypto/ <comment><USER2> The currently tremendous success of their business model relies on their reputation being that if you pay, you actually get your data back. Once that reputation is destroyed, their market is going to crash. So I say: don't help them, let them destroy their reputation and be their own undoing. Good riddance.

<comment><USER3> > let them destroy their reputation and be their own undoing

My only concern is that their "reputation" is one perceived inside our sweet tech bubble. Basically, people like my parents and cousins from rural [Insert Southern State Here] have no idea what ransomware is. I reckon that the average computer-user doesn't either and may not know what to make of the results from a Google search on the subject.

That being said, in crisis mode, it's likely victims would go on to pay for their files to be decrypted depending on whether or not they can afford to do so. To me, this is similar to a government saying "we don't negotiate with terrorists". That's all well and good if you're the government and have tactical teams trained to carry out extractions if you're the one kidnapped. However, the family of your average citizen, like your average computer-user, may be more than willing to negotiate with said terrorists if it means ensuring their loved ones (or files) are returned unharmed. IMHO.

</comment></comment><comment><USER4> Wosar should help them, but make it so there are subtle weaknesses that can be used to break their encryption.

<comment><USER5> The help will probably be a one-two liner. Not enough to hide a backdoor</comment></comment>


Ask HN: What's your definition of a technical debt? - <AUTHOR> What are your parameters or mindset or mental model to figure out a technical debt?
How do you deal with the tech debt? How do you prioritize the tech debt severity?
In general, not restricted only to the computer science field, how is the technical debt described for a particular field?
To me, field: computer science - software, any denormalized database object is technical debt, with a severity directly proportional to the amount of additional code being written to manage denormalization. <comment><USER2> Tech debt is something that saves time/resources now, at the cost of even more time/resources later.

This could include not writing tests, spaghetti code, poorly planned or poorly defined features, and so on.

I treat it much like financial debt. The best ones are the ones you might not have to pay off - experimental features that may not be used or that could be replaced.

There are some cases where the amount you save vs future cost is really poor, e.g. denormalized database or spaghetti architecture. It's quite a senior/specialist skill to get the right balance.

</comment><comment><USER3> Technical debt is debt. It provides leverage but accrues interest. Technical debt is wiped away in bankruptcy.

The last is important. Technical debt accrued in pursuit of a bad idea goes away when the project is abandoned. For a startup that is scaling rapidly, technical debt goes away because the problems of scale require rewriting even the best tuned small scale code.

Even in ordinary business cases, the cost of carrying technical debt is very often lower than the cost of eliminating it. One extra engineer to deal with it, is less expensive and lower risk than rewriting the code base on moral grounds. Carrying it contributes more to the bottom line and cash flow than an effort to eliminate it.

</comment><comment><USER4> Field: software development

A technical debt is anything that slows down either performance and development.

It could be:

\- memory leaks

\- zombie routines

\- variable/function/type/endpoints misnomer

\- out of date comments

\- unhandled errors

\- technological goldplates

\- readability-hindering and overly-strict conventions

\- non-forward compatibility

\- unnecessary side effects / mutability

\- god objects

\- improper architecture

\- unclear separation of concern

\- flow dead-ends

\- non-scalable storage access strategy

\- unused data created in memory (seriously, this is annoying. Imagine reading codes like these like this:

fn renderSomeHeavyStuff(errorKind: string) {

      let renderables = {

        "kindA": someHeavyProcedureA(),
        "kindB": someHeavyProcedureB(),
        "kindC": someHeavyProcedureC(),

      }

      return renderables[errorKind]

}

)

\- structure written imperatively

\- stories written declaratively

\- premature abstraction

\- leaky abstraction

\- overprotective abstraction

\- over-complex resource endpoint

\- under-complex procedure endpoint

</comment><comment><USER5> IMO there are two types of tech debt.

The first is "techincal" debt - which is stuff that gets ignored for the sake of faster delivery but slows down development in the long run. Missing tests, spaghetti code, weird hacks, poor documentation.

The second type is "product techincal" debt - stuff that purposely half baked / half delivered for the sake of meeting deadlines. Features that are delivered or bugs that are fixed in less-than optimal ways.

I'm much more sympathetic to the second kind. At a certain point you always have to negotiate quality with speed. As long as there is a shared understanding that "this isn't perfect, but we're agreeing to move forward", it can generally be corrected eventually.

The first kind is usually the kind that gets piled up though. It's the stuff that causes engineers to want to burn down everything and rebuild, and eventually leads people to quit. Nothing is worse than being forced under time constraints and then realizing you can't implement a new feature without being forced into a major refactor, or spending a week on adding tests that should have been there in the first place. It's this stuff that causes the most stress IMO, because management usually sees it as unnecessary.

</comment><comment><USER6> Basically, when I look at something and think "ugh". Code which is usually much too long for what it's doing, is hard to follow, or will otherwise likely limit our team's ability to change the product in the future.

Due to our small team size and low test coverage, we will almost always leave such code alone until such time that we have the chance to work on the product in earnest (e.g. changing or adding a feature that touches the affected code in some way).

</comment><comment><USER7> Search for TODO, HACK, etc in the code base to uncover the obvious technical debt.

The hidden ones are those undocumented code, workaround, config settings etc that no one understands what it does.

</comment><comment><USER8> Code that has not been reviewed. Worse is code that has not been documented. Code without proper test suite. Code without code management.

</comment><comment><USER9> > technical debt

[https://vimeo.com/108441214](https://vimeo.com/108441214)</comment>


Stack Overflow adds developer IQ scores to profiles - <AUTHOR> https://stackoverflow.blog/2018/02/06/pluralsight-stack-overflow-helping-worlds-developers-learn-new-skills/ <comment><USER2> So, employment in this industry requires

1\. maintain an active github profile

2\. have active Stack Overflow profile where you help various people for free during the day.

3\. be willing to do coding assignments for any potential employer that take a couple hours out of your day (aside from the time spent looking for work)

4\. potentially answer tricky questions in interviews that have nothing to do with your job.

5\. Have a linkedin profile or maybe some sort of social media profile so that potential employers can be sure you are not an antisocial shutin who spends all their time in front of the computer working on github projects and answering Stackoverflow questions.

And now, maintain public IQ scores.

on edit: improved formatting</comment>


IBM Closes Acquisition of Red Hat for $34B - <AUTHOR> https://www.redhat.com/en/about/press-releases/ibm-closes-landmark-acquisition-red-hat-34-billion-defines-open-hybrid-cloud-future <comment><USER4> So IBM buys Red Hat for $34B, of which $20B are borrowed monies. The debt is priced at 1.05 percentage points above Treasury yield rate [1] which would be somewhere around 3.5% which puts interest on bond debt at ~$700m every year.

Now consider that Red Hat had a net income of $433m. Even if they reach $500 this year, Big Blue will still be $200m short, every year.

At the moment, IBM is trading down at -0.5% on an otherwise slight green Nasdaq.

Just from these numbers we can conclude that IBM is seeing some pretty significant synergies in the purchase that the market isn't.

[1] [https://www.barrons.com/articles/ibm-bond-sale-red- hat-51557...](https://www.barrons.com/articles/ibm-bond-sale-red- hat-51557347372)

<comment><USER5> But IBM bought RH only because they believed that the company has growth ahead. If it grows a little more than 1% a year (which should be easy) that will be enough to break even. I think that was a smart move by IBM.

<comment><USER6> You are forgetting about the opportunity cost of $34 billion.

<comment><USER5> This is money used to buy large corporations, there are no other ways IBM could easily find a loan to spend $34B.

</comment></comment></comment></comment><comment><USER7> I don't doubt the committment of RH to Open source, but looking at IBMs rather chequered history with regards to how they look to minimize costs, there must be some concern that next time there's a bad set of results, executive management will be looking for cost savings.

There are plenty of examples [https://www.thelayoff.com/international- business-machines](https://www.thelayoff.com/international-business-machines)

specific example related to RH [https://www.thelayoff.com/t/ZJ4vNfo](https://www.thelayoff.com/t/ZJ4vNfo)

TBH I hope I'm wrong and that IBM corporate leaves RH alone long term, but that's not the general trend with acquisitions...

<comment><USER8> As the very good comment above points out, IBM will need to cut costs very significantly regardless, as they've paid so much the interest on the debt is more than Red Hat makes.

<comment><USER9> They could easily make it up by cross selling to Red Hats consulting customers and likewise for Red Hat to IBM customers. They shouldnt have to gut Red Hat to extract additional value from an M&A. Plus other intangibles like access to talent and access to new markets in the future for both sides.

Cost cutting isn't the only business strategy. Although one that modern (public shareholder driven) businesses became obsessed with since the 1980s.

</comment></comment></comment><comment><USER10> IBM is all in on the multi cloud story since they missed the cloud memo, and RH openshift is their key to allowing customers to lift and shift from AWS to Azure to GCP etc.

Plus it's pretty clear they know how to do layoffs and that knowledge may be applied to RH soon to boost profitability.

<comment><USER11> So more an IP acquisition and IBM sure does know from decades of experience to recognise some company that fills a gap that has usurped their own offerings and acquired it.

You may well be right, indeed that was along the lines of my initial thought about this and would explain the size and scale of investment. Then if RH fails as they would currently to keep up those interest payments, then accountants can just rub their hands and use that debt to offset profits down the line.

Time will tell, certainly IBM has the kit and for years had its own dark fiber internet backbone globally, so have been well placed for years to capture the cloud market, yet failed to move on. Which for a company that saw a shift towards service offerings, was probably a big source of embarrassment internally at some levels.

<comment><USER12> Almost 80% of IBM's profits come from its cloud division, which is only 27% of it's business.

It seems like the idea behind the Red Hat acquisition would be to increase the cloud division revenue and keep roughly the same profit margin, which in theory could be great for their bottom line, especially if Red Hat is growing quickly (is it?).

The arm chair CEO in me doesn't see how this adds up, though. Red Hat seems pretty pricey. I just don't see how Red Hat competes with AWS, Azure, and GCP moving forward, and I don't really see how it plays nicely / fits into those clouds either. I also don't see how it would make IBM's cloud more attractive. I can see how it could make IBM's cloud more profitable, but it seems like a stretch, given what they paid for Red Hat.

<comment><USER13> _I just don 't see how Red Hat competes with AWS, Azure, and GCP_

It doesn't. Their cloud tech, OpenShift, runs on top of the others. Kubernetes can sit on top of that. It makes private clouds portable (kind of).

<comment><USER14> Slight nitpick. OpenShift, since its latest major version (3?) _is_ Kubernetes. It's mostly a repackaging/distribution of k8s. OpenShift can run on top of AWS/Azure/GCP, but also, most importantly, OpenStack.

<comment><USER15> Another nitpick, openshift is not a repackaging but a fork of Kubernetes pure and simple, if you look at the origin you'll see those merge patch they do on every Kubernetes releases

</comment></comment></comment></comment></comment></comment><comment><USER16> I really hope IBM can keep their fingers out of Red Hat, if not, it does not matter how many promises they make, they will run it into the ground. If they actually manage to keep away, and let their cloud business grow without interference; they actually have a chance to grab a big piece of the cloud business.

<comment><USER17> You don't spend $34B to not interfere.

<comment><USER18> I respectfully disagree - I'm a Red Hatter so you can take that for what it's worth. To me the 34B buys IBM the real estate in the open hybrid cloud market which Red Hat has built up in the last 5 years. That is part of a large and rapidly growing market. If IBM interferes with Red Hat they will likely squander the value of what we've built. If they foster what Red Hat did to win that critical ground then their 34B could stand to increase substantially.

<comment><USER19> I certainly don't want to argue or appear confrontational, but wanted to ask you this:

Have there ever been any situations where the acquisition of a smaller company by a larger one has resulted in the smaller company remaining independent? Or has there been any positives for companies like Red Hat when they get bought?

Usually I hear or read the positive-yet-bland press release talking about how wonderful this is, and how big-corp won't destroy little-corp's culture. Yet a year or less afterwards, I read stories of how everyone in little-corp has been laid off, and now little-corps applications/services are now crap.

I'm a _huge_ Fedora/CentOS/RHEL fan, and use it every opportunity I get. I'm very, very worried that Red Hat will be gutted and defiled until there's nothing left. Which is a very, _very_ bad thing for open source because Red Hat is a huge cornerstone of OSS development and support.

<comment><USER20> I usually put it this way: "Name one company that was better after a merger."

I've yet to find any affirmative answer.

It's good to have hope, but it's not good to be unrealistic.

<comment><USER21> Pixar / Disney

Marvel / Disney

Facebook / Instagram

EBay/PayPal

Exxon/Mobil

Massive numbers of banking / pharma/ industrial mergers.

I will agree though that I can't think of a tech sector merger at this scale that worked out really well. They seem to work best at the sub $2B level.

Although LinkedIn/Microsoft is looking OK.

<comment><USER22> What you don't hear about are the dozens of companies Disney has acquired then shut down over the years. Playdom. Tapulous. Junction Point Studios. Fall line Studios. Wideload Games. Propaganda Games. Black Rock Studios.

<comment><USER21> Or the tragedy of LucasArts, which is one reason I left LucasFilm off the list.

Disney and gaming seem like a match made in heaven, but for some reason it seems like the mouse struggles to perform in that market compared to its unqualified successes in Movies, TV, and theme parks.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> IBM basically has control of _all of Linux_ now. They've gotta love that sweet, sweet strategic leverage over the entire Web and cloud ecosystem.

<comment><USER24> There is a lot of truth to this. Since Fedora is the upstream for Red Hat, and IBM historically kill off anything not making a profit, how long before this happens? I wonder if they'll split the two?

Red Hat does "control" a disproportionate amount of Linux development. Everything is also now basically dependent on systemd.

I'm seeing more and more IT guys I know move over to Free/OpenBSD because they don't like the direction Linux is taking. While Linux is only a kernel, the entire userland is basically dependent on systemd.

Linux has become what it hated in Windows. A massive, bloated mess. I've always preferred BSD on the server and something else on the desktop (hurry up, Haiku!). I still wish BeOS would have gotten more traction beyond the BeBox.

Methinks the move towards FreeBSD--and it's happening in quite a few circles, will continue, especially if IBM get heavy handed with Fedora/Red Hat. I'm not worried, per se, but I am concerned, for the aforementioned reasons.

<comment><USER25> > the move towards FreeBSD

Who? Where? for what?

You mentioned BeOS. Sorry, I love nostalgia too, but I have no idea what you're talking about. Out in AWS, GCP, Azure, DO -land... it's still going to be Ubuntu, Debian, CentOS, Windows, etc for a long time.

<comment><USER24> It's all in what people are willing to tolerate or change. Obviously, the gentlemen over at Haiku feel they have something to offer, as small as it may be. I always though that BeOS was somewhat revolutionary in its approach.

I'm still somewhat bothered that Apple let their server offering go. And yes, FreeBSD replaces Linux easily. Not everyone runs their stuff in the cloud. It's not the be-all and end-all. Serious non-IT businesses are still on mainframes, BSD, and other, and there are plenty of them. A friend of mine is a COBOL programmer for a large financial house, and he's set for as long as he wants to work there, and at almost $80hr (Texas), he's making better coin than most programmers here.

<comment><USER26> > And yes, FreeBSD replaces Linux easily.

No, it doesn't. Take any non trivial system running Linux and try to run it in FreeBSD. You may get it running in little time, however the number of issues you would have would be big.

Remember that the modern stack have multiple layers of complexity, Linux, your app, SomethingSQL, AnotherThingDb, Kubernetes, AWS/GCE/Azure, etc. Since FreeBSD is not the common choice to run those things you will probably hit a issue here, another issue there, a combination of issue in one layer with another, etc.

Yeah, this may say more about our current systems than anything, however to say that it is easy to substitute Linux with FreeBSD is simply not true.

<comment><USER27> Depends on the system. For a desktop enviornment you are correct, *bsd is at best an after thought to pretty much all projects. However "serious" server programs tend to get much more testing on BSD. I don't think you will have any issues running a database on BSD, and probably not a web server (though some web frameworks are Linux first so YMMV)

<comment><USER28> The biggest problem in "FreeBSD desktop" is not the "FreeBSD" part - <USER2> works pretty much fine.

<comment><USER27> I run a FreeBSD desktop. There are enough problems that I wouldn't install that for my family. Too many blank windows and the like (I suspect graphics driver issues but have no idea how to debug further)

<comment><USER28> I wouldn't install it for my family either, but I wouldn't do that with Linux either. It can be fine for chromebook-like usage, but not as the usual desktop.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> This is a great move for both companies. The doom and gloom in this thread is depressing.

RedHat gets access to IBMs massive sales machine and IBM picks up a number of key technologies. Win-win.

<comment><USER30> The problem with any M&A is no different than what happens in marriages - <USER3> the two blend together, does one dominate the other's culture, etc? The truth is that IBM's history (and to be fair, almost all 10-figure+ market cap tech companies) even with multi-billion dollar acquisitions (that's almost all they do with the exception of Google and Apple I can think off the top of my head) is that the current company's inertia dominates whoever they acquire and the internal sales-driven culture in developed markets supersedes anything resembling engineering related from a company they acquire. Sometimes IBM gets ripped off too but wishful-thinking top-down thinking instead of a more critical, measured engineering oriented focus is typically not consulted even for absolutely essential company initiatives internally.

Disclaimer: former IBM employee with short tenure with a failed acquisition by every definition of it

<comment><USER31> _" the current company's inertia dominates whoever they acquire and the internal sales-driven culture in developed markets supersedes anything resembling engineering related from a company they acquire"_

What engineering-related innovation has RedHat come up with?

As a Linux sysadmin I've noticed that all of the companies I've worked at that have used RedHat chose it not because it was innovative but because:

1 - they could get a support contract

2 - because RH dominated the commercial Linux space

3 - because RH was the OS the admins knew and both wanted to leverage that knowledge and keep their knowledge current for continuing work with this market leader in future jobs (as that was likely the OS they'd use in most jobs to come)

Most of the "innovations" I can attribute to RH have been widely seen in the sysadmin community as negative. Innovations such as systemd, Network Manager, and selinux. The latter two we've often turned off because they caused so many problems. Unfortunately, systemd was too integrated in to the OS to be able to turn off.

There's RPM, but that was created decades ago when RH was not the company it was now, and it's just one packaging format out of many, and not one that IBM even needs to spend billions to buy. The only other positive tech that RH owns that I can think of is Ansible. But they didn't create it. They bought it.

What RH-originated innovations should we impressed by?

<comment><USER32> The engineering culture is not solely determined by the innovations the company has come up with, so I don't really see the point of the question you ask, with regards to the statement you quoted.

When you say that "most of the innovations [...] have been widely seen in the sysadmin community as negative", well, that can only be true in your own sysadmin community. If you replace "innovation" by "contribution", and make the list include everything RH works on (SELinux, NM and systemd are really a tiny part of it), the sentence becomes factually incorrect, even in your own sysadmin community (I hope).

Also, systemd was not created by RH (LP was not employed by RH at the time), and SELinux is from the NSA's TRUSIX. Labeling SELinux as a "negative innovation" is very weird (not that whole sentence isn't).

When you say that RH's only "positive tech" is Ansible, but that it was an acquisition, that's true for mostly everything RH participates in (Ansible, but also systemd, OpenStack, Ceph, CoreOS, GlusterFS, KVM, LVM/DM, gcc, gdb, systemd etc... were acquisitions or acqui-hires), so I really don't see your point. Does the fact that all of this software originated from somewhere else than RH negates the existence their engineering culture ?

EDIT: made quotes inline

<comment><USER31> If the bulk of RH's tech was acquired and did not originate with them then why is their engineering culture even relevant? What engineers work by acquisition? That doesn't sound like engineering to me but business.

Now, if you're talking about the engineering cultures of the companies RH acquired, if RH was able to preserve the engineering cultures of the acquisitions they made, why can't IBM?

Also, if by "engineering culture" you're not actually talking about any innovative products that RH itself came up with, but rather the contributions that RH engineers made to open source projects like gcc or the Linux kernel, IBM has done a lot of that too. I'm not sure why that wouldn't continue under IBM's stewardship of RH.

<comment><USER32> I feel bad for having inserted myself into this discussion. I think I'm actually agreeing with you here, in that there's nothing that shows that IBM couldn't preserve the culture of its acquisition. I just wanted to comment on what I thought was a statement on their engineering culture.

Personally, I just hope that RH can preserve its engineering culture. I can't say anything on whether it will happen or not, because I don't know.

</comment></comment></comment></comment></comment></comment><comment><USER33> IBM now has control over systemd, and as other users here point out, also pulseaudio, dbus, gnome, wayland, and a significant share of kernel.

IMHO this is a good time for the Debian project to reconsider the decision to rely on systemd. If you also think so, consider letting them know.

<comment><USER34> Is there really any likelihood of that happening? If Torvalds got cold feet about systemd and started making it less integral to the upstream kernel (or at least more walled off as an optional subsystem), there's a chance Debian would take that as an opening to move in a non-systemd direction. But as long as the upstream kernel imports more and more systemd-related stuff and treats it as the default/expected configuration, and then things like desktop environments follow suit and depend on it, Debian would need to maintain what amounts more and more to its own fork of the rest of the Linux world to do otherwise. When this was last discussed, most Debian developers didn't think it had the dev resources to do that.

<comment><USER35> That makes no sense. As long as Linux is concerned, systemd is totally irrelevant: it is not "integrated" in the kernel in any way and cannot even be considered a subsystem.

</comment></comment></comment><comment><USER36> Feel sad, I know it's just the way things go in big business, but watching a prime example of a fiscally successful company built on open source who has committed so many resources to kernel development and making the Linux community better get bought by a beached whale like IBM just shakes me.

<comment><USER18> I run Red Hat's Developer program, our developer tools portfolio and our developer relations team. When I first heard the news I had a similar reaction. But I've worked with IBM'ers in open source projects for years and they've always been great contributors. Perhaps more importantly both IBM and Red Hat are very committed to not changing our open culture and open source development model. That's been the source of our growth and why IBM felt we were worth 34B. Ultimately words are cheap, so if you see Red Hat's actions in the open source community changing please say something - I for one am committed to continuing to work the open source way.

You can read my blog post and comment here: [https://news.ycombinator.com/item?id=20391504](https://news.ycombinator.com/item?id=20391504)

<comment><USER37> Open source doesn't make money, you're at IBM now to save their failing cloud business. If you can't do that, expect your time on open source to dry up.

<comment><USER38> Open source absolutely does make Red Hat money, billions of dollars a year.

<comment><USER37> Open source doesn't make them that money, _servicing_ open source does.

<comment><USER14> How will they service open source if they stop funding its development?

I'm assuming that you're implying that's what IBM wants?

</comment></comment></comment></comment></comment></comment><comment><USER39> Does this acquisition open up the market for a Linux company to move into the Linux enterprise space?

Maybe Ubuntu could pivot into this space.

<comment><USER18> Red Hat's business model and open culture isn't changing. We will remain independent and I look at this as an opportunity for more people to engage with our stellar support and field teams.

For some context you can read the email our CEO sent out to the whole company today: [https://www.redhat.com/en/blog/jim-whitehurst-email-red- hatt...](https://www.redhat.com/en/blog/jim-whitehurst-email-red-hatters-red- hat-ibm-acquisition-closing)

<comment><USER40> I remember a very similar email from my company's CEO during a merger. Within months he had retired with millions and everything had changed. I sincerely wish Red Hat and your work doesn't fall victim to a similar fate, but IBM literally owns you as of today.

<comment><USER41> That sort of depends on whether the CEO will remain in the company or not, and which incentives he has to continue to perform

<comment><USER40> The CEO doesn't have full control over everything. Plenty can (and did) change even without a change in the CEO. Again - they are literally _owned_ by IBM now. I'd be optimistic if Red Hat really were to be fully independent with respect to products. But unless IBM made this investment purely as a financial strategy, they will absolutely begin interfering.

</comment></comment></comment></comment></comment><comment><USER42> Share price was $187.71 prior to the announcement. As posted in the article - $190/share agreed purchase.

<comment><USER43> And to give even more context, it was $170.00 back in Oct 29 when it was first announced. Thus, if you bought then and sold now, you'd have a 11.7% return in 8 months. The S&P index would've returned 12% in comparison.

Not risk-free by any means, but almost certainly less risk than buying the S&P index during that time period. There was a reason Warren Buffett parked a ton of cash into Red Hat stock after it was bought.

<comment><USER44> Is it less risky? Say a decent chunk of your portfolio in a single stock? And something weird happens during due diligence , not only is the acquisition over - the stock will bomb.

Not sure how often acquisitions fall through after being announced, I assume very low. But still seems similar or higher risk then a stock fund.

<comment><USER45> Redhat has a 20year history as a public company, it's very unlikely that there'd be a big surprise in due diligence.

<comment><USER46> I think the worry was less due diligence and more a weird anti-trust case from USA, China, or Europe.

</comment></comment></comment></comment></comment><comment><USER47> One can only hope IBM does not mismanage Red Hat. They will certainly twist workflow for their benefit. Owners will probably get a well deserved windfall.

<comment><USER48> We're all watching Microsoft with GitHub. . . it'll be interesting to see how the tech industry evolves over the next 5-10 years.

</comment></comment><comment><USER49> Here's the official announcement from Red Hat Developer: [https://news.ycombinator.com/item?id=20391504](https://news.ycombinator.com/item?id=20391504)

</comment><comment><USER50> Hopefully this helps validate the red hat model to spur more investment into the space and create a new crop of competitors to fill the void after IBM ruins red hat.

<comment><USER18> I really hope so too. To me this is a huge signal that open source has won. That alone is exciting.

</comment></comment><comment><USER51> Prev. [https://news.ycombinator.com/item?id=18321884](https://news.ycombinator.com/item?id=18321884)

</comment><comment><USER52> i'm just a lurker and i have a lot of respects for this community but why some of you acting like somehow RedHat is not going to make money anymore after IBM bought them.

RedHat already make billion doing what they do now. Why would that change? IBM is basically a consulting company and adding RedHat is more than a perfect match since RedHat main business is selling supports.

this thread just wow.

<comment><USER53> Both companies have very different, even incompatible cultures. And it's not part of IBM culture to buy a company and not integrate it.

Specially, IBM is used to much fatter margins than RH's market allows.

<comment><USER54> IBM does not integrate companies beyond putting their logo on stuff. Look at the weather company and Softlayer.

</comment></comment></comment><comment><USER55> A different source with the same news: [https://www.cnbc.com/2019/07/09/ibm- closes-its-34-billion-ac...](https://www.cnbc.com/2019/07/09/ibm-closes- its-34-billion-acquisition-of-red-hat.html) .

</comment><comment><USER56> What does this mean for centOS?

<comment><USER57> I was going to say that CentOS is independent from RedHat, but then I realized I don't know what I'm talking about.

From CentOS wikipedia page:

> In January 2014, CentOS announced the official joining with Red Hat while > staying independent from RHEL,[7] under a new CentOS governing board.

So, good question!

<comment><USER58> After taking over they are now slow to ship new releases. It doesn't really make sense to use CentOS unless you may need to pay for RHEL support.

</comment></comment></comment><comment><USER59> It would be curious to see how Red Hat OpenShift works with parallel to IBM Cloud Private. Both offer same functionality to the customer and IBM invested so much amount revenue and time into IBM Cloud Private, so would they co-exist or merge into one offering is something worth a watch.

Openshift - [https://www.openshift.com/](https://www.openshift.com/)

IBM Cloud Private - [https://www.ibm.com/cloud/private](https://www.ibm.com/cloud/private)

</comment><comment><USER60> At least 80% of ___ALL_ __acquisitions destroy value. IBM has overpaid just like the vast majority of M &As.

</comment><comment><USER61> Is Red Hat's strategy multi-cloud or hybrid cloud? In other words is it easy enough to run your RH cloud-applications at the same time on all of AWS, Azure and GoogleCloud?

Or are they "hybrid" in the sense that you can run your apps both on-premises AND a CHOICE of Azure, AWS etc. ?

<comment><USER62> The answer is "it depends". Their main offering in this space is OpenShift versions 3 and 4. They have different underlying management planes. v3 is on a bunch of different clouds, v4 is still catching up but probably will within the next 12 months or so.

Disclosure: I work for Pivotal, a competitor in the same space (most directly through PKS).

</comment></comment><comment><USER63> The title looks wrong.

</comment><comment><USER64> Great for Open Source?

<comment><USER65> Bam!

</comment></comment><comment><USER66> I think it may have been RHAT's plan all along to get bought by IBM.

<comment><USER66> Not so sure why this is being voted down.

RHAT has always been seen as an anomalous case of an open source company that has done well on the stock market on a sustained basis.

All along they were working on things that IBM lacked, waiting for the day that IBM would be floundering and would need a big acquisition to boost confidence.

</comment></comment><comment><USER67> Elastic is the next

Disclaimer: I own a bunch of Elastic stock</comment>


New York Times word frequency 1970-2018 - <AUTHOR> https://twitter.com/paulg/status/1136962504343662592 <comment><USER2> To be meaningful, this would need to be compared against similar publications or general word frequency across many works. e.g. the Google Books ngram viewer for the first word in the chart, "sexism", looks quite similar: [https://books.google.com/ngrams/graph?content=sexism&year_st...](https://books.google.com/ngrams/graph?content=sexism&year_start=1970&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Csexism%3B%2Cc0)</comment>


What Is Combinatorics? (2013) - <AUTHOR> https://igorpak.wordpress.com/2013/05/14/what-is-combinatorics/ <comment><USER2> There isn't a good textbook for this field... or at least there wasn't one 10 years ago when I last took a course on combinatorics.

<comment><USER3> There are a few quite large sub-fields, but there are classic textbooks covering most of these. Here are some:

For classical enumerative combinatorics, there is Richard Stanley's 'Enumerative Combinatorics'.

For graph theory, Diestel's book 'Graph Theory' is popular for introductory courses, and Bollobas' 'Modern Graph Theory' is more advanced and (as the title says) modern.

And there is Laszlo Lovasz's fantastic 'Combinatorial Problems and Exercises', which is a collection of problems and answers, and is a great way to get a feel for the subject.

</comment></comment><comment><USER4> the UD definition would involve poker, and not much else.</comment>


Nairobi Dev School - <AUTHOR> http://www.indiegogo.com/projects/nairobi-dev-school

<comment><USER2> Look at this! This 19 year old Kenyan girl raised the funds to go to Hacker School in NYC, and then couldn't get a tourist visa because they're afraid that she's going to outstay her welcome. Agh! It makes my blood boil. Anyway, instead of being disheartened, she's setting up a Hacker School in Nairobi. What a badass! Here's where you give her money</comment>


800Gb of possible Census Bureau data (tax records,etc) leaked. Check your data - <AUTHOR> https://cybernews.com/security/report-unidentified-database-exposes-200-million-americans/ <comment><USER2> It's asking for my email to check if my census data has been leaked? Email isn't even shown as a field in the leaked records. Is this site just harvesting emails?

<comment><USER3> don't think it's a scam. forbes covered it ([https://www.forbes.com/sites/zakdoffman/2020/03/20/stunning-...](https://www.forbes.com/sites/zakdoffman/2020/03/20/stunning- new-google-cloud-breach-hits-200-million-us-citizens-check-here-if-youre-now- at-risk/#35eeee4d8587)) although more neutrally than this title

<comment><USER4> Are we really still using Forbes as evidence? Forbes is blogspam. I need a much more credible source before handing over my email to this site.

</comment></comment></comment><comment><USER5> It's 800GB, not Gb. Original title has been replaced completely and used wrong units. Original is "Report: unidentified database exposes 200 million Americans" which is far more useful.

<comment><USER6> Why do people unnecessarily change titles like this?

</comment></comment><comment><USER7> While there could be census data, this is weak substantiation and feels more like click-bait:

> It seems that much of the data on the main folder might have originated from > the United States Census Bureau. Certain codes used in the database were > either specific to the Bureau or used in the Bureau's classifications.

</comment><comment><USER8> > Enter your email to check

Uhhh this is definitely a scam

<comment><USER9> Agreed. I didn't enter my email during the census

<comment><USER10> Also, why would census data include a credit score?

This is fishy.

</comment></comment></comment><comment><USER11> This data sounds like it could have been someone's copy of the voter file, the database political groups keep on every American who can vote. Versions of that file have leaked before. There's some speculation some of the leaks have been deliberate, to illegally avoid campaign finance laws.

<comment><USER12> Got a link? That sounds like interesting reading. (The explanation of how leaking a database of every voter's info helps exploit a loophole in campaign finance law, I mean, not the data.)

<comment><USER13> I don't have a link, but here's how that would work: there are strict limits (a few thousand per donor) on how much an official campaign can raise/spend. Outside/independent groups have no such restrictions (see Citizens United) - they could take a billion dollars from one donor and spend it all on behalf of one candidate. But what good would the official restrictions be if the campaigns could call the independents and say "buy a million dollars of ads for me". So there are also strict laws about "coordination". You can probably figure out the rest by yourself... But leaving the records in a place where they are "available to the public" provides plausible deniability to the coordination problem.

</comment></comment></comment><comment><USER14> I am certain that this is a scam. After having worked extensively with Census data there is no place, AFAIK, that the Census Bureau collates mortgage, credit and tax data or has the capability to. The datasets listed here sit in 3 disparate organizations - IRS, private banks and credit bureaus. There exists no mechanism to collate it in one place - you would need releases from individuals to get the credit data. IRS data is almost impossible to get (cf: DJT tax records). Finally, mortgage records are public but payment history sits with the banks.

</comment><comment><USER15> This doesn't have anything to do with the Census Bureau and isn't the current title of the page. ??

Yes, marketers have excellent info on all Americans and sell it to anyone. No, it doesn't have anything to do with the Census Bureau.

</comment><comment><USER16> Techradar also posted about this leak [https://www.techradar.com/news/major- data-breach-exposes-dat...](https://www.techradar.com/news/major-data-breach- exposes-database-of-200-million-users)

</comment><comment><USER17> It's annoying to see these leak check things that don't actually show you what specifically was leaked about you.

There are big differences in risk factors and reactions depending on what specific data was available.

<comment><USER18> Problem there is that making it easy for you to see info about you makes it a lot easier for me to see the info about you.

</comment></comment><comment><USER19> Doesn't Google know who is using their services? Who paid?

<comment><USER20> someone with a stolen credit card, probably

</comment></comment><comment><USER21> Cyber news has done many of these stories.

</comment><comment><USER22> First we are legally required to give them our info then they leak it

</comment><comment><USER3> isn't the census about to start this year? this is some "same shit, different toilet" scenario. all these so-called secure government institutions or private companies or wherever this database came from. always promising a lot, and delivering little.

that's what happens when non-cybersec people are in charge of cybersec things

<comment><USER23> We have been doing the census for hundreds of years and it seems to go pretty okay.

If someone wants to map your name to your home address, they already have the voter registration database for that.

<comment><USER24> It's all the data that's not census data and the fact that it's joined with census data. Why is this data joined with tax information, calls to fire departments, and bike share information?

<comment><USER23> Because people use their real name as the primary key in almost every database? The census team did not steal Lyft's database and leak it.

<comment><USER24> Yes it's their fault for using their own name. It's not the fault of the people keeping creepy dossiers on random customers that creates this hazard.</comment></comment></comment></comment></comment>


In Memory of Dennis Ritchie: Remembering the Creator of Jobs, Torvalds and Gates - <AUTHOR> https://medium.com/@caspervonb/in-memory-of-dennis-ritchie-b3304f1b86ff <comment><USER2> This just in; Dennis Ritchie father of 3.</comment>


Show HN: Stripe for Printing - <AUTHOR> https://www.infraprint.com/

<comment><USER2> I think it's truly awesome that "stripe for X" now means "X with a sane REST API".

<comment><USER3> I like how Stripe made it cool to put example curl requests right on the front page. I guess I'm biased in that I love marketing aimed squarely at developers.

</comment></comment><comment><USER4> It's been a while since I saw something and instantly had a dozen ideas for things I could build with it. Nice!

Has all the makings of a great infrastructure business. Once a startup or SME (or big enterprise) gets something like this integrated, they're often loathe to rip it out, so the cheques keep on coming.

</comment><comment><USER5> I have two apps that use the Amazingmail API to print and mail postcards on demand. ([http://babygra.ms](http://babygra.ms) [http://lulcards.com](http://lulcards.com)). Their prices are extremely competitive compared to Infraprint's and their customer support is excellent.

[http://www.amazingmail.com/direct-mail- automation](http://www.amazingmail.com/direct-mail-automation)

edit: I'm also pretty sure this is the same service that Sincerely uses for their Ship API. If that's true they are basically a middle-man for the excellent work Amazingmail does.

<comment><USER6> When I looked into Amazingmail, it cost $2K for an API key. Is this still the case?

<comment><USER5> Yeah, it's not really for an "API key" though, that oversimplifies things. You are paying for support in setting up your account. For something like printing it takes a few iterations to make sure things are set up properly and you are producing the proper assets for them to print (colors, margins, etc.) This isn't a turnkey thing like Stripe or other APIs, there are a number of practical issues that you need to address when designing something for automated printing. When I set up my account with them they caught a number of issues with my template before I started printing, and then verified physical prints looked acceptable before mailing me some test prints. This support is what you are paying for.

A self-service REST interface like this, for non-trivial jobs, is going to either require the same level of setup/support, which is a cost they are swallowing somehow but won't be sustainable in the long run, or will require you to do a large number of test-runs to get things right before going live, with each test-run taking about a week before you have the physical result in your hands. And even then, there may be issues that you are unaware of, such as cropping, clipping, or color bleeding, that may occur only a small percentage of the time based upon their specific process if you did not design things properly. There's no free lunch.

</comment></comment></comment><comment><USER7> IMO this is a little premature, I know it has an alpha label but functionally this has catch up to do with a number of existing offerings in what is a fairly competitive space. That said, a sane API on top of a service that works globally would appeal.

Here are some suggestions: 1) add the ISO 216 paper sizes that most of the world uses, 2) integrate to various contact / address book formats, 3) add a templating/mailmerge feature, 4) figure out a capability to print and send in more countries than just the US and 5) imagine what questions a compliance officer will ask about security, privacy, data sharing etc and answer them.

Look forward to seeing it evolve.

Edit: formatting lists. Grr.

<comment><USER8> Could you list some of the competitors? The space doesn't seem competitive, it seems like crap.

<comment><USER5> Amazingmail has been awesome. Their actual API isn't really the most elegant thing in the world (XML), but on the list of things that matter when you are dealing with printing and mailing physical products this comes in low on the list of what's important. Their API is reliable and feature complete and my customers have been thrilled with their prints, which is all I care about. Not to mention, their customer support is superb.

I think it's great to see more competition here but people pointing to a REST API and nice website and ignoring the fact that there are no actual examples of their work or any reason to believe they can deliver on their service, nevermind that their pricing is insane, show these people have not done their homework or are focused on the wrong things.

<comment><USER8> Thanks! I am currently shopping a low-volume on-demand print service... as soon as I went to AmazingMails site and saw "no minimum" I became delighted, will be testing them out this week!

</comment></comment></comment></comment><comment><USER9> I don't really do postal mail any more. After you've printed it, could you scan it in and email it to me instead? :)

</comment><comment><USER10> After reading the comments here, I understand that this seems to be US only but would it really be that hard to just point it out on the website? Nowhere I can find something about a country restriction...

</comment><comment><USER11> I've got a card in my project ideas Trello board titled, "Print on demand postcards API." It's cool to see that someone else had the same idea.

<comment><USER12> Was on my ideas list as well! I think it's something that's just begging to be done. Good luck!

</comment></comment><comment><USER13> I'm a photographer, i want to be able to offer 150 limited prints to viewers of my website printed onto very specific paper sizes and qualities. Is this something infraprint can do? How does it integrate into payment systems such as stripe? Ideally i want to offer the user 1 button to print that takes them through the entire ordering and fulfillment process.

<comment><AUTHOR> Yes we can do this. However, currently they would have to pay you and you would have to pay us.

<comment><USER13> Hmm ok thanks, maybe something i can customize in the checkout script to make it seamless.

</comment></comment></comment><comment><USER14> That seems a lot like Peecho ([http://www.peecho.com/](http://www.peecho.com/))

A few questions: \- Which area are you able to ship to? \- Do you or plan to print posters (80x60cm and larger)? \- any notable difference compared to Peecho?

</comment><comment><USER15> This is something I've wanted for a long time -- Peecho with sane US pricing and distribution would be great. The front page says "Create on demand books and flyers," though, and I don't see any binding options listed elsewhere on the site. Is this in the works?

<comment><AUTHOR> We offer it to a few customers who use it. Still trying to figure out the best way to offer it publicly. Happy to work with you if this is something you are looking to do. We definitely need more feedback on this one.

</comment></comment><comment><USER16> You can also check out Infraprint's interactive doc (Mashape) here - [https://www.mashape.com/infraprint/infraprint#!documentation](https://www.mashape.com/infraprint/infraprint#!documentation)

</comment><comment><USER17> Any details on the stock/colors that you use? Is the stuff coming out at commercial print quality? Digital print? Or are you just a couple guys with a nice inkjet and some fancy API footwork?

Can I choose stock, or finishing stuff? Matte vs. Gloss?

<comment><AUTHOR> These are printed on high quality printers. Yes you can choose between stock and finishing.

</comment></comment><comment><USER18> Looks good. I used Sincerely's Ship API for a postcard app a while back. Would be good to see some examples of your past print jobs for a quality comparison (or better yet to request some samples). Will check this out.

</comment><comment><USER19> I'm curious. At what volume of customers/work does this kind of business change from being a guy who reads the requests, opens files, and prints them to being a more automated solution?

</comment><comment><USER20> Where can I see examples of the resulting printed product?

</comment><comment><USER21> This is a great iteration after receiving plenty of useful feedback on the last post (mine included) ... especially on the home page. Keep up the good work

<comment><AUTHOR> Thanks and good to hear. Keep the feedback coming! Its all about iterating based on what users say.

</comment></comment><comment><USER22> How do you compare to a service like trypaper.com? They seem to have been around a little longer and have more reasonable pricing?

</comment><comment><USER23> Do you guys plan to offer greeting-card printing? Realize it may be slightly harder than postcards.

<comment><AUTHOR> Would love to talk and understand how you imagine this would work. DM me.

</comment></comment><comment><USER24> The object pricing calculator is not working for Paper Size 6" x 9"

</comment><comment><USER25> I'd love to use it for Picplum. Do you guys have Lustre prints?

</comment><comment><USER26> Where to do you ship? Just the states? Canada?

<comment><AUTHOR> Everywhere. contact me directly if you want international we are piloting this with a few select customers right now.

</comment></comment><comment><USER27> No clouds over Europe... shame.

<comment><AUTHOR> Soon. We can work with you to get this started!

<comment><USER10> Hey, drop me an line (email@example.com) because I'm interested in this in Europe as well.

</comment></comment></comment><comment><USER28> This needs poster printing

<comment><AUTHOR> We just started doing poster printing for some customers. Let me know what you are looking to print and we can have it integrated into the API

<comment><USER28> Awesome! Ideally 11"x17" and 18"x24" in 20 & 100# - I'd love to see pricing for those!</comment></comment></comment>