Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
asa400
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
17 ms
·
241.
▲
by
asa400
2y ago
I don’t do much Clojure anymore (I wish I did!) but agreed on all points. The JVM interop is such a huge, huge advantage that it’s hard to express to people who aren’t used it.
242.
▲
by
asa400
2y ago
Correct, `use` is a part of Elixir. When you `use` a module like `use FooModule`, it runs the `__using__` macro defined in `FooModule`. Because `__using__` is a macro, it serves as an extension point that allows modules that define it to &q
243.
▲
by
asa400
2y ago
Years ago, this was almost exactly my experience at my first software job, a large Rails monolith in the Ruby-on-Rails heyday. Obviously I was inexperienced, but aside from that, the application code itself was so hard to understand that
244.
▲
by
asa400
2y ago
Depends on you, your team, your target hardware/os, your project, and many other factors. Considering all of those things, the hurdle of installation might just be too large for it to be worth it.
245.
▲
by
asa400
2y ago
Elixir also has inline dependencies in scripts, via `Mix.install`: https://hexdocs.pm/mix/1.17.1/Mix.html#install/2 . I've used it quite a bit, it works great.
246.
▲
by
asa400
2y ago
> I sometimes wonder why we don't see ruby used for shell stuff more often. The reason we don't see Ruby used more for shell stuff is because Python won this particular war. It's already installed on basically every Linux
247.
▲
by
asa400
2y ago
Pretty sure I’ve made exactly the same mistake. I feel like everyone who ever writes concurrent code learns that lesson at some point. It’s absolutely astonishing how much mileage one can get out of thread-per-core-fed-by-work-queues archit
248.
▲
by
asa400
2y ago
The source code for Task is very readable but also kind of subtle, and makes for a good study. I would say definitely give it a shot to trace the flow from Task.async[0] to Task.await[1] to Task.Supervised.start_link[2] to Task.Supervised.r
249.
▲
by
asa400
2y ago
This is the shortest, clearest explanation I've yet seen of object safety. Thanks.
250.
▲
by
asa400
2y ago
I can’t second this enough. I never knew him personally but hung out around him at a few Erlang conferences and he was always incredibly kind and giving. He never knew it but he had a huge impact on me as an engineer.
251.
▲
by
asa400
2y ago
Briefly, the tradeoff that Erlang and its independent process heaps model make is that garbage collection (and execution in general) occurs per-process. In practical terms, this means you have lots of little garbage collections and much few
252.
▲
by
asa400
2y ago
Indeed it is: https://zeroclarkthirty.com/2024-04-21-benchmarking-erlangs-...
253.
▲
by
asa400
2y ago
To be fair, it was already on fire, you just didn't know it yet!
254.
▲
by
asa400
2y ago
Is there anything I can read about what capabilities Datomic requires of the underlying storages it uses?
255.
▲
by
asa400
2y ago
If you're feeling any less interested, I hope you reconsider and still give it a shot. There are issues, but there are issues with every technology. I promise you'll learn something.
256.
▲
by
asa400
2y ago
> My impression is that it's difficult to learn about these topics without real hands-on experience (something that seems hard to replicate in small/solo projects). Maybe. Unfortunately, I don't think there's a cheat
257.
▲
by
asa400
2y ago
As someone who was Elixir hire #1 at a company that eventually ended up with ~25 Elixir developers with a novel product that people actually used, I see people in this thread and elsewhere mentioning the unorthodox nature of the language or
258.
▲
by
asa400
2y ago
The greatest trick the devil ever pulled was convincing people that Clojure is not a practical, get-shit-done language. For obvious reasons (syntax) Clojure gets lumped in with the other lisps but Clojure is really intensely practical. It m
259.
▲
by
asa400
2y ago
I don't know. I'm sure there is a design reason for it, but I haven't been able to find it in any of the public discussion.
260.
▲
by
asa400
2y ago
There are more benchmarks and quite a bit more detail here: https://github.com/erlang/otp/pull/8111
261.
▲
by
asa400
2y ago
This is not mentioned in the article, but since it has performance implications for a ton of BEAM applications, it's probably relevant: OTP 27 will also include a new builtin JSON module, and I did a quick and dirty benchmark [1] of it
262.
▲
by
asa400
2y ago
This is not mentioned in the article, but since it has performance implications for a ton of BEAM applications, it's probably relevant: OTP 27 will also include a new builtin JSON module, and I did a quick and dirty benchmark [1] of it
263.
▲
by
asa400
3y ago
It's a truism to say healthy people are healthier than unhealthy people. Of course they are. The point isn't that healthy people can work more than unhealthy people, it's that all people - even healthy people, even young peop
264.
▲
by
asa400
3y ago
A bunch of people think they're good at working 12 hour shifts. Almost none of them are. There is an absolute mountain of fatigue research that bears this out. Truck drivers and pilots are legally prohibited from working more than a ce
265.
▲
by
asa400
3y ago
This is one of the sanest comments I've ever seen describing what FOSS actually is. I think you nailed it when you said: > We can't just say "Oh FOSS is better than much closed software" when things are good, then imm
266.
▲
by
asa400
3y ago
Honestly that's a fair reply, thanks for the additional nuance to your argument. Upvoted.
267.
▲
by
asa400
3y ago
Is this default really that big of a problem? Most people running Tokio are going to be running it on multicore hardware, and they'll get some additional throughput for free. If they're sufficiently resource constrained to the deg
268.
▲
by
asa400
3y ago
Honestly: just ignore them. Just start using Rust! It's a lovely, useful language. HN/reddit are not representative most of the people out there in the real world writing Rust code that solves problems. I am not saying their conce
269.
▲
by
asa400
3y ago
> But as it stands now, async/await may be the biggest current premature optimization in common use. To be fair, isn't the entire point of OP's essay that async/await is useful specifically for reasons that aren'
270.
▲
by
asa400
3y ago
I have to respectfully disagree. People are allowed to like stuff, it doesn't make it a marketing campaign or a conspiracy. This negativity on async, as if it's just a settled debate that async is a failure and therefor Rust is a
More ›