What's Next for Scala - <AUTHOR> http://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala.html <comment><USER3> The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.)

Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Their decision to embrace whitespace sensitivity, while simplifying the syntax for predominant use-cases (again, union types!) betokens flexibility, and a desire to swing for the rafters.

The only thing that saddens me somewhat is that Scala Native does feel like a bit of a second class citizen. The `stackalloc` feels a little sad (coming from C++ -- it should be inverted!). I wonder if it's possible for Typesafe to leverage Scala Native in a manner akin to Python with Numba/Cython. With whitespace indentation - native code inlined and FFI'd automatically - <USER2> there with the rest of the nice JVM stuff.

I can't resist citing my email from Feb '07 asking (politely) why we needed a 'new' keyword. Dotty apparently removes the need for that keyword. Should have listened earlier, team Scala ;)

[http://www.scala-archive.org/quot-new-quot-keyword- td1989540...](http://www.scala-archive.org/quot-new-quot-keyword- td1989540.html)

<comment><USER4> Unfortunately, I slowly got frustrated reading the what's coming for Scala 3.

* True intersections and union types -- use them sometimes, not something you can't live without though.

* Trait parameters -- slightly easier life for OOP, ok I guess.

* Function types and implicit function types -- right, will make your code even harder to read (subjective).

* Generic tuples -- again, I can't remember we ever had problems with tuples in Scala.

* Opaque types -- another small OOP improvement.

* Type lambdas -- I've never seen them used.

* Erased parameters -- probably useful if it improves performance even at the cost of readability right?

* Enums -- finally something practical, good.

And that's all about major changes in Scala 3. Ah, yes, we get a new compiler. Are you excited?

These changes look like a quarterly release than a major version shift. Now, imagine a project manager who's estimating the migration downtime for Scala 2 for the sake of the above.

<comment><USER5> Scala 3 could improve on 2.x struggles with supporting JDK 9 and up:

Support features of JDK 11+ [https://github.com/scala/scala- dev/issues/139](https://github.com/scala/scala-dev/issues/139)

Support Java Module System [https://github.com/scala/scala- dev/issues/529](https://github.com/scala/scala-dev/issues/529)

In comparison language features seem to attract much more attention:

Removing existential types [https://contributors.scala-lang.org/t/proposal-to- remove-exi...](https://contributors.scala-lang.org/t/proposal-to-remove- existential-types-from-the-language/2785)

Significant indentation syntax [https://github.com/lampepfl/dotty/pull/7083](https://github.com/lampepfl/dotty/pull/7083)

<comment><USER6> That is a good example why betting on the platform languages is always a long term safer bet than betting the house on guest languages,

Eventually they won't keep up with the underlying platform.

<comment><USER7> It's not like it isn't working. Scala runs fine on JDK13 (probably 14 too, but we currently run one Play project in prod on 13).

Java is a pretty safe bet, as it has an outstanding backward compatibility track record.

</comment></comment></comment></comment></comment><comment><USER8> Author here. The full title is "The Death of Hype: What's Next for Scala", and the full title is significant. This article is as much about the initial hype and its decline as it is about the future prospects of the language. It very much isn't an official or even unofficial roadmap for the language, which is what the shortened title makes it sound like.

<comment><AUTHOR> I posted it with the original title. I don't know why the HN moderators almost always change titles. Happened to me a couple of times.

</comment></comment><comment><USER9> Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains high. Your more experienced colleagues will not allow to write anything that even remotely smells OOP. This delays the time when you can be productive. Third, on paper Scala tries to serve both object oriented and functional worlds but in practice the the latter is the unconditional standard. Although I like the positive tone of the article, I find it difficult to agree with Scala ever becoming mainstream.

<comment><USER10> I was asked to join a team of scala developers. Most except one had started learning about 6 months earlier. I was asked to learn it while making small contributions to the project. I quickly found out that there were statements that could be interpreted in multiple ways, can't remember now what it was. Then I got stuck on something and even our seasoned very enthusiastic Scala developer could not solve it. I then and there decided not to pursue learning the language and quickly have myself transferred to another team. It's a difficult language, one should not spend thinking on the language but spend time thinking about the problem itself. Probably what I say is not doing justice to Scala as I was just a newbie but I did not have those problems with Clojure which is another not that mainstream language.

<comment><USER9> And that's the whole problem with Scala. When you work with it, you are having a battle with types and compiler more often than you should. Funny but it is not the first typed language I had to write code in. Never did I have to do so much unnecessary dancing around and asking senior colleagues for help. I guess not all of us are capable of grasping such expressiveness at the cost of such complexity. The majority just need simpler tools to be productive.

<comment><USER7> That's what led to ZIO.

Going full FP in Scala with Scalaz and "tagless final" (I still have no clear idea what's that) and whatever else that's hip, leads to madness. Sure you can write maximally polymorphic code. Great. But you end up doing the extractions/refactors that the type system and the compiler allows, not those that would help the code the most. Because those are too slow (too much boxing and GC churn), or the compiler has a bug (or the library) so you end up putting a TODO comment in the code with a link to a github issue.

Or it's a feature that's not supported by Scala, so you end up with a FP spaghetti. :(

</comment></comment></comment></comment><comment><USER11> I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following:

1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes. Nothing wrong with that. But that also means language features are added not to solve a practical problem but mostly to show that "it can be done"/"prove a point". When you are awake at 3 AM early in the morning because a release made in the evening went awry and you are trying to grep though logs/code to see what caused the issue I can assure you that debates about "pure" versus "impure", Monads, Kleisli arrow will be further from your mind. So the problem that Scala seems to suffer from is that of "image".

2) Second, Scala is neither a fully functional (FP) nor object oriented (OOP). Support for mixed/multi-paradigm sounds nice on paper but let me ask this question: do you know of any hard core FP programmer who is excited about inheritance or abstract classes or other OOP features? Vice-versa the same thing can be said about many OOP programmers lukewarm response towards many functional features of Scala. I believe that support for mixed/multiple paradigms has hindered large scale adoption of Scala. The language seems to be caught at cross-roads not knowing which way to advance next.

3) Third is lack of niche. True, I absolutely love "Spark" and primarily use it to extract/manipulate data from HDFS/Hive storage but I am gradually gravitating towards "Python" libraries due to their ease of use. What about better Java? Kotlin check. What about sidecar systems used by DevOps? Go check. What about a better designed system language? Rust check. The days of pure general purpose programming languages are truly over and Scala will be in great peril if it fails to expand into newer niches. Without broadening its programmer base it will finally run out of people that can design newer language features in light of ever advancing progresses in processor, OS and memory architectures.

Just my two cents.

<comment><USER12> Well put. I had to use Scala for a little and I wasn't a fan. It's maybe a fun language to play around with for a pet project, but for a reliable production system I would never pick it.

The language is too flexible with too many ways to do the same thing, increasing cognitive load and making things difficult to understand. Maybe you can limit that in your own projects, but what if you have to look at a library codebase that's structured completely differently. Trying to understand that can take a lot of time.

Also there is the problem with hiring. Maybe your current team can work well with Scala, but what if a key member leaves or a service gets transferred. Hiring for Scala turned out to be impossible, so you get all these people that need to learn Scala first. Normally that may be ok, but Scala has a pretty steep learning curve so it takes a lot longer to onboard people.

<comment><USER13> On hiring: Python Paradox comes to mind ([http://www.paulgraham.com/pypar.html](http://www.paulgraham.com/pypar.html)). I've never met sub-par FPer or Scala programmer specifically. Using PHP or Javascript might give you a bigger top of the hiring funnel, but it doesn't mean you'll have easier time finding well-qualified applicant.

</comment></comment></comment><comment><USER14> I've been using Scala as my main programming language for over 5 years. I've found my "plateau of enlightenment" by sticking to a subset of the features: case classes, for comprehensions, futures, immutability, pattern matching. By avoiding things like implicit, overly complex types, defining/overloading operators, and being dogmatic about FP/OOP I find the language stays out of your way and lets you write code that reads like what you're trying to do.

<comment><USER15> I've done the same by being lazy, mainly treating it as a better Java and only learning new stuff when necessary or obviously beneficial. I want to write good programs, not fancy code.

My advice:

\- Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way

\- Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with caution

\-- Except parallel collections. Use those liberally

\- No Scalaz or any other FP-crusader stuff ever

\- Macros and implicits should be rejected by default in code review. Amazing justifications required

\- Enforce coding rules with linters. This applies for any language, but especially important for dynamic and non-straightjacket languages

<comment><USER16> OK, here's my question then. You're embracing Option type and yet presumably avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"), right?

So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types.

So do you match on every one, and nest match expressions inside match expressions inside match expressions? That can get very, very messy and even confusing.

<comment><USER17> For comprehensions should alleviate the examples you have given with regards to readability.

Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent.

<comment><USER16> My question was poorly phrased, since if you're using Option types, you're obviously already using monads, applicatives, and functors.

What I should have asked was: if you're using monads such as Option, then how do you use them effectively without using integral tools such as flatMap?

And you've answered: you can use for comprehensions. I primarily have used Haskell and OCaml, so I sometimes forget about Scala's very nice for comprehensions, which I agree is a great solution. But note that for comprehensions are just syntactic sugar for `flatMap`.

I agree that if you do use Option types in Scala, for comprehensions are a very elegant way to interact with them.

But I'll end with a question. If you're already using option types with for comprehensions, why not also throw in other useful monads like bifunctor IO, which is a great way to deal with async code? I understand the dislike for the tendency in the FP Scala community to use custom sigils, but I do think most people who are using options and for comprehensions would also be comfortable and happy using other useful monads with for comprehensions.

<comment><USER18> > but I do think most people who are using options and for comprehensions > would also be comfortable and happy using other useful monads with for > comprehensions.

You seem to vastly underestimate the gap there is between using a for comprehension and understanding what a bifunctor is.

Nothing wrong with that: once you gain a certain advanced knowledge, it's often very hard to put yourself in the shoes of someone who hasn't gained that knowledge, and even harder to explain it to them in terms that they will understand.

Which is why we have so many unhelpful monad tutorials.

</comment></comment></comment></comment></comment></comment><comment><USER19> As one of those new people boosting recent numbers, Scala is great! I use vscode with Metals and had no jvm experience before. sbt is annoying, Mill seems super promising, and graalvm native images basically mean that if I was going to do it in python, I might as well use scala now.

<comment><USER20> Scala 3 have a Python feeling over it with optional braces indentation ([https://dotty.epfl.ch/docs/reference/other-new- features/inde...](https://dotty.epfl.ch/docs/reference/other-new- features/indentation.html))

I wrote an example using this new (optional syntax) [https://github.com/olofwalker/ting](https://github.com/olofwalker/ting), if anyone wants to have a look.

<comment><USER21> Maybe it's just me, but "optional" is a word I hate seeing in language design, because I'm thinking of how many code reviewers I've met that have a hard time with "optional".

</comment></comment></comment><comment><USER22> I've taken several passes at Scala but the thing that always stops me is that I find it really hard to read unfamiliar code, including the core API implementations. The only Scala code I find easy to read is impure semi-object oriented code which is the non-idiomatic code that the Scala community tries not to write. I'm not sure if there's some point at which a penny drops and it all starts to become easy, but even if that is true, the time period it takes for that to happen is a real hurdle for newcomers.

To me, you have to be intrinsically motivated to become productive in Scala because of that early friction. Which is fine if you are, but if you're looking at a team of programmers and thinking "how do I get them all over that line" when about half of them have no intrinsic motivation to do that, it's a real disincentive to use the language.

</comment><comment><USER23> Scala faces tough competition from Kotlin which has two huge platforms - Android and Spring/Pivotal. Arrow ([https://arrow-kt.io](https://arrow- kt.io)), is enough to satisfy all but the most zealous FP purists whilst maintaining first-class inter-op with the host language. I foresee a lot of new projects adopting Kotlin where once they might have favoured Scala.

</comment><comment><USER5> For context see

Lightbend secures 25MM funding round, proceeds to layoff Scala contributors [https://news.ycombinator.com/item?id=22842166](https://news.ycombinator.com/item?id=22842166)

<comment><USER24> I don't follow Scala (never wrote a single line), so I didn't realize the company changed names from Typesafe to Lightbend. Here's a question: how on earth do they make any money? The Wikipedia article makes an offhand mention of something called Lightbend subscription; is that what keeps them afloat?

<comment><USER25> A lot of it is consulting, and they also have some proprietary and/or hosted services, and even akka plugins that they charge for.

<comment><USER24> thanks

</comment></comment></comment></comment><comment><USER26> I love Scala! It's the language that enlightened me and be more productive. Now, every time I code in other languages (e.g. Dart for Flutter, or JS for web stuff), I grumble when I can't find "standard" features such as "map", pattern matching, optional and named params, implicits.

Also, when I code in Scala, I frequently google and end up learning something new about the language. I know it sounds like distraction/wasting time, but there's a certain satisfaction when I found the "Scalaic" way of doing things, like, "There's gotta be a one-liner way of doing this."

Of course, my complain is still compile time (yes it's significantly faster, but I'm impatient).

<comment><USER4> You would be enlightened the same way or even more if you started with Haskell. That is, it is not Scala you are so excited about but the functional programming.

Btw, the actual thing to be inspired with in Scala is immutability and Option/Some/None instead of null. These are the things that make you code stable and reliable.

</comment></comment><comment><USER27> I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious.

But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to...

2) It is hard to pitch to an organization because of the learning curve if you assume any project maintainer must learn scala to expert level. I failed (in one attempt on a scala mailing list) to pitch to the scala community the idea of having language levels: a compiler switch or the like that would guarantee that a given project will be maintainable by java programmers with only N (1-2 I hope, for the first level) hours of scala training or study, maybe another level for adding certain features (or listing them in a config file), and full-on expert. So teams can be formed with realistic long-term maintainability in mind. Edit: This may be practical with add-ons I didn't try yet.

3) It was unclear what would be the best reasonable, maintainable way to use sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows, mac. Maybe call a native code library for each? Sounds like lots of work and maintenance to do it well.)

4) Startup times, future viability of scala native (edit: or equivalent), and whether it helps or adds enough more complexity given all the above, to just learn Rust and (hopefully) simplify life (in some ways).

5) And you have to learn java first (for those who didn't know it already), and know its libraries and idioms to some extent. Will that still likely be true?

Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme), in a way that is hopefully/eventually at a complexity level that is inviting to other devs, but with plenty of learning headroom for my future growth.

<comment><USER28> Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple.

One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things.

What you have to learn, at least in a basic form, is how the JVM works.

<comment><USER27> Thanks. I used Scala for some years and was always drawing on my java knowledge. Are there now good scala learning materials that don't assume java knowledge?

And the maintainability issue seems similar to perl vs. python in that way: it can be done, but I've found it takes much more work and long-term attention & presence, to enforce things with code reviews than with a project-level config that everyone knows why it is there. Just once when you are not looking and now you have a new (large or small) social and technical headache.

(Edit: in other words, while code reviews are essential I think for many reasons, any time there is a way to enforce something good, before the review, it seems like a win.)

<comment><USER28> As for learning resources, I always loved the Oreilly "Programming Scala" book: [http://shop.oreilly.com/product/0636920033073.do](http://shop.oreilly.com/product/0636920033073.do)

It's one of the few books that is structured in the same way a Scala developer thinks. Lots of Scala books follow the same order: keywords, usual syntax, features also in Java, features exclusive to Scala. I think this is damaging for any person looking to learn Scala, because it does nothing to lay out the way the features interact together. for instance, the Oreilly book shows pattern matching and implicits before class hierarchies, and that maps well with how Scala devs work, because the former features are encountered daily, while the latter tends to be uncommon.

As for maintainability: you're right. Stricter languages are more maintainable. There's also the issue of powerful languages attracting certain kinds of people. Over the years, I've settled on a simple policy: reject everything that is not documented. This goes for both internal code, and external dependencies.

</comment></comment></comment></comment><comment><USER21> Scala has the reputation of being fun to create stuff with, but horrendous when understanding other people's creations. Is this still true?

<comment><USER29> It's less true now because some of the patterns associated with code that's difficult to understand have been deprecated or flagged by the community to avoid.

For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern.

Another example is that it's now (more or less) recognized within the community that it's not preferable to dogmatically adhere to a particular style of programming, such as pure functional or reactive/actors. It's better to use the right tool for the right problem.

Whole classes of confusing code are now prevented or mitigated by language changes in Scala 3. For example, Scala 2's implicits are famously hard to learn and follow within a codebase. One reason for this is that in Scala 2 the keyword "implicit" was overloaded into a few common patterns, including the aforementioned implicit conversions, typeclass instances, and dependency injection. Scala 3 introduces new constructs and keywords to split out these patterns into separate language features, making them easier to learn and more understandable within a codebase.

<comment><USER30> > For example, implicit conversions are now disabled by default. It's possible > in Scala to pass a Foo to a function requiring a Bar due to a chain of > automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and > magical but difficult to understand and debug. The community and language > itself now suggests against this pattern.

Oh God I'm having flashbacks to using Lift in... 2012? There were about four levels of implicit conversions between my model and the final JSON, trying to understand that was hard.

That said, David Pollak the founder of Liftweb was amazingly helpful on on their mailing list.

</comment></comment></comment><comment><USER31> What's with the quote's casual Clojure dissing? Clojure seems more popular and growing more than Scala, from where I sit. Kotlin is not eating into Clojure's user base like Scala, which makes sense.

</comment><comment><USER6> Since the post mentions Scala Native, all these guest language projects that eschew the platform that made them famous and try to pursue the dream of being their own platform, while building an ecosystem, GC and optimising compiler from scratch (even if they build on LLVM or compile via C/C++), would be much better taking advantage of AOT and JIT caches from several JVM implementations instead of pretending they don't exist.

<comment><USER29> In my mind, GraalVM native compilation has superseded scala-native.

GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect.

Scala is now a great choice for CLI tools.

<comment><USER32> > statically linked so they "just work"

If I remember correctly you have to redistribute some .dll (VC something) file alongside your .exe on Windows since fresh Windows installations don't have the .dll. Did that change?

<comment><USER29> I haven't tried GraalVM native-image on Windows :(

</comment></comment></comment></comment><comment><USER33> I'm particularly interested in how this plays out with dotty. My understanding was that lightbend was at some going to take over that compiler from EPFL, but taking over a compiler (the second, besides the current/old one) at the same time they are laying people off?

<comment><USER5> Announcement on Dotty as the future Scala 3 came from Scala Center (EPFL) not Typesafe/Lightbend.

AFAIK Typesafe/Lightbend has made no commitment to Scala 3.

Too bad the roadmap for Scala 2.14 has been scrapped.

<comment><USER29> I've worked with Dotty a bit and read about it a lot.

I am very excited about Scala 3 :)

Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the get-go. I expect that most Scala programmers and companies will want to write Scala 3 code asap.

Within the Scala community, the only truly divisive aspect of Scala 3 afaik is the introduction of optional python-style and Haskell-style syntax with significant whitespace. I was stridently against significant whitespace and now prefer it after having tried coding Scala 3 for awhile.

<comment><USER34> Thanks for this info, very useful and exciting.

I stopped using scala around 5 years back, want to get back to it. Would you recommend jumping straight to dotty? I've been doing a mostly python and a bit of Haskell in the meantime.

<comment><USER29> I'd jump straight to dotty! You may as well learn the latest 'n greatest.

</comment></comment></comment></comment></comment><comment><USER5> Farewells piling up:

Six years at Lightbend, by Eugene Yokota (Scala sbt, scalaxb, scopt) [https://news.ycombinator.com/item?id=22836399](https://news.ycombinator.com/item?id=22836399)

</comment><comment><USER35> I think a major reason Scala flourished was a big reason it has struggled as well: it opened the doors for many people to new and fundamentally different programming paradigms such as actor systems and functional programming. Many people got excited and implemented these new paradigms in production systems without regard to the immaturity of their own grasp of the concepts (think of how many years of imperative/OO programming you had under your belt before feeling confident of setting the style for a project), the learning curve they were non-consensually committing their coworkers to, and the hiring, productivity, and morale burden they were saddling their employers with. From the management point of view, allowing Scala in the door meant running the risk of waking up one day with a bunch of Scalaz in the codebase, one grinning functional programmer happy as a pig in shit, and the rest of the team shouting and cursing.

Likewise, on top of the real problems created by ill-conceived adoption, the irrational backlash against new paradigms is real as well. I'm old enough to remember the fuss over OO programming. Many experienced, successful coders were scared that they were about to become personally obsolete. Some OO proponents insinuated — and panicked veteran coders believed — that a large number of procedural programmers would have to retire or switch careers because they were too old or not intellectually nimble enough to adapt to object-oriented programming. Major companies such as Sun responded to these fears with a marketing blitz to prove their _their_ OO technology was simple and easy to learn and would herald a new age of programmer productivity. Programmer culture was more driven by magazines and books in those days and therefore much more easily influenced by industry marketing. The "simplicity" of Java was an invention of Sun marketing, a successful self-fulfilling prophecy as Java became so familiar that similarity to it became millions of programmers' benchmark of simplicity.

There has been no total war marketing blitz for functional or actor-based programming from a company with the same stature that Sun had in the 1990s. The emotional reaction, the resentment at feeling a step behind the future, the anxiety about whether you will ever be as comfortable and confident in the new paradigm, operate virtually in a vacuum, or worse, in the echo chamber of the internet. Whatever latent fear of functional programming a person feels, the prospect of using Scala will bring it to the fore. The only countervailing force is the (usually lone) individual pushing adoption, and they are unlikely to be up to the challenge. There is a tension between programmers who are more oriented towards business problems, or who just want to get their job done and go home, and the programmers who get excited about different and potentially better ways to express programs. They both think of themselves as humble and results-oriented and have a hard time accepting each other as being equally humble and results-oriented in their own way. They both experience the other as snobbish, condescending, and threatening to their self-image as good engineers.

Sadly, the root of the problem is that Scala is expressive and powerful enough to be a natural vehicle for these new paradigms. An engineering organization should not fear expressive power, because they should have a culture that is incompatible with a single engineer (or a small cabal) committing their peers to a learning curve without consultation, debate over the cost and payoff, and buy-in from the team. Unfortunately, there seems to be an assumption that beyond choosing a language, you have no ability to consciously choose a style. I.e., Scala-as-a-better-Java (the least imaginative approach, but not a bad one) is an impossibility. This is grounded in the assumption that any aspect of a language that can be abused, will be abused, and that engineers cannot make collective decisions about how they will work together, which are odd assumptions to make about the behavior of highly paid professionals. As someone who wrote C++ professionally for many years, I can testify that it is possible for engineers to conform to coding standards that restrict them to a strict subset of the expressive power of a language. However, it sometimes requires management authority to bring people in line -- and perhaps this is a deal-breaker in an industry where teams of engineers are supposed to be entirely self-managing.

</comment><comment><USER36> Scala is an awesome language and studying it helped me improve as a programmer more than I can describe.

That being said, even though Haoyi said he doesn't think Java has "caught up", the fact is it has closed the gap significantly on the language side, and will always remain ahead in other ways (performance as one example). OpenJDK 14 is an outstanding general purpose development platform, and the days are long gone of anyone actually _needing_ an alternate JVM based language, whereas 10 years ago (or maybe even 5) there was a desperate need.

<comment><USER35> If you think of it in terms of the words "need" and "alternative" then you will find a reason not to use Scala. Personally, I have found it painful to watch Java tack on Scala features years late and in awkward and clumsy ways. Encountering ideas first in Scala and then in Java is too often like learning math from a modern textbook and then looking at the same math in a textbook from a hundred years ago. You appreciate how decades of small improvements have made the subject less intellectually taxing despite the fundamental content not changing at all. For Java to end up on the wrong side of this comparison even when it implements features years later, to me marks it as a language in terminal decline, no matter if its popularity has begun to reflect it yet.

</comment></comment><comment><USER37> > _Currently Scala is overwhelmingly used for backend services and /or Spark > data pipelines,_

This is also being taken over by Python. Databricks Koalas is a pandas interface on top of Spark - [https://koalas.readthedocs.io/en/latest/](https://koalas.readthedocs.io/en/latest/)

PySpark was already there (and very much in production). But Koalas (in beta) completely changes the go-to production aspects of spark.

</comment><comment><USER38> I'm sad not because Scala is dying but because it will embolden the many loud voices who like to proclaim it as dying, while others will believe them. Meanwhile, it will continue to progress. I became a better java programmer, a better php programmer, and a better javascript programmer by studying Scala. I became better at distributed systems concepts by studying Akka. I'm sure I will become better at a lot of other things by studying Akka Typed and Dotty. It's a language that clarifies your thinking in a way that brings better practices to other spheres. It's absolutely worth learning.

I've also had the experience of using it on undisciplined teams and that sucked. One overly "clever" programmer can turn off a sufficient number of other programmers and give it a bad rep. I don't think a language being expressive is sufficient cause to blame the language for that, though.

</comment><comment><USER39> > _it seemed to peak around 2016_

[https://trends.google.com/trends/explore?cat=5&date=all&geo=...](https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=scala,golang,rust)

Early 2017, perhaps! Are Go and Rust seen as competitors to Scala?

<comment><USER40> Depends who Scala was a competitor to.

If you viewed Scala as a competitor to Java, then Go is a competitor to Scala and not Rust; because Go is a competitor to Java in my opinion.

<comment><USER6> Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries.

If Go 2.0 ever happens, it will be a competitor to Java 5.

<comment><USER40> So, it depends on what you're talking about; language or organizational need.

Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you're talking about how teams use Java and Go, they're a good match now.

Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and moving them around. From an organizational perspective there are a ton of Java shops that use Java for similar reasons, plus the ability to cheaply and quickly acquire contractors who know Java.

<comment><USER6> Both, people comparing Go to Java apparently lack a complete understanding of the Java universe.

If you are talking about doing REST APIs, talking to Postgres in Java 1.0 servlets style code, yeah Go is a replacement for Java.

Except that is like 1% of everything that is currently being done in Java.

</comment></comment></comment></comment></comment><comment><USER41> > It's not Clojure-dead

What does this mean? I thought Clojure has a dedicated, if small, user base.

<comment><USER42> I guess in the authors mind, dead here means it's stable, solves its problems well and doesn't try to attract developers with shiny new features but instead focuses on enhancing the core experience which gets better.

As a Clojure/Script developer, I could understand that Clojure looks dead from the outside if you're a JS developer, you're used to new language features being shoehorned into the language every year.

But for someone inside the Clojure ecosystem who used to be a JS developer, it's a breath of fresh air when I can take a 4 year old library and include it, everything works and no bugs are to be found. If there is a bug, I can patch it from the outside, if I really have to.

Clojure in general lends itself very well to be extended from the outside (like what clojure.spec is currently doing [and many others]) so the core language doesn't really have to change anymore, we're just building libraries on top of the language which extends the language.

<comment><USER41> The dig at JS developers is completely uncalled-for.

I'm a JS developer and I admire the way Clojure has seemed to skip both the hype and disillusionment phases and jump straight to the productivity plateau.

<comment><USER43> > The dig at JS developers is completely uncalled-for.

Oh, no, as a developer who dealt with web front-ends for a long time, I can attest - it is totally justified.

Modern Javascript, in just a matter of a few years from being a small, simple language with a few quirks has blown into this colossal monstrosity. ECMAScript specification today is almost as big as Java's. There are tons of things that were added ( and still being added ) without careful thinking and upfront design. And that not to mention things that break all the time in the ecosystem of any JS framework. Have you ever tried updating dependencies in a nodejs project that is just a few months old? It rarely is simple and straightforward. Things break left and right. It feels there's no stability at all, compared to Clojure(script) projects. You can pretty much pick any Clojure project (that is a few years old) and update its dependencies, and most of the time, you can expect things not to break.

People got excited about React hooks, and Clojurescript people were like: "folks, we've had a better way of dealing with stateful components for a few years now."

JS devs got excited about destructuring (which looks like a weak attempt to borrow it from Clojure), without even slightest hint of how much more straightforward and cooler destructuring actually looks and works in Clojure.

They say they love JSX, which, compared to Clojure's Hiccup, is just a total and absolute crap.

JS devs are eager to use nulish coalescing and optional chaining and write unreadable crap like: `input ?? obj?.key ? 'yes' : 'no'``. And they dare to say that Lisps are not readable? ¯\\_(ツ)_/¯

Honestly, after years of dealing with it, my take on it is this: Javascript is a morally outdated programming language. And Typescript is somewhat not the best attempt to fix its issues.

<comment><USER44> TypeScript adds that extra Java smell back into the mix ;)

</comment></comment></comment></comment></comment><comment><USER45> Scala and the Play Framework became my tool belt for whatever web application I need. It has all the batteries included, it's stable and rock-solid. It never felt so good to use a "boring" stack.

</comment><comment><USER46> Hands down, Scala is my favorite language. The world-class type system combined with its very practical nature make it a natural fit for really any server backend. And now with GraalVM, Scala hopefully will make inroads into desktop and command-line apps (start-up time has always been an issue, until now). Scala 3 looks pretty amazing and the future is bright!

</comment><comment><USER43> > It's not Clojure-dead

It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten.

Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them.

\- Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²"

\- Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³"

\- R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴."

\- Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵"

\- JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff like React Hooks, and Clojure people: "Hmmm... actually we had a better way of dealing with stateful UI components for a few years now. We've been trying to tell you, but you never listened..."

They've been saying, "Clojure is dead" for years now. But despite all the odds, Clojure is very much alive and thriving. It's the most popular language within languages with a strong FP emphasis. Just look around - it has more books, more jobs, more podcasts, more conferences, and meetups than of Haskell, OCaml, Purescript, Elm, Elixir, F#.

I suggest people from other PL communities learn from Clojure people. It is a small but diverse and very friendly community of pragmatists - while others keep shoveling the same shit from one corner to another, trying to re-invent things over and over again, Clojurists keep borrowing good ideas and filtering out bad ones. And calmly and quietly keep building cool stuff and getting paid for it⁶.

¹ [https://dragan.rocks](https://dragan.rocks)

² [https://github.com/clj-python/libpython-clj](https://github.com/clj- python/libpython-clj)

³ [https://github.com/candid82/joker](https://github.com/candid82/joker)

⁴ [https://github.com/scicloj/clojisr](https://github.com/scicloj/clojisr)

⁵ [https://github.com/clojerl/clojerl](https://github.com/clojerl/clojerl)

⁶ [https://bit.ly/3a3wxNH](https://bit.ly/3a3wxNH)

<comment><USER47> Hmm, I don't like the concept of talking about a programming community as e.g. "python people" in combination with stating something on their behalf.

<comment><USER43> You are absolutely right to correct me, I re-read my comment, and it does look hypocritical, which wasn't my intent. Paradoxically, in the spotlight of what you've said, it looks a bit like "bees against the honey" movement. After all, I myself one of those "Python people." My lame excuse is that English is not my first, second, or even third language. Choosing proper words and nicely phrasing things in it ain't my forte, but I'm trying my best.

</comment></comment></comment><comment><USER23> One of the most off-putting experiences when starting with Scala is the lack of a dedicated Scala repository such as Clojars for Clojure. Floundering around in Maven Central trying to get an idea of what's available for Scala is an exercise in futility and enough to make you want to give-up before you've even started.

<comment><USER48> [https://index.scala-lang.org/](https://index.scala-lang.org/)

<comment><USER23> Great. I stand corrected. How long has that been up? Last time I started with Scala it didn't exist.

<comment><USER49> More than 3 years. I've been using it for that long but it was pretty functional and full even 3 years ago.

</comment></comment></comment></comment><comment><USER50> It is fun to see python being the beacon of friendly library design :)

</comment><comment><USER51> Kotlin

</comment><comment><USER52> Next Step for Scala: Shutdown.</comment>


DNA Digital Data Storage - <AUTHOR> https://en.wikipedia.org/wiki/DNA_digital_data_storage <comment><USER2> Is there anything significant that could be learned from DNA and applied to traditional computer storage methods? Or is this efficient something intrinsic to DNA that can't simply "be transferred"?

<comment><USER3> The other aspect is that the shelf life of DNA can be significantly longer than other mediums. I haven't personally done anything with DNA data storage, but the idea is that tape storage is good for 30-50 yrs, but we can recover intact DNA from mammoths (~10,000 yrs)

<comment><USER4> I believe that DNA recovery after 10k years is not very representative of DNA durability.

<comment><USER3> You are correct, but the variable of interest is recoverability</comment></comment></comment></comment>


Portugal Dominated Angola for Centuries. Now the Roles Are Reversed - <AUTHOR> https://www.nytimes.com/2017/08/22/world/europe/angola-portugal-money-laundering.html <comment><USER2> What an odd assertion. Most of the elite and leadership ( especially business ) in agola are portuguese. It's just the angolan political elite and portuguese business elite plus a handful of chinese oil companies that dominate angola. It isn't angola dominating portugal. It's portuguese businessmen and angolan political elite dominating and robbing angola of its wealth and moving it to europe.

</comment><comment><USER3> Not Angola, but the cadre of family members and generals that rule the country. It's a daily shame for many of us Portuguese, seeing how our governments grovel to them and keep silent while Portuguese citizens (even if they're also Angolan) are made political prisoners. Our self-respect indexed to the barrel of Brent.

I really hope they can move on, but my Angolan friends (both emigrants and living there) aren't hopeful for the short term.

<comment><USER4> Yes, not Angola, but the select Angolan crony elites which basically bleed the country dry for their benefit, with the blessing of the western world. The same can be said about a couple handful of other African countries as well.

</comment></comment><comment><USER5> Here's a graph of all the political and corporate interconnections, from a popular book and documentary (afaik, only published in Portuguese), called Os Donos Angolanos de Portugal (the Angolan Owners of Portugal).

[https://i.imgur.com/Fb0ZWRG.jpg](https://i.imgur.com/Fb0ZWRG.jpg)

And another one, sans politicians, from a sister publication, Os Donos de Portugal (The Owners of Portugal)

[https://i.imgur.com/NBJHcB7.jpg](https://i.imgur.com/NBJHcB7.jpg)

</comment><comment><USER6> "On her Twitter account, Ms. dos Santos identifies herself with just one word: entrepreneur."

It makes me vomit a little bit in my mouth to hear a super corrupt billionaire, daughter of a guy who has been president in a country for 38 years, calling herself "entrepreneur".

EDIT: she was invited to the London School of Economics to give a lecture. WTF? What's next, Kim Jong Un giving a lecture in democracy?

<comment><USER7> On her Instagram account (linked from the NYTimes article) there's this pic: [https://www.instagram.com/p/BWnuoDFlGC1/?taken- by=isabel_dos...](https://www.instagram.com/p/BWnuoDFlGC1/?taken- by=isabel_dos_santos.me)

What does she use to get that weird, almost photoshopped like effect?

<comment><USER8> The strong front lighting reduces shadows, for example on her face, that normally provide visual clues about the depth of her features (e.g. how large her nose is) this tends to flatten a persons features to a degree as pointed out by rangibaby.

The overall focus in strongly divided into foreground features and very blurred background features. I haven't played around with the ability of the iPhone 7+ to do this blurring algorithmically, but it is very commonly done with SRL cameras by choosing a very shallow depth of field. This is done by using a large aperture, say f2 or f2.8. This wider open lens allows more of the outer, more curved, part of the lens to collect and focus light onto the image, and due to the geometry of the optics this makes the range of the scene that remains in sharp focus much shallower. (See, [https://en.wikipedia.org/wiki/Depth_of_field](https://en.wikipedia.org/wiki/Depth_of_field) .) Notice particularly, the excellent bokeh formed by the blurred lights in the background. ([https://en.wikipedia.org/wiki/Bokeh](https://en.wikipedia.org/wiki/Bokeh))

Finally, a flash combined with a wide open lens can overpower the exposure, a problem for film's limited range of sensitivity (film speed). Cameras can compensate for this by using insanely short exposures, like 1/8000 second, and/or adjusting the exposure sensitivity for a few individual shots (film cameras require changing film rolls to change sensitivity, but today's digital cameras can automatically change the sensitivity on a per shot basis). To me, the picture has a frozen, surreal aspect that can come from a high shutter speed.

All of these effects, which can be done with the appropriate camera settings, can also be simulated with enough Photoshop work. This particular photo could have just been produced serendipitously, especially in this age of unlimited snaps from cell phones that never run out of film, but it looks more professional to me. Consider the careful edge lighting that separates the hair from the background. (See [https://www.slrlounge.com/5-ways-to-separate-your- subject-fr...](https://www.slrlounge.com/5-ways-to-separate-your-subject-from- the-background/) )

</comment></comment></comment><comment> aaron-lebo Kind of crazy just how late it was decolonized: 1975. You don't really think of 20th century Portugal as having remnants of empire.

<comment><USER2> > Kind of crazy just how late it was decolonized: 1975.

Actually it was fully decolonized in 2002.

Independence didn't lead to real independence. Europeans, americans, russians, etc fought over "independent" angola for 37 years after 1975.

The last foreign troops "officially" left in 1989.

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

> You don't really think of 20th century Portugal as having remnants of > empire.

Portugal officially returned macau to china in 1999. Now that is shocking. A small nation of 10 million keeping territory from a nation of 1.4 billion until 1999.

[https://www.britannica.com/topic/Macaus-Return-to- China-3537...](https://www.britannica.com/topic/Macaus-Return-to-China-353703)

Also portugal kept gao from india into the 60s.

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

It's pretty amazing how such a small colonial power stayed under the radar for so long.

Most european empires still have overseas colonies. The french still have colonies all over the world. The british just renamed their the "commonwealth".

And former european colonial powers still exercise power over much of africa, middle east, etc.

[https://en.wikipedia.org/wiki/Northern_Mali_conflict#Battle_...](https://en.wikipedia.org/wiki/Northern_Mali_conflict#Battle_of_Konna_and_French_intervention)

It's now under the banner of "democracy and freedom and etc" rather than to bring "civilization". European colonization just got rebranded. That's all.

<comment><USER9> > The french still have colonies all over the world

They're not colonies if their inhabitants are full French citizens (which they are AFAIK). Are the Hawaii a US colony?

<comment><USER10> Semantically no, but in reality it is. Like many parts of the US, if they hadn't been flooded with American citizens they would have eventually regained their independence.

Not that I think independence is necessarily a good thing.

<comment><USER11> >> Semantically no, but in reality it is.

If you're still including French oversea departments in that statement, then you are out of your depth here, I must say. Do you know people from the French Caribbeans or Reunion? I do. If you had said they feel under-represented, not supported enough by their government (relative to other regions), or victim of racism, you would have been correct. But talks about being 'colonized'? I have basically never heard that. This is not even part of the discussion for them.

This is supported by their local political landscape: independentist-leaning parties are either anecdotical in size, or have changed their position on this topic. Hell, there are more overt secessionist parties on the French mainland itself (Britany, Corsica), which should tell you something.

This is also a weird remark to make, since France is known to still be very much a neo-colonial power that often interfere in their former colonies' politics, and seldom for the better. So if you're looking for nefarious colonialist behaviour, it's there, just not in their oversea departments.

<comment><USER10> No, I wasn't making any remark about French colonies as I was replying to a direct question about Hawaii.

I actually think unification is preferable to independence. Independence mainly seems to benefit the people in control.

</comment></comment></comment></comment></comment></comment><comment><USER12> Portugal is a small country. I did not see any serious investments going on, anything besides their "golden visa" program. A rich guy may invest 500k there to get his residency but serious cash is stored in the UK, Switzerland, Luxembourg, USA. But isn't this the case for most African countries?

OT: A much more interesting woman than Ms. dos Santos, also from Angola: [https://en.wikipedia.org/wiki/Nzinga_of_Ndongo_and_Matamba](https://en.wikipedia.org/wiki/Nzinga_of_Ndongo_and_Matamba)

OT2: Actually most of the oil in Angola is in an obscure enclave: [https://en.wikipedia.org/wiki/Cabinda_Province](https://en.wikipedia.org/wiki/Cabinda_Province)

</comment><comment><USER13> > _"And suddenly they were able to help us and to buy things that we cannot > buy," he said. "It was like a housekeeper buying your house. That is > awkward."_

Good lord. Come on.

<comment><USER14> Yeah I found that statement rather classist/racist

</comment></comment><comment><USER15> This is really interesting, especially in light of all the alleged racism in Portugal.

As far as the corruption in Africa, are there any good books that explain why this is so common in Africa? Is this simply a post colonial pattern that can be found through out human history or is it unique to the recent situation in Africa?

</comment><comment><USER16> Anyone interested in reading more about Angola and the U.S.'s involvement should check out the book "In Search of Enemies" by John Stockwell who was a manager in the CIA, and involved in the Angola operations.

</comment><comment><USER17> > Angola is often listed as one of the world's most corrupt nations. And > Portugal has been singled out for its laxness in reining in money laundering > and bribery...

The end of story.

<comment><USER18> Would you please not post unsubstantive comments to HN, especially on inflammatory topics? This never serves thoughtful discussion, which we're hoping to see in HN threads.

</comment></comment><comment><USER19> And here's yet another major publication resorting to click bait...

</comment><comment><USER20> > late stage capitalism

Much later than the capitalism in most advanced economies ?

<comment><USER7> "late stage capitalism" is a reference to a view that capitalism inevitably leads to a system run by oligarchs. Or something like that - it isn't exactly used consistently[1]. Originally it was a Marxist term, but I don't believe many people use it in this original meaning[2].

It's a pity, because everything else in that poster's comment made sense, I think this detracts from their point.

[1] [https://www.theatlantic.com/business/archive/2017/05/late- ca...](https://www.theatlantic.com/business/archive/2017/05/late- capitalism/524943/)

[2] [https://en.wikipedia.org/wiki/Late_capitalism](https://en.wikipedia.org/wiki/Late_capitalism)

<comment><USER21> Pegging "capitalism" into a teleological historiographic narrative (aimed at justifying non-capital producing collectivist dictatorships) has been around for so long that its retro chic again.

<comment><USER4> That wasn't at all my intention. But nor is it unreasonable to argue that capitalism as it is practiced today cannot sustain itself indefinitely. Nothing teleological or prophetic about it.

<comment><USER21> To my ear that's like saying evolution cannot sustain itself indefinitely. As long as there are generational selective pressures on imperfect replicators, evolution will continue.

Without a superstructure of omnipresent social domination to hinder or disrupt it, capitalism will be used where countable savings for investment and idea that promising accountable returns find themselves together.

Here's a thought to explain my defense of capitalism: capitalism doesn't cause corruption, but like anything else it is destroyed by corruption. Capitalism is used by the corrupt because it is so good at identifying that which the market values and in delivering it.</comment></comment></comment></comment></comment>


Announcing Lightning Loop Alpha: An Easier Way to Receive on Lightning - <AUTHOR> https://blog.lightning.engineering/posts/2019/03/20/loop.html <comment><AUTHOR> This sounds like it will solve the UX problem of being unable to receive payments on lightning when you first create your wallet without finding a friend who will open a channel with you.

Look forward to trying it out!</comment>


Curiosity Rover spots shiny object on Mars surface -photos - <AUTHOR> http://www.repubblica.it/scienze/2012/10/09/foto/curiosity_c_un_oggetto_lucente_su_marte-44174770/1/

<comment><USER2> Oh, man. Curiosity just missed a screw.

</comment><comment><AUTHOR> here in English:

[http://cosmiclog.nbcnews.com/_news/2012/10/08/14300136-mars-...](http://cosmiclog.nbcnews.com/_news/2012/10/08/14300136-mars- curiosity-rover-holds-up-on-its-scoops-to-check-out-weird-object?lite)</comment>


Google ends major OS support for Nexus phones and Pixel tablet - <AUTHOR> https://arstechnica.com/gadgets/2018/03/google-ends-major-os-support-for-the-nexus-phones-and-pixel-tablet/ <comment><USER2> The iPhone 5S is still supported by Apple and was released on Sept 10th 2013 [1] .

The last iPhone to be not supported by Apple was the iPhone 5 released on September 21, 2012 and ended support on July 19th 2017 [2]. They supported it for almost five years.

The Nexus 6P, Nexus 5X, and Pixel C were released on September 29, 2015. [3] [4]. Their software support ends today on March 7th which is slightly more than two years.

[1] [https://en.wikipedia.org/wiki/IPhone_5S](https://en.wikipedia.org/wiki/IPhone_5S) [2] [https://en.wikipedia.org/wiki/IPhone_5](https://en.wikipedia.org/wiki/IPhone_5) [3] [https://en.wikipedia.org/wiki/Google_Nexus](https://en.wikipedia.org/wiki/Google_Nexus) [4] [https://en.wikipedia.org/wiki/Pixel_C](https://en.wikipedia.org/wiki/Pixel_C)

EDIT: I made a mistake in my last statement that I corrected. Thank you child comment :)

<comment><USER3> Yes, it is. It also runs like poop.

<comment><USER4> No, for the animated poop you need iPhone X

</comment></comment></comment><comment><USER5> This is just pathetic. You buy a piece of hardware that could trivially keep working for 5-8 years, and it becomes actively dangerous to use, not just for the owner but to everyone else (think botnets), after 3 years because the vendor stops giving security updates for its software? This should be illegal.

<comment><USER6> > after 3 years because the vendor stops giving security updates for its > software? This should be illegal.

 _Feature_ updates stopped, _security_ updates did not. The phones are still receiving monthly security patches and will continue to do so. Google did not stop those.

<comment><USER7> Security updates "are not guaranteed" after 3 years.

Source: [https://support.google.com/nexus/answer/4457705](https://support.google.com/nexus/answer/4457705)

</comment></comment></comment><comment><USER8> The irony of stopping major OS support for older phones because you introduced yet another layer of abstraction to make major OS support for older phones easier.

<comment><USER9> Yup. And the sadness of being dependent on SoC vendor's kernels/drivers. Basically only Apple is capable of fully supporting their phones, because no one company does as much of their tech stack in-house as Apple. (Samsung is close, but does not really understand software... and I say this stuff as a long-time android-only user, and Samsung employee...)

</comment></comment><comment><USER10> Help me [https://postmarketos.org/](https://postmarketos.org/), you're my only hope.

I don't really know what changed, but I used to be the guy who always wanted the new phone (or <insert really any "device" here>), but ever since I got my 5X I just haven't wanted anything more hardware-wise. I really hope that some of the long-life, open source, replacement OSs for phones take off.

<comment><USER11> Oh man, the 5X was such a piece of junk at the end of its useful time as a phone. I never really liked it, while the Pixel 2 I'm using now I can definitely see myself using it for a bit longer.

<comment><USER12> > end of its useful time as a phone

Huh? My 5X feels like new to me, absolutely love it. Running LineageOS (just upgraded to 15.1 Oreo), never had any problems.

</comment></comment></comment><comment><USER13> There is a comment I remember from slashdot a million years ago after yet another gmail design. I'm paraphrasing, but was something along the lines of, when is Google going to stop redesigning things and just position all the UI elements randomly every time you open gmail?

I'm starting to feel similarly about major Android release.

Just for example, why move the clock? Why? After almost a decade of looking at the upper right, I'm going to have to hunt for it every time I need it.

<comment><USER8> They knew it themselves, even. At one point a favorite pastime of the Android team was counting how many clocks were displayed:

[https://youtu.be/rimXGaUdaLg?t=48m1s](https://youtu.be/rimXGaUdaLg?t=48m1s)

</comment></comment><comment><USER14> For comparison; the iPhone 5s from September 2013 is still receiving updates, and still runs like a charm.

<comment><USER15> I think we also need to discuss how long all these phones were on sale. Sure, if you bought a brand new iPhone in Sep 2013, you're still getting updates.

But if you bought the iPhone 5c (which was sold by Apple until August 2015), you're out of luck -- it is no longer supported by iOS 11.

I don't know how long other companies sell their models, but Apple typically sells every iPhone model for 3 years.

For customers it's not as important how long a model is supported after it was released, but rather how long it is supported after you buy it!

<comment><USER16> This comparison requires context.

\</comment></comment></comment><comment></comment><comment>-----

First, timelines:

Nexus 5X

Released: October 22nd, 2015

Discontinued: October 5th, 2016 - (12 months from release)

Mainstream Software Support Ended: December 5th, 2017 (13 months from discontinuation, 25 months from release)

iPhone 5C

Released: September 20th, 2013

Discontinued: September 9th, 2015 (24 months from release)

Mainstream Software Support Ended: July 19th, 2017 (22 months from discontinuation, 46 months from release)

\</comment><comment></comment><comment>-----

Next, positioning:

iPhone 5c: Bottom of the lineup, released as a budget/$0 contract option in comparison to the rest of the iPhone line.

Nexus 5X: Flagship of the Nexus line. You could argue the Nexus 6P was the flagship, but it's irrelevant as it was also released, discontinued and exited support on the same days. Point is, these were the top-of-the-line Nexus phones at the time.

\</comment><comment></comment><comment>-----

Here is how I see it:

Apple had a reduced support lifecycle for a bottom-of-the-line experimental phone that they never repeated. They typically support a phone for 3-5 years, this one was 2-4 years depending if you count from release or discontinuation date. This was _still_ longer than the support life cycle for the flagship, top of the line Nexus phones, the only Android phones with the reputation and stated goal of offering extended software support. They managed to make it just over 1-2 years.

I don't care how you slice it, that's embarrassing. Even the flagships can't begin to _approach_ Apple's support timeline for their worst and most neglected device. Throw in non-flagships, even from just the major manufacturers, and it just gets depressing. There are phones being sold right now that will never see an update after the customer purchases them. They've exited support before the customer even unwraps them.

I think any way you look at it, Apple is the only company who can be trusted to provide a reasonable support lifecycle, regardless of when you buy the phone.

</comment><comment><USER17> I'm still on my Nexus 5. There hasn't been any phone worth upgrading to, that I'm aware of. If I knew that the Pixel would be so over the top expensive I have upgraded to the 5X at the time it was released but I was hoping that skipping a release would be worth it. I wouldn't mind a Pixel though, I'm just not going to pay $1000+ (AUD) for a phone.

For me the Nexus 5 was the last phone that had a great form factor, good enough features and was sold at a reasonable price.

<comment><USER18> You dodged a bullet with the 5x though with LG's notorious bootloop issue. I bought two, one from amazon for myself and one from google store for my wife. Both of them bootlooped, mine after 12 months and my wife's after 20 months. LG took in my phone for repair and returned it back as is claiming "water damaged" (although I didn't remember getting it wet). Google was gracious enough sending a replacement for my wife's 5x, 8 months after the warranty expired.

I'll be damned if I buy another LG product again in my life.

<comment><USER17> I had a bit of boot loop, sometimes it would restart itself for no apparent reason. There was an issue with the on/off button. I took the whole phone apart and cleaned it out with a big brush. It was full of pocket lint, dust, etc. Even removed the on/off button (which is a fiddly little thing). It had a bunch of gunk on it (probably from my hands, you know, the stuff you'll find on your mouse after a while). Cleaned it out and put it back together. No issues since.

</comment></comment></comment><comment><USER19> This isn't surprising. Google has had their device EOL plans up and public for many moons now: [https://support.google.com/nexus/answer/4457705?hl=en#nexus_...](https://support.google.com/nexus/answer/4457705?hl=en#nexus_devices)

</comment><comment><USER20> My frustration is that you used to be able to buy a used Nexus phone from craigslist, ebay or really anyone and know it was going to be ROMable. Now we have 2 different Pixel phones. The Verizon models and Google models(which have an unlocked bootloader). It has made the resell market an absolute pain. For me the disappearance of the Nexus will be the disappearance of a guaranteed flashable phone

</comment><comment><USER21> I own a Nexus 5X and I'm very satisfied with it. Even the battery is holding up after 2 years of daily usage and loading from <20% to ~90%. While it's sad to see that I wont get Android 9, I'm happy with the Android updates I got for my phone. It never got slower, rather quicker with every update. At least I can count on Google giving me security updates once a month.

<comment><USER22> What do you use your 5X for though? I couldn't get more than 2 hours of video streaming on mine in a single charge and it was less than 1 year old.

<comment><USER21> I regularly watch Netflix on mine and I can get about 3 hours with 90% charge and then have some left over for other stuff.

Maybe it's because I only have about 20 non-Google apps installed, of which are 3 web browsers, 2 are chat apps, 2 CardDAV and CalDAV apps, a better calendar, and Spotify, Netflix, Twitch, and Amazon Video. All Google apps except Maps, YouTube, Calendar, Messages, Camera, and Phone got deactivated. If anything looks like it's using a resource hungry background service it doesn't need, it simply gets uninstalled.

What I did from the beginning to keep the battery in a good shape was to never load over night to 100%. I plug in my phone before showering and eating breakfast in the morning and this loads it up to 90%. But I don't plan my day around charging my phone, even when it sounds like it - when my phone needs charging, I charge it.

One thing I also did, that might impact battery performance: I deactivated animations entirely. They are unnecessary and keep me waiting for things I could do a lot faster. As a side-effect some loading spinners aren't animated anymore and show a static circle shaped arrow but that's okay for me.

</comment></comment></comment><comment><USER23> Title is misleading - should say "Google ends major OS support for Nexus 5x, 6p, and Pixel C"

<comment><USER24> The 6p and Pixel C aren't even 3 years old.

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

People probably bought them 2 years ago.

<comment><USER25> Right - on sale around November 2015? 2 years OS, 3 years security. I actually got a Nexus 6P in July 2017 (under $300 like new). It's a great phone - we'll see how it's running in December when the security updates dry up. Maybe it'll be time to get something else if I'm worried about unpatched security flaws.

<comment><USER26> Android P isn't going to be released until later this year. So if you ignore prerelease builds, these devices will have had the latest OS for about three years after they first went on sale.

</comment></comment></comment></comment><comment><USER27> I have a Nexus 6 (Not 6P) and I'm running Android 8.1! Although it is officially dead, but the good thing about Nexus/Pixel phones is that it is easy to port the new version of android to them (unofficially). My phone works better with the custom ROM than with the stock android! I know the average person won't go through all the trouble to flash a custom ROM on their phone, but this was one of the reason that I bought a Nexus in the first place, the community support at XDA.

Edit: Nexus 6 came to market in 2014. I bought it in 2015 and after years of usage, it has never been faster and snappier. Android 8.1 is quick and it gave my phone a new life.

<comment><USER28> I'm interested in a phone like this for members of my family who are constantly replacing their phones purely for "snapiness". Are there off the shelf vendors where you can buy phones without bloatware, with decent upgrade paths? I would so happily pay for this.

<comment><USER27> I think Google provides the longest upgrade period among all Android phones (Which clearly is not enough). But the good thing about Nexus/Pixel is that the bootloader is unlocked (if you buy Pixel from the Google store not Verizon). An unlocked bootloader enables you to flash cutom ROMs on your phone. For snappiness, most of new phones with Android 8.1 are fast enough. But again, if there is a big community for that phone in XDA (like with Nexus phones), and the bootloader is unlocked, you will be able to flash new versions of Android for a long time.

</comment></comment></comment><comment><USER29> That's beyond pathetic. I purchased a new Nexus 6P from Best Buy in November 2016, and now it's not going to be updated anymore, but my grandmas iPhone 6 (Fall 2014) will be?

</comment><comment><USER30> Why is this a surprise? Google's has shown a pattern that they don't care about your Android hardware since they partnered with HTC and released their first branded phone.

\- Nexus One / Paperweight Owner</comment>


A Pixel Is Not A Little Square (1995) [pdf] - <AUTHOR> http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf <comment><USER2> I imagine this came up partly as a result of the recent alpha compositing discussion.

We desperately need some research, based in user studies and using modern display technology, to settle some basic questions:

* What reconstruction filter gives the best results? Is it the same for vector (text) and natural images? By "best" I do mean contrast (sharpness) and lack of visible artifacts.

* For rendering of very thin lines (relevant to text), what gamma curve gives the perception of equal line thickness across the range of subpixel phase? How does it vary with display dpi? (Hint: it's likely not linear luminance)

* What gamma curve yields the perception of equal width of black-on-white and white-on-black thin lines (also relevant for text)? (Hint: likely not linear luminance)

I've seen a number of discussions where people feel they are able to answer these questions from first principles, and corresponding arguments that doing these in a "correct" way gives results that are less visually appealing than the common assumptions of treating a pixel as a little square (so doing a box filter for reconstruction) and ignoring gamma so effectively using a perceptual color space for the purposes of alpha compositing.

I posit that these questions _cannot_ be solved by argumentation. I think user studies might not be very difficult to do; you could probably get "good enough" results by doing online surveys, though this wouldn't pass standards of academic rigor.

<comment><USER3> I can tell you right now that you will have a very difficult time beating a normalized gauss filter with a diameter of around 2.2 pixels in a general case.

Color and luminance is a separate and orthogonal issue from filtering. I also know that people get away with compositing without converting to linear space, but I'm skeptical that any benefits they see aren't just a matter of getting the color curve they want for free, as opposed to doing a similar correction after something has been composited correctly.

<comment><USER4> I was working at PDI Dreamworks during one of the semi annual investigations into which filter kernel was best. And I was completely blown away by how quickly the lighting sup could identify and react to various filters. Gaussian was voted down reliably and repeatedly for being too blurry.

Personally, I like the extra blur I get (and extra safety and guarantees) you get with Gaussian. Back in the NTSC days I discovered that vertically blurring interlaced video made it noticeably more clear and visible, even though it was softer.

But, If you do really spend time with sharper filters, it is true that Gaussian is softer and some pros really do want sharper images than Gaussian can provide.

<comment><USER3> Were all the filters being compared with the same width? At the same width it will be softer, at a smaller pixel radius is where you can compare aliasing with the same visual sharpness as something like catmull-rom.

<comment><USER4> There were a variety of widths, it was one axis of the study. But I don't remember the details, it is certainly possible you're talking about something we didn't test. Personally, at first I couldn't even see the differences they were discussing.

Having studied graphics and signal processing for a few years in graduate school before that job, I thought I would be good at seeing the differences, and I was a bit shocked how good they were at it, and how not that good I was. :)

Truncating the Gaussian too closely though, and it's not exactly a Gaussian anymore, you lose the best antialiasing properties. I can totally see how it will be sharper and more comparable to other popular filters. (Normalized & truncated at 1.1 radius is just slightly outside the 1 std dev line, right?)

Gaussian is my personal choice for large format prints of images with extreme aliasing problems.

<comment><USER5> My experience has likewise been that film DP's have extremely impressive visual acuity, memory for color, etc. Talented artists often have developed whole sets of skills that the rest of us are unaware are even skills. In the same way a programmer might have thought about cache line false sharing as it affects memory hierarchy throughput, visual art often hides lots of expertise you cannot directly perceive, even as you can sense the quality of the whole.

<comment><USER6> I like to describe "learning to draw" as "installing a 3d modeling and rendering package on your brain, along with a decent collection of base models to modify". It's a _complex_ skill set. If you start animating you get to add in a physics simulation. And you become conscious of so many little things that the layman only notices when you get it wrong.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> A pixel is a picture element. An element of a picture. Hence the name... It turns out that thinking of them as little boxes arranged in rectangular grids is very useful. Because that is how computers deal with them. Not as point samples.

The article reminds me of the many mathematical text I've read insisting on that vectors are not tuples of numbers. That thinking of them as anything other than directions with magnitudes is wrong. Technically, that might be correct but vectors-as-numbers is much more useful when calculating with them. When you get into more abstract mathematics, and your vectors contain other kinds of algebraic objects, such as polynomials, you are already so accustomed with them that you can think of them as flying burritos if you like.

When I teach graphics programming, I will continue to tell students that pixels are like little boxes.

<comment><USER8> > The article reminds me of the many mathematical text I've read insisting on > that vectors are not tuples of numbers. That thinking of them as anything > other than directions with magnitudes is wrong.

I break every mathematical object down into three things:

1\. The intuition. Why do we have this concept to begin with? What underlying idea are we trying to capture?

2\. The definition. These are the axioms.

3\. The implementation. This includes every way to _communicate_ the idea, from natural language words to notation to source code.

Without the intuition, you have nothing but a symbol game. It's hollow. Something with rules and notation but no deeper intuition is, arguably, chess.

Without the definitions, you can't think rigorously about your ideas and you don't know if they lead to internal contradiction. You can dump the axioms without losing the intuition; we did this with set theory at the turn of the previous century, when Russell proved that the previous axioms were inconsistent. We saved set theory without having to abandon the notion, the intuition, of sets entirely.

Without implementation, it's just thought, and you can't communicate with anyone. Moreover, without some intuition, the implementation is meaningless, because you have no cognitive frame to use to interpret it.

So the tuple of numbers is one implementation of a vector. It allows you to communicate some aspects of a vector, but without the underlying idea of what a vector _means_ , what concept we're trying to get across, it's just a list of numbers. They might as well be box scores or something.

<comment><USER9> There's also the case that there's a bunch of vectors you _can't_ represent as tuples of numbers. A vector with orientation but a magnitude of 0 is a completely valid vector afaik, and you could do things with it like normalizing it to get a unit vector of the same orientation, and it's not representable as a tuple.

The tuple model is extremely useful, but incomplete.

<comment><USER10> Vectors with different orientation but the same magnitude are the same vector (the zero vector.) Observe that if you add a zero magnitude vector and a unit vector, the result is just the same unit vector. It follows that the normalization scheme you described can't be a function on vectors (since you can "normalize" two equal vectors but get two different results.)

</comment></comment></comment></comment><comment><USER4> This piece is a classic and a must-read for graphics people, but do remember that this was written before LCD displays. Today's pixels actually are little squares to a much greater degree than CRTs in 1995. That doesn't change the theory or truth in Alvy Ray's paper, but it does mean that the perfect reconstruction isn't the same now that it was then.

<comment><USER11> Heck, if you've written color film recorder software, they're not even particularly square

</comment></comment><comment><USER12> I wrote this on Quora several years ago, answering the questions of why pixels are square (and quickly clarified that I interpreted it as "why are they laid out on a rectangular grid?"): [https://www.quora.com/Why-are-computer-pixels- square/answer/...](https://www.quora.com/Why-are-computer-pixels- square/answer/Rob-Brown-13)

The more I've thought about it since, the more I think we should represent images with hexagonal pixels (i.e., laid out on a hex grid), and that color images should treat the center points of red, green, and blue subpixels as not being right on top of each other. (the third image in the post shows how they would be arranged, which is actually similar to how they are on some displays)

It would be a little harder to deal with for graphics programmers who are working at a pixel level, or at the least, it would require a bit of relearning. But it makes more sense in so many ways. Hex is just a better way of "circle packing" (as you notice if you arrange a bunch of pennies on a table), and of course real world displays tend to have the red, green and blue subpixels offset from one another anyway. (are there any that don't?)

Obviously it isn't easy to change something like this at this point, but still, I find the idea fascinating, and appealing to the OCD efficiency fan in me.

<comment><USER13> You might want to look into pentile displays. You are correct in that they provide higher resolution than rectilinear displays (see the controversy tab in [1]), but they have largely fallen out of style because it is impossible to draw a straight line so everything looks blurry upon close inspection.

One cool trick is that you can sprinkle in more efficient white pixels to allow the display to reduce its power consumption.

[1] [https://en.wikipedia.org/wiki/PenTile_matrix_family](https://en.wikipedia.org/wiki/PenTile_matrix_family)

</comment></comment><comment><USER14> This is very relevant for image reconstruction for medical imaging systems. When determining how much a beam of radiation is attenuated through an image, it really matters what the representation you use when translating a 2D matrix of values of material parameters, to an image representation. Are they boxes, trapezoids (bilinear interpolation), 2D gaussians, spheres? Each technique has some drawbacks, but for getting down to millimeter precision in scans it matters.

</comment><comment><USER15> Some previous discussions:

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

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

</comment><comment><USER16> The same is true for digital audio.

We are so used to see the visual presentation of samples that look like a bar diagram, that a lot of people think analog sounds better because the curves are smoother.

Chris Montgomery has a great talk about this.

<comment><USER17> >We are so used to see the visual presentation of samples that look like a bar diagram, that a lot of people think analog sounds better because the curves are smoother.

Except for a philosophical debate about continuity, isn't that true?

<comment><USER18> [http://productionadvice.co.uk/no-stair-steps-in-digital- audi...](http://productionadvice.co.uk/no-stair-steps-in-digital-audio/)

 _The "stair-steps" you see in your DAW when you zoom up on a digital waveform_ only exist inside the computer. _[...] When digital audio is played back in the Real World, the reconstruction filter doesn't reproduce those stair-steps – and the audio becomes truly analogue again._

<comment><USER19> Yeah, it's strange people are thinking the display of a spectrum analyzer is somehow 1:1 with the underlying thing which they are measuring. As if a digital clock with only the hour and minutes displayed implies that seconds don't exist.

</comment></comment></comment></comment><comment><USER20> A great video which touches on this idea, but mostly in the context of audio: [https://youtu.be/cIQ9IXSUzuM](https://youtu.be/cIQ9IXSUzuM) (relevant part around 8 minutes)

<comment><USER2> Be careful generalizing the audio results to pixels. The central lesson of xiph's work is that people simply cannot hear frequencies above, let's say 20kHz. Therefore, as long as your sampling rate is above the Nyquist limit (and under the assumption the signal chain is linear), any reconstruction filter that passes frequencies through 20kHz is effectively "perfect."

There are two ways this is not true for pixels. First, even for "retina" displays the human visual system can make out spatial frequencies beyond the Nyquist limit of the display (this will vary by viewing distance, so is more of an issue for young people who can get close to their displays). Second, even assuming perfect gamma, the display must clip at black and white because of physical device limitations. Thus, especially for text rendering, only a reconstruction filter with nonnegative support is generally useful. Such a reconstruction filter would be an extremely poor choice for audio.

It is true that many of the underlying signal processing principles are the same, and I encourage people to learn and understand those :)

<comment><USER20> Thanks for the heads up. There is one specific section where he compares pixels to lollipop graphs and that is mainly what I was referring to, I didn't mean to suggest that all the principles in the video apply to graphics in the same way that they apply to audio.

</comment></comment></comment><comment><USER21> However, image is not a wave. Sampling theorem applies beautifully to audio, but only to a limited degree to images. Some filters make sense in frequency domain, eyes are sensitive to certain frequencies more than others, but it all breaks down on hard edges, which don't behave like square waves.

The problem is that in images the Gibb's effect is visible and annoying (ringing artifact). If sampling theorem applied, people wouldn't be able to see it, like they can't hear the difference between square waves shifted by a half of a sample.

<comment><USER22> This is mostly only true because our display technology lacks the resolution to reliably saturate the visual system in the same way that our audio technology does.

</comment></comment><comment><USER23> Well, it's an overloaded term (like pretty much every term in software development).

But there's good information in this article. In many contexts you should be thinking in terms of point-samples, not squares or other areas.

I think it's not such a great idea to try to simplify the definition of pixel in this article because it distracts from the useful info.

</comment><comment><USER24> > [title repeats 3 times]

> rid the world of the misconception that a pixel is a little geometric > square.

> The little square model is simply incorrect. It harms.

> I show why it is wrong in general.

Why the bluster?

He makes a decent case for this point in the domain of graphics processing; what he calls "correct image (sprite) computing".

But the narrow focus on computer graphics undermines these broad generalizations. There are many other domains that can be represented in pixel-based data models. Climate, terrain, population and land cover mapping are just a few domains where the use of a pixel as a "little geometric square" is a perfectly viable approach.

Ultimately, if the message is "think about how your data model maps to reality" \- I agree. But why the hyperbole? Why shit on an entire model because it doesn't fit for your very specific use case?

</comment><comment><USER25> Pixel and voxel are not commensurable. A pixel is a display hardware concept. A voxel is more comparable to a texel.

[https://en.wikipedia.org/wiki/Texel_(graphics)](https://en.wikipedia.org/wiki/Texel_\(graphics\))

Texels and Voxels _can be_ square/cubic, such as in video game applications where it is accepted and exploited as a fundamental esthetic: worlds are textured with tiled mosaics which reveal their square unit when approached closely, and ditto for worlds made of voxels.

A voxel as a sample of a solid, for instance from a computed tomography, where the fidelity of the reconstruction matters, is subject to different requirements.

<comment><USER26> Both the word "pixel" and the word "voxel" are commonly used in both of these different senses. I believe the word "voxel" was created to be explicitly a 3D analog of a 2D "pixel".

For example, you can also have "pixel art", drawings made up of little squares, which only loosely have to do with pixels as samples for a raster image or physical camera detector elements or physical display elements. [https://en.wikipedia.org/wiki/Pixel_art](https://en.wikipedia.org/wiki/Pixel_art)

</comment></comment><comment><USER27> A pixel is basically a little square dude, come on.

<comment><USER3> No, your pixels are displayed using little squares (sort of).

</comment></comment><comment><USER28> I remember the fanfare & hoopla around the introduction of the IBM PS/2 featuring square pixels. Made computing shapes much easier.

</comment><comment><USER29> Of course not. It's a little teacup.

</comment><comment><USER30> > A Pixel Is Not a Little Square! Microsoft Tech Memo 6

is this the reason why they forced this horrible bilinear filter on the windows image viewer for so long (guess they still do) ? It made me crazy, it's so ugly

<comment><USER3> No, this was written by Alvy Ray Smith 25 years ago in response to incorrect filtering in computer graphics in general. This has nothing to do with whatever you are seeing.</comment></comment>


Let's Encrypt now supports issuance for Internationalized Domain Names - <AUTHOR> https://community.letsencrypt.org/t/idn-support-enabled/21469 <comment><USER2> Off-topic but the auto-renewal tools are so nice, combined with a chron job and nginx reload, I would always prefer Let's Encrypt over alternatives.

</comment><comment><USER3> See also: [https://news.ycombinator.com/item?id=12760984](https://news.ycombinator.com/item?id=12760984)</comment>


New Job Fear – You are not Alone - <AUTHOR> http://nyghtowl.io/2013/09/22/new-job-fear-you-are-not-alone/ <comment><USER2> This sounds similar to imposter syndrome [http://en.wikipedia.org/wiki/Impostor_syndrome](http://en.wikipedia.org/wiki/Impostor_syndrome)</comment>