11 ms·

Cool project, but this project demonstrates the reason I've stopped writing things in C. The standard library has garbage string functions and it seems every pr

• xmonkee 3y ago
  I have the same issue, but I blame the absence of good package management. If it had that, one of the thousands of these libraries would have won out and become quasi-standard.
  • le-mark 3y ago
    I always thought the glib part of gtk was really nice for this, but adoption is spotty at best.
    • ranger_danger 3y ago
      glib is a massive dependency just for this, and I think many would argue that gtk in general is not a good idea for painless cross-platform development in 2023.
• alex_lav 3y ago
  This is how I felt writing Go. Writing the same nongeneric functions with slightly different type signatures and/or endless interfaces and/or interface{} signatures. It's 2023.
  • 2h 3y ago
    never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right? and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.
    • vore 3y ago
      Many people don't need generics? Significant runtime cost? I would argue that everyone should be using type-safe collections like maps, lists, etc. (I know these are built into the language in Go, but they're basically special-cased generics). And, if anything, not having generics has more cost because you end up boxing your values to place into collections rather than letting the compiler monomorphize it. The compilation cost can be more expensive, yes, but it saves a lot of work you would be doing by hand. While Go has had generics for a while now, the vast swath of existing Go code doesn't. The situation is definitely improving but there is still a lot of non-generic legacy cruft.
      • 2h 3y ago
        > you end up boxing your values to place into collections rather than letting the compiler monomorphize it. you know that Go has interfaces right? and I dont just mean the "any" interface. you can write your own interface similar to io.Reader and others, then add types that implement that interface, then no type matching is needed. > non-generic legacy cruft AKA normal, fine code. generic code is not some magic pixie dust that makes bad code into good code. plenty of awful bloated slow generic code around as well.
        • emodendroket 3y ago
          What kind of argument is this? Nobody says it’s “magical pixie dust that makes bad code into good code.” It’s a way to avoid writing repetitive code over and over and the runtime cost can be insignificant depending on implementation.
        • vore 3y ago
          If you are using interfaces, the value is necessarily boxed as the storage for the value may be heterogeneous. Once a value is typed as e.g. `io.Reader`, dispatching to its methods necessarily requires a vtable lookup (i.e. runtime cost!). Compare this to parametric polymorphism where you can avoid the type erasure and perform static dispatch at compile time. Though, unfortunately, Go's implementation of generics ("GC shape with stenciling" instead of full monomorphization) still ends up incurring some runtime cost. With regards to your second point, there are definitely situations where generics are vastly preferred: type-safe collections being a big one. For instance, the standard library containers (https://pkg.go.dev/container https://pkg.go.dev/container) are still non-generic with no generic versions in the standard library yet. This is the kind of cruft I mean: generic collections can be turned into concrete collections with type safety, but not the other way around. I make no claims about use of generics making your code being absolutely good or bad, but I do make claims that use of generics can make your code less error-prone and more safe.
  • earthboundkid 3y ago
    You know Go has had generics for the last 15 months, right?
    • alex_lav 3y ago
      Yep! Why?
• dajtxx 3y ago
  I know it's not your code, but related to this comment, it looks like it missing a check for lks == null? https://github.com/robdelacruz/lkwebserver/blob/main/lkstring.c#L47 https://github.com/robdelacruz/lkwebserver/blob/main/lkstrin...
  • denotational 3y ago
    That assert is checking a library invariant; it should never fail unless there’s a bug in the string library itself (although I’m not entirely sure this string library would tolerate a malloc failure from a quick glance through). This is distinct from checking the parameters; if lks is null then the user of the API has made an error. Some libraries may sanitise user parameters, others don’t. At any rate, an assert would be the wrong choice to check user parameters since this would result in a (recoverable) user error leading to an abort unless the assert is disabled at compile time (-DNDEBUG), returning an error would be a better choice.
    • gpderetta 3y ago
      assert is an acceptable way to deal with precondition failures.
  • robdelacruz 3y ago
    Thanks, much of the asserts were scaffolding while I was programming the helper functions. They function similar to comments, reminding me of the internal conditions that should always be valid.
• userbinator 3y ago
  That's the "lazy, dumb" way of doing it --- write another string library. A much better way is to design your algorithms so they need a minimum of string manipulation, which is unfortunately on the more difficult side for text-based protocols like HTTP. Personally, I wish HTTP messages were closer to something like ASN.1 DER; there's little in the way of string manipulation necessary for those, and all the lengths are prefixes instead of "try to find the terminator" (and don't forget to not run past the end of the buffer...)
  • jeremyjh 3y ago
    Peak HN right here folks. Pack it in we are done.
    • favorited 3y ago
      Impossible– no part of the thread has involved someone suggesting rewriting it in Rust, which means there's no opportunity for someone else to reply "This project seems like a perfect fit for golang, why would you suggest they use Rust instead?"
      • earthboundkid 3y ago
        I could write this thread in an afternoon.
        • tomcam 3y ago
          Deep cut! For newer HN users, that's a reference to this comment responding to the original DropBox announcement. https://news.ycombinator.com/item?id=17732980 https://news.ycombinator.com/item?id=17732980
  • jerrysievert 3y ago
    or just parse in place: https://github.com/celcius-labs/tiny-http/blob/master/src/http_request.cpp https://github.com/celcius-labs/tiny-http/blob/master/src/ht...
• krapp 3y ago
  >It's fun to write this (and read others' versions) the first 3 or 4 times, but it gets old quickly. I mean, you can always just use an existing string library or reuse your own. There's no reason to rewrite string operations for every project.