The myth of using Scala as a better Java - <AUTHOR> http://appliedscala.com/blog/2017/myth-of-scala-as-better-java/ <comment><USER2> 2009 I sucked it up too.

"Hey Java is pretty much shit and here is this new better language called Scala, which you can use with your Java ecosystem!"

And I was hyped!

But, well then I saw the actual Java ecosystem...

Java itself is a pretty clunky language, especially for people like me, who did scripting language programming all the time and are probably not considered Real-Developers-TM to the Java folk. So the ideas of Scala resonated with me pretty much.

Anyway, after trying to configure stuff like Kafka, Zookeeper and Maven and setting up a SOAP API, I saw that the problem with Java isn't the language. Yes it's ugly, but JavaScript is ugly too, well even Python has its ugly parts. The problem also isn't performance, like so many C devs cry about daily. The problem seems to be that Java devs like to create things more complex than they need to be. Conglomerates of XML files, layers on layers on layers... I just don't know anymore.

I didn't use Scala for long and it wasn't because it failed me, it did, it brought its own complexity with implicit conversions and overloaded operators etc. but that wasn't the reason, it was the ecosystem which usage Scala enabled, the ecosystem that felt like it was still stuck in pre 2000. :\

<comment><USER3> You're missing the forest from the trees. Java libraries and frameworks are complicated because Java _the language_ is not expressive enough.

As I like saying, the status quo in Java land is Spring and Hibernate and people bemoaning Scala's implicit parameters never wonder why such monstrosities like Spring or Hibernate happened. Sure, blame the culture, but that's only half the story.

The same thing happens with other inexpressive languages. One of them is Python. And here we disagree again, as I think Python is chock full of ugly parts.

It started with refusing powerful and multi-purpose language features, like multi-line anonymous functions. As a result Python has been patched repeatedly with multiple non-orthogonal features to supplant the need for multi-line anonymous functions and/or to make up for its statement oriented nature. Oh, now Python 3 got await/async as well, but somehow I don't think this will stop people from monkey patching the socket module. I'm going to make the claim that in fact Python is not a TOOWTDI platform, in spite of its much touted "spirit" and anybody making that claim never tried working with Gevent or Eventlet, trying to make it work with MySQL's client and being forced to use the _native_ client because Django wasn't compatible with the pure one. Or with an N-th iteration of Ruby inspired libraries that hack into its meta programming features to make it smell like the DSLs in Ruby, but with limitations and leaks. I don't even want to talk about the build and dependency management tools in Python's land, because it should be self- evident how broken the Python ecosystem has been.

Another language in this category is Go. It's still young enough that people haven't used it much outside the niche it was created for and doesn't have much reuse going on in libraries. Give it time, you'll see the same pattern, same mistakes repeated again and again. Java was also a pioneer in dealing with concurrency, Java introduced generics really late and it was also built by famous engineers working for a sexy company, designed to appeal to beginners and managers.

<comment><USER4> No. It's not the Java language. It is the developers. They are the ones who have to have 35 levels of abstraction. Why? Because for some reason they think this will make modifying the software they write easier. In reality, no, it doesn't because everyone gets frustrated wading through the abstractions. If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in, then it is really hard to make any real changes to the code.

<comment><USER5> > They are the ones who have to have 35 levels of abstraction.

Have you seen FizzBuzz: Enterprise Edition ?

