Threads for osener

  1. 11

    I wrote this some years ago to scratch my own itch:

    It has been invaluable. I have used it hundreds of time to fetch information from websites and html documents.

    1. 7

      I can’t count how many times I’ve done it using BeautifulSoup in a python REPL. I never bothered to generalize it and wrap it in a command line interface, though. Great idea.

      1. 2

        I made one of these before as well: It has some extra bells and whistles such as scripting, screenshots and optional browser backend (unfortunately puppeteer didn’t exist at the time).

        This sort of thing is pretty useful for statusbars such as i3bar, polybar or xmobar

      1. 13

        This is a very welcome development. We have been using Reason, native OCaml, and BuckleScript in production for at least three years and ReScript transition has been a big worry for us.

        OCaml 4.12

        BuckleScript’s (an OCaml compiler fork) transition from 4.02 to 4.06 took a long time. Using ancient versions of OCaml meant that tooling and library support suffered. It seems like ReScript might not follow new OCaml releases anymore so it is great news that we get to receive updates to the compiler when targeting JavaScript (our main use case, and we prefer this over js_of_ocaml)

        New Reason versions

        ReScript is stuck on an old Reason version and will no longer update its refmt binary. We were working around this by using reason-repacked but support for this is getting removed next release and we won’t be able to upgrade to new compiler releases as we use new Reason features. This has been an overall trend over the years for us. Tooling and features we rely on slowly rot or get removed, and eventually, workarounds stop working.

        Dune and Esy support

        Building native Reason apps, I got to use these awesome tools and BuckleScript way of managing your builds and dependencies felt primitive over the years. It is great to see the promise of reconciliation with advancements in OCaml ecosystem.

        This will also allow us to keep using existing libraries, do code sharing and continue taking advantage of PPX’es to extend the language.

        Merlin and ocamllsp support

        Merlin with Emacs has been my dream development environment for the longest time. I used to be able to use Merlin with BuckleScript, but that was a big hassle and got worse over the years, eventually stopped working altogether. There is no Emacs support for ReScript (or OCaml/Reason with BuckleScript) anymore. I grudgingly switched to VSCode and unstable reason-language-server. New rescript-language-server which is a bit better but it has fewer features and less stable than ocamllsp, plus it has no Reason or OCaml syntax support. I made a Pull Request adding Reason syntax, which was rejected (wasn’t even that big of a change, but didn’t fit the vision).

        I’m excited for Merlin and (upcoming) ocamllsp support as I’ll be able to have the same great development experience I have with native Reason (and used to have with BuckleScript).

        Community-led development and the future

        I advocated Reason and BuckleScript, onboarded teams, and shipped software with it over three years and multiple companies, and now I’m working full-time with them. It goes to say that I repeatedly felt unwelcome when I tried to contribute code or feedback to BuckleScript, and ended up having to be a silent (and happy) user of it.

        I’m excited to have an alternative path of refuge that is actively maintained and that I can contribute to and keep using. I think this is the best outcome for both projects, this way new and old users who want ReScript to be something else than it is now will have a happy and safe environment to exist while ReScript language can follow the new vision without being held back by users dissatisfied by the transition it is going through.

        Just like js_of_ocaml and BuckleScript at the beginning, projects should be able to have different goals and co-exist. I’m sure ReScript will have success following its path to be a not-so-FP-focused alternative to JS and TypeScript with a stronger type system. I don’t know what name and shape this fork will take in the future, but just like the successful BuckleScript fork of OCaml I hope it can create a healthy and sustainable community that can stand on its own.

        It is slightly worrying that there are now threats from ReScript side about switching to a non-free license to prevent this fork from receiving updates, this is not in the spirit of open source and a bit weird since ReScript is itself a fork of OCaml. But these things were said on Twitter and Discord in the heat of the moment, and I’m sure we’ll have a healthy discourse soon and things will settle down. I wish anmonteiro the best of luck. This project has my support and I will do my best to contribute to it moving forward.

        1. 2

          I really hope the hostile closing of the rescript source does not happen! I’m a huge ocaml fan, but I was planning on exploring rescript too because I’m excited by their philosophy of “give up on some ocaml compatibility because we want to focus our efforts on making the generated code as close to optimal handwritten javascript as possible”, where “optimal” also covers things like code size and readability.

          if they don’t want to play nice with others I won’t waste my time, but ideally both rescript and this bucklescript fork will succeed and help grow the ocaml-in-the-browser pie, rather than fighting over slices of the existing one.

          1. 2

            I’m sure ReScript will have success following its path to be a not-so-FP-focused alternative to JS and TypeScript with a stronger type system

            From what you are saying it looks like, if I want a FP language, I’d be better off staying with BuckleScript, F#, PureScript or GHCJS … and avoid languages like Elm and what ReScript is becoming.

          1. 13

            the basic argument of the article is this:

            • in javascript, if you have an async function, you cannot call it from a sync-function and get it’s return-value in a sync way.
            • in rust this is not true, you can achieve this.
            • therefore, rust does not have the coloring-problem.

            this might be true, but the more fundamental problem is still there: you should not mix&match sync and async functions too much, otherwise bad things can happen (even the article mentions this). so i think the coloring problem is still there.

            this is not something any language (that has both sync and async functions) can escape from i think. for example, async-functions assume they never block (for a long time). so every time you call a sync-function from an async-function, you have to know that it will return shortly.

            1. 4

              This argument doesn’t even hold up against JavaScript when using Node.js. Although it is a hack and not at all recommended for production use, on Node.js you can use something like deasync to block on promises and other things.

            1. 1

              I did the same and landed on Hetzner Cloud + NixOS. I’m pretty happy with it!

              I use krops to manage it. Here is a simple script for initial setup.

              1. 1

                Have you tried Morph and NixOps? I’m currently planning on switching to Nix flakes for my systems, and am wondering what deployment tool will work best.

              1. 2

                Nice article!

                Google does not provide a Linux client for Google Drive. For me it is enough to use the web version. But there are some promising (paid) 3rd-party clients.

                Maybe Rclone can help.

                1. 2

                  After i install it, I usually never hear a beep from Insync. It just works. I see that they alsosync OneDrive now, but I have no need for it.

                1. 1

                  I’ve had 3 Noppoo Choc, 2 Mid and 1 Mini, and a Mid has been my daily driver at work, the one I am currently using for the last 7 years. It’s the best mechanical keyboard I have ever owned, but my experience is not that vast. I might buy my coworker’s Ducky One, because it has a numpad and he wants to get something else anyway, but maybe I’m not enough of an keyboard aficionado to care that much - I prefer MX black but would like to try out reds for a prolonged time. That’s the important thing for me, blue is completely out and browns are ok for gaming.

                  This list is still up to date: but I backed and am waiting for the summr now.

                  1. 1

                    Haha nice, if I had a new backup keyboard I’d send you my Choc Pro for you to add to your collection.

                    1. 1

                      I have 2 noppoo choc’s (one brown and one blue), and while I absolutely love the layout, both have been acting up lately, with double (or triple) key activations. Blowing into the depressed switches with compressed air helps for a while, but then the glitching returns. ‘E’, ‘R’, ‘T’ and the space bar are the worst offenders.

                      There seems to be an absolute death of compact mechanical keyboards with a short space bar (space bar should extend from beneath the ‘C’ key and end flush with the ‘M’ key). I would love a mechanical keyboard with the same layout as a thinkpad or dell xps: short spacebar and all F keys easily accessible without mode switches.

                    1. 6

                      Topre Realforce 87U Variable Weight. My Cherry Blue keyboard is collecting dust since the last 6-7 years I got this one, Topre switches and variable weight keys (keys you press with weaker fingers are lighter) are amazing.

                      Pretty much meant that my MK hobby was over quickly and saved me a ton of money, since none of those cool and exciting keyboards coming out use Topre switches :).

                      1. 2

                        This looks really good to me. I used a IBM Model M then ended up with a dell generic and I was surprised it was fine. I’m at home back on the ancient M and I’m really interested in variable weight.

                      1. 1

                        This time around I wanted an alternative to a multi screen setup, and went for a 43” (!) monitor:

                        It doubles as a decent TV, and indeed it has a tiny remote, but it’s actually an awesome monitor. Once I got used to it, and dusted off my old XMonad setup, I’m totally sold and liking it more than multi monitor setups!

                        This thing has a ton of inputs too, and cool ways to display them at once. Using a 60fps 4k HDMI for playstation, and Display Port over USB-C for my laptop.

                        1. 2

                          Started playing around with Revery and libgit2, building something that will maybe become a native git client that’s sort of Magit-like:

                          Also considering picking up an almost-abandoned project again, that enhances Github with better code reading and review experience using language servers:

                          1. 3

                            I started using React about a month ago, and was expecting to hate it. I have an instinctive distrust for frameworks, but I have also heard a lot of whining and moaning about how complicated it is. Much to my surprise, everything just… worked? The declarative, functional style translated pretty much directly into a DOM with few surprises. Handling mutable state with useState() declarations mostly just worked, and was a far cry simpler than $watcher in Angular. I had to read a few doc pages for things like contexts and routes, but everything went surprisingly smoothly.

                            At this point, React seems pretty great as far as I can tell. Am I just naive and the real pain is yet to come?

                            1. 4

                              I really like React as well and have been using it since 2013. It has essentially stayed the same since then, with the paradigm it championed influencing the UI libraries of big players like Apple and Google as well. It has a clear API surface, and does one thing very well. The biggest recent improvement was Hooks, and it changed the game for me and many other people too. The team is also continuing to come up with novel solutions to some pretty hard problems that have been historically unaddressed by JS libraries, such as Concurrent Mode. Not that everyone has these problems of course.

                              It is one of the most mentioned keywords in job postings, and it’s here to stay. Your investment in it will certainly not be wasted.

                              With that said, I’ll play the devil’s advocate and try to answer your question:

                              It is not a framework. When viewed from the eyes of a novice, or someone who bootstraps a lot of projects, or onboards a lot of new developers, the lack of conventions are quite tough. Every React codebase I’ve seen are wildly different, from state management to styling to code conventions to project structure to… you name it. In the end, for a frontend library to not even have a good solution for things like styling and routing is pretty out there.

                              This didn’t stop it from getting to where it is of course, and more complete things like Angular, Vue etc have been suffering from backwards-compatibility issues in this fast moving platform, language and ecosystem. I read a quote by Vue’s author in which he said that (paraphrased) he likes Svelte’s approach, he would’ve liked to adopt some of it if not for backwards compatibility. And just a few moments ago Vue was the new hotness.

                              When I bootstrap my own projects, I love it. I get to engineer my application just the way I want for the problem at hand. Usually choosing ReasonReact. But every time I join a new team using React, I have to learn everything from scratch, and a lot of your knowledge, war stories, preferences don’t transfer. Right now “we use React” tells me just as much as “we use Lodash” about a company’s engineering culture, programming paradigm etc.

                              It’s also very easy to get overwhelmed with the sheer amount of choices you have to make, usually in a group of people with different opinions and experience, from the start and at every step of scaling your app and your team.

                              1. 2

                                So what you’re saying is: Hell is other engineers. Guess I have our lead web guy to thank for how easy it was get to started with our React app.

                                1. 2

                                  Just that when it gets bad it can get very bad, and there’s nothing in JS and its ecosystem that stop you from building projects that drown in tech debt, horrible performance, and completely go against React’s programming paradigm. You basically have to learn everything the hard way, or have awesome people in your team. For some the answer is more hand-holding and out-of-box featureful frameworks. For me it was using functional and immutable-by-default languages to use it at its best, and skip all the bad parts of JS.

                                  1. 2

                                    Just wanted to second @osener. I’ve been using React since 2015 across 3 companies and it felt quite different at each. Routing was different, state management was different, etc. Given all that, React is still my number 2 choice for web apps.

                            1. 1

                              Svelte and Vue look cool, but I have no appetite for fancy JS frameworks anymore. React, and other libraries on different platforms using the same model of building UIs, stood the test of time for me. I’ve used React in production with apps written in Reason, Clojure, PureScript and TypeScript, and was always free to design and build my applications however I want.

                              I guess it’s the same tradeoffs that are in play when deciding for or against Rails. Made worse because of a fast moving platform, language and ecosystem though.

                              1. 2

                                I have no appetite for fancy JS frameworks anymore. React, and other libraries on different platforms using the same model of building UIs, stood the test of time for me.

                                The fact that React doesn’t count as a “fancy JS framework” to some people is kinda boggling to me.

                                1. 2

                                  Well, React is 6 years old and working with the library is pretty “boring” compared to the major JS web frameworks that have come since.

                              1. 4

                                This is very cool!

                                The Dhall Kubernetes package specifies record types for every object available by default in Kubernetes.

                                I glanced at Dhall & Nix for this purpose, as this could’ve saved me a lot of pain as a casual Kubernetes user. But on the flip-side, I didn’t go through with it after I realized that I did not write 99% of my manifests myself, and instead copy pasted & configured what’s available on Github. The way I use it, I’d need a massive ecosystem around Dhall+k8s with reusable bits around most things you want to deploy on kubernetes.

                                If I find myself doing this full-time in the future, and writing most of my manifests myself (without worrying of catching up with third party software), the safety and abstraction level this provides sounds like a big win.

                                1. 2

                                  I didn’t go through with it after I realized that I did not write 99% of my manifests myself, and instead copy pasted & configured what’s available on Github.

                                  Would it work for you to convert YAML manifests from Github to JSON and importing them through json-to-dall? Haven’t tried that myself yet, but doing something similar with cuelang at the moment. I guess the drawback is that you would probably have to annotate types by yourself?

                                  1. 1

                                    rekube mentioned in this thread sounds even more up my alley actually, as I’m a heavy Reason user. And looking at it’s repo it seems to have such a tool, so it is certainly possible! Maybe it’s a bit easier with rekube because how good OCaml is at inferring types?

                                1. 2

                                  Working on my side project, a minimalistic functional-style web framework for ReasonML/OCaml. Having fun working on hardening it with some security headers. From next week planning to tackle something more difficult–integrating a GraphQL server as a middleware.

                                  1. 1

                                    ReWeb looks great! Looking forward to GraphQL support and trying it out as a replacement for graphql-cohttp!

                                    1. 2

                                      Thank you! It’s on my todo list :-)

                                  1. 3

                                    Haskell: I love how it helped me formalize and structure my understanding of type systems. More than that, I like how much it helped me focus on the structure of data in my programs and how types can be most effectively used by modeling that data. These skills have stuck with me as fundamentals that pervade almost all my thinking ever since then. (I’m not sure how much this was Haskell’s doing vs a right-place-right-time sort of a thing, but it definitely had a strong influence.)

                                    1. 2

                                      I’m not sure how much this was Haskell’s doing vs a right-place-right-time sort of a thing, but it definitely had a strong influence.

                                      I feel the same way, but I’m not sure I’m 100% there, and I find it hard to put it in words when I try to explain it to others. Do you know any resources that cover this topic in depth?

                                      1. 2

                                        Unfortunately, I don’t know of any particular reading material that I could point to. Your link to “Domain Modeling Made Functional” seems plausible. It appears to have the right words and chapter breakdown. But I’ve never heard of that book myself. I’d also be somewhat skeptical that it’s an OO-vs-functional thing, although I can certainly see why it’s convenient to learn this stuff in a functional paradigm.

                                        1. 1

                                          Looks like the author has a talk online with the same name, I’ll check that out before buying the book. Thanks!

                                        2. 1

                                          Can you clarify which topic in particular that you mean?

                                          1. 1

                                            The lessons burntsushi says his Haskell experience taught him.

                                            I have this book on my reading list, I wonder if it’s along the same lines:

                                      1. 5

                                        I’ve been working on Haskell bindings for Thrust. It allows you to create easily deployable desktop apps using embedded Chromium for your user interface (like node-webkit).

                                        It feels like I’m being too eager choosing this for my first Haskell project but thanks to the amazing GHC compiler I was able to keep fixing the type errors and get something working even with my elementary understanding of the language.

                                        I think the API turned out to be not that bad. Here is an example showing how to build a menu: (you can compare it with the go version), and another one using Haste for type-safe client server communication