Xtend – Modernized Java - <AUTHOR> https://www.eclipse.org/xtend/documentation.html <comment><USER4> I've used xtend last year, before I switched to Scala. Eclipse integration is better with Scala (autocompletion among others), and Scala has more to offer. Biggest pain point: stack traces point to the Java translations, not to xtend's source code. That made me switch to Scala.

<comment><USER5> Autocompletion in the Xtend editor is quite excellent, you might want to try a recent version. The last time I tried the Scala IDE (during the first Coursera lecture), Scala's autocompletion suggested may invalid proposals. It felt more like the editor was guessing about types than actually doing proper type analysis. If you happen to have a Java stack trace from Xtend code and click on a stack frame, Eclipse will open the Xtend file and highlight the proper line in your Xtend code.

<comment><USER4> Good to hear Xtend got better... but too late for me, I'm afraid. I learnt to like Scala, but I'm working with node.js now (coffee-script)...

I think Scala is a good language, but maybe it has too many features for me. Xtend did not leave me a bad impression anyway :)

</comment></comment></comment><comment><USER6> "Modernized Java", it's basically a slightly uglier C#.

Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at the moment, but it's kind of wry that C# did such a good job of keeping current where Java lagged so terribly behind.

<comment><USER7> Same can be said for the JVM vs CLR, only in reverse.

<comment><USER8> I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.

<comment><USER9> Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.

</comment></comment></comment></comment><comment><USER10> I don't see any advantages in this over Scala.

<comment><USER11> Probably easier to write for Android with Xtend than Scala.

<comment><USER7> Why is that? Tooling support at this point is much better for Scala than it is for many JVM languages, including Xtend.

