Storm 2.0 - <AUTHOR> https://storm.apache.org/2019/05/30/storm200-released.html <comment><USER2> Salient line:

 _While Storm 's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more accessible to developers who don't want to learn Clojure in order to contribute._

Very common story that I hear from a lot of shops that tried to go Clojure first. Great language, but too little penetration amongst developers. Makes it very difficult to effectively recruit employees/contributors.

At some point, you just accept that it's more important to get a new warm body than to continue pursuing some idealized programming perfection.

<comment><USER3> This is salient too though:

 _The new Java-based implementation has improved performance significantly, and made Storm 's internal APIs more maintainable and extensible._

It's not totally clear if this is _because_ it's been rewritten Java, but the intrinsic qualities of the language do matter; there are real tradeoffs between maintainability and dynamism/flexibility. I feel like this sometimes gets shortchanged in these narratives.

<comment><USER4> Idiomatic java is like idiomatic C: pretty fast. Most smaller languages prioritize other things. Clojure has immutability and Haskell has purity.

I have noticed this with every "X produces code faster than C": you begin with two programs that use a suboptimal algorithm, then you take your non-c language and try to write C in it. The result is always awful and removes most reasons not to use C in the first place.

This has somewhat changed with rust and in some sense C++,but for other languages my point still stands. They have a nice idiomatic golden path that is fast enough for most cases. Once you need performance badly enough you have to treat you language as an assembler, and then you will always lose to languages that actually are good at that.

I say this as a scheme/Haskell weenie. Writing really performance scheme and Haskell code often means writing ugly code.

<comment><USER5> Kotlin generally is not slower than Java. One exception is that it inserts a lot of null checks. And there are features that will make it even faster than Java, I'm talking about inline lambdas.

<comment><USER6> The compiler is significantly slower than Java's, though.

<comment><USER5> That's the sad truth for a lot of modern compiled languages (I think Go is an exception). While I did not dig into their compiler internals, it just seems an inevitable consequence from a powerful language (Go is pretty simple in that regard). C++, Rust, Scala, Kotlin, Swift, they all have significantly longer compilation times compared to their predecessors. Probably that's the price we have to pay.

<comment><USER4> Chez compiles a 80Kloc project of mine in less than a second, and apparently that is still 2x slower than before they switched to a nanopass compiler.

There is no reason compiling things should not compile at similar speeds to chez unless you are telling your compiler to ootimise everything.

C++/ruae are just exceptionally slow and it became the new bottom line somehow. I know rust does a lot of housekeeping, but after using chez and sbcl, 45s for a 1.5kloc project is killing me inside.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> To me, this makes total sense as the project moved to Apache. Obviously, much more people will be able to consider contributing when it's in Java. Apache goal is sustainability and long-term viability, and Java would work better for that.

I also consider this a success story for Clojure. It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years and benefit thousands of developers until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.

<comment><USER8> I think it's noteworthy that whatever the benefits of clojure it didn't outweigh the adoption issue.

It's quite a mature language so I'm not sure that bodes we'll for its prospects this late in the game.

<comment><USER9> A Java shop inherited a Clojure project and rewrote it in their preferred language. It's silly to read more than that into this.

<comment><USER8> I'd agree if it didn't keep happening .

<comment><USER10> Rewrites between languages keep happening in all kinds of permutations. I think pessimism or optimism from just headlines and announcements is more about what you read into it.

<comment><USER8> It reminds me of the "why we switched from Mongo to X" or "why we switched from Ruby to Y" trends some years ago.

I saw Clojure become popular long before it was ready for the limelight: it definitely wasn't pragmatism driving it. It was a fetish for syntax and paradigm.

