High-speed trains are coming to America - <AUTHOR> http://www.onearth.org/article/on-the-fast-track <comment><USER2> Seems like the big advantage of "no waiting in line for check-in, security, or boarding." can't last.

<comment><USER3> It has lasted everywhere where there are high-speed trains. Check-in, security checkpoints, and boarding 300 people through one tiny door are all exclusive to air travel. When you take the train, you buy your ticket from a machine, put it in a turnstile to access the platform, and then wait until your train pulls in. Then you board through one of the 20-or-so doors that is closest to your seat. It's really that simple, and it has been that way for years.

Remember, America is almost 45 years behind the rest of the world here. The first Shinkansen in Japan went 130mph and started carrying passengers in 1964. We still don't have anything like that (except Acella), in 2009.

<comment><USER4> Actually, in Spain, we had to go through a metal detector to get on train from Sevilla to Madrid. Security wasn't as tight as for airplane boarding, and was very quick, but I was very surprised to find it there at all.

<comment><USER5> mmm, AFAIK , there are no metal detectors in AVE (Alta Velocidad - High Speed) trains in any of the 5 or so routes we have in Spain (just took a couple of them a week ago). They do we have a small x ray machine for carry on baggage, but the process is ridiculously fast (about 5 - 10 seconds total).

This is really important if you think that we do have an in active terrorist (or political liberation, according to some) group in Spain, which targeted those trains in the past.

<comment><USER2> Interesting point, especially since trains (or at least train stations) have been targets in Spain.

</comment></comment></comment></comment></comment><comment><USER6> Things that are actually more efficient don't require subsidies....

I like trains, but as passenger transport, they're not competitive.

Yes, I know about the energy efficiency of a full train. However, you can't have both decent utilization (reasonably full trains) and reasonable ridership. And, if you don't shoot for reasonable ridership, the fixed and labor costs will kill you. At reasonable ridership, lower utilization kills the realized efficiency and you're still having trouble with fixed and labor costs.

Note that govt involvement makes things worse. If a congress critter comes from a particular town, that town will get a stop, regardless of whether that makes sense. (Stops have a huge impact on average speed.)

<comment><USER7> Not competitive compared to what?

Combined spending by federal, state, and local governments on roads and airports amounts to _hundreds of billions of dollars a year_. Not exactly a profitable enterprise. Throw in the billions spent by end users of these roads on their own vehicles, and it's hard to see why there is such a fuss over the funding of trains.

I'm not saying they are always the best solution in every situation. Planes will continue to win for long distances, and roads will continue to win for short ones, but there is a definite middle ground where trains shine.

Having some double standard about profitability and competitiveness when we subsidize airports and highways to the tune of hundreds of billions a year seems rather disingenuous.

And I wholeheartedly agree with your statement about government involvement leading to perverse decisions, but remember that this is the case whether we are talking about trains or highways or any other big spending project.

<comment><USER6> > Combined spending by federal, state, and local governments on roads and > airports amounts to hundreds of billions of dollars a year. Not exactly a > profitable enterprise.

Profit is not measured by spending, but by the relationship between spending and revenue.

> it's hard to see why there is such a fuss over the funding of trains.

Because they lose public money - they cost more to build and run than folks will pay to use them. I've no objection to you spending your money on them, but I'd rather not spend my money on them.

> Having some double standard about profitability and competitiveness when we > subsidize airports and highways to the tune of hundreds of billions a year > seems rather disingenuous.

We don't subsidize highways; the total taxes collected more than cover the costs. That's why the rail folks try to get a piece of it.

<comment><USER7> > _We don't subsidize highways; the total taxes collected more than cover the > costs._

Sorry, but this is a commonly held misconception. From this article: <http://www.foxnews.com/story/0,2933,274113,00.html>

_"Close to two-thirds of the trust fund's $40 billion in receipts last year came from the gasoline tax."_

So the trust fund, which is made up of gas and diesel taxes, amounts to about $40 billion a year.

As I have pointed out before here: <http://news.ycombinator.com/item?id=260824>

Total federal outlays were about $67 billion that same year, and states and local governments usually throw in billions more.

And besides, I never claimed you can't fund rail via use taxes. But subsidizing roads to the tune of billions a year and expecting rail infrastructure to compete without such subsidies is just silly.

<comment><USER6> Gas taxes aren't the only taxes that come from autombile use.

</comment></comment></comment></comment></comment><comment><USER8> Wow! I'm all for trains. This made me sad: [http://en.wikipedia.org/wiki/Great_American_Streetcar_Scanda...](http://en.wikipedia.org/wiki/Great_American_Streetcar_Scandal)

</comment><comment><USER9> Taggart Transcontinental...?

</comment><comment><USER10> This is very interesting... I hope it will be much faster than Amtrak. If you take Amtrak from NYC to San Francisco for example, it would take around 50 hours with stops!

I know some people who don't really like to fly, and still prefer train or car in travelling.</comment>


Porting 30K lines of code from Flow to TypeScript - <AUTHOR> https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ <comment><USER2> I recently did the exact same job as the author of this post.

Migrating 15K LoC from JS to TS.

The author of Vue.JS also migrated Vue completely to Typescript.

At first I had major apprehension because of how much Microsoft generally enforces things on developers.

It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )

But after I did the migration , I was blown away by how confident and how much flexibility I had when i was writing my code.

Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence.

Having used Javascript since before Node.JS , I think the whole idea of having to "transpile" my code to something or to respect some "rules" define by a company with a reputation that wasn't really "all in open source" .

But after using Typescript on multiples projects , you just can't go back , it's incredible how well it's scale without enforcing anything on the developers.

Hopefully , one day bootcamps will include Typescript in their trainings to demonstrate how typings can solve maintainability issues...

<comment><USER3> "Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence."

Same here.

Isn't this truly amazing?

Take a jangly language like JS, and add some typing for the compiler, which forces you to write cleaner code in addition to all the compiler advantages ... combined with some really cool features and _bang_ a magical, pragmatic language.

Aside for some script things for which Python is still a blessing, I'd chose TS for everything else, at least to start.

It just has the right mix of flexibility and expressivity etc..

Though TS is an MS project, I suggest it really is quite different, it's 'open from the start' kind of thing, you can have a loot at TSC internals. The team seems to be fairly dynamic and responsive.

Typscript is my #1 favorite 'invention' of the last few years, I think it will be around for a while, and I hope to see many more JS API's 'properly documented' with the help of TS.

<comment><USER4> The exception I'd add is that JavaScript's standard library is still very weak. I find myself leaning on Lodash for functionality that would be built into any other language.

Part of me would love for TS to build one out and add shims as part of the transpilation process, but it would go miles out of the scope of what TS is trying to do. And I love that (compared to Babel) TS has no plugins and relatively few options.

<comment><USER3> This is a very good point.

I wish lodashy functions, and a few other things (Time?), were just integrated into JS, in a thoughtful way ... as part of the standard lib. So they could all be done in native code in the engine.

<comment><USER5> I'm sympathetic to this point of view, but I find lodash to be too huge of an API. Most of the collection methods can be done as a small _.reduce, and I find the many method names and subtle distinctions to add more trivia than they remove.

<comment><USER4> The good news is that you can use lodash as an ES6 module, with any tree-shake capable bundler stripping out all the crap. Absolutely agree it's not optimal though.

