6 ms·

There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not

There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not suggesting everyone should be rolling their own crypto, but there must be a healthy middle ground between that and a library that lets you pick font color.

bayindirh 6mo ago
That won't happen, because time to market is the biggest obstacle between the developers and the monies. If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret. Because an app is not built to help you. It's built to make them monies. It's not about the user, never. Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".
- thefounder 6mo ago
  It’s not always about money. It’s also about the time of the developer. Even for a hobby project you may burn out before to actually deliver it.
  - bayindirh 6mo ago
    I'll say depends. Personally, my hobby projects are about me, just shared with the world because I believe in Free Software. Yet, I'm not obliged to deliver anything to anyone. I'll develop the tool up to the point of my own needs and standards. I'm not on a time budget, I don't care. Yes, I personally try to reach to the level of best ones out there, but I don't have a time budget. It's a best effort thing.
    - thefounder 6mo ago
      In reality you are always on a time budget that is correlated with the output of the software you develop.(I.e is it worth it your time?) I’ve found out that the most important thing is to get feedback early even from yourself using whatever software you develop. If you develop a small effort piece of software you can ship it before other stuff is starting to compete for your time. But if it takes a year or more before even you can make any use of it I guarantee you that the chances of shipping it diminishes significantly. Other stuff competes for your time(I.e family, other hobbies etc).
      - bayindirh 6mo ago
        I think we tackle the same problem in different ways. For me, if something is not urgent, I do it in a best effort way, and the shipping time doesn't matter. I generally judge whether I allocate time for something or not depending on the utility and general longevity of the tool. I hack high utility / short life tools, but give proper effort to long life tools I need. As a side-effect, a long life tool can start very crude and can develop over time to something more polished, making its development time pretty elastic and effort almost negligible on the long run. For me shipping time is both very long (I tend to take notes and design a tool before writing it), yet almost instant: when I decide that the design is enough for V1, I just pull my template and fill in the blanks, getting a MVP for myself. Then I can add missing features one at a time, and polish the code step by step. Currently I'm contemplating another tool which is simple in idea, but a bit messy in execution (low level / system programming is always like that), but when it's design is over, the only thing I'll do it is to implement it piece by piece, without no time crunch, because I know it'll be long-living tool. I can time-share my other hobbies, but I have a few of them. I do this for fun. No need to torture myself. And, I can't realize my all ideas. Some doesn't make sense, some doesn't worth it, some will be eclipsed by other things. That's life, that's fine.
  - mock-possum 6mo ago
    Times are monies though
- iugtmkbdfil834 6mo ago
  This is wild shift that AI allows now. I am building stuff, but not all of it is for public consumption. Monies matter, but, so does my peace of mind. Maybe even more so these days.
- dijksterhuis 6mo ago
  i guess it's a market thing? because when i build stuff in a B2B scenario for customers, it is about the customer's users. Because the customer's users are the money. at least, that's my attitude on it :shrugs:
  - bayindirh 6mo ago
    > Because the customer's users are the money. That's exactly what I'm talking about. The end desire is money, not something else. Not users' comfort, for example. That B2B platform is present because everyone wants money. Most tools (if not all) charge for services not merely for costs and R&D, but also for profit. Profit rules everything. Users' gained utility (or with the hip term "value") is provided just for money. Yes, we need money to survive, but the aim is not to survive or earn a "living wage". The target is to earn money to be able to earn more monies. Trying to own all. This is why enshittification is a thing.
  - dnnddidiej 6mo ago
    The customer is the money. If the customer cares about its users then they are the money. Then you have the user is the product the customer is the advertiser situation. You please the customer enough to have a product to sell to advertiser. And this before we even touch deceipt. E.g. lying to the customer to make more money. companies work for their shareholders kinda they work for where the power lies. even shareholders get fucked too.
monarchwadia 6mo ago
Anecdata from a JS developer who has been in this ecosystem for 14 years. I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks. Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration. Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts. Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.
- jagged-chisel 6mo ago
  Frontend: eh - you could pick something that targets wasm. Definitely a tradeoff with its own headaches.
  - lukax 6mo ago
    Rust wasm ecosystem also needs a lot of crates to do anything useful, a lot of them unmaintained.
    - tclancy 6mo ago
      Now I imagining it like being outside a concert or other ticketed event: "Crates, who's selling? Who's buying?"
    - sjrd 6mo ago
      Try Scala? You only need one 0-dependency library for UI (Laminar), and you're good to go.
