1. 4

    offline web apps

    They could be web apps or offline apps. No both at once.

    And I approve every measure to kill cancerous “webdev” in mobile apps. Just treat your customers right and deliver native applications, okay?

    1. 7

      It can be both at the same time. You get the best of both worlds, the amazing distribution capabilities of the web and the offline features of a native app. The fact that you don’t like them shouldn’t preclude people from shipping them and those who enjoy them, from using them.

      For example, my main machine is a Surface Pro X and I don’t get many native apps for my system but I can use PWAs on the desktop and they work great.

      Also you mention:

      I approve every measure to kill cancerous “webdev” in mobile apps

      Which means you’re unaware that this affects desktop as well, thought you should know.

      I find your phrase:

      Just treat your customers right and deliver native applications, okay?

      Disingenous are there are many reasons to ship a web app, among them is the fact that to ship an iOS application you need at least a Macintosh computer and a paid membership to Apple’s developer program, while to ship a web app you need nothing, you can do it from a cybercafe using nothing but online services. The Web is empowering, democratic as in most people can post, and interoperable. These qualities are not usually present in native apps. Saying that web developers are cancerous is quite bad. The Web is the only mass media communication channel available for mankind. It is how many of us are finding comfort and solace in this time of lockdowns and pandemic. It is how we’re learning new skills, finding new friends, recording our memories. Do not disqualify something that is larger than what your petty prejudices can reason about.

      1. 7

        Just treat your customers right and deliver native applications, okay?

        This may be preferable for your existing mainstream customers, but it also makes sure that you become one more reason why any iPhone/Google Android alternative is bound to fail.

        I hate web technologies as much as anybody else, but if it wasn’t for them I wouldn’t have Uber or Duolingo on my phone. If webapps is what it takes to have any chance at some mobile platform diversity, I’d happily waste some CPU cycles.

        1. 3

          Are you talking on the desktop or on mobile?

          On mobile, as a consumer, I really don’t want apps I need to install and that spy on me. I trust the web browser sandbox plus plugins so much more then I would ever trust app reviews. And app stores are closed ecosystems and there are so few of them and they are OS specific – argh. Disgusting.

          On the desktop, app sandboxes are premature. And often suffer the same problems as the app stores.

        1. 3

          I think that Apple replied in the original post (in the section “A Note On Web Applications Added to the Home Screen”):

          As mentioned, the seven-day cap on script-writable storage is gated on “after seven days of Safari use without user interaction on the site.” That is the case in Safari. Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. We do not expect the first-party in such a web application to have its website data deleted.

          If your web application does experience website data deletion, please let us know since we would consider it a serious bug. It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.

          As far as I understand, PWAs are not affected so…

          1. 4

            PWAs are not affected if they are installed onto the home screen, if you keep using them inside Safari they are still affected and so are all the other web sites. It is also a bit confusing because the wording under:

            Web applications added to the home screen are not part of Safari and thus have their own counter of days of use.

            Emphasis added by me to highlight that they are counting days for the installed PWA usage, which makes me wonder if they are deleting it as well or why they are counting the days of usage in such cases. I don’t know.

            1. 2

              I find the text incredibly confusing.

              have their own counter of days of use.

              So, what counts as use? Do I have to open the app? And after what number of days is my data deleted?

              1. 2

                What counts as use is opening the app from the home screen. Data will be deleted after 7 days without opening the app.

                1. 2

                  Safari: each day you use it counts as a day. If 7 days of usage have passed without you visiting a specific website, its data is erased.

                  Homescreened webpage: each day you use it counts as a day. If 7 usage days have passed without you visiting the website, its data is erased. But since you visit the website every time you click the icon on your home screen, the counter should never go above 1. (If you’re using some third party domain to store the data, if it gets erased depends on how the webpage works and what your user does.)

                  1. 1

                    I find it confusing as well.

              1. 3

                This seems like a typical versioning API problem. You have those naturally at the boundaries of teams or maintainership. FreeBSD seems to move the boundary further up so that legacy support is clearly separated from core interfaces by layering. I like it.

                I wonder how the compat layer is used. It sounds like you need to choose to use it which might be bothersome. Your stuff stops working, you debug, you use the compat layer. Much wasted effort.

                If the interface is clearly versioned, things might be too conservative but automatic.

                1. 3

                  From a kernel perspective, with FreeBSD, lots of the compat is on by default for quite a while(one might argue too long). FreeBSD really is known for not breaking things willy nilly. In my experience, even when they do finally, almost reluctantly, turn off compat, they leave it optionally enabled by a recompile. FreeBSD is amazingly stable in that regard. Unless it’s a giant security hole that can only be fixed by breaking userland, the stable branch tends to be very very stable. They would only break compat during a major release (say 11.X to 12)

                  For instance, FreeBSD right now is in the middle of merging the linux ZFS stack into FreeBSD replacing the Illumos upstream, which comes with lots of potential incompatibility. In 12.X(read stable) it’s an optional package one can install and play with, and it’s very well labelled as experimental. It should become the default with the 13.X release. Meanwhile they keep updating the experimental version in 12, working through the bugs. So users can play with the “new hotness” now, even in the stable branch, if they want, but are warned. Plus of course you can install the 13 branch(unstable/development) to play and test as well if you want.

                  1. 3

                    From a kernel perspective, with FreeBSD, lots of the compat is on by default for quite a while(one might argue too long). FreeBSD really is known for not breaking things willy nilly

                    That’s true to a degree, but it’s also a bit more complicated. In some ways, FreeBSD’s compat guarantees are a lot stronger than Linux’s, but in others they’re weaker. FreeBSD does not break ABIs (or KBIs) within a major release. I was amused to learn recently that Debian/kFreeBSD added FreeBSD support to DKMS, even though it’s solving a problem that simply does not exist with a FreeBSD kernel: a kernel module for FreeBSD X.Y will work with FreeBSD X.(Y+1). It will (almost?) definitely not work with FreeBSD X+1.

                    For the userspace APIs, FreeBSD guarantees backwards compatibility within a major release and across releases if you install the compat libraries and build your kernel with the right COMPAT_* options. The kernel options will include compatibility versions of system calls (when a system call changes in an incompatible way, it gets a new syscall number. The old one is supported only when the relevant compat options are included). Most FreeBSD core libraries use symbol versioning, so you don’t need to have multiple versions installed, but the compat packages include old versions of libraries that have had SONAME bumps or have been removed in newer FreeBSD.

                    One place where Linux does a lot better; however, is in admin interfaces. FreeBSD does not guarantee compat between major versions for the ioctls used for control plane things. For example, all of the things that ifconfig uses may change in incompatible ways between major versions. Linux tries much harder to keep these stable (though they may completely remove things, like OSS, and just expect the world to rewrite software to suit this week’s APIs - basically, all bets are off when it comes to device drivers and each one has a different support story), so an old ifconfig still works on a new Linux.

                    This is a problem for FreeBSD when you combine it with jails. You could run a FreeBSD 9 jail on a FreeBSD 10 system for testing things on older systems, but unfortunately you couldn’t run FreeBSD 9’s ifconfig because the interfaces it needed had changed. I believe that there’s been work recently to add compat layers for a bunch of those things, though I’d prefer to see a setup where the host system could configure everything for a jail, without needing all of the init / RC goo in each jail.

                    1. 1

                      agreed and thanks for the detailed response!

                      I was trying to keep my response simple, but you definitely added more detail, and it’s much appreciated!

                    2. 1

                      merging the linux ZFS stack into FreeBSD replacing the Illumos upstream

                      huh, is that actually happening? I’ve seen some patches from ZoL land, but in -CURRENT the stock ZFS still uses opensolaris.ko, and the ZoL-based thing is still only in the external openzfs-kmod, regardless of whether you run -STABLE or -CURRENT

                      1. 1

                        Last I heard[0], but I’m not part of that team, so I can’t say with any certainty. I imagine it’s still their goal, but perhaps there are some blockers delaying the adoption? I don’t have any new information around this.

                        0: https://papers.freebsd.org/2019/bsdcan/jude-the_future_of_openzfs_and_freebsd/

                  1. 6

                    I do not fully understand they did not just update ifconfig(8) – random IRC rumors say there was a failed attempt due to ifconfig(8)’s convoluted code-base.

                    ^ That seems like the “real reason”.

                    1. 10

                      The reason is that ifconfig maintains bugs. The Linux kernel is irrelevant. If ifconfig would change its output format, many scripts around the world would break.

                      1. 3

                        The reasons seem connected, though. If maintaining known bugs weren’t the policy, then ifconfig could have been rewritten.

                        1. 4

                          It can still be rewritten and use the new interfaces.

                          1. 1

                            So the real title should be: “ifconfig maintains bugs: The real reason ifconfig on Linux is deprecated”.

                            (Also, there are ways of transitioning over to new APIs; you could release an ifconfig2 or whatever with new behavior, or add a flag for a new structured output that might be more pleasant to parse anyhow.)

                        1. 12

                          Hearing about stuff like this is why when I hear that somebody has worked at GOOG or others I’m not automatically impressed or intimidated.

                          Also, I am curious what the internal codebase of a such a place looks like when they seem to optimize for hiring folks with theoretical knowledge who don’t value their own time. After a couple of decades of this, it’s probably not pleasant to work in.

                          1. 18

                            Oh, it’s extremely pleasant to work in, as long as it’s what you like. The tooling is amazing compared to anything on the outside. People with theoretical knowledge who don’t value their own time, tend to rabbit-hole on building the most elegant solution to the general problems they’re facing - and a lot of people at Google have successfully built those solutions, which lets everyone else benefit. Developer time may not be the metric that the tooling optimizes for, but developer comfort is amazing.

                            That said, there’s rough edges everywhere that nobody has time to fix. Almost everything is maintenance work in an existing project, so if you aren’t experienced at working in a codebase that’s too large to fully understand, good luck. Deploying something to production also has a lot of hurdles that would not exist in a smaller organization; I believe those hurdles are there for good reasons and shouldn’t be eliminated, but it’s a fashion of working that many people wouldn’t enjoy.

                            1. 4

                              The tooling is amazing compared to anything on the outside

                              That’s a strange statement. How would you know?

                              I was impressed with some tools but generally my job involved a lot of waiting for unnecessarily slow tooling.

                              1. 7

                                Some of us have worked at several other places before Google.

                                1. 2

                                  Sure, me, too. I guess what this meant was “The tooling is amazing compared to anything on the outside [for what I’ve seen]”. Maybe even “[compared to the five other big tech companies that I worked for]”. Or whatever your experience is.

                                  It seems like nit picking but I think it is important not to put Google on that pedestal. And in my experience the tooling is nowhere as good to believe this is true. But I guess it also depends on what is important to you. There is some amazing infrastructure at Google for sure but I had to use terrible tooling as well which was easily bested “outside”.

                                  I’d even say, it is easy to get a much better development experience for me than I had at Google for a small company setup. It will just nowhere scale as good.

                                  1. 3

                                    “Anything” was certainly an over-statement. I think it came off like I was saying something stronger than I meant to; I was trying to compare against what’s generally available in open-source communities, not against other companies with similar levels of resources.

                                    It’s also true that a lot of Google’s fancy tooling is meant to solve problems that nobody smaller than them has, because those problems only arise at scale.

                                    I do agree that it’s important not to put Google on a pedestal. I will certainly agree that, even comparing to what’s available in open-source land, nothing at Google is so dramatically better that we should give up on ever matching it.

                                    1. 1

                                      Yeah, different set of needs. Now I’m curious about what you had to use. Mind PMing me?

                              2. 3

                                The codebase is in decent shape overall, especially considering its size & age. Thanks to having a monorepo & some very impressive tools for refactoring at scale, plus a willingness to constantly deprecate stuff even if it’s painful, the code stays in good shape even when nobody even works on it anymore!

                              1. 4

                                I had really fun in my interviews.

                                It was somewhat disappointing that there were not really challenges like that when I started working.

                                1. 9

                                  Indeed, in the 8.5 years I’ve worked at Google building software I think I’ve had to solve an interview-calibre algorithmic problem maybe thrice. Mostly we write plumbing to move protos around.

                                1. 19

                                  I do not agree with the last point. Debuggers are useful and use of one does not point to poor code quality.

                                  1. 5

                                    I agree. I don’t see how using a debugger is any different from one of the suggested alternatives:

                                    Use print statements

                                    If I see code littered with echo or printf or logging statements, it says to me that you’re not sure what the code is doing there and you want some insight.

                                      1. 2

                                        If I see code littered with echo or printf or logging statements, it says to me that you’re not sure what the code is doing there and you want some insight.

                                        I think this only holds if you know all the ways in which the code is driven from the outside. Many of the bugs I find, at least in my code, are the result of emergent behavior I didn’t completely foresee. They are bugs in their own right, sure, but they tend to be manifest themselves only when my code runs in the scpoe of a larger system.

                                        In such a case I find it immensely useful to have prints, logs or traces all over the place so that I can see how the system is driven into an error state. Having the prints can also mean you’re not sure how your code is being used.

                                      2. 5

                                        95% of the time I have to use a debugger, it is because the code is not written in a simple and obvious way.

                                        The other 5% of the time it’s because “some other weird thing is going on.”

                                        Having to use a debugger to understand what code is doing is absolutely a sign of a poor code. Good code can be read on its own and understood with a very high degree of confidence.

                                        Of course, as a programmer working with other people’s code and legacy systems, knowing how to use a debugger is important. But it still usually means you’re working with code that is overly complex.

                                        1. 2

                                          You can also completely understand how a piece of code works, but don’t understand why it exhibits certain behavior. This happens when your code is used in a big opaque system, and it happened to me a lot. For example:

                                          class Person {
                                              public Person(string name, int age) {
                                                  if (name == "" || name == null || age < 0 || age > 150)
                                                      throw new Exception("Invalid person.");

                                          If the exception is thrown, it is obviously the caller’s fault. But if this exception shows up, it’s not immediately clear where something is going wrong. You would need to read through the whole code to see what’s happening.

                                          Especially in languages with pointers or references, it is possible that a reference/pointer is copied somewhere in an unrelated function, and aliases with data you use. This way, data can be overwritten when you don’t expect it to be. I usually debug this by stepping through the code and watching the data.

                                          … and yes, it does mean that the code is not perfect. But hey, mistakes do happen.

                                          1. 1

                                            The problematic code in this case – from the perspective of my original comment – is the system code.

                                        2. 2

                                          Debuggers are symptomatic of not understanding the code. Agree or disagree?

                                          1. 11

                                            Oscilloscopes are symptomatic of not understanding the circuit.

                                            1. 2

                                              Yes. If you understood what they were doing, you wouldn’t need instrumentation.

                                            2. 4

                                              Debugging is symptomatic of not understanding the code.

                                              I think Hintjens is saying your (understanding of the) code & recent change should be so clear you don’t need a debugger, while c-jm is saying debuggers can be useful even when your code is clear and your changes were small. Both are obviously true.

                                              1. 2

                                                I think they are orthogonal really, code can be clean and hard to debug all at the same time.

                                                Elements of “clean” code can also lead to making debugging harder. The more functions you have to do smaller things while more easily readable always introduces context shifts etc.

                                                As with everything there are costs and benefits to every decision, all my point was is that in terms of a code quality the need to debug is not a good metric.

                                              2. 1

                                                What’s “the code” though. Abstractions layered upon abstractions. Finding bugs without debugging in legacy code or multi-threaded code is almost impossible without debugging.

                                                1. 2

                                                  I don’t dispute that.

                                                  Yet if you indeed are able to understand your code without a debugger, that’s a very good thing.

                                              3. 1

                                                Often you need to debug code somebody else wrote.

                                                1. 1

                                                  “Need” is the key part. Debuggers are super useful, but if I require them to do my job, then something is wrong.

                                                  1. 1

                                                    In my mind, debuggers are a great tool to validate and to enhance your understanding of how the code actually works. I have sympathy with the thought that it should not be necessary to run your code with a debugger to understand it. What I find weird is that the author puts this in a list together with “If your language offers a REPL that’s cool. “ which is for me in the same category of exploratory tool.

                                                  1. 19

                                                    My milter implementation has been completely stable since written in Python 2 in 2011. Now I have to destabilize it because people are taking Python 2 away.

                                                    (I do not have tests. Tests would require another milter implementation that was known to be correct.)

                                                    Sounds like the Python 3 tests have a completely stable Python 2 implementation to be tested against.

                                                    1. 4

                                                      My thought exactly.

                                                      He can test against live input samples. And some randomly generated ones / edge cases which he should have done anyways.

                                                      But of course, it is work. But if his current version really is rock solid, he could just continue running it with python 2 or buy red hat enterprise.

                                                    1. 5

                                                      I agree with the article but “use sequences in databases” might not be sufficient for your use case.

                                                      A common use case is syncing some sequence of events among clients. Considering Postgresql, the serials themselves are not covered by your transaction, allowing concurrent transactions on the same sequence but leading to gaps, jumps in the sequence etc.

                                                      It is particularly annoying that rows with lower IDs could commit later. So you cannot use that as paging/sync token to retrieve all rows added after your last sync. I don’t know if there is an elegant solution while allowing fully concurrent writes.

                                                      But I guess using constraints, optimistic locking etc is good enough usually. Other than that, with some extra config, you can use monotonic transaction IDs and query the range of still active transactions…

                                                      1. 5

                                                        This con about go is also very interesting :

                                                        The Fuchsia Platform Source Tree has had negative implementation experience using Go. The system components the Fuchsia project has built in Go have used more memory and kernel resources than their counterparts (or replacements) the Fuchsia project has built using C++ or Rust.

                                                        1. 4

                                                          Isn’t that the design of Go, though? I was under the impression that they optimised for latency at the expense of memory usage on purpose.

                                                          1. 3

                                                            That might be quite true, I don’t know about go’s goals.

                                                            Note though, that they used go in the beginning and apparently hoped for something better. So it surprised them. And Go was designed at the same company.

                                                            Maybe it was also a political decision to try to use go on the first place.

                                                            1. 3

                                                              Maybe it was also a political decision to try to use go on the first place.

                                                              It is explained in the pro section for Go. They integrated gVisor’s Network Stack and that’s how it ended up there. It’s not a surprise that they’d then make some effort to try and use it elsewhere as an experiment. Unless the use of gVisor usage is political, it seems like a fairly innocuous and commonsense approach to evaluating Go usage for their needs.

                                                              1. 2

                                                                True. Maybe “political” was a bit strong.

                                                                I wanted to play devils advocate to my own argument that they at least believed in the beginning that go would be a good fit.

                                                              2. 1

                                                                It’s a big company and Go is pretty specialised as a language. It’s really for shifting bytes around network sockets and not much more. The only reason it exists is that Google does a metric shitton of shifting bytes around network sockets.

                                                          1. 2

                                                            Someone has to irrationally pitch new technology and use it so that new paradigms get tested and formed.

                                                            Also, it might be not the lowest risk road but for me, choosing none mainstream technology has often worked very well. It gets to be a problem if you revisit your choices too often for too little cause.

                                                            1. 2

                                                              Fuzziness warning:

                                                              I remember using Postgresql years ago and that I had trouble finding a canonical way of escaping user terms. E.g. Include a quoted user provided term in a more complex full text search query. Maybe there exist an easy answer but I did not find it.

                                                              1. 3

                                                                Not sure I understand your requirements but were you looking for something like websearch_to_tsquery which translates a Google like query ie.

                                                                signal -“segmentation fault”


                                                                ‘signal’ & !( ‘segment’ <-> ‘fault’ )

                                                                which means find documents with signal present and segmentation followed by fault not present.


                                                                It is quite new (appeared in PostgreSQL 11) so it might have not existed when you last checked.

                                                                The <-> (followed by) operator appeared in PostgreSQL 9.6

                                                                1. 1

                                                                  Probably shouldn’t have commented. It was around 9 years ago.

                                                                  I wanted to insert a user provided term into a premade query string. Fully quoted so that it means “exact match”. As far as I remember, I did not find documentation on how to quote safely in the query language and no function to do so.

                                                                  Edit : I mean quoting inside a query string and not on the SQL level.

                                                                  1. 2

                                                                    I have run into this fairly recently.

                                                                    There’s a builtin function for ‘simple’ search (which is almost what you’ve asked for), but there’s still no ‘just find documents that match this string even if it has query directives in it’.

                                                                    1. 1

                                                                      A bit weird, isn’t it?

                                                                      It assumes that if we want to provide more complex queries to the user, they have to use one of the provided syntaxes on the database level. If you want to translate from a different query language, you really need quoting.

                                                                      Probably easy to provide inside of Postgresql as a function.

                                                                      1. 1

                                                                        It’s not weird. Full Text Search works because it tokenizes & stemmes complex documents. Then performs a search on that.

                                                                        This way words:jump jumping jumped all get indexed as ‘jump’. Then any search for either form will match. Searching verbatim how it stands in text, including all the stop words that get evicted during parsing/stemming would counter all the performance you gain from full text search and at that point you just perform regular string matching.

                                                                        1. 1

                                                                          That’s not what either me or pkolloch are talking about.

                                                                          to_tsquery parses its inputs, which are interpreted in the postgres tsquery language. There is no builtin input-escaping function for that language. As far as I know, the characters :|*'&() have special meaning, but there may be others.

                                                                          You can use plainto_tsquery if you only have user input, but if you want to combine user input with non-user input for powerful searches, you are going to run into trouble quite rapidly.

                                                                      2. 1

                                                                        You want prepared statements


                                                                        which can safely interpolate and quote user provided inputs. Slightly less safe (easier to misuse) are all the available string manipulation functions from the quote_ family and format (https://www.postgresql.org/docs/11/functions-string.html).

                                                                        Additionally most good database drivers handle proper quoting themselves (like psycopg2 for python) - there are a lot of gotchas but in all cases that has been a solved problem.

                                                                        1. 1

                                                                          Yes, I used prepared statements or some quoting framework support.

                                                                          Not talking about quoting on the SQL level, that’s clear but inside of a query string.

                                                                  1. 59

                                                                    I don’t want in the least to be a jerk about this piece. I can relate to it, inasmuch as my last effort to find a new job was for the most part a miserable and disheartening experience, and I don’t personally have anything like the will to engage in good faith with the kind of bullshit that’s described here.

                                                                    With that said, this kind of thing - of which I’ve read countless iterations by now - mostly functions for me as a reminder that, at root, the industry is completely fucked and somehow we’re all playing along. The fundamental work of most “software engineering” is poisonous to the world, the organizations described in these essays are owned by people who fall somewhere on a spectrum between con artists and malevolent oligarchs, and a class of diligent strivers is engaged in competing for a place in the second-order technical/administrative ranks. A status that lets you earn much better money than in most of the rest of the economy while directly helping engineer everybody else into a state of precarity. (A state which, of course, is what awaits you if you exit the predatory scene you’re enabling before extracting enough resources to be insulated from its effects.)

                                                                    Doing well in this environment seems to require either a quietly mercenary attitude or a profound capacity for self deception. There is of course a lot of human wreckage along the way. It’s striking to me how seldom I see anyone make the leap from “trying to get these jobs was a bad time full of getting raked over the algorithmic live-coding coals” to “we should burn this entire structure to the ground”.

                                                                    1. 14

                                                                      To be fair though, software engineering isn’t a homogeneous field, and I’m not sure ‘most’ is poisonous to the world. I have certainly never worked on anything I would consider poisonous, enabling of some kind of evil, or similar. What I do now is targeted at helping people out of bad situations and get themselves more stable.

                                                                      If you have some analyses of software engineering across the full spectrum that can back up what you’re claiming, I’d be interested to see them, as what I hear in articles like this just sound like they’re from a bubble I haven’t been near.

                                                                      1. 11

                                                                        what I hear in articles like this just sound like they’re from a bubble I haven’t been near

                                                                        Those are exactly my feelings. For the last 10 years in the field I haven’t been anywhere close to the environment described in pieces like this, and yet every time they pop up people (mostly on the orange site though) always find it relatable and comment with their similar experiences.

                                                                        Perhaps it’s just my own bubble, but it seems so alien and bizarre that it seems like an entirely different industry whatsoever. My first job was in a ~300-person company, and that was the last time I had a technical interview, and the last time someone asked for my resume. Everything since then was a “oh, we already know you from somewhere else/seen your code on github, that’ll do, when can you start”.

                                                                        All this talk about having a Top Dog Company in your CV, and I’m yet to see anyone even bothering to look at mine. All this bragging about massive salaries if you can get there, and yet my friends at Google get about the same money as I do with me bouncing between small companies and niche startups. I don’t think I’m that unique here either – and it makes me wonder why do people choose to put up with that crap? Multi-stage interviews, GDPR-insulting background checks, and for what? A status symbol, bragging rights? In an industry that is so starved for competent engineers that it’s willing to please you left right and center if you ask for it?

                                                                      2. 5

                                                                        Your comment has generalizations such as

                                                                        at root, the industry is completely fucked and somehow we’re all playing along. The fundamental work of most “software engineering” is poisonous

                                                                        and your solution (even though I hope metaphorical) is unrealistic and violent:

                                                                        “we should burn this entire structure to the ground”.

                                                                        I think that comments like that invoke raw emotions which harm constructive discourse. It is very unlikely that the “the industry is completely fucked”. I guess strong language feels good sometimes but may leed to people just expressing more of it and either cherishing their helpless victimhood or go for (hopefully harmless) violence.

                                                                        1. 2

                                                                          It is very unlikely that the “the industry is completely fucked”.

                                                                          This is undeniably a generalization. All the same, it encapsulates pretty well how I feel about the broad spectrum of the software economy, from smalltime undertakings to startups to bigcos to megacorps. There are places where writing code isn’t directly in service of anything particularly egregious, and employment relationships that are relatively benign, but both are still situated in a dysfunctional ecosystem in technical, social, and economic senses. It’s almost impossible at this stage for even the best of intentions and practices to escape this reality. To a first approximation, there is very nearly no ethical participation in software which is compatible with making a living at it.

                                                                          So: Yes, I think, completely fucked. Many intelligent people of good will disagree with me, but as these feelings have solidified, I’ve also found I’m hardly alone in them.

                                                                          I think that comments like that invoke raw emotions which harm constructive discourse.

                                                                          Perhaps. I don’t have any desire to turn a venue like this one into more of a shouting match. On the other hand, when I read material like the linked article, I can’t help feeling that a lot of people would be better off with a straightforwardly negative view of the system within which they’re competing for status and access.

                                                                          1. 1

                                                                            Thank you very much for the thoughtful reply!

                                                                            Do you have examples of professions with a better ecosystem in terms that you like?

                                                                            I guess “burning down” wouldn’t work or would actually just create chaos that is unlikely to be filled with something better. But I’d be interested in how something better would look like.

                                                                            1. 1

                                                                              Do you have examples of professions with a better ecosystem in terms that you like?

                                                                              I’m really not sure. I think we could stand to learn from the healthier aspects of the trades, academia, and actual engineering disciplines. But then these are realms with their own deep problems.

                                                                              But I’d be interested in how something better would look like.

                                                                              I imagine there’s a possible path from where we’re at to somewhere better, however unlikely. I’d like to see people at existing companies unionize & otherwise organize. I’d like to see new enterprises organized from the start as worker cooperatives or similar. Beyond improving their own working conditions, I’d like to see technical professionals use their relatively high status and power to better the lot of working people in general and reign in the predatory impulses of capital. (If nothing else by, like, forcefully declining to pour labor into said predation.)

                                                                              I’m not very optimistic about any of that, but sometimes I read essays like Considerations Regarding Distributed Software and dream a little.

                                                                          2. 1

                                                                            I honestly do not understand how trying to get everyone to speak like a cartoon version of a british buttler is an improvement of discourse. It’s not like this is a children’s tv show either, nor is lobsters funded by Disney.

                                                                            I don’t think policing speech to try to make everybody write like a lawyer is gonna make the site “better”. Might reduce the ratio of curse words, but it will also make everything boring to read.

                                                                            1. 2

                                                                              Oh, I don’t care much about curse words. I think that the comment overgeneralizes in a way that is not helpful for discussion.

                                                                              That is subjective and you are free to disagree. If you tell me why, I might even change my mind ;)

                                                                        1. 15

                                                                          Complaints about interviewing seem rather similar to complaints about open-plan offices. Pretty much everyone agrees it sucks, but it also never seems to change 🤷‍♂️ Indeed, things seem to be getting worse, not better.

                                                                          My biggest objection is that you’re often expected to spend many hours or even days on some task before you even know if you have a 1%, 10%, or 90% chance of getting hired, and then you get rejected with something like “code style didn’t conform to your standards”, which suggests they just didn’t like some minor details like variable naming or whatnot.

                                                                          I usually just ignore companies that treats my time as some sort of infinitely expendable resource, which doesn’t make job searching easier, but does free up a whole lot of time for more fulfilling activities.

                                                                          1. 2

                                                                            Getting rid of open - plan offices seems doable. Yet, we do not know how to screen for good engineers reliably with our without wasting anyone’s time.

                                                                            1. 1

                                                                              Hire them for an extremely short contract? Bootcamp does that. They pay travel and $1000 to work for them for a week, which doesn’t seem too bad.

                                                                              1. 5

                                                                                How would that work for anybody who’s currently employed?

                                                                                1. 2

                                                                                  The last time I interviewed, I was talking to about 10 companies. If the hiring process involved a short contract, they’d have been off my list.

                                                                                  1. 2

                                                                                    “Hire a candidate for a week” doesn’t strike me as a solution to, “Screen people without wasting anyone’s time.” At the very least, it forces the candidate to spend a week in what amounts to an extended interview. It seems to me like it’d be far more time-consuming for the existing team as well, what with coming up with a steady stream of short projects that require little or no onboarding, working with the candidate for the week instead of whatever else they’d otherwise be working on, evaluating the candidate’s work, and so on.

                                                                                    I’m not arguing that it’s a bad idea in general, just that I suspect it isn’t a good way to reduce wasted time.

                                                                                    1. 2

                                                                                      The responses show that it is just hard to come up with a process that works for everyone. Maybe one needs to offer choices but that has its own complications and reduces comparability.

                                                                                1. 11

                                                                                  That is one area in which Java has impressed me. Not sure about the last versions but if you refrained from internal APIs, your program wouldn’t break with a new version.

                                                                                  That was _not _ true for C++ which was an older language in 2005 when I had to make sure that C++ code would work with newer Windows/AIX versions. I think that the priorities of the language designers matter a lot.

                                                                                  Go seems relatively conservative with only slow language and library evolution - so to an outsider line me, it looks relatively time safe.

                                                                                  Rust changes a lot but is committed to keep old code working. But idiomatic rust and the library ecosystem is still evolving rapidly. Therefore, I think your code might have a fair chance to keep working in 10 years but only with ancient library versions.

                                                                                  1. 2

                                                                                    I just incorporated C++ code I wrote 18 years ago into a new project without effort. The C++ core language API does have this property. External libraries on the other hand might not, but this is also true for Java. Java has one advantage here in that the graphics APIs are part of the core language.

                                                                                    1. 2

                                                                                      Go has an extreme compatibility guarantee. Rusts is much weaker - compiling older rust code with a new toolchain can require quite a bit of fiddling (much less once you know the language well).

                                                                                      1. 4

                                                                                        I’m not sure why you say it’s weaker for Rust. This is the point of their “editions”. https://doc.rust-lang.org/edition-guide/editions/index.html

                                                                                        Software authors have to opt-in to breaking compatibility.

                                                                                        1. 2

                                                                                          I say that because I’ve tried to get a rust program written 18 months ago to compile, and had to fight all kinds of mess.

                                                                                          This is largely because in order to target the microcontroller I was using, you needed to run nightly. Original author didn’t pin the nightly version they were using, though.

                                                                                          1. 2

                                                                                            I think you should have mentioned the circumstances in the initial comment.

                                                                                            That said, go as a language does not evolve much and that makes it a better platform right now if you are change averse.

                                                                                            1. 1

                                                                                              Go doesn’t have a “this may (will) be broken in 6 months” mode; rust does. That’s the weaker guarantee.

                                                                                              Personally I like rust better than go, but that wasn’t the question being asked.

                                                                                              1. 1

                                                                                                Sorry for the “should”. I still think that misrepresents stable rust. Probably there is some misunderstanding between us. Or I was very lucky. So you think that it is common that your code breaks with a new stable update? This happened once years ago to me with an obscure crate because of a fixed compiler bug and the language team had offered a fix to me (!!!) as a pull request upfront.

                                                                                                For stable rust, they strive for high compatibility. As with go, they may fix for safety reasons and some others. Otherwise, the language itself has strong stability guarantees and the language team had upheld those well as far as I know.

                                                                                                For libraries, it’s different. The ecosystem is evolving.

                                                                                                1. 1

                                                                                                  As an outsider trying to get existing rust code to run, there isn’t an obvious distinction.

                                                                                                  The existence of stuff that breaks under the “rust” name is significant.

                                                                                                  Possibly worse because for a long time nightly was required to target microcontrollers, so lots of things used unstable features.

                                                                                                  1. 1

                                                                                                    Which distinction?

                                                                                                    Between the language and the ecosystem? => I somewhat agree. The language being stable is an important ingredient in getting the ecosystem to mature, though.

                                                                                                    Between stable and nightly? => well, using nightly screems, “I care more about some fancy new experimental feature than about stability.

                                                                                                    1. 1

                                                                                                      Between stable and nightly? => well, using nightly screems, “I care more about some fancy new experimental feature than about stability.

                                                                                                      As an outsider, I come to rust when there’s an existing project I’d like to get running.

                                                                                                      In the rust projects I’ve looked at, the ratio of ‘needs nightly’ to ‘runs on stable’ is about 50/50.

                                                                                                      To me, that means that the stability of rust is only as good as the stability of nightly. That would be different if I were writing my own rust, but I’m not.

                                                                                                      As a person who wants to compile software written in rust: It’s quite likely that the software doesn’t compile without hacking it.

                                                                                                      1. 1

                                                                                                        I understand your point now.

                                                                                                        I think that you are just exposed to different parts of the ecosystem. I don’t know what is more typical.

                                                                                                        I think that if your perspective is typical, that’s quite problematic and I have been blind to that before.

                                                                                    1. 1

                                                                                      That surprised me. I thought I’d remembered that the difference is surprisingly small.

                                                                                      It’s weird that the article doesn’t mention the compiler.

                                                                                      1. 2

                                                                                        It’s more a question of runtime and ABI than of compiler. If you compile to linux/ELF and your runtime uses libunwind there isn’t that much the compiler can do to affect the performance.

                                                                                        Many compiler people talk as though that the performance of exceptions is the performance of code when no exception in thrown. Look at the phrasing about zero-cost exceptions, for example. (BTW, zero-cost exceptions either have a small cost or none, depending on how you count. It’s quite fascinating if you’re fascinated by that sort of thing.)

                                                                                      1. 8

                                                                                        @nmattia: lots of deserved praise for niv there ;)

                                                                                        1. 3

                                                                                          I was only surprised by point 3.

                                                                                          What is more, you will notice these quirks while programming which is a good time to notice quirks.

                                                                                          Giving its aim to type real-world TypeScript, I think it is a very well designed language.

                                                                                          1. 7

                                                                                            Did anyone else laugh at “This makes Nix packages a kind of blockchain.”?

                                                                                            (I assume that it was meant as a joke)

                                                                                            1. 9

                                                                                              I intentionally hide jokes like that in my more ranty posts, and you are the first one to mention it. You win the prize of knowing you are the first to report it. Congrats!

                                                                                              1. 2

                                                                                                NB: Noticed it but didn’t find it funny. Blockchains are serious business!11

                                                                                            1. 16

                                                                                              It seems the author has a different concept of “clean”. To me, “clean” is “less complicated” rather than “less duplicated”.

                                                                                              1. 3

                                                                                                I think that “clean” is not a good word to use because it is subjective and ambiguous. It is better to ask

                                                                                                • “Do you understand the code?” => “Can I make it easier to understand?”
                                                                                                • “Is it correct? Can you determine easily that it is correct?” => “Can I make it easier to verify?”
                                                                                                • “Is it fast enough?”…