rlander

For solo projects that don’t need all the boilerplate I think Hoplon is an even better option (there’s a Luminus profile for it). It’s kinda like Svelte: it doesn’t use a vdom and makes interacting with the actual dom really simple: http://hoplon.io/

Agree. But slowdown in internet hype doesn’t mean slowdown in industry adoption though.

That statement indicates that the author is not part of the Clojure community. My company uses Clojure and I know of many fintechs that also use Clojure as their primary language and are actively hiring. It is not a large community by any means, but it is very much alive.

I’ll bite. What’s a “fintech system” with “complex Gov app”?

Just wanted to mention that Sandstorm is awesome. For some reason, despite being around for years, I only found out about it recently. I really think that it should be way more popular than it currently is. Lots of apps are outdated, so I’m planning on investing some personal time to contribute to it.

I think a lot of responses in this thread are taking the author’s words literally. In my experience, it’s not about being more or less angry. Germans are more restrained with regards to showing strangers their true feelings, while Australians are more comfortable sharing their emotions. It goes both ways: if an Australian is feeling happy, he/she will smile at you but if he/she is feeling frustrated, it’ll also show.

I would definitely not consider someone who runs NixOS on the desktop inept nor inexperienced.

You have a fair point, but if by "more difficult" the grandparent meant "more difficult to maintain", I'd have to agree with him. The failure modes of processes running in the BEAM are much more transparent and understandable than the usual ad-hoc JS nodejs server.

You should be annoyed with the less than ideal coding practices of your former colleague not the language.

I feel the same way. Elixir users keep banging on the macro drum but most Erlangers don't want them.

I can read any Erlang program I wrote 10 years ago with ease. I have difficulty understanding a small Elixir project I wrote just a few months ago.

If both languages have the same semantics, why choose the one with more complex syntax?

"The language should be simple – Simple in the sense that there should be a small number of basic principles, if these are right then the language will be powerful but easy to comprehend and use. Small is good."

In one episode of Parks and Rec, the lead character, councilwoman Leslie Knope, is trying to pass a bill that adds fluoride to the town’s water source, while being opposed by a councilman/dentist who wants to continue making money off of the many cavities that occur in the town. As she discusses the debate, she realizes, “On my side, I have facts, science, and reason. All he has is fear-mongering. Oh my god, he’s gonna win.”

Best series ever.

> Async everything

What do you mean by that? Most code in Erlang/Elixir is synchronous, meaning it will block the process (but not the scheduler). Maybe you meant concurrent (or message-passing) everything?

Just to be a little pedant, Dialyzer (an Erlang success typing lib) precedes Elixir and the other static typing efforts you mentioned by many years, way before this so called “static typing renaissance”.

It’s a great project, but I doubt it’ll ever reach the maturity and functionality of Reagent, Om, Rum. Fulcro, Datascript, re-frame and Hoplon.

Same here. I’ll take Erlang’s conciseness and readability over Elixir’s prolixity any day.

I can think of a few reasons: same language between front and backend, extensive standard library, repl driven development, simplicity, brevity, spec.

Previous HN discussion: https://news.ycombinator.com/item?id=2852415

So, in a Python-only org, someone with no Erlang experience decided to ship his first ever server to production, thinking Erlang would be a magic bullet to “scalability issues”. Obviously, there were maintainability issues and the org, blaming the language, decided to switch back to python.

To me, the fact that a novice was able to deploy production code that went on unmaintained for months, running a crucial part of the operation, speaks positively about Erlang.

> the preferred left candidate just left political prison last week, after a year without trial

He was found guilty by no less than 20 different judges (in 3 different courts) half of which were appointed by the criminal (Lula) himself. And he’s still in prison, by the way.

My city does this (Florianopolis, Brazil). I can use a smart phone app to start the clock or just let an officer pass by and tag my car. Chalking seems very... rudimentary.

Take a look at REBOL. This one-liner opens a window with a form that accepts an email address and url, downloads the web page contents and emails it to said address.

  view layout [u: field "user@rebol.com" h: field "http://" btn "Send" [send to-email u/text read to-url h/text alert "Sent"]]

This is devastating. I’m in shock. Joe was one of my programming heroes and it was one of my goals to, one day, see one of his talks in person. He was incredibly articulate, good-humored and didactic in his posts on the Erlang list. He will be very much missed.

My last employer sent out a company-wide email asking every employee (and their friends and family) to order their flagship product (IoT device) on Amazon, write a 5-star review and e-mail the marketing department for reimbursement and product return. The returned products would then be re-shipped to Amazon.

Needless to say, it was the shortest time I've ever spent at a job.

This should be the first thing on the website: “why use this and not plain Js”.

I read everything and I still don’t understand why.

This seems targeted at bodybuilding (at least the landing page screenshots are). If this really works, it would be interesting to see how the algorithm fares in competitive sports like olympic weightlifting and triathlon.

Exactly. There's no silver bullet, only trade offs.

In this case you're only shifting the complexity from "maintaining" to "orchestrating". "Maintaining" means you build (in a semi-automated way) once and most of your work is spent keeping the services running. In the latter, you spend most of your time building the "orchestration" and little time maintaining.

If your product is still small, it makes sense to keep most of your infrastructure in "maintaining" since the number of services is small. As the product grows (and your company starts hiring ops people), you can slowly migrate to "orchestrating".

Awesome! That's exactly why I pointed out Lisp. Those who enjoy the tight feedback loop of Jupyter might also enjoy a language where this process is the natural way of doing things.

Thanks for the link, I'd never heard of REBL. Very cool!