HN user

choiway

72 karma

https://choiway.github.io B97F 5BA3 3E2D E45A 094A 5963 3413 5EAC 6083 2C90

Posts9
Comments51
View on HN

If you type a lot for a work, spending the time and money for better tooling is not only healthy but should be encouraged. Unhealthy, is when you try to track down an after market Key Cult for $2,000 and spend $500 on switches because you feel like you have to try them all.

You're not missing anything if you can and don't mind building a framework of tools that run long running processes, handle the start up, failure and state of those processes and be able to introspect the status and internal state of those processes in a standard way.

The way isolated processes can be created and managed allows for the "let it crash" ideology in Erlang. For example, when you visit a Phoenix Framework site, you have your own process. If I was visiting the same site and encountered a state that crashed my process your process would be unaffected. The "exception" would only affect me until you ran into the same state that caused the crashed.

If I reported the crash to the developer, the developer could fix the bug and soft start the entire application without affecting your process. This isn't possible because of the language per se but really because of the entire Erlang ecosystem around fault tolerance.

*edited for more stuff

Crazy New Ideas 5 years ago

It's funny how this context changes the entire the article. I didn't realize that this was related to Mighty and thought it was a good "call to arms" for domain experts in non-tech industries to disrupt their markets.

The problem that I have with Tailwind is that it's not that different than using inlined styles but adds a lot of bloat without a path to clean abstractions.

I'm confused. What is it that Nvidia can do by owning ARM that it can't do by just licensing the architecture? Can't they just license and build all the chips people think they'll build without buying the whole thing?

A couple thoughts after using it for a couple years.

1. It actually takes a while to get your head around the fact that the biggest advantage of elixir is having access to the battle tested features in OTP. It takes longer to realize that these benefits don't come for free and elixir might not be the best solution to your problem.

2. The learning curve for writing functional code is different for different people. As a result, it's impossible to figure out before hand how long it will take a team used to writing pythonic code, for example, to start writing functional, elixir code.

3. You're able to emulate something like type checking between pattern matching and ecto schemas but it's not type checking. Be prepared to spend time coming up with best practices for writing tests.

I don't think the microservice vs monolith process is as cut and dry as people make it out to be. Microservices are hard because abstractions are hard. I've found working on abstracting code within a monolith usually results in better microservices. Haven't seen a good process for starting a project with a series of microservices.

Startup Pivots 7 years ago

There's survivorship bias here. Where's the list of companies that pivoted to oblivion?

This article just makes matters worse. Saying nothing would have been better. Not selling would have been the best.

This seriously falls in the "I didn't know you could do that category" for me.

No at the start of a project. Yes for refactoring.

I used to write tests for all pure functions because they were the easiest tests to set up. They are also the easiest to debug so the test didn't really help unless you're checking for type signatures.

I think that implementation tests are important but I found that I suck at figuring our how to set up a test before the actual implementation. So I do them after the fact and judiciously.