Ask HN: Any downsides of programming in Haskell? - <AUTHOR> To anyone who developed a real world application in Haskell, what are the downsides of it?
What is in your opinion more laborious than needed? Are library sufficiently available and documented? Is doing I/O fine? Is working with a DB easy? Please share with people interested in learning Haskell and put it to work in a real world application!
PS: asking for negatives only because I'm very interested and positive about Haskell, but I wonder if I miss some gotchas... <comment><USER3> Most of the issues mentioned so far are trivial or just warts. The real issue is understanding the design patterns that work well enough to build high performance applications. Also in order to really exploit the power and productivity of Haskell there is quite a learning curve.

We built an algorithmic trading system, and almost everything else in Haskell. Our code base is over 100K of human written code.

The major library gaps were a time library (you can find a version of what we have been thinking about releasing at [https://github.com/time-cube/time- cube](https://github.com/time-cube/time-cube)). We use our own build system that drives cabal and ghc. Otherwise having many libraries is just painful.

We found that composing applications as conduits to be a very effective design pattern that minimizes many laziness issues. Monad transformers are very powerful but the machinery for them (like forking) is not fully cooked.

Maintaining the codebase is far easier with haskell than with anything else I have worked with (C/C++,C#,Java,etc...). Refactoring in Haskell is great.

You can't fight the language. Fighting with Haskell will cause great pain. When you go with the flow, using lots of strong types, higher order functions and can apply things like a monoid instance to a problem the language is a joy to work with.

Debugging is more painful than it has to be. There are still times when you need some real GDB wizardry.

Lastly if you have more questions feel free to contact me through our website [http://www.alphaheavy.com](http://www.alphaheavy.com)

<comment><USER4> I strongly recommend folks take Steve up on his offer, they (alphaheavy) do really neat engineering and they're incredibly knowledgable.

</comment></comment><comment><USER5> Haskell's record system (analogue of C's structs) has two major deficiencies.

1\. Modifying a record value (that is, making a copy of a record value but with different values in one or two of its fields) is unnecessarily complicated and uncomposable. This makes modifying a subfield painful.

2\. Field names are in the global namespace. Thus you cannot have e.g. a field named `map` (conflicts with the standard `map` function); nor a local variable named `owner` in the same scope that you use a field named `owner`; nor may two different record types both have a `name` field. C had this problem in the 70s (which is why e.g. struct tm has tm_sec and tm_min fields instead of sec and min fields), but they solved it a long time ago.

The solution to deficiency 1 is to use lenses. Use the lens package from Hackage, but don't read its documentation at first: it generalises the problem exceedingly well, but this makes it harder to understand at first glance. Instead seek out a basic tutorial. At the cost of a short line of boilerplate for each record type, this works well.

There is no satisfactory solution to deficiency 2. Some people define each record type in its own module, and import each module qualified. I don't think this scales well. I prefer to put a record-type prefix on each of my field names (i.e. the same thing C programmers were forced to do in the 70s).

<comment><USER6> Both are true, but I consider the second problem to be more like a trade off. In PHP I miss field extraction from an array so often; in Haskell it is just `map fieldName` and voila. Works just as well with namespaces -- I understand it does not scale when creating data types, but you normally don't import all of them at the same time into another module anyways.

<comment><USER7> That doesn't require them to be in the global namespace.

</comment></comment></comment><comment><USER8> In my opinion the module system ([http://www.haskell.org/onlinereport/modules.html](http://www.haskell.org/onlinereport/modules.html)) is a bit weak. For example: "It is not possible, however, to hide instance declarations in the Prelude. For example, one cannot define a new instance for Show Char."

Instances can't be explicitly imported either.

Another thing I don't like is if you have two different functions with the same signature but different implementations meant to give swappable functionality, there's no way of specifying that explicitly. As a user of a library, you just have to realize the functions can be swapped out with modules. For example:

[http://hackage.haskell.org/packages/archive/bytestring/0.10....](http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/Data- ByteString-Char8.html)

[http://hackage.haskell.org/packages/archive/bytestring/0.10....](http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/Data- ByteString-Lazy-Char8.html)

It's really not that bad but I do like how other languages allow the programmer to make this explicit.

<comment><USER9> > Instances can't be explicitly imported either.

You can import only instances by saying "import A.B.C.Instances ()" where A.B.C.Instances is the name of the module where the instances are defined.

<comment><USER10> But not individual instances.

</comment></comment></comment><comment><USER11> For me, the biggest downside is lack of solid embedded device support -- arduino (Atmel AVR), android(ARM), iOS (ARM).

After using Haskell pretty much full-time for 10 years, writing C and Java code makes me sad. The support for the above mentioned platforms is in- progress, but is not yet mature.

There are some neat things like Atom which use a Haskell DSL to target arduino.

My other issue is that the garbage collector in GHC is not really sufficient for real-time audio applications because it can pause for too long. GHC HQ has tried to tackle this in the past -- but there is a reason why it is a research topic :)

If your application _requires_ interfacing to a C++ world -- your are not going to have fun. Though there might be a GSoC project for that this summer?

Also, GUI stuff is somewhat lackluster. There are bindings to gtk, etc. And they can get the job done. But they don't really capture the essence of what makes Haskell awesome. We are still searching for the GUI abstraction that really clicks.

<comment><USER12> _After using Haskell pretty much full-time for 10 years_

Wow! Doing what?

</comment></comment><comment><USER9> Depends on what you are doing. The library eco-system used to be a weak link in Haskell, but I see it improving. To clarify, there were (and still are) a lot of broken and/or poorly documented and/or unmaintained libraries on Hackage. Or several libraries for doing the same thing where there is no indication of which library is the best choice. I suspect that is, to some degree, the case in any open-source eco-system, thought. Recently, though, thanks to the effort of the giants like Edward Kmett there have been an influx of great well-documented libraries on Hackage. And of course, you are welcome to contribute new packages/improvements to existing packages.

Working with DBs is easy, especially if you use HaskellDB. There are bindings for non-relational DBs, as well as a DB written in Haskell (acid-state).

As for the language itself, you might find it tricky to develop computation intensive applications with large run-time data-sets due to garbage collection (but that is true for any garbage collected language). Other than that, it's one of the best performing languages in the Debian PL shootout. And the fact that concurrency is (comparatively) easy means you can make use of those extra cores.

Monad transformers and monads are fine, you just need to learn how to use them.

To sum up: it depends on what you do and what you consider a "real world application". Might be a good idea to elaborate. For example, are compilers, games, web apps, automated trading systems, android apps considered "real world"? Because any of these has been done in Haskell.

<comment><AUTHOR> I mentioned real world app to mean "not a toy project". That is, i meant a reasonably large, structured, maintainable code base. I am thinking of haskell as the language to use for a new project, and am interested to know more about the potential problems and downsides i should be aware of. Also are there situations where one should absolutely avoid haskell?

<comment><USER9> Yes, I think you should avoid Haskell (and any language with managed memory) on embedded systems or in very performance critical applications. Beyond that, it's going to be a choice of whether there are enough well-supported libraries that help your cause versus some other language. It would help to know in what domain is your new project is going to be.

You've mentioned web apps, so, to be specific, I think the Haskell web app frameworks (Happstack, Yesod and Snap) are mature. There aren't nearly as many utility libraries, as there are, say, for Rails. But that, in my opinion, is compensated by greater correctness guarantees and performance.

I'd encourage you to join the haskell-cafe [1] mailing list: it's a great place to get help if you get stuck.

[1] [http://www.haskell.org/mailman/listinfo/haskell- cafe](http://www.haskell.org/mailman/listinfo/haskell-cafe)

<comment><USER13> > Yes, I think you should avoid Haskell (and any language with managed memory) > on embedded systems or in very performance critical applications.

You're forgetting about atom, [http://hackage.haskell.org/package/atom](http://hackage.haskell.org/package/atom).

</comment></comment></comment></comment><comment><USER14> The runtime is somewhat immature. It locks up oddly sometimes under heavy load. Dealing with latency and queuing issues around gc pauses is _much_ less understood/documented than in the JVM world. The set of best practices in general for doing intense things with the ghc runtime is just still young and sparse.

STM can exhibit something that looks a hell of a lot like livelock.

Error handling is brutal. Catching all classes of exceptions (at the place you want to catch them!) for recovery is surprisingly tricky. This isn't necessary in theory with things like MaybeT, but in practice, lots of odd libraries use things like partial functions and the error function.

Not having tracebacks in production code is painful

The library community is thriving but it has a lot of volatility. Things break each other quite frequently. Semantic versioning either isn't enough to save it or hasn't been adhered to strictly enough.

Thunk leaks and other consequences of unexpected laziness aren't as common as people worry about, but they're kind of a pain to track down when they occur

Strict vs. Lazy bytestrings, String, Text, utf8-string, etc. You may find yourself doing a lot of string/bytestring type conversion

There's still wars raging about the right way to do efficient, safe I/O streams. Conduit vs. Enumerator vs. Pipes etc. They're all turning into pretty compelling projects, but the fact that there are N instead of 1 is sometimes a drag when you're dealing with libraries and dependencies.

There are not a lot of good open source "application server" type frameworks that really handle thread pooling, resource exhaustion, locking, logging, etc, in robust nice ways. We have one internally, and I'm sure a bunch of other haskell-using shops do too, but the ones on hackage are not nearly sophisticated enough (IMO) and I suspect not very battle tested against the kinds of ugly queuing problems you run into in highly loaded environments.

If I think of more, I'll add em... these are off the top of my head.

<comment><USER10> > lots of odd libraries use things like partial functions and the error > function.

This is very naughty and I _hate_ it.

</comment></comment><comment><USER15> Runtime debugging in Haskell is more rare, but when you need it, it's more of a headache.

Achieving performance is harder than in c or c++.

The ecosystem is strong on some counts and weak in others.

There's lots of API duplication (lazy/strict byte strings, map, set, seq, etc).

Good performance may depend on brittle ghc optimizations that might break in very difficult to comprehend ways if ghc is upgraded.

</comment><comment><USER16> We wrote our RF radio mesh coordinator software in Haskell, and it's been a great success. Working with binary data formats (various building control protocols) in Haskell is the kind of thing that spoils you forever.

The one issue I've run into is that ghc can't cross compile. If you want to run your code on ARM, you have to compile an ARM version of ghc (QEMU comes in handy here).

<comment><USER4> much better cross compilation support will be landing in ghc 7.8

</comment></comment><comment><USER17> Let's begin by stating that Haskell is great, but there are a lot of stuff I don't like about it:

1\. Way to many user defined operators. Haskell lets you define almost anything as an infix operator which library authors love to (ab)use. So you get operators like ".&&&." (without the quotes) because they are functions reminiscent of the boolean and operation.

2\. But weirdly enough, many operators aren't generic. String concatenation is performed with "++" but addition with "+".

3\. Incomplete and inconsistent prelude. It has unwords and words for splitting and joining a string on whitespace. But you dont get to specify what string to use as the delimiter like the join and split functions in other languages lets you do.

4\. So instead you have X number of implementations of splitStringWith on Hackage, some of which are unmaintained, deprecated or just not working, meaning that just answering the question "how should I split a string?" becomes a big endeavour ([http://stackoverflow.com/questions/4978578/how-to- split-a-st...](http://stackoverflow.com/questions/4978578/how-to-split-a- string-in-haskell)).

5\. There are four different "stringish" types in Haskell: List, LazyList, ByteString, LazyByteString. A function like splitStringWith works on one of the types, but not the three others for which you need other functions. Some libraries expect Lists, other ByteStrings or LazyByteStrings so you have to keep converting your string to the different types.

6\. Most Haskellers seem to content with just having type declarations as the api documentation. That's not a fault of Haskell per se, but imho a weakness in the Haskell community. For example, here is the documentation for the Data.Foldable module: [http://hackage.haskell.org/p](http://hackage.haskell.org/p) ackages/archive/base/latest/doc/html/Data-Foldable.html

7\. This is very subjective and anecdotal but I've found the Haskell people to be less helpful to newbies than other programming groups.

<comment><USER18> 1\. What library are you complaining about? Haskell has a pretty small, well established set of operators. If a library is defining more operators than you like, then don't use it. That is no different than a library defining functions with names you don't like, it happens in every language.

2\. Why on earth would string concatenation be the same operator as addition? That isn't the same operation. I want to know if I used + that I have to have gotten a number, or else it won't compile. Getting a string would be very unhelpful. If you just want any monoid, then there is a generic operator for that, it is <> or mappend.

5\. The different types are for different purposes. String is a list of chars. You use normal list functions on it. Bytestring is not a string, it is an efficient container for storing bytes. It is used for things like networking. Text is an encoding aware, efficient representation of strings. Use this for text data. There is an IsString typeclass for generic functions that operate on any type that can behave like a string.

7\. I've always heard the exact opposite from everyone, and my experience has also been the opposite of yours. The only other computer related community I have seen that is as helpful as haskell is postgresql.

<comment><USER17> 1\. HXT, Lens, Arrows.. etc. _I think_ (as in, this is my opinion, someone else may think that the amount of operators they contain are reasonable) they introduce way to many infix operators. They are also pretty important to the Haskell eco-system, so you can't just choose alternatives with less "line- noise."

2\. I think the question should be why on earth should they not use the same operator symbol? In most other mainstream languages they are. I know the answer is "because [Char] isn't part of the Number typeclass" but that misses the point.

5\. Both Text.Regex and the split library someone else mentioned operators on strings ([Char]). Data.Aeson uses ByteStrings. So not everything in Haskell- land uses Text when they should which leads to lots of annoying string packing and unpacking. Contrast this with Python (3) where you have (unicode) strings and (byte) buffers. Only. If you want more efficiency there are 3rd party lazy implementations of them, but they aren't forced upon you like in Haskell.

<comment><USER19> 1\. I don't think they define too many specialized operators personally; Haskell's heritage is more "mathematical" than many other languages so it makes sense that many variables are single letters and operators are defined with symbols instead of _reallyLongAndDescriptiveName_. It's part of learning the idioms of the language.

2\. They should _never_ use the same symbol. As the parent said, if you want the generalized notion of a monoid then use that (<> or mappend), otherwise each library should not be conflating its instance of a TypeClass with other libraries' instances of a TypeClass - it is confusing and you end up with stuff like:

        import Some.Lib as L
        import Some.Other.Lib as OL

        (L.+) 2 3
        (OL.+) "2" "3"

vs.

        import Data.Monoid

        (Sum 2) <> (Sum 3)
        "2" <> "3"

Which is inevitable for some libraries (Fay for example re-defines a lot of Prelude functions) and sometimes accidental; but it is confusing and bad design unless you define a way to generalize it (Monoids!).

5\. Data.Aeson uses ByteStrings for the JSON serialization, when encoding/decoding you provide your own instance defining the Types (can be Text/String/ByteString) so I don't understand your gripe here; Text.Regex shouldn't be used for Data.Text, that's what this package is for: [http://hackage.haskell.org/packages/archive/text- icu/0.6.3.5...](http://hackage.haskell.org/packages/archive/text- icu/0.6.3.5/doc/html/Data-Text-ICU-Regex.html)

<comment><USER17> When you want to encode and decode JSON data of unknown format then you need to use the encode and decode functions directly which operates on ByteStrings. You really don't want to create a new record for each possible kind of JSON data container you have.

text-icu is an experimental 3rd party binding and doesn't work like pcre anyway. It's not something you would use over Haskell's standard library regexp support, so you still have to deal with X number of different string types.

<comment><USER19> True re: encoding or decoding; but it does make sense to me to keep it in ByteStrings as that is an efficient representation - from ByteStrings you can do what you want with it (convert it to Text).

I personally haven't used the Text.ICU package but I know many, big, packages that retain the "experimental" flag. So that shouldn't necessarily deter usage; just because it's 3rd party doesn't mean it's bad either - <USER2> fundamental components of the Haskell ecosystem are 3rd party! There are also many libraries that implement bindings - I don't necessarily see why that is a bad thing either; obviously a pure Haskell approach would be nice but in some cases it does defeat the purpose to reinvent something.

What I do agree with you on, though, is the lack of clarity in _what_ should be used. I think the Haskell Platform is a good start in that direction but there are few docs written on "this is how you deal with strings and unicode in Haskell and all the libraries we recommend for it".

The good news is, this language has the capability to serve both the research needs of academics and the practical needs of implementers; so uncovering this stuff is very good.

</comment></comment></comment></comment></comment></comment><comment><USER20> This discussion has also been linked from Reddit:

[http://www.reddit.com/r/haskell/comments/1gknfs/ask_hn_any_d...](http://www.reddit.com/r/haskell/comments/1gknfs/ask_hn_any_downsides_of_programming_in_haskell/)

</comment><comment><USER21> I found it a lot slower than more imperitive style languages. I've been writing in c-like languages for something like 30 years, so I suppose that's not unexpected. I found that the type system sometimes got in my way. And combining monads (even with monad transformers) was also a faff. In the end I suppose it depends what you're trying to make. I think Haskell is great for DSL applications and less so for things like web dev. Though that being said Yesod is a pretty nice framework.

<comment><USER22> The thing is, if you feel like the type system is "getting in your way" you have to step back and ask, "do I really understand what I'm achieving here?" Of course, it's very easy to feel like you know what you want and you can't figure out the types for it, but you have to realize, if the type check fails then what you asked for just doesn't make sense, like adding an Int to an (IO Int).

The whole point of the type system is that it substitutes compile-time errors (that are admittedly esoteric) for obscure run-time bugs that might not even ever show up except on that one person's machine and use-case.

But yeah, it's never fun to see a screenful of type errors.

</comment></comment><comment><USER4> Honestly I think the biggest down side is that there's not enough commercial endeavors using Haskell, and thus theres horrifyingly few people working full time on many core pieces of the ecosystem. Yes, my biggest critique is that all the great stuff in the Haskell ecosystem is the result of a small collection of smart folks helping out in their spare time.

It makes me wondering what magic would happen when those folks can work on helping the ecosystem full time!

I have to say that one of my favorite things currently about haskell is how nice and easy the c ffi is to use. So darn simple! (I'm also GSOC mentoring some work to provide a nice C++ ffi tool too).

Theres so many great tools in the Haskell ecosystem, for every problem domain. Its not perfect, and theres always room for more improvement, but those improvements are happening, and the more people invest in supporting the community, the more those improvements happen!

For example, one thing i'll be exploring in the neat future is how to do good Numa locality aware scheduling of parallel computation. It looks like i might be able to safely hack support in via a user land scheduler (though i'll find out once i get there).

My principal work right now is building numerical computing / data analysis tools, and some of the things I'm doing now would be simply intractable in another language.

</comment><comment><USER23> Cabal and friends are awful compared to Bundler/Maven/etc.,even with the various wrappers available. Also, the tooling isn't that great compared to Scala or F#.

</comment><comment><USER24> Monad transformer hell.

<comment><AUTHOR> Can you share a bit more? I'm not familiar with Monad transformers.

<comment><USER8> Monad transformers are just monads wrapping other monads. I actually like it and think it's a really clean way to organize your state, IO, etc. For example, you could have a Reader wrapping a Writer wrapping a State wrapping IO. The reader is your configs, the writer is for error logging, the state is for some application map, and the IO is for doing networking or something. That's an extreme case but it's nice to lay it out in that way.

<comment><USER23> lurker14, you're shadow banned. He/she said:

That's a special case, because RWS already exists (Reader, Writer, and State all commute), and wraps IO easily.

Light overview of the issue: [http://ro- che.info/articles/2012-01-02-composing-monads.html](http://ro- che.info/articles/2012-01-02-composing-monads.html)

It's the other cases that get head-desk-banging. This paper is great, but shows what a high mental tax you pay to get highly-principled programs:

[http://www.grabmueller.de/martin/www/pub/Transformers.en.htm...](http://www.grabmueller.de/martin/www/pub/Transformers.en.htm..).

At the end of the day, most people on most projects seem to prefer sacrificing some formal specification (and some actual correctness) for getting code running for the common case.

Related reddit conversation:

[http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s...](http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s..).

</comment></comment></comment></comment><comment><USER18> Records are annoying, but can be worked around. The compiler is incredibly slow and uses tons of RAM (I need 2GB to compile my simple little web app for example). The slow compile times can start to really kill productivity on large projects. The web frameworks are all pretty focused on trying to reproduce industry worst practices rather than doing things right, so if you are doing web development and you don't want your app to be a mess, you are kinda on your own. That's pretty much it.

edit: to clarify on the web thing, when I say "on your own" I mean you won't be able to get much from existing tutorials and examples since you will want to do everything differently. Not that you will have to write your own framework.

<comment><USER25> I'm interested in hearing your thoughts on web development. Would love to chat on IRC...or maybe drop me an email if you're inclined.

<comment><USER7> I'd be interested in hearing, too, so please make it public if you're comfortable with that (and link it here, if the conversation isn't held here).</comment></comment></comment>


Developer reactions to the Mac App Store - <AUTHOR> http://www.tuaw.com/2010/10/21/developer-reactions-to-the-mac-app-store/#continued

<comment><USER2> Generally I like the idea.

I wonder, though, whether the Mac App Store will eventually become the _only_ way to install apps on a Mac. (I.e. you'd have to jail break your Mac to install alternative apps).

This seems far fetched now, but as PC and mobile device continue to become more and more alike.

If history is any measure here, that is probably what Apple wants in order to assure a unified user experience.

<comment><USER3> There will always have to be some SDK version of the OS you can run that will allow you to freely develop and QA apps. Part of developing, of course, is pulling random code from the Internet and compiling a single, local copy of it for yourself.

Even if OSX copies iOS and stops accepting unsigned apps, developers will still be able to simply share the source code for any app they really want distributed, such that any other developer can then just pull the code down, build it, locally sign/provision it, and run their locally-signed binary. That might actually make the OSX third-party software ecosystem _healthier_ , all- said.

</comment></comment><comment><USER4> Seems like the reaction is overwhelmingly positive on the developer side. There are some concerns, but overall, developers understand how much more exposure a Mac App Store would give their software.

<comment><USER5> To me many of the responses sound politically correct. You shouldn't bite hand that (may) feed you.

</comment></comment><comment><USER6> <http://bit.ly/g7yY3>

"I think this is wonderful news for users as it makes the lengthy download- install-buy-license process as simple as a single click."

Maybe not a click, but the Ubuntu Software Center is basically that.</comment>


How the Frightful Five Put Startups in a Lose-Lose Situation - <AUTHOR> https://www.nytimes.com/2017/10/18/technology/frightful-five-start-ups.html <comment><USER2> I think this article completely bypasses the root causes of the issue in order to paint Silicon Valley dominating businesses in the worst light possible.

Look, the real issue is simple: all of these "web startups" are not very innovative. All of them are roughly the same: ever so slightly more novel way to deliver roughly the same set of data to users in exchange for app or token of money. How is _that_ "ground breaking"?

Thing is, when everyone is doing roughly the same thing, which costs perhaps a few engineering months to build, how can startups ever compete with the big guys who are hell bent on ensuring their success? It's like trying to open supermarkets to compete with Walmart, or building gasoline car to compete with Toyota, except it's cheaper for the Big Five to copy than for Toyota, because the media (information) is inherently more traceable.

I remember when Windows 98, XP, Google, Gmail, Prime (and Uber, eBay, and paypal) came out. They blew everyone's mind. They changed how we work and live. What's so hot about SnapChat? I mean, it's probably ever so slightly more entertaining than, says, Hangout or WhatsApp, but it's just minor tricks on top of roughly the same set of features. Of course these competitors will drive it out of the marketplace. It holds no long term competitive advantages.

There are businesses that don't deserve to die. For example, a local store provides not just goods, but a community center and an identity for a small town; it gives more value than mere commerce. The decline of these should alarm us. On the other hand, some businesses do deserve to die. And lack of long term advantage, lack of innovation, lack of additional value sounds exactly "should die".

<comment><USER3> You're looking at the features rather than the true value of these apps, the users. Snapchat has the biggest reach into the most impressionable market, teenagers. That's why it is valuable.

<comment><USER4> Snapchat is valuable from a monetary perspective, but actual real value is little to none. No one is going in 10 years will say Snapchat changed our lives or progressed society's knowledge. People will look back wondering why it made a handful people beyond wealthy.

<comment><USER5> Yeah, but to be honest, that's true of the vast majority of companies, tech or non.

<comment><USER6> You're not wrong, but the 'frightful 5' were all transformative for society. The point is that the big companies quash non-transformative small companies.

</comment></comment></comment></comment></comment><comment><USER7> People seem to think that Microsoft is a company that at some point sucked at innovation. In fact, the reason Microsoft let a generation of startups blossom was mostly because they got hit by antitrust.

Google, FB and Amazon are probably ripe for antitrust, too, but the government won't move.

<comment><USER8> It's hard to go after the FAANG companies for anti-trust when they all compete with each other in so many ways -- facebook and google have multiple competing services, apple, google and amazon all build consumer hardware, and facebook is dipping it's toes in, they all have music services.. Netflix has tons of competitors outside of the big five, but amazon and google both have streaming movie services. Amazon and Google both have cloud services.

Really the only two that have a genuine monopoly are Google in search and Facebook in social networks, and I think perhaps Amazon in online retail.

<comment><USER9> The big thing is that the US government needs to recognize how vertical integration harms consumers. While Apple and Google and Amazon may all compete with each other in multiple venues, very little of that is cross-compatible. People with one product or service from a company often has little option but to use the rest of that company's products and services. The ecosystem effect means that even if there is a handful of "competitors", those services on an individual level often aren't available to consumers. If you have your stuff purchased in iTunes, you have massive monetary cost preventing you from switching to Android, for example.

One of the stories I hadn't heard of until recently when discussing the AIM closure, is that the FTC ordered AOL once to make AIM cross-compatible with their two largest competitors or face antitrust action. Had someone like Google been subjected to the same, we'd have had Gmail, YouTube, etc. on Windows Phone, and it wouldn't have died from the lack of Google apps support.

I'd be more than in favor of ordering vertically integrated companies to support at least two competitors' platforms in every way they support their own.

<comment><USER10> That's quite the can of worms, but what an interesting topic.

I see your point and agree that vertical integration is harmful. I would like to offer the automotive industry as an interesting comparison of an industry with similar compatability issues.

All of the major components produced by the big manufacturers tend to be incompatible (without heavy engineering effort). When parts on a car are compatible between many makes and models it tends to be a third party parts manufacturer that has made it but a concerted effort from the big manufacturer that allowed that to happen. Think brake pads, tires, air filters, spark plugs. In most cases engines, their computers, interiors, transmissions and so on, are all make specific and also usually model specific.

No one is compelling BMW to make sure their engine fits into a Jeep. When I buy a BMW I am locked into their infrastructure and without their parts and support I could find myself without a working vehicle.

While you can often mix and match manufacturers parts so long as you can wield a few tools and have time and knowhow, it's pretty rare that someone wants to. Similar to emulators or jailbroken phones, IFTTT, APIs and integrations, it's easy to see there is a desire for this kind of flexibility but again it's often only a particular type of individual with a particular desire that makes it happen.

I feel that this desire for interoperability is niche. My mother on her Windows phone has been perfectly happy. I have never met anyone who wasn't in tech that has complained about interop. So while I agree it would probably be a good step to introduce more flexibility there, I don't think it's critical to protecting consumers against monopolistic behavior. If you buy an iPhone you are locked into Apple for that device, but you can still buy an Android. Just like I am locked into BMW while I own their car, but could still move to an Audi.

<comment><USER11> It's not just parts though. The car analogy is more like, I can't drive my car to your house because your house was built by BMW and my car is an Audi. It's like we all live in corporate-controlled subdivisions with proprietary, incompatible rail lines instead of roads.

</comment></comment></comment></comment></comment><comment><USER12> _> The best start-ups keep being scooped up by the big guys (see Instagram and WhatsApp, owned by Facebook)_

Well, I don't know. "Scooped up" sounds very hostile, in reality these startups were sold for a fortune. Also, the fact that you're able to buy an innovative startup does not necessarily mean that you'll integrate or run it successfully. Take for example google's Nest or Motorola acquisition. Acquiring and sustaining is quite difficult.

<comment><USER13> They can measure the performance on social media + google queries.

Then they can "scoop" it up before it's valued higher than themselves.

<comment><USER14> Why would they need social media or whatever? The startups themselves advertise their own success. It wasn't a secret that Whatsapp was growing tremendously.

</comment></comment></comment><comment><USER15> There seems to be a concerted effort to paint the silicon valley elite companies as "dangerous"? I'm not sure it's unwarranted, but it seems relatively recent to me, as if to drum up political support for regulation. What's interesting to me is the big technology/infrastructure/media corporations that are escaping this broad brush, including AT&T and Comcast.

<comment><USER16> It's a political attack against Mark Zuckerberg's upcoming presidential run. The propaganda machines are starting now by painting a picture of Silicon Valley elite being out of touch, dangerous, etc. etc.

<comment><USER17> I'm perfectly happy if FB's shady doings keep Zuckerberg out of the presidency. Last thing we need is a president with a propaganda mill

<comment><USER18> One might look at the founding of Fox News and its relationship to the GOP and be forgiven for thinking the last thing has already happened, even though it only reaches diehard GOP voters.

<comment><USER17> This would be more like...if Trump ran Breitbart for a decade, and Breitbart had a following consisting of most of the US population and could easily be used to sway huge portions of the electorate because you spent the last decade figuring out how to manipulate your viewers.

Probably a better example is if the GOP owned a private intelligence firm that had data on every citizen and could manipulate what they saw/read/said

</comment></comment></comment></comment></comment><comment><USER19> > The Five run server clouds, app stores, ad networks and venture firms, > altars to which the smaller guys must pay a sizable tax just for existing.

Hmm... thats not actually whats going on. Its not like start ups wouldn't have to pay hosting costs if the big 5 didn't exist. If anything these ability to host at Google/MSFT/Amazon lowers the barrier to entry for startups.

<comment><USER9> Perhaps, but bear in mind, instead of a multitude of potential hosts, that hosting tax _must_ go to the Big Five. Which means the Big Five will _always_ have a financial advantage entering any market.

<comment><USER20> Is that true, though? You can certainly host on Rackspace, avoid AWS entirely, and so on. Amazon will have cheaper hosting than you no matter how you get it, but that's merely a function of scale, not monopoly.

Google traffic/ads and the iOs app store are the only two spots that seem truly captive.

<comment><USER21> AWS is quite expensive. It's not the case that it's cheap. Rather, you pay more for convenience.

The idea that startups "must" pay AWS or equivalent is the kind of idiotic junk that only rags like the NYT could come out with. Nothing stops you buying your own hardware and racking it. For many companies that's in fact a better option than paying for cloud services!

<comment><USER22> > Nothing stops you buying your own hardware and racking it.

If you're a bootstrapped startup, sure.

I think you'll find it a rather hard sell to tell your VC-backed board that you are hosting somewhere other than AWS or GCE these days.

It's an _extremely_ concerning trend for anyone paying attention. Mandated-by- investor vendor lock-in before you even deploy a line of code.

<comment><USER20> I don't expect anyone will actually be racking their own hardware, but "AWS or CGE only" still sounds pretty narrow to me. Are VCs really going to object to Oracle's bare metal setup, or RackSpace with OpenStack?

</comment></comment></comment></comment></comment></comment><comment><USER23> Another poor quality article with little research. It started with big tech companies are bad and followed that with some reasons. Lot of start-up don't succeed because they are not innovative and lack vision. The ones that did add value are doing well likes of uber, Netflix, airbnb, slack. In fact, if the author expands his world view a bit more and looks across the globe than he will find many more such examples. Even within the big five there is significant amount of competition and currently it is good for customers. This article is just crying wolf without offering any substantial reasons. Big companies buying of smaller competitors isn't some cunning move neither it is something new. This happened all the time even earlier. In fact the rise of cloud services has reduced the entry barrier for tech companies significantly by reducing upfront capital costs. Imagine if before starting a factory you first had to build a coal powered electric plant, not many would venture i guess. The argument about snapchat paying google for cloud services is just absurd. It would be costlier for snap to build this on their own.

</comment><comment><USER24> _Note that Snap booked only $330 million in ad revenue for the first half of this year. In other words, it 's paying more than half of its revenue to Google._

I wonder if it's possible that small companies are better at creating _user_ value, but big companies monopolize the mechanism of delivering _customer_ value, which is advertising.

</comment><comment><USER25> > In January, Snap signed a cloud hosting deal with Google. It agreed to pay > Google $400 million a year for the next five years. Note that Snap booked > only about $330 million in ad revenue in the first half of this year. In > other words, it's paying more than half of its revenue to Google.

This figure is hard to put in context without knowing how much of Google's own revenue goes to operating it's data centers. Sure, they're not paying that money to another single giant company, but they're still paying it.

<comment><USER26> It's being called out to highlight a diversification issue not a profitability issue.

</comment></comment><comment><USER27> > Fewer than 1 percent of start-ups end up as $1 billion companies.

Is that the goal for society, to have more $1 companies (vs. having that value rolled into a larger, pre-existing organization)? Is there an assumption that more $1 billion companies will somehow mitigate the power of the Big Five? Are the Big Five stifling innovation?

Feels like it's only a problem if the big boys enter into non-complete agreements (like the hiring issue a few years ago).

To put it another way: do we need/want to spread the value from the "Frightful Five" to something like 7, 8, or more companies? Is a "Terrible Ten" better/worse than five?

<comment><USER28> Yes, your "Terrible Ten" is better than five.

Google quickly came up with this: [https://academic.oup.com/antitrust/article/1/1/162/274807/Is...](https://academic.oup.com/antitrust/article/1/1/162/274807/Is- competition-always-good)

But there's so much more that says more competition is good for an economy.

<comment><USER27> There's a fine line there, though, right? We want competition, but we also want integration. I'm not happy that there isn't deeper integration with Apple hardware and Google software. having Google search + Google assistant + Apple Phone + Somebody else chat isn't what I'm looking for as a user.

</comment></comment></comment><comment><USER29> >> Fewer than 1 percent of start-ups end up as $1 billion companies

1 percent sounds ridiculously high. I would think more along the lines of "1 in a million".

<comment><USER30> Are there really millions of startups

<comment><USER31> What are we calling a start-up? You're going to have to set at least a modestly limited definition.

 _Any_ relatively new business? Sure, there are tens of millions of those started every year globally.

Six million small businesses are formed each year in the US (any new business with less than 500 employees), most of those are small, usually single person, self-employment entities. That's clearly too broad however.

Closer to the definition of a corporation being formed with the intent to hire other employees, it's more like half a million per year in the US. [1] It's probably safe to say it's at least five or ten times that globally.

[1] [http://money.cnn.com/2016/09/08/news/economy/us-startups- nea...](http://money.cnn.com/2016/09/08/news/economy/us-startups-near-40-year- low/index.html)

<comment><USER32> That still includes a huge number of local plumber/accountant/lawyer/landscaper/restuarant companies that hire a few employees.

In principle they could grow into a Home Depot / McDonalds, but it is still strange to call them startups

</comment></comment></comment></comment><comment><USER33> > fewer than 1 percent of start-ups end up as $1 billion companies

Not every company needs to achieve a billion dollar evaluation. This eat-the- world mentality is incredibly toxic. An an entrepreneur one should be satisfied with making tens of millions in revenue, but of course you can't stop there when VCs are involved.

</comment><comment><USER34> Dropbox isn't even mentioned in the article. Dropbox is fighting against at least four of the five giants : iCloud Drive, One Drive, Google Drive and Amazon Drive. Guess who should buy Dropbox (or Facebook Drive?)

<comment><USER32> Dropbox is in a special niche because their core feature is cross-plaform compatibility. No single platform can compete with them.

<comment><USER35> I frequently see people saying that they'd love it if Microsoft dropped a One Drive Linux client. My guess is that those companies could compete with Dropbox, with little real additional effort.

</comment></comment></comment><comment><USER36> Question: is a 1% chance at becoming a unicorn higher or lower than before? I mean, the vast majority of startups fail. 1% actually seems high to me

<comment><USER37> The article actually says "fewer than 1%", but they don't include the "fewer" as part of the link text, which seems like a poor choice.

The linked article reports the actual value in their cohort to be 0.91%[0], which is surprisingly close to 1%.

For what it's worth, this cohort is of companies that received their initial seed in 2008–2010. Obviously it takes a while for a company to hit $!Bn valuation, but the landscape has changed a fair bit in 7-9 years, so the current number may be a lot lower (or a lot higher).

[0] [https://www.cbinsights.com/research/venture-capital- funnel-2...](https://www.cbinsights.com/research/venture-capital-funnel-2/)

</comment></comment><comment><USER38> > Snap, the company that makes the disappearing messaging app Snapchat. > Although it is one of the most innovative consumer-focused internet > companies

Isn't this part of the problem? Snap, albeit innovative and fast as they are in creating new paradigms should in no way be the most innovative consumer- facing company. There's an imbalance here somewhere. Maybe when it makes sense for everyone to create their own infrastructure, the hold of the five will loosen up. That might require another wave of infrastructure improvements that the huge companies will not be able to compete with the collective many.

<comment><USER39> Err, mind explaining why shouldn't they? I say this as an 'olds' who still uses Facebook (though I've tried Snapchat, but only after they IPO'd).

<comment><USER38> I meant: there must/should be more innovative companies that are targeting more fundamental problems. Of course every company should be as innovative as maximising profit allows.

To reiterate I meant there ought to be lots more companies with bigger dreams than that of Snap, no matter how innovative Snap is. That Snap _IS_ considered one of the most innovative companies is indicative of the problem.

<comment><USER31> Snap is only considered one of the more innovative companies in consumer facing social. That's it. There's no sense in expanding that to include everything in tech, they are not one of the top few most innovative consumer companies in all of technology.

That Snap gets pegged as that, is a fake set-up to write articles that stick to a script that the writer wants to push. It's equivalent to asking someone's opinion when you've already entirely made up your mind, except in this case it has a particularly negative effect as it's being pushed out into the world as a form of media propaganda.

Here's how it works (to use a famous example of this setup): we expected flying cars and all we got was 140 characters. That's a bullshit setup, it fails to even question whether flying cars make sense, and then sets up Twitter as an ideal example of today's level of innovation (which it never was). While Thiel was pushing that bogus premise, incredible innovation (both hardware and software) had occurred in mobile all around the world in a mere ten years from 2007 to 2017. Drastically improved communication, as one example, is far more important than flying cars.

Innovation is so terrible today! Then hold up mediocre examples of innovation while ignoring the vast, extraordinary innovation going on (from quantum, to crispr, to AI).

</comment></comment></comment></comment><comment><USER40> > _The best start-ups keep being scooped up by the big guys (see Instagram and > WhatsApp, owned by Facebook)._

I was under the impression that that was the point. From the investors' perspective, you're playing volunteer R&D/HR for Amazon or Google or Facebook in hopes that they'll take notice and buy your devs and users off you. That's what an "exit strategy" is, and we all know that every startup needs one. The bit about changing the world and revolutionizing the way we communicate is a sop to keep the engineers happy and productive.

</comment><comment><USER41> I completely agree with this premise. Nowhere is it more obvious than in OSS companies. There is no open source business model that cannot be disrupted by the cloud bigs which also include Microsoft.

<comment><USER33> This is why I do not publish any open source projects except with GPLv3 license. I refuse to let Amazon profit off my hard work.

</comment></comment><comment><USER42> I don't think there's any "there" there, w/r/t this article. All it's really saying is "some companies build infrastructure and they profit when other companies use their services". Well duh. In this regard Google or Amazon are no different from the local electric utility. Well, with the exception of that fact that there are many cloud hosting providers to choose from and there is actually some competitive pressure there, where electric providers almost always have a true monopoly.

So Snap is paying Google $400MM USD / year or whatever... OK, now ask "how much would it cost Snap to build their own datacenter(s), host and manage their own services, provide electricity, cooling, etc..." It might or might not add up to the same as they're paying Google, but it would definitely be a significant chunk of money. It's not like Google is taking their money and not providing some value in return!

The flipside of this is that services like AWS, Google Cloud etc. make it FAR, FAR easier and cheaper to spin up a new (software) business. For some of the stuff we're doing at Fogbeam, we would never even be able to start if we had to build a datacenter, buy servers, etc., etc. But we can deploy on AWS for a minimal spend during development, and then scale our use of AWS as we start to generate revenue. If/when the day comes that the economics make sense, we could look at moving to a colo center or even build a dedicated data center.

Personally, I don't begrudge Google, Amazon, etc. the money they're making. _shrug_

<comment><USER21> I agree that the article is kind of useless, but I think you're maybe over- estimating the difficulty of racking your own machines. You don't have to build your own physical building to run your own hardware, and unless you're using tens of thousands of machines they don't die _that_ often. The savings from bringing it in house can be substantial.

On the other hand, if you need some of the more exotic cloud services that don't exist or exist very badly in the self hosted space i.e. you are really paying for access to their software stacks, then sure.

<comment><USER42> _The savings from bringing it in house can be substantial._

Oh yeah, absolutely. I don't dispute that. But I don't see any reason to think that anybody put a gun to the head of any Snap executives and made them sign the deal with Google. Apparently they thought they were getting their money's worth, or else why sign up?

Anyway, all I'm trying to get at is that it isn't like Google are somehow victimizing some poor, defenseless, startup. These guys made a deal that they thought made sense, and they know their business better than any of us.

</comment></comment></comment><comment><USER43> The reality of monopoly and collusion is here and it's real!

When I started my first company it was easy to access customers(30k+) via all types of cheap online marketing. But around 2012, a massive shift started happening towards "content aggregators" and a closed web. Which made marketing a lot more expensive and less effective.

The big guys have closed the web and are now taxing business for access to people's attention.

</comment><comment><USER44> This is very US-centric - there are some behemoths outside the US e.g. Tencent.

<comment><USER45> China has the same problem the US has. BAT (Baidu, Alibaba, Tencent) control most of the Internet in China. So China only enforces the claims that NYT makes, at least for the China market.

<comment><USER46> _BAT (Baidu, Alibaba, Tencent) control_

"Are responsible for its day to day running" perhaps but there is only one entity "in control".

<comment><USER32> The line between the Communist Party and the owners of BAT is... blurry.

</comment></comment></comment></comment><comment><USER47> If this is correct, the return on venture capital should be dropping. Is it?

<comment><USER48> Fred Wilson's post is informative [http://avc.com/2013/02/venture-capital- returns/](http://avc.com/2013/02/venture-capital-returns/)

</comment></comment><comment><USER29> The government should force public corporations to hold internal democratic elections every few years to select a new board and executives and limit how many terms a CEO can stay in office.

The government is so busy fighting dictatorships overseas that it's forgetting about the dictatorships that are growing on its own soil.

<comment><USER49> If you founded a successful company, how would you feel if you were legally forced one day to resign from running it, even though you've done nothing wrong? Under either capitalism or communism, this seems unfair.

<comment><USER29> The fact that someone is allowed to be the leader of a massive too-big-to-fail company for the rest of their lives just because they happened to be employee #1 seems extremely unfair.

We should stop pretending that the CEO is the one doing the work and delivering the value.

Absolutely anyone can be a great CEO if they have lots of smart people under them.

<comment><USER49> This is kind of a narrow way too look at things, isn't it? I think a founder of a company is more than "Employee #1". They are literally the person who envisioned and created the company. That deserves respect and if the founder is not harming the company or breaking laws, I don't see any reason why my government should have the legal ability to make them step down.

</comment></comment></comment></comment><comment><USER50> submarine for IAC

</comment><comment><USER51> Every NYT article i see here lately has been spinning a negative narrative around tech. Funny</comment>


Adding watermarks, credits, badges and text overlays to images - <AUTHOR> http://cloudinary.com/blog/adding_watermarks_credits_badges_and_text_overlays_to_images

<comment><AUTHOR> This post describes how to easily add watermarks and textual credits to your own images by using Cloudinary's new Image overlay feature. This same method can be used to embed custom badges and medals to your users' profile pictures, merge arbitrary text to your website's selected images, and much more.</comment>


The First 10: Week 0.  My blog about bootstrapping a new product. - <AUTHOR> http://first10.255bits.com/wordpress/2013/01/02/week-0-initial-progress-report/

<comment><AUTHOR> I'm aiming to be completely transparent through this whole process. Feedback is appreciated, and feel free to ask me anything.</comment>


Improving Facebook Mobile Profiles - <AUTHOR> http://newsroom.fb.com/news/2015/09/improving-mobile-profiles/ <comment><USER2> Off topic - but why does their chosen font (Freight Sans Pro) render so poorly on Chrome?</comment>


WiringPi – Deprecated - <AUTHOR> http://wiringpi.com/wiringpi-deprecated/ <comment><USER2> That's a bit of a rant, indeed, but also a very good summary of the reality out there...

</comment><comment><USER3> such a shame</comment>


In 2017, VR Headset Shipments for Most Top Brands Went Down - <AUTHOR> http://nwn.blogs.com/nwn/2018/01/vr-sales-shipments-2017-superdata.html <comment><USER3> > In many more words: 2017 sales of "full VR" rigs were flat or even negative, > with Rift shipping slightly more HMDs in 2016 than 2017, and HTC Vive > shipping less last year than the year before.

By those numbers, PC VR sales are only down in 2017 if you exclude Windows MR. That seems a bit arbitrary, as the Odyssey at least is apparently a fairly decent system overall.

Again by these figures, sales of all PC and console VR systems are up except for the most expensive, the Vive, which was $800 US for most of 2017. That seems to support optimism that future PC VR price reductions will improve sales: especially an end to the cryptocoin-driven GPU cost (and availability) crisis.

It also has to be said that people with inside information have publicly expressed skepticism about the SuperData numbers: [https://twitter.com/PalmerLuckey/status/959172783765729280](https://twitter.com/PalmerLuckey/status/959172783765729280)

(Repost of my comment: [http://nwn.blogs.com/nwn/2018/01/vr-sales- shipments-2017-sup...](http://nwn.blogs.com/nwn/2018/01/vr-sales- shipments-2017-superdata.html?cid=6a00d8341bf74053ef01b7c95052ff970b#comment-6a00d8341bf74053ef01b7c95052ff970b) )

</comment><comment><USER4> One thing I didn't see in the comments or the article: the price rise/shortages in GPUs which is impacting those interested in pc gaming (and thus vive/oculus VR systems).

I've actually been warming up to play with VR more but am concerned first- party eGPU solutions (I.e a MacBook eGPU box) will get delayed.

<comment><USER5> I definitely think this is part of the story. Most people need to upgrade their systems to support VR, but it is becoming prohibitively expensive to get a decent card.

</comment></comment><comment><USER6> Popping a mobile phone into a VR headset is a pain, as is all the cables on the high end (desktop) VR platforms. I am curious how Oculus Go[1], launching soon changes the game (if it does). At the very least, it opens the market to a lot of iOS users. Thoughts?

[1] [https://www.oculus.com/go/](https://www.oculus.com/go/)

</comment><comment><USER7> Can't use VR if you can't get a decent GPU

<comment><USER8> Can't get a decent GPU if you can't get a decent CPU

<comment><USER9> Can't use your CPU when RAM doubles and trebles in price.

ETA: I looked up my graphics card and it had also doubled in 'value' since I bought it. From my cold, dead hands though.

</comment></comment></comment><comment><USER10> I have purchased multiple VR headsets (the kind that your phone goes into, not "full vr") and each one has massively hurt my face. The Cardboard ones hurt my nose from the very second I put it on or hold it to my face (while using it and for some time after). The only way to get a good picture is to have instant and intense pain in my nose.

Google Daydream is a bit better. With the nice fabric and straps it takes about 1-2 minutes before the intense head pain starts. Not only is it insanely heavy and makes any experience hurt my neck, but also, it hurts my nose too! (I do wear glasses, but each of these products says that it doesn't matter and that glasses-wearers can use VR too. Not sure if that is a lie or if this affects non-glasses-wearers just as much).

Additionally, the content available in the Play Store is not of great quality, in my opinion. The paid content is also a mess, not just the free stuff. There are some neat games, but they don't work well (lose save state, etc) and everything hurts physically after 1-2 minutes on a $100 system.

I'll wait many many years before trying to purchase again. It feels like the '80s VR rush all over again, where actually using the product falls so far short of the expectation that I'm disillusioned.

It's true that I have not yet tried a "Full VR" system - but they have been too expensive so far and I am not certain that they would be any less awful of an experience for me to use.

Do other people have the same head pain issues as I do? I would certainly expect that the decline in sales is mostly to do with people finding out that actually using VR isn't very fun (yet).

Edit: I bought a $10 game, Eclipse I think, where I have had to play the same intro level to the game like 8-10 times, because my nose hurts so much that I have to take a break. But you can't take a break or you lose your save state (I have spent more time than I would like to admit trying to find a way to save the state, this game looks super neat). But now if I want to play this game I paid $10 for, I have to play the same sequence again and again, and try to finish before the nose pain is unbearable. At this point, I am losing interest in the game despite its amazing reviews and my previous intense dedication to playing it.

<comment><USER11> I have an Oculus Rift that I use for three setups: Sim Racing, Sim Flying, and playing Elite Dangerous.

I've been able to put in multiple hours in all of them, with two caveats.

First, I take my glasses off. There's just no way that's gonna be comfortable ever. You can buy prescription lens inserts for the Oculus, but my prescription is mild so it doesn't bother me.

Second, you have to loosen the straps. If the headset is leaving an indent in your face it's too tight! I learned that the hard way..

<comment><USER10> Interesting! Okay, thanks for the info. I did guess that the "glasses are okay" business was more marketing than reality, so it's interesting to hear you say you wouldn't use it with your glasses. Everything in VR gets real blurry for me if I try without my glasses, and I'm not ready to buy special prescription VR glasses either, so I'll wait a bit.

I'll try looser straps on my Daydream next time I try it, but it'll be hard to keep it on my head that way too I think.

Thanks again for the info.

<comment><USER12> PSVR works great with glasses though. I have quite large glasses and they fit just fine.

Note that the PSVR floats before your eyes, hanging by a frame mounted on your head. The oculus and rift push directly on your face

</comment></comment></comment></comment><comment><USER13> I would have several actual uses for VR, and from the top of my head I'd kill to have proper depth perception and enhanced controls while modeling the solids I have to make.

The headsets make today would meet my requirements perfectly. The price is not an issue. As a coder, I wouldn't have any problems with just a library exposing the display and sensors.

However the VR market is just full of BS and lock-in. I'm not moving an inch on any of these closed platforms.

<comment><USER14> Razer has an OSVR headset. Oculus is OSVR-compatible. Even Vive has a (less supported) OSVR plugin. What's your complaint?

<comment><USER3> There's also a Khronos standard in the works: [https://www.khronos.org/openxr](https://www.khronos.org/openxr) .

</comment></comment></comment><comment><USER15> VR is awesome, but strapping a cell phone to your face with magnifying lenses is stupid. The technology needs to progress beyond this paradigm to ever be successful. Even the high end "real vr" HMD's are just a cellphone strapped to your face. Perhaps once solid state optical waveguides are a thing we will see mass adoption. But the current gen is extremely lackluster and frankly useless once the initial wow factor wears off.

<comment><USER16> Saying that VR headsets are cellphones strapped to your face is just flatly wrong. There is a lot of work poured into VR when you start talking about room-scale plus intuitive control solutions.

I would far from say that it is extremely lackluster considering what I've experienced and worked with thus far.

<comment><USER17> I believe they are referring to those Android VR headsets like "Gear VR" by Samsung.

</comment></comment></comment><comment><USER18> Here we come across a great Trough.

</comment><comment><USER19> Aside from perhaps Rez Infinite, VR doesn't really have a killer app yet. Almost no other title can deliver a compelling experience without risking motion sickness and eyehurt, and Rez Infinite just isn't enough for J. Random Gamer.

<comment><USER20> I'd wager my entire lifesavings that the stickiest, highest DAU/MAU app for vr - SO FAR - is porn like the SLR app. Somewhere in Oculus there's a dashboard showing user retention rates by most commonly used app and SLR or Honey Select or whatever else is at the top. But they can't say that at a press conference.

Nobody wants to be the one to tell their buddy "hey check out this porn on my VR headset" so it's not growing as fast as it could via word of mouth. But it's a very very big step up in terms of UX.

Would someone pay $300-400 for a better porn experience? Probably not.

But if we're talking about "of the people who already own a VR HMD and still use it often rather than letting it collect dust, what do they actually use it for?"

The answer is porn.

<comment><USER21> Meh, not really man. Porn is tired and obvious. The real killer app for VR is social interaction with other people. It's quite an experience to see someone else in VR standing before you and interact with them naturally as you would in real life.

<comment><USER22> Considering texting has more adoption than video chat even though video is very accessible, I don't see how VR interaction is going to make a really big dent.

<comment><USER21> Texts will be more widespread due to their transactional nature. You can't really do video chat unless you're ready to sit down and have a conversation.

<comment><USER22> Voice still dominates video too.

</comment></comment></comment></comment></comment></comment><comment><USER23> I recently got the PS4 VR system, and....wow.

I expected a glitchy system that was too early to be useful but had neat moments.

What I got was a glitchy system that has some useful parts already and the neat moments really show the promise.

Despite it being not very realistic, my brain was happy to adjust. Playing Skyrim with peripheral vision and being able to reach out to the side and snag some item without changing the direction I was moving was surprisingly amazing. I found my body reacting as if the projection was real - flinching, trying to scratch my nose because I forgot I was wearing a huge mask, ducking, reaching out with an arm, peeking around a corner, glancing. I'm a terrible gamer, so "block" functions are something I rarely use...but pulling up my shield when someone is swinging a sword at me was natural - and seemingly worked.

Fruit Ninja VR is the sword/lightsaber game I've always wanted. Full angle and rotational movement, I could slice, slap aside with the flat of the blade, and even spear completely naturally.

Some games have the controller wands replaced by hands in the projection and I would occasionally drop the controllers because I was trying to use my "fingers".

Motion definitely makes motion sickness more likely. Smudges on the eyepieces are terrible, and getting just the right focus and calibration is finicky, especially vertical (some games have me stand at the same distance from the camera that other games require I sit). Teleportation movement broke immersion a lot, but constitutes an entire new genre of game as far as I could tell - <USER2> tried a demo of a shooter that had only teleportation movement, and the tactics it involved were totally new. Archery imitations fell very flat for me - motions a bit too imprecise to "nock" an arrow, and holding a wand in each hand is not close enough to a bow and sting. The lack of tactile feedback on the draw strength was surprisingly less important than I expected though.

The Star Trek Bridge Crew game and Battle(something involving tanks) gave me control panels to my immediate left and right that seemed perfectly natural in ways that a flatscreen display has not.

Honestly, we're a lot closer to a big interface change than I thought. I think the Input is now behind the Output. Get me Geek gloves so that I'm not holding a controller and can have my fingers in game and some more natural way to indicate walking/running/jumping and I'll call the package truly revolutionary even with the various caveats and finicky-ness of the VR display. (of course, I just listed some things I have no idea how to implement)

After a couple of hours, I was ready for the Singularity. Upload me and screw this physical limitations business. The VR wasn't real, but it was already close enough to make me very happy.

That said, while I have a blast each time I use it, I often elect to not go through the hassle of getting it all set up when I have some rare free time to play a game, particularly during daylight hours when the sun might wreak havoc with the camera's ability to find the helmet. I'm not surprised sales haven't been strong. I also won't be surprised if that changes dramatically when it's a pair of goggle-sized goggles, even without input changes, and with input improvements it's...surprisingly awesome.</comment>


Yoga: A cross-platform layout engine - <AUTHOR> https://code.facebook.com/posts/1751945575131606 <comment><USER3> One thing I've thought about recently is Facebook's Patent grants, and it's one thing that makes me uneasy about using any open source technology from Facebook like React (I currently do but am thinking to move to Preact because of the nicer MIT license and that it's analogous to React in many ways) because they're generally given a patent grant. I'm not a lawyer so I don't know if the grant would hold up in court since it's not actually in the license itself, only referenced in the readme but if I had a patent and Facebook infringed on it my license is terminated if I assert my patent rights against Facebook even if it is valid and doesn't pertain to specific React technologies. This has been discussed heavily in the past but suffice it to say it's pretty scary and bears thought.

This library looks very useful for those who use React Native or want a layout engine in C# or Java for their mobile app, but as someone who works in an industry (bio/chem engineering) who develops applications around tools in that industry and thinking that Facebook may one day enter that field, or even if we create a software patent for some idea we create while developing the tools, it makes me uneasy whenever a new Facebook open source project, especially one with the potential to become popular in a specific area of software development, is introduced.

Also, another thing to keep in mind is not every big company does this with their open source tech. For example, Angular and Visual Studio Code are both under MIT license.

<comment><USER4> I am curious to hear of anyone who has reviewed this license with their lawyers / legal departments and received a positive, non-cautionary response to go ahead and use the software and libraries covered under it.

<comment><USER5> The React wiki has a non exhaustive list of users[0] which includes some rather large companies (BBC, Airbnb, Automattic, Atlassian, eBay, Netflix, etc.). I presume most of those larger companies had their legal departments approve its use.

[0] [https://github.com/facebook/react/wiki/Sites-Using- React](https://github.com/facebook/react/wiki/Sites-Using-React)

<comment><USER4> That may be the case, but I personally would be surprised. My impression is that most companies don't do a good job of managing and monitoring dependency licensing.

I have seen tooling that analyzes licenses, but not for node or client-side javascript. Maybe I'm just in the dark.

<comment><USER5> That may be true in general but the React license has generated _a lot_ of buzz. If you look at pretty much any Facebook project posted on HN, you'll find that one of the top comments is about the license. Also, the decision to use React is impactful enough that I'd expect most tech CTOs to know about it. I grant you that some might not take the license issue seriously enough to discuss it with legal counsel.

To answer your original question, I found this statement by Automattic's legal counsel[0]:

> "Automattic looked at the legal issues with Facebook's patent license on > React," Sieminski said. "The termination provisions of the patent license > aren't ideal, but are not a blocker to using React as part of Calypso."

[0] [https://wptavern.com/automattic-will-continue-to-use- react-j...](https://wptavern.com/automattic-will-continue-to-use-react-js-in- calypso-despite-patent-clause)

</comment></comment></comment></comment></comment><comment><USER6> I made a similar library earlier this year. It builds as C or C++ and is only two files (MIT license): [https://github.com/randrew/layout](https://github.com/randrew/layout)

The API is similar to Yoga. I hadn't seen Yoga before, and I'm surprised at how similar it is. It seems like Yoga is about the same age (or older?) than my Layout library.

It's meant to be easily embedded into existing software, such as game engines, OpenGL-based tools, custom GUI libraries, etc. without requiring its own complicated build system. Its API and layout engine seems to work in a way similar to Yoga, but it doesn't have pre-made bindings for any existing GUI toolkits. There is, however, an example binding for the Lua scripting language.

API comparison:

Yoga:

        YGNodeRef root = YGNodeNew();
        YGNodeStyleSetWidth(root, 500);
        YGNodeStyleSetHeight(root, 120);
        YGNodeStyleSetFlexDirection(root, YGFlexDirectionRow);

        YGNodeRef image = YGNodeNew();
        YGNodeStyleSetWidth(image, 80);
        YGNodeStyleSetMargin(image, YGEdgeEnd, 20);
        YGNodeInsertChild(root, image, 0);

Layout:

        lay_context ctx;
        lay_init_context(&ctx);
        lay_id root = lay_item(&ctx);
        lay_set_size_xy(&ctx, root, 500, 120);
        lay_set_contain(&ctx, root, LAY_ROW);

        lay_id image = lay_item(&ctx);
        lay_set_size_xy(&ctx, image, 80, 0);
        lay_set_margins_ltrb(&ctx, image, 0, 0, 20, 0);
        lay_insert(&ctx, root, image);

The Layout library can handle laying out tens of thousands of items in a few microseconds, so I would expect Yoga to have similar performance. (Layout is meant to work stutter-free and waste-free with layouts that could be animated or changing every frame in a game engine.)

One major difference I noticed, though, is that Yoga seems to allocate for each individual node, whereas Layout uses a single resizable contiguous buffer. This is gives it pretty good CPU cache performance (writes are all in their own separate region of the buffer) and allows you to do complete rebuilds of the layout hierarchy without any heap allocations. It's nice if you have a dynamic layout and want to keep the layout calculations fast/cheap. It might be interesting to do benchmarks of the two libraries in different scenarios.

Are there any other libraries similar to Yoga and Layout?

<comment><USER7> Hey, this looks really good - I'll give a shot at using this in MOAI! Thanks for that!

<comment><USER6> Thanks. Leave a message or issue on GitHub if you have any problems and I'll try to fix it. I've only used it in my own software, so there's a chance you will encounter some shortcoming or bug that I haven't.

</comment></comment></comment><comment><USER8> I like the concept and the C# code is just hands down the best example out of all of them (yet another reason I miss coding in C#).

I'm curious though, will this be eventually ported to JavaScript? Yeah yeah I know "flexbox is already on the web!" but if you could write a layout in this fashion versus using style sheets then you could take it and directly apply it to any of your applications (even if you have to convert between languages the exact same setup is still there it's just a straight up conversion).

Overall cool idea and implementation. Curious to see where it goes from here.

<comment><USER9> I'm not sure how you're supposed to use this from C# in real life, though.

Ok, you have a layout engine. For what widgets? Windows.Forms? WPF? Xamarin Forms? Can those even use a third party layout engine?

I'm slightly confused :)

<comment><USER10> To be honest, I'm a .NET developer and I'm not entirely sure either. None of the tests they wrote show any integration with existing widget engines.

One thought I had is that one could use this layout engine to do the calculations for the positioning of visual objects on the screen, but you would have to essentially build a fully integrated layout manager that renders to the particular framework you're using. Maybe overridding the hooks for existing layout managers that come with the particular UI framework (for example, WPF has layout managers).

For example, in WinForms, if you build the UI programmatically rather than old fashioned drag-and-drop, you could set X/Y positions, widths/sizes etc. per the constraints generated by this engine. Needs to be observable/reactive so the UI changes are fed back into the engine and then the UI automatically changes - much like existing layout manager tech.

Perhaps doing this work/exercise was left to the open source community/reader. There aren't any examples/tests showing how to integrate this layout manager with any existing .NET UI widget frameworks. It looks like they wrote the integration with .NET in C# (on MacOS as well), and tested the layout engine itself, but that's about it.

EDIT: Possible hooks for old WinForms maybe? [https://msdn.microsoft.com/en- us/library/z9w7ek2f(v=vs.110)....](https://msdn.microsoft.com/en- us/library/z9w7ek2f\(v=vs.110\).aspx)

</comment></comment></comment><comment><USER11> Okay, question: can it perform the following task elegantly?

Say, I build a declarative tree describing a layout, and I render it. Now I remove one item from the tree. Can the layout engine efficiently remove the item from the view, and... (now it comes) provide an animation for it? As in, the item slowly losing opacity, then the surrounding items moving closer together? (Or a different animation depending on settings).

Of course, the opposite should also be possible (i.e., inserting an item).

Implement this, and we're a step beyond CSS, because so far this has not been possible (elegantly) in CSS. I.e., remove the element from the DOM tree, and it is gone immediately (without the animation). And no amount of CSS can fix this.

<comment><AUTHOR> Yoga itself does not handle animation but by using another animation system on top of Yoga it should be very possible. I have not yet tried it myself but by wrapping a layout change in a UIView animation block the above should be doable (on iOS but similar should hold on other platforms).

<comment><USER11> Interesting. Could it be done efficiently? I.e., without walking the complete tree on every update?

<comment><USER12> It's platform specific, as I understand Yoga, it's just a nicer way to write UI code as I see it. On iOS for example, you should totally be able to wrap it be able to wrap Yoga code in existing animation engine, like UIView animation, layer animations and UIKit dynamics. So it'll be as efficient as the system its running on implemented its layout and animation engine. In the case of iOS, it would be amazingly efficient.

</comment></comment></comment></comment><comment><USER13> Yoga's layout API is very similar, if not a direct copy, of the web's Flexbox. Which funny enough means that we might get a chance to use Flexbox on the desktop before we can use it on the web. (I'm looking at you IE and your continuing partial support: [http://caniuse.com/flexbox](http://caniuse.com/flexbox))

<comment><USER14> Yes, it's directly based on CSS Flexbox. See more info about the similarities and differences here – in particular a few default values are different:

[https://facebook.github.io/yoga/docs/learn- more/](https://facebook.github.io/yoga/docs/learn-more/)

<comment><USER15> Is there a plan to add support for the extensions (especially AspectRatio) in React web? I would greatly welcome them.

</comment></comment></comment><comment><USER16> Cool to see Facebook release code in C! I clicked the "C" tag in the blog post, and this is the only post referencing C. Heh. Anyway, finally code from an Internet Giant in a language I care about enough to go and take a look at.

It seems ... smallish, which was a pleasant surprise. The core Yoga/ folder contains six files which is certainly fewer than I expected.

Didn't have time to do a full read-through, but one thing that I couldn't ignore is the use of a pointer-hiding typedef for the core layout node:

        typedef struct YGNode *YGNodeRef;

I'm really opposed to "hiding the asterisk" in C, since whether or not a thing is a pointer typically _matters_ , and code becomes harder to read when you need to think about this more.

Even stranger, though, is that then most function protypes look like this:

        void YGNodeMarkDirty(const YGNodeRef node);

So, you have a function called "mark" which really sounds like a mutating, modifying, operation. But it's declared to take a constant node reference!

Peeking at the code, what it does boils down to:

        if (!node->isDirty) {
          node->isDirty = true;
          ...
        }

So it really is modifying, there's no trickery involved (like having node be a handle or indirect reference). It then recurses upwards through the chain of parent nodes, like you'd expect.

This works since the "const" here doesn't apply to the pointed-at object (it's distinct from the un-typedef:ed version "const struct YGNode * node"), it applies to the reference.

So the code jumps through these hoops and adds a const to the _external_ interface, which doesn't matter, all it does is say "yeah, this function won't re-assign the reference variable to point at something else". Which, in my opinion, is not very useful information, as opposed to "this function doesn't write to the object you pass in" which you'd get with the non-asterisked version.

Can anyone shed some light on why one would do this?

<comment><USER7> I'd guess that its because changing the value of the *Pointer would actually be a bug, and const args are used to catch these kinds of bugs...

</comment></comment><comment><USER17> Why not use parallelism? Parallel layout tends to be a major speed boost in our experience, and we have a parallel implementation of flexbox already. See Meyerovich 2010 [1] for the basic idea; you can adopt it to flexbox relatively easily.

Additionally, I'm a bit skeptical about the use of C here: this stuff tends to end up exposed to the user and security-sensitive.

[1]: [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.207...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.207.1244&rep=rep1&type=pdf)

<comment><USER18> For React Native, at least, I think the threat model is a little different. Browsers have to deal with any hostile webpage, so all input can be considered hostile to something like the layout engine -- but here, you're baking the application along with the engine and shipping it wholesale. But I guess it depends on the details of how Yoga actually integrates and what its surface area actually is.

That said, I think the more likely conclusion for security vulnerabilities is the one you allude to, where people will probably end up reusing this component elsewhere and exposing the engine to potentially hostile input somewhere along the line, and it might not end well.

<comment><USER17> Right, it's not an issue with React Native. My concern is that people will end up using this in browser-like settings with untrusted content. Do they adequately guard against stack overflow with deeply nested layouts, for example?

</comment></comment></comment><comment><USER19> Is it just me or does anyone else also feel a bit left behind by this?

They say it has bindings for Android and yea, I can generate these Yoga objects in Java but how exactly would I integrate this with my Android view hierarchy? Do I need to use React for that? The documentation says exactly _nothing_ about this.

What's the piece of information that I'm missing?

</comment><comment><USER20> Why not just embrace Cassowary ([https://en.wikipedia.org/wiki/Cassowary_(software)](https://en.wikipedia.org/wiki/Cassowary_\(software\))) aka the algorithm behind Cocoa's Auto Layout? Auto Layout isn't perfect but I think that it's fundamentally the API/UI that you are working with, the concepts are definitely at the right level of abstraction. Some sort of DSL could really solve this.

Flexbox could be implemented as a framework on top of this.

<comment><USER21> (Original author of css-layout here)

I've spend a few months playing with Cassowary before working on css-layout and had long chats with its creator Greg Badros and the people behind [https://gridstylesheets.org/](https://gridstylesheets.org/).

Cassowary underlying abstraction is a linear inequation solver. So you give it a bunch of constraints of the form ax + by + cz + d < 0 and it's going to give you values for x, y and z.

## There are two innovations in Cassowary:

1) There's a concept of strength (required, strong, medium, weak) which allows you to define which rules should be dropped in case of conflicts. This is a very different way to think about building UI and was a really fun exercise.

That said, I had to build a dedicated tool to show me which rules where overridden or why otherwise it was very hard to understand what happened when the layout didn't work as I expected.

2) Cassowary is an iterative solver, this means that it's not going to recompute the entire simplex from scratch on every tiny update.

## The biggest issue with Cassowary is that you cannot express everything with a linear system of equations:

The most annoying instance is line breaking. You cannot encode how lines are going to break as a set of linear inequations. In practice, what happens is that you're going to "fake it" by iterating outside of the simplex by first giving it a rough size and then do another pass with the real one. It usually works but you are not guaranteed for it to converge nor to have the optimal layout.

## In practice

It's extremely painful to write all the inequations yourself. If you want to have a container with an item of height 100px with 5px of padding it looks like.

        obj.left = parent.left + 5
        obj.top = parent.top + 5
        obj.right = parent.right - <USER2>
        obj.height = 100
        parent.height = obj + 5

For every single object you need to define 4 inequations to "define": top, left, width and height which is very verbose.

So I started writing abstractions for containers, padding... At some point, I realized that I was just reimplementing flexbox. But it was a worst implementation of flexbox because it didn't properly work with text and was way slower.

The other difficulty is that you need references to all those elements. In order to tell where an element is, you need a reference to your parent. This model doesn't work well with React components where you only shouldn't know about your parent.

## Where it shines

The places where constraint solver shines is when you have a wysiwyg element builder. You have a reference to all the elements as they are visible on- screen so it's very easy to link them and you can show 4 inputs for each constraint.

This is very useful for xcode interface builder and would be a good fit for designer tools like photoshop.

Hopefully this gives some light around why we didn't proceed with cassowary :)

<comment><USER22> HN Comments are ephemeral... this would make a nice blog post!

<comment><USER23> They may be harder to find, but HN comments are probably _less_ ephemeral that most blogs (that is, HN comments are more long-lasting and at the same "permalink"... seems that plenty of blogs fall off the internet after a few years).

</comment></comment></comment></comment><comment><USER5> > Yoga also does not support styling properties that have no impact on layout, > such as color or background properties.

Does that mean that Yoga is too low level to be used directly by application developers? Who's the intended audience?

<comment><USER24> Yoga is a Layout engine, not a UI or graphics engine. It's output is basically just the size and position of those objects put into it. So you'd need a bridge to use it for existing UI systems or build a new UI system on top of it (just like what React Native did).

</comment></comment><comment><USER25> Page - [https://facebook.github.io/yoga/](https://facebook.github.io/yoga/)

GitHub - [https://github.com/facebook/yoga](https://github.com/facebook/yoga)

</comment><comment><USER26> I'm especially happy to see the C in CSS go away.

Flexbox and the explicit inheritance used in react native makes styling so much nicer.

</comment><comment><USER27> Very, very interesting - curious about whether the C# bit supports Xamarin on iOS and Android, or if the C# piece is just Windows-only (not super clear from the documentation).

<comment><AUTHOR> I'm not very familiar with Xamarin but I think it should work. If it doesn't please file an issue on the repo.

<comment><USER9> How do you see it being used? I'm especially interested in the C# widget toolkit you used this with, if any.

<comment><AUTHOR> I haven't worked much with the c# bindings myself. It should be able to integrate into most widget toolkits fairly seamlessly I would think.

</comment></comment></comment></comment><comment><USER23> Curious how using this for a complete page layout "feels" to someone who's familiar with designing websites. Since flexbox is intended for 1-dimensional layout only (as opposed to the old-school display:table or the forthcoming Grid spec, which are intended for 2-dimensional layout), I wonder what they do to make it work well for the full page / screen layout (in terms of ease of coding, not the display algorithm itself).

<comment><USER28> The vast majority of interfaces are nested 1-d layouts

</comment></comment><comment><USER29> Yoga is also the new Lenovo laptop. Human languages need better support for namespaces.

<comment><USER30> I would think that the industry vertical is namespace enough.

Hardware laptop vs software library?

</comment></comment><comment><USER31> I wonder why the new C implementation is faster on Android than the old Java implementation, even though the former comes with some overhead for JNI and the inability for the ART ahead-of-time compiler to do any cross-module optimziation between Java and native code. Is it because C has structs, which java still doesn't have?

</comment><comment><USER32> Looks like a nice library, but maybe I'm missing one thing in the examples. In the examples they define an image and text views, but only in the iOS Obj-C example are they a native image or text view. How do you define the YogaNode to say be a TextBox in C#?

</comment><comment><USER33> I'd love to see this defined as a formal spec so it might be implemented in JS. Having access to raw layout calculations in React applications would solve the need to peek at the DOM all the time in so many cases.

</comment><comment><USER34> Is anyone thinking of creating a Go binding for this?

</comment><comment><USER35> I like Facebook creating platforms but it is unclear, at least to me, what the problem is they are trying to solve here.

<comment><AUTHOR> There are a couple of things which we set out to solve with Yoga. These are two things.

\- One layout concept across different platforms. This allows developers to more easily collaborate and jump between platforms and re-use knowledge.

\- Decouple layout from rendering. A lot of UI frameworks couple layout tightly with rendering which often ties the layout to be run on the main thread. By decoupling layout we are able to run it asynchronously. [https://code.facebook.com/posts/531104390396423/components-f...](https://code.facebook.com/posts/531104390396423/components- for-android-a-declarative-framework-for-efficient-uis/) Talks about how we make use of this.

</comment></comment><comment><USER36> I wonder if this competes with Qt or GTK?

<comment><USER37> No it does not. But, with some hand wringing you could probably write a Gtk+ GtkLayout-based widget that used this engine to do layout rather than box packing or ebassi's constraint stuff that's going into Gtk+ 3.89.x/4.x.

...I'm not sure that you'd actually want to, but that's a different issue.

</comment></comment><comment><USER38> I wish they had chosen a different name, Yoga is too popular a name to be chosen for something like this.

</comment><comment><USER39> Static layouts are hardly "complex." The complexity comes from animating between different layout states, animating elements in a list, animating elements relative to other elements (e.g., parallax), animating element size changes, etc.

It seems confusing to me to have "layout" as a separate component rather than having it be tightly integrated with the rest of the UI framework.

</comment><comment><USER40> Is there a designer online to easily build these layouts? (not counting generic flex box tools)

</comment><comment><USER41> Can i use this in react?

<comment><USER15> Not yet (other than react native)

Which is a shame, since the lack of aspect ratio support is one of Flexbox's failings (and apparently resolved with Yoga)

</comment></comment><comment><USER11> What is the footprint of this library in bytes?

And is it light on dependencies?

<comment><AUTHOR> If you are using purely the C library it is very small and has no dependencies. I can't remember the exact size as it was a while ago I looked but check it out.

</comment></comment><comment><USER42> Is this a more general-purpose, polyglot version of Vaadin?

</comment><comment><USER43> Looks nice but the naming is wrong. We shouldn't expropriate well known names for tech solutions

<comment><USER11> I think the name comes from flex -> yoga.

<comment><AUTHOR> correct :)

</comment></comment></comment><comment><USER44> Great work guys.

I think now we can start on CSS => Compiled Style Sheets. :)

</comment><comment><USER45> Why not use something like XAML instead? Much more readable and powerful.

</comment><comment><USER46> I really dislike how software is able to hijack meaning of nouns in our regular lives. To call a software 'Yoga' is so tasteless lol.

<comment><USER47> > To call a software 'Yoga' is so tasteless lol.

Or hip, depending on where you are :)

</comment></comment><comment><USER48> Using the name "Yoga" for your software is cultural appropriation. Facebook should not do it.

It is equivalent of naming a sports team Rednecks.

<comment><USER49> Is Yoga a derogatory term? I've never heard it used in such a way, so I think that's quite the false equivalence.

<comment><USER48> Does not matter. It is not a good idea to use other people's cultural heritage to name "things". In fact the downvotes here suggest how deeply prejudiced and racist people are on HN.

<comment><USER50> _In fact the downvotes here suggest how deeply prejudiced and racist people are on HN._

Is it fair to generalize like this across all the members of HN? You might argue that this is the case for those that down-voted, but everyone?

<comment><USER48> If a comment has down-votes it is fair to say people who did not upvote despite reading supported the action of the downvoters.

<comment><USER50> Okay, I can understand that point of view. Even that only includes those who saw the discussion, right?</comment></comment></comment></comment></comment></comment>