bigbuppo 6mo ago
I would say the solution is to make it small and ugly, back to the way it was in the pre-Web-2.0 era, but SQL injections were a thing back then, and they're still a thing today, it's just now there are frameworks of frameworks built on top of frameworks that make fully understanding a seemingly-simple one liner impossible.
tombert 6mo ago
I agree. I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses. I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately. I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example. Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.
- lukax 6mo ago
  Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)
  - tombert 6mo ago
    I mean, define "need" :) The answer is no, obviously I could use Jetty or Netty or Vert.x and have done all of those plenty of times; of course any of those would require pulling in a third party dependency. And it's not like the stuff I write performs significantly better; usually I get roughly the same speed as Vert.x when I write it. I just like having and building my own framework for this stuff. I have opinions on how things should be done, and I am decidedly not a luddite with this stuff. I abuse pretty much every Java 21 feature, and if I control every single aspect of the HTTP server then I'm able to use every single new feature that I want.
bensyverson 6mo ago
My opinion on "don't re-invent the wheel" has really shifted with these supply chain attacks and the ease of rolling your own with AI. I agree that I wouldn't roll my own crypto, but virtually anything else? I'm pretty open.
mpyne 6mo ago
> but there must be a healthy middle ground between that and a library that lets you pick font color. When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN. But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.
hgoel 6mo ago
I think we've pulled way too much towards "software must be a constantly maintained, living item, and users should update often", thus the recklessness with dependencies. This has also exacerbated the other aspects of dependency hell. But not only does this not match reality, it makes projects very vulnerable to this supply chain hijacking stuff. I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.
- xmcqdpt2 6mo ago
  From a purely aesthetic point of view, this is what I enjoy so much about C and Fortran. You look up a Rust crate and it hasn't been touched in 5 years. That means it's unmaintained and unusable, don't add it to your project or you will have a bad time. You find a C or fortran library that hasn't been touched in 20 years and (sometimes) it's just because it's complete and there hasn't been any reason to update any parts of it. You can just add it to your project and it will build and be usable immediately. I wish we had more of those.
  - dgb23 6mo ago
    Clojure and Go are similar to this from my experience.
tristor 6mo ago
The only time I would agree with that is crypto. Don't roll your own crypto. Otherwise there's minimal downside to rewriting basic things directly, and often its unnecessary if your language has a complete standard library. The only place I feel differently is with something like C, where the standard library is far from complete, in that case it makes perfect sense to rely on many third-party libraries, however you should assess them for robustness and security.

bayindirh 6mo ago

That won't happen, because time to market is the biggest obstacle between the developers and the monies. If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret. Because an app is not built to help you. It's built to make them monies. It's not about the user, never. Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".

thefounder 6mo ago
It’s not always about money. It’s also about the time of the developer. Even for a hobby project you may burn out before to actually deliver it.
- bayindirh 6mo ago
  I'll say depends. Personally, my hobby projects are about me, just shared with the world because I believe in Free Software. Yet, I'm not obliged to deliver anything to anyone. I'll develop the tool up to the point of my own needs and standards. I'm not on a time budget, I don't care. Yes, I personally try to reach to the level of best ones out there, but I don't have a time budget. It's a best effort thing.
  - thefounder 6mo ago
    In reality you are always on a time budget that is correlated with the output of the software you develop.(I.e is it worth it your time?) I’ve found out that the most important thing is to get feedback early even from yourself using whatever software you develop. If you develop a small effort piece of software you can ship it before other stuff is starting to compete for your time. But if it takes a year or more before even you can make any use of it I guarantee you that the chances of shipping it diminishes significantly. Other stuff competes for your time(I.e family, other hobbies etc).
    - bayindirh 6mo ago
      I think we tackle the same problem in different ways. For me, if something is not urgent, I do it in a best effort way, and the shipping time doesn't matter. I generally judge whether I allocate time for something or not depending on the utility and general longevity of the tool. I hack high utility / short life tools, but give proper effort to long life tools I need. As a side-effect, a long life tool can start very crude and can develop over time to something more polished, making its development time pretty elastic and effort almost negligible on the long run. For me shipping time is both very long (I tend to take notes and design a tool before writing it), yet almost instant: when I decide that the design is enough for V1, I just pull my template and fill in the blanks, getting a MVP for myself. Then I can add missing features one at a time, and polish the code step by step. Currently I'm contemplating another tool which is simple in idea, but a bit messy in execution (low level / system programming is always like that), but when it's design is over, the only thing I'll do it is to implement it piece by piece, without no time crunch, because I know it'll be long-living tool. I can time-share my other hobbies, but I have a few of them. I do this for fun. No need to torture myself. And, I can't realize my all ideas. Some doesn't make sense, some doesn't worth it, some will be eclipsed by other things. That's life, that's fine.
