The only folks I ever here say "the right tool for the job" are Java devs. /s

In all seriousness, people using non-mainstream languages are very attached to them. At least in my sample size of one.

In my experience on Windows 10, localhost doesn't work all the time 127.0.0.1 like it does on MacOS or Linux.

Lazy evaluation is what's most commonly blamed for that, no?

I just walked away from an offer at a React shop in Manhattan for 200K TC. There's plenty of specialization available still.

I think the ReasonML parser and formatter have numerous issues that'll keep it from being adopted more widely.

Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour.

The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy.

That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead.

An example of lossy translation from Reason -> OCaml:

https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBA...

You mean using ReasonReact without JSX in OCaml is a pain?

Doesn't it allow to quickly code something like HyperScript-Helpers?

I don't understand, what is being lost here?

`| ((Some (result))[@explicit_arity ]) -> Js.Array.forEach Js.log result`

the explicit_arity being added in. I can't think of other examples at the moment.

As far as I understand, 'lossy' would mean information was lost, right? But here it looks like information has been added.

I agree with that definition.

Maybe lossy is the wrong word, but the transforms historically had gotchas. PPX and what not. Especially when converting between Reason syntax version upgrades and the more stable OCaml syntax (locked to OCaml 4.2 because of bucklescript).

That doesn't necessarily mean lossy, but just that knowing what refmt will error out on depending on the version of Reason the code was written to target vs. locked down ML.

Long ago, when I was at Amazon, we used Collaborative Filtering pretty heavily. It's great when there's a heavily sweetened path with lots of things ordered together or in a chain.

It's horrible for moderately popular items though.

> The power balance is so skewed in the direction of the employee in the software industry

Maybe for the folks at the very top, the Rockstars of yore. Bloomberg ran this yesterday.

https://www.bloomberg.com/news/features/2019-02-11/apple-bla...

At least in Germany, there are quite a few EU local body shops pushing the power balance in employers' favor.

I did not get the feeling that the Bloomberg piece was about devs. Did I miss something? They specifically called out Apple Maps, which requires a lot of data cleaning.

In the US, maybe contractor/body shops are rarer around dev work? Mostly around the Department of Defense.

My point was that employers' ability to pull in lots of short term employees weakens their negotiating power. At least in Germany.

I think the point of the parent comment is that we're discussing software engineers, who certainly have a different negotiating power than the (presumably nonengineering) contractors mentioned in the article.

https://github.com/fscheck/FsCheck is something I've used very briefly in the past. I did more work with this sort of thing in Scala.

In my experience, you usually end up with much more coverage than you want or need.

Both BuckleScript and PureScript use the someVar|0 trick.

As an American that took a substantial pay cut (taxes add to the pain) to get into Germany, this sounds about right for my experience. I came over mostly as a cultural thing, and salary was less of a concern.

I work with a few Canadians as well, and they didn't have access to the same salary levels back in North America that Americans do, so salary is less of an issue for them coming to Germany.