Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T

TehPers

@ TehPers @beehaw.org

Posts
0
Comments
455
Joined
3 yr. ago

  • I tried AI, was impressed by it, and it's embarrassing; Need advice

    Jump

  • I keep trying to manually write code that I'm proud of, but I can't. Everything always needs to be shipped fast and I need to move on to the next thing. I can't even catch my breath. The only thing allowing me to keep up with the team is Cursor, because they all use it as well. The last guy that refused to use AI was just excluded from the team.

    This is the problem. It's not new that a company rushes its devs to deliver new features at a pace that results in garbage code. What's new is that devs who are willing to can deliver those features fast using a LLM. This obviously looks great to the imbecilic C-suites. Deliver features fast, get to market quickly, and spend less on devs!

    This is just short-term thinking, and it looks like you've noticed this. The team you're on won't change because the culture at your company is to deliver the next feature ASAP and focus on the short term. This is common with startups, for example, because it's a constant race to get more funding. However, it always results in some half-assed product that inevitably needs to be rewritten at some point. With LLMs now, you'll also have a team of people who don't even understand their own code, making it take even longer to fix things or rewrite it later.

    Anyway, if you hate it, start applying places now. At least in the US (where I am), the job market is ass. The more time you give yourself to search, the better the chance is that you'll find an option you like.

  • You can code only 4 hours per day. Here’s why.

    Jump

  • My favorite meeting is my 8am standup that's scheduled for 30 minutes and averages an hour. It really makes sure I have no energy to do anything else that day. Except it's every day. And most updates are "no updates" with extra words to make it sound like people are doing stuff.

  • Error handling in bash

    Jump

  • If you're writing a script that's more than 269 lines long, you shouldn't be using Bash.

    Jokes aside, the point isn't the lines of code. It's complexity. Higher level languages can reduce complexity with tasks by having better tools for more complex logic. What could be one line of code in Python can be dozens in Bash (or a long, convoluted pipeline consisting of awk and sed, which I usually just glaze over at that point). Using other languages means better access to dev tools, like tools for testing, linting, and formatting the scripts.

    While I'm not really a fan of hostility, it annoys me a lot when I see these massive Bash scripts at work. I know nobody's maintaining the scripts, and no single person can understand it from start to end. When it inevitably starts to fail, debugging them is a nightmare, and trying to add to it ends up with constantly looking up the syntax specific commands/programs want. Using a higher level language at least makes the scripts more maintainable later on.

  • What additional concepts should I learn before starting to learn rust?

    Jump

  • You can learn Rust whenever you want. There's no rule that you must learn anything (including C) before learning Rust. Of course, knowing C will make the basic concepts, especially around memory management, a lot simpler.

    If your goal is to eventually learn Rust, your next rabbit hole should be the book ideally. If you prefer a video format, I don't have any specific suggestions since I don't learn through videos usually, but I know there's some good video resources on YouTube.

  • A Software Library with No Code

    Jump

  • Moreover, you cannot say compilers are deterministic. There are situations where they are not (at least for the user).

    https://krystalgamer.github.io/high-level-game-patches/

    I'm not following. Which part of this is nondeterministic?

    The language being complicated to write and the compiler being confusing to use isn't an indicator of determinism. If GCC were truly nondeterministic, that'd be a pretty major bug.

    Also, note that I mentioned that the output behavior is deterministic. I'm not referring to reproducible builds, just that it always produces code that does what the source specifies (in this case according to a spec).

  • A Software Library with No Code

    Jump

  • The library is two text files (code) that are processed by an LLM (interpreter) to generate code of another type. This is not that new in terms of workflow.

    I think what makes this the worst is the fact that the author admits that you can't be sure the library will work until you generate the code and test it. Even then you cannot guarantee the security of the generated code and as you do not understand the code you also cannot give support or patch it.

    I've tried explaining how LLMs are not equatable to compilers/interpreters in the past, and it's usually to people who aren't in software roles. What it usually comes down to when I try to explain it is determinism. A compiler or interpreter deterministically produces code with some kind of behavior (defined by the source code). They often are developed to a spec, and the output doing the wrong thing is a bug. LLMs producing the wrong output is a feature. It's not something you try to fix, and something you often can't fix.

    This, of course, ignores a lot of "lower level" optimizations someone can make about specific algorithms or data structures. I use "lower level" in quotes, of course, because those are some of the most important decisions you can make while writing code, but turning off your brain and letting a LLM do it for you "abstracts" those decisions away to a random number generator.

  • Sudo maintainer, handling utility for more than 30 years, is looking for support

    Jump

  • Sudo maintainer, handling utility for more than 30 years, is looking for support

    Jump

  • It doesn't have to be. There are multiple sudo alternatives.

  • Sudo maintainer, handling utility for more than 30 years, is looking for support

    Jump

  • Funding or not, Miller expects sudo-rs to become the next generation of the tool in coming years.

    "Ubuntu is already shipping sudo-rs as the default sudo command in their latest versions," Miller told us. "I've been in contact with the people working on sudo-rs since the project started and I trust them to do right by the sudo user base."

    Projects don't last forever, and when they inevitably end, it's an opportunity to switch to something newer and hopefully better. Sudo coming to an end, if it does, will just force people onto alternatives.

    Being open source, sudo will always exist, whether someone else wants to maintain it, fork it, use it as-is, or just reference it. It's because it's open source that it can serve a purpose even beyond its EOL.

    Anyway, sudo's not dead yet, so there's still plenty of time for people to look at what's out there. Some distros have already moved to, or are considering moving to, alternatives like sudo-rs, so I'd expect that to continue.

  • Inheritance in 🦀

    Jump

  • Authentication in microservices

    Jump

  • The solution is project dependent but sometimes both are used. For example, on Azure, you can use a private network and managed identities to lock away the microservices. It depends on how much security you need/want.

  • Gas Town’s Agent Patterns, Design Bottlenecks, and Vibecoding at Scale

    Jump

  • At this point, wouldn't it be cheaper to buy a GPU and burn the electricity yourself? At least you can do a closed water cooling loop and limit the impact to 1-2 KW off the grid. Sure you lose Claude, and that'll have a huge impact, but I don't personally know anyone who can afford that much usage just to play around with some LLMs.

  • Breaking the Spell of Vibe Coding

    Jump

  • By default, doesn't tsc just output the source TS files with type info stripped? Worst case you run a formatter on that output and you're done.

    There's some nonstandard TS features like the iterator shim and decorators and such, but you don't get those by default from what I remember.

  • How useful are functional programming languages?

    Jump

  • Is a database handle you can write to not ... basically mutable state, the arch-nemesis of functional languages?

    Access to an external database is a kind of effect. In functional terms, you'd use a monad to represent this, though in Koka you'd define an effect for it. In either case, it becomes part of the function signature.

    A "pure" function could instead work around it by returning (without executing) a query, accepting a state and returning a new, modified state, or otherwise returning some kind of commands to the caller without directly querying the database.

  • Code review is dead, long live code review

    Jump

  • This puts far too much control on the LLMs. A LLM can provide suggestions for a PR, but those suggestions are not a sufficient replacement for a real review.

    If the rate of PRs is too high to review, the solution isn't to sacrifice the reviews. It's to ensure that the PRs are of sufficiently high quality that the reviews are quick. Small PRs are faster to review, and readable code is easier to review. Tests can validate correctness to the reviewer. Make the review process as easy as possible for a proper code review.

    The hybrid approach seems to me like it'd be the most successful here. Generate your PR suggestions, and let the PR owner resolve them how they like. Then, do a proper review on the PR. Where I disagree with the author here is the reviewer shouldn't review the suggestions and resolutions, but the final diff instead.

  • Breaking the Spell of Vibe Coding

    Jump 
  •  sh
        