[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

<comment><USER6> I'm going to be laughing about this for days.

<comment><USER5> its beautiful, not only is it absurd and hilarious, but it says so much. Not as a direct diss to java, but how badly a simple task can get over-designed to the point of being indecipherable. What would be great is if they added some kind of CRM or e-commerce to it, and donated the proceeds to charity. So like, could "Pay as a service" or sign up for "fizzBuzz as a service" and pay to run fizz buzz up to certain limits.

</comment></comment></comment></comment></comment></comment><comment><USER7> After doing this shit professionally for more years than I could care for anymore, when I see programming language or framework comparisons I immediately think of something like[1]:

"Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver".

And then I imagine myself going back to using my shitty old Phillips screwdriver set to screw in a few screws in a non-optimal fashion and someone might say "Wow, thanks for hanging my door!" and I imagine the surprise on my face as I realize that people want functioning doors and are not too bothered about which brand of screwdriver was used to achieve that.

[1] [http://blog.cnccookbook.com/2015/08/19/8-brands-to- consider-...](http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-for- the-worlds-best-screwdriver/)

<comment><USER8> What a crap, supercilious comment. Yes _laypeople_ want functioning doors, but this is not an article for laypeople, it's an article for engineers. What we want are tools that allow us to build performant, maintainable, reliable code.

Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.

<comment><USER7> I used Angular Material to build a website. I dunno if you've ever been to the Angular Material website *[https://material.angularjs.org/latest/](https://material.angularjs.org/latest/)), but check it out if you haven't. You see that nifty looking navigation bar on the left? You can't actually build that using Angular Material given all those wonderful components they list there. There are entire blog posts created so you can make a similar looking navigation menu [1][2]. There are so many things missing or incomplete in this framework that you'll only realize when you try and build a "real" application with it. Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2. Yay for the people who just want functional doors.

[1] [http://blog.vizuri.com/creating-your-own-angular-material- na...](http://blog.vizuri.com/creating-your-own-angular-material-navigation- menu) [2] [http://stackoverflow.com/questions/28389671/create-a-menu- li...](http://stackoverflow.com/questions/28389671/create-a-menu-like-in- angularjs-material-website)

Let's talk about Material Design Lite. Go check that website, especially the components page ([https://getmdl.io/components/index.html](https://getmdl.io/components/index.html)). It's really nice and responsive, try changing the size of your browser window and see how the navigation bar collapses to the top. Damn this looks like a great framework, I'd like to do the same thing in my app. Imaging the surprise when you can't actually do that using the framework out-of-the-box. Oh by the way, forget about MDL, all the developers have moved on to Material Components for the Web ([https://github.com/material-components/material- components-w...](https://github.com/material-components/material-components- web)). So much for the guys who just want to hang a door, there's a new brand of screwdrivers on the block.

It would be great if the so-called "engineers" could spend some more time creating a complete toolbox instead of reinventing new screwdrivers every month.

<comment><USER9> You're forgetting that this is every web developer's dream. To always keep learning new frameworks (to do the same fucking thing) over and over.

<comment><USER10> I get that this is the easy way to see it from the outside, but:

\- You don't have to learn every new framework. Google has 10k+ Angular 1 projects, this stuff doesn't go away after hitting critical mass.

\- This constant iteration has lead to multiple production-ready UI paradigms that were just relegated to FP research. Try using Angular 1 or vanilla React, and then do something with vanilla Android. Or GTK+. Do we want GTK to be our baseline for UI work? Qt is nicer, but it's definitely playing catch-up.

You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.

<comment><USER11> > Everyone opts for electron

And I'm just sitting here, using [https://github.com/ReactiveX/RxJavaFX](https://github.com/ReactiveX/RxJavaFX)

<comment><USER12> Is JavaFX okay? Or maybe even good? What's wrong with it? (Not polished enough, not maintained enough? Not updated fast enough?) RxJava seems pretty okay.

<comment><USER13> Off the top of my head: misses some UI elements / widget types (spinner / numeric entry). UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).

And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).

<comment><USER11> > misses spinner

[https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...](https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/Spinner.html)

> UI bindings require a lot of manual converters instead of doing conversions > that p.e. WPF does out-of-the-box (like double to string when using a text > box; principle of least surprise).

You can use String.valueOf, but usually don't want to do that. And how do you want to represent the float? With Scientific notation, Engineering notation, or purely decimal? This is not simple.

> And (the worst) it's not conceptually compatible to the model classes > (abstract tree model) that almost every UI framework (including Swing) > provides. Instead, tree nodes have to be manually instantiated).

Or you use the FXML bindings for creating them from XML?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I really wanted to love Scala, and for the first few days I did. But it was a never ending story learning this language. It is so complicated and feature rich that there's just too much to learn. I couldn't just read someone's code without stumbling on some special syntax or language feature that handles a once in a lifetime use case that I didn't know about. Eventually I gave up on Scala.

<comment><USER15> I don't really understand all those complaints. I am using it professionally since 8 month and I only had problems the first two month, then I felt good, even if there is always something else to learn.

For the complexity problem, here is how I manage it : the functional programming scala is scala, everything else is garbage included for java compatibility. It works like a charm.

I can't think of a language I could feel better with.

<comment><USER16> Mostly agreed.

There are some pains associated with Scala, though. Sometimes self-inflicted by people who want it to be like Java: for example, most ORMs for Scala suck. A team at my office tried to use Hibernate to disastrous effects (Scala and Hibernate's hostile takeover of collections don't play well). Even some DSLs like Scalike tend to also be painful and unwieldy. I also dislike Play and its multitude of quirks and incompatible versions.

It used to also be the case that both Eclipse (ScalaIDE) and IntelliJ IDEA were almost unusable with Scala, in particular constantly resulting in spurious compilation errors. I've no idea if Eclipse got better -- completely got rid of it after decades of using it with Java -- but IntelliJ did get better and mostly works (though it still cannot always compile Scalike DSLs).

But even with all of the above, when I have to work with Java code again I cringe. Even with all the pain, Scala is simply better to work with for new code.

<comment><USER17> Ever asked yourself why it's taken so long for Scala IDEs to be minimally useful? The complexity of the language makes it difficult to optimise compilation and the language is still suffering. Paul Phillips left Scala because of this and he said it was impossible to rectify without re-inventing the language. This shaky complexity is why I refuse to build valuable projects with Scala.

<comment><USER18> and yet Paul Phillips still, to this day, writes Scala. Think about that, he's one of Scala's biggest critics; still Scala all day, everyday.

There's nothing "shaky" about Scala's complexity, it's quite stable, and not going anywhere until Dotty lands circa 2020.

Despite everything (slow compiler, average tooling, implicit/operator overloaded "magic" code bases, etc.) Scala will draw library creators (like those behind Spark, Kafka, Akka, Play, etc.) which in turn draws developers, resulting in the thriving ecosystem backing the language.

Scala will live on despite itself; the ecosystem is what will carry the language to the Dotty land and beyond.

<comment><USER19> True. Scala jobs growth is still very healthy too: [https://www.indeed.com/jobtrends/q-scala.html](https://www.indeed.com/jobtrends/q-scala.html)

</comment></comment></comment></comment></comment></comment><comment><USER20> Ive used Scala as both "better java" and as "worse-haskell" in two different teams. Both times it was much more pleasant than doing Java.

<comment><USER21> Here here.

Im new to scala and I love it.

Also sbt > maven!

<comment><USER22> it's "hear, hear". The expression Comes from the English Parliament back in the 17th century.

<comment><USER23> Now the really puzzling question is: How would someone learn about this particular saying without seeing it in writing? Are there actually people still using "hear hear" in everyday speech?

<comment><USER21> Ironically, I've have an English bachelors degree,and I've never seen it in writing before, till now! Language is active learning. There's no real way to avoiding these pitfalls, besides reading and engaging with others. I'm OK with it aslong as those offering corrections do it kindly.

I've learned German, too. German is 'difficult', not because of its grammar, but because how mistakes are handled. Which is often with harsh commentary, ridicule or confusion. Not sure why that is the case, but English speakers are often kinder when offering corrections!

<comment><USER24> To disprove your last point: I'm curious as to how you achieved such a degree while using "till" as shorthand for "until". Are you sure your Bachelor's wasn't in agriculture? ;)

Joking aside, I think it's a consequence of English being a very complicated language with all sorts of borrowing from different language families. There's almost no such thing as "correct" English, and attempts to reason about it in a prescriptive rather than descriptive manner will almost certainly fail. Whether that's a good or bad thing is up for debate, but mistakes happen either way, and I reckon the average English speaker to be a bit more cognizant of that, recognizing that nobody - oneself included - really has a perfect understanding of the English language.

<comment><USER25> "Till", in fact, predates "until". [http://english.stackexchange.com/questions/6989/what-is- the-...](http://english.stackexchange.com/questions/6989/what-is-the- difference-between-till-and-until). See, for example, the marriage service in the Book of Common Prayer (1662): "Till death us do part".

<comment><USER26> My advice as a native English speaker here: In my entire life, I've only seen or heard "till" in the following contexts, given in order of frequency:

1 A cash register (noun)

2 In very poorly constructed resumes

3 In the farming sense (verb)

4 In internet forums alongside poorly written English

5 Shakespeare and other literature from several centuries ago.

So my advice: unless you're a time traveller, use "until".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> Kotlin 1.1 + Reactor ([http://projectreactor.io/](http://projectreactor.io/)) has erlang style messaging passing paradigms, world class tooling and is gradually replaceable (class-by-class) for Java.

It's going to be interesting comparing the adoption curves of both these languages especially after Java 9 and most importantly Graal ([http://openjdk.java.net/projects/graal/](http://openjdk.java.net/projects/graal/)) .

<comment><USER28> > erlang style messaging passing paradigms

Or you could, you know, go directly to the source while experiencing a pretty nice language on its own [http://elixir-lang.org/](http://elixir-lang.org/)

<comment><USER29> elixir is for rubyists, really. dynamnic typing.

<comment><USER28> Guards, pattern-matching (even down to the structural level) and typespecs cover a lot of the ground that static typing would, without forcing the type rigidity. Although Haskell seems to have admittedly cornered the static typing market

</comment></comment></comment></comment><comment><USER30> I once drank the Scala cool-aid as well. Even wrote an enthusiastic article about it [1]. Since then, my enthusiasm has been replaced by disappointment: the JVM interop is a lie, as Java libraries often are a bad fit, people won't have time to write the extensive wrapper code needed to hide it, and as a result ugliness starts permeating your codebase - yes, bad, but that's how teams under time pressure work; the multi-paradigm-and-widening (back in 2009, Scala was a smaller language) is one big headache - everyone has an opinion of how you should write code in Scala, so inevitably you spend a lot of time debating features you should or shouldn't use in your teams (instead of writing code. In Elixir, we never have to debate paradigms, we write code); sbt is a sorry mess - no-one understands it and it's slow.

I still think it's a very well designed language, the choice of the JVM+Java ecosystem as the target just has bogged it down with legacy crap like everything else on that environment and the designers should start to make some choices instead of offloading that on every single development team in the world. I think that "single-paradigm" is one of the reason that simple languages that get shit done, like Golang and Elixir, are so successful these days.

Were I bound to the JVM, I'd still give it a good look (not sold on Clojure or Kotlin yet and it _is_ nicer and less frustrating than Maven+Java if you keep it simple); I'm just not married to the JVM so can freely consider other options.

[1] [http://www.artima.com/weblogs/viewpost.jsp?thread=260478](http://www.artima.com/weblogs/viewpost.jsp?thread=260478)

<comment><USER31> I took a sip of Scala, and I found it very interesting. Other than LISP it was my first functional language that was being used for something other than a college course project. I liked having been made to think differently about the code I wrote - fitting things into a functional construction.

That being said, I found that many of Scala's features can quickly become drawbacks. I'm not a fan of JVM languages, but I've effectively programmed in Java and there are many useful, well-written frameworks and tools built on top of JVM languages. sbt is a pain in the ass, and I learned that fairly soon in my Scala exploration. Our project also used many Java libraries and it was jarring (no-pun) to switch between the "pure" Scala and the grafted-in Java.

The person or community you enter Scala through can also be very influential on your experience. Though that's likely to happen with any language. The developer leading our project was extremely opinionated and felt that no other language was superior. He forced, oftentimes to the detriment of progress, abstractions in the code that made it nearly inscrutable. He became tiresome during discussions because his speech was mostly a stream of jargon. I could never tell what he was trying to achieve by using all the more complex features of Scala... other than job security.

</comment></comment><comment><USER32> As someone who is currently having to deal with a monolithic Java app built on spring, hibernate, aspect weaving, code drenched in null checks, and other questionable architecture choices, this article makes me want to switch to Scala, and the reasons are mainly community, not programming language.

I think you could do a lot of the above In Java although the code would be a little boiler-platey. But why do people care about boiler plate so much? Hasn't GoLang shown us that boilerplate is not our greatest enemy?

<comment><USER33> It's not the boilerplate. When you take some of the best java developers on the planet, after a couple years you end up with a AbstractSingletonProxyFactoryBean, so what is a mere mortal supposed to end up with? Evolve any Java codebase for N years and the result is the same.

[http://docs.spring.io/spring- framework/docs/2.5.x/api/org/sp...](http://docs.spring.io/spring- framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

You could also make a similar argument for Scala. Not boilerplate, but other problems. There are some epic scala flamewars out there. A mortal could be forgiven for looking at an "idiomatic" scala codebase and scratching their head, looking at all this higher order "stuff" and wondering, "but where is the actual code, that does the actual thing?" And I'm not sure there exists a human on the planet who knows what idiomatic scala is. The whole point of the language was to make some impossible compromises, and as such you can kind of feel forces inside the language in tension with itself, not in alignment. Perhaps FP and OOP are not meant to be unified.

<comment><USER34> > Perhaps FP and OOP are not meant to be unified.

The only thing that keeps FP and OOP from integrating properly is the "Everything is an Object" mentality. Pure-data structs aren't objects, and you start making loads of weird compromises when you force them into an object- shaped hole. Java (and, I guess, C++) kind of pushes classes as better structs, and lots of bizarre problems come from there.

I find that, when I'm programming in the small, on the lower-level implementation details, FP design principles serve me best. Inversely, when thinking about the structure of my applications, OOP principles suit the problem better.

This sort of design is what leads some people to say that Erlang is the most OOP language out there — Erlang processes map very naturally to objects in this sense, and it is, obviously, a functional language through-and-through.

<comment><USER35>
       The only thing that keeps FP and OOP from
       integrating properly is the "Everything
       is an Object" mentality.

Actually ... in Scala everything _is_ an object.

Functions are special cases of objects. That's Scala's great insight and it reverses what people used to think: everything is a function, and OOP is a special case of FP (this is e.g. OCaml's idea). If you look at Scala's foundations (DOT -- the dependent object calculus) this becomes pretty clear.

Could you be referring to the difference between pure programming and stateful programming? Note that OO can be done in a pure way.

</comment></comment></comment></comment><comment><USER36> What appeals to me about Scala is that is expressive and concise. It also encourages some healthy patterns like such as making distinctions between mutable and immutable containers, using futures/promises for asynchronous functions, using option types to prevent null pointer exceptions and many many others.

It influenced my programming style a lot and I try to prefer those patterns when I use other languages as well.

Some people like more advanced aspects of Scala, and like to flirt with category theory and hardcore functional stuff. Personally I find it hard to express myself in terms of higher order kinds, monoids, functors, semigroups and such. You can learn them but it's a bit like switching from qwerty to dvorak... if you have to look at the keyboard each time it doesn't make things simpler for you.

</comment><comment><USER37> Scala appeals to those who love programming languages. Java and a few other languages appeal to those who love making software, something that Scala is terrible at.

<comment><USER38> Scala is a language of compromises. That's part of its success! I think it appeals to people who want to try out many different types of language styles, but the programming language purist in me hates it because it's not opinionated and is such a mish mash.

<comment><USER39> > Scala is a language of compromises

Scala tries to be everything at once, it's hardly a language of compromises. It was successful because when it was created Java sucked and now of course people are stuck with Scala deployments as nobody can decipher all that code. Java still sucks but less that it used to be. It needs type inference for like yesterday. The biggest drawback of the language is the slow toolchain.

</comment></comment></comment><comment><USER40> I have used Scala to build the backend of [https://huu.la](https://huu.la) for years, which is not a small codebase anymore, I love the language itself, it's fast, typesafe, productive, and gives access to the rich Java ecosystem. The only thing I dislike is the tooling, especially whenever I open eclipse, the fan just screams to hell and it's still slow as a snail.

<comment><USER41> Have you tried using IntelliJ?

<comment><USER42> Totally agree, time and again, I see people use Eclipse (for pretty much anything) would be ten times better off in IDEA.

</comment></comment></comment><comment><USER43> Regarding json serialisation, at the time I was using scala, I found quite "unusual" that the play library could not deserialize a json with more than 26 fields (or something like that). I hope they fixed it in the newer versions, but still I don't get why to rewrite all the libs from scratch, when java has good ones available.

<comment><USER44> As asked (and answered) here[0], it used to be a Scala case class limitation. There are tricks to do it anyway, like manually mapping fields by writing your own JsReads or JsWrites for your object.

[0] [http://stackoverflow.com/questions/20258417/how-to-get- aroun...](http://stackoverflow.com/questions/20258417/how-to-get-around-the- scala-case-class-limit-of-22-fields)

</comment></comment><comment><USER45> I wouldn't characterize Scala as a better Java any more than I would Python as a better C.

Kotlin is a better Java.

Groovy is a scriptable Java.

Scala is a "worse Haskell" or an "extensible Swift", with close Java interoperability (that last part leading to the warts).

<comment><USER3> > _Scala as a better Java any more than I would Python as a better C_

The difference between Python and C is huge because C is not interpreted and doesn't do _automatic memory management_ , which is actually the deal breaker for many apps. Saying that such a difference exists between Scala and Java is simply _wrong_. It's wrong starting from the fact that both are garbage collected, running on top of the same VM, having the same performance and thus targeting the same application profiles.

> _Scala is maybe a "worse Haskell", with extensive Java interoperability_

Haskell is a language I like and that I'm in the process of grokking, being a continuous inspiration, but to tell you the truth, to the contrary I think Haskell is a less practical Scala. Scala follows the pragmatism of the ML family. OCaml is another pragmatic language. Clojure and Racket are too.

Empirically speaking, Haskell is good at being a trend setter in the FP community, but besides really cool libraries and concepts, I don't see much in the way of applications built by Haskell folks. Some big companies have built complex systems on top of Scala, not to mention projects like Kafka and Spark, which can also credit Java and the JVM. For OCaml, even with a much smaller community than both Scala and Haskell, you have some really cool stuff like MirageOS. What does Haskell have to show for, besides badly documented libraries and compiler implementations?

Don't get me wrong, correlation does not imply causation, maybe Haskell simply has a popularity problem, but the onus is on the Haskell community to prove that Scala, OCaml and others are inferior alternatives to Haskell by showing some results. Because at the end of the day it's the final artifacts that really matter.

<comment><USER46> Haskell has lots of large projects written in it.

Besides the ones others have mentioned, Haxl is probably one of the bigger known industry uses of it. It is used at facebook as their spam filter:

[https://github.com/facebook/Haxl](https://github.com/facebook/Haxl)

If you scroll to the bottom of that github page, you can find several papers and articles that go into detail about it.

<comment><USER47> "Lots" is pretty relative. Haskell has lots compared to what? Arc[0]? It's not in the same league as Scala, that's for sure. And that also means that it is orders of magnitude away from the likes of C, C++, Java, Python, Perl, Ruby, etc. Haskell is and always will be a niche language for more experimental or research-y purposes that somewhat occasionally have real world uses.

That shouldn't be a bad thing. Haskell, like Prolog, SML, Simula, Smalltalk, and Lisp, have influenced the world of programming far more than one could ever expect if we only measured success by large project usage. I don't see why Haskeller's need to defend their meager industry adoption so much. It has some pretty good adoption compared to most research languages, but its industry adoption is not that great for a general purpose language, and _it doesn 't need to be_.

[0] [http://paulgraham.com/arc.html](http://paulgraham.com/arc.html)

</comment></comment></comment></comment><comment><USER11> This post contains several wrong statements.

First, Java does support macros – you can use Annotation Processors normally (as Butterknife, Dagger, and other projects do), or you can use Annotation Processors to actually get the AST and modify it (not supported officially, but used by projects like Lombok).

Second, Java has no type classes – this is technically true, but not exactly. The mentioned example can also be handled with Java 8's interfaces, as they support default methods and private or protected methods.

Due to that, you can define a method instead of the writes() field, and then use an interface-defined default method to handle actual serialization.

If combined with Annotation Processing, this allows easy, simple, compile-time generation of JSON serialization (and yes, I've written stuff like this before, so I know it's actually usable, and not too complicated).

</comment><comment><USER48> Yeah, Scala is not a better Java. And Scala is still a very young language. With a lot of interesting features, yes, but also a _LOT_ of backward and broken things.

Have you tried to serialize something to JSON ? Yes ? Which one of the _TWELVE_ libraries did you use ? Need to compile something ? You can take a coffee break. You defined a `unary_-` function ? I'm sorry you can't search your code to locate the calls.

<comment><USER45> Scala grew up in a different time then Java.

Have you tried to serialize something to XML in Java? Which of the fifteen libraries did you use?

</comment></comment><comment><USER49> Kotlin is a better Java. Scala is just something else.

</comment><comment><USER50> It is also about tooling and libraries. I find Scala ecosystem to be behind Java ecosystem couple of years (SBT versus Maven/Ant/Gradle, collection libraries...).

And Kotlin makes this debate irrelevant anyway.

<comment><USER51> That's completely not true because Kotlin has something near zero adoption. I have a Kotlin fanatic coworker so I know all about the manifold benefits of Kotlin -- it sounds awesome.

Never had a project OK'd to use it, probably never will. They obviously need a PR and marketing department; otherwise they end up being the CouchDB to XYZ's Mongo.

<comment><USER50> I usually hava Scala/Java debate before new project (or refactoring) is started. And here is Kotlin relevant.

Kotlin is bundled with Intellij Idea. And Kotlin has smaller adoption barrier.

<comment><USER51> If you work with other teams, especially onprem or offshore teams, they use netbeans or some other piece of shit IDE. It's just a fact. They know J7, can be convinced to try J8, once read a blog that mentioned Scala, and don't know what the fuck Kotlin is.

<comment><USER52> On the other hand, if you decide to use Kotlin, you'll post a job listing, get only a handful of candidates, and nearly all of them will be outstanding and the type of curious, driven engineer that you'd normally have to sift through a mountain of dime-a-dozen, uninspired Java hacks to find.

It's not until you've had to hire Java devs that the mystery of why so many people feel the need to ask a question as facile as FizzBuzz becomes clear.

</comment></comment></comment></comment></comment><comment><USER53> What "better java" means? It means I can build the same stuff but in a better way. Easier to read, to maintain, and at least with the same performance. Scala has a big plus on asynchronicity, but the article doesn't even try to go there. Libraries like Akka, FS2, Monix, ScalaZ etc are not mentioned either. In Scala I can use everything from Java and much more, and this is why is better.

I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.

<comment><USER54> A "better Java" means keeping the same concepts and paradigms as Java, but fixing some of the design issues. That's what Kotlin is.

Scala on the other hand is a completely different beast, but some people use is as "a better Java" because it doesn't force you into its paradigms. You can code in Scala without using case class, with var everywhere, etc.

It can be handy to fallback to "Java style" when you don't know how to do it in idiomatic Scala, but at the end of the day if you don't want to embrace the key paradigms of Scala it's better to use a different language.

</comment></comment><comment><USER55> My follow-up question would be: Is Scala still competitive to modern languages like Swift and Rust?

I experienced several drawback according to library quality and code-safety. There are too many small details that left me with an unpleasant feeling (I would take ScalaNLP/Breeze for example).

But my central issue is the VM/GC dependency. In times of GPU computing, native interface programming becomes a burden. The knowledge of object ownership improves code readability. I feel uncomfortable leaving object lifetime to a background process.

<comment><USER56> It depends how you define "competitive". If you are trying to collect hipster points then Scala is not going to help you but let's be real. Nobody is writing big systems in either Rust or Swift, these are playgrounds for people at the moment.

<comment><AUTHOR> I am big fan of Swift and Scala... and, to be honest, for Swift there's a long way ahead before a big system can be deployed... tooling and libs are not there, also not considering that the lack of ABI stability makes the source code necessary for any external dependency.

</comment></comment></comment><comment><USER57> Not a myth: Kotlin is the better Java

Although Kotlin does have a lot of stuff that technically allows to write weird code, most of that (eg. extensions) is around for better interfacing with Java, and normally not used in pure K code.

</comment><comment><USER58> So much Java hate in here. I understand most people think Java devs live in caves, toiling away thinking Java and XML are the only technologies in the world. Still, this Java dev has used Haskell, Prolog, Ruby, Python...etc. I have left the cave. I've seen the world. It's nice, but Java still provides a ton of support and tooling to get things done. People have done bad things in the name of Java, and they have done fine work, too. Most of your practices from the bad old days of 90s to early 2000s Java are in rapid decline.

It's not my favorite language (I heart Ruby), but a practical choice for many projects. Don't kid yourself; once you leave "Hello World" land, and have to deal with a variety of features, platforms, technologies, you can't hope to roll your own salvation--no matter how expressive your favorite language. And you don't want Johnny's 3 star github project solution, sorry. You want a battle tested beast, with the scars to show for it. That's Java for you.

<comment><USER59> The software engineering community is bottom heavy right now, driven by improvement in accessibility of various platforms (eg Rails), and the prevalence of the San Francisco tech startup bubbles (where tens of thousands of developers have 10 jobs on their resume but never worked on one with more than 20 developers). And then these people go on and get lucky, and you have unicorn billion dollar companies built like if they were startups.

That creates a weird/interesting world, where the #1 priority is "how long does it take to use this if I've never heard of it before, and how quickly can I build an MVP with it"

That...changes priorities. A lot. Java is the other end of the spectrum, being born long before that world existed, and probably went a little too far. Fact remain, Java was born in a world very much opposite to what the majority knows today. So it will get flack from people who don't understand (or worse: don't remember, even though they were there!) why it is that way, and why it's (sometimes! Not always!) valuable.

For a mature project, I don't give a damn how quick it is to learn or how fast you can get your login form ready. The login form was written 10 years ago. I want to see how quickly you can find, debug, diagnose and fix issues or how quickly can a new module be added to the code base while being consistent with the rest of the architecture.

The java ecosystem is actually pretty good at it. At this point I haven't done Java in a very, very long time, but a large part of our stuff at work uses it, and I can open one of our hundreds of repo, look at it, and I know what it does and how I could extend it, even though I've never used the framework its built on.

</comment></comment><comment><USER60> Admittedly biased but can't help but think this article reads like something stating that Scala is indeed a "better Java".

Well, perhaps not "a better Java" but at least "better than Java".

<comment><USER61> That seems to be the point. Proper or idiomatic scala code uses tools only available to scala. I used scala for a while. It has some neat tricks that I grew to like, but I think it ultimately had a problem I noticed in Ruby: there are many "right" ways to do things and each team has its own culture. This makes learning foreign codebase pretty hard--especially with how dense scala code is.

</comment></comment><comment><USER62> Though correct this author makes a key assumption I dispute. "Scala as a better Java" === "people code in the same way in Scala & Java". This assumption leads to the focus on various Libraries and accepted standards.

But, at least to me, "Scala as a better Java" === "Scala with better syntax and less boiler plate but access to Java libraries if you need them".

Java is a brilliant language. But nothing can survive without some assumptions being voided over time. Despite that, many institutions relay on the good parts of Java (which there are many). Scala is a middle ground which has that backwards compat but with fixes to invalidated assumptions (syntax that has gotten clunky over time, lack of functional constructs)

</comment><comment><USER56> Is The Scala Evangelism Task Force back in action? I'm game.

</comment><comment><USER63> There are at least two things more important than Scala being a cleaner Java:

1\. The IDE 2\. Oracle's claims on Java IP

A good IDE is more important than Java being verbose, and the only way Scala will displace Java is if Oracle win suits and makes Java expensive to use.

</comment><comment><USER64> I wonder if standard practices for Kotlin will diverge from Java in the same way. I could guess either way. On the one hand, Kotlin maps between its properties and Java's standard bean getters and setters, whereas Scala does not. On the other hand, a desire to share code between the back-end and statically optimizable JavaScript (and Android packages) will hopefully push Kotlin libraries away from reflection and toward build-time code generation (presumably based on annotation processors). Then again, the latter option is also available to plain java (see Dagger 2), if only the broader Java community would embrace it.

</comment><comment><USER65> Question - can I simply drop scala into an existing java based maven build? Using something like the scala-compiler plugin [https://mvnrepository.com/artifact/org.scala-lang/scala- comp...](https://mvnrepository.com/artifact/org.scala-lang/scala- compiler/2.12.1)

<comment><USER66> Scala is compiled against the jvm, so you're able to e.g. compile a scala jar and call it directly from java.

A couple of caveats, though.

\- collections are different. You'll need to use helpers from JavaConversions, etc. to e.g. turn a Scala list into a Java list. \- scala methods with default arguments are irritating to call from java. \- avoid the more esoteric scala features

</comment></comment><comment><USER67> > With compile-time DI, you make service classes accept lower level > dependencies as constructor parameters. In Scala, constructor parameters are > accessible from regular methods, so most of the time, these services could > be completely stateless. This approach is also advocated by several Java > (and .NET) experts, but it's by no means mainstream. Interestingly, Scala > developers have an advantage over Java/C# users, because they can > significantly simplify the implementation by combining a macro-based library > with lazy definitions:

Asking for a dependency explicitly is service location not dependency injection. Your code there does not solve anything better than a regular service locator in a constructor would. The point of DI is that it's abstracted from the user code and the user doesn't have to care about these `wire` calls and can test it "as if dependencies were just passed regularly".

<comment><USER32> I don't think you're understanding what the author was saying. The author is advocating for constructor-based dependency injection, which incidentally, I also advocate for. There is a macro-based library in Scala, MacWire, that helps write the constructor calls for you, essentially acting as an auto-wire- like replacement to Spring and Guice, except that it does all its work at compile time. This mean you catch errors much earlier in the build and deploy process.

<comment><USER67> Where are the wire calls performed? Not in the constructor but in an initialization file?

<comment><USER32> I'm not familiar with MacWire, but I believe it's powered by macros. You can think of a macro as a function that runs at compile time. It's input is a syntax tree representing some code, and it's output is an arbitrary syntax tree representing code. The compiler, while processing source code, will recognize places where a macro should be invoked on some syntax. It will call the macro on that syntax, then replace the syntax with the output of the macro.

In this sense, you can imagine a macro that takes in the source code for a class that has wire calls, and rewrites the wire calls into object constructor calls based on introspection of the syntax and types in the class.

If you're familiar with C macros, they are technically the same kind of thing, although very basic, error prone, and unpleasant to work with. If you want to learn more about macros, I would recommend starting with a simpler, more sane macro system like one in Scheme, or, if you want something that looks more like Java, Nemerle ([http://www.nemerle.org/About](http://www.nemerle.org/About)).

Scala's macro system has a bit of a bolt-on feel since the language wasn't designed from the ground up for macros. That said, I applaud Scala's effort to try to figure out how to integrate macros into their core language and hope they are successful in the future with Scala Meta ([http://scalameta.org/](http://scalameta.org/))

</comment></comment></comment></comment><comment><USER68>
        Not surprisingly, this approach has become very popular in
        recent years and made the Play team consider promoting it
        as the default in the upcoming version of the framework.

It's not really the default. It's just another reasonable choice without adding guice as a dependency. Even the Starter templates include guice: [https://github.com/playframework/play-scala-starter- example/...](https://github.com/playframework/play-scala-starter- example/blob/SNAPSHOT/build.sbt) Play! also does not enforce somebody to the Scala Ecosystem, it doesn't come with many functional patterns (but they can be used with it). The overall goal of the last versions was getting a DI approach, so that the testability of an Applikation can be greatly improved and also the testability of Play itself.

</comment><comment><USER69> I am a long time Java developer and, believe it or not, regularly write important new product features in concise, performant Java 8.

I have looked at Scala time and time again and am not sure what to think. It is currently a popular choice for big data munging -- I'm into Apache Flink and most Flink jobs are way easier to read when written in Scala VS. Java.

But I also feel like Scala requires more decisions per line of code than Java, which makes it a more demanding day-to-day language. Also, it seems to have lots of dark corners. But these are really my impressions based on limited experience, so I am likely wrong.

Also, my limited experience indicates that IDE support for Scala is quite behind that of Java.

But I am still open to it.

To get to my point, actually my question: Where should I look to learn quality, ideomatic Scala?

My preference would be to focus on small example programs that do one thing well while demonstrating the correct, native use of Scala.

Thank you.

<comment><USER70> I'm just starting to pick up Scala (and functional programming for that matter) and I've been working my way through Functional Programming in Scala[1].

So far, it does a good job of teaching functional programming by taking stateful scala code, and refactoring it using pure functional approaches. The result might be considered quality, ideomatic scala.

[1][https://www.manning.com/books/functional-programming-in- scal...](https://www.manning.com/books/functional-programming-in-scala)

</comment></comment><comment><USER71> The very first example is about DI and advocates MacWire to do that in Scala:

lazy val userDao = wire[UserDao]

I come from Java and when I moved to Scala I wanted to use DI to mock dependencies in my unit tests. The logical choice for DI seemed to be MacWire, however it did not help me with the mocking at all.

In Java you have Mockito and annotations such as @InjectMocks that inject all your mocks into your SUT automagically. In Scala, regardless if I used MacWire or not, I had to override my SUT's implementation and its dependent fields by myself, or use constructors that take all the dependencies as arguments so I could override them in my tests. Luckily this is much easier in Scala than in Java, but to me MacWire was a disappointment.

<comment><USER72> Eventually you learn not to need mocks. It's a long road though. An important first step is making your dependencies very very simple functions that are trivial to define on the fly.

<comment><USER71> Yes I agree, in Scala mocks are not as useful as in Java and the Scala language has some features that make it easier to work around them.

However what I don't understand is what is so great about MacWire. Maybe I'm missing something but I always believed that the main advantage of a DI framework was that it facilitated mocking. If this is not needed in Scala, then what is so great about MacWire?

<comment><USER72> You're right. The biggest thing that DI frameworks have historically done for me is make mock injection easier.

There are other benefits, however. \- Manual wiring generally has quite a lot of boiler plate (even in Scala, especially if you use free monads) \- DI frameworks enforce a pattern of behaviour. This can be especially helpful when navigating a project.

Having said that, whether these benefits are worth the cost of a DI framework is debatable. My current weapon of choice is FreeK...

</comment></comment></comment></comment><comment><USER73> Even though Scala might not be the answer, I still think we need a replacement for Java.

All the Java enterprise projects I know suffer from the same problems; incredible complex project structures, a lot of "dead code" (e.g. empty Java interfaces), XML, money being burned for engineers fighting with Tomcat or Glassfish, slow database operations because of an ORM centric development and so on.

I am not sure, what's going to be the solution but from my perspective Java as a language needs to be replaced.

<comment><USER74> Java 8 is much better for programmer's sanity. If you could force people to jump to that, and completely burn down some areas of the ecosystem (like XML overuse), maybe Java could actually be saved.

Alas, I think backtracking on parts of the ecosystem is a hard thing, and I don't see it happening soon.

<comment><USER74> Adding: I was messaged by someone who interpreted my comment as if I was saying "Java 8 is better than Scala". That's not what I meant. I mean that with Java 7 and 8, _Java_ the language is more bearable than it was in the past, so Java the language is in less dire need of being replaced by something else.

</comment></comment></comment><comment><USER75> Scala quicky got my favourite language. I really like handling data using functional and imutable concepts.

Great libraries for db access (slick) and json handling (sparay-json) were not mentioned in the article, I wonder why slick is not even mentioned in the comments, it is really nice!

Using scala with these and combined with akka and futures feels like a so natural way of programming for me.

</comment><comment><USER76> " _With compile-time DI, you make service classes accept lower level dependencies as constructor parameters. In Scala, constructor parameters are accessible from regular methods, so most of the time, these services could be completely stateless._ "

Um...the constructor parameters become invisible instance variables. It's not stateless.

</comment><comment><USER77> You might want to try Kotlin which is basically just a Turbo Java without the baroque fluff Scala brings to the table.

</comment><comment><USER78> It's not a better Java, it's a worse Java.

I like the late-time binding in Spring, it is a very complete answer to the problem of "shipping a set of binary components" and "configuring those components endlessly". Why is that a problem? Because your build is slow and because it's dangerous to patch the source code every time you want to tweak the configuration, ...

Trouble is: a lot of folks "learn" Spring working on a project somebody else started by cutting and pasting and searching for answers on Google and Stackoverflow.

You can learn some things that way, you cannot learn Spring that way. If you read the manual a few times straight through you realize that it makes a lot of sense.

</comment><comment><USER79> Did anyone switch to Clojure from Scala? Sounds like an attractive choice given the complaints.

</comment><comment><USER80> The only data layer for Scala that matters is Spark and Data frame.

<comment><USER81> To be pedantic in Spark 2.0 it is now Dataset. DataFrame is now an alias for Dataset[Row].

</comment></comment><comment><USER82> Nice examples!

</comment><comment><USER83> "STOP STOP, It's already dead"</comment>


Update on the upcoming NavDB v0.5.0 release - <AUTHOR> https://navdb.io/2019/05/01/update-on-the-upcoming-v0-5-0-release/ <comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

<comment><AUTHOR> Thanks. This update seems like it's not a good candidate for Show HN, but when I do release v0.5 it should be.</comment></comment>


Ask HN: Do you have a desk to sublet for a tiny startup in SF? - <AUTHOR> Hello :-) This might be a long shot, but a shot nevertheless.
We're two founders of a tiny, early-stage startup with no employees. We moved to SF from Zurich 6 months ago and have been working at WeWork. However, we thought it might be more fun to rent a desk at a startup. We're an EdTech company and are working to make math & science tutoring more accessible (orders of magnitude cheaper, better product than incumbents).
If you have a desk with two chairs to sublet or know someone, please let me know (email in my profile), and we'll be happy to get to know you. <comment><USER2> Why did you leave Zurich? : (

Your profile does not have your e-mail address in it.</comment>


I finally did it I launched my fisrt eBook/guide - <AUTHOR> https://makingithappen.tech/ <comment><AUTHOR> I've been in IT since 2006. For the past 5-6 years I've helped mentor several coworkers and other individuals. Earlier this year I decided to create a guide with insights into how to start out and succeed long term. I also threw in my own personal Cover Letter and Resume template.

I'm so happy I've been able to do this. It's been hard since I work full time and my work has actually become more demanding since COVID. I've learned a lot about the whole process and am available to answer any questions.

I'm thrilled to finally have it completed and available to help people!

20% discount code "itpro" is available.

[https://makingithappen.tech/](https://makingithappen.tech/)</comment>


The Perfect Weapon: How Russian Cyberpower Invaded the U.S - <AUTHOR> http://www.nytimes.com/2016/12/13/us/politics/russia-hack-election-dnc.html <comment><USER2> The perfect BS. That a country that

(a) continuously meddles with internal Russian affairs ever after the Cold War,

(b) with tons of sponsored "NG"Os, "watchdogs", journalists paid to publish any old BS about Russian politics IN Russia and outside,

(c) which even openly sponsors the main opposition trying to finally re- install some friendly patchy in power (a la Yeltsin, who will sell the country to foreign interests wholesale),

(d) and which, unlike Russia, which is the pale relic of an ex-superpower, that even that wasn't all that powerful as it was thought to be, actually has the power, money, and global resources to actually make that have an effect (sponsoring 'orange revolutions' nearby, enforcing sanctions, etc),

has the gal to speak of Russia "invading" them and affecting their elections is beyond me. Especially since the one that won the elections had tons of free coverage from all established US media and broadcasters, and huge support in the fly-over states.

These fake cries of foreign intervention are a double insult for all those countries, in Latin America, Africa, Asia, even Europe, that had their legitimate leaders replaced by dictators with the help of US intervention, from the Shah to Pinochet and beyond to today's mess in the Middle East.

<comment><USER3> _[hypocrisy, double standards, orange revolutions, misdirection, blah blah blah]_

None of which has any bearing whatsoever on the simple factual matter of how the attacks happened, and what parties where responsible.

<comment><USER2> > _None of which has any bearing whatsoever on the simple factual matter of > how the attacks happened, and what parties where responsible._

Which I didn't address and I don't care much about. However the attacks happened, and whoever parties were responsible, they were obviously inconsequential to the outcome of the elections.

But pointing out the hypocrisy is important, because it brings things to perspective and shows the absurdity of the complaints.

<comment><USER4> You are raising two points.

One is wrong: These attacks were not "obviously inconsequential", and the complaints of Russian hacking of the DNC are not "absurd".

Your second point ("the US does it too") is not wrong, but should not stop discussion of this particular attack. The U.S. has meddled in elections, but at the very least, the tactics here were new in their scale and effectiveness.

<comment><USER2> > _The U.S. has meddled in elections, but at the very least, the tactics here > were new in their scale and effectiveness._

Compared e.g. to downright sponsoring and conspiring and successfully establishing a military dictatorship in my country (and tons of others)?

Or (for the "new" part) hacking and reading the mails of all world leaders, allies or not?

Hardly new and hardly major.

</comment></comment></comment></comment></comment><comment><USER5> This kind of thing has also happens to smart, tech-savy, people within the tech community. It's sad to me that we are glossing over this issue because it did not happen in the physical world.

Imagine if we caught Russian agents physically breaking into the DNC office, in a Watergate-esque sort of way. I doubt we'd just continue our election business as usual.

I feel like as members of the tech community, it's sort of our job to connect the dots for people. We always lament every time we hear about security breaches on popular websites and want to do something about it. But this is happening at the highest level in our country and I feel like everyone is just kinda silent about it because they don't want to be appear partisan.

</comment><comment><USER6> I'm a bit nervous about some of the proposed legislation that is (ostensibly) protect us from this..I mean the patriot act was supposed to protect everyone from terrorism, but it served to legitimize the surveillance state.

[https://www.congress.gov/bill/114th-congress/house- bill/5181](https://www.congress.gov/bill/114th-congress/house-bill/5181) [https://www.congress.gov/bill/114th-congress/senate- bill/269...](https://www.congress.gov/bill/114th-congress/senate- bill/2692/all-info)

"...develop and synchronize government initiatives to expose and counter foreign information operations directed against U.S. national security interests and advance fact-based narratives that support U.S. allies and interests"

<comment><USER7> "...develop and synchronize government initiatives to expose and counter foreign information operations directed against U.S. national security interests and advance fact-based narratives that support U.S. allies and interests"

This sounds suspiciously close to an official propaganda department. Anything that does not conform to the government narrative will be deemed a foreign information operation.

</comment></comment><comment><USER8> I think the question here, implied but not directly asked is: did Donald J Trump commit an act of treason by collaborating with a foreign power (and their military) to undermine our electoral process?

I don't know that we've seen evidence of that yet, but it's possible that someone such as the NSA has evidence of the collaboration from secret channels.

I certainly believe that a man whose entire campaign was based on lies and whose business dealings are littered with fraud and broken contracts would betray the nation while campaigning to lead it. His economic decisions (and appointments) have already betrayed the very people who got him elected.

So I hope we get a detailed report before Obama leaves office -- because no person should be allowed to serve as president if they've committed an act of treason (and particularly if they committed treason during the election)!

Tl;dr: Spy agencies, please help us know if Treacherous Trump is really Treasonous Trump.

</comment><comment><USER9> This whole article smacks of the NY Times reporting surrounding WMDs in Iraq. Yet again we have some very alarming assertions made by top officials and being parroted by the paper without any actual concrete evidence being produced and displayed to the public. If anything, it's worse because the NY Times is taking the assertions as gospel and jumping to their own conclusions.

 _> In the meantime, the hackers moved on to targets outside the D.N.C., including Mrs. Clinton's campaign chairman, John D. Podesta, whose private email account was hacked months later._

 _> Even Mr. Podesta, a savvy Washington insider who had written a 2014 report on cyberprivacy for President Obama, did not truly understand the gravity of the hacking._

This is the first I'm hearing of any ties to Podesta's emails and Russians. If anything, I always assumed that particular attack was some teenager in Tennessee[0].

In this case the CIA & co absolutely need to publish all the evidence they have linking Russia to the intrusions. The evidence they are claiming could be anything from something as tenuous as "превед"[1] in a log file to something as concrete as a CIA mole participating in the attacks from within the walls of the Kremlin. Right now we the people are being bombarded from all sides with 100% unhelpful bullshit.

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

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

<comment><USER10> At the very least do you believe that the American election was targeted by hackers in Russia? That part seems to be pretty well agreed upon by multiple agencies inside and outside the government.

<comment><USER11> I'll believe evidence - not authority.

<comment><USER12> That's a good sentiment to have.

The evidence has been released by both Crowdstrike and FireEye. They both have fairly detailed writeups of them. Attribution is an important part of computer security. FireEye has a similar reputation for attribution and forensics as Kaspersky.

<comment><USER13> The NYT article mentions that the Russian groups Crowdstrike identified ('Cozy Bear', 'Fancy Bear') were working independently of each other. If two groups gained access independently, how is anyone sure that one or more other groups or individuals didn't also gain access? And the article never makes the link to how Wikipedia came to receive the information, only assumes it was one of the two Russian groups Crowdstrike identified.

<comment><USER12> These are good questions to ask. The right thing for you to do is study how a computer intrusion campaign works and how attribution is done. Everyone has their own limit of when they trust expert advice. For example, I refuse to trust my doctor's advice fully and pull up studies at home to verify what she tells me. It's good to learn more about computer security if it interests you.

It is extremely difficult, maybe impossible, to completely conceal one's pivots, implants, and exfiltration in a computer network. True, it is possible that an attacker that is more capable than GRU/Cozy Bear and FSB/Fancy Bear did just that and exfiltrated the emails and documents. But this is going beyond what the evidence suggests.

</comment></comment></comment></comment></comment></comment><comment><USER14> I don't really understand why there is so much energy being spent trying to spin this into Russia subverting our Democracy. Corporate and government espionage happens. In this case, the results of these 'hacks' has been release of confidential emails and documents. If the contents of these dumps were completely mundane, I do not think it would have been a big deal at all. It's sort of like saying 'information subverted our Democracy'.

</comment><comment><USER4> This has been flagged, but doing so is a mistake. It is a hack in both senses of the term, and clearly merits discussion here.

<comment><USER15> _" It is a hack in both senses of the term, and clearly merits discussion here."_

Agree @mturmon, not happy HN is flagging away stories like this. A lot of security, technical and business questions can be asked and learned from this incident.

<comment><USER4> Exactly, it is hacking in the biggest sense of the term. It is not just run- of-the-mill politics, which I admit, HN does not do well at, and is no fun to discuss here.

</comment></comment></comment><comment><USER16> Security is hard. Look at the email from Charles Delevan. It legitimized the phishing attack on John Podesta, and caused the compromise of Mr. Podesta's emails. All the advice in that email is good, solid, and accurate. But he claims to have typoed one word, where he typed legitimate instead of illegitimate, and the hackers were in. A good reminder that in security, you have to be right every time, and the attackers only need you to slip up once.

<comment><USER17> Not to mention the ancient adage: "In business, nothing is done until it is checked."

</comment></comment><comment><USER7> Looks like they learned from the US.

[https://www.theguardian.com/world/2004/nov/26/ukraine.usa](https://www.theguardian.com/world/2004/nov/26/ukraine.usa)

[http://www.washingtonsblog.com/2014/12/head-stratfor- private...](http://www.washingtonsblog.com/2014/12/head-stratfor-private-cia- says-overthrow-yanukovych-blatant-coup-history.html)

[https://en.wikipedia.org/wiki/CIA_activities_in_Syria#War.2C...](https://en.wikipedia.org/wiki/CIA_activities_in_Syria#War.2C_2011.E2.80.9316)

<comment><USER17> You did read the article, I hope. Including the mention of the extensive 1996 Russian cyberattack on the US?

</comment></comment><comment><USER18> Why do news outlets insist on calling everything Cyber-xyz. This is Information warfare aided by technical tools. It's not the hacking that is the weapon but how and where you release the information gained by those tools.</comment>


The Shirky Principle (2010) - <AUTHOR> http://kk.org/thetechnium/2010/04/the-shirky-prin/

<comment><USER2> I once read something similar: "The primary function of any institution is to preserve itself, and only secondarily to do whatever it was intended for." I seem to recall that it was attributed to a founder of sociology, perhaps Durkheim or Weber, but can't remember. If anybody can trace the source I'd love to know.

<comment><USER3> Just as an additional data point: I've heard something in that vein attributed to Durkheim, multiple times. Unfortunately, I do not know the source, and a cursory search doesn't turn anything up.

</comment></comment><comment><USER4> This is more a statement about bureaucracy than about institutions generally. I might state it as "Bureaucracies will tend to preserve the process to which they are the solution." There are lots of other reasons that technologies might become entrenched, but bureaucracies become entrenched because job security means everything for people working in non-creative or expendable positions.

Or, to consider this from another angle: [http://strikemag.org/bullshit- jobs/](http://strikemag.org/bullshit-jobs/)

<comment><USER5> I was once flipping through channels and stumbled on the channel that records the meetings for the local government. There were people sitting on some raised platform and for 10 minutes straight they were just shuffling papers back and forth between themselves. They were quite literally paper-pushers for those 10 minutes. I laughed for a little bit and then felt really sad that this was actually my own town government.

On a more technological side of things we have APIs and APIs for APIs. I have spent non-trivial amount of time trying to build something usable on top of AWS and OpenStack APIs. Same goes for various ecommerce APIs. The situation is so bad that there are entire companies built around making horrible APIs more usable. See channeladvisor and sellbrite. Horrible APIs are the equivalent of inefficient bureaucracies for programmers and quite literally keep them employed. More than once I've had the thought that if some API was more usable then I would not have a job.

</comment></comment><comment><USER6> And it creates coordination across multiple institutions. Everyone may have different solutions, but they must all preserve the same problem.</comment>


Tymeline | Project Planning that makes sense (Kickstarter-ish) - <AUTHOR> http://tymelineapp.com/

<comment><USER2> I like the look of it.

One thing that would help reduce my anxiety about inputting my email address would be to give an indication about how long development is likely to take (e.g. we anticiapte Tymeline will be ready 4 months after we have 8,608 users signed up). If you do this, it may be worth showing how many people are already signed up, so I get an idea how much longer it will be until development kicks off fully.

</comment><comment><USER3> Thats a great Kickstarter-ish Idea. I think its going to set a trend.</comment>


On the Homogenizing Dangers of Easily Translated Literature (2016) - <AUTHOR> https://lithub.com/the-murakami-effect/ <comment> barry-cotter > The growing dominance of English has come to mean that European, African, > Asian, and Latin American writers are considered to have "failed" if they > are unable to reach an international audience.

Is this really true? I can absolutely see it as a possibility for countries that see the US as the centre of the intellectual and political world, like Germany, the U.K. or the Netherlands, but do countries with highly inflated senses of their international importance and power, (France) or a great sense of the beauty or transcendence of their high culture (Italy, Russia) really look to the US so much?

<comment><USER2> Reporting in from Germany, not true. The domestic market is fairly big and it is understood that works of non-English origin usually don't do well in English-speaking countries.

</comment></comment><comment><USER3> The mentioned difficulties do not appear to actually be due to translation, but instead due to lacking the background to appreciate a given work as worth reading.

> _Zoku meian_ [Light and Darkness continued], is a tour de force in which she > creates a very plausible, stylistically pitch-perfect ending to _Meian_ > [Light and Darkness], the last, unfinished masterpiece by Natsume Sōseki, > Japan's most important modern novelist.

...

> As a fragmentary, dependent work, standing in relation to a classic text > that is largely unknown outside Japan except to a handful of experts, it is, > in effect, impossible to render into comprehensible English or, for that > matter, any other language

If "Light and Darkness continued" had been written as a continuation of an English translation of _Meian_ , it is likely that it would have failed to gather any significant readership except translated into Japanese as _Zoku meian_. That's simply due to targeting an audience that is already familiar with _Meian_ and might pay attention to a well-written continuation.

A similar problem arises for _Star Wars_ novelizations, without any translation involved. Being invested into the universe that serves as backdrop for the story is essentially a prerequisite for becoming a reader. If you tried to "translate" an English _Star Wars_ novel for the English mass market, you'd fail the same as when translating a novel full of Japanese cultural references for the same market.

The "homogenizing danger" then isn't so much about writing to be translated, but about writing to be read by the largest possible number of readers, be it in translation or not. Other literature can exist, but you shouldn't expect it to get popular outside a small niche. Sometimes the niches are separated by language boundaries, other times they're not. I'd assume translated _Star Wars_ novels to also appeal to Japanese _Star Wars_ fans, for example.

<comment><USER4> Maybe this is just coming from my background as an academic and general nerd, but personally I would rather read a book that I don't fully understand, but had lots of notes and references to explain the context, than something that's been conceptually "translated".

<comment><USER5> As a general nerd I feel like this is a common experience and one that I've quite enjoyed when reading countless sci-fi/fantasy books.

You start of and many cultural references or things seem completely alien and only start to click once you're part way through.

</comment></comment></comment><comment><USER6> As with most literary criticism, I'm pretty skeptical of this. Thinking in the opposite direction, Snow Crash would be easier to translate than Neuromancer. Neuromancer would be easier to translate than Finnegan's Wake. That doesn't mean that Snow Crash is part of some homogeneous morass or any less worthy than those other two novels. Though I suppose many literary critics would prize the Joyce over the Stephenson, there are no absolutes in art. There is just what people like.

<comment><USER7> I felt the author was pretty careful in emphasizing that he's not declaring neither Mizumura nor Murakami is superior over the other, just that translatability can be a factor in how works spread.

BTW, all three works you mention has been translated into Japanese (including Finnegans Wake!) The translation for Neuromancer is also something to behold; Hisashi Kuroma, the translator, invented a literary "cyberpunk style" which can only be done with an Asian language. Words in Kanji are sprinkled with ruby text [1] which, instead of annotating the pronunciation of the word, fills in the romanized equivalent English neologism, eg. "接続" would be annotated not as "せつぞく" but as "ジャック・イン" (jack in).

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

</comment></comment><comment><USER8> I still haven't finished reading it end-to-end, but I love the form and shape of Hofstadter's "Le Ton beau de Marot"[0] which is sort of an extended dialogue on the difficulty, beauty and/or impossibility of translation. It's not just about language translation of course, being Hofstadter, but that's the entry point.

[0][https://en.wikipedia.org/wiki/Le_Ton_beau_de_Marot](https://en.wikipedia.org/wiki/Le_Ton_beau_de_Marot)</comment>


Data Warehouse vs. Data Lake: What's the Difference? - <AUTHOR> https://www.talend.com/blog/2016/12/21/your-resolution-list-for-2017-5-best-practices-for-unleashing-the-power-of-your/?utm_medium=socialpost&utm_source=twitter&utm_campaign=blog <comment><USER2> A lake is what you get after everything runs downhill.</comment>


Amazon's Invasion of the CIA Is a Seismic Shift in Cloud Computing - B-Scan http://www.wired.com/wiredenterprise/2013/06/amazon-cia/?cid=8957294

<comment><AUTHOR> Is it a seismic shift, or just an example of a very large operator contracting another very large operator with experience in the field to do something right the first time?</comment>


Researcher shows that black holes do not exist - <AUTHOR> http://phys.org/news/2014-09-black-holes.html <comment><AUTHOR> [http://backreaction.blogspot.com/2014/09/black-holes- declare...](http://backreaction.blogspot.com/2014/09/black-holes-declared-non- existent-again.html)

</comment><comment><USER2> Stephen Crothers definitively shows the absurdity of black holes again and again but no physicist hears him:

[https://www.youtube.com/watch?v=QBorBKDnE3U](https://www.youtube.com/watch?v=QBorBKDnE3U)</comment>


PipelineDB (YC W14) is Joining Confluent - <AUTHOR> https://www.confluent.io/blog/pipelinedb-team-joins-confluent <comment><USER2> Announcement from Pipeline's side: [https://www.pipelinedb.com/blog/pipelinedb-is-joining- conflu...](https://www.pipelinedb.com/blog/pipelinedb-is-joining-confluent)

</comment><comment><USER3> Congrats Derek and Jeff. Excited to see what you guys build together at Confluent.

</comment><comment><USER4> congratulations, it's been very interesting following pipelinedb's story the past few years!

</comment><comment><USER5> Congrats guys!

</comment><comment><USER6> Congrats!</comment>


Selecting a Database for an Algorithmic Trading System - <AUTHOR> https://medium.com/prooftrading/selecting-a-database-for-an-algorithmic-trading-system-2d25f9648d02 <comment><USER2> Been there done that.

Selecting a database is the least of your worries. And you learn to live with the limitations - for example, in clickhouse you add a millisecond and a microsecond field.

Litteraly every solution listed will work, as the database will only be used to persist your data. Your trading will NOT use your database in any way except to load the data when you start (and potentially restart) your bots.

What really matters is 1) execution, 2) network performance and finally 3) good data

Language, database etc are just tools. This is a case of premature optimization.</comment>


Know when a startup/incubator opens its applications - <AUTHOR> https://pipecourse.com/course/dNLgbkqD <comment><USER2> This is really cool. But only if its updated everytime. I think its useful.</comment>


Mercurial vs Git: Why Mercurial? - <AUTHOR> http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ <comment><USER2> The part which struck me: "For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Keeping this functionality out of core prevents new users from accidentally using it until they're ready."

What this means in practice: when you need to rebase in Git, you simply do so. When you need to rebase in Mercurial, you have to enable a bunch of extensions which aren't well polished or documented because they're not part of the standard feature set and many people have been discouraged from using them. That second situation is far more likely to cause data loss, which is a pity because rewriting local history is a valid operation which often produces cleaner commits and avoids merge failures.

I started using Mercurial earlier than Git but have been using both for years. Mercurial remains the only one where I have experienced data-loss (histedit) and the one where I had to switch to a less natural workflow to deal with limitations of the tool (e.g. patch queues are such a kludge-fest it's obvious that nobody really believes you should use this feature).

<comment><USER3> To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my experience are just as well documented and tested as other bits of Mercurial.

It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default.

Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.

<comment> guard-of-terra Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one.

Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase.

If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time.

Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(

<comment><USER4> Your comments highly suggest that you are not by any means a knowledgable mercurial user. You don't have to "assemble" mercurial from parts to do history rewriting. Enabling the relevant extensions amounts to adding a single line to a config file. I usually copy the same config file around when installing mercurial anew so that I can cut out even that step.

Shelf isn't that necessary because of mq, which is bundled by default. It is very feasible to use mq as a simple shelf substitute, much easier than using it for its more complex usage scenarios. Also, for your use case, it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again, so you don't even need shelf or mq to do that if you haven't checked anything in.

<comment><USER5> I can't count the number of times I did:

        cd $PROJECT
        svn diff > ~/working-on-foo.patch
        svn revert *

        patch < ~/working-on-bar.patch

        30 GOTO 10.

Ugh. Thinking about going back to that workflow makes me physically ill.

Git (as Linus says) is a STUPID content tracker. 99.9% of the time when I'm working on source code, git allowing me to do stable, local "bookmarks", keep multiple local branches (and local history) active simultaneously, and keep all my content tracked... Git has its flaws and warts but don't seriously suggest that "svn diff > ~/working-on-foo.patch" is a valid workflow. That's bringing a knife to a gunfight.

I suggest that if you can understand a linked list, you can understand git. And if you're a programmer that can't understand a linked list... well... print out your "cheat sheet", here's a copy of Tortoise, and commit your code to a branch before it gets approved for main-line.

<comment><USER4> I only suggested the diff/patch workflow for the simple case where you realized after making edits that you were in the wrong branch. It might even be possible to just update to the correct branch and have mercurial automatically try to remerge your changes, though I haven't tried to know for certain. I think you're taking my suggestion way out of context, though I could be misunderstanding you.

Mercurial has remote-trackable bookmarks now (something I felt they needed for a long time). I agree Mercurial's branch tracking in general isn't nearly as good as git's, local branches being the biggest example. There is a local branch extension for mercurial (<http://mercurial.selenic.com/wiki/LocalbranchExtension>), but having used it a long time ago I'm not sure I'm the biggest fan.

However, I firmly believe that mercurial is in the same league as git and both are more than good enough to get the job done, and each have their relative strengths and weaknesses. I also believe that the outspoken part of the git community tends to be overzealous and blind to git's faults and Mercurial's strengths.

</comment></comment></comment></comment></comment></comment><comment><USER6> Why would their product marketing manager be bashing Git with accusations like Windows support is a "completely separate project" when it's the first download link on git-scm.com?

This is a very thoughtless article full of issues of personal taste and FUD towards Git. I was starting to really like Atlassian since they added free private Git repos on bitbucket.org. We've been considering using JIRA and other paid services from them where I work, but this gives me serious pause.

<comment><USER7> Not that I'm biased here (I use git and am more than happy on it), but git on Windows is an abomination as compared to Mercurial. Other than the sometimes complex commandline statements, it's one of git's bigger problems.

<comment><USER8> An "abomination", really?

I use Git regularly--and happily--on Windows with very few issues. It is considerably slower than its Mac/Linux builds, but aside from that the experience has been positive.

What exactly do you consider to be Git's failings on Windows? And how is Mercurial superior in those respects?

<comment><USER9> I haven't used git on Windows for some time now so maybe things have changed, but at that time, it was pretty obvious that Mercurial was a polished first- class citizen of the Windows platform while git was an incomplete port (and in git's defense, I don't believe "make it work on Windows" was ever a design consideration when it was written).

I presume things have changed since then but it wasn't always the case.

<comment><USER10> I have found the same things, even recently.

Git for windows basically brings half of MinGW with it including a shell and pisses up your windows cmd settings terribly. There is no platform abstraction layer in Git, so you're stuck with dragging GNU with you (it's not even POSIX compliant).

Mercurial is far more respectiful as it uses Python as the platform abstraction layer, uses windows semantics quite happily and considered Windows very early on.

Mercurial is just more polished on Windows.

Also the IDE integration and tooling on Windows is an order of magnitude better. It just works with no fannying around.

Add to that it's considerably less cryptic than Git and it's won.

<comment><USER10> Downvoted by a git fanboy...

</comment></comment></comment></comment></comment></comment><comment><USER11> GitHub is the first and last reason to prefer Git to anything else. That community is so vital right now, it cements Git as the essential VCS. I could believe Mercurial is better in some ways than Git and I could even believe Atlassian's BitBucket service is in some theoretical sense better than GitHub. But most code is on GitHub, so git wins.

<comment><USER12> There are 6 responses your comment and not one has mentioned that both hg and bzr have full interoperability with git. I use github extensively with both bzr and hg, and haven't used git in a while. Your personal choice of SCM is entirely irrelevant to which web service you use.

<comment><USER13> As a lover of bazaar, how did you manage to do that? I always feel so dirty when I have to use git because everyone uses github.

<comment><USER12> Just use bzr-git, it works perfectly.

</comment></comment></comment></comment><comment><USER14> It is a bad thing to have just _one_ command to move files instead of 3? Nah, I don't get it.

That git has different commands than svn is because it _is_ different. Why should it adopt any of the commands if it does different things?

When I started with git, I _never_ _ever_ destroyed any of the history. Because it's not easy to do so.

I looking forward to read the follow-up article where he wants to point out some advantages of git.

</comment><comment><USER15> Regarding the "A Sane Command Line Interface" topic. Linus mentioned in his talk at Google about Git that he often chose the opposite approach to do things rather than follow the Subversion approach. This might be why the commands are not named the same as Subversion commands.

git add/rm handles making changes to the index and there is no similar concept in mercurial or subversion.

<comment><USER16> I think this is not only about similarity. For example, branching works with `git branch foo`, but it doesn't immediately switch to that branch. If you want to do this, `git checkout -b foo` is the way to go. While this might make some sense if you understand the details behind git, it is horrible from a user interface perspective. I know a lot of people that didn't know about checkout -b because they never thought about looking there.

Also, some features are half-implemented, for example `git add -p` which does not trigger on file-additions (and sometimes is broke out of the box on some distros).

I like git, but the interface: not so much. Too many rough edges.

The blog post does not illustrate this, though :/.

Update: and for the downvotes, would you care to explain why?

<comment><USER17> I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout command switches between them. There is a convenience command that does a checkout and create. The main thrust of the checkout command is to change branches so if a branch does not exist they give you a convenience method to do so.

edit: git add -p(atch) is supposed to create patches of existing files assuming that that is the most common use case. Use --interactive if you want to add new files and still do interactive patching.

<comment><USER16> I am aware why the distinction exists - from the perspective of "git(1) manipulates the git file system", it make sense (as I wrote). But most people I know tend to use "branch" for all their branching work (as the name implies) and never bother about the finer details. But the fact that this sore point exists and is real makes the git UI problematic. I don't bother, because I know the details, but if I have to explain it to every new guy in the office, there is something wrong.

About git add -p: yes, I am aware of -i, but it doesn't give you the easy "give me all changes to the file system and let me sign them off"-interaction that git add -p has. They are two completely different interaction modes.

<comment><USER17> git add -i

5<enter>

*<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc...

then <enter> gets you to the staging that you are used to. this will get you into the quick patch mode that -p does.

-p is just a short circuit of this.

</comment></comment></comment></comment></comment><comment><USER18> "Backwards Compatibility

The maintainer (and original author) of Mercurial, Matt Mackall, is a strong proponent of backwards compatibility, which is important when you're choosing a version control system that you plan to rely on for a long time."

Well, that's air-tight. You sold me.

<comment><USER19> And since when GIT ever broke backwards compatibility?

 _almost never_. Details below:

[http://stackoverflow.com/questions/1314668/git-repository- ba...](http://stackoverflow.com/questions/1314668/git-repository-backwards- compatibility)

<comment><USER15> I'm pretty sure jcoder was being sarcastic :).

<comment><USER18> Yeah, just drawing attention to the "rigorous discussion" (hand waving).

</comment></comment></comment></comment><comment><USER20> I find the "Easy to Extend" argument very unconvincing.

The example shell script is not at all integrated with hg (no more so than any other Unix command), and these are not Windows portable, as the article indicates is so very important. Git appears to have an edge here, since you can integrate shell scripts directly into the git interface.

Git allows aliasing just as easily as hg.

</comment><comment><USER21> I like what's on the git part of the table better, and it isn't just familiarity with git but familiarity with unix. I'm glad that since I use git and git-svn, I don't have to type remove and move instead of rm and mv.

<comment><AUTHOR> One thing the article misses is that hg also has a bunch of built-in aliases for a lot of these commands, including:

* mv for move

* rm for remove

* co for clone (which SVN uses as an abbreviation for svn checkout)

* ci for commit

As well as the fact that you can abbreviate _any_ command that hg doesn't have specific aliases defined for by typing any unambiguous prefix. Git, on the other hand, has _no_ aliases by default, and no prefix aliases.

<comment> buff-a Gosh, I know. That's awful. Its much better that hg allows people to type hg mv, rather than _forcing_ lazy people to modify the .bashrc file so that they can type "ga" instead of "git add".

I mean, I know "hg mv" is actually _longer_ than "ga", but by golly, expecting unix shell users to know about the alias system _built into the operating system_ is just the kind of elitism we can expect from linus.

<comment><USER21> I hate to burst your bubble, but git has alias support. <http://githowto.com/aliases>

</comment></comment></comment></comment><comment><AUTHOR> The fact that the average HN'er seems to be completely unwilling to even _consider_ using a tool different than git is rather depressing. While I understand that git does have some impressive features that Mercurial does not, most of them are somewhat esoteric, and I certainly doubt that they are enough of a motivation to justify this viewpoint that git has already won and that Mercurial is a pile of trash.

"The more I use git, the more I realize that everyone enamored with it has a severe case of Stockholm syndrome." -- Matt Might [1]

[1] <https://twitter.com/#!/mattmight/status/161495662033248256>

</comment><comment><USER22> I did 'git log' on a repo with 60K commits and about 3k files. I finished in a second or so.

I imported that git repo into Mercurial and did 'hg log'. It took 13 sec.

This was about 3 years ago. I haven't looked at Mercurial again. Maybe things have changed now?

</comment><comment><USER23> Almost all git vs mercurial differences for most users are cosmetic/usability/culture related. With a few extensions turned on, you can use either interchangably. The biggest exception to this is if you use named branches (a fairly common thing in git, slightly less so in mercurial). Mercurial hard codes a branch name in the metadata of a commit, git doesn't do that. I prefer git's method as it means that a commit can move around on branches (or really that branches can point to different commits) without messing with the commits themselves.

<comment><USER24> Branching is one of the big differences. I find Mercurial's named branches mostly useless; fortunately, with some care, bookmarks can be used to simulate Git-style branches.

I think, early on, the Mercurial community favored cloning as the means of creating feature branches, while Git used named branches to do so. But in many cases you want to be able to switch lines of development in a single repository (especially when using a workspace-based IDE like Eclipse), so the Git model becomes a win.

</comment></comment><comment><USER25> >Many programmers prefer to use a graphical interface to their version control system instead of working through a command line.

to be honest git is my first true VCS (because I was used to working on my own and my VCS was Wuala sync that synced every changed document to the cloud + daily backups to another HDD). I have used the built in revision control system in Visual Studio but not extensively. When I started out with git I was looking for a GUI client because I assumed that it would be easier to use but now I much prefer the cli version of git and I assume this is true for most Linux (and possibly Mac users idk). I would even go as far as to assume that this is true for most HN readers. Anyone care to comment?

Also git (even direct publishing to github) is built into PyCharm/RubyMine and there is also TortoiseGit for Windows (not sure about other OSs)

edit: I just realized this might be slightly OT but I still hope this wont be downvoted into oblivion as I'd love to hear some opinions

<comment><USER26> For my part, I started using git at the command line because most of the Linux GUIs were pretty weak. They may have gotten better since I looked (1 yr?) but at this point I'm comfortable with the command line interface.

Also, I jump between Linux at work and OS X at home, and the git workflow is the same on either if I am using the command line.

The Mac GitHub app seems really nice, though.

</comment></comment><comment><USER27> Having used both git and hg in my own projects, I have strong feelings towards both, although in the end they're like siblings who got the same lessons from their parents and just choose to go to different colleges.

With that said, I'm not sure this post really pushes one to use hg. The comments about being close to svn are pretty lame. While I get the point; subtle differences really won't matter after the first week. And getting over the mental difference that comes with distributed version control is a lot more to take in than a couple letter changes in commands.

The two things I most like about git are how -- by default -- you can choose line-by-line what gets commited. Where as the default in hg is to commit all changes. This actually changes how I find myself coding and my comfort with the repo. I know you can do something similar in hg, but it's a bit of a nuisance.

The other standout is how simple branching is in git.

</comment><comment><USER28> I used to worry about Git vs. Mercurial too. Neither made me really happy. Then I found Fossil[1]. Now I am coding instead of worrying about version control.

[1] <http://fossil-scm.org>

<comment><USER29> I eventually settled on git, for no particular reason but to choose one. They are equivalent for all practical purposes, but require learning different commands to do the same thing. It was taking too much mental bandwidth for me to context-switch between them.

It's great to see some diversity though.

Edit: There are also plenty of scripts to convert between repositories of one format to another, and communicate between them, another reason to use the one you're comfortable with...

</comment></comment><comment><USER30> The need to be a technology contrarian, that's why.

</comment><comment><USER31> Or, let's be honest, because Github already nailed Git so we had to base bitbucket on something else.</comment>


C10K - serving thousands of clients - <AUTHOR> http://www.kegel.com/c10k.html

<comment><USER2> This is some good information, but I ultimately decided that letting smarter people handle this was better then writing my own server. I adapted the protocol I was writing to work via HTTP, and just used nginx to handle the inbound connections.

It's pretty hard writing a reliable server that can handle a lot of concurrent connections, for most people I'd imagine their time is better spent on writing the actual application code.</comment>


Ask HN: Article about Math in schools and the lack of creativity - <AUTHOR>

It was a well written popular paper, kind of long, about how the life has been sucked out of math, or something to that effect. It was a beautifully written paper but I can't find it for the life of me.
I tried various search queries on HNSearch.com too but I can't find anything!
Thanks. <comment><USER2> Was it "Lockhart's Lament" ?

[http://www.maa.org/sites/default/files/pdf/devlin/LockhartsL...](http://www.maa.org/sites/default/files/pdf/devlin/LockhartsLament.pdf)

<comment><AUTHOR> Yes that is it thank you.</comment></comment>