- mock-possum 6mo ago
  Times are monies though
iugtmkbdfil834 6mo ago
This is wild shift that AI allows now. I am building stuff, but not all of it is for public consumption. Monies matter, but, so does my peace of mind. Maybe even more so these days.
dijksterhuis 6mo ago
i guess it's a market thing? because when i build stuff in a B2B scenario for customers, it is about the customer's users. Because the customer's users are the money. at least, that's my attitude on it :shrugs:
- bayindirh 6mo ago
  > Because the customer's users are the money. That's exactly what I'm talking about. The end desire is money, not something else. Not users' comfort, for example. That B2B platform is present because everyone wants money. Most tools (if not all) charge for services not merely for costs and R&D, but also for profit. Profit rules everything. Users' gained utility (or with the hip term "value") is provided just for money. Yes, we need money to survive, but the aim is not to survive or earn a "living wage". The target is to earn money to be able to earn more monies. Trying to own all. This is why enshittification is a thing.
- dnnddidiej 6mo ago
  The customer is the money. If the customer cares about its users then they are the money. Then you have the user is the product the customer is the advertiser situation. You please the customer enough to have a product to sell to advertiser. And this before we even touch deceipt. E.g. lying to the customer to make more money. companies work for their shareholders kinda they work for where the power lies. even shareholders get fucked too.

monarchwadia 6mo ago

Anecdata from a JS developer who has been in this ecosystem for 14 years. I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks. Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration. Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts. Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.

jagged-chisel 6mo ago
Frontend: eh - you could pick something that targets wasm. Definitely a tradeoff with its own headaches.
- lukax 6mo ago
  Rust wasm ecosystem also needs a lot of crates to do anything useful, a lot of them unmaintained.
  - tclancy 6mo ago
    Now I imagining it like being outside a concert or other ticketed event: "Crates, who's selling? Who's buying?"
  - sjrd 6mo ago
    Try Scala? You only need one 0-dependency library for UI (Laminar), and you're good to go.

bigbuppo 6mo ago

I would say the solution is to make it small and ugly, back to the way it was in the pre-Web-2.0 era, but SQL injections were a thing back then, and they're still a thing today, it's just now there are frameworks of frameworks built on top of frameworks that make fully understanding a seemingly-simple one liner impossible.

tombert 6mo ago

I agree. I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses. I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately. I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example. Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.

lukax 6mo ago
Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)
- tombert 6mo ago
  I mean, define "need" :) The answer is no, obviously I could use Jetty or Netty or Vert.x and have done all of those plenty of times; of course any of those would require pulling in a third party dependency. And it's not like the stuff I write performs significantly better; usually I get roughly the same speed as Vert.x when I write it. I just like having and building my own framework for this stuff. I have opinions on how things should be done, and I am decidedly not a luddite with this stuff. I abuse pretty much every Java 21 feature, and if I control every single aspect of the HTTP server then I'm able to use every single new feature that I want.

bensyverson 6mo ago

My opinion on "don't re-invent the wheel" has really shifted with these supply chain attacks and the ease of rolling your own with AI. I agree that I wouldn't roll my own crypto, but virtually anything else? I'm pretty open.

mpyne 6mo ago

> but there must be a healthy middle ground between that and a library that lets you pick font color. When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN. But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.

hgoel 6mo ago

I think we've pulled way too much towards "software must be a constantly maintained, living item, and users should update often", thus the recklessness with dependencies. This has also exacerbated the other aspects of dependency hell. But not only does this not match reality, it makes projects very vulnerable to this supply chain hijacking stuff. I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.

xmcqdpt2 6mo ago
From a purely aesthetic point of view, this is what I enjoy so much about C and Fortran. You look up a Rust crate and it hasn't been touched in 5 years. That means it's unmaintained and unusable, don't add it to your project or you will have a bad time. You find a C or fortran library that hasn't been touched in 20 years and (sometimes) it's just because it's complete and there hasn't been any reason to update any parts of it. You can just add it to your project and it will build and be usable immediately. I wish we had more of those.
- dgb23 6mo ago
  Clojure and Go are similar to this from my experience.

tristor 6mo ago

The only time I would agree with that is crypto. Don't roll your own crypto. Otherwise there's minimal downside to rewriting basic things directly, and often its unnecessary if your language has a complete standard library. The only place I feel differently is with something like C, where the standard library is far from complete, in that case it makes perfect sense to rely on many third-party libraries, however you should assess them for robustness and security.