1. 2

    ssh alone is enough to warrant the title of the blog post.

    1. 4

      except ssh was not invented by openbsd, they have a very popular implementation sure, but let’s keep things honest https://en.wikipedia.org/wiki/Secure_Shell

    1. 2

      OpenBSD are Heros for good. sysupgrade gets better and better.

      1. 1

        We need everything updates forever. That’s hyperbole, but this pattern is clearly needed way more broadly. cars, toasters, houses, software, communities, governments, crop fields …

        1. 1

          Never give in. BSDs are the torch bearer of Unix on servers. Linux is for phones and tablets.

          1. 2

            I used to use perl all of the time. I think it was my first dynamic language that I really leaned into. Then I “grew up” into python.
            Now I like perl again, and think python is too grown up. For big projects I’ll use lisp or golang, but anything up to that is now back in perl.

            1. 6

              I’m glad this was said. And I appreciate the nuance and difficulty separating the band from the music. The art from the artist. I took a deep dive into racket and love it, but the leadership made me uncomfortable. Now I’m putting that energy into common lisp. To be fair I compulsively learn and re-visit languages constantly.

              1. 5

                Early in my “lisp adventure,” I settled on PLT Scheme, and got really turned off by the community. I never did fully retrospect on it, but I am pretty sure “academic elitism” is a fair assessment. As an industry practitioner… From there, I jumped from Scheme to Scheme, to Clojure at one point, etc. I tried to get into Common Lisp, but it never really stuck. I ended up going back to Racket for a while (PLT became Racket), even made a few contributions, spoke at a RacketCon, etc. But somehow, I found myself retreating from the community again, and I don’t know exactly why. I can point at one specific case that frustrated me, around a proposed change I made to json handling that was met with a very negative, dismissive response, but I don’t think, by itself, that was it…

                Anyway, I find myself jumping a bit between schemes again, mostly settling on Chibi, the R7RS reference implementation, with a fairly large and practical standard library, but it’s nowhere near as polished as Racket, because the project is a million times smaller. I wish I had more time to help… :(

                1. 5

                  Have you given CHICKEN a try? It has a lot of useful add-on libraries, good standards support and a welcoming community (at least, we do our best to make it so)

                  1. 1

                    I have! I occasionally end up using Chicken. And, in fact, the last Scheme based play project I did used it, but without embracing any Chickenisms, because I wasn’t sure which implementation I wanted to go with for good. It was a hack week, and I had it installed already. I got a basic demo working and then did nothing more…. which was great in that I didn’t have to make an actual decision…

                    Thanks for your contributions to the Chicken project!

                  2. 3

                    Pull request management in Racket is definitely one of the things I think should be improved. Recently, I have been going through unmerged PRs and try to get them merged if they are in a good state.

                    It looks like the PR that you are talking about is https://github.com/racket/racket/pull/1878?

                    I’m not sure if I would characterize the responses as “very negative, dismissive”. Two people apparently think that this is a good idea (heart emoji react). Many comments politely discussed about what is the best way to implement the feature. The only comment that I think could be perceived as negative is the last one, which says the change should not be included in the standard library (because it’s too opinionated in their opinion), but rather you should make a separate library instead. But in any case the comment itself seems polite and was made in good faith to me.

                    1. 1

                      Yeah, this is the bulk of the json thing I mentioned. I remember it being worse somehow, and wonder if there is additional discussion / events not reflected there, or if I am remembering a feeling and reacting negatively to that.

                      I remember that I definitely started another library that handled json differently, and I am pretty sure I threw my hands up at some point and decided it was not worth doing. This all came up, incidentally, because I was writing some API consuming code and the default json stuff was woefully inadequate for dealing with it. I gave up on that and used a different language (I know this for sure, but am fuzzy on the details). In other words, I was unable to use racket for a practical task I was doing, because the official json handling makes impractical choices because it’s more sound, academically. Something like that. (Again, projecting a feeling here, rooted in opinion, and building off of other feelings)

                      1. 2

                        There is a real risk with this kind of PR to get stuck, if there is no “owner” of the original code. In that case no-one feels entitled to take a decision. It sometimes helps to ping such an issue to bring back some attention to the issue.

                1. 10

                  Browsers are too big to fail. Too big to try and make a new one at this point. I keep my eye on all the new ones for one that might break out like FF did.

                  I don’t see the problems with FF. It works fine for me. It was a few years ago or more where chrome had things that FF didn’t.

                  People are OK with the “not fooling anyone” levels of malicious intent by big corporations, if it means not giving up a modicum of convenience. Choosing FF is a no brainer. I wish there was a choice to not choose amazon or walmart.

                  If chrome writes the rules … Much of the criticism of FF will boil down to “FF is not chrome”. That is a huge problem.

                  1. 5

                    I wish there was a choice to not choose amazon or walmart.

                    I stopped shopping at Wal-Mart in 2009 and Amazon in 2016. (I sometimes still went to Whole Foods or got Woot t-shirts after Amazon bought them, but I’ve since shed both of those too).

                    Newegg, eBay, Reverb … almost everyone with an Amazon store has stores on all the other mega-shopping platforms. Typically you can get the same price or save by going directly to the store instead of using their Amazon portal, like with Adorama, B&H, etc. I’ve written about the new e-commerce landscape before.

                    Even if it cost me an extra $15, I’d rather not give money to Amazon. It’s honestly not difficult at all. I don’t see why people keep buying stuff from Amazon. It’s not a high effort thing to avoid them.

                    1. 3

                      It’s honestly not difficult at all. I don’t see why people keep buying stuff from Amazon. It’s not a high effort thing to avoid them.

                      (I agree with you 100%, I avoid amazon at all costs… but to play devil’s advocate….)

                      I think the big draw to amazon is kinda pointed out by your comment, you have to go to multiple different vendors/sites to collect the things you need. amazon makes it ‘easy’ by providing a single interface/account to folks. no need to use individual online or physical storefronts with vendors. the amazon ‘free shipping’ thing with prime is probably another way they trick people into continuing to use them, it’s a literal embodiment of the sunk cost fallacy.

                    2. 2

                      Too big to try and make a new one at this point.

                      Wrong. Unless you want to compete with Chrome, which is more of a webapp browser than a web browser.

                    1. 5

                      “I also, once upon a time, maintained some ports before getting banned for “conduct issues”’ and “How about you stop with the intimacy like you know me, unless you’re too chicken to tell me who the hell you are.” … This guy is toxic.

                      1. 3

                        “There are many reasons why print debugging is still the best option for many developers. rr, Pernosco and similar tools can’t even be used at all in many contexts.”

                        So no. Print debugging should not go away.

                        1. 4

                          Print debugging should go away whenever better option is available, and we should invest more resource so that better option is available everywhere. It doesn’t seem that controversial.

                          1. 1

                            The article explicitly states that it shouldn’t, just a few sentences later:

                            invested accordingly we could make enormous strides, and not many people would feel the need to resort to print debugging.

                            …so it’s pretty clear that “should go away” means “should become much less popular”, not that it should disappear entirely.

                          1. 2

                            The irony with key/cred management is that it’s inherently a very private thing. I don’t care what blog posts there are about it, the people best at it, don’t publicize it.

                            Like i’m watching what I say right now. I might let an attack vector slip.

                            These are the lessons you have to learn on your own, and viscerally. Akin to how you are better at unix after you “rm -rf *” in the wrong place once.

                            If creds are pushed they must be removed from use, and yesterday. You can’t reliably clean up history. Before things go to prod you must ask how can undo any creds/keys/passwords fast. This leads to questions like “can I stop payment and/or payment sources fast”.

                            In other words in some cases it’s already too late, so what are you second tier mitigation strategies.

                            Being agile/startup etc. does not take away this responsibility. It actually enhances it. You’re the targets. I say that because non tech ppl with the money control might not want to hear about this in early stages. But early stages is where this belongs.

                            (maybe leave some passwords in source control …)

                            1. 6

                              I was so excited to see the conclusion was not what I expected. Idealism tempered with “you have to get there from here”.

                              1. 1

                                I use this on all of my production linux systems. Great to have an alternative to sysystemd.

                                1. 3

                                  I want this, but I’ve been burned too many times buy proprietary newish stuff over the years. I would like to even have just an e-ink monitor on my pc.

                                  1. 2

                                    i use gpg encrypted files in a git repo.

                                    1. 24

                                      It is safe to say that nobody can write memory-safe C, not even famous programmers that use all the tools.

                                      For me, it’s a top highlight. My rule of thumb is that if OpenBSD guys sometimes produce memory corruption bugs or null dereference bugs, then there is very little chance (next to none) than an average programmer will be able to produce a secure/rock solid C code.

                                      1. -1

                                        My rule of thumb is that if OpenBSD guys sometimes produce memory corruption bugs or null dereference bugs, then there is very little chance (next to none) than an average programmer will be able to produce a secure/rock solid C code.

                                        Why do you think “the OpenBSD guys” are so much better than you?

                                        Or if they are better than you, where do you get the idea that there isn’t someone that much better still? And so on?

                                        Or maybe let’s say you actually don’t know anything about programming, why would you trying to convince anyone else of anything coming directly from a place of ignorance? Can your gods truly not speak for themselves?

                                        I think you’re better than you realise, and could be even better than you think is possible, and that those “OpenBSD guys” need to eat and shit just like you.

                                        1. 24

                                          Why do you think “the OpenBSD guys” are so much better than you?

                                          It’s not about who is better than who. It’s more about who has what priorities; OpenBSD guys’ priority is security at the cost of functionality and convenience. Unless this is average Joe’s priority as well, statistically speaking OpenBSD guys will produce more secure code than Joe does, because they focus on it. And Joe just wants to write an application with some features, he doesn’t focus on security that much.

                                          So, since guys that focus on writing safe code sometimes produce exploitable code, then average Joe will certainly do it as well.

                                          If that weren’t true, then it would mean that OpenBSD guys security skill is below average, which I don’t think is true.

                                          1. 5

                                            OpenBSD guys’ priority is security at the cost of functionality

                                            I have heard that claim many times before. However, in reality I purely use OpenBSD for convenience. Having sndio instead of pulse, having no-effort/single command upgrades, not having to mess with wpa_supplicant or network manager, having easy to read firewall rules, having an XFCE desktop that just works (unlike Xubuntu), etc. My trade-off is that for example Steam hasn’t been ported to that platform.

                                            So, since guys that focus on writing safe code sometimes produce exploitable code, then average Joe will certainly do it as well.

                                            To understand you better. Do you think average Joe both will use Rust and create less mistakes? Also, do you think average Joe will make more logic errors with C or with Rust? Do you think average Joe will use Rust to implement curl?

                                            I am not saying that you are wrong - not a C fan, nor against Rust, quite the opposite actually - but wonder what you base your assumptions on.

                                            1. 3

                                              I’d also add that there is deep & widespread misunderstanding of the OpenBSD philosophy by the wider developer community, who are significantly influenced by the GNU philosophy (and other philosophies cousin to it). I have noticed this presenting acutely around the role of C in OpenBSD since Rust became a common topic of discussion.

                                              C, the existing software written in C, and the value of that existing software continuing to be joined by new software also written in C, all have an important relationship to the Unix and BSD philosophies (most dramatically the OpenBSD philosophy), not merely “because security”.

                                              C is thus more dramatically connected to OpenBSD than projects philosophically related to the “GNU is Not Unix” philosophy. Discussions narrowly around the subject of C and Rust as they relate to security are perfectly reasonable (and productive), but OpenBSD folks are unlikely to participate in those discussions to disabuse non-OpenBSD users of their notions about OpenBSD.

                                              I’ve specifically commented about this subject and related concepts on the orange site, but have learned the lesson presumably already learned many times over by beards grayer than my own: anyone with legitimate curiosity should watch or read their own words to learn what OpenBSD folks care about. Once you grok it, you will see that looking to that source (not my interpretation of it) is itself a fundamental part of the philosophy.

                                              1. 1

                                                If that weren’t true, then it would mean that OpenBSD guys security skill is below average, which I don’t think is true.

                                                At least not far above average. And why not? They’re mostly amateurs, and their bugs don’t cost them money.

                                                And Joe just wants to write an application with some features, he doesn’t focus on security that much.

                                                I think you’re making a straw man. OpenBSD people aren’t going to make fewer bugs using any language other than C, and comparing Average Joe to any Expert just feels sillier and sillier.

                                                1. 3

                                                  What’s your source for the assertion ‘They’re mostly amateurs’?

                                                  1. 2

                                                    What a weird question.

                                                    Most openbsd contributors aren’t paid to contribute.

                                                    1. 3

                                                      What a weird answer. Would you also argue that attorneys who accept pro bono work are amateurs because they’re not paid for that specific work?

                                                      Most of the regular OpenBSD contributors are paid to program computers.

                                                      1. 1

                                                        because they’re not paid for that specific work?

                                                        Yes. In part because they’re not paid for that specific work, I refuse to accept dark_grimoire’s insistence that “if they can’t do it nobody can”.

                                                      2. 1

                                                        You seem to be using the word “amateur” with multiple meanings. It can mean someone not paid to do something, aka “not a professional”. But when I use it in day to day conversation I mean something more similar to “hobbyist”, which does not tell much about ability. Also saying they are amateurs, thus do not write “professional” code, implies anyone can just submit whatever patch they want and it will be accepted, which is very far from the truth. I assume with reasonable certainty that you never contributed to OpenBSD yourself, to say that. I am not a contributor, but whenever I look at the source code, it looks better than much of what I saw in “professional” work. This may be due to the focus on doing simple things, and also very good reviews by maintainers. And as you said, the risk of loosing money may be a driver for improvement, but it is certainly not the only one (and not at all for some people).

                                                        1. 1

                                                          You seem to be using the word “amateur” with multiple meanings,

                                                          I’m not.

                                                          as you said, the risk of loosing money may be a driver for improvement, but it is certainly not the only one

                                                          So you do understand what I meant.

                                                  2. -1

                                                    nailed it

                                              1. 6

                                                This question was prompted by a discussion I had about how I felt like all the momentum in programming languages is pointing toward Rust these days, and I felt like there’s no point in keeping my Go current (it’s been languishing for a couple of years now anyway).

                                                So, I asked this question to see (among other things) if I’m right or wrong.

                                                1. 12

                                                  What is driving that feeling? Genuinely curious, because I feel the opposite. I am seeing more and more enterprises adopt Go. In conversations I have with other engineers, Rust still feels a little underground.

                                                  I also think that Go and Rust have slightly different use cases & target audiences.

                                                  1. 9

                                                    Well, lobste.rs, for one. I feel like everywhere I look on here people talk about how they’d re-do everything in Rust if they could. The number of Rust advocates I see here seems to dwarf the number of Go advocates. Maybe that’s perception because Rust is “newer” and its advocates louder, but who knows.

                                                    The things that really stuck with me, though, were Linus indicating that he’d be open to allowing Rust in the kernel, Microsoft starting to switch to Rust for infrastructure, and Dropbox migrating their core technologies to Rust.

                                                    I just don’t see stories like that for Go. I don’t know if I’m not looking in the right place, or what.

                                                    1. 22

                                                      Go and Rust more or less solve the same problem (although the overlap isn’t 100%), just in different ways, not too dissimilar to how Perl and Python more or less solve the same problems in very different ways.

                                                      I have the impression that, on average, Go tends to attract people who are a little bit jaded by the Latest Hot New Thing™ churn for 20 years and just want to write their ifs and fors and not bother too much with everything else. This is probably one reason why the Go community has the (IMHO reasonably deserved) reputation for being a bunch of curmudgeonly malcontents. These are not the sort of people who go out and enthusiastically advocate for Go, or rewrite existing tools in Go for the sake of it: they’re happy with existing tools as long as they work.

                                                      Another reason I don’t really like to get involved in Go discussions is because some people have a massive hate-on for it and don’t shy away from telling everyone that Go is stupid and so is anyone using it every chance they get. It gets very boring very fast and I have better things to do than to engage with that kind of stuff, so I don’t. There’s some people like that on Lobsters as well, although it’s less than on HN or Reddit. It’s a major reason why I just stopped checking /r/programming altogether, because if the top comment of damn near every post is “lol no generics” followed by people ranting about “Retards in Go team don’t think generics are useful” (which simply isn’t true) then … yeah… Let’s not.

                                                      1. 14

                                                        Go and Rust more or less solve the same problem

                                                        Hard disagree, rust is way more useful for actual problems like c/c++ are. I can write kernel modules in it, there is almost no way i’d want to do that with go. Having a garbage collector, or even really a runtime in go means a different use case entirely to being able to run without an os and target minis. Yes I know go can be used for that too but just due to having a GC you’re limited on how far down the horsepower wagon you can go.

                                                        I hold no views outside of that rust actually has solutions and community drive (aka people using it for that upstreaming things) for programming things like avr processors etc… I don’t hate go it just strikes me as redundant and not useful for my use cases. Kinda like if you learn python not much use for learning ruby too kind of a deal. And if I’m already using rust for low level stuff, why not high level too?

                                                        I don’t however miss debugging goroutine and channel bugs though, go is way easier to shoot yourself in a concurrent foot without realizing it. It might be ‘simple’ but that doesn’t mean its without its own tradeoffs. I can read and write in it but prefer the rust compiler telling me i’m an idiot for trying to share data across threads to goroutine debugging where two goroutines read off one channel and one of ems never gonna complete cause the other already got it. I’m sure “I’m holding it wrong” but as I get older these strict and more formal/functional languages like rust/haskell/idris/blah strike my fancy more. I”m not talking about generics really but stuff like Monads (Option/Result essentially) read to me way better than the incessant if the thing i did isn’t nil constantly. Its closer to what I’ve done in the past in C with macros etc…

                                                        Its not that I hate it though, just that the language seems a step back in helping me do things. Idris as an example though is the coolest thing I’ve used in years in that using it was like having a conversation with the compiler and relearning how to move my computation to the type system. It was impressive how concise you can make things in it.

                                                        As a recovering kernel/c hacker, you’d think go would appeal but to be honest it just seems more of the same as c with less ways of stopping me from shooting myself in the foot needlessly.

                                                        But to each their own, functional languages with types just strike me as actually doing a lot of things that OO languages from the mid 90’s always said could be done with open form polymorphism but never seemed to happen.

                                                        In 10 years we’ll see where the ball landed in the outfield so whatever.

                                                        1. 11

                                                          Yes, hence the “more or less”. Most people aren’t writing kernel modules; they’re writing some CLI app, network service, database app, and so forth. You can do that with both languages. TinyGo can be used for microcontrollers, although I don’t know how well it works in practice – it does still have a GC and a (small) runtime (but so has e.g. C).

                                                          I don’t however miss debugging goroutine and channel bugs though, go is way easier to shoot yourself in a concurrent foot without realizing it.

                                                          Yeah, a lot of decisions are trade-offs. I’ve been intending to write a “why Go is not simple”-post or some such, which argues that while the syntax is very simple, using those simple constructs to build useful programs is a lot less simple. In another thread yesterday people were saying ‘you can learn Go in two days”, but I don’t think that’s really the case (you can only learn the syntax). On the other hand, I’ve tried to debug Rust programs and pretty much failed as I couldn’t make sense of the syntax. I never programmed much in Rust so the failure is entirely my own, but it’s a different set of trade-offs.

                                                          In the end, I think a lot just comes down to style (not everything, obviously, like your kernel modules). I used to program Ruby in a previous life, which is fairly close to Rust in design philosophy, and I like Ruby, but it’s approach is not without its problems either. I wrote something about that on HN a few weeks ago (the context being “why isn’t Ruby used more for scripting?”)

                                                          1. 4

                                                            Most people aren’t writing kernel modules; they’re writing some CLI app, network service, database app, and so forth. You can do that with both languages.

                                                            CLI yes, database probably, but I don’t think Rust’s async or concurrency or whatever story is mature enough to say it’s comparable with Go for network services.

                                                            1. 1

                                                              Cooperative concurrency is just more complicated (as a developer, not as a language designer) than preemptive concurrency. The trade-off is that it’s more performant. Someone could build a Rust-like language, i.e. compiler-enforced data race freedom, with green threads and relocatable stacks. And someday someone might. For now, the choice is between performance and compiler-enforced correctness on the Rust side, or “simpler” concurrency on the Go side.

                                                        2. 3

                                                          There’s just a lot of toxicity about programming languages out there, and subjectively it feels particularly bad here. Rust has a lot to like and enough to dislike (abandoned libraries, inconsistent async story, library soup, many ways to do the same thing), but something about its culture just brings out the hawkers. I still heartily recommend giving Rust a try, though you won’t be super impressed if you’ve used Haskell or Ocaml in the past.

                                                          1. 6

                                                            I came to Rust after having used Haskell and the main thing about it that impressed me was precisely that it brought ML-style types to language with no GC that you could write an OS in.

                                                            1. 5

                                                              with no GC

                                                              I guess I find this often to be a solution with very few problems to solve. It’s understandable if you’re writing an OS or if you’re working on something real-time sensitive, but as long as the system you’re making can tolerate > 1ms p99 response times, and doesn’t require real-time behavior, Go, JVM languages, and .NET languages should be good enough. One could argue that there exists systems in the 1-10ms range where it’s easier to design in non-GC languages rather than fight the GC, and I can really see Rust succeeding in these areas, but this remains a narrow area of work. For most systems, I think working with a GC keeps logic light and easily understandable. When it comes to expressive power and compiler-driven development, I think both Haskell and Ocaml have better development stories.

                                                              1. 1

                                                                Rust also has a much cleaner package management story and (ironically) faster compile times than Haskell. And first-class support for mutability. And you don’t have to deal with monad transformers.

                                                                Haskell is still a much higher level language, though. I experimented last night with translating a programming language core from Haskell to Rust, and I quickly got lost in the weeds of Iterator vs Visitor pattern vs Vec. Haskell is pretty incredible in it’s ability to abstract out from those details.

                                                            2. 0

                                                              Your descriptions of both advocates and Go haters match my experience exactly.

                                                            3. 14

                                                              I’ve been using Go since around the 1.0 release and Rust for the last year or so. I don’t think either of them is going away any time soon. Go has less visible advocates, but it’s definitely still used all over the place. Datadog has a huge Go repo, GitHub has been looking for Go engineers, etc.

                                                              Rust is more visible because it’s newer and fancier, but it still loses for me in multiple aspects:

                                                              • Development speed - It’s a much pickier language and is much slower to develop in, though it forces you to get things right (or at least handle every case). Rust-Analyzer is great, but still fairly slow when compared to a simpler language.
                                                              • Compilation speed - Go compiles way faster because it’s a much simpler language.
                                                              • Library support/ecosystem - Because Go has been around for quite a while, there are a wealth of libraries to use. Because Rust hasn’t been around as long, many of the libraries are not as mature and sometimes not as well maintained.

                                                              However, Rust makes a number of improvements on Go.

                                                              • Error handling - Rust’s error handling is miles above Go. if err != nil will haunt me to the end of my days.
                                                              • Pattern matching - extremely powerful. This is an advantage Rust has, but I’m not sure how/if it would fit in to Go.
                                                              • Generics - In theory coming to Go soon… though they will be very different feature-set wise

                                                              They’re both great languages, and they have different strengths. For rock-solid systems software, I’d probably look at Rust. For web-apps and services, I’d probably look to Go first.

                                                              1. 4

                                                                Rust also loses massively in concurrency model. Tokio streams is so subpar to channels.

                                                                1. 3

                                                                  Tokio also has channels - MPSC is the most common variant I’ve seen.

                                                                  When Stream is added back to tokio, these will also impl Stream

                                                                  I do agree that having goroutines as a part of the language and special syntax for channels makes it much easier to get into though.

                                                                  1. 1

                                                                    Rust’s async/await is definitely more complicated than Go’s green threads, and is almost certainly not worth it if Go has everything you need for your project. However, Rust’s standard threads are extremely powerful and quite safe, thanks to the Sync and Send marker traits and associated mechanics, and libraries like rayon make trivial parallelism trivial. Just yesterday I had a trivially parallel task that was going to take 3 days to run. I refreshed myself on how to use the latest rayon, and within about 10 minutes had it running on all 8 hyperthreads.

                                                                  2. 2

                                                                    Spot on. They both have their annoyances and use cases where they shine.

                                                                  3. 6

                                                                    A further difference is that Go code is hard to link with other languages due to its idiosyncratic ABI, threading and heaps. Rust fits in better. Not just in OS kernels but in mobile apps and libraries. (I’m still not a fan of Rust, though; Nim fits in well too and just feels a lot easier to use.)

                                                                    1. 1

                                                                      I would say that is entirely compiler dependant, and not a property of the language Go. https://github.com/tinygo-org/tinygo

                                                                      1. 3

                                                                        As long as the language has highly scalable goroutines, it won’t be using native stacks. As long as the language has [non ref-counted] garbage-collection, it won’t be using native heaps.

                                                                        1. 1

                                                                          Well, tinygo != go, and e.g. gccgo still reuses the official standard library from the main implementation (which is where lots of the frustrating stuff is located, e.g. the usage of raw syscalls even on platforms like FreeBSD where it’s “technically possible but very explicitly not defined as public API”).

                                                                      2. 5
                                                                    2. 9

                                                                      Golang is awesome. It works without fanfare.

                                                                      1. 8

                                                                        As someone who dislikes Go quite a lot, and is really enjoying Rust: I think they are different enough they serve different use cases.

                                                                        Go is much faster to learn, doesn’t require you to think about memory management or ownership (sometimes good, sometimes very very bad, Go code tends to be full of thread-safety bugs), is usually fast enough. For standard web app that is CPU-bound it’ll work just fine, without having to teach your team a vast new language scope.

                                                                        On the flip side, I’m working on a LD_PRELOADed profiler that hooks malloc(), and that’s basically impossible with Go, and I also need to extract every bit of performance I can. So Rust is (mostly) great for that—in practice I need a little C too because of Reasons. More broadly, anytime you want to write an extension for another language Go is not your friend.

                                                                        1. 4

                                                                          Go comes with a built-in race detector. What sources do you have for “tends to be full of thread-safety bugs”?

                                                                          1. 11

                                                                            As someone with a fair bit of go experience: the race detector only works on races you can reproduce locally, as it’s too slow to run in production.

                                                                            Rust stops you from doing things that can race; go gives you a flashlight to look for one after you accidentally introduce it.

                                                                            1. 1

                                                                              That is a good point, but once a developer has encountered the type of code that makes the race detector unhappy, will they not write better code in the future? Is this really a problem for most popular Go projects on GitHub, for instance? Also, the “staticcheck” utility helps a lot.

                                                                              1. 3

                                                                                Unfortunately, there’s still, even among some experienced programmers, a notion that “a race will happen so rarely we don’t have to worry about this one case”. Also I’ve seen an expectation that e.g. “I’m on amd64 so any uint64 access is atomic”, with no understanding of out-of-order execution etc. I assume in Rust this would be a harder sell… though the recent drama with a popular web framework (can’t recall the name now) in Rust seems to show to me that using unsafe is probably kinda similar approach/cop-out (“I just use unsafe in this simple case, it really does nothing wrong”, or “because speed”).

                                                                        2. 3

                                                                          I think (hope) the world settles into Rust and Go. I don’t see the Bell Labs folks not going 3 for 3 with Go. Rust I enjoyed playing with many months ago and it was a bonus I guess (at the time) that it was backed by Mozilla. Misplaced loyalties abound. Maybe (in a decade or so) lots of things once written in C will Rust over and tcp/http stuff will be written in Go.

                                                                        1. 2

                                                                          Great article, the perspective is good even if you don’t end up building your compiler in exactly these steps. You had me at C and YACC. It’s weird to see a chicken developer hate on C. I thought that was chicken’s superpower. From the highest level of abstraction to the lowest (figuratively at least) it has you covered. (I really like programming in chicken along with C.) To all you vader haters out there, we’ll blow you’re planet up.

                                                                          1. 4

                                                                            haha, hi :)

                                                                            C is (or: was? before all the UB exploitation) a nice language to work with, but it is not sacred. It has a lot of issues (and we’ve certainly run into our share of issues particularly due to using it as a compilation target). It is great for low-level operations and for interfacing with existing operating systems. But for prototyping a new compiler? That’s silly. Manual memory management and its impoverished string processing functionality alone should put anyone off of using it for prototyping. At that stage, you don’t need performance or low-level control over anything, really.

                                                                            1. 3

                                                                              C’s string handling sucks (“impoversed” is harsh), but you can learn to use it. However, string handling really doesn’t matter for a compiler (really, I’m serious). The only time the compiler ever handles strings is in the lexer, and it’s not especially more difficult in C to convert input text into a token stream. From that point forward, you’re just working with types.

                                                                              The language which inspired this post has a lexer which is about 1 kloc, and literally none of the remaining stages use strings at all. The last stage, emit, does deal with strings insofar as it translates an AST back into text, but that’s accomplished entirely with fprintf calls and it’s quite straightforward.

                                                                          1. 1

                                                                            I use go with my own self hosted modules and public modules. It was confusing at first. Getting the go-import meta tag into the http/html paths was fun.

                                                                            Now I love it.

                                                                            I could see building large multi team projects this way. It’s far superior to how java does it.

                                                                            I should probably speak up more about it on the internet to offset the anti google moaning, but i guess i don’t care. (I am no google advocate either.)

                                                                            1. 3

                                                                              cgit combined with unix user account ssh based git repos is great. You can show anyone your code, but the real action is still on comandline git and ssh.

                                                                              (I was only using github as a code viewer)

                                                                              1. 0

                                                                                Why do people say hello to docker in the first place? Because unix, Make, compiled code, and shell script glue isn’t powerful enuf? Or to make devops a job title that means something. –Sarcastic and jaded, systemd still sucks

                                                                                1. 3

                                                                                  Well for example when you’re not working with compiled code (or you’re working with loads of shared libraries) then the system configuration starts playing a big role in how your program replies.

                                                                                  For example, you have a Python webserver. Firstly, do you have the right Python available? And if this server does something like PDF rendering it might call out to another application to do so, so is that installed properly?

                                                                                  I think that this stuff is more avoidable with like…. proper compilation artifacts but it can be painful to reproduce your production system locally when you are doing something more novel than just querying a DB and generating text

                                                                                  1. 3

                                                                                    Well for example when you’re not working with compiled code

                                                                                    Have you actually ever worked with a bigger C/C++ application? :) I’ve never seen any ecosystem where it is worse to separate your system’s library version in /usr from custom installed stuff. Everything from Python, Ruby, PHP is so much easier to work with in this regard.

                                                                                  2. 2

                                                                                    One of the reasons is because “we have an Kubernetes / OpenShift / Frozbinitz Special cluster” that is supported by “the enterprise” and I can do my initial work on my laptop with Docker.

                                                                                    I don’t like Docker the company, but Docker the command line tool is fine. Docker Desktop has the potential to be great, but it seems like it would require Docker the company to be purchased by someone less dependent on registered users as a metric for survival.

                                                                                    1. 1

                                                                                      Here’s one example. At my last job, I first introduced Docker to our environment because, sadly, we had a few Node.js applications written at various points in the company’s history each of which required a particular version of the Node runtime and also particular versions of various modules that weren’t compatible with all the versions of the runtime we were using.

                                                                                      It made the production configuration a bit of a nightmare to keep track of. If you wanted to run two of these on the same host, you could no longer just install a Node system package, etc.

                                                                                      Packaging the applications in Docker containers eliminated all those headaches in one step.

                                                                                      We were not running Kubernetes or any other orchestration system; we just stopped deploying directory trees to our servers. We still used scripts to do our deployment, but they became much simpler scripts than before.

                                                                                      1. 1

                                                                                        Because their code doesn’t scale. Docker is a hardware solution to a software problem

                                                                                        1. 1

                                                                                          Can you elaborate on this? I’ve mostly used Docker to simplify dependency management, nothing whatsoever to do with any kind of scaling concern. How is it a “hardware solution” when it is a piece of software?

                                                                                          1. 1

                                                                                            K8s (which is just fancy docker orchestration) allows you to string containers together. You can find many pre defined config a that allow rapid scaling up and down, allowing an “app” to add additional workers when needed, add those to the load balancer and when they are idle to tear them down. It’s really “neat” but by adding (and subtracting) machines as needed it’s my point of being a hardware solution to a software problem.

                                                                                            Instead of worker threads and processes and LPC you end up with many machines and RPC. The plus side of going with RPC of course is that you do get to scale on multiple physical hosts easily, while a thread aware app now needs to manage LPC and RPC to scale.

                                                                                            It’s “expensive” hardware wise but look at Rancher it’s a quick and easy k8s that deploys painlessly and once you setup shared storage you can take some predefined app setup and hit the plus button from the UI and watch it auto scale, then hit minus and watch it right size.

                                                                                            1. 1

                                                                                              Sure, that makes total sense, but you’re talking about Kubernetes, not Docker, no? How does any of that apply if you’re running a fixed set of standalone Docker containers on a fixed set of hosts, say, or running Docker in development environments to get a consistent build toolchain?