Threads for bluejekyll

  1. 1

    This survey was kind of terrible tbh maybe it would be better if the preparation of it was a FOSS process..

    1. 4

      It’s the same survey as last year, so there was a whole year to complain about it.

      The process is open, you just need to volunteer (I did last year). It’s not done through GitHub, but let’s not make presence on Microsoft’s service the bar for things being open.

      1. 3

        What do you think was terrible about it?

        1. 2

          Maybe it is good idk.. from my pov it didn’t look like the structure of the questions/answers would be able to identity certain types of respondents or give good insight into what they want to know.

          But I think I was also just being negative to vent, normally I wouldn’t have said anything.

        2. 3

          The prep of the survey is done by a working group that’s open to join (the community team), but for reasons of speed and management, the final prep of the survey is done in a chat on the platform in use.

          It is essentially the same survey we used for the last years, because this also gives the ability to compare - also, it’s easier on the translators, as it is multilingual effort.

          We’d be interested in actionable and direct feedback, e.g. what was missing and what not. Surveying programming languages has only become popular in the last 5 years (about since we run the survey ;)), so feedback and people with skills to create them are few and far between.

        1. 2

          I don’t know why but I have that weird fascination for the DNS protocol (the same for GeoTIFF and cloud-ready GeoTIFF files format for example). It is a good write up about it and an easy implementation to follow in Rust. Being not exposed that much to binary file format and how compact some can be besides the fact it is a hidden core part of the stack of the Internet push to discover more about it. It is a big rabbit hole especially the last few years where different vectors of attack were developed around that spec and the evolution of the domain from “Clound DNS”/CDN space, attacks like DNS spoofing, DNSSEC/DNSCurve, and so on.

          I simply found it fascinating how DNS (and BGP) layers works and attacks are crafted against those. Who knows why.

          1. 3

            If you are really interested in this place, we’re always looking for new contributors in the trust-dns project:

            We have a pretty good start here I think.

          1. 28

            Have done this, can confirm it works. If you have trouble with the political side of things, introduce the strangler as a diagnostic tool or a happy path and start shipping new features under its guise instead of under the legacy system. Arguing for two concurrent system with initially disjoint usecases is easier than a stop-the-world cutover.

            1. 3

              Strongly seconding. I’ve seen countless person-hours wasted on trying to replace legacy systems wholesale. IT systems are like cities: They grow organically and need to change organically if you want to avoid displacing whole swaths of the population and causing more harm than good.

              1. 1

                How do you handle downstream consumers of functionality as you strangle the original piece of code? Can’t always force everyone to move to a new API route or use a new class in a library.

                1. 8

                  The best case is not to force them to change anything. In my case, we did exactly as the article mentioned, and slowly transitioned to a transparent proxy. Then slowly we turned on features where API requests were handled by the new code, rather than being proxied to the old code.

                  1. 4

                    It’s obviously harder if your API has multiple consumers (some of which you don’t control). One option is to have the proxy expose the same endpoints as the legacy system, though that’s not without its own complications (especially if the technologies are particularly divergent).

                    1. 3

                      That’s a political problem, not a technical one. You solve it by building political power in the organisation.

                      1. 2

                        Only if the consumers of your API are within your organisation…..

                        1. 3

                          For this you need separate gateway service that hosts the API and then forwards to either the new service or the legacy service. It’s also generally appropriate to use the legacy service as the api gateway, and abstract the route through that to the new external service.

                          Be mindful of added latencies for remote systems.

                          1. 2

                            If people are paying you for a working API, I’d struggle to imagine a viable business case for rebuilding it differently and asking customers to change.

                            1. 3

                              It happens all the time. That’s one of the reasons that REST APIs are generally versioned.

                              1. 1

                                That still doesn’t solve the problem. The customers still need to transition to the newer version.

                                1. 3

                                  I think our wires are crossed. I was using multiple versions of REST APIs as a counterpoint to the idea that there’s no “viable business case for rebuilding it differently and asking customers to change.”

                                  That change may even be driven by customers asking for a more consistent/functional API.

                        2. 3

                          I’ve normally handled this my making all consumers use a service discovery system to find the initial endpoint, and then using that system to shift traffic “transparently” from the old system to the new one.

                          This is admittedly a lot easier if your consumers are already using service discovery, otherwise you still have a transition to force. But at least it becomes a one-time cost rather than every migration.

                      1. 6

                        Big fan of the relaxed orphan rule. That has gotten in my way many times. I’m now going to excise some newtypes from our codebase. And, if I’m not mistaken, the C ABI change will allow a lot of unsafe transmutes in FFI to be avoided, right?

                        Congrats and thanks to everyone involved!

                        1. 5

                          Agreed, the strict orphan rules were something I also encounter frequently, this makes it possible to do the ‘correct’ thing, avoiding newtype wrappers.

                          I also like that they redesigned the lock file format to avoid conflicts. A practical change that really makes everyone’s love’s easy.

                          Rust now really seems to be in a phase of very gradual refinements to reduce/remove papercuts. I love it!

                          1. 1


                            They just released async await, a huge new language feature!

                          2. 1

                            It was and remains incorrect to transmute between Box<T> and *mut T. This just avoids having to use Box::from_raw() and Box::into_raw() at the FFI boundary.

                            1. 1

                              On the FFI front, yeah it looks like we doing need to do the basic dance of immediately wrapping C pointers. It looks like the guidance here is to only do it on Rust functions exposed to C and not the other way around.

                              I’m sure there are a whole bunch of caveats, but I’m thinking if the memory is owned by rust and passed to C and then passed back into Rust, we don’t have any concerns around alignment and other initialization issues. If the memory is allocated by C, don’t use this technique.

                            1. -10

                              Money quote:

                              Why are you leaving? Little bored. Not learning as much as I used to. I’ve been doing the same thing too long and need a change. […] I want to build something new again. I don’t want to get stuck in a comfortable rut.

                              I hope the author, who has so far worked on Go at Google, reignites his learning through something relatively more sophisticated like Rust or Haskell.

                              1. 61

                                This is an incredibly patronizing thing to say.

                                1. 27

                                  Agreed, I usually downvote and ignore such comments, but I can’t help but point this out in light of the recent “Lobsters Is Better than Hacker News thread” [1] (which I also found to be “low effort”)

                                  The comments on this same article on HN are significantly more enjoyable and positive to read than this thread:


                                  It reminds me of the “low effort” framing here regarding open source participation.


                                  Leaving aside the fact that the comment is patronizing (and IMO should just be deleted), it just has so little effort behind it that it contributes nothing.

                                  I try to ignore the many low effort / tribal comments on, but sometimes the noise overwhelms the signal. I think the relatively aggressive HN moderators have done a good job. I understand why people dislike the site, but that’s because it’s big and the bad stuff jumps out at you.


                                  Anyway I write this in hopes that people will put some more effort into their comments. I didn’t submit my last 7 blog posts here and it wasn’t a loss. One post was submitted to HN yesterday and that was plenty of feedback – at least 80% of it not “low effort”.



                                  1. -1

                                    I didn’t submit my last 7 blog posts here

                                    With all due respect, personally I havent missed it. I admire what youre trying to do with the Oil project, but its not of personal interest to me and I havent found a way to filter it out. To be candid it feels as if you use Lobster as a advertising platform sometimes. I think it would be better if you posted more non-Oil topics. Looks like 12 of last 15 were Oil Shell:


                                    Good luck to you.

                                    1. 37

                                      I hate advertising as much as the next guy, but this is very unfair to Andy. For one, the pieces aren’t just about Oil shell. Most of them are about topics inspired by Oil shell, things like motivations, facets of the system, different techniques used to implement it. He’s also written tons of comments on other people’s submissions. He’s a good-faith member of the community.

                                      1. 13

                                        I agree he definitely interacts more than simple link dumping and while Oil isn’t interesting to me, so are a lot of other technologies that I can’t filter out. I think he should be welcome to share his links so long as they contain new information and not a repetition of existing information. For example I probably would be interested in how he stays so productive and how he manages tasks, and how he decides what to work on next. I hate to admit it but I’m probably more likely to click it if a product name isn’t in the title ;).

                                      2. 18

                                        Disagree strongly. @andyc’s blog posts are exactly the kind of content that should be submitted to lobsters. Please don’t stop Andy!

                                        1. 13

                                          Strongly disagree. If @andyc content is not for lobsters, what is? Each of the posts is technically sound, and I learned many things from them, even tho I’m not interested in Oil per se.

                                    2. 19

                                      Interestingly, a sentence immediately below, which however didn’t make its way into above “money” quote, is:

                                      It’d be nice to primarily work in Go rather than work on Go.

                                      1. 19

                                        How good of a programmer does one have to be before they can reject Haskell or Rust have it reflect something other than their own ignorance?

                                        1. 4

                                          Sorry, I don’t understand your question/statement. Could you please rephrase it, English is not my mother tongue. I’m not sure if you ask about the skill level one has to have to be able to reject Haskell or Rust on a non-ignorance base without prejudice of other developers, or something completely different?

                                          1. 5

                                            Some fervent proponents of programming languages will imply that programmers that like or use other languages simply do not understand the unique benefits they convey. Paul Graham wrote a whole article that may be the root of some of this thinking.

                                            Rust and Haskell stereotypically attract these followers more than many languages. But other languages are not immune to this criticism; I’m a Lisp weenie and as we all know, Lisp is still #1 for key algorithmic techniques such as recursion and condescension.

                                            I read cgag’s comment (and upvoted it) as a tongue in cheek joke: a fervent follower of language X will always consider a criticism of X or a desire to not use X as a position rooted in ignorance of X’s capabilities.

                                            1. 3

                                              Some fervent proponents of programming languages will imply that programmers that like or use other languages simply do not understand the unique benefits they convey. Paul Graham wrote a whole article that may be the root of some of this thinking.

                                              This is true a lot of the time. It’s certainly possible for two people who have both used language X to disagree on whether the style of programming that language X facilitates or encourages is good; but a lot of the time a person who likes language X is making the case that language X is good to programmers who haven’t used it and don’t care to (which is fair enough - it takes a decent amount of time and effort to learn a novel programming language well enough to have an informed opinion about it, and it’s reasonable to decide that you don’t care about forming an informed opinion about a language and doing something else with your time instead).

                                              1. 1

                                                Oh, I think you and pg make a good point: sometimes there really are advantages that you can’t see when you look up from blub to language X, and the only real way to get it is to learn X. But I think it’s important to think about looking down the ladder too.

                                                When I’m in X slinging macros to build a DSL that makes my life easier, I’m making a decision that forces the next programmer to look at my code to deeply understand my DSL and all the decisions therein. What multiplies my productivity might quarter theirs.

                                                Sometimes you look down and the forced simplicity of blub looks OK :)

                                        2. 8

                                          I spent a little bit of time on both Rust and Go and I learned a lot more with Go. Rust is pretty standard and sane, calling into libc, using LLVM. Go goes wild and does its own thing everywhere, it even does its own linking. It’s a lot of fun.

                                          1. 4

                                            I believe I understand what you meant, Go has a goal of simplicity, Rust and Haskell are more feature rich. Working on the Go compiler as a result can feel like polishing the same thing over and over, spending tremendous effort to make small improvements. The way you phrased it though appears as though you think Rust and Haskell are “smarter” or “superior” in some way. Implying some language is “smarter” or “more sophisticated” is a good way to make everyone hate that language.

                                            1. 6

                                              Implying some language is “smarter” or “more sophisticated” is a good way to make everyone hate that language.

                                              I would only ask that while some fans of other languages can become overly zealous that we try to not anthropomorphize the language itself by applying a label of hate to it. I think we can all agree that the GP comment is of poor quality.

                                              1. 3

                                                I can see that. I doubt anyone truly “hates” a language any more than they hate broccoli or brie. I love broccoli and I love brie, but I have heard some people hold strong negative opinions before.

                                              2. 1

                                                I think he just means Go isn’t that great of a language. I don’t really blame him for having that opinion. Go reminds me a lot of Java, it got adopted because a giant tech company “sponsored” it

                                                I mean just replace “Go isn’t that good” with “C++ isn’t that good” or “Java isn’t that good” and it suddenly becomes way less controversial.

                                                1. 4

                                                  i first played with go before it was 1.0, and immediately liked it because it got so many things right, even back then. easy compilation, easy definition of packages without additional magic files, binaries that can just be copied. it’s just optimized for sanity if you want.

                                                  so, imho: it got adopted because smart, experienced people got as much time as they wanted to carefully build something.

                                                  1. 2

                                                    Yea from what I’ve heard/experienced, the Go tooling is incredible (just like the Java tooling was incredible). I think what people have a problem with is Go the language.

                                                    Full disclosure though, I’ve never used the language in any serious capacity (other than adding a 5-line patch to the backend code at work here and there) so I don’t have much to say. I have an irrational distaste for the language that I can’t put my finger on. I’m not sure if it’s the weird syntax or what. Tooling seems great though. I’ve been meaning to install 9front on one of my computers.

                                                    1. 1

                                                      most, if not all of the weird choices were made deliberately, the faq explains some of them. imho these things make the language great. for example, the “backward” declarations really feel natural for me, compared to c style declarations.

                                                      the rest of the language is really boring, but the single features really work well together. that’s what makes it great. maybe it’s like watching a anthony bourdain episode where someone cooks a great meal in a single wok over a wood fire outside. it’s about how the tools are used, not how complicated the tools are :)

                                                      1. 1

                                                        Hm maybe I should check it out then. I really like Lua and C for the same reasons you like Go