298
C++ takes decades to master (thelemmy.club)
submitted 3 months ago by to c/programmer_humor@programming.dev
85 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 6 points 3 months ago* (4 children)

I've been a long time believer that some problems are better solved via OOP, others through functional programming. The perfect language would be a successful blend of the two.

Many popular OOP languages are horribly lacking on FP or it looks like an eyesore (golang, python, etc). ...and FP languages trying to do OOP are kinda awkwards (see common-lisp).

I thought Crystal Lang (a statically type checked dialect of Ruby) was going to be the "perfect language"... but the compile time performance and the lack of 3rd party libraries (like an aws SDK) really made it hard to use.

Hearing what you said about Rust has renewed my hope.

That said, I did notice that features like Coroutines have been "experimental" for nearly 9 years.

I hope I'm missing something obvious, but how would you create any sort of heavy-lifting, long running, multi-session daemon/application without having some sort of asynchronous mechanism that goes beyond threading (which is limited to the number of cores the host machine is running).

edit: cleaned up a few thoughts (prematurely hit submit)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 5 points 3 months ago* (last edited 3 months ago) (1 child)

    I don't think there's an std-way of doing it, but the Rust ecosystem has this thing where people usually settle around one library. In this case, it is tokio. Afaik, most async stuff is done using tokio. What little async I've used, it's been using tokio or some library like actix-web that uses tokio under the hood.

    Also, side note, I never understood the idea of why golang is ugly. I think it's fine, except for maybe the repeated if err != nil guards. Those are ugly. I wish it used additive types for error handling.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 9 points 3 months ago (1 child)

    As a passionate Golang hater, I can gladly explain!

    • It's not just the repeated if err != nil, even though that's already bad enough. But the really fucked up part is the := bullshit. It makes moving code around unnecessarily annoying, and it's telling that few other languages share Golang's approach.
    • The lowercase/uppercase rules for private/public stuff is theoretically not a horrible idea, but it makes the code look much more inconsistent. I find _ much easier to read, and this leaves upper/lower to signal other details. But I see that this is mostly personal preference.
    • Fairly basic operations take much, much more code than they should (e.g. deserializing JSON while handling extra args, or basic functional operations - though that should change sooner rather than later with the new generic methods, right?)
    • The decision to initialize every non-pointer primitive with the "bottom value" (or whatever it's called again) makes sense in isolation, but it's really unfortunate that they don't support additive types, because this means a bunch of common tasks need to use pointers, and unfortunately the type system is worthless when it comes to preventing segfaults caused by bugs with pointers.
    • I find that most Go libraries have basically no documentation, if you're lucky you get an example that might vaguely be related to whatever you want to know. I've had much better experiences in other languages.

    All in all IMO most Go code is 5x longer than necessary to actually express itself in a readable manner, all because the language still doesn't have proper error handling or generic support (until recently at least). At the same time it's fairly inflexible, the type system is still shallow and basic, and it's still way too easy to shoot yourself in the foot.

    The only good thing Go has going is the single file deployments, but I'll gladly spend one hour of every remaining day of my life setting up containers, if it means I never have to touch anything Go again.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 months ago

    Fair enough. I'm not a professional programmer, so I guess I won't understand your frustration with long term maintenance of Go code. I do agree that it can be unnecessarily verbose. Writing something as simple as an http server takes a long time. Also, the dependency management sucks. It can't seem to decide if it wants to be declarative or not.

    I do like that it's dead simple though, and that the standard library has most of the basic stuff. I've mostly replaced the need for Python with Go, for small CLI apps. Nowadays, I only use Python when I have to use some specific library, mostly for mathematical computing.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 3 months ago

    some problems are better solved via OOP, others through functional programming. The perfect language would be a successful blend of the two.

    That was the entire goal of Scala and I would say Scala both accomplished it and is a worse language for doing so. Some OOP principles are just bad, namely subtyping. Rust genuinely does blend OOP and Functional in a better way. Instead of classes and interfaces with lambdas you have algebraic data types and type classes with for loops.

  • permalink
  • fedilink
  • source
  • parent