Skinney

10 ms·

121.
by Skinney 4y ago
> Erlang, on the other hand, offers me much that Elixir does not. Genuinly curious. Like what?
122.
by Skinney 4y ago
> better at your job than you are What you mean is «better at negotiating than you are». Work skill an negotiation skills don’t always coincide (in my experience they almost never do).
123.
by Skinney 4y ago
most of our thread pools are long lived, so we don't ever shut them down. When the pool is not long lived, we have a try-with-resources wrapper which handles the shutdown. Most of the time, we do calls to .execute and then join the dif
124.
by Skinney 4y ago
> think you have a wrong concept of what kotlin co-routines are and are assuming limitations that it simply does not have. What I’m referring to is this: > you just use your connection pool as usual and use a threadpool based corouti
125.
by Skinney 4y ago
> You probably should be using something a bit higher level. While there's nothing wrong in using something higher level, the main reason for using higher level libraries are because using threads doesn't scale past a certain p
126.
by Skinney 4y ago
I believe so, yes.
127.
by Skinney 4y ago
Exactly. But the thing is, I can switch GC implementation according to my needs. If throughput is my number 1 concern I can use ParalellGC, if not I can use ZGC. Or G1 if I want something in between (not sure if the paper picks up the huge
128.
by Skinney 4y ago
Java’s ZGC has a constant (O(1)) sub-milliaecond pause-time. GC runs concurrently with the app
129.
by Skinney 5y ago
for simgle users (hobby projects) that's not a concern. For teams, you'd go through a hosted server anyway.
130.
by Skinney 5y ago
what self-hosted, offline available, system do you use for bug tracking, wiki and forums?
131.
by Skinney 5y ago
I believe you can call functions through a table, which makes it trivial to switch out functions at runtime.
132.
by Skinney 5y ago
I don't really see why Nova should attempt to be compatible with another editor just because they landed on JS as the integration language. It's doubtful that VS Code has the best API, and it's doubtful that VS Code's AP
133.
by Skinney 5y ago
You need to login with your BankID (national auth provider) which is bound to your personal id number, and which is illegal to use for machine access, so no.
134.
by Skinney 5y ago
In Norway, this is normally asked during the interview. If the employeer would look up your tax returns, you’d be notified of it and, at least for me, it would be such a huge red flag that I would almost unconditionally decline an offer.
135.
Improving the Performance of Elm-CSS(medium.com)
4 points by Skinney 5y ago|0 comments
136.
by Skinney 5y ago
Yes, but lazy adds to that work. So for views that will pretty much always need to be re-rendered (because the only changes are at the bottom of the view hierarchy) then wrapping them in lazy will only slow down the dom recalculation.
137.
by Skinney 5y ago
It’s a shallow comparison, not deep. But yes, there is both computational and memory overhead when using Html.Lazy
138.
by Skinney 5y ago
Author here. It’s both. Html.Styled is converted to regular Html when run, meaning it uses «normal» Html.Lazy under the hood.
139.
by Skinney 5y ago
This article is a part of a larger series that tries to figure out how Elm's runtime performance can be improved: https://blogg.bekk.no/successes-and-failures-in-optimizing-e... I'm the author of the articles, btw
140.
by Skinney 5y ago
The Java code being called, or calling, the Kotlin coroutine code also needs to be async in order to reap all the benefits. A Java codebase doing a lot of blocking calls can't just call some random Kotlin coroutine code and expect bene
141.
Successes, and failures, in optimizing Elm's runtime performance(blogg.bekk.no)
2 points by Skinney 5y ago|0 comments
142.
by Skinney 5y ago
Yes. The original green thread implementation was M:1.
143.
by Skinney 5y ago
If you need multi-platform then coroutines is still your best bet. But many people don't use Kotlin in a multi-platform way, and lightweight threads will be an easier migration path (and more compatible with Java libraries if you cant
144.
by Skinney 5y ago
I didn't mention calling Java from Kotlin. Kotlin can call a Java API to spawn a lightweight thread. There's no reason to use coroutines when you can do that.
145.
by Skinney 5y ago
> I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. Switching to virtual threads will, at least in the microservices I work with, involve changing a few lines (Executors.newUncachedThreadPool() -> Ex
146.
by Skinney 5y ago
Project Loom will include structured concurrency. But most of that will come out in releases after virtual threads. If you read the JEP though, you'll see that Executors are auto-closable now, which means you can use try-with-resources
147.
by Skinney 5y ago
I actually think it will greatly provide a lot of oxygen to other languages. Virtual threads, project lilliput and valhalla is likely to be a great benefit for Clojure, which has great thread primitives and also spawn a _lot_ of objects tha
148.
by Skinney 5y ago
If it works, don't fix it. Besides, this hasn't been targeted to a release yet, so it might not come before Java 19, which is a year from now. Even then, it will still be a preview, which likely means another year before it's
149.
by Skinney 5y ago
Javalin is _very_ lightweight, and starts up fast. Use the framework that best suits your requirements. Also, Java is working on reducing ram usage: https://openjdk.java.net/projects/lilliput/
150.
by Skinney 5y ago
Kotlin can call regular Java APIs, though. Doesn't have to take the coroutine route.

More ›