Checkout: [https://github.com/pocorall/scaloid](https://github.com/pocorall/scaloid)

You can do that in combination with IntelliJ IDEA for example, which has awesome support for both Scala and Android. Google's new Android Studio is actually the same as IntelliJ Android plugin that they distribute as part of their open-source distribution. It's also the best IDE ever.

</comment></comment></comment><comment><USER12> Oh, how many "next Java" options we have now... Kotlin, Ceylon, Gosu, Xtend, Java 8 :) (Scala not mentioned as I refuse to call it "the next Java", it's a new player)

<comment><USER13> Had not seen or forgotten Gosu. Thanks. Not that I'm likely to use it, Kotlin will be my first choice when I get back to my Android app.

<comment><USER14> Doesn't Kotlin target jvm 1.6?

<comment><USER13> Honestly, I don't know. No one seems to have mentioned anything like that as an obstacle to kotlin on android, but I haven't done a ton of research.

</comment></comment></comment></comment><comment><USER15> It's like Coffeescript for Java...

I hereby suggest it be renamed "Coffee".

<comment><USER16> That would be an evil prank on us all though... We'll have job offers with "12 years of Coffee experience with jQuery".

</comment></comment><comment><USER17> I've used Xtend many times over the last few years. In fact, I'm using it right now at my "real" job for an internal project. I'm mostly a Clojure guy who still has to do a lot of Java work to pay the bills - when I can't use Clojure on a project, Xtend is a breath of fresh air.

The current form of Xtend has been around for a few years now, and has steadily improved. Its origins go back many years, to the OpenArchitectureWare project where its predecessor (called Xpand) was used as a templating and model transformation language for the framework. Since oaw moved to the Eclipse foundation (5-6 years ago?), most of the tools have been dropped, reworked, or merged in with other Eclipse projects.

Out of all this reworking for the new generation of Xtext came Xbase, which is an expression language that you can just drop into your DSL and have pretty much the entire Java language available (type system, expressions, scoping, etc.). If you're doing serious modeling/DSL work, this is about as good as it gets without going to something like MPS (which is awesome, but has its own set of limitations). Xtend is essentially this Xbase language in stand-alone form, with a few other goodies. There is also another project called Xcore which lets you create EMF models in plain text, mixing behavior along with structure, and it uses Xtend/Xbase as well. This is one of the reasons why I'm not too worried about Xtend becoming "abandonware" or anything like that - <USER2> main components are pretty essential to some key projects in the Eclipse ecosystem.

So why wouldn't you just use (Scala, Groovy, etc.)? Well for one thing, I can (and have) bring Java developers up to speed on Xtend in about an hour (less if they know anything about functional programming). You can see some benefits in more concise code right away, and it only takes a couple days to get productive with it. No one can do that in Scala or Clojure. If you're looking for a strategic platform to build your next JVM architecture on - well, that's not really Xtend's place, you're looking for Scala or Clojure (hint - <USER3> latter). But there are a lot of projects where Xtend is a very nice fit, and as a bonus, I've found that developers who learn Xtend first have a much easier time learning a more "serious" language like Scala or Clojure later.

</comment><comment><USER18> Compared to other JVM languages Xtend seems to be seeing very little adoption or interest. I have yet to encounter anyone who's actually using it.

<comment><USER19> It is a me too language from Eclipse foundation without any clear roadmap why anyone in the industry would care to use it given the more mature JVM languages, specially given its dependency to Eclipse and generation of Java code instead of bytecode.

<comment><USER20> Xtext, the Eclipse/JVM language development toolkit behind Xtend, is in many ways more interesting than Xtend itself. In fact (I may be wrong) but Xtend was really done as an Xtext example/test/advertisement.

I have used Xtend a little (not in production) and it was interesting when first introduced. I suspect Java 8 will make it redundant.

<comment><USER19> My feelings as well. I just looked into it as a possible language for Android development given the stagnation on Java compliance on the platform, but Kotlin looks much better suited for it given Google's investment into InteliJ.

</comment></comment></comment></comment><comment><AUTHOR> Xtend seems to be a very conservative, but sensible iteration on Java. Does anybody have some experience with it, knows some pitfalls, etc.?

<comment><USER21> I think its only usable with eclipse. I do wish it had ADT and pattern matching.

</comment></comment><comment><USER22> MPS from jet-brains offers another good option something called baseLanguage with very good DSL equivalents for a lot of use-cases combined with one more called SModel language.But its not parser based one like xtend is , its AST based projection editing and manipulation platform.I've been learning it for sometime.

</comment><comment><USER23> What I would hope is that these features get rolled back into Java. Xtend could be a testing ground that shows how something would work, similar to the way browsers have their own proprietary implementations of an idea that then serve as examples to the W3C.

<comment><USER18> I find it sad that some view JVM languages which aren't Java as a testing ground for features which could be added to Java. Other JVM languages are worthy of usage independent of the Java language. Not everything can be back- ported to Java and keep the language backward compatible.

<comment><USER19> The main problem is that the enterprise sees:

JVM == Java and CLR == C# (or VB.NET for VB shops)

Given the size and skills of the said teams, usually you cannot sneak in alternative languages anyway.

So for many of us, regardless how much we like alternative languages, those are the ones we are allowed to play with.

</comment></comment></comment><comment><USER24> coming from java, xtend is probably the best choice right now (also compared to java8) because you are up and running in few hours. really! and the development time will decrease significantly. You can create full projects in a fraction of time. Active annotations are also very useful to generate common boring code (Logging, patterns, ...) also from configuration or HTML files, or to generate files like javascript to call your backend service. the only drawback is that it only works in eclipse. Eclipse has full support, meaning that debugging, refactoring, click from stacktrace and so on are available and work perfectly. just try it for 30 minutes, you'll not come back!

</comment><comment><USER25> This all looks OK to me but my first worry would be ease of debugging. I eyeballed the doc but couldn't see anything specific to debugging. Anyone has some experience they could share?

<comment><USER5> You can debug Xtend code using the Eclipse Java debugger and debug Xtend code just like you would usually debug Java.

During debugging, you can select for every stack frame if you want to see the Java code or the Xtend code. This makes sense since Xtend code gets compiled to Java code which then gets compiled to byte code.

</comment></comment><comment><USER26> They surely need to find a solution for proper debugging. Nobody likes mental gymnastics needed when debug stack traces to a language other than the language you write the s/w in.

<comment><USER5> Xtend isn't supposed to replace Java. It enhances it. That's why Xtend doesn't compile to byte code but to Java code.

If you do imperative programing in Xtend, there will be exactly one Java method for each Xtend method. I.e. the "Xtend stack trace" (if it would exist) is exactly the same as the Java stack trace.

If you do a more function style of programming and use lambda expressions, each lambda will be a anonymous class in Java 7 or older. So you'll see them in your stack trace. But I guess that you would also see them in Java 8.

</comment></comment><comment><USER27> JVM languages seem to be the flavour of the month at the moment. Why do IDE makers feel the need to invent their own languages?

<comment><USER5> Because many languages were designed with only the compiler in mind, but IDEs have requirements regarding language design, too…

Example 1: text-based preprocessors such as the ones you find in C or C++ are a nightmare for IDE developers. They turn static analysis into a game of guessing because your source code can manifest itself into too many variations.

Example 2: SQL: If a user wants to write "SELECT mycolumn FROM mytable;" but he/she has only written "SELECT " and now trigger auto-completion… it can not work, because the IDE has no idea from which table it can list the columns. If the language would have the syntax the other way around "FROM mytable SELECT mycolumn" auto-complete could easily propose the tables first and all the columns from a specific table later.

</comment></comment><comment><USER28> Better to use Java 8 with Lombok extensions.

<comment><USER29> Anyone with any sense of taste avoids Lombok. It's a terrible hack. Rather use Scala which gives you far more. Maintaining Lombok + Java is a pain.

<comment><USER30> I dislike nearly everything about Lombok but `val`. Everyone else seems to be the opposite :-(

</comment></comment></comment><comment><USER31> Xtend seems for me to be like coffeescript. It gives nice syntax like blocks to java.

</comment><comment><USER32> Xtend has been around for a while and I think one of the reasons why it didn't catch on is because it generates Java, which severely limit its performances.

These days, "modernized Java" would probably be Ceylon or Kotlin.

</comment><comment><USER33> What's that «guillemets» nonsense??

<comment><USER5> It's finally a syntax that doesn't get into your way when you want to generate stuff.

Think of XSLT. Every time you want to generate a "<" or ">" you need to escape it.

Think of PHP. Every time you want to embed a command you need at least two characters to escape it: <? ?>

Xtend choose «guillemets» because they're concise and very unlikely to occur in the string/text/file your generating. You might want to use UTF-8 or ISO-8859-1 encoding.

<comment><USER34> <? is easier to type and no harder to read than «.

<comment><USER17> Sure, until you are trying to generate php.

The templating engine is one of the parts carried over from the old Xpand project on which Xtend is based. Xpand's sole purpose was as a templating language for writing code generators in MDE projects, and as such they tried to make it easy to generate any kind of code, so they chose a non-ASCII delimiter.

It's really not a problem in practice - type < and then ctrl-space and code completion will fill it in for you. The only real gotcha is that you have to make sure your project is set to use UTF-8 encoding, which unfortunately is not the default setting in Eclipse.

</comment></comment></comment></comment><comment><USER35> Everyone and their dog is writing a language these days. Oh well.

Id rather improve on applications and libraries we already have.

<comment><USER36> > Id rather improve on applications and libraries we already have.

Can you be more specific?

Also, working on tooling is _way_ more interesting than working on apps...at least for me. There are actually hard problems to solve ;)

<comment><USER27> You're trying to invent solutions to problems that nobody have.</comment></comment></comment>


Staff US Congress voting options during Covid19 [pdf] - <AUTHOR> https://rules.house.gov/sites/democrats.rules.house.gov/files/StaffReport_VotingOptions.pdf <comment><USER2> _By far the best option is to use the existing House rules and current practices_

Good grief. The fact that the US Congress doesn't already have a contingency plan ready for this extremity is a dereliction of duty and the sign of a failed state - one that believes in the magic of its own customary behaviors rather than any practical considerations.

I mean, one of the planes on 9-11 was intended to hit the US Congress. You'd think that would have been sufficient motivation to dust off cold war-era continuity plans and reimagine them for the possible catastrophes of a new era but instead the USA has opted to institutionalize its sclerosis to the point of ossification.

The USA is becoming a failed state in near real time. I'm sure that statement will seem hyperbolic to many readers but I think most of you have little conception of just how abruptly institutions can collapse.</comment>


Building the next generation of financial infrastructure - <AUTHOR> http://blog.zactownsend.com/building-the-next-generation-of-financial-infrastructure

<comment><USER2> Wow. Extremely impressive all around. I can see how Standard Treasury's priorities are well-chosen, in every respect. Personally, however, I find it a bit regrettable that interacting with personal investors' brokerage accounts does not seem to be on that list of priorities. I'd just like to weigh in by saying that for me, for the project that I'm working on, and ultimately for every personal investor, it would be awesome to be able to interact programmatically with brokerage accounts, in a way that is not indirect, kludgy, and costly. The first and most important step would be to get daily balances and cash flows. Next would be getting information about trades. Ultimately, of course, one would be able to make trades. Again, like everything else, this is possible now. It just needs to become easy and not cost an arm and a leg.

</comment><comment><USER3> Reposting my comment in this repost of [https://news.ycombinator.com/item?id=8240626](https://news.ycombinator.com/item?id=8240626)

Conway's Law:

>Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

In my experience this is very true at banks. Perhaps it is truer at banks than anywhere else - although I suspect as much, I can't be sure. Bank software is basically about implementing in code, processes that were developed to be applied solely by humans 100 years ago or more. It's all the same stuff. There is nothing new. It's so bad that, after an organizational change, even if there is no logical reason that this change should affect the software running the bank at all, it will anyway, because some existing piece of technology was the old guy's pet project, and so the new guy needs his own pet project. And all projects are pet projects. And so on.

And that's just on the tech side. Of course, on the business side, technology is a cost to be grudgingly paid out and worked on, at best. And once the technical debt gets to be unworkable, someone comes up with the great idea to hand everything over (or in pieces, whatever) to a vendor. But then eventually the cost structure there gets too onerous as well, and so the business tries to replace it in-house again, after spending the last decade clearing out all their in-house expertise. And so the cycle continues.

Some banks are worse than others, but if this article has you thinking that maybe at Goldman Sachs, or Credit Suisse, or Morgan Stanley and Deutsche Bank, technology isn't an absolute shit-show, well think again. And these places run the world economy while their technological infrastructure is held together by duct tape.

The article is right, of course, that banks will still be around in 20 years. Obviously. But, the big banks have known they need to get their act to together for, at the very least, forty damn years. And not a single one of them (not one!) has done it. And they never will, because they are dominated by a culture going back two hundred years that will not ever let engineers anywhere near the levers of the business, which is where they need to be, and for that matter will most of the time not invest profits back into the business when they can funnel it into their own bonus instead.

If you want to disrupt banks, start a bank! Start a bank where you can do things and enter markets that the big guys can't, because their tech is half- assed and they aren't creative enough to do anything about it. Finance is in need of disruption, and the potential windfall to pulling it off is enormous, but you aren't going to get there by selling to existing players.</comment>


Show HN: Now live, what BTC should have been - <AUTHOR> https://nimiq.com <comment><USER2> So it is a premined coin that you need to buy in some overly complicated manner and it solves the same problems as other cryptocurrencies. I fail to see the point.

</comment><comment><USER3> I really want to like this, because browser-based stuff is great, and their UX seems great in every aspect, but I fail to see the point also.</comment>


BeeChat.Network - <AUTHOR> https://beechat.network/ <comment><AUTHOR> BeeChat.Network is free and open source software allowing legal (<1 watt or 100mW @ 2.4GHz or 868 MHz) license-free, mesh network radio communications in an encrypted manner without the Internet. It works by plugging a Digi XBee dongle into your USB port to turn your machine into a node in the mesh network, allowing you to transmit data such as files, and even chat with other nodes.</comment>


Insurance Policies on Slaves: New York Life's Complicated Past - <AUTHOR> http://www.nytimes.com/2016/12/18/us/insurance-policies-on-slaves-new-york-lifes-complicated-past.html?em_pos=small&emc=edit_dk_20161219&nl=dealbook&nl_art=0&nlid=65508833&ref=headline&te=1 <comment><USER2> Also see "dead peasant insurance": [http://www.snopes.com/politics/business/deadpeasant.asp](http://www.snopes.com/politics/business/deadpeasant.asp)

</comment><comment><USER3> Just because everything in the past was horrible doesn't mean we need to burn it all down.

We definitely don't need a culture of victimhood where anyone with documented ties to the past gets vilified.

<comment><USER4> _Just because everything in the past was horrible doesn 't mean we need to burn it all down_

Spoiler: this is where a solid libertarian argument for universal basic income begins. Since we know just about every distribution of property/wealth in the present day traces back to a use of force or fraud in the recorded past, but just about _everybody_ has cause against _someone_ , it would be impossible to equitably settle every case individually in order to create a clean slate on which to build a libertarian society. It would also be impossible to just declare "libertarianism, starting right now" and lock in the current known- inequitable distributions of wealth and property. Adding a universal basic income, given to everyone and funded by taxation of everyone, offers a way around this conundrum.

<comment><USER5> No it doesn't. There's no immutable law of nature that requires that the use of force against distant ancestors is at all relevant to contemporary judgments of equality, justice, and fairness.

And there's no immutable law of nature that says a universal basic income would excuse any current or future disputes regarding equality, justice, and fairness. Indeed, UBI could even exacerbate feelings of unfairness in myriad, unpredictable ways.

The fundamental issue is that concepts like equality, justice, and fairness are highly dynamic and often far removed from most objective measurements of well-being.

That's not a critique against those concepts. Our need to feel treated "fairly" is innate. But the reality is extremely messy. The meaning of "fair" is constantly evolving, from the perspective of each individual, each community, and society-wide. And it rarely if ever means the same thing to any two people or groups, and hardly ever means the same thing to the same person across time or other context.

<comment><USER4> "Fair", to a libertarian, has an objective definition. No force, no fraud, contract freely entered by all parties. If that definition is not met, then it's not fair.

</comment></comment></comment></comment><comment><USER6> Can you give examples of how (in 2016) "white supremacy" is affecting "anyone who's black in America"?

<comment><USER7> I'm late to seeing this but it needs a moderation response.

Whether you intended it that way or not, this amounts to trolling. It can lead to nothing but flamewars and ideological battles that are completely unwelcome here, so please don't do it again.

We detached this subthread from [https://news.ycombinator.com/item?id=13216240](https://news.ycombinator.com/item?id=13216240) and marked it off-topic.</comment></comment>


Python Serialization Performance - <AUTHOR> http://www.kurtsp.com/python-serialization-performance.html <comment><USER2> > Disable Schematics Validation ... There's a cool Python trick to create an > object while skipping the __init__ function.

Yes, but now every single time you update the library which provided the base class, you need to re-verify that __init__ doesn't do anything new. May be worth the tradeoff, but it really should be noted.

</comment><comment><USER3> Seems like a good use case for protocol buffers [1].

[1][https://developers.google.com/protocol- buffers/?hl=en](https://developers.google.com/protocol-buffers/?hl=en)

<comment><USER4> It might be that they consider it important to be able to interrogate the in- memory or on-disk representations without the help of a decoding step. Protobufs are great for getting objects into a nice compact format to throw on the wire, but god help you if you end up with multiple actors filling up a queue with inconsistently encoded objects.

<comment><USER5> doesn't Apache Avro solve this problem?

</comment></comment></comment><comment><USER6> TL;DR: Things get faster if you disable validation and parse dates using more specialized code. Duh.

It's humorous when someone who presumably cares about performance tells you they use Python. Python is a wonderful language, but performance is not what it is designed for. Basically _anything_ that does not require an interpreter to run will be 10-30x faster on the same hardware, and most will also consume less RAM and be able to use more than one core on the system efficiently. It used to be that Python's lack of performance didn't matter because disks and networks were so slow things were IO bound. In more and more cases that's just not true anymore. You could be easily reading at 1GB+/sec and pushing 10-20Gbps to NICs, depending on the hardware.

<comment><USER2> It depends what "using python" means though. Cython is pretty good at optimizing basic code. Numpy will process your matrices and vectors using specialised libraries faster than most manual C approaches. Shedskin will give you a nice code framework which you can optimise in parts that matter. (insert other specialised examples)

CPython is slow as an interpreter, true. "Programming in Python" may or may not be many times slower than compiling the comparable code in other language. Depends what you're doing and how you're doing it.

Also, I care about performance in any language to some extent. If I can write a backup bash script that takes 2h, or write one that takes 20min, I do care about performance and will choose the second one. Why shouldn't I?

<comment><USER4> Is Shedskin still actively maintained? I haven't looked in a long time but last I saw it hadn't gotten any updates in a couple years (maybe I have corrupted memory though ;)

Anyhow, the relatively new Nuitka project seems to be aiming to tackle the python-to-c++ compiler problem, and seems to have a lot of promise. Really good compatibility, apparently decent speedups, and cross platform support. Works into Python3 too. I have a lot of hope!

<comment><USER2> I don't think it is. But that doesn't mean it doesn't still work :) But yeah, Nuitka is probably a more interesting target for new code.</comment></comment></comment></comment>


India's Supreme Court: Repair Taj Mahal or Tear It Down - <AUTHOR> https://www.eturbonews.com/227788/indias-supreme-court-repair-taj-mahal-or-tear-it-down <comment><USER2> Judging by my personal experience with air pollution in the region - I am doubtful how successful they're going to be. There are just too many 2-stroke engines and too much hydrocarbon air pollution. The stone of the Taj Mahal was only white before industrialization became widespread. At least the Badshahi Masjid in Lahore is made from red brick and stone and, despite Lahore's incredibly air pollution, doesn't look discolored...

Anything white in that environment is going to be hard to keep clean. Go out on a mid summer day and ride motor-rickshaws around Delhi all day wearing a crisp white shirt, then take a look at the shirt collar and the rest of the shirt at the end of the day.</comment>


Media Temple's stand on SOPA - <AUTHOR> http://weblog.mediatemple.net/2011/12/23/media-temples-stand-on-sopa/

<comment><USER2> I realize that GoDaddy has reversed their position on SOPA. However, to me and to many others the damage has been done. I've been with Media Temple for a couple of years now and have been extremely happy with the service and support. On the other hand, GoDaddy has been nothing but disappointing. This is just the culmination of 5 years of frustration.

We the consumer have enormous power over these rigid companies with interests that aren't inline with their customers.

</comment><comment><USER3> They really are an excellent company. I currently host my startup with them and I couldn't be more pleased. Glad to see they're against SOPA as well.

<comment><USER4> I also agree. I've been with them for 10+ years and only had 2 or 3 issues which were solved in a few hours. Great support and an excellent company.

<comment><USER5> I was only with them for six months and after that time they managed to irreversibly destroy _everything_ I had been working on, including the backups I'd paid for. (They said that the backups were on a different server which also happened to catastrophically fail at the same time...)

I want to love MediaTemple, and I agree that their support is excellent, and I accept that terrible accidents happen, but I can never bring myself to use them in a production environment ever again. (The project I was hosting with them was in a sort of private beta, and although I had second backups of the code I had very very foolishly trusted the Snapshot backups with _all_ my user data. Lesson learned.)

Anyway, I'm just one dissenting data point in a giant sea of happy customers. I don't mean to dissuade anyone from using MT--just please don't be any less paranoid about their service than the rest.</comment></comment></comment>


The way we run Exist - <AUTHOR> https://exist.io/blog/the-way-we-run-exist/ <comment><USER2> I've used Exist for a few years and love both the service and the way its run. The design of the app is great, its reliable and continues to evolve, but the biggest thing for me has been how open and transparent the dev team are.

</comment><comment><USER3> The app looks nice, but really, do you think I'll readily hand so much data over to a company which I barely know?

I do think this could be an amazing local-storage service though, not free, still paid as a subscription model.

</comment><comment><USER4> Yeah, everything will be hunky-dory until Belle and Josh are struggling to make their mortgage payments, and Facebook comes calling.

</comment><comment><USER5> Why does this need to be centralized? This is like asking for the user's soul. For the good of everyone, services need to start thinking offline-first, smh. I would not use this service for the _exact_ same reason I never used Facebook.

</comment><comment><USER6> Asking for credit card details on a free trial is going to be a stopper for new users.

<comment><USER7> Clearly it wasn't a show stopper for all their existing users, who are now paying two engineers their salaries.

<comment><USER6> Well, it was for me. I read the blog post and decided I wanted to try it until I had to add my cc details on the sign up form. If you are providing a one month free trial why on earth do you need them?

<comment><USER7> To protect against users creating a new account each month.

To be fair, though, I'm largely in agreement with you in this case. For products like cloud infrastructure, where the company is fronting real costs, the requirement makes sense to prevent abuse. But this product has low marginal cost per user, and also loses all of its value if a user recreates his account.

<comment><USER6> Why would I do so? the nice thing about this is to have the historical of data. If I created a new account I would have to start over.

Unless, of course, you could import historial data somehow. But then maybe just make that feature not available on trial.

<comment><USER7> Exactly; that's why I'm agreeing with you for this particular service. This was what I was referring to when I said the product "loses all of its value if a user recreates his account."

</comment></comment></comment></comment></comment></comment><comment><USER8> Does anyone here actually use this odd app? Why? Did it bring any improvements in your life?

<comment><USER2> I use it. Its great for bringing together data from various self-tracking sources and try to get some learning from them.

Why - several reasons. It means I go to one place to look at this data, and its presented in a consistent way. It also helps try to drive meaning from all this data by looking for correlations and commonalities.

Did it bring improvements. For me its helped me get in shape, its helped me find things that have a knock-on effect to my mood and/or productivity.

<comment><USER8> Interesting..if you mean physical shape, then I always thought that the most effective way to "get in shape" is a simple discipline combined with the primitive reward-system..Literally - just don't eat junk food, work out for 30 minutes per day and if you are happy about results, go ahead and reward yourself by a piece of apple cake or whatever(reduce your normal intake to keep everything balanced - for advanced users). This is so simple and so effective that you don't need anything else - no trackers, no complex data analysis or shrink visits. Amazingly a lot of people ignore this simple path and try various tools like this "exist" thingie.

<comment><USER2> Obviously having discipline, exercising and not eating junk food is a big part of it, and for many people that would be enough. What Exist helped me with on this was keeping me motivated over a period of time and helping me identify other things that were / are impacting my progress (e.g. sleep, work etc). Clearly its not for everyone - but it is certainly something that I value, and something that has helped me.

<comment><USER8> Oh, I forgot about sleeping. Indeed it's the paramount and it's the most difficult part. Sleep at least 7hrs per day, use the ear plugs and the sleeping mask, don't take sleeping pills and stay away from taking melatonin in capsules. Stop drinking liquids at least 2 hrs before going to bed. Use the anatomic mattress and pillow.

<comment><USER9> > Stop drinking liquids at least 2 hrs before going to bed

Even water? What if you're thirsty? Any sources?

<comment><USER8> To me it's just stop eating AND drinking at least 2 hrs before going to bed. My most reliable source is "burn the fat feed the muscle" book that helped me to endorse the healthy way of living this life...Here is the quote:

"I strongly recommend moving the last intake for the day as far away from bedtime as you can. 3-4 hours is ideal, but at least 2-3. This increases the length of the "fast" which in reality nighttime is - broken by breakfast. Using this method consistently is one of the most effective ways to lower body fat - and it doesn't take a lot of effort"</comment></comment></comment></comment></comment></comment></comment>


Study: Women Who Can Do Math Still Don't Get Hired - <AUTHOR> http://economix.blogs.nytimes.com/2014/03/10/study-women-who-can-do-math-still-dont-get-hired/ <comment><USER2> I wish we had the actual paper, because the abstract and summary are odd:

 _We studied the effect of such stereotypes in an experimental market, where subjects were hired to perform an arithmetic task that,_ on average, _both genders perform equally well._

If this is actually what they did, then it's a bit shady. Most of the data shows that men and women are the same _on average_ , but men have a higher _variance_. So if managers are hiring the best, you'll get more men. Of course, the paper is paywalled, so who knows?

It is nice to know that objective measurements can reduce bias. Score 1 for hiring by github. I'd be curious to see what happens with incentives taken into account - make the employees do math problems and the manager gets $1 for every correct answer.

<comment><USER3> Here you go: [https://mega.co.nz/#!6UxzVLIA!BVUOujU76VnhZM45QE4N2oFz0yLRTf...](https://mega.co.nz/#!6UxzVLIA!BVUOujU76VnhZM45QE4N2oFz0yLRTfgO4Mj6GRgT9wU)

<comment><USER2> Actually this paper is very interesting. So they did in fact reward employers for employee performance.

What I found the most interesting:

 _If, instead, we were to impose a random choice on employers, their earnings would drop by 11.4%, because employers do gain some relevant information from the appearance of the candidates, and this information allows them to make better-than-random choices (as can be seen in Fig. 1, which shows that employers in this condition choose the higher-performing candidate 55% of the time)._

 _If we remove the anti-women bias in expectations [in the case of appearance only], employers would earn only 0.1% more in compensation._

So it turns out that anti-female bias is almost negligible _when basing decisions entirely on candidate appearance_. That's really surprising to me. I wish they included a table describing how much alpha could be gained by eliminating anti-female bias in all cases.

Also, it looks like the best (and least biased) predictor was Past Performance. Surprise surprise. Maybe people will now stop complaining about employers who ask for a github (aka "Past Performance") instead of a resume ("aka "Cheap Talk")?

</comment></comment></comment><comment><USER4> I'd be interested in seeing a meta-version of this: give two papers with identical methodologies, one showing that employers tend to hire women less because they are biased, and one showing that employers tend to hire women less because the women are less capable.

Then present them to reviewers and see which ones they would accept for publication.

</comment><comment><USER5> I just did an Implicit Association Test, as suggested by the article, and got a result that was interesting in light of my views of myself.

[http://implicit.harvard.edu/](http://implicit.harvard.edu/)

<comment><USER6> Oh, wow, I highly suggest everyone try this. It really puts your subconscious bias into stark focus.

<comment><USER7> All the tests are highly political topics centered on identity politics & social justice topics. They also have weird American classifications of ethnicity being only "Hispanic vs non-hispanic" and "race" which seems more attached to skin color vs who the person is. I tapped around other countries and saw that they used some more or less classifiers of ethnicity & 'race' but the distinction are still there. It makes me put doubts about the testing itself and how much it would be used to advance political agendas.

</comment></comment></comment><comment><USER8> Reading the abstract, it is interesting that the gender of the manager do not effect the bias.

I did however not like the idea put forth by the paper that managers should assume that people lie about their performance. Doing so will only cause inflation in the lies, in which honest people will lie to balance it up and dishonest people will lie even further to get an advantage over honest people.

<comment><USER9>
        > I did however not like the idea put forth by the
        > paper that managers should assume that people lie
        > about their performance

How about: people are generally poor at objective appraisals of themselves?

<comment><USER10> my resume is a little on the exageration side. mainly so that when hiring managers read my resume and assume i'm lying they'll hopefully end up with a picture of me thats about at the right place.

Also I think that appearing to be better than you really are is a skill that companies are interested in having on their work force. So being frank and transparent could possibly work against you, especially if the hiring manager knows youre being frank and transparent.

<comment><USER9> I think you are over thinking this. I interview a lot of people for engineering positions. If I think you're trying to deceive me, or I think you've lied on your CV, you're getting a much bigger black mark than if you struggle a bit on the technical tests.

An aside: if you consider a $30,000 wage bracket a senior developer might fall in to ($80k-$110k), I see little correlation between what people ask for and what they 'deserve' based on their technical skills (inside of that bracket)

</comment></comment></comment></comment><comment><USER11> This is a shame. My anecdotic experience is that 9 out of 10 female engineers are solid, productive members of society and 1 out of 10 is marginal. The male side is much worse. Yes there is 1 out of 10 who is really good, but 2 out of 10 are not worth their paycheck at all, 1 is marginal and 6 out of 10 are solid productive members of society.

<comment><USER12> My experience is the opposite of yours (I wish it wasn't so). I've haven't worked with that many female engineers in 28 years as an engineer. There's been maybe 12 total as there are so few.

Of those 12 only 2 would I personally hire. That's under 20%. On the male side, depending on the company, it's between 95% at good companies and 50% at bad. In other words, 80% of the women I've worked with didn't seem like a peer (as in able to keep up) whereas less than 50% of the men couldn't keep up. In both camps, men and women, there were plenty of people I liked as people and would be happy to have as friends but I wouldn't hire them to work with.

I know that's just an anecdote

Maybe we're saying different things though. You're claiming in your experience 9 of 10 female engineers are productive members of society. I'm claiming in mine 10 of 12 female engineers are not productive engineers. They may be productive members of society but at work I need productive engineers.

It would really be nice if there was an objective way to measure and or fix this. I'd really like engineering more if there were more women and every time I interview a woman for a job position I hope she's going to pass but even that has been poor. Then again, so few women interview that I don't know what the hit vs miss ratio is there vs men. I'd say it's 1 of 6 or men at best. So far it's 1 of 5 for women meaning I've only interview 5 women since we get so few female applicants.

<comment><USER13> > _I know that 's just an anecdote_

that's not just an anecdote, that's a disastrous sampling scheme.

</comment></comment></comment><comment><USER14> It's not just math, you can put any traditionally male-dominated field in and it'll still work i.e. Study: Women Who Can Code Still Don't Get Hired; Study: Women Who Write Games Still Don't Get Hired etc etc

<comment><USER15> Who is hiring game developers?

<comment><USER14> In New York, there's a relatively large indie game scene. They hire game developers, but usually for casual games i.e. iOS app games (think flappy bird) or indie games

</comment></comment></comment><comment><USER16> Study: 90% deaths at workplace are men.

Study: most victims of violent rapes are men (prison)

Study: college hostile towards men, most graduates are woman.

<comment><USER17> > Study: most victims of violent rapes are men (prison)

But that's just funny! "Don't drop the soap!" haha...

<comment><USER16> What is funny about that? 20% of rape victims are totally ignored.

<comment><USER17> sarcasm

</comment></comment></comment></comment><comment><USER18> Edit: if you want to down-vote this, go ahead, but please tell me which one of the facts I have written is incorrect. I also welcome opposing viewpoints with explanations. I am merely providing some of the reasons that men are hired above women. This does not necessarily represent my personal viewpoints, I am playing devils advocate in some cases here.

> _The economist Larry Summers famously suggested once that so few women > become scientists and engineers because of discrimination, preference and > even differences in innate ability._

Ability? There are many teenage prodigies who become homeless and total failures in life. Who ever thought that ability alone guarantees anything? This is a flawed and narrow minded mentality.

Does anyone ever stop and think that there may be more logical reasons than ability that men are hired above women?

There are probably thousands of reasons that men get hired in front of women. Here are some (many of which are not politically correct) facts. As derived by science, statistics, and surveys. I am only echoing information based on research and experience (as a HR specialist for 15 years). These are generalities and certainly don't apply to all women and all men.

Women are generally less ambitious (even if they had better grades). Less creative problem solvers, and less logical (more emotional) with their decisions. Most of them lack the strong drive that men have for career advancement and success. Many men relentlessly work toward advancement and achievement despite having to make sacrifices such as family time, and other obstacles. Much of this is because of the role of testosterone and the design of the male brain (for competition and dominance). I am not saying that there are no women who are ambitions. I am just saying that the ratio is highly in favor of men here. I mentioned the testosterone part because many of you will respond that it is only that women have not been given the proper chance and thus the difference. This has been dis-proven by science and statistical studies.

Most women at some point get pregnant and have kids. This (moderately to severely depending on the person) affects their productivity and mood while pregnant (9 months). Afterward they are off work for 4-6 months (or potentially much longer if the newborn has health problems). The women cannot be legally replaced during this time. Her job has to be waiting there for her when (and if) she eventually comes back. When she does come back, women miss far more work than men to take care of sick kids. This all puts a company in a difficult position (financially and otherwise) that does not exist for men.

Women miss work more often than men because of personal illness and depression.

Women are far less amenable to overtime and don't perform well in crunch situations. They do not cope with stress as well as men, and emotionally degrade with fatigue at a far faster rate than males. When distressed, they become irritable, combative and irrational more often than men when in high stress situations (their emotions escalate more quickly).

Women's hormones fluctuate at a far higher rate and frequency, often affecting their moods, concentration, and productivity. Estrogen causes emotional instability and fluctuation. Men have little estrogen and don't experience the peaks and valleys that women do. Women are more likely to form clicks and ostracize, other women among other social problems. Women just don't get along with women quite often. It causes a real distraction for everyone and hurts workplace morale.

Women (attractive ones) are a distraction to many men. I am generally not blaming women for this, but it is a fact. Men will spend time talking to a pretty female employee just because. Workplace relationship that may form are often disastrous. When the relationship ends, a real mess ensues.

Men can and do occasionally (some men more than occasionally) talk dirty when women aren't around. You have a women around and men have to watch everything they say. They can't say t__s or b__bs out loud. That could land them in the unemployment line because of a sexual harassment complaint.

Men have been in charge since the beginning of time. They have leadership built into their DNA. They see women as trying to encroach on that and being the competitors that they are - don't want extra competition. This is natural.

Political correctness and "equality". Wither you are are for or against them, are not natural, logical or intuitive. Men thinking that men should be selected above women in tech/science because as a whole, they posses more natural skills and posses less natural challenges is logically the best bet. There are instances where a women will outperform a man, but statistically the odds are against this happening by a large scale.

Edit: here are a couple more statistics: Women are more likely to quit a job. Women are more likely to exit the workforce altogether.

There are a number of books rationalizing gender based wage and hiring inequality that point out far more statistics and logical (cause and effect) reasoning than I have mentioned here. I will try to dig up a couple.

<comment><USER19> With the exception of pregnancy, most of the points you raise are symptoms of inequality rather than causes:

\- Women are "less ambitious" because they perceive, often rightly, that their path up the ladder is blocked.

\- Women miss more work due to illness and depression because they aren't treated fairly and are put under more pressure to get the rewards their male counterparts get easily.

\- Women are less amenable to overtime because men are less amenable to doing housework.

\- Women can, and do, cope with "hormone fluctuation" very well. They're quite used to it.

\- Attractive women in the workplace are only a distraction to unprofessional, easily distracted men.

Your two final points are plain wrong:

\- Men talking dirty in the workplace just shouldn't. Regardless of the (imaginary) sensibilities of women, what about the men who don't like that?

\- Men haven't been in charge since the beginning of time. History has had plenty of matriarchal societies.

The simple fact is, any business that doesn't select the best possible candidate _regardless of gender_ , is failing their duty to their shareholders/investors/employees to build a secure, stable, profitable and growing company. If I knew that a company I owned part of was recruiting men over women even when the woman is the better candidate I would call for the CEO to be fired.

<comment><USER20> Thank you for posting this. I'd just like to also add that the "best possible candidate regardless of gender" clause does not run orthogonal to having ratio targets.

Firstly, they act to overcome the biases mentioned in the OP. Secondly, rarely do employees operate in a vacuum, and the benefits brought to teamwork by having mixed genders is important and valuable. The office I work in is infinitely richer for having moved towards having more equal (albeit still terribly inequal) gender balance by recruiting female Engineers. This shines through in group work where a diverse range of perspectives is important at achieving a robust outcome, e.g.: risk assessments, etc.</comment></comment></comment>


Things about programming I learned with Go - <AUTHOR> http://mjk.space/5-things-about-programming-learned-with-go/ <comment><USER3> > It's better to compose than inherit

I know that this is just a restatement of the "composition, not inheritance" mantra in Go, but it still makes about as much sense as "product types, not sum types". A more meaningful statement would be: "use inheritance to express sum types, use composition to express product types." There's no "better" relation between the two concepts, each has its own distinct purpose.

Yes, inheritance has traditionally sometimes been abused to implement a limited form of product type (for example, to work around Java's lack of proper value types), but that's a misunderstanding of what inheritance is used for.

> Go doesn't have the concept of inheriting structs by design.

Go has automated delegation, and as we know, (automated) delegation IS inheritance [1, 2]. Some implementations of delegation are a bit more limited, some are a bit more expressive, but fundamentally they have the same purpose.

[1] [http://dl.acm.org/citation.cfm?id=38820](http://dl.acm.org/citation.cfm?id=38820)

[2] [http://dl.acm.org/citation.cfm?id=900985](http://dl.acm.org/citation.cfm?id=900985)

<comment><USER4> 'A more meaningful statement would be: "use inheritance to express sum types, use composition to express product types."'

I'm not sure how well that works as a meaningful statement, because it assumes that the reader has a solid grasp of what a sum type and a product type are. If not (and I make the perhaps dubious assumption based on my own experience and knowledge that most programmers, especially most people using mainstream languages like Go or C++ or Python will not) then it doesn't really convey any information, unfortunately. I think a lot more people will know roughly what inheritance and composition are.

<comment><USER5> That's ... sad. Sum types and product types are simultaneously easier to understand _and_ are more useful to know about than inheritance.

Sum types are simply types whose values can be one of several choices - <USER2> that's something a _child_ can reasonably understand!

Product types might be a little harder to grok - they're essentially structs - but surely no harder to understand than inheritance and the whole IS_A/HAS_A mess

<comment><USER6> Inheritance is not a way to express sum types, it's a form of subtyping. A sum type is like a discriminated union, it can only be one thing at a time. Subtyping allows a value to have multiple (related) types simultaneously, which is much more expressive. I suppose you can use one level of single inheritance to emulate a sum type, but you could just as well emulate it with a discriminated union in Go, e.g. a struct with a type identifier and an interface{} holding the value.

<comment><USER3> > Inheritance is not a way to express sum types, it's a form of subtyping.

A distinction without a difference. This is probably most visible in languages like Scala and Kotlin, which implement algebraic data types by way of inheritance.

That inheritance creates a subtyping relationship is irrelevant; there's a similar subtyping relationship between variants (or groups of variants) and the overarching type using a traditional sum type notation as in Haskell or ML. This is most clearly visible in OCaml's polymorphic variants [1, 2].

[1] [http://caml.inria.fr/pub/docs/manual- ocaml-400/manual006.htm...](http://caml.inria.fr/pub/docs/manual- ocaml-400/manual006.html#toc36)

[2] [https://stackoverflow.com/questions/16773384/why-does- ocaml-...](https://stackoverflow.com/questions/16773384/why-does-ocaml-use- subtyping-for-polymorphic-variants)

<comment><USER7> Pony ([https://ponylang.org](https://ponylang.org)) uses sum types, perhaps excessively. Just yesterday, I wrote:

        (None | (In, USize))

I.e., None (the null valued type) or a pair made of a type variable (In) and a USize.

The thing is, the values that satisfy this type are not subtypes of None and a pair. (That would be silly, given None.) Such a value is either None, or a pair.

<comment><USER3> > The thing is, the values that satisfy this type are not subtypes of None and > a pair. (That would be silly, given None.) Such a value is either None, or a > pair.

Unless I'm misreading you, this seems to be a misunderstanding of what sum types are. A sum type `T = A | B` represents the (disjoint) union of all possible values of `A` and of all possible values of `B`, simply put, not the intersection (as you seem to indicate by the phrasing of "not subtypes of None and pair"; correct me if you meant something else).

Recall what subtyping means (I'm going with Wikipedia's definition here for sake of accessibility):

> _[S]ubtyping (also subtype polymorphism or inclusion polymorphism) is a form > of type polymorphism in which a subtype is a datatype that is related to > another datatype (the supertype) by some notion of substitutability, meaning > that program elements, typically subroutines or functions, written to > operate on elements of the supertype can also operate on elements of the > subtype._

This holds in the case of sum types. Operations that work on the sum type will generally also work on the variants that constitute the sum type.

The same goes for inheritance. If an abstract class T has two concrete subclasses `A` and `B`, then a value of type `T` belongs to the union of values of type `A` and of type `B`.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm no Go expert, so the following may just come from having not used it enough.

The two things that shocked me out of continuing with Go were exception handling and package management.

Exception handling is basically not implemented. Instead the Go developers dediced to add half a step from return codes towards exceptions and work with that. And now the community seems to have decided to just reraise everything that comes their way. Nobodoy seems to see that such a simple basic feature shouldn't require a piece of code, it should be done automatically by the language. And the community doesn't seem to see why it's nearly impossible to debug. I really hope that Go developers have some secret tools I just don't know about, because there are no stack traces, and on the abstraction level of a user getting an error from an underlying framework printed out doesn't really help at all, especially when the code seems to continue after printing the error (making it a bug, by reporting a warning as an error). My favorite example is kubernetes helm reporting a connection error in my job's infrastructure, every time you use it, but after that error it actually switches from IPv6 to IPv4 and just works. But still it feels good about reporting that error. wtf.

The next thing is package management. I had high hopes here after going through the trouble of working on that topic in 2012 when the Python community was developing its package management. I mean if you don't add that on top of an existing world, but create it from scratch, there is a chance to just do it right and not have to bother with all the pains of legacy systems, right? Well, Go decided it doesn't need versioning on imports. Just put the Github link there, don't even choose a branch. How can any code ever get finished that way? My best guess is that now they have to develop stuff on top of that already-born-as-legacy system and also try to integrate that with their core. Sad.

I really hope someone can add some corrections to this view.

<comment><USER9> I'm about 8 months in to using Go for a few largish projects and I'd say these are probably the two biggest things I still struggle a bit with. (not generics as others seem to obsess about)

On errors, I'm really of two minds. In a way, it is a lot like how Java started with checked exceptions, it forced you to deal with the error. But at some point most people decided that was annoying and switched to runtime exceptions for everything, which while requiring a lot less code, still led to errors often bubbling up all the way to the user.

I think checked is the right thing, but it does require developers to be thoughtful and not just throw errors upwards. If you accept that checked is the route you want to go, I don't find Go's use of error values worse than exceptions.

On the package management front, I think the current best practice for projects that must not break is to vendor your dependencies. Go is working towards having better tools to allow you to specify SHA's for your dependencies easily but we aren't fully there yet.

While it took a bit to wrap my head around using `govend` to vendor my dependencies, in the end it really hasn't ended up being a big pain point in practice. I also never have to worry about a dependency either disappearing or pulling a trick of shipping the same version # with different code. (or having the repo/package manager be down, which anybody who has shipped a lot of code will tell you has happened)

So yes, I agree these are both, weird, but they aren't deal breakers. For our particular application, I really love Go, more so than I have any other language in recent memory.

<comment><USER10> > not generics as others seem to obsess about

One reason people obsess about generics is specifically because of error handling. With generics, you could implement Result and Option types, which make error handling significantly more sane.

<comment><USER11> Personally I loathe this style of programming. It's not that it's difficult, it just seems to obscure code a great deal.

Writing this sort of thing in Rust:

        fun some_function(a: &A) -> Result<&B, SomeError> {
            let c = foo(a)?;
            let d = foobar(a, c)?;
            Ok(if xfoo(c) {
                let e = blah()?;
                bar(d, e)?
            } else {
                baz(d)?
            })
        }

where you have to write every function in this pseudo-do-notation where 'return' is just wrapping the return expression in 'Ok' and `a <\- expr` becomes `let a = expr?;` is just horrible.

I'd much rather write this:

        fun some_function(a: &A) -> &B throws SomeError {
            let c = foo(a);
            let d = foobar(a, c);
            if xfoo(c) {
                let e = blah();
                bar(d, e)
            } else {
                baz(d)
            }
         }

See how that's so much cleaner? It's not actually any different from exceptions anyway, you're basically using them like exceptions, and they're implemented in the same way. The difference is that in the latter the code is much simpler and easier to understand. That's all.

In fact, that syntax could be added to Rust (after 6-12 months of bikeshedding as usual) and just have it automatically translated to the above anyway.

The other issue with Result/Option is that people start doing really horrible things like adding Option::map. Sorry but it's not a container that has 0 or 1 things in it. It's an optional value. That they're mathematically equivalent doesn't mean that they're the same thing conceptually. It's as bad as pretending that Result<T, Err> is useless and everyone only needs Either<L, R> where by convention R is the error value. God please just no.

<comment><USER10> > See how that's so much cleaner?

No, I don't. I look at the former snippet and I can easily tell each and every function invocation that can cause SomeError. In your theoretical style, I have no idea whether foo, foobar, xfoo, bla, bar and/or baz will throw that error. I prefer explicit over implicit since I find it far more readable.

> really horrible things like adding Option::map

You can quibble about the names (Option and map), but Option is essentially the Maybe monad and map is bind, so you're kinda arguing against core functional programing constructs.

<comment><USER11> >No, I don't. I look at the former snippet and I can easily tell each and every function invocation that can cause SomeError.

The reason that functions have type signatures is that you can read them. You can tell which functions can cause SomeError by going and reading their definitions.

>I prefer explicit over implicit since I find it far more readable.

'Explicit over implicit' is dogma. Rust requires you to annotate your code with gibberish in cases where it is not necessary.

>You can quibble about the names (Option and map), but Option is essentially the Maybe monad and map is bind, so you're kinda arguing against core functional programing constructs.

That's literally my entire point. The attitude that it's technically a Functor so it makes sense for it to be called map? No, it doesn't. It's not a map. You're not mapping over anything. Naming is important.

Calling it 'the Maybe monad' shows that you actually have no idea what you are talking about. It's not 'the Maybe monad'. The Maybe monad is the instance of Monad for Maybe. It is _not_ Maybe itself.

The entire concept of having the literal 'Monad' word as a word in your language, a thing that you use in programming, is very stupid. Monad is not a useful or good abstraction. Maybe is a good abstraction. Or Optional, or Option, or whatever you decide to call it. But Monad is a bad abstraction. Abstracting over superficial syntactic similarities between completely different constructs is completely stupid.

The name being terrible is not 'quibbling' by the way. Naming is incredibly important. Calling it 'map' just shows how out of touch Rust is with real programmers.

</comment></comment></comment></comment></comment></comment><comment><USER12> Don't want to hi-jack the article, but we've built Bugfender using Go. The problem is, we thought this is an internal (experimental) project and so Go (as a new language) would be fun to try out. But then Bugfender started to take off and we ran into serious problems making Go scale. Not because it is a bad language, but simply we were new to it ourselves.

Today we're still running on go and we're more or less "ok" with it now, but it was a difficult path to get there and while it's fun to use a new language (or new anything) it's probably not the best choice for a startup product. Also when you need to hire people.

We've summarized our experiences here:

\- [https://bugfender.com/blog/one-year-using- go/](https://bugfender.com/blog/one-year-using-go/)

\- [https://bugfender.com/blog/go-pros-cons-using-go- programming...](https://bugfender.com/blog/go-pros-cons-using-go-programming- language/)

\- [https://bugfender.com/blog/three-years- bugfender-9-5m-users/](https://bugfender.com/blog/three-years- bugfender-9-5m-users/)

<comment><USER13> I would have thought Go is easy to hire people for. It's such a simple language and has such a well-designed standard library you can pick it up extremely quickly.

I think "anyone can learn it" is one of its main benefits. Compare that to Rust or Haskell for example...

<comment><USER14> I think the issue is finding people that _want_ to learn it. Systems programmers are turned off because of it's limitations and your average pythonista or rubyist isn't interested in mucking around in type definitions or even thinking about concurrency.

<comment><USER15> > Systems programmers are turned off because of it's limitations and your > average pythonista or rubyist isn't interested in mucking around in type > definitions or even thinking about concurrency

Systems programmers were the bulk of Go's early adopters, even before it hit its first stable release.

I can't speak for Ruby, but as for Python - I've been writing Go professionally for five years, and my first talk on Go was actually at the New York Python Meetup. They specifically asked me to speak about Go because they had significant interest from their members in learning or using Go. This was back when Go was still on its 1.0 release.

Soon after that, Python added type hinting and concurrency to address needs that Python programmers had. That was enough for some, but there clearly has been interest from Python programmers in Go's approach, and there continues to be; Python is one of the more common language backgrounds for new Go programmers that I see.

Furthermore, there's no shortage of experienced developers who already know Go. While the numbers are evening out a bit as more companies have begun to adopt Go, there are still more experienced Go programmers looking for jobs where they can write Go full-time than the other way around. (And that's not even looking at people who are inexperienced programmers or experienced programmers who don't know Go but might be interested in learning.)

Go may not be for everyone, and that's fine, but there's really no shortage of good programmers who can write Go. If a company is evaluating languages and considering Go, availability of talent is a _selling point_ , if anything, not a concern.

<comment><USER16> My subjective impression (supported by informal surveys [1]) is that most Gophers come from a Python or Node.js background, doing mostly network code, DevOps automation or CLI tooling. Rubyists are less likely to fall in love with Go, given that the huge philosophical gap, though the pragmatist among them adapt go for what it excels at (performant microservices and statically linked binaries).

Still, most newcomers to Go seem to come from dynamic typing background, and it shows with all the buzz about Go being 'strongly-typed' and 'helping you to detect typing errors', which sounds crazy to anyone who played with C++ or C#, let alone an ML-family functional language.

And yes, Go also has a small but prominent contingent of C developers, and while some of them _also_ do systems programming, this is generally not what they do in Go. This crowd seems to be mostly focused on tools and networking- oriented code, two areas where Go excels. The thorough standard library and top notch static linking support make go a hard to beat choice for this type of work, but its a less obvious choice for traditional systems programming, which usually still eschews garbage collection.

You'll rarely find Go being used in most of the traditional systems loads: drivers, kernels, high-spec graphic engines, emulators, JIT compilers, filesystems, browsers and definitely not in real-time programs. The one traditional systems realm where Go does see some activities is lightweight databases and key-value stores (BoltDB, TiDB), but databases performance is often dependent on concurrency no less than it depends on memory, and in fact Java has been long popular for NoSQL databases (HBase and Cassandra), and even way more niche languages like Erlang gave rise to popular NoSQL solutions (Riak, CouchDB).

[1] [https://blog.golang.org/survey2016-results](https://blog.golang.org/survey2016-results)

</comment></comment></comment></comment></comment><comment><USER17> > 1\. It is possible to have both dynamic-like syntax and static safety IHMO: > This convenience causes more harm than good in the long term. Note: My > experience is that this is a minefield of bugs and defeats the point of type > safety. Also, because Go lacks generics, there's a lot of boiler plate and > interface being used as function argument (just check large open source > repos on github and you will notice).

> 2\. It's better to compose than inherit IHMO: It's better to have both tools > available. Note: Inheritance, like static types, offer a more rigid > structure and helps on large project that will exist in the long term. In a > language that does not offer something like traits, "composition of > behavior" ends up being a hack. Of course, we also have the tendency of > blaming the language for the fault of the programmers. I would think the > example of the Vehicle is not the best to explain the paradigm of behavior > composition.

> 3\. Channels and goroutines are powerful way to solve problems involving > concurrency IHMO: Powerful, yes. But I would use actors instead. Note: Same > problem: as your business problem gets complex, goroutines start to become a > pain and the code will become unreadable and littered with hacks.

> 4\. Don't communicate by sharing memory, share memory by communicating. I > read other comments here that express what I think better than I can > articulate Note: You still have to "synchronize" if you are working with > shared resources. There's no magic solution.

> 5\. There is nothing exceptional in exceptions Oh, Boy! This causes more > wars than "space vs tab". IMHO: Good in theory. Too rigid in practice. Note: > While works for small stuff, the the lack of exceptions becomes a problem in > large projects, causing people to just ignore "for now" (and usually, > forever).

In conclusion: The "cool features" of Go might teach some people about programming, but take a toll on more complex projects. I would use Go for small system utilities and tools but would never touch business logic with it.

<comment><AUTHOR> Hi, author here. Thanks for your opinion.

> 1\. On a daily basis I work in a 200k LOC Ruby project and to me from that > perspective lack of static typing is a minefield ;)

> 2\. Since I have finally learned how to do proper composition (~a year ago) > I haven't use the inheritance even once. Of course, you may say that my > project is special, but I can't help feeling that inheritance is often > overused.

> 3\. Yes, I've also come across opinions that Go's channels are too low level > to be used in a large commercial project. But still, as a concept I find > them interesting.

> 4\. True. But, you can have one goroutine that'll just "guard" that resource > and communicate with it from many places using one shared channel.

> 5\. TBH I've seen more flame wars about the "space vs tab" thing ;) As I > mentioned in the article I don't think that's the best error handling > pattern ever invented, but I just like the concept of treating errors as > regular return values. IMO it's good to have it at the back of your head, > regardless of the language you use.

</comment></comment><comment><USER18> "There is nothing exceptional in exceptions"

No there's not, but it's a royal pain the arse to have to keep passing them up through your function calls to the level that actually cares about them and will do something about them. Try/catch eliminates boilerplate.

<comment><USER19> Doesn't Go have any syntactic sugar for pass errors out of function? Something like Rust's Carrier/From traits and try! or `?`.

<comment><USER20> No, go "errors" are just a convention, there is absolutely nothing special about them.

Go has panic/defer, which are exceptions, but done badly. They were probably retrofitted in the language when its creators realized they needed exceptions anyway, which makes the whole "error as value" a bit hypocritical. If they truly cared about error as value, then yes, Go would support some form of try! macro.

<comment><USER21> Yes, Rust would be seriously irritating without try! (and its short friend the question mark operator). So I feel the pain of gophers here.

</comment></comment></comment></comment><comment><USER22> Minor nitpicks, from someone who really likes Go:

> It is possible to have both dynamic-like syntax and static safety

Well, you can learn that one by coding in C#, too. In fact, I have the feeling this is a general trend across several relatively popular languages these days - provide as much as possible of the benefits of dynamic typing while keeping the benefits of static typing.

I sometimes think how nice it would be if I could write my code entirely without type declarations and have the compiler or some preprocessor figure out as much of the type information as possible.

> It's better to compose than inherit

It depends, really. Personally, I think composition is the simpler solution more often than inheritance, but sometimes it is not.

I completely agree about the error handling, though - at first it was very tedious to handle all errors explicitly, but after I while I came to appreciate it. Once I had fallen into the habit of checking for errors without having to think about it too much, detecting errors became much easier, and deciding if I could "deal" with some error or escalate it (possibly to the point of terminating my program) became more straightforward, too.

<comment><USER23> > In fact, I have the feeling this is a general trend across several > relatively popular languages these days - provide as much as possible of the > benefits of dynamic typing while keeping the benefits of static typing.

Some languages go the opposite way. Dart 1.0 has optional typing, but Dart 2.0 will be statically typed (with type inference though).

<comment><USER3> > Dart 1.0 has optional typing, but Dart 2.0 will be statically typed (with > type inference though).

Not quite; it's more that compile time typing is getting cleaned up. You can still omit types, which will then either be inferred or set to `dynamic`. The following is valid strong mode Dart:

      f(n) {
        if (n <= 1)
          return 1;
        else
          return n * f(n - 1);
      }

The following will no longer work:

      int x = "foo";

In short, you can still omit types. It's just that _if_ you declare them, they are enforced [1]. Dart will also infer them if possible, i.e. the following is illegal:

      var x = 1;
      x = "foo";

Here, x is inferred to be `int`, which makes the assignment of a string illegal. However, the following works:

      var x = true ? 0 : [];
      x = "foo";

Here, the type of `x` cannot be inferred, so it becomes `dynamic`, and therefore the assignment of "foo" becomes valid.

You can turn this off with --no-implicit-dynamic; with this option, all types must either be declared or have to be inferable.

[1] Sometimes not at compile time, though: Dart allows implicit downcasts and covariant generics at compile time and will insert runtime checks to catch those situations.

</comment></comment></comment><comment><USER24> I came to really dislike embedding interfaces and types, but I know I'm a minority opinion, on this.

When I came to go from OO (ruby), and before I learnt to use embeddings, something blew my mind : I could always say where a function was coming from, and which functions were available in the current scope. No need to grep anymore to find from which parent class or which included module a method was coming from.

And after I started using embedding all over the place, I realized that problem was back again. Go made me love the idea of "simplicity, not easiness" and the fact that I can get what code was doing immediately, without wondering where parts were coming from. Today, I prefer to avoid embedding altogether. I use function parameters instead of types, and this also has the advantage of avoiding initialization problems (and if I omit a parameter, I'm immediately warned by compiler).

</comment><comment><USER25> > Don't communicate by sharing memory, share memory by communicating.

Well, if you're using immutable data-structures, then structural sharing can be very useful. You can then pass large data-structures in constant time, and of course you can "modify" them efficiently using immutable techniques.

As long as you don't perform any writes in a shared data-structure, the memory hierarchy should be perfectly happy and no delays or locks should be necessary.

Of course, as you start scaling across multiple machines, there will be different trade-offs, as there will not be a shared memory bus.

<comment><USER26> You're not "communicating by sharing memory" though, at least in the idiom's sense (in which "memory" is an alias for "mutable state"), the structural sharing is just an optimisation.

Which may not even be desirable: despite being built entirely upon immutable data structures, Erlang only share large binaries between processes (AFAIK even the new maps are copied despite being HAMT) to ensure process heaps and thus garbage collections are completely independent.

<comment><USER25> > Erlang only shares large binaries between processes to ensure process heaps > and thus garbage collections are completely independent.

That sounds unnecessarily restrictive. At least they should give developers a choice (e.g., "this process should receive integral data, and should not be disturbed by a GC cycle of other processes").

Also, concurrent (not stop-the-world) GC techniques could make this problem moot.

<comment><USER26> > Also, concurrent (not stop-the-world) GC techniques could make this problem > moot.

It would mostly introduce insane additional complexity. Erlang GC works per- process (each process has its own private heap and stack) and you'd normally create lots of small processes, so the GC is concurrent as an emergent effect of the system construction.

Not to mention processes can be distributed across nodes for which your scheme completely breaks down, what's supposed to happen if you ask for memory sharing across the network?

<comment><USER25> > It would mostly introduce insane additional complexity.

GoLang has a concurrent garbage collector.

> what's supposed to happen if you ask for memory sharing across the network

Yeap, I mentioned that. Again, as a developer you want the choice. You don't want your language telling you "sorry, that's too complicated for your brain, so you can't do that".

<comment><USER26> > GoLang has a concurrent garbage collector.

Golang also has a single, shared, mutable heap, it does not have tens or hundreds of thousands of individual heaps.

> Yeap, I mentioned that.

No, you did not.

> Again, as a developer you want the choice.

Er… no?

</comment></comment></comment></comment></comment></comment><comment><USER27> > Authors of Go wanted to give users more flexibility by allowing them to add > their logic to any structs they like. Even to the ones they're not authors > of (like some external libraries).

Except that you can't. "You "cannot define new methods on non-local type[s],". You have to compose them. That makes the struct function definition syntax a bit moot in my opinion.

<comment><USER28> I've never thought of that syntax as conveying a particular statement. They could also have done

      func *Receiver.method(arg int)

instead of

      func (r *Receiver) method(arg int)

The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.

<comment><USER29> _The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I 've come to like this design decision._

self, at least if you're talking about Python, is not a keyword, it's just a convention. You can use whatever your want.

<comment><USER30> It's not just python that uses self. Rust, for example, it's sugar for self: Self

</comment></comment></comment></comment><comment><USER31> "Error theater" and zero initialized values, while understandable due to other design decisions, are the biggest source of frustration whenever I have to work on go code.

Off topic from the article, I think, but what go has taught me about programming is that some parts of our industry are stuck in time and intellectually stagnant.

Go is a better C. I would prefer Go over Python. But really, when the state of the art (and production ready!) is light years ahead of Go, it frustrates me to no end to see colleagues spending so much time on things in their day to day that are solved problems in other languages.

<comment><USER11> This sort of attitude is never going to win over people that you are talking about. I hate to bring politics into things, but it's like calling all Trump supporters hopeless and backwards. Yeah maybe they are, but they're going to react to that by never listening to anything you say again, so even though it's true, it's not helpful.

The 'state of the art' is increasing, over-the-top complexity to a truly ridiculous level. Go programmers don't want to open up the documentation for a library and see this:

[http://i.imgur.com/ALlbPRa.png](http://i.imgur.com/ALlbPRa.png)

or look at the language reference and see this:

[http://en.cppreference.com/w/cpp/language/constraints](http://en.cppreference.com/w/cpp/language/constraints)

and I don't blame them.

</comment></comment><comment><USER32> > Thanks to goroutines and channels Go programmers can take a different > approach. Instead of using locks to control access to a shared resource, > they can simply use channels to pass around its pointer. Then only a > goroutine that holds the pointer can use it and make modifications to the > shared structure.

How does this prevent data races if more than one goroutine holds a pointer to the shard structure and they're running concurrently?

<comment><USER33> It doesn't. I think goroutines make concurrency easier that it is in, say, Java, but Go still passes around state and that is where a lot of the issues with concurrency arise. Concurrency is much easier to deal with in functional languages, where data is transformed via chains of functions, rather than stored in state.

<comment><USER11> The difference is that in Go, it is unidiomatic to share mutable state across threads, while in C/C++/Java it's not.</comment></comment></comment>


Versioning Feature for Amazon S3 Now Available - <AUTHOR> http://aws.amazon.com/about-aws/whats-new/2010/02/08/versioning-feature-for-amazon-s3-now-available/

<comment><USER2> It doesn't diff the versions, charges you for total storage:

[http://aws.amazon.com/s3/faqs/#How_am_I_charged_for_using_Ve...](http://aws.amazon.com/s3/faqs/#How_am_I_charged_for_using_Versioning)

<comment><USER3> Any idea why they don't do it the same way as snapshots?

<comment><USER4> I'd guess snapshots aren't retrieved fairly often so the additional CPU and IO overhead of reconstituting a version are totally worth it given the space savings, unlike for data that's used regularly?

(Disclaimer: I have no experience in snapshot system implementation so I don't know what I'm saying)

</comment></comment></comment><comment><USER5> If this works with CloudFront, it would save us a ton of effort renaming files to their MD5 hashes. We could then serve multiple concurrent versions of your website from a single file tree.

<comment><USER6> No word from them yet. They normally strip query arguments. Hopefully they'll make an exception for versioning.

</comment></comment><comment><USER7> There was some discussion previously, here: <http://news.ycombinator.com/item?id=1067154>

</comment><comment><USER8> if only they had rsync support...

<comment><USER5> No kidding. We only push changed files to S3 after every build, but it's still a lot of bytes that go across the wire. I wish there was a way to build a new file as a diff from an old one.</comment></comment>


Comparing Browser Page Load Time: An Introduction to Methodology - <AUTHOR> https://hacks.mozilla.org/2017/11/comparing-browser-page-load-time-an-introduction-to-methodology/ <comment><USER2> Great work. But, I wonder if is this is just a case of different browsers focusing on different metrics? Chrome seems to have shifted its focus on paint timing metrics [1], while Mozilla is optimizing load timing metrics.

Personally, I feel optimizing both metrics are important. It would be nice if this study had also published a comparison of paint timing metrics.

[1] [https://developers.google.com/web/updates/2017/06/user- centr...](https://developers.google.com/web/updates/2017/06/user-centric- performance-metrics)

<comment><USER3> In my opinion, not many care until of course it becomes a serious SEO no-no to have slow loading pages and the exact metric to hit Google's ranking.

</comment></comment><comment><USER4> I can severely recommend Firefox with the tracking protection. It's quite a refreshing experience compared to Chrome.</comment>


What books would you recommend to read about ZX Spectrum computer programming? - <AUTHOR> Hello. <comment><USER2> The original orange manual is pretty impressive. It even has the z80 opcodes in the back for when you graduate to assembler

And of course it's on the web.

[http://www.worldofspectrum.org/ZXBasicManual/](http://www.worldofspectrum.org/ZXBasicManual/)</comment>


Ask HN: How do you judge a HN submission and act on it? - <AUTHOR> 	I'm really curious about how HN audience shape the content quality: - The title may be unattractive, so what drives you to read them?<p>- After reading or skimming, what drives you to comment or upvote the submission?<p>Thanks. <comment><USER2> Your question is too broad to answer. Why not assume it's the same as for the readers of any other forum system, or for yourself? How would that assumption not be useful?

BTW, of your 14 submissions, 3 are AskHns and 2 appear to be your own writing on Medium. Are you asking us for help in how to SEO ourselves to read or reply to your content?

If so, there's a long process of trying to figure out what it is that you find interesting, which isn't already covered by others, and writing or commenting about it and finding an audience[1]. There can be shortcuts - "5 better ways to compile your code!" \- but it's always seemed a crowded field.

[1] I have an interest in the early history of chemical information. Which has an audience of a few hundred people. I've been researching it as a hobby for several years. Any title will likely be unattractive to HN readers. :)

</comment><comment><USER3> I think most people just read /new -- at least that's what I do. And afaict, the only thing that shapes /new is time always appearing to move in the same direction.

I comment on things I'm interested in. But not always. Often, whatever I would have said had already been said by the time I got there.

I don't usually vote because I don't care about votes. Frankly, I don't see the point.</comment>