</comment></comment></comment></comment></comment></comment><comment><USER6> They wrote: "The TypeScript compiler could theoretically perform bundle optimizations based on types and you are missing on that by having a separate emitter and type checker."

Actually, this isn't true, and it's a fundamental property of TypeScript. It's actually the secret to being a TypeScript wizard, and the more you internalize it, the more questions about TypeScript you can answer in advance. I go through some others here: [http://neugierig.org/software/blog/2016/04/typescript- types....](http://neugierig.org/software/blog/2016/04/typescript-types.html)

It's an important property in part for exactly the reasons this author worries about it -- it preserves the property always safe to type check and emit separately.

It's so fundamental to TS that their bug tracker, when reporting a bug, has a checkbox about whether your request violates this property, and if so they will discard your bug.

<comment><AUTHOR> Author here, I actually addressed this in a footnote linked directly to that sentence you quoted.

EDIT: This is incorrect ^, I misread your comment at first.

Thank you for bringing this up, this makes me feel even better about using Babel to emit code.

<comment><USER7> I might be missing something, but that sentence does not appear to have a footnote, nor do any of the footnotes directly address the OP's comment.

<comment><AUTHOR> Oops, you're right, I misunderstood the original comment.

</comment></comment></comment></comment><comment><USER8> Even though I'm a huge TypeScript fan, I'm grateful for the existence of Flow.

Their focus on soundness has shown the TypeScript team that they should give a lot more priority to getting the typesystem in a better shape over the years. If Flow didn't exist, I doubt we'd be seeing many of the features in TypeScript's --strict mode.

Plus, they were the first to develop some features like intersection types, or even some of the advanced type transformations. Shame it was (at least historically) a bit difficult to find them in the docs.

I'm hoping Flow can push TS to close up the remaining soundness gaps, and fix up some of their features (sealed vs open types is much better than the strange object literal checks in TS)

<comment><USER9> Competition, even for open source projects is a great boon.

I really would hate for Facebook to kill off flow because Typescript is popular.

Microsoft, as great as they are at OSS, they still have to answer to a chain of Managers who are distant from the actual users of their software.

<comment><USER10> I actually think TS team is much closer to the community than Flow's. Just look at the number of open and closed Issues on GitHub.

To me, Flow feels like something they needed in Facebook and they happened to open source. Their main focus is still FB's internal use and the direction is set by it.

TypeScript, on the other hand, does not feel like this at all. They truly put the community first, or so I - and many others - feel like.

<comment><USER11> > _Flow feels like something they needed in Facebook and they happened to open > source_

This is how most Facebook tools feel to me. It makes me afraid to use them. React is possibly an exception, but again -- too afraid to use it because Facebook's open-source offerings seemed to have only selfish goals in the past and often seem to be full of important bugs.

</comment></comment></comment></comment><comment><USER12> Are there any people that have switched to TypeScript that still think dynamically typed languages have advantages over statically typed ones? Even for small projects with only me working on them, I find static typing saves me a ton of time and dynamic features are very rarely required or useful. The vast majority of bugs in my TypeScript programs collect around the places they interface with untyped JavaScript code.

