Skip Navigation
firelizzard Ethan

Principal Engineer for Accumulate

Posts 10
Comments 176
  • if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.

    That goes without saying; I'm not a barbarian.

    “readability” is subjective. much like how there is no objective definition of “clean code”.

    Did you not see the part where I said it's less readable "in my opinion"?

    i am insisting that people use a common standard regardless of your opinion on it.

    I can read this one of two ways: either you're making an assertion about what people are currently doing, or you're telling me/others what to do. In the first case, you're wrong. I've seen many examples of self-closed <br> tags in the open source projects I've contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I'll do what they do, but if I'm the lead engineer starting a new project I'll do what I think is the most readable unless the team overwhelmingly opposes me, 'standards' be damned, your opinion be damned.

    The spec says self-closing is "unnecessary and has no effect of any kind" and "should be used only with caution". That does not constitute a specification nor a standard - it's a recommendation. And I don't find that compelling. I'm not going to be a prima donna. I'm not going to force my opinions on a project I'm contributing to or a team I'm working with, but if I'm the one setting the standards for a project, I'm going to choose the ones that make the most sense to me.

  • VSCode: Debugging Attached Process does not work
  • The TL;DR is that you have to exec —privileged and execute dlv attach within the container then tell VSCode to connect. I’ll look up my notes tomorrow and post more details.

  • VSCode: Debugging Attached Process does not work
  • Attaching to and debugging a process most certainly does work. I did it yesterday. Your issue is that Go doesn’t have any way of telling the process to pause until a debugger attaches. Which is frustrating but not the same issue.

    Specifically for debugging stdin, by far the easiest way to do that (in VSCode) is "console": "integratedTerminal". Another comment links a stack overflow answer that includes other options.

  • <br>
  • If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.

  • Solus Linux dropping patches for AppArmor and will end support for Snaps
  • AppArmor is part of the kernel. Why does it require patches?

  • Gitlab is not willing to make a team around federation
  • GitLab, Inc is a business and it’s not run by idiots. If federation was going to make them a bunch of money, they’d put a team on it. Relying on an outside group to execute your business goals is terrible management. It’s clear federation is not one of their business goals.

  • Gitlab is not willing to make a team around federation
  • They may advertise it, but they’d be working on it themselves if they thought it would bring in serious revenue.

  • Implementing RFC 3339 shouldn't really be that hard...
  • GMT doesn’t have daylight savings but London does

  • What are the applications that I can remove from Mint? + Mini Rant.
  • IMO that list is the obvious answer to “which packages can’t be removed without breaking the system”. Sufficiently obvious that I consider your insistence on specific “requirements” to be obnoxious. Though for that specific phrasing I would not include the terminal emulator or file browser. Using a system without them would be annoying but entirely doable.

  • What are the applications that I can remove from Mint? + Mini Rant.
  • You seem to be implying that applications could be considered basic functions. I can understand that perspective, but an application such as a music player or browser is certainly not a basic function of the OS, and I think it's a stretch to call those a basic function of the desktop environment. Maybe a better word is 'essential'. User applications are not essential to the OS, and the only applications I consider essential to the desktop environment are a terminal and a file browser, though the last one is negotiable. Of course things like the system setting app (or whatever GNOME calls it) are essential, but that's a component of the desktop environment and not a user application. So my list is:

    • The kernel
    • The init system
    • Essential system components and services such as dbus and pipewire without which the OS and/or desktop environment will be degraded or not function.
    • A terminal emulator app
    • A file manager app
  • What are the applications that I can remove from Mint? + Mini Rant.
  • The obvious answer is packages that aren’t essential for basic functions of the OS/desktop environment.

  • It's not like I just change things for the sake of change
  • I have no issue with their drivers working with their cards. I have issues using a proprietary, out of tree driver that taints my kernel and forces me to jump through hoops to get it to work whenever I recompile my kernel, which happens maybe once a month when Gentoo’s kernel source package is updated.

    Also I use Wayland (because that’s what KDE defaults to).

  • It's not like I just change things for the sake of change
  • I was an Apple fan for most of my life. And then Jobs died. The man was a huge asshole by all accounts but he sure knew how to design. Since then Apple has become just another tech giant making average products driven by business majors.

  • It's not like I just change things for the sake of change
  • I’m about ready to rehome my RTX 2080 and get an AMD card so I don’t have to deal with Nvidia’s proprietary garbage or the shit-tier open source drivers.

  • What am I losing by not using the C# Dev Kit?

    I exclusively use Visual Studio Code for editing code. I primarily work with Go, and a little bit with JavaScript/TypeScript, but I need to do some C# work.

    I have no interest in using Microsoft's proprietary C# Dev Kit or dealing with their licensing terms. What capabilities am I losing? The marketing materials for the dev kit talk about a lot of stuff that appear to be features of the open source C# extension, so it's unclear which features are actually exclusive to the dev kit.

    Surely "1337" is the same as 1337, right?
  • That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.

  • Linux market share passes 4% for first time; macOS dominance declines
  • I'm interpreting that as clickbait - just something they added to the title to drive traffic.

  • Play stupid games, win stupid prize
  • hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You're not supposed to hack the platform.

  • Is this the electron-alternative we've been waiting for?
  • It's not just about learning a language. Given two equivalent languages, writing a project using one or the other is always going to be less work and less of a maintenance burden than writing it using both. A competent manager will take that into account when deciding what tools to use. On top of that, learning a new language has a cost. Of course Rust and JavaScript are not equivalent, but which one is 'better' is highly subjective and dependent on how you measure 'better'. So a manager needs to take that into account. But my fundamental point is that using two languages for a project adds overhead, and learning a language adds overhead, so unless cost (including time) is irrelevant, there must be a compelling reason to choose a dual-language solution* over a single-language solution, and to chose a solution that requires your devs to learn a new language over one that does not. Not to mention switching platforms has a massive cost if your project is already mature. Even if you're creating a new project, if your team already knows JavaScript and doesn't have any particular objection to Electron, there's no compelling reason.

    If there is a good reason to learn a language then people will.

    Sure. Except in my experience interviewing candidates and from what I've seen online, there are a lot of developers out there who aren't very good. I am not optimistic that the average developer will have an easy time learning a new language. If the "we" in "Is this the electron alternative we've been waiting for" is you and I, that's not a problem. But if OP meant to suggest there will be a large-scale shift away from Electron, then the average developer is quite relevant.

    *As someone else pointed out, Dioxus is designed with the intent that you'll right the frontend in Rust, so it's not exactly dual-language like I thought.

  • Is this the electron-alternative we've been waiting for?
  • Ah, well that’s great for folks who already know or want to learn Rust

  • Why is crypto.subtle.digest async?

    Why is crypto.subtle.digest designed to return a promise?

    Every other system I've ever worked with has the signature hash(bytes) => bytes, yet whatever committee designed the Subtle Crypto API decided that the browser version should return a promise. Why? I've looked around but I've never found any discussion on the motivation behind that.


    What search engine do you use?

    Not sure if this is the right community, but I didn't see a general one. What search engine do you use? Besides Google increasingly spying on its users, the quality of its search results seems to have gotten significantly worse over the last decade. What search engine(s) do you use?


    What scientific journals do you recommend?

    I have a subscription to Nature but most of the articles are totally beyond me. I’m thinking of switching to a comp-sci specific journal. I’m mainly interested in compiler design and implementation of JIT compilers and VMs like JVM and .NET.


    Self taught = no imposter syndrome?

    I am a self-taught programmer and I do not have imposter syndrome. I have a degree in electrical engineering and when I thought that was going to be my career I did have imposter syndrome, so I'm not immune. I wonder if there's a correlation. It seems that many if not most professionals suffer from imposter syndrome; I wonder if that's related to the way they learned.

    When I say self-taught, I don't mean I never took a class, I mean the majority of my programming skill was learned by doing/outside of classes. I took a Java class in high school that helped me graduate from procedural languages to OOP, and I took classes in college but with few exceptions the ones that were practical (vs theoretical) covered material I already knew.


    Systems engineering in the software industry

    My last job was at a company that designed and built satellites to order. There was a well defined process for this, and systems engineers were a big part of it. Maybe my experience there is distorting my perspective, but it seems to me that any sufficiently complex project needs to include systems engineering, even if the person doing that is not called a systems engineer. Yet as far as I can tell, it isn't really a thing in the software industry. When I look at job postings and "about us" blog posts about how a company operates, I don't see systems engineering mentioned. Am I just not seeing it, is it called something else, or is the majority of the industry somehow operating without it?


    What languages are well suited for testing SDKs written in multiple other languages?

    I am working on an application that has SDKs in multiple languages. Currently Java, JavaScript, Dart, and Go, but ultimately we'd like to have an SDK for every major language. Our primary test suites are written in Go, which means our other SDKs are not well tested. I do not want to write or maintain test suites in four or ten different languages.

    What I would like to do is choose a language to write the tests in, define a test harness interface, implement that test harness for each SDK, and write the tests using that harness. Of course I could do this with RPC/HTTP/etc but that would add significant complexity. I'd prefer to write the tests in a language that has a meaningful degree of interop/FFI with most of the major languages. Lua comes to mind, since it seems like someone has built a Lua interpreter for basically every language in existence, but I have very little Lua experience and I have no idea how painful it might be to do this in Lua. I am open to other suggestions besides interop/FFI and RPC, though I don't want to take the approach of creating test templates and generating the tests in each language. I've done things like that and they're a pain to maintain.


    Why should I use rust (as a Go enthusiast)?

    I am not hating on Rust. I am honestly looking for reasons why I should learn and use Rust. Currently, I am a Go developer. I haven’t touched any other language for years, except JavaScript for occasional front end work and other languages for OSS contributions.

    After working with almost every mainstream language over the years and flitting between them on a whim, I have fallen in love with Go. It feels like ‘home’ to me - it’s comfortable and I enjoy working with it and I have little motivation to use anything else. I rage every time I get stuck working with JavaScript because dependency management is pure hell when dealing with the intersection of packages and browsers - by contrast, dependency management is a breeze with Go modules. I’ll grant that it can suck when using private packages, but I everything I work on is open.

    Rust is intriguing. Controlling the lifecycle of variables in detail appeals to me. I don’t mind garbage collectors but Rust’s approach seems far more elegant. The main issue for me is the syntax, specifically generic types, traits, and lifetimes. It looks just about as bad as C++'s template system, minus the latter’s awful compiler errors. After working almost exclusively with Go for years, reading it seems unnecessarily demanding. And IMO the only thing more important than readability is whether it works.

    Why should I learn and use rust?

    P.S.: I don’t care about political stuff like “Because Google sucks”. I see no evidence that Google is controlling the project. And I’m not interested in “Because Go sucks” opinions - it should be obvious that I disagree.


    How often does branchless programming actually matter?

    I've started noticing articles and YouTube videos touting the benefits of branchless programming, making it sound like this is a hot new technique (or maybe a hot old technique) that everyone should be using. But it seems like it's only really applicable to data processing applications (as opposed to general programming) and there are very few times in my career where I've needed to use, much less optimize, data processing code. And when I do, I use someone else's library.

    How often does branchless programming actually matter in the day to day life of an average developer?


    How do you organize miscellaneous tasks?

    I am an experienced developer, but not an experienced manager. I'd prefer if organizing tasks was not my responsibility, but I work at a small company and no one else is inclined to do it. How do you organize miscellaneous tasks when using a task management system such as Jira? We're using GitLab, but it has the same basic features, such as epics, milestones, tasks, and subtasks.

    I don't want to have miscellaneous tasks floating around in the ether, because things like that tend to get lost. But an epic is supposed to have a well-defined end goal, right? A good epic is something like "Implement this complex feature" or "Reach this level of maturity" - not "Miscellaneous stuff".

    The majority of the work we do fits fairly clearly into specific goals, such as "Release the next version of <this> feature." But what about bug fixes and other random improvements and miscellaneous tasks? How do you keep those organized?