</comment></comment></comment></comment></comment></comment><comment><USER11> It is interesting to read the history of Storm from the original author (Nathan Marz) himself: [http://nathanmarz.com/blog/history-of-apache-storm- and-lesso...](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons- learned.html)

Clojure allowed him to build the initial Storm release by himself in only 5 months.

> I made all of Storm's APIs in Java, but implemented Storm in Clojure. By > keeping Storm's APIs 100% Java, Storm was ensured to have a very large > amount of potential users. By doing the implementation in Clojure, I was > able to be a lot more productive and get the project working sooner.

Also interesting is that Nathan has now founded a startup working on something which sounds like the next evolution of Storm, and he's building it in Clojure again:

[https://redplanetlabs.com/](https://redplanetlabs.com/)

They recently got 5M in funding and are hiring. Building a Clojure team for it.

Personally, I feel the Storm 2.0 release rewrite to Java is really just a case of the new maintainers not knowing Clojure very well, and being primarily Java devs, looking for contributions from people using Storm, which tend itself to be mostly Java shops. Clojure is not quick to pick up, and very different from Java, so unlike Scala, Kotlin, C#, Go, etc. Someone with a Java background and no Clojure or Lisp experience won't be able to contribute as easily. And that's fine, and possibly best for Storm's future now that Nathan has moved on. Unless a Clojure dev had stepped up and adopted Storm, this change isn't at all surprising.

</comment><comment><USER12> I struggle to see how you pick Java over Kotlin on the JVM these days. It's everything that Java is, minus everything Java shouldn't be, plus everything that Java should be.

<comment><USER13> Syntactic sugar does not solve programming problems. Kotlin does not offer any paradigm changes which could make switch worth it.

<comment><USER5> The only Kotlin feature that it's really hard to live without is properties. Otherwise sure, it's better than Java 11, but I can live without all those niceties. And (non)nullable types even get in my way!

I just don't understand where there's syntax sugar for propeties in Java. There are lot of unneeded stuff added, that I don't really care about. But my classes are still full of autogenerated getters/setters. I recently tried to find some JEP and I did not find one. There was some talk around Java 7, but nothing since that. Nobody even wants to add properties support for Java?

<comment><USER14> Probably because in general they are a code smell. They are anti-OO.

<comment><USER5> That's just not true. If I'm writing simplest REST service, I have to return JSON responses. To return JSON response, I have to write class corresponding to that response. And that will be data class. If I'm interacting with database, I'm writing data mapping classes. And that will be data class. Those are normal code that every developer writes every day. If you think that it's anti-OO, then I don't care about that OO. I care about writing performant, concise and extensible software.

<comment><USER13> That statement is valid in both contexts you mention. You do not need properties for data mapping and serialization - it's possible to write a good OO code without getters and setters.

</comment></comment></comment></comment></comment></comment><comment><USER15> _" While Storm's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more accessible to developers who don't want to learn Clojure in order to contribute."_ \- interesting phrasing. Seems that the authors assuming that new contributors are more willing to learn Java instead of Clojure. And those who know Java find Clojure difficult to learn? Clojure, in fact is quite easy to grasp - especially for someone coming from Java, as you would still be working on JVM and always have Java Interop. I guess same thing goes to someone coming from Erlang to Elixir, where you are still working in the familiar ecosystem.

<comment><USER16> > Clojure, in fact is quite easy to grasp - especially for someone coming from > Java

I disagree on that point. In my experience as a programming language teacher, people often struggle to learn functional programming and even more to learn a Lisp, especially if they are used to a C-like language. And learning both at the same time is even more difficult. I liked working with Clojure but I have yet to meet someone who easily grasps the language and - more important - development patterns.

<comment><USER17> Hello, this is an interesting take. Clojure has been a hobby of mine for some time but now I am a professional Clojure developper (clj/cljs). I knew the language before starting my new job but I found it really different than know the "platform": how a project is layed out, tests are written, some libs, how to pinpoint potential technical debt/suboptimal code accurately and so on... But I guess this would have been true if I had transition to any other new language.

Would you have any example of what your trainees stumbled upon or found difficult in the language? That would be useful I guess when we try to onboard new people on the project.

Have a nice day :)

</comment></comment></comment><comment><USER18> Apart from the language part , i am super excited about trying storm-2.0. In many ways the buzz in the ecosystem has been that storm was dead!. We run lot of prod workloads on storm and spark , storm has worked like a wonderful workhorse without quirks. The ecosystem has moved on , but i think storm may still continue having loyalists!

<comment><USER19> > The ecosystem has moved on

Just ouf of curiosity, what tools are people using instead of Storm?

<comment><USER20> Flink is a strong competitor. Spark itself also claims to be a runner up with minibatching.

But streaming model is more widely adopted outside of frameworks. AWS Lambda or Fass platform can be viewed as streaming model with simple topology.

</comment></comment></comment><comment><USER21> Clojure just seems "too weird" to too many people, albeit for all the wrong reasons. Its syntax looks like a 6ft hurdle to newcomers, especially if they have lots of experience in C-synthax-languages. But anyone who just /tries/ to jump it finds out the hurdle really isn't that high at all.

This dynamic will probably never change. Clojure will remain an acquired taste, which is fine, I guess. Those 'in the know' will happily continue to develop effectively with it.

</comment><comment><USER22> Bet they had to reimplement half of Clojure when rewriting storm core.

<comment><USER23> Yep, at last a lot of progress to report to Apache Board of Directors

</comment></comment><comment><USER24> In this thread:

* Non-Java JVM languages are too different for people to use.

Also:

* It's not worth switching from Java to other languages because they're just Java with syntactic sugar.

<comment><USER25> Clojure and Kotlin are two very different languages. I don't see anyone making the broad statements you are calling out.

<comment><USER24> No, of course not.

I misread

> Syntactic sugar does not solve programming problems. Kotlin does not offer > any paradigm changes which could make switch worth it.

and

> Also, java 8 and above is getting a lot leaner to use, api, linguistics .. > so the gap with clojure is a bit less than before.

</comment></comment></comment><comment><USER23> Apache products have always been a result of a blind majority rule, and thanks to that many of them are a corporate-style incomprehensible mess. They favor the process instead of a result: Apache things need to show constant progress to be afloat.

Indeed, adopting Clojure for the developer product of this style is a dead end. Clojure is a minority rule. A slow tinkerer's and a lazy (in a good sense) practitioner's tool, whose aim is to survive in a real world, not to show a steady movement no matter what.

<comment><USER26> These Talebian references got me thinking. Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools" detachment from reality to use Clojure instead of good ol' Java?

<comment><USER27> > _Couldn 't you argue that it shows a certain arrogance and non-results > oriented "falling in love with ideals and tools" detachment from reality to > use Clojure instead of good ol' Java?_

Since when trying to do better than using a tool designed for mass-producing software with dumb and cheap labor is "falling in love with ideals and tools"? It's kind of like saying that using an excavator over a bunch of people with shovels is "falling in love with ideals and tools". No, it just allows a single person to get more work done faster and better.

Our industry is weird. When recruiting, companies claim they want "the best of the best" and will often test you on ridiculous stuff. But when it comes to actual work, on industry scale, learning, growing professionally, and doing things in a clean and efficient way is frowned upon. Best take the weakest tool available and compensate for its shortcomings with third party services.

<comment><USER28> > trying to do better than using a tool designed for mass-producing software > with dumb and cheap labor

This is completely disregarding the available developer pool of Java programmers, and the fact that a lot of them are really talented and can write efficient, production ready software.

The fact is, there is at least an order of magnitude more developers to choose from compared to Closure, and hiring and replacing people is hard. Ignoring business realities like this is bad, and akin to "falling in love with ideals and tools".

Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth. It's possible to write bad FP code as well.

<comment><USER27> > _Also, someone using Java does not automatically make them dumb cheap > programming labour, same as someone using Closure is not automatically going > to be a 10xer who has memorised Knuth._

I'm not claiming that. I'm claiming that Java has a long history of enabling factory-farming software development, whereas Clojure doesn't lend itself to this style. I mean that in the sense that an army of cheap labor with shovels _can_ , in principle, do the same job as a few trained operators in construction machines. The physics of dirt is the same, and so the job done is essentially the same - just some tools let you do it faster with fewer people. And then, the quantity (or lack of it) has a quality of its own - the more people you engage doing smaller and smaller pieces of work, the more your work becomes about coordinating people than doing the actual job.

(I'm aware that since version 8, Java is growing to be a quite decent programming language. This somewhat weakens my criticism, but not all that much.)

But yeah, I'm also claiming that ceteris paribus, the pool of Clojure developers will yield you higher-skilled programmers on average than the pool of Java programmers - simply because everyone and their dog knows some Java nowadays, and some Java is enough to make some progress in factory-farming software development, whereas Clojure is somewhat atypical and requires expanding your competences beyond the very basics.

(Or, in other words, I'm claiming that the distribution of skill of Java programmers is wider than that of Clojure programmers, with the latter having higher minimum and mean values, and comparable max values.)

<comment><USER29> Does Clojure lend itself idiomatically to _any_ style other than quick-and- dirty prototyping, though? There are real benefits to many features of Java when it comes to long-term maintainability, even though it also has some very real pitfalls at the same time (no optional values, no variant records with pattern matching, no composition-plus-delegation-over-inheritance etc. etc.).

<comment><USER9> Yes, it absolutely does. My team has projects that have been running for many years in production. They're far easier to maintain than equivalent Java projects we've done before. And there are plenty of companies, like Circle CI, who built there stack on Clojure out there. Here's a talk from Kira Systems who went from a quick and dirty startup to a 150 employee company in 8 years using Clojure: [https://www.youtube.com/watch?v=u-4FiFpkPlQ](https://www.youtube.com/watch?v=u-4FiFpkPlQ)

<comment><USER30> Considering Kira Systems had to resort to using Go for much of their heavy lifting, due to Clojure immutability memory overhead, I would hardly concur that this is a shining example of the benefits of using Clojure.

<comment><USER9> Over 80% of their codebase is in Clojure, but obviously it's providing them no benefit.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> poor lisp, just like reddit ... always dropped for another language.

<comment><USER32> The SW world is full of Java/C++ rewrites of products that originally started out in a dynamic & productive language like Lisp or Python. It might make sense in the lifecycle phase when you're past making big changes under make- or-break pressure, and are in the "provide predictable 10 year maintainance roadmap for this large codebaes" stage. You end up employing different kinds of programmers too because many of the original team may be reassigned to something more exciting/important to do.

But it's in no way inevitable, of course, there are many old Lisp, Python, etc codebases in production too.

BTW. I've been trying to rediscover this blog post and can't seem to find it again, anyone? It described different kinds of software projects, the (1) kind that try to deliver incremental improvements (eg 10% cost savings), and the (2) kind that try to make 10x improvements, and the difference in how those projects are run (the 1-type project can't go over budget because it will then deliver negative value etc).

<comment><USER29> Hopefully we'll start seeing some Rust rewrites in the future then, since the pitfalls of C++ are widely-known by now, and few people would claim that they _don 't_ impact long-term maintainability. (And the Rust Evangelism Strike Force would surely approve of such a shift!)

<comment><USER33> If Rust Evangelism Strike Force volunteers to rewrite code in Rust instead of heckling original developers to do it they may prove themselves to be more productive and useful.

</comment></comment></comment></comment><comment><USER34> > While Storm's Clojure implementation served it well for many years, it was > often cited as a barrier for entry to new contributors. Storm's codebase is > now more accessible to developers who don't want to learn Clojure in order > to contribute.

It is interesting to contrast this with state of affairs in Apache Spark. Spark has thrived well in spite of being a Scala project; Scala arguably has a higher barrier for entry compared to Clojure (although the flavour of Scala used within Spark closely resembles Java).

</comment><comment><USER35> In the old days a project would often start in Lisp (Common Lisp for example), and then later be rewritten in C.

This is the same pattern, and one should embrace it. Write the first cut, explore the problem space and prototype in a dynamic language. Once the design is proven, rewrite in statically typed language for performance and to get the possible remaining bugs out.

If the design was perfect from the get go, you could just write it in assembler to start with.

</comment><comment><USER32> For anyone interested in the Clojure history, there's this interview of Nathan Marz, originalcreator of Storm, from 5 years ago: [https://www.infoq.com/interviews/marz-lambda- architecture/](https://www.infoq.com/interviews/marz-lambda-architecture/)

</comment><comment><USER36> While most comments touch on the developer issue, the significant performance gain deserves more discussion. I guess Java's static type, pragmatic mutability with less garbage produced, and efficient parallelism give substantial boost to performance.

It would be interesting to see what the upcoming blogs have to say about the performance gain.

<comment><USER9> My guess would be that it's always easier to make a rewrite performant because you already have a working version and know exactly where bottlenecks are. I imagine rewriting it in Clojure, or any other language, would've resulted in a significant performance boost as well.

</comment></comment><comment><USER37> Sad to see it happen, however it is yet another example how platform languages always win in the end, even if due to their nature and market size they tend to be more conservative regarding feature adoption.

<comment><USER25> I dare say it may be _because_ they are more conservative regarding feature adoption.

</comment></comment><comment><USER38> > While Storm's Clojure implementation served it well for many years, it was > often cited as a barrier for entry to new contributors. Storm's codebase is > now more accessible to developers who don't want to learn Clojure in order > to contribute.

While I appreciate that programmers have limited free time and may not want to learn a new language to contribute to open source, I feel like learning Clojure could be of value to the programmer in itself.

The supposition that Clojure acts as a big barrier against contribution from developers might be true, but I really feel like developers who only write code in the ALGOL family of languages are missing out. Learning a lisp language is not an impossible task and can improve your skills as a developer.

</comment><comment><USER11> Can someone enlighten me on the inner working of Apache?

Do they hire developers to maintain and work on the projects? If not, is there community leads in charge of each one? How are they appointed?

<comment><USER33> [http://www.apache.org/foundation/governance/](http://www.apache.org/foundation/governance/)

<comment><USER11> Interesting, where would you go to see the list of committers for a given project and find information about them?

I'm curious if the commiters are Clojure developers who chose to switch to Java, or if they are Java devs who decided to rewrite the project to a language they are more familiar and comfortable in. Or if they are Clojure devs looking to transition the project to other commiters and they struggled to find other Clojure devs willing to take it over.

</comment></comment></comment><comment><USER39> We did the same with our open source project. We ditched Clojure and Clojurescript for NodeJS and JavaScript, for the same reason as it was a huge barrier to entry for new users

</comment><comment><USER40> How am I just learning about this? This seems to be rather novel. Real-time bolt on for any database? Pretty cool stuff.

</comment><comment><USER41> How does this relate to Apache Heron? I thought Heron was essentially Storm 2.0. Which one should I be using?

<comment><USER42> Not well known is that Heron's performance claims in the "flying faster" blog and SIGMOD paper were made by comparing against a fork of an older (pre apache) version of Storm even though much more performant version was already out.

IMO (biased?) Heron makes surprisingly poor design choices for their key distinguishing features like threading model and backpressure. And it shows when you benchmark it. More specifics: [https://github.com/apache/storm/pull/2241#issuecomment-31787...](https://github.com/apache/storm/pull/2241#issuecomment-317879907)

</comment></comment><comment><USER43> If you're going to be on the JVM, stick to what the J stands for :)

<comment><USER44> The newest JVM out of Oracle, GraalVM, has its polyglossy as its central feature. And Clojure has always been a lot closer to Java (in terms of quality of interop) than even e.g. Scala, let alone something like Jython. (Notable exception JRuby.)

</comment></comment><comment><USER45> What exactly are you doing?

</comment><comment><USER32> cutting off 1.0 immediately sounds quite harsh, I wonder what kind of user base it has?

"EOL for 1.0.x With the release of 2.0.0 the 1.0.x version line will no longer be maintained."

<comment><USER46> > It is designed to push boundaries on throughput, latency and energy > consumption _while maintaining backward compatibility_.

</comment></comment><comment><USER47> DISCLAIMER: I'm one of PMC member of Apache Storm.

Even though Clojure has been Nathan's first-class language, not everyone in contributors and even committers couldn't become native on Clojure. (Though I guess part of committers could feel Clojure as native.) It might not be a problem when Nathan builds most of things in Storm (I'll link his blog post which describes lesson learned from Storm on his perspective [http://nathanmarz.com/blog/history-of-apache-storm-and- lesso...](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons- learned.html)), but when Storm becomes popular and also no longer his toy project, Clojure matters for scalibility of the project.

Personally, I had a hard time understanding plenty of macros and even chained macros - that might not be a problem if I were allowed to have plenty of times to study Clojure and get used to it, but possible contributors don't get a chance when they're ready. In many cases, the first time they read the code on what they're using is when they encounter issues on stage/production and have to dig with stack trace. For me, I had to investigate on Storm because my team suffered from lack of documentation and also lack of knowledge on internal which ended up just taking workarounds. It was pretty hard time learning language to just read and understand the details to track down the issue. I even couldn't think of writing code on Clojure.

When I decided to contribute Apache Storm, I started from connectors and CI build which wasn't written on Clojure. After some months I was able to read and understand the code to get into details but I still couldn't be native for Clojure, so still required N times of efforts to read and write the code even after I became one of PMC member.

Don't get me wrong. I'm not saying something is better than some other one. In scalability point of view on project, I guess we had to do this, even though it ended up teaching me some lesson that migrating language is not the thing which can be considered easily, especially for a big project. Lots of efforts were spent here.

Someone could claim for Apache Spark's case for Scala. Yes, I'm also contributing to Apache Spark and I had to learn Scala (fortunately I had a chance to do that before contributing) but the case is different. If you read Databricks Scala guide in details, you might realize that the doc is actually not encouraging contributors to use advanced features (a.k.a the features only Scala geeks might feel natural) on Scala. Same goes on reading codebase. Apache Spark community has been trying to keep necessary knowledges on Scala to contribute Apache Spark low enough, so that non-expert of Scala engineer could easily try out contribution. If they have been requiring hard understanding of Scala to accept contributions - Spark may not be able to get its amazing reputation.

</comment><comment><USER48> Why change the title of the post?

Almost every one of the ~100 comments is in response to the original title that Storm switched from Clojure to Java. Now this context is lost.

<comment><USER44> Because the previous title was editorialized? Furthermore, perhaps the conversation is about the old title because it was, and now the conversation can go be about Storm itself :)

<comment><USER48> I think the rule about not editorializing needs an exception so that someone can point out an important or interesting fact using an article whose original title is too generic.

Another example would be "Press release from XYZ". If it talks about XYZ reaching some major breakthrough, the title should be allowed to reflect that. It's a waste of everyone's time to post the article titled "Press release".

And arguably this situation should fall under such an exception.

</comment></comment></comment><comment><USER49> Java is statically typed. Clojure is not. To me, this is the biggest difference and the reason to choose Java.

<comment><USER50> Is this true or false? I don't understand the downvotes.

<comment><USER51> While it is true that Java is statically typed and Clojure is dynamically typed it is perhaps one of the less important differences between the two languages. If you in fact would like to add a static type system on top of Clojure there is a way to do that: Typed Clojure.

[https://typedclojure.org/](https://typedclojure.org/)</comment></comment></comment>


Better SQL joins in CockroachDB - <AUTHOR> https://www.cockroachlabs.com/blog/better-sql-joins-in-cockroachdb/ <comment><USER2> I always enjoy these insights into how they are building Cockroach DB.

Could you imagine having this level of detail laid out during the development of postgres or mysql?

<comment><USER3> design documents within the repo itself (under docs/RFCs [0]) actually do well to capture some of the past implementation details/rationale and future directions CockroachDB is planning to take. in my (very biased) opinion they've gone out of their way to keep everything as transparent as possible.

[0] - [https://github.com/cockroachdb/cockroach/tree/master/docs/RF...](https://github.com/cockroachdb/cockroach/tree/master/docs/RFCS)</comment></comment>


Things We Hate About Email - <AUTHOR> http://avc.com/2014/05/fun-friday-things-we-hate-about-email/ <comment><USER2> I dislike not having an easy mechanism to remind myself which outgoing messages require a response (so I can send reminders). My mental accounting says that I've done my part as soon as I respond to an email, but I would like to have something to ping me (or give a list of pings) when I don't have responses yet. I have to believe this already exists somewhere.

</comment><comment><USER3> Please replace Email by Gmail on your statement. If your e-mail tool can't help you to get organised, I think is not e-mail's fault.

E-mail was a complex and then insecure messaging protocol. Google built a tremendous tool around it to cover up much of the 90's mess to the every day user.</comment>


Ask HN: Most productive functional languages? - <AUTHOR> Which functional language are you most productive in?
We're in the process of choosing a primary language for our backend systems at a new venture. A few we're considering: Haskell, Clojure, OCaml, Elixir, F#, Scala.
What's a reasonably productive choice for a new startup? What would you choose if you determined a functional language mapped well to the objectives you were trying to accomplish? <comment><USER2> I'm in the same boat as you.

Right now for the frontend we selected Elm.

Now for backend I've been playing with

Elixir and Haskell

Elixir has the nice syntax of ruby with all the performance of Erlang. So that makes it a good candidate however what I don't like about it is: \- it isn't strongly typed... and once you get used to types and all the bugs it catches you can't go back. \- although variables are inmutable they behave as if they look a lot like mutable state and I don't want to lose that warranty either.

Then there is Haskell. Haskell is great until you need to do IO. And 80% of the webdevelopment is IO... either to the database, to an API or HTML... and all the current options seem overly complicated. I tried haskell with Servant which gives strong type to an API but the syntax is ugly Used Scotty (like ruby's Sinatra) but then the URLs are strings and when definning APIs you can't specify the types. Then I tried with Yesod I don't like such heavy frameworks and try to avoid Template Hasell...

So I continue to search....

Next in my list consider is FSharp and OCaml

<comment><AUTHOR> Very interesting! I've been using Elixir on a smaller project and have been quite impressed. It just feels friendly and palatable, while also being quite powerful for highly concurrent workloads.

Agreed on the typing, however.

<comment><USER3> _Agreed on the typing, however._

Have you guys looked into Dialyzer?

 _Dialyzer is a static analysis tool for Erlang and other languages that compile to BEAM bytecode for the Erlang VM. It can analyze the BEAM files and provide warnings about problems in your code including type mismatches and other issues that are commonly detected by static language compilers. The analysis can be improved by inclusion of type hints (called specs) but it can be useful even without those. For more information I highly recommend the Success Typings paper that describes the theory behind the tool._

That's from the Dialyxir (for using Dialyzer w/Elixir) github page: [https://github.com/jeremyjh/dialyxir](https://github.com/jeremyjh/dialyxir)

More: [http://learnyousomeerlang.com/dialyzer](http://learnyousomeerlang.com/dialyzer)

(Perhaps this should be read first: [http://learnyousomeerlang.com/types-or- lack-thereof](http://learnyousomeerlang.com/types-or-lack-thereof) )

And this is the Success Types paper behind it (mentioned in the excerpt above):

[https://www.it.uu.se/research/group/hipe/papers/succ_types.p...](https://www.it.uu.se/research/group/hipe/papers/succ_types.pdf)

<comment><AUTHOR> I was just reading about it today. Awesome!

</comment></comment></comment></comment><comment><USER4> Interesting blog post describing the choice to go with OCaml: [http://techblog.arena.io/2016-12-04_Risky_Libraries/](http://techblog.arena.io/2016-12-04_Risky_Libraries/)

To that post I would add that the OCaml -> JavaScript compiler, BuckleScript, now gives you access to the entire npm package repository, so it's not such a big risk any more as it was for them at the time.</comment>


Ask HN: What is your strategy for personal blog, for getting work? - <AUTHOR> Lets say you have multiple skill sets (product development, some languages, devops etc) and you're looking for work, using your blog to get clients. What would be your strategy? Do you blog about all those skill sets in the same blog, or create one site per skill set?<p>Anyone using some strategy like this to get clients? <comment><USER2> If you work on the intersection of the fields, blog about the intersection. You'll get less but more qualified leads.

If you work on the union, I'd personally blog just about the fields that gets you more money, and then try to upsell the other services.

Blogging about more than one seems the best way to waste as much time as you can to get a single lead.

InterimCMO.co is an example of company that I know and is pretty successful in getting leads from blog posts (and now articles).

</comment><comment><USER3> I would suggest writing about a problem or a method in this areas and at the end of the article, you can say "hey! I can help you solve this problem, get to know more!" or say how you would solve this problem and offer to help them do it.

</comment><comment><USER4> The more niche you go, the easier the positioning becomes. The crux is, of course, to decide on which skill to focus on. It's a personal decision that requires to say "no" more often then "yes".</comment>


Amazon adds 800 TV Shows, Disney-ABC to Prime Streaming - <AUTHOR> http://www.amazon.com/

<comment><USER2> Looks like a big move to put the hurt on Netflix.</comment>


Google App Engine Blog: $50 Credit for new billing signups and budget changes - <AUTHOR> http://googleappengine.blogspot.com/2011/08/50-credit-for-new-billing-signups-and.html <comment><USER2> Is there a way to verify the billing credit after making a budget change? I think this $50 credit will mean webputty.net can run for a few months for free, but I can't figure out where to find the credit after I made the change.</comment>


One Year of PostmarketOS: Mainline Calling - <AUTHOR> https://www.postmarketos.org/blog/2018/06/09/one-year/ <comment><AUTHOR> dupe, did not see. woops [https://news.ycombinator.com/item?id=17272122](https://news.ycombinator.com/item?id=17272122)

still hoping to spread the information around in the hopes it gets increased attention!</comment>


Medieval door believed to be the inspiration for Tolkien's entrance to Moria - <AUTHOR> https://twitter.com/historylvrsclub/status/985815807098806272?s=20 <comment><USER2> There's no supporting reference given, and this doesn't resemble Tolkien's description in the slightest in size, shape, or appearance of materials. The door in the film corresponds much better.

See: [http://tolkiengateway.net/wiki/Doors_of_Durin](http://tolkiengateway.net/wiki/Doors_of_Durin)</comment>


21 android apps ripped off, exploits added and republished. 200k d/ls. - <AUTHOR> http://www.reddit.com/r/netsec/comments/fvhdw/someone_just_ripped_off_21_popular_free_apps_from/ <comment><AUTHOR> Apologies if the headline seems a little cryptic. This a link to an ongoing discussion on reddit about how 21 popular apps on the android marketplace were downloaded, had root exploit code added before being repackaged and put up on the official android market for download. There's since been between 50,000-200,000 downloads of these trojaned apps in the past 4 days.

There's some commentary here: [http://blog.mylookout.com/2011/03/security- alert-malware-fou...](http://blog.mylookout.com/2011/03/security-alert- malware-found-in-official-android-market-droiddream/) along with a list of publishers and applications.

If you're an android developer you might want to check this out. If you've been affected I'd love to hear your thoughts and feelings about this here.</comment>


Relax. You can (mostly) stop using Interfaces in Java now - <AUTHOR> http://garmhold.blogspot.com/2010/03/relax-you-can-mostly-stop-using.html

<comment><USER2> Please don't. Interfaces are one of the few redeeming aspects of the language. They give you a way to fake mixins, they're the only hook for dynamic proxies (for quick, simple, non-bloated aspect-oriented programming), and they let you swap in different implementations. Interfaces are good, use more.

What's the perceived downside of using interfaces? That you end up with more files? That you dead-end into bare method declarations when browsing your code? Any others?

<comment><USER3> How about trading off code readability for code complexity that has some potential future payoff? Library developers might want to trade more of their readability than app developers because of the nature of 3rd party code. It's ultimately a trade off that you have to make, but there are some general rules of thumb can help you so that uber flexilibity doesn't take over.

<comment><USER2> Do you really think that interfaces on their own constitute 'uber flexibility taking over'?

<comment><USER3> Prolific over use of interfaces when all you have is a single implementor. In a word Yes.

</comment></comment></comment></comment><comment><USER4> There are good reasons to use interfaces and to just accept the extra minor bit of work that goes with them. When using injection frameworks (like Spring), it makes life easier to reference an iface and have your concrete class plugged in automagically (using annotations). The iface also provides a clean look at the intentions of the application. Writing impl classes is trivial with an IDE - you can create your impl and fill in stub methods quite easily. The tradeoff of separation can be worthwhile in a complex system.

<comment><USER5> Yes, but generally speaking, if you're writing FooIFace and FooImpl you should probably rethink what you're doing.

<comment><USER2> Ideally, you'd just get it right the first time, but if you're going to screw up, it's usually better to screw up by having an interface you don't really need than by having a class that should really be an interface. Generalizing that makes it hard for me to agree that FooIFace and FooImpl is, on its own, evidence that something's wrong.

<comment> Tuna-Fish This does condense what I dislike about java quite nicely. All proper java code is full of speculative architecture and genericity -- in order to have your code easily extensible, you do have to have setters, getters, interfaces, factories and everything else from version one.

As an example of a language that gets it right, look at python. You can write your orginal classes in the simplest possible way they could be written, and yet expand from there to just as much architecture as your problem needs without ever touching the users of the class.

<comment><USER5> Well, point taken about the getters/setters, those should be automatic or at least managed via keyword or annotation (private gettable String fname or something like that)

As for the rest of it.. it's just a question of proper design. If you're just making a utility, you don't need any interfaces or factories. If you're making a module for something that's intended to be run with a half-dozen service dependencies, it's probably a good idea to design it in a way that said dependencies can be injected -- whether you're using spring or doing something more lightweight. That applies across languages, same deal in python.

<comment> Tuna-Fish I honestly don't think "private gettable String fname" is in any material way better than getters and setters, as your ide can already insert the boilerplate for you. The problem isn't the boilerplate per se, it's forcing you to think about things before their time. Your attention is a scarce resource. The only satisfactory way for the first version is "public String fname", with the ability to later turn that into proper getters and setters when it is needed without the consumers of the class even knowing.

My big point about python is that you can always inject the dependencies, and you don't have to spend any thought beforehand to achieve this. Java could go a long way here with just a few minor changes -- for example, remove "new", you get a new object by calling it's constructor, without any special operators. Allow shadowing of functions. This alone would end the factory madness -- in fact, factories are just an awful boilerplatey way to implement this. For example, if I have a class Foo that needs to instantiate Bar to function, and I want to inject a different bar for some tests (or something), in python I can just:

        def make_test_foo():
            Bar = DummyObjectConstructor
            return Foo()

(this will of course occur only in local scope, so that other potential users in other threads are not going to be stuck with dummy objects against their will)

To achieve the same in java, the way I was taught to was to design in a BarFactory for use when needed. In most cases, it's not going to be needed. But if you don't make it, boy are you going to be in a world of pain when you do need it, and half the world already depends on your class.

What really irks me about this, is that hotspot is perfectly capable of dealing with these kinds of things -- it is a really nice platform for this kind of dynamicity. Sun just used think that poor programmers are going to be confused when you hit them with too many high-level concepts, and refuses to add constructs like this. Which would be fine, except that the programmers invariably go on to develop their own ugly workarounds, like factories, because they need the power.

This I believe to be the big reason why python is so much faster to program in than java. I can program for the now, completely ignoring superfluous architecture when my programs consists of 3 files, with the knowledge that I can safely add it later when needed. The syntax and dynamic typing are just a nice extra.

</comment></comment></comment></comment></comment></comment><comment><USER6> I don't do Java, but I always prefer to code to interfaces rather than implementations. It is more sane and allows you to "late bind" more. It is also easier to test, even in languages that aren't as strict as Java. Sure, not everything should be an interface/implementation combination, but it's not a bad start.

</comment><comment><USER3> I guess this is only tangentially related to each other Mock objects and interfaces. I stopped using interfaces in this manner. My rule if you only have one implementation of an interface you don't need an interface. Wait to create the interface when you get your second implementation, and we have great tools that make that easy.

Now for people who do lots of mock objects this rule doesn't help them out much, but my other rule is I don't overly separate my system for testing purposes. Sure there are times when you need a mock object for java mail or external services you need to mock out. But, doing it for every service you have is really a lot of work for questionable gain. This is predicated on practical experience rather than architecture theory. The reason you separate your system for testing is to find more bugs. I found that I wasn't finding anymore bugs by separating things than I was by testing it integrated. And, in fact I found more bugs in the integration of services than I would if I only tested them in separate form. Therefore, I stopped doing the extra work to separate them because the payoff was really too small to bother. It's been much more productive to think like this.

</comment><comment><USER7> So, the argument is that you can stop the pattern of writing IFoo and FooImpl when you're pretty sure that the only other impl of IFoo will be MockFoo.

</comment><comment><USER8> Is it me or in both of the examples there is an extra { ? Is this something about Java I don't know about?

<comment><USER9> The first { opens the body of the anonymous inner class.

The second { starts an instance initialization block, which runs on each object when it is constructed - not sure if it's before or after the constructor - gonna guess before!

It's useful in this case as anonymous inner classes can't define constructors.</comment></comment>


Ask HN: Tax Implications of Ethereum Smart Contracts? - <AUTHOR> Hey Guys,
I'm thinking of building a web based app that uses smart contracts. If my app takes a percentage of a given transaction how does the IRS view that? Is it only taxed if I convert that to FIAT?
Hoping some of you have experience with this.
I also wonder if a given app utilizes smart contracts if that is considered a money transmitter business. <comment><USER2> The taxable value will likely accrue at dollar value at the time you receive the fee.

<comment><AUTHOR> Ahh I see thanks Charles! Yeah I'm reading up all I can about this subject atm. Curious to see if any fellow HNers have been down this path.

<comment><USER2> I'm not American, but the thing with taxes is (especially if things are undefined / unclear in the law) that you need to go with the most straight forward solution so the tax authority can't call your "solution" unreasonable.

If you earn $100, you'll pay corporate tax on $100. If you earn 1 ETH on the 1st of January, and the value of 1 ETH at that point is $500, then you should value that ETH at $500 and pay the tax on the corresponding dollar value (in this case $500). You're not going to run into any problems there, as it is pretty much the most reasonable approach.

<comment><AUTHOR> Thanks for the input. Yeah I suspect it may be this way.</comment></comment></comment></comment>


On Building Flipboard for iPhone - <AUTHOR> http://craigmod.com/journal/digital_physical

<comment><USER2> Incredible.

As a fellow creative, the amount of care and consideration that's displayed here is not at all surprising. The product really speaks for its self.

This type of journey that a product takes is so often lost forever.

I wish more people documented their creative journeys. At the time, small anecdotes may not be that interesting, but the sum can offer incredible insight into how something came into fruition.

It's valuable both as a display of how much unseen work goes into great products, and as a way to help others learn from your mistakes.

I'm as guilty of this as anyone else.

<http://www.folklore.org> is a great example of how enthralling these stories can be.

</comment><comment><USER3> I love this idea. I've been involved in so many projects and I know very well the ephermal feeling he describes. I wish I had a book like this for every lengthy project I've been a part of--it would just feel so much more gratifying than something that turns into a blurb on a resume and then eventually falls off.

Every project manager should make one of these for their teams, and themselves. For every project.

<comment><USER4> Some of my best bosses have done this in different ways and it's super inspiring. I know it's a ridiculous amount of work in and of itself but it's something that becomes absolutely priceless to those who were involved.

For those who are managing software teams, check out <http://code.google.com/p/gource/> It does a stunning job visualizing your codebase being built based on git changelogs. Record it with fraps, add some background music and you have a music video you can watch of each major release. :)

</comment></comment><comment><USER5> When a lot of effort and energy has been put into polishing a product it clearly shows. The last 10% of the polish makes up 90% of the differences between a great product and an average one. Great to see a great team of engineers/designers focusing not on "what" the product does but on "how" it does them. Kudos to the Flipboard team.

</comment><comment><USER6> Imagine you're looking to hire a top tier developer, or perhaps a "product person." After a strong interview, he or she is walking through the door, pauses, turns back, and says, "oh, one more thing." And hands you something like this.

<comment><USER7> Ha. Craig would probably do this, and then say "Hold on" while he plunks down his book on Tokyo Art Galleries: <http://craigmod.com/journal/kickstartup/>

What can I say? The man is prolific.

</comment></comment><comment><USER8> I am blown away. Completely. It's almost as if I'm reading an epic journey…

The amount of iterates over the layout, typography, transitions, all told over those pages.

Wonder how I can get a copy… :P

</comment><comment><USER9> This article really inspired me, as well as got me thinking about past projects I wish I would have documented in a similar way.

Imagine surprising your team with copies of something similar after they have killed themselves building an amazing product. I can't imagine a better reward (other than users who love using your product).

</comment><comment><USER10> I know it's not made for anyone outside of the company, but why not? Trade secrets? It would be an interesting read to other people too, and they might also have the experiences of reading "The Umbrella" on software craftsmanship...

<comment><USER11> While we would love to, there are many ideas and designs that may appear in a future release, so they stay in the design vault for now.

</comment></comment><comment><USER12> reaching to the finished product is the most difficult outcome in this. A play like is definitely appreciated in time. Well done, Craig.

</comment><comment><USER13> go craig!!!!!!!

</comment><comment><USER14> SO... Android version coming soon (please)?</comment>


Ask HN: anyone in SF need a kickass frontend developer? - <AUTHOR> My current job is pissing me off. Most of the people I work with don't seem to have a clue as to what they are doing. I'm given a "must do next-day" priority, then the next day they change their mind and I'm off to work on whatever else they think is important today. We're a community-focused site and yet there's little care shown for site size, future extensibility, best practices, building for the future, etc.
I have spent over a year trying to improve the situation, promoting better development practices, evangelizing community oriented features, and more. The other frontend developer and I are constantly ignored and major frontend decisions are being made by the lead of engineering who is a straight "Java expert". Frontend dev is a completely separate team with our own manager, and yet nothing is done to respect or even solicit our ideas and opinions.
I'm just tired of regretting waking up each morning and slogging uphill through a mountain of mud and not having achieved anything at the end of the day.
I want to work on something important, where we can build and iterate fast and where I can have a hand in shaping the future of what I'm working on.
I do a lot of side experimental projects ranging from better CSS and javascript techniques to building around public APIs and experimenting with new languages. For example, I've been working pretty heavily for the last 2 months on implementing a server-side javascript environment based on V8 and got an API proxy working in Google App Engine 2 nights ago in a few hours. (I've never used nor touched Python before that). I released a Twitter promo tool on Google Code a couple weeks ago (http://code.google.com/p/fathomer/). I want to be in a place where if I am working on something cool on the side, there's a chance that it could be used and further adopted by the business. <comment><USER2> If you're not happy at work, do whatever you have to do to change it -- even if you need to quit and build up a portfolio for a few months. I left a stable but miserable existence at IBM a couple years ago, and now enjoy every single day I'm working with my startup colleagues. Life's too short to be miserable.

We are looking for another top-notch front end dev here at Zivity. Feel free to email me at firstname.lastname@example.com if you want to grab a beer at 21A some evening.

</comment><comment><USER3> Take a look at Palantir Technologies: <http://www.palantirtech.com/>

We're doing some world-changing stuff: <http://blog.palantirtech.com/2009/01/22/tarp/>

We need as many kickass frontend-devs as we can find! (we're down in Palo Alto, but very CalTrain-able)

</comment><comment><USER4> I've been in a situation similar to this, where management just did not get it. They would ask for our input, but then never act on it.

You are on the right track by looking for a way out. The company is doomed. I left and it has worked out great.

</comment><comment><USER5> StreamFocus.com is looking for one. We just got a new CEO and are planning a major UI redesign. Our backend is all in Lisp, but the frontend is going increasingly toward javascript and ajax. Let me know if you're interested: email@example.com

</comment><comment><USER6> Disqus is looking for one. We're in SOMA (2nd & Howard) - shoot me an email: email@example.com

<comment><AUTHOR> Daniel, you and I have spoken before. Thanks for the heads up, I'll email you during lunch.

</comment></comment><comment><USER7> Sugar Inc (popsugar.com, shopstyle.com, etc) is looking for a kickass frontend developer to help make 50 women editors happy.

We are at 111 Sutter. email@example.com

<comment><USER8> He said he wanted to work on something important.

<comment><USER9> LOL :-)

</comment></comment></comment><comment><USER10> I'm a co-founder at a startup called Boffery, a visual diary for people's sex lives. (Think Geni.com for sex.)

The sex angle alone doesn't sound terribly important, but our long-term plan is to license the technology to other social networks -- or, and this is terribly unlikely but obviously tempting, become a large-scale general- interest social network on our own.

We have a spec, an early prototype built by our one developer, a forthcoming angel investment, a thousand people on our beta-tester waiting list, and a plan for getting to revenue (but not profit) by the end of the year. If you're interested, I can introduce you to our project manager. E-mail me at firstname.lastname@example.com.

</comment><comment><USER11> If you are seriously looking to go to SF you should have no problem. I was looking for positions last year and the east coast just kept calling. That said, you will be working for a start up given your requirements which lends itself to the very condition you are describing. You'll have a ton of fun, learn a lot, but eventually the mess will hit the fan and you'll have unrealistic timetables and a grab bag of management woes.

Building the future is an excellent goal and something to strive for, but if you want stability and dependable management I'd head for corporate America. They have the capital to hire decent managers, train you for free, and give you realistic deadlines. Couple that with realistic hours, and maybe you'll have more time to experiment.

Zed Shaw put it perfectly, "Fight your hardest not to be a corporate coder: your life as a geek or a coder should be all about exploring some new domain that no one else gets -- you can only go to conferences and talk to other geeks about what you do. A corporate coder works only on the stuff he's supposed to on one language, and never touches code otherwise. You should go home and do something fun with technology."

<http://vimeo.com/2723800>

A disclaimer, I work for a giant corporation. I work on things that I think don't matter, but to the people on the ground building our products, the tools I help build and deploy mean a lot. They prevent accidents, environmental hazards, and close calls.

Then I go home and hack on Python, PHP, .NET, and Arduino. And play Rockband.

<comment><AUTHOR> I already live in SF.

</comment></comment><comment><AUTHOR> Thank you to everyone who has contacted me, commented here, and started following me on Twitter. I REALLY appreciate the outpouring of support from the HN community. I will be getting in touch with everyone who has contacted me ASAP!

</comment><comment><USER12> geuis: My social games company is always on the lookout for good engineers. Why don't you shoot me an email at siqi[at the domain]seriousbusiness.com. We're a pretty small team of < 20 guys, two technical co-founders (I was in YC for a week or so) with a team of really smart engineers (some ex-Powerset, some ex-Google), and we've got an awesome casual but focused culture.

We are metrics driven, and iterate extremely quickly (we deploy dozens of times in any given day). I think you'll like it here if you're frustrated at where you are because your voice isn't getting heard and you aren't moving fast enough.

</comment><comment><USER13> I'm looking for a co-founder on a project I've been working on for some time. If your interested shoot me an email. Mine's jklub at live.com

</comment><comment><USER14> I know of an unadvertised opportunity with an extremely interesting team for a talented front-end developer/designer. HN folks can Send an email to firstname.lastname@example.com for details, it isn't up on their web site yet so I'd prefer to keep the name off the web until it is public.

And in the mean time, HN readers get a head start on the opening :-)

<comment><USER12> Reg, shot you an email yesterday about a job. Still on the market? =)

</comment></comment><comment><USER15> Are you interested in a low pay situation? My startup doesn't have the revenue at present to pay you much, but you'd have a big hand in shaping the direction of the product and a friendly, happy atmosphere. And obviously we expect some revenue soon. Shoot me an email at gmail if you want to discuss.

<comment><USER16> ok dude, what's your email

</comment></comment><comment><USER17> I'll consider you, but first you'll have to prove your claim that you can "kick ass" -- fight club style.

<comment><USER18> The first rule of Fight Club is - you do not talk about Fight Club :)

</comment></comment><comment><USER19> If you're interested in interviewing at Facebook (some of the most cutting edge frontend stuff on the web, changing how social communication works, some of the best developers anywhere, fantastic place to work), drop me a message at firstname.lastname@example.com

</comment><comment><USER20> Upvoted to help you out. Good luck!

<comment><AUTHOR> Thank you Dave!

</comment></comment><comment><USER21> Hey man. I'm looking for a developer for my web startup as well. I'd be happy to discuss details if you could email me at firstname.lastname@example.com

</comment><comment><USER22> Think is looking for programmers, front-end and back-end. Send stuff to jobs at thinkcomputer.com, and mention YC or Hacker News.

</comment><comment><USER23> I could use some help, but I don't need someone in a specific place, and don't need a full-timer.

</comment><comment><USER24> experiment with drastically reducing your productivity. if no one notices great, you now have time to spend on personal projects and get paid. If people notice look for a new job.

I don't understand why everyone doesn't do this at jobs they dislike.

<comment><USER25> Not sure if you're trolling or not, but I'll respond anyway.

I'll give two reasons: 1) it's dishonest 2) if your mgmt does notice, this will burn bridges with both mgmt and your coworkers who have to pick up the slack.

<comment><USER24> I find that the "burn bridges" argument rarely applies in real life unless it's a small community.

</comment></comment></comment><comment><USER26> Are you interested in telecommuting from home for an OR-based company?

</comment><comment><USER27> Are you a "code ninja"?

</comment><comment><USER28> startup may be one of your option, join one or start one and be ready for low pay, high fun and may be some equity ... :-)

<comment><USER29> Start ups do not necessarily mean low pay. I am work at one and we are all paid at or above market rates - it is worth it to pay for good people.</comment></comment>


I'd like to set up a torrent tracker. How? - <AUTHOR> http://vrypan.net/log/2010/03/12/id-like-to-set-up-a-torrent-tracker-how/

<comment><USER2> Many of the current private trackers use TBsource <http://sourceforge.net/projects/tbsource/></comment>


What's keeping drone startups from taking off? - <AUTHOR> It seems widely accepted that drones have significant applications in package delivery, health care/emergency response, site mapping, etc. So why aren't they widely used today? Is it because of regulatory barriers? A lack of profitability? Are there technological hurdles that are yet to be resolved? Ease of use problems? What are your thoughts? <comment><USER2> I wonder the same thing. Maybe people just worry about regulations and public opinion?</comment>


Ask HN: What university to apply to? (CS) - <AUTHOR>

Hi, HN.
As the title suggests I'm in the process of choosing a university (UK, US) and an undergraduate program for me to apply, and, honestly, I have no clue how to make the right decision. I've browsed university websites, read guides and asked for advice from people I know, but I'm yet to find the proper answer.
The thing I want from a university is a solid theoretical background in CS. I'm not a programmer yet, but I care deeply about the ways people approach computing, and my goal in the long run is to be able to build programs even on the lowest levels of abstraction. I probably need CS for that. I don't care about employment opportunities as long as I can support myself and code the way I feel is right. I would be incredibly disappointed to see Java, C☂ or anything corporate in my curriculum. I need theory, not a job at MS.
I've got my BS in Management and (if you forgive a lame pun) I've come to realize what a total BS it is. I know Ruby reasonably well; although I'm a total '() in Lisp (Scheme) and Smalltalk, I feel like these two language are gems in their respective domains, and for this reason I'm now making my way through the famous SICP lectures and a Smalltalk-80 book.
I really hope to get some response, because I know you are all smart and have a lot valuable experience to share. Sorry for the rant. <comment><USER2> I only know the US side. But there are two schools of thought that I believe hold true -- specifically for the U.S.

You can go to school for the education or the reputation. The best of both worlds: Stanford... but it's a long shot to get in for just about anyone.

Universities really aren't moving fast enough to keep up with web technologies, so what you teach yourself will be faster than what a school can keep up with.

For reputation: Stanford, Harvard, MIT, CMU

For theory, plenty of schools are good schools. Maryland (full disclosure, my alma mater), Michigan, Cornell, Berkeley, Austin

Best of both worlds (in my personal opinion): Stanford, Berkeley, CMU

Again, theory will depend on the classes you pick and the professors you get (You'll likely get 90% of it from one specific class that ends up matching up with your interest and learning style the most). Relevance will depend on what you can learn on your own.

<comment><AUTHOR> Thanks for the input.</comment></comment>


Churn Is Looking for a Technical Co-Founder/Developer - <AUTHOR> https://angel.co/churn-3/jobs/50338-lead-software-engineer

<comment><USER2> Do you already have a complete MVP? Do you have significant funding? Your AngelList profile leads me to believe that you don't.

Friendly Advice: If I was to seriously be evaluating this as a potential CTO, I would want my equity stake to be equal to that of you and your partner.

5%-10% to the person doing all the heavy, technical lifting is very low.

</comment><comment><AUTHOR> We are seeking a Co-founder to join our new startup.</comment>


Elementary Is Crowdfunding a Pay-What-You-Want App Store for Open Source Apps - <AUTHOR> https://www.indiegogo.com/projects/appcenter-the-pay-what-you-want-app-store <comment><USER2> Instabacked! Elementary is doing great work making Linux a viable mainstream alternative to macOS and Windows. It's a huge task but having funding to help them and open source developers is sure to help.</comment>


Show HN: Open Source Generalized Cognitive Behavioral Therapy on iOS - <AUTHOR> https://getquirk.app/ <comment><AUTHOR> For those unaware,

CBT is an extremely effective, evidence based way of treating many mental health disorders including depression and panic disorder.

It's also a fantastic way of reevaluating biases. It can be extremely effective at getting to you really evaluate points in your life when something you've thought is illogically affecting your mood. For example,

> Wow that demo went terribly, everyone must think I'm a dumbass.

It's really easy for us to let these thoughts take over the rest of us. We tend to find ourselves repeating events that make us angry, guilty, or afraid as if they were movies in our brains. That can mess with our opinions of others and cause us undue stress and discomfort.

Instead, CBT will ask us to list the __cognitive distortions __and then __challenge __this belief. So for the thought above, we 'll say it's:

* mind reading (since we don't know what other people think)

* catastrophizing (since we're implicitly assuming something terrible could happen because our demo went poorly)

Then, it will ask us to come up with a "better" or "alternative" thought like this:

> That demo went poorly, but I'll do better next time and I'm glad I learned > from it!

That may seem silly, but the act of writing it down helps you notice when your thoughts are taking too much control over your life. And the act of challenging it helps train your brain to "automatically" think better thoughts in the future.

For some, these negative thoughts control much of their life and we may consider that a form of pathology. But for many of us, it's just a part of our monkey brains we'd like to deal with better.

Quirk is made with both uses in mind. It's general enough that it can be used for any condition. It started as a prototype I build just for me, but I hope it's useful to others as well. It was built to only incorporate the evidence backed treatments. Many apps overly couple CBT with "relaxation tapes" or other untested treatments. Quirk is as slimmed down as possible.

If you don't want to pay the 2 dollars, Quirk is open source and you're welcome to build it yourself. Here's a couple promo codes as well though:

NM4MKLPYNPNL YMWAXHMKJYA3 A3NALPLLM7LK P4EYRPPX37PM 9TP9P9F6NMWN YKLJK7N7PH3E 4RP3RJJTRRER W6MAYR7JM7HH L76NMLP9PXLT L7A9PLTNKPN7

And if you need to talk, or just have questions about quirk. Feel free to email me: quirk @ econn.info

<comment><USER2> I need citations for effacacy. I found CBT to be mostly self confirming bs. I realize its the psych dujour right now, but actual hard data is fleeting in my experince.

<comment><AUTHOR> A meta-analysis ([https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3584580/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3584580/)) of 269 studies found it for depression to be roughly equal to medication treatment and that when combined with medication was more effective than one or the other:

> Compared to pharmacological approaches, CBT and medication treatments had > similar effects on chronic depressive symptoms, with effect sizes in the > medium-large range (Vos, Haby, Barendregt, Kruijshaar, Corry, & Andrews, > 2004). Other studies indicated that pharmacotherapy could be a useful > addition to CBT; specifically, combination therapy of CBT with > pharmacotherapy was more effective in comparison to CBT alone (Chan, 2006).

It also found it to be effective in nicotine cessation and other addictive behaviors:

> Treatments for smoking cessation found that coping skills, which were > partially based on CBT techniques, were highly effective in reducing relapse > in a community sample of nicotine quitters (Song, Huttunen-Lenz, & Holland, > 2010), and another meta-analysis noted superiority of CBT (either alone or > in combination with nicotine replacement therapy) over nicotine replacement > therapy alone (Garcia-Vera & Sanz, 2006).

In anxiety disorders, studies found them to be effective "first line" approaches, including when the CBT was delivered over the internet:

> In general, CBT is a reliable first-line approach for treatment of this > class of disorders (Hofmann & Smits, 2008), with support for significant > positive effects of CBT on secondary symptoms such as sleep dysfunction and > anxiety sensitivity (Ghahramanlou, 2003). Further, internet-delivered or > guided self-help CBT showed some promise in immediate symptom relief as > compared to no treatment, but the long-term maintenance with this modality > of CBT remains unclear (Öst, 2008; Coull & Morris, 2011).

Also, the meta-analysis also found it to be effective for:

* insomnia

* anger and aggression

* general stress

and many other disorders.</comment></comment></comment>


Ask HN: Where can I find a Tech Co-Founder To Generate Leads?  - <AUTHOR>

I am looking to add a tech co-founder who can generate leads for my company, where should I look? <comment><USER2> You might find a co-founder here: www.founder2be.com</comment>


The Linux Graphics Stack - <AUTHOR> http://blog.mecheye.net/2012/06/the-linux-graphics-stack/ <comment><USER2> I can understand that Wayland does not want to pay for the complexity of network transparency, but I'd be sorry to see it go entirely. I'm one of the few people who do make use if X11's network transparency on a regular basis. Being able to open a web browser on a machine that is several ssh hops away is awfully convenient. I hope that Wayland has some provisions for reproducing or emulating X11 even if it isn't built into the core.

<comment><USER3> This may be incorrect; I have only vague familiarity with the subject. I don't know if there are any non VNC-like solutions being worked on.

Wayland doesn't have network transparency as a first-class citizen, but it's easy to fit it into the mix. A bit of background:

In X11, the client sends the actual drawing commands (draw a line here, a smooth gradient here, a pixmap here, a curved line here, etc.) over a network pipe. The X server on the other end takes those commands and builds the resulting image.

In Wayland, your program just transfers (well, using shared memory) complete images of the entire window to the Wayland server.

The X11 solution is absolutely excellent and very efficient _assuming your programs primarily use the X11 primitives_. Most modern programs and toolkits do not use the drawing primitives; they just build the images they want and send a bunch of pixmaps to the X server. They do this primarily because X11 doesn't have a number of useful drawing primitives, like anti-aliased text. The result is that you're doing more or less what Wayland intends to do. (Though sending things like Xclock or Xeyes will be less efficient under Wayland, seeing as they use the X11 drawing primitives.)

In the end, Wayland will probably have something very much like per-window VNC. Your program will produce an image, some stub Wayland server will send that image over the network, and a Wayland compositor on the other end will receive it and display it.

</comment></comment><comment><USER4> I wish that unoccluded or maybe just the frontmost window could be unredirected too, even if it's not fullscreen. The decorations and shadow could still be drawn in the Compositor Overlay Window.

I work on Linux on a program which is entirely drawn by OpenGL (I target ARM devices, but I test on the desktop before doing an ARM build). Application GL performance suffers immensely under a compositor, so on most machines I can't use GNOME3 (though I would like to). On machines where I get acceptable GL performance in my app, vsync is broken so there is constant tearing.

I'm sure there are some caveats with unredirecting the frontmost window -- like when it becomes occluded it would have to be redirected and that requires a round trip to the client (which might hang, etc), but there are probably other situations like this which the window manager has to deal with already (resize timers?) so maybe there is a way to implement it...

<comment><USER5> I think that Mac OS X unredirects unoccluded windows; I've noticed windowed computer games suddenly getting much slower when I move another window in front of them.

<comment><USER4> It appears to, or has some other trick... My coworker has a huge monitor, and his MBA doesn't hit 60 FPS on any of the fullscreen animations, but individual window contents can go at 60 making me think they don't repaint the world every time a window changes.

</comment></comment></comment><comment><USER6> Absolutely fascinating.

Some questions...

Would this mean that window managers themselves would have to be re- implemented in order to support the Wayland protocol?

Is anyone working to create a non-reference optimized implementation of libwayland?

Have the Wayland developers said anything about supporting multiple monitors yet?

<comment><USER7> Yep, the Wayland developers' solution to window management is for anyone who wants a different window manager to replace Wayland with a different compositor+window manager speaking the same protocol. Their suggested way of supporting proprietary graphics drivers is also replacing the compositor+window manager with one specific to that hardware which speaks the Wayland protocol, sort of like in the early days of X when there was a seperate X server binary for every piece of hardware. So your window management choices under Wayland depend on which graphics drivers you're using.

<comment><USER8> Not quite. Wayland itself doesn't require any graphics-driver-specific code; it uses the standard kernel interfaces and graphics stack (Mesa, DRI, libdrm, KMS, etc). That also works fine with radeon and nouveau, and it would work fine with the proprietary drivers as long as they support the standard graphics stack. It just won't work with proprietary drivers that implement their own entirely un-integrated graphics stack, which seems unsurprising to me.

Your window manager of choice can just link into Wayland/Weston and ignore all the underlying graphics driver bits; they'll Just Work.

<comment><USER9> It's been years and years since I knew the details, but at one point the nvidia drivers replaced pretty everything from libX11 down, and I don't think you could hook in at a middle point. (ie, they don't support the "standard" graphics stack.) Would appreciate if anyone could comment on how things stand today.

<comment><USER8> Somewhat better, but still awful. They don't replace libX11, but they do replace libGL, and they bypass the entire kernel graphics stack in favor of their own.

</comment></comment></comment></comment></comment><comment><USER10> Now, this is the sort of article I want to see on Hacker News. Excellent read.

</comment><comment><USER9> _instead of going over the network, they'll go over a UNIX socket, and the kernel doesn't have to copy data around._

This isn't really true. Even if the kernel does cow pipes (on both ends), the writer is almost certainly going to trash the page and cause a fault. The data is just copied around without being bundled into TCP packets.

There is also a SHM extension which does use shared memory, but that's separate and mostly only used for pixmaps and the like.

</comment><comment><USER11> > While it's very apparent that X is going to go away in favor of Wayland some > time soon...

Isn't it a bit early to be saying something like that? While I hope that Wayland will succeed, it has an equal chance of ending up as vaporware.

<comment> chao- At minimum we'll get at least one distro attempting to utilize Wayland eventually: Ubuntu. See the bottom of <https://wiki.ubuntu.com/Wayland> where it reads:

 _Canonical is investing in making Compiz Wayland-enabled and running Unity on top._

While it does not completely refute your concern of Wayland becoming vaporware, a commitment from Canonical is about as close as anything in the Linux Desktop world ever comes to being a hard milestone. Put another way: it's more reliable than a random user on the Arch forums* talking up grand plans to rebuild WMFS to work with Wayland.

*A purely random example, and not a knock on Arch forums, which are an awesome/informative place.

<comment><USER12> >a commitment from Canonical is about as close as anything in the Linux Desktop world ever comes to being a hard milestone

Furthermore, most Xorg and desktop developers are pro-Wayland if the OP is to be believed.

<comment><USER13> I think if anyone really doubts this they should spend some time programming something directly on top of Xorg to convince themselves that when the ball of mud is gone there will be at least a bit more sanity.

<comment><USER14> I haven't used the raw stream protocol directly, but if you mean Xlib, I actually find it more usable than most toolkits. (Although a big part of that is being able to use select(), whereas most toolkits force you to do everything in callbacks while the toolkit drives the main loop.)

</comment></comment></comment></comment></comment><comment><USER15> So wait... Wayland does nothing, makes existing things harder and requires the Linux ecosystem to greenspun X in perpetuity?

<comment><USER16> Not sure why you're being pessimistic. VNC demonstrates that graphical access can be networked at the application level rather than as a fundamental architecture decision we pay for constantly. Wayland is an attempt to cash in on the savings.

<comment><USER9> Except it doesn't look good, and copy/paste is even shittier.</comment></comment></comment>


Claim that tardigrades got 1/6 of DNA from microbes is starting to unravel - <AUTHOR> http://www.theatlantic.com/science/archive/2015/12/rival-scientists-kill-recent-discovery-about-invincible-animals/418755/?single_page=true <comment><USER2> Fuck this narrative of rivalry.

Scientists working in the same field have put out a study that disagrees with the first study. This is not a severe blow, it does not debunk the first study, it does not imply some sort of rivalry. Science is _cooperative_. We all want to find the truth.

<comment><USER3> PNAS Paper (the firs paper) is here : [http://www.pnas.org/content/early/2015/11/18/1510461112.abst...](http://www.pnas.org/content/early/2015/11/18/1510461112.abstract) : "Evidence for extensive horizontal gene transfer from the draft genome of a tardigrade". The gene transfer angle is the most prominent thrust of the paper: "Horizontal gene transfer (HGT), or the transfer of genes between species, has been recognized recently as more pervasive than previously suspected. Here, we report evidence for an unprecedented degree of HGT into an animal genome, based on a draft genome of a tardigrade, Hypsibius dujardini."

Non target contamination in sequencing DNA and RNA is common. Attributing "horizontal gene transfer" due to the "noise" is a mistake. The second group actually does debunk the initial paper's main point.

Perhaps establishment science need to move the peer review from before publication to after.

<comment><USER4> > Perhaps establishment science need to move the peer review from before > publication to after.

The after publication 'peer review' is when colleagues attempt to replicate your findings. It's a series of gates to credibility and general acceptance, not a single door.

</comment></comment></comment><comment><USER5> This leads off a series of tweets from the Edinburgh team evaluating the read data with some informative images: [https://twitter.com/sujaik/status/671758970982416385](https://twitter.com/sujaik/status/671758970982416385)

</comment><comment><USER6> Is there a way to get just the DNA you're interested in sequencing in the first place? Eliminating the sequences that look out of place afterwards does not seem like a good strategy.

<comment><USER7> Supposing there was, why wouldn't they have done that?

<comment><USER6> Cost.</comment></comment></comment>


EcmaScript Edition 5, formerly known as 3.1: Getting a new JavaScript - <AUTHOR> http://ajaxian.com/archives/ecmascript-edition-5-formerly-known-as-31-getting-a-new-javascript

<comment><USER2> Even if this is ever rolled out to modern browsers, IE6 is still (according to w3schools) at about 17% of the market.

We'll never lose IE6 entirely, due to the plethora of small/medium/large business apps that only work with it (and won't even work with IE7).

IE6 is trending downward at about half a percent per month. That will likely plateau, but if it does continue we should be IE6 free in three years.

The key, like always, will be to develop two versions of your app: One that's shiny and works in new browsers, reverting to traditional html and anchors for any other browser.

I'm actually seriously considering treating IE6 as if it does not have Javascript support at all, in the future.. and if users want the full experience, they should upgrade their 8 year old browser.

<comment><USER3> I see a lot of posts like yours on a lot of web development forums, especially on hacker news. _"Gotta support ie6, it still has some market share"_ they always say. But who is running this legacy browser? What kind of person is it? Well it's probably either: A) the office worker stuck in a legacy-IT job, or B) someone who doesn't really know better, and just uses their computer to check their email, maybe.

If you consider this, for the majority of sites, we are already IE6 free. Yes, you could develop 2 versions of the same app, but wouldn't your time be better spent either improving your more functional version of your app, or maybe creating an entirely new app with your free time?

<comment><USER4> A lot of people only surf the web when at work. If you want to sell to those people then your website has to work on their work computer.

</comment></comment></comment><comment><USER5> They dropped EcmaScript Edition 4 because of internal fights between Adobe and Microsoft - and I doubt they have resolved their issues as it's a clash of mega corporations. Right now, most of the proposed changes in EcmsScript Edition 5 are minor and there will go a long time before they are used by the mainstream developer. I think most future web development will be focused on HTML 5, CSS3 and improved performance of JavaScript - - which is a shame, since EcmaScript Edition 4 implemented correctly would have made a real revolution.

<comment><USER6> The first update to JavaScript in nearly a decade and rather being happy that the revision introduces some nice new features, fixes some of the biggest problems with the standard, and has been embraced by all parties so should have a relatively quick introduction, people would rather moan that it's not enough.

</comment></comment><comment><USER7> This really takes some of the best of Mozilla and PrototypeJS's work (or the ideas from them) and incorporates them into EcmaScript. Function.prototype.bind, JSON object, DOM prototypes, and Mozilla's array helpers. All super great stuff that has been hacked into the language via libraries/frameworks thus far.

<comment><USER8> Is there a changelog or something similar anywhere? Or better yet a summary, "Here's what developers need to know."

<comment><USER7> Sure! There is now: <http://news.ycombinator.com/item?id=562045></comment></comment></comment>


Motorola One launches in the US on November 11th for $399 - <AUTHOR> https://www.engadget.com/2018/11/04/motorola-one-us-release/?guccounter=1 <comment><USER2> You can also purchase practically the same exact phone for $159. It's an Android One phone as well. Xiaomi Mi A2 Lite.

Snapdragon 625 w/4000mAh battery and a higher resolution screen, dual SIM, expandable SD to 256GB, smaller notch, same chin, full metal body except for the parts where RF needs to escape. The Motorola also doesn't have Band 12 LTE like the Xiaomi. The Motorola is _extremely_ overpriced at $400.

This is priced even higher than the Nokia 7.1 which is significantly higher spec'd and comes from a reputable high quality manufacturer! What is Motorola thinking?

</comment><comment><USER3> Looks like your cookies are disabled. Please enable and try again.</comment>


AirPlay 2 cracked, will allow multiroom play to non-supported speakers - <AUTHOR> https://9to5mac.com/2019/12/05/airplay-2-cracked/ <comment><USER2> Wow, wasn't expecting that to happen anytime soon. I wonder if Apple is prepared to release AirPlay 3 to start the process all over again, or if they will just eventually open-source the spec in defeat.</comment>


First chunk of Meteor auth now in GitHub - <AUTHOR> https://groups.google.com/forum/?fromgroups#!topic/meteor-core/g4Bsm3yFTe4

<comment> X-Istence For those of us that don't spend every waking moment on Hacker News and thus have no idea what Meteor is, could someone please give a quick rundown of what this is and what it means and why I should care?

<comment><USER2> It was one of the all-time biggest product launches on Hacker News, with 1300+ upvotes.

It's a realtime JavaScript framework that makes it very simple to sync data between multiple clients and a server. When data changes, views are automatically updated and re-rendered.

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

<comment><USER3> OK, now that you bring it up, yeah, I remember that.

But I didn't remember that it was named 'meteor'.

</comment></comment></comment><comment><USER4> I am surprised that the collective hn memory seems to fail so terribly.

When Meteor was announced, people upvoted and commented like crazy. There was genuine excitement. A lot of people saw the potential for this being the next Ruby on Rails.

The commenters (including me at the time) only found two major flaws with Meteor: a) the license was too restrictive for a framework and b) security/authentication was still missing.

The Meteor team fixed a) right away and now they finally address b).

For me this means I am finally going to spend some time digging deeper into Meteor. And I thought people here would be similarly excited.

Do people here really forget that quickly, or is it just the weekend?

</comment><comment><USER5> context? What is this and why should anyone care?

<comment><USER6> When Meteor was released it was floating on the front page of HN for a while and attracted a lot of attention. One of the biggest criticisms people had was the total lack of authentication, which the developers said would be released eventually.

Eventually starts now, I guess.

<comment><USER7> Was it really? Many frameworks don't offer much beyond HTTP basic.

<comment><USER2> The issue with Meteor was that all clients have full write access to the server-side database, including other users' data. Which is problematic, to say the least.

<comment><USER8> This actually isn't true. One can easily remove the "autopublish" package to disable the behavior of publishing all data to the client, and selectively publish only certain records to the client. Then, all client-side database modification methods can be disabled, and using server-side functions, an authentication system can be built and you can build your application's logic.

</comment></comment></comment></comment></comment><comment><USER9> This is almost identical to what we were doing at Bungie Labs in 2008, except Meteor is much better. Bungie suffered from defining their own language (they didn't think this could be done in JavaScript); having a proprietary, web- based IDE; not having self-managed deployments; and being too early in the market (and probably some other stuff, too).

Without auth Meteor was interesting but not very useful. _With_ auth, though, it becomes much more exciting.

</comment><comment><USER10> This is the future of hackathons, free code days and weekend dev marathons.

Yet I'm not sure how soon any serious company will trust it with serious applications.

I'm not putting it down, this is incredible progress, the money (x millions in funding) behind it will give it a good amount of momentum, but it just seems a bit too easy, a bit too gimmicky to be taken seriously. I hope I'm wrong.

<comment><USER11> _a bit too easy_

That's an awful curious criticism to level against a platform.

<comment><USER12> Do you mean awfully curious?

<comment><USER13> See 'flat adverbs':

[http://books.google.com/books?id=2yJusP0vrdgC&lpg=PA451&...](http://books.google.com/books?id=2yJusP0vrdgC&lpg=PA451&dq=%22flaunt%22&as_brr=3&pg=PA451#v=onepage&q&f=false)

<comment><USER14> The fact that flat adverbs exist doesn't make this usage correct. The fact that it's incorrect however doesn't warrant comment. We all know what the writer intended.

<comment><USER12> I found it genuinely ambiguous. I guess I'm not used to read "American English".

<comment><USER13> The link in my previous post has more background. Daniel Defoe, Jonathan Swift, John Dryden, Jane Austen and so on were hardly writing in "American English." In fact the non-ly adverb is a relic of Anglo-Saxon declension and is present in all modern Englishes, much like the few remaining English accusatives ("him," "her," "them", etc.).

Contrary to the comment above, "awful curious" isn't incorrect usage. It's only ambiguous if you start from the assumption of an error (missing punctuation, missing conjunction, or missing -ly).

English is rich with similar constructions that are widely mistaken for errors due to prescriptions in basic style guides, which is about as far as most folks' knowledge of the language extends. Another common one is the comma splice, which isn't an error as long as you know to call it _asyndeton_ or _parataxis_.

<comment><USER14> With a few noted exceptions (often where the -ly form has another meaning) flat adverbs are considered archaic at best. That the examples you cite are from early modern English is hardly surprising - American English usage did not develop in complete isolation from its roots.

That occasional use of this earlier form has persisted in American English dialect is also unsurprising; there are other examples of anachronistic language forms, often in slang, topolect or sociolect, where common usage has otherwise died out.

The GP poster correctly observes that non-standard use of flat adverbs is more common in American English, sometimes associated with a "deep South" topolect.

Yes flat adverbs still exist in common and accepted usage, usually for good reason, but this does not make using just any adverb in plain form "correct", or less jarring to the educated ear, unless done so for stylistic reasons (which was not the case here).

I still feel the correction was unwarranted in this particular social context, but perhaps that's just me.</comment></comment></comment></comment></comment></comment></comment></comment>