<comment><USER13> Does TypeScript let you build a program interactively as a living thing? Example of what dynamic languages for the browser (ClojureScript) have been doing for 5 years now: [https://www.youtube.com/watch?v=KZjFVdU8VLI](https://www.youtube.com/watch?v=KZjFVdU8VLI) Given that frontend work is so often an endless series of tweaks I don't know how people stand doing anything big for a long duration the classic way of edit -> compile (refresh) -> rebuild runtime state to look at what changed/play around/test -> repeat.

<comment> basil-rash To me that example doesn't look all that different from typical hot-reload provided by webpack or similar. Can you tell me what I'm missing here?

<comment><USER13> I'm not familiar with webpack but in general hot reloading isn't quite the same as dynamic redefinition, but can be close enough for many purposes. If you can set up something approaching Java's hotswap (made even better by JRebel) then perhaps the advantage is lessened.

<comment><USER14> You get dynamic redefinition with Wright[1][2] and chrome, and you can plug in Typescript pretty easily.

In v2 currently under way, you can use es modules which gives you a much better experience since you can reload a single file instead of an entire bundle (always sub 100ms update times).

[1] [https://github.com/porsager/wright](https://github.com/porsager/wright) [2] [http://porsager.com/wright/example.mov](http://porsager.com/wright/example.mov)

</comment></comment></comment></comment></comment><comment><USER15> This is wrong: (from the article)

      function f(leaves: Array<Leaf>, aggregators: Array<Aggregator>): Array<MemsqlNode> {
        // The next line errors because you cannot concat aggregators to leaves.
        return leaves.concat(aggregators);
      }

That's just wrong, of course you can't concat aggregators and leaves! and Typescript is OK to not accept it. If you want that to be ok, you could do something like

      [].concat(leaves, aggregators)

<comment><AUTHOR> Author here. I understand this example may be a little controversial. However, from my point of view, if I annotate my function as returning an `Array<MemsqlNode>` and `leaves.concat(aggregators)` can be cast to `Array<MemsqlNode>`, then I don't see why I shouldn't be able to return this in this function without verbose syntax or "tricks".

<comment><USER15> it's not a trick. Yes, it can be casted, but you should be explicit about it. AFAIK, the signature for the concat function is dependent on the array you're using it, so in this case, it's Array<Leaves>. Even though concat returns a new array, it is expecting the arguments to be of similar type. That's a "safe" behavior and something I would expect. Auto-casting to the return type (in this case) is something that I would not expect to happen, as it could be the source of errors.

Doing [].concat(Array<A>, Array<B>) is fine, because you did not specify the type of the array for the literal [], it's not a trick, in that case the type should be Array<any>, but it's casted to Array<MemsqlNode>.

<comment><AUTHOR> Right but isn't that effectively changing the runtime code (thus making it a trick) in order to fix a type error? I don't know if the performance of `a.concat(b)` is the same as `[].concat(a, b)`.

<comment><USER16> The argument is that you have a potential type error in `a.concat(b)` that you hadn't considered before in that code: If `a` is defined everywhere as Array<Leaf> and you push() something to it that is not a Leaf you potentially broke one of your own invariants somewhere else that uses `a`. In JS concat happens in place and is a mass push, so the same general concept holds.

<comment><USER17> `concat` doesn't happen in place, it builds a new array:

        https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/concat

<comment><USER16> Interesting. Then that should be a fixable bug in TS' lib files then.

<comment><USER16> There's an issue mentioning it with a PR Welcome sign up: [https://github.com/Microsoft/TypeScript/issues/27545](https://github.com/Microsoft/TypeScript/issues/27545)

<comment><USER16> Ah, and there is at least one PR specifically for it: [https://github.com/Microsoft/TypeScript/pull/25716](https://github.com/Microsoft/TypeScript/pull/25716)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> What about the speed of type-checking? Flow is near-instant by keeping everything live from the last check whereas TypeScript has always been much slower.

Other than that aspect (which is very important!) I do think TypeScript is likely a better choice if you use any third party libraries that already have definitions available.

<comment><USER19> I work on a >100KLOC Flow codebase and I can tell you the type checker is anything but instant.

</comment></comment><comment><USER20> > unfortunately when you share a TypeScript playground link, those settings > are not saved in the URL. For this reason, you have to manually set them > when you open any TypeScript playground link from this article.

There is a much better typescript playground[0] that supports all options in the permalink, for example see this link[1] that has `removeComments` enabled.

[0]: [https://typescript-play.js.org](https://typescript-play.js.org)

[1]: [https://typescript- play.js.org/?removeComments=true#code/PTA...](https://typescript- play.js.org/?removeComments=true#code/PTAEBUAsEsGdQMYHsC2KCmA7ALqA7tADaGgAmcAhgA5XoUBOAUMprEoegHSFIDmAFAHIocUBliwKvdPiIl66FBWiZBASgDcQA)

<comment><USER21> There's also a good TypeScript playground clone here as well:

[https://agentcooper.github.io/typescript- play/](https://agentcooper.github.io/typescript-play/)

<comment><USER20> This links to the same code as my post. You might just have an older bookmark. See this PR[0].

[0]: [https://github.com/agentcooper/typescript- play/pull/24](https://github.com/agentcooper/typescript-play/pull/24)

</comment></comment></comment><comment><USER22> I wish Typescript had support for partial function application, since I use that much more than "Executioner" classes.

Actually, I've moved away from OOP in general in my JavaScript, only as a last resort. (Not going to put in long comment from tablet screen...)

<comment><USER23> Outside of type annotations, Typescript never supports syntax that isn't in an ECMAScript standard or a popular proposal.

That said, there is a Stage 1 TC39 proposal for partial application. [https://github.com/tc39/proposal-partial- application](https://github.com/tc39/proposal-partial-application)

<comment><USER22> Thanks for the tip.

I have been using Ramda's R.partial() function a bit, as well as some in-house stuff (e.g. - to generate 0-arity event handlers), but this would be a very helpful feature, particularly once IDE recognition becomes widespread.

Background: suite of related projects started in early 2015, ES5 on IE11 kind of limitations... (recently started using a transpiler for syntactic sugar)

</comment></comment></comment><comment><USER24> I'm currently porting about 15k lines of my own JS to TS. There's something so satisfying about finding all kinds of bugs through this process.

And what I love the most: anywhere that I absolutely positively don't want to deal with it yet: `any`

</comment><comment><USER25> > Lower quality editor/IDE integrations (when compared to TypeScript)

This is one of my favorite aspects of TypeScript, the first-class support it receives in Monaco Editor (part of VS Code) which is one of the reasons I also chose first-class TypeScript support when making Autumn, since I could embed Monaco right into it and get countless amazing IDE features for free.

> unfortunately, we had to change a very small amount of runtime code to fix > some logic that TypeScript could not understand

Would be very curious what this is, I've only found maybe one or two things TypeScript could not understand, and they were already under active development in the Github repo.

<comment><USER26> > countless amazing IDE features for free.

Is this just from LSP? Or are there extras that are built into VSCode?

<comment><USER27> Ironically typescript doesn't have a supported language server from MS. TSServer (in the typescript npm package) is language server-esque and that's what VS Code plugs into. I believe the main language server for typescript is maintained by sourcegraph.

VS Code is written in typescript though and the projects have a pretty nice cadence of new features. Typescript is very much a first class citizen in VS Code

<comment><USER28> Pretty much anything that comes from Microsoft today that is a web app, or uses the HTML for UI on the desktop (such as Electron apps), is likely to be written in TS. Not even because there's some push to do so, but because people who mostly write in C# and C++ find TS far more preferable.

(That, by the way, is one reason why you can trust that it's not going away anytime soon.)

</comment></comment></comment></comment><comment><USER29> Thanks for sharing that.

We've just started a new Node project where typing was one of the main drivers and went through a similar thought process. We use Flow on our client code but the positive chatter about TypeScript had made us wonder if we should re-think that. We have similar thoughts on a lot of the trade-offs. Flow feels better at inference but the TypeScript ecosystem is amazing.

We ended up sticking with Flow for consistency (and we don't want to migrate the client right now). It's good to know that a migration isn't impossible if we ever change our minds.

</comment><comment><USER30> Thanks for this writeup! We also chose Flow in 2016 for the exact same reasons you listed.

We aren't planning on switching anytime soon because we also are using Relay which generates flow types for our GraphQL queries - but its good to know its doable if we need to.

<comment><USER31> Relay supports generating Typescript types for queries as of v1.7.0

[1]: [https://github.com/facebook/relay/pull/2293](https://github.com/facebook/relay/pull/2293)

[2]: [https://github.com/relay-tools/relay-compiler-language- types...](https://github.com/relay-tools/relay-compiler-language-typescript)

</comment></comment><comment><USER32> For anyone working on Nodejs targeted TypeScript I would highly recommend checking out ts-node. I use it a ton when I want to not worry about the pre- compilation step for various reasons. Can work with absolute imports, and caches code on the first run as well. Pretty sweet.

[https://github.com/TypeStrong/ts-node](https://github.com/TypeStrong/ts-node)

Article mentions ts-jest; can also recommend. I use Jest for all my TS projects from serverless to selenium. Its watch mode is fantastic.

I also typically use ts-loader with Webpack instead of Babel.

Eh, might as well toss a few more recommendations in there:

* source-map-support

* Bluebird for long stack traces with async/await(v8 now has a zero-cost feature behind a flag now though as of end of 2018)

* Get the debugger hooked up to your browser/nodejs process for a great debug experience

<comment><USER33> Note for --transpileOnly flag which speeds up compilation if you've already checked for typing errors in your editors and don't need to do it again on compilation.

There's also ts-node-dev which is a variation of node-dev that auto reloads files loaded on change.

As for a bundler, parcel supports TypeScript out of the box which just allows you to write browser side code with TS without effort.

</comment></comment><comment> drew-y > This number scared us (a lot) at first but we quickly figured out that most > of these were related to TypeScript not supporting .js files.

Typescript actually does support .js files. You just need to use the `--alowJs` option.

<comment><USER34> I think it's a catastrophically poor decision to not have the allowJs behavior as the default. That one flag fixed almost all of the QOL issues I was having.

<comment><USER16> It's the default if you name your project-level config file jsconfig.json instead of tsconfig.json, which is an interesting convention versus configuration trade-off. VSCode makes this somewhat clear in some of its tools (it will offer to create a jsconfig or tsconfig for you and tries to guess based on source code metrics), but it's easy to miss in most Typescript documentation.

</comment></comment></comment><comment><USER35> What are the chances of ecmpascript adopting optional typing like they adopted the features in coffescript?

I've seen a few proposals around but it seemed that they were are stalled.

<comment><USER16> TC39 still has scars from ES4 which tried to add optional typing (and is the only "lost" ES standard that browsers never implemented).

My hope is that since then we have examples like Python's PEP 3107 [0] that help make sense as where a TC39 proposal could move forward: encourage browsers to AST parse type annotations, and ignore them by default; leaving the actual semantics still to tools like Flow and Typescript until there is a better convergence in semantics and/or browsers have greater needs of specific type annotations.

[0] [https://www.python.org/dev/peps/pep-3107/](https://www.python.org/dev/peps/pep-3107/)

</comment></comment><comment><USER36> Lots of love here for TS. I'd like to share my personal experience with it: I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors. Man, was it frustrating and JS felt suddenly crippled because it was hard to use its dynamics. TS catched a mistake here and there - true - but that did not equal out the hours burned by writing and debbugging type structures. In the end I removed every bit of TS from my projects and continued happily without it. I found out that using JSdoc comments and relying on the linting abilities of my IDE plus writing unit tests gave me stable code as well, without pulling my hair out. I was there before TS and just went back to it.

I get that TS may be a good idea if you deal with teams of mediocre devs to prevent they do stupid things but by talking with a couple of JS devs and looking at my own JS experience it seems like the desire of using TS vanishes if you reach a certain experience ans confidence using vanilla JS. It looks like the most people who embrace TS see JS as some kind of inferior thing, anyways - but that might just be a wrong observation by me.

<comment><USER37> > I went from "fast and convenient" with JS to constantly fighting against the > TS compiler and linter above cryptic type errors

Would you, perchance, be able to share an example of such an error? We generally strive to improve error clarity where possible~

> I found out that using JSdoc comments and relying on the linting abilities > of my IDE

Ah. Well, spoiler alert: if your IDE is vscode or VS that JSDoc is actually still getting typechecked by TypeScript ;)

<comment><USER38> Do you have a list of common errors that TypeScript usually will detect ?

</comment></comment></comment><comment><USER39> > A very common function in our source code is the invariant function. I can't > explain it any better than the documentation does

Seems like you'd have an easier time explaining what it does if you'd just called it "assert()" in the first place. This isn't a new concept, why does it have a new name?

<comment><USER40> It originates from design by contract (but is still the incorrect term). An assertion is not a contract.

<comment><USER41> How so? The major design by contract language I know of is D, and its contracts are essentially asserts that are either placed at the beginning of the body or prior to all returns.

You can certainly get substantially similar behavior just using asserts at the beginning of the function body and ensuring asserts at the end before a return are hit by all code paths (e.g. make an anonymous function that contains the body, then call it wrapped in a try/catch and assert on the return value.

Unless I'm missing something about design by contract, it's essentially just asserts at the beginning and end of a function.

<comment><USER40> Precondition (called invariant here): a set of conditions that must be met in order to call a method. Another name for argument validation, but it can be other things (e.g. connected must be true before calling methods on a connection).

Postcondition: guarantees that a method makes. For instance, it won't return null.

Invariants (incorrectly used): conditions that always hold true on a type, e.g. the starting index on a slice must always be greater or equal to zero.

[https://en.m.wikipedia.org/wiki/Design_by_contract](https://en.m.wikipedia.org/wiki/Design_by_contract)

I guess D is guessing via implications, but from what you've said it can't support invariants, meaning it doesn't strictly qualify as DbC.

</comment></comment></comment></comment><comment><USER42> No experience of Flow, and I hear all of the opponents of these "superset JavaScript" solutions who lament their inability to really tighten up the language in a way that a true static language would. However, JavaScript is clearly going nowhere anytime soon, and whilst WASM has the ability to change the state of play, I've found adopting TypeScript in general to be hugely beneficial.

It's 100% fair to point to all of the things it _doesn 't_ provide, or indeed the way that it tries to make JS out to be some classical OOP language which it's not, but it's helped me track bugs and refactor code in ways which would never have been possible without it, and for that I'm grateful. In comparison to other tools such as mypy, TypeScript is light-years ahead in its general ease of use and community support.

</comment><comment><USER43> I migrated Polar from JS to Typescript:

[https://getpolarized.io/](https://getpolarized.io/)

It's a pretty sizable app. The migration wet pretty smooth and I would absolutely never go back. Typescript is amazing.

<comment> lf-non Polar looks brilliant. Thanks for creating this and making this open source.

</comment></comment><comment><USER44> Partially inspired by this post (I was already convinced), I finally finished adding typescript to a javascript project I recently inherited. I'm an experienced backend developer but relatively new to frontend javascript stuff. Short term, I need to own this until we can expand our team.

Errors that a compiler would normally save me from when doing Java/Kotlin are a major PITA when you are dealing with a foreign code base in Javascript. Over the past few weeks I've slowly gotten comfortable with the code base, the build system (rollup, babel, less, and a few other things etc.), and the frameworks we use (redom, mainly). After updating everything to their latest versions (e.g. babel 6 -> babel 7) and getting that working; I figured adding typescript should be straightforward.

Turns out this is super easy and delivers instant value. The hardest part was figuring out what part of our somewhat convoluted build.js script to modify so that it processes ts files as well. After finding the relevant for loop and adding the rollup plugin for typescript that seemed to be working out of the box. I added a tsconfig.json file to support some ecmascript2017 stuff we apparently are using.

After that it got easier. I fixed a few hundred lines of javascript code to have types. That's in my first hour of using typescript. VS Code and tslint are very helpful. I also found and fixed the first type bug that slipped through earlier: instant value.

Kudos to MS. Vs Studio Code is a game changer. I've been shying away from doingb frontend stuff for years for reasons of it seeming to be backwards to be coding blindfolded with your hands behind your back. VS Studio Code changes that. Autocomplete, quick fixes, refactorings, import organizing, etc. So much better than my browser telling me I messed up by not loading the page.

I renamed several js files. Worked my way through the clearly marked warnings. Mostly quick fix works reasonably well. You do need to replace the any type with something more appropriate usually (like e.g. string). Anyway, free of warnings and vs studio code also found and added a redom type definition for us. Awesome. Very impressed with how easy that went.

Typescript only for me going forward. Opting out of a perfectly good type system seems silly.

</comment><comment><USER45> Glad to hear Typescript is winning hearts and minds. They've been great maintainers; avoiding the infighting, toxicity, and the perverse incentives that unfortunately plague the front-end landscape.

</comment><comment><USER46> > We didn't have to buy into an entirely new ecosystem of JavaScript > development. Dropping Babel for tsc (TypeScript compiler) was scary because > it wouldn't give us the flexibility

This shouldn't really have been an issue. It's always possible to not do any transpilation and leave it to another tool

</comment><comment><USER47> Ok, well done! BUT.... Now port it to something you can really trust like Reason ML. See [https://www.reaktor.com/blog/fear-trust-and- javascript/](https://www.reaktor.com/blog/fear-trust-and-javascript/)

<comment><USER48> Or Purescript =)

</comment></comment><comment><USER49> Any opinions on Webstorm vs Visual Studio for using TypeScript?

<comment><USER50> I was a long time Webstorm user until switching to Typescript, and found that its Typescript support is pretty far behind VSCode's. Its been around 6 months since I switched so I can't remember the specifics, except that VSCode generally had better indicators of what was wrong with the type.

Neither is perfect at displaying errors but that might also have something to do with your ts config. I also think that Webstorm is a much better editor than VSCode in every other respect, but for me VSCode is 1% better for my productivity so I am forced to use it.

<comment><USER11> > _found that its Typescript support is pretty far behind VSCode_

This isn't (can't be?) true. Both editors use the same language server. I've used both and found their language support to be identical, and WebStorm feels a little more natural to me when using automated refactoring.

I also have both eslint and tslint set up through WebStorm, so I have everything integrated in one place: hinting, linting, compiler warnings, and compiler errors.

VS Code can do the same, as far as I know. I just prefer WebStorm for other reasons.

</comment></comment></comment><comment><USER51> What is Typescript providing that you don't get by writing 1 test that checks type and by following modern ECMAScript specs? Does that justify a new syntax? The answer I think is no. I see much praise in this thread, but very little definition of why that praise is merited.

<comment><USER52> Tests don't cover everything and just on input and result. All the code in the middle can still have bugs that are uncaught because you don't have the right test for it.

Type systems provide a lot of safety with less work, meaning less bugs and more productivity. Just having the definitions available when writing makes you go faster.

<comment><USER53> > Type systems provide a lot of safety with less work, meaning less bugs and > more productivity

I hear this argument all the time. As well as the opposite: type systems slow you down and only catch easy-to-find bugs. Would love to see a real study that quantifies productivity among static and dynamic systems and ends this flame- war once and for all.

<comment><USER52> I dont think there are formal studies but there are quite a few discussions, this one on SE is good: [https://softwareengineering.stackexchange.com/questions/5960...](https://softwareengineering.stackexchange.com/questions/59606/is- static-typing-worth-the-trade-offs)</comment></comment></comment></comment>


Ark HN: Any Using Standing Desk at Work? - <AUTHOR> I am wondering how many company uses / to have a choice of Standing Desk at work. Or even require to use a Standing Desk. Given the obvious benefits to your health. <comment><USER2> Almost every job I've worked in the past twenty years around Seattle has let me have the choice of a standing desk. I know that some of my coworkers definitely preferred to have the stand up style of desk and were fairly productive in them. I took the standing option once and after two years of it, I found I prefer to sit "most of the time", especially so when I'm working on code. I found that after requesting the standup desk, I found a bit of guilt as I didn't want to stand most of the time. I compromised with a tall chair and a large foot rest instead of having facilities switch the desk back to sitting. This let me have a sitting desk that I could stand on occasion, but I could tolerate hopping down from the tall chair for only two years. I went back to sitting full time. Towards the end of my tenure my employer purchased sit/stand desks for everyone. Those were quite nice but pricey - I'd like to find one for my home office, but in the mean time, a sit down desk and taking regular walking breaks in the neighborhood seems to work for me.

</comment><comment><USER3> I started using a standing desk at my home office (I work remotely).

It takes some time to adjust too, after sitting for years, but is totally worth it.

I still have a chair that I probably sit in an hour a day, on calls or taking breaks.

I've seen some neat hybrid solutions at companies I've worked for (that let you, with the switch of a button, transition between standing and sitting height for your monitor and keyboard).

</comment><comment><USER4> We are a young startup, about 13 people in our office. 2-3 of us use a standing desk.</comment>


VR roller coaster ride collides in Madrid, several injured - <AUTHOR> https://vrscout.com/news/vr-roller-coasters-collide-madrid/ <comment><AUTHOR> Collision happened at the boarding area at moderate speed, causing injuries to 33 people.

None of the injuries appeared to be serious, yet it is believed that the VR headset prevented people to prepare for the collision, making them worse.

The ride had successfully passed all the daily maintenance checks.</comment>


From Linux to OSX - 1 Year Later - <AUTHOR> http://batsov.com/articles/2012/09/09/from-linux-to-osx-1-year-later/ <comment><USER2> Interesting. I actually love the Command key. I see it as a Control key for GUI operations, leaving my actual Control key free for doing things in my Terminal. This is actually a big sticking point when it comes to trying to work on Linux workstations like we have at work -- GUI and console stuff end up munged under the same modifier key (and this is harder to change than you'd think, even with a lot of xmodmap work).

That said, I've also ditched my Caps Lock key entirely and turned it into a second Control key. Control-A has never seemed difficult to me, at least with this arrangement, but I'm not a home row typist (or an Emacs user -- I just use the Emacs bindings in text boxes and terminals).

Otherwise this more or less mirrors my experience, although mine was ~7 years ago (so the Linux desktop environment was even less mature at the time). I haven't found a need to shop around for as many alternative applications. In particular, you can have Terminal.app when you pry it from my cold dead hands.

<comment><USER3> I never forget that time when I was ssh-ed on some machine and was doing something very urgent, and wanted to copy some text from the terminal to text editor (it was an Ubuntu machine) and accidentally pressed control-c and killed the session. I could've killed someone.

IMO, the Command key is one of the best features of a Mac.

<comment><USER4> I have the opposite problem. There's one command - I think it's probably <C-w> (split screens in Vim) that I always hit every time I'm using a Mac, and it inevitably closes my entire terminal.

The nice thing about Linux is that I can at least remap these keybindings. On OS X, it's literally impossible to do a perfect remapping of the keys (trust me. I've tried.)

Hopefully I've saved recently (or run the process inside GNU screen....).

<comment><USER3> If by <C-w> you mean control-w (I'm a vi user and don't know!), also take a look here: <http://news.ycombinator.com/item?id=4497258>

<comment><USER4> No, I already remap Caps_Lock to Esc - much more useful.

</comment></comment></comment></comment></comment><comment><USER5> I value free, open source software more than convenience. For this reason, I will not use OSX or any other non-free operating system no matter how convenient they may be to use. That convenience comes at a great cost that I am not willing to pay.

<comment><USER6> I'm curious about your thoughts outside of software. This is a sincere question because I often see so much passion about the topic in software, but rarely outside.

Do you only play free games, listen to free music and read free books? What about the electronics you use, the architecture of the buildings you live in and the car you drive?

<comment><USER4> The analogy breaks down for most things outside of software (even hardware, to a degree), because the basis for the argument in favor of free software is the four freedoms[1], which are themselves mere extensions of the rights of purchase.

If you sell me something, you cannot tell me that I can't modify it for my own use, for example. You as the seller can't tell me that I'm not allowed to resell my textbooks, or to modify the frames on my eyeglasses, or to hire my friend to fix my vacuum cleaner.

Proprietary software licenses _do_ do that - the main difference is that is a non-rivalrous good; I can redistribute software _without losing access to it myself_. Because of that, people think it's somehow 'wrong' to say that I should be allowed to purchase a program and then resell it to another person, but if you look at it the other way, that's no more 'wrong' than purchasing a physical good and then reselling it.

In the South, it used to be common to sell property on the condition that the purchaser never sell it to a black person (I think they still used the term Negro or 'colored' then). If I remember correctly, that was first deemed illegal in certain parts _not_ because it's horribly racist, but because it violates the principles of first sale: you've sold me something, and now you can't tell me what I'm not allowed to do with it.

[1] <http://www.gnu.org/philosophy/free-sw.html>

<comment><USER6> Textbooks and eyeglasses are guarded by copyright and patents. I cannot improve on the design of Oakley sunglasses and hire a firm to manufacture them. I can modify it for myself, but that is a much more limited form of freedom. Microsoft probably wouldn't care if I somehow reverse engineered Windows and modified it for myself only.

Same goes for architecture. When I buy a house, I can make modifications to it. But I don't think I have the right to hire construction companies to build new houses based on the design.

Electronics and car companies guard heavily the schematics and designs that makes it possible to repair their products much less reproduce them.

Edit - One more thing: Just the ability to modify something you own (like textbooks or sunglasses) does not make it free. For example, I've made many modifications to OS X through utilities and configuration. The fact that OS X doesn't come with source code is equivalent to Textbooks not coming with their LaTeX source.

<comment><USER4> > Textbooks and eyeglasses are guarded by copyright and patent

I'm talking about the physical book, not the words contained within.

> When I buy a house, I can make modifications to it.

When I buy software, I should be able to make modifications to it.

> Microsoft probably wouldn't care if I somehow reverse engineered Windows and > modified it for myself only.

That's explicitly prohibited by the license. Whether or not you think they'll enforce the license in your case has no bearing over the fact that it _does_ violate it, and free software advocates argue that such licenses cannot be nonenforceable.

In any case, patents are a separate issue altogether. So is copyright, actually - free software licenses are a way of twisting current copyright law into doing the opposite of what it was meant to do: provide freedom.

<comment><USER6> Let's take a step back and look at the goals of free software. It's not just to modify and tweak things I own, it's to allow me to modify, enhance and contribute that work back to the community.

By that yardstick, most textbooks and eyeglasses are not free. I can't improve a textbook and put it online. I can't put my improved sunglasses on the market (even if it was non-profit).

So why are people revolted by a copywrited and patented (hence unfree) OS, but have no qualms using other non-free products?

Personally, I think free and proprietary products can co-exist. Both models produce innovations which ultimately benefit society.

<comment><USER4> > By that yardstick, most textbooks and eyeglasses are not free. I can't > improve a textbook .... I can't put my improved sunglasses on the market > (even if it was non-profit).

Yes you _can_ \- the product in that case is physical, not digital. You can certainly turn the pages of a book into an origami creation and sell that on a secondary market if that's what you want to do. You can sell modified copies of physical products to your heart's content.

<comment><USER6> > You can sell modified copies of physical products to your heart's content.

Yes, but only in a very limited way. You've only mentioned examples where I can modify the original physical atoms.

I cannot modify and re-distribute the ideas present in textbooks. It is those ideas that have the most value, not the paper it's printed on.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I'm a hardcore Linux user, a sysadmin, developer of some kinds and an humble desktop user. For some IOS projects I have to use an hackintosh.

The experience is - in one word - disgusting. It lacks common denominator keyboard shortcuts and keyboard bindings. It lacks sane default simple applications like a decent terminal emulator. ( Yes Windows lacks is too). unavailability of a great package manager - all of us knows it, homebrew or macports doesn't cut it - makes me vomit. Unfamiliar key bindings makes me think twice or thrice before typing , "Which key should I use for this? Apple or Option? How can I skip to end of line? Why I'm at end of file now?" Also some desktop choices are not ok for my liking; switching to full height windows instead of full screen windows with the maximize button? Why on earth I would opt-in for loosing screen real estate? So many details.

Most of the time I can't help myself to stop restarting into Linux. I get slower and distracted. I have to install Mozilla Stack (Thunderbird and Firefox).

This may be only me but, I hate OsX. And I'm not starting on the "wanna be walled garden-ness."

<comment><USER8> _decent terminal emulator._ \-- lie.

 _makes me vomit._ \-- visit your local physician.

 _Unfamiliar key bindings_ \-- "Unfamiliar" by definition = "I don't know it" which isn't the OS's problem. You've gotta admit Command-C for copy being different than Control-C is brilliant.

 _switching to full height windows_ \-- it's not a maximize button, it's an "optimal size" button. If your content is 500px wide, you don't need a 1000px wide window full of white space.

 _may be only me_ \-- I'm pretty sure it is (check their stock).

<comment><USER7> Terminal as a decent terminal emulator? I believe you are referring to iTerm2 but that's not the default.

unfamiliar key bindings, look for any other keyboard except OsX ones and show me the apple or the option or the command keys then I will back.

For the "Optimal Size button", the underlying operation does not account for the contents width, it only accounts for the desktop height.

The world is not running on OsX or Apple hardware. They have a decent userbase but not the whole computer users are using one.

<comment><USER3> 1\. Terminal.app is a very good app. I switched to iTerm 2 a while back, but only because of a few minor features that I could've lived without. What are your problems?

2 & 4\. You don't run a Hackintosh and expect it to work. If you want OS X, you buy a Mac. And all Macs (except the Mini) come with standard Apple keyboard.

3\. I'm not sure what you're talking about. There's no "magic" algorithm that all apps use. Each app can use its own "algorithm" and can account for screen width as well. Just because Finder.app (most of the time) just grows the height doesn't mean all apps should do it, or are doing it.

<comment><USER7> Terminal app is a sufficient terminal emulator. But it lacks most of decent options. Can you split windows? Use tabs? Can you change color profiles? May be so many simple decent ap choices are lacking from it. Also I'm not even talking about the lack of simple Terminal emulation modes. I told you I'm a system administrator and I live in terminals. So Terminal.app is not cutting for me.

What's wrong with a Hackintosh other then legal and ethics issues if it's running well? I used Apple hardware and my criticisms were the same.

and for the 3, If every app is using it's own algorithm than I'm really on the wrong side of the issue. And my criticism lacks proper bases. I have to take it back. But again, why not a maximise button?

<comment><USER3> Terminal has tabs (had it since early 00's).

The lack of split panes was what made me switch to iTerm. I don't use it that often, but it's a "nice to have" feature. Terminal.app has split panes, but it's not "two sessions, side-by-side", rather "different windows into the same session", which I personally don't like much.

And you're right. You can't change the color profile like <http://kde- look.org/content/show.php?content=86353> , which might be a bummer for some one like you (you can change the 16 ANSI colors to look less horrible though!).

Why no maximize button? I don't know the reasoning behind that, but I don't miss it. Full screen apps are amazing (for one monitor scenarios), and OS X has a nice handy feature called "Hide Others" (Command-Option-H) that gives you a distraction-free experience without making the app ridiculously large (and showing you a million white pixels!)

[1] touches upon this issue and has good arguments for it.

But of course, power users need more "power", so I also use the wonderful Moom[2] which combined with "Zoom" and "Full Screen" fulfills 100% of my windowing needs.

[1]: [http://www.macyourself.com/2011/02/06/why-doesnt-mac-os- xs-g...](http://www.macyourself.com/2011/02/06/why-doesnt-mac-os-xs-green- zoom-button-maximize-windows/)

[2]: <http://manytricks.com/moom/>

<comment><USER9> > And you're right. You can't change the color profile like <http://kde- > look.org/content/show.php?content=86353>

I may be missing something but I don't see how it's different from what has been available since Lion (and since Tiger with a SIMBL plugin). I've been using Zenburn and Solarized since what seems like forever.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10>
      You need to install a giant lame IDE just to get
      a bunch of command line development tools?

That hasn't been true since earlier this year. If you login to developer.apple.com, you can download the "Command Line Tools for XCode" from here:

      https://developer.apple.com/downloads/index.action

No "lame" IDE required. But you might think that IDE is not so lame the first time you use Instruments...

<comment><USER11> To add to that: I think XCode is the most powerfull IDE I've ever used when it comes to coding c/c++/objective-c.

<comment><USER12> I have a macbook air and have some projects where I write cross platform C and C++ libraries (Linux/OS X/Windows via mingw), currently using Makefiles and a text editor. I use and like IDEs when programming python, C++ on Windows and javascript and certainly wouldn't mind a powerful C IDE. Can XCode help in this case or do you have to basically be writing Mac/iOS apps to access that power? Also can XCode work nicely with Makefiles or do I have to buy into a special platform specific build system (again a problem with the whole cross platform thing)?

<comment><USER13> "Can XCode help in this case or do you have to basically be writing Mac/iOS apps to access that power?"

I'm also very interested to get the answer of this.

</comment></comment></comment></comment><comment><USER14> Within the last year I have moved my work desktop (iMac) to Windows - RDP(actually Remmina/FreeRDP are looking good on Linux recently), VPN etc. just works better there - and development laptop (MBP) to Linux.

More and more as Linux matures and OS X gets buggier/fancier, I don't see the need to use OS X. I am running KUbuntu 12.10 beta on my 2010 MBP and it is pretty pleasant to work with - boots fast, nothing crashes, wi-fi connects and stays so, suspend resume works, no proprietary drivers needed. I did have to do some little hackery to do an EFI install and disable the Nvidia crap and that gives me very good battery life.

To get me to stick to OS X - Apple needs to do significantly better. Each release gives me new headaches and no features I need - bad battery life, Wi- Fi issues, graphics glitches - I can at least try to fix those with Linux.

</comment><comment><USER15> What annoys me about OSX is the whole "copy app to install"

"please wait while 500 megs are being copied". Oh hi non-shared libraries.

I also don't see what's so great about iTerm2, some lights would be interesting. Otherwise I'll claim Konsole is the best termminal emulator in the world, bare none just like that too :)

Finally I do agree that OSX gets Spotlight right. The Linux look alikes for this feature plain sucks. But that's probably the only thing I can see.

<comment><USER16> > What annoys me about OSX is the whole "copy app to install"

As opposed to "press a button (or 30) to copy/install"?

<comment><USER17> No -- as opposed to pacman -S package (or whatever his former distro used). Having come to Linux from OS X, I agree that OS X installations are pretty inferior to Linux's.

<comment><USER16> OSX does have homebrew (or macports if you're so inclined), which IMO is better than the usual package manager in a linux distro; it doesn't litter the disk with init scripts or config files, you always know where things are being installed to. Copy to install is only for GUI apps.

<comment><USER4> > Copy to install is only for GUI apps.

That's the problem - you have two completely different installation methods, neither one of which is particularly UNIX-y, and neither of which is capable of talking to the other in a reliable manner.

> IMO is better than the usual package manager in a linux distro

It's incapable of handling binary installations, which is remarkable considering the hardware variation is _far_ less than there is for Linux, it installs to /usr/local, it doesn't integrate well with language-specific package management tools, and it can't update system files.

> it doesn't litter the disk with init scripts or config files

I've never once had this problem with Linux; the man pages for any Linux package manager should provide a straightforward way of figuring out which package own which files.

> you always know where things are being installed to.

Because they're _not installed to the right place_.

I can't count the number of times an OS X package has told me that I need to add such-and-such folder to my $PATH. Hint: if you're requiring me to change my $PATH so that your installed file works, _you're not installing it properly_.

</comment></comment></comment></comment></comment><comment><USER3> Regarding the Control key - you can swap that with the absolutely useless "Caps Lock" key: <http://thehelpfulhacker.net/2012/02/15/killing-caps-lock/>

Now you can do CapsLock-a, CapsLock-e, etc. all day, which is much easier.

</comment><comment><USER18> ..and you've swapped from using an open OS to buying an OS from a company that fires patent lawsuits left and right. You've also bought that company's hardware.

I grant you it's convenient in many ways to use OS X, but supporting companies that commit patent mayhem is not good for our industry.

(Yes, yes, I know the competition isn't clean either, blah blah. But you switched from _Linux_.)

</comment><comment><USER19> >> _iTerm2 is the ultimate terminal emulator. It alone warrants the purchase of a Mac._

This is quite a strong statement and caught me a little off guard. What particular features does iterm2 offer that make it so stellar? I'm genuinely curious, as I haven't ever felt the burning need for a "better" terminal emulator on OSX (or Linux for that matter).

<comment><USER20> From what I remember, the default terminal emulator on OSX does not even allow customising the color palette! I was able to only change the foreground and background color, and forced to stick to one of the predefined themes for the rest. On the other hand, I doubt iterm2 can achieve the flexibility and customisability of urxvt, which for me is still the #1 terminal emulator. Just my two cents to add to the discussion :)

<comment><USER2> > From what I remember, the default terminal emulator on OSX does not even > allow customising the color palette!

For what it's worth, at least in Mountain Lion you can change the ANSI palette in Terminal.app. That said, it would never have occurred to me that this is something someone might want to do :).

<comment><USER3> Come on. The default "blue" color is ridiculously ugly. I always thought of it as a punishment for those who want to mess with OS X.

Compare that disgusting color palette with a sane one: <https://github.com/pstadler/optometrist>

<comment><USER21> I guess people don't know how to use google:

[http://osxdaily.com/2012/02/21/add-color-to-the-terminal- in-...](http://osxdaily.com/2012/02/21/add-color-to-the-terminal-in-mac-os-x/)

</comment></comment></comment></comment></comment><comment><USER22> Alfred[0] has to be one of the most valuable (as far as $/usefulness) pieces of software I've ever bought. Besides the Spotlight-style file/app search, can also manipulate files/dirs, does pasteboard history[1], and one-shot terminal commands; without having to drop whatever I'm doing for another window.

[0] <http://www.alfredapp.com/>

[1] not part of Alfred, but pbcopy/pbpaste in the terminal are your friends.

<comment><USER23> You can also use it for math expressions, type in URLs to quickly open them, search Google and Wikipedia. It's completely changed the way I compute. The only time I see the app tray anymore is when I accidentally make it spring up from the bottom with my mouse.

</comment></comment><comment><USER24> perhaps macports is better, but AAPL will f* you over with time, after the honeymoon. And this applies to OSX updates too, even if you fork over the money

<http://news.ycombinator.com/item?id=4433082>

back to linux. (it has ruby too.)

<comment><USER25> The App Store is where you send your not-so-sophisticated computer relative to. In theory, applications there, are less likely to hose your operating system.

In practice - lots of stuff that you have to get off of the App Store such as LittleSnitch, Arq, SuperDuper, QuickSilver, Carbon Copy Cloner - basically, anything that needs to plumb into the internals of the OS, or break outside the sandbox, will have to be purchased from a third party - and run the (greater) risk, of course, of doing damage to your OS.

</comment></comment><comment><USER26> I turned Spotlight indexing _off_ on my Lion install to stop regular bouts of unresponsiveness on my 2011 Mac mini (with hard drive, not SSD).

<comment><USER27> Is your hard drive almost full? I've found that when drive space is running very low, OSX deletes some of Spotlight's cache, probably to make sure there's space for hibernation and swap. When it gets back enough space, it rebuilds the cache again.

The problem is that if you are constantly orbiting a certain point of fullness, it goes crazy and keeps deleting and rebuilding all the time, causing slowdowns.

<comment><USER26> 47% of capacity with 248 gigs free.

</comment></comment></comment><comment><USER28> > Programs like launchctl (for instance) are not exactly fun to work with, but > they do get the job done.

One thing I like about launchd is that on OS X, there is one standard way to launch daemons. On Linux, there are a thousand ways to launch daemons. launchd also has a bunch of features, one of which is to start services on demand, upon connection to a socket, something Ubuntu hasn't had until the latest 12.04 ([http://manpages.ubuntu.com/manpages/natty/man8/upstart- socke...](http://manpages.ubuntu.com/manpages/natty/man8/upstart-socket- bridge.8.html)). I do agree, however, that OS X shouldn't be used for anything more than a desktop workstation.

<comment><USER4> > On Linux, there are a thousand ways to launch daemons.

Depends on your distro, really - Arch keep things fairly centralized and simple.

I never really got the hang of Ubuntu, though, by comparison.

<comment><USER29> I really liked BSD style rc.d and now Arch and other distros are moving to systemd but Ubuntu won't ship it in 12.10.

</comment></comment></comment><comment><USER30> What is so great about the OS X Desktop? (Honest question; As a long term Mac OS (X) user who switched to Linux about a year ago I am really wondering...)

Also, has a heavy computer user I mainly switched to Linux/FreeBSD because of the much improved customization possibilities. While the default OS X experience might be superior to GNOME/KDE, I now get a lot of things done a lot faster since I could make my machine exactly fit my needs. I really cannot imagine why any (not platform depending) programmer would ditch Linux for OS X just because the defaults work better.

</comment><comment><USER31> Sorry, how did this get so many points? Most of it is rubbish. All I hear is "Wah wah wah I like the control key, I don't understand the command key wah wah". And some of it is factually incorrect.

</comment><comment><USER32> OSX is good for developers with families. The wife and kids are happy and you're pretty happy too. Win-win all the way around.</comment>


A Deeper Look at the PlayStation 5 - <AUTHOR> https://www.wired.com/story/exclusive-playstation-5/ <comment><USER2> It's funny, as someone who grew up in the NES days (and played a little Atari and Apple ][), my reaction to every generation after the original PSX is "how could things possibly get better?". And of course, looking back now, I realize how silly I was (yes, I too bought into the hype of the PS3 "super-computer" [0]).

But the PS4/Xbone generation seems to have truly hit a high mark in fidelity, in which there is obviously room for more realistic and complex 3D visuals (especially with VR), but in which the returns seem much more diminishing than in past generations. I would be very happy with a PS5 (though not happy enough to buy it just for this) that rendered Witcher 3 with 60FPS and slightly higher quality, and near-instantaneous load times. I'm sure I'll be wowed once again by how developers take advantage of increased graphical capabilities. But the high mark that's already been reached is satisfying enough. It helps that there's been a renaissance of great indie gaming that hand-drawn (Cuphead) and retro (Shovel Knight, Undertale, Minecraft-likes) games in which graphical rendering does not require continued leaps in next-gen graphics hardware.

[0] [https://www.eurogamer.net/articles/digitalfoundry-2018-what-...](https://www.eurogamer.net/articles/digitalfoundry-2018-what- was-actually-real-in-the-e3-2005-ps3-reveal)

<comment><USER3> Looking at eg The last of us part 2, which is coming to ps4 and not being a ps5 exclusive, and various videos on Youtube (eg Unreal engine speed level designs, Quixel material libs), I think the huge moves forward these last years have been in the toolchain.

Now, even small studios (not meaning Naughty dog here) can make really high quality games, since they can buy/license the engine, textures and models, and focus on the game mechanics.

What the next generation brings is more firepower, which likely translates to more dynamic NPC and enemy behaviors. We'll also see the removal of artificial barriers meant to hide eg load times (as mentioned in the article), or workarounds.

Not in the game or console business, just my observations and speculations.

edit: speed level designs: [https://www.youtube.com/watch?v=TUM2Qc9TP9s](https://www.youtube.com/watch?v=TUM2Qc9TP9s) [https://www.youtube.com/watch?v=-HFnR43ms1k](https://www.youtube.com/watch?v=-HFnR43ms1k)

quixel, megascans: [https://www.youtube.com/watch?v=9fC20NWhx4s](https://www.youtube.com/watch?v=9fC20NWhx4s)

etc etc

</comment></comment><comment><USER4> "The controller (which history suggests will one day be called the DualShock 5, though Cerny just says "it doesn't have a name yet") does have some features Cerny's more interested in acknowledging. One is "adaptive triggers" that can offer varying levels of resistance to make shooting a bow and arrow feel like the real thing—the tension increasing as you pull the arrow back—or make a machine gun feel far different from a shotgun. It also boasts haptic feedback far more capable than the rumble motor console gamers are used to, with highly programmable voice-coil actuators located in the left and right grips of the controller."

I didn't think of having haptic feedback in the ps5 controllers. It's going to be interesting on how it will turn out.

</comment><comment><USER3> I think this little nugget was interesting, speaking of reducing load times:

> To minimize [rotating harddrive seek time], developers will often duplicate > certain game assets in order to form contiguous data blocks, which the drive > can read faster.

> "If you look at a game like Marvel's Spider-Man," Cerny says, "there are > some pieces of data duplicated 400 times on the hard drive."

400 times! That's a lot. I wonder to what extent or ratio the game is simply redundancy. Likely only smaller assets are duplicated.

edit: also,

> However, game installation (which is mandatory, given the speed difference > between the SSD and the optical drive)

I guess this means only a cursory disc check will be performed at game start, from then the rest will be from ssd. That'd be great.

<comment><USER5> > I guess this means only a cursory disc check will be performed at game > start, from then the rest will be from ssd. That'd be great.

That's already the case on the PS4 and Xbox One. The disc is only used to install the game to the hard drive and for copy protection I guess.

<comment><USER3> Aha, that is likely the case, but I still experience the disc (Spiderman, PS4) spinning for quite a long time after starting the game before spinning down.

Ie, not just a "is the correct disc inserted?"-check. Perhaps some kind of late release of file handle or something, or optimization from the ps4 itself.

</comment></comment></comment><comment><USER6> I'm glad somebody is sticking with a sensible naming scheme.

<comment><USER7> I'm sorry, I can't hear you over the sound of my Azure Edge GPU system for Legacy Games 3.11 for Workgroups (built on NT Technology.

<comment><USER8> The one with SuperDuperSpeed USB4 Gen 4x2 Type-C ports?

</comment></comment></comment><comment><USER8> > Like the PS5, Scarlett will boast a CPU based on AMD's Ryzen line and a GPU > based on its Navi family

> "There is ray-tracing acceleration in the GPU hardware," he says

It'd be great if AMD would release a PC version of that GPU soon. The market desperately needs the competition.</comment>


LA Uber drivers turn off app to create artificial surge pricing - <AUTHOR> https://nplusonemag.com/online-only/online-only/i-am-not-an-uber/?ftcamp=crm/email/_DATEYEARFULLNUM___DATEMONTHNUM___DATEDAYNUM__/nbe/FirstFTEurope/product

<comment><USER2> Inflammatory cherry-picked title. The actual title is "I Am Not an Uber: A night with LA's Uber drivers"

<comment><AUTHOR> Cherry-picked sure, but the generic title obscures why the article may be of interest. The other noteworthy part of the article is that Uber drivers are starting to organize.</comment></comment>