tsc

    And now you're back to pure JavaScript.

  • Adventures in Rust borrowing deserialisation

    Jump

  • This does seem like an issue with the library you're using. Your second solution, using RawValue, is likely what I would have gone with, bundled with a self-referential type (wrapping the Pin in another nicer-looking type though). This is assuming I want to pass around a 'static type with the partially-deserialized data. In fact, I've done something like this in the past to pass around raw log data next to that same data in a parsed format (where the parsed data borrows from the raw logs).

    Alternatively, I'd have deferred the lifetime problem to someone else (library user for example) since the source data is probably provided at a higher level. This is how the libraries you're using do it from what I can tell. They make the LT the user's problem since the user will know what they want to do with the data.

  • Adventures in Rust borrowing deserialisation

    Jump

  • If I had chosen to write this code in Go I never would have had to think about any of this and I expect it would have been fine.

    Well the article is about zero-copy deserialization in Rust. If you just slap #[derive(Deserialize)] on a bunch of 'static types and let it copy the strings, then you don't have this issue in Rust either.

    Also, you'd be using Go, not Rust. That's fine, but not really relevant when you want to do JSON deserialization in Rust, is it?

    What a wild conclusion to come to.

  • Is the async_trait still necessary for dync Trait with async methods?

    Jump

  • Breaking down what async fn in trait does, it converts it to a fn method() -> impl Future<Output=T>, which breaks further down into fn method() -> Self::__MethodRet where the generated associated type implements Future.

    This doesn't work for dyn Trait because of the associated type (and the fact method() needs a dyn-safe self parameter).

    Instead, your methods need to return dyn Future in some capacity since that return type doesn't rely on associated types. That's where async_trait comes in. Box<dyn Future<...>> is a dyn-safe boxed future, then it's pinned because async usually generates a self-referential type, and you need to pin it anyway to .poll() the resulting future.

    Edit: also, being pedantic, associated types are fine in dyn traits, but you need to specify the type for it (like dyn Blah<Foo=i32>. Even if you could name the return type from an async fn, it'd be different for every impl block, so that's not realistic here.