I do agree that personally I don't like using big frameworks. My personal favourite is the express architecture: a thin substrate that allows for middleware plugins to be installed and not much else beyond that.
I've also come to really appreciate a good standard library. I used to POC things in node because it's so simple, but the dependency tree is hard to justify.
I do like Rust's stdlib too, but its a different tool for a different project. My issue with Rust is the refactor cost when it needs to change.
Not sure who to believe. :-D
This might have been a long time ago but I can't think of much that you cant do. I've seen this behavior though on some project, but it was usually not about the stdlib's deficiencies but more so the developers lack of understanding what they're supposed to do and so revert to another lib.
That’s an interesting take. I’ve heard it before but I believe the opposite. For me, Rust is much easier to refactor.
Like, try to build dynamic nested ands with ors using jsonb with gorm. Maybe there are two people on this planet who would like “aha, I know”. Just use your standard sql strings with prepared statements.
You can write your own or you can use someone else's. Those are the two choices.
That doesn't mean you need an entire system to represent every table as an object-like thing (which is what I assume when people say ORM). It's actually possible to just emit queries to read and write the exact data that's required in the shape that makes sense for the caller.
The minute you add relationships your approach becomes unusable.
There is a reason ORMs have persisted for over 30 years.
Congratulations, you've invented an ORM.
But then it's nice to have something that generates optimised, database-specific SQL, can handle date/number conversion, supports many-many relationships, converting BLOB to binary streams etc.
Source: Wrote an ORM that other people actually use. Still adding features, twelve years later.
An ORM library maps an entire relational database to a graph of objects, with the intention of abstracting away the relational database. Copying query results to structs doesn't actually do any of that.
https://en.m.wikipedia.org/wiki/Object%E2%80%93relational_ma...
And db updates are either relations or tuples (and a tuple is a relation with cardinality of 1, so...)
If copying query results to a list of structs is enough to qualify as an ORM, then the term is so generic as to be entirely useless.
Mine doesn't, so I don't need an ORM. Plus, I think that when people say ORM, they mean more than just a map from the relational model to the object model and back. They refer to things like hibernate and SQLAlchemy and all the extra stuff that comes with that, like the active record antipattern, and a query builder which successfully encapsulates all trivial queries (which don't need encapsulation) but then as soon as you need to do anything even remotely complicated, the abstraction leaks. I'll be honest, not a fan of ORMs.
I've been using Go recently, and while I'm not convinced on an active-record style ORM in Go (I don't think the language is dynamic enough, and I'm not the biggest fan of codegen), I've been loading the row data from Postgres into a Result struct (pretty much a 1:1 mapping of the Postgres result set into the struct), and then using another function to load the Result struct into struct with their relationships attached (using tags on the structs to define the relationships between them). This has worked great using reflections & generics.
I’m building something similar and I can’t decide on the relationship struct tag syntax to use. Would be neat to see how others are thinking about it.
Every language need to deserialize results into some object so by definition every language that deal with a DB do some form of ORM. So ORM is meaningless in that context.
The System.Drawing namespace at least as of .NET Framework 4.5 required virtually all of its operations to be done through a System.Drawing.Bitmap, which meant that no matter how your image data was represented, it needed to get rasterized. This wasn't a big deal for most desktop/local use cases, but it's very inefficient, so if you had any servers relying on this, and had a reasonably decent amount of traffic to those servers, you could be getting CPU usages way too high.
As an example, I remember one time we were hosting 30 kb TIFF images (high res, 1 bit per pixel) for download, and generating the thumbnails was done in real time, which caused literally gigabytes in memory churn per request due to the rasterizations... IIRC I fixed it by using emscripten (this was 2015-2016) to do resizing and rendering in the frontend with a small C module using LibTIFF, then the server only needed to send the 30 kb files as is. Unfortunately I've had a hard time finding people to work with these days that give me that kind of room to execute.
Does Go's standard library have these rough edges or is it actually pain-free? I'm on the fence about whether I should learn Go or Rust while I am on a short employment break.
As for this question, > I'm on the fence about whether I should learn Go or Rust while I am on a short employment break.
What are you learning the new language for? If for fun, then this question is longer. If for employment, I would bet that there are more devops, devops adjacent and "systems developer" roles in the Go language.
When you have an insufficient stdlib, you often get compatibility issues, where things don’t compose. So you get these kind of pseudo-std mega frameworks like Tokio instead. It was a while ago I was deep in JS but I remember similar things there.
I will say that I do prefer Gorm only to be used to scan the table -> model, I'd still rather write the sql by hand but I also don't want to scan the rows every time. But other than that I really cannot think of what it's missing.
Having to explicitly handle every type of error immediately without any support for deferring, encapsulating, chaining, manipulating, transforming etc is antiquated and tiresome.
Rust has Option and Result types and all of the niceties along with it.
Rust has all those nice things and yet you still need to import two of the most popular error lib to work decently.
And in Rust you don't need to import anything.
var cursor int64 = 0
for {
rows, cursor, err := db.PaginatedRows(cursor)
...
}But, to be honest to myself, I don't think anything will be too different in my day-to-day programming, nor that I would produce better code with less bugs.
Odin[1] is a better alternative in the niche modern language space, and also shares many design choices with Go. It has operators like `or_return` and union types like `Maybe(T)`, which can in practice be used for improved error handling.
Though I honestly don't find Go lacking in this sense. The syntax is a bit verbose, but it forces you to think about how to handle every error, which is a good thing. There are far more important design topics worth discussing than this. Go usually makes more correct trade-offs where they matter compared to other languages, and most of the criticism it receives is unwarranted IMO.
I mean, kudos for sticking to it over the years in spite of the mountain of criticism, but I personally confirmed a few months ago that it's indeed half-baked. :) Certain features work sometimes, but often fail in cryptic ways. The documentation is a mixture of missing, outdated, wrong or aspirational. I've forgotten the specifics, but I remember being frustrated by it relatively quickly, and abandoning it altogether in less than a week. Good luck with it anyway!
Anyone taking a serious look at Odin or C3 (strangely morphed from C2 into being more Jai-like or Odin-like), will know they are both no where near to being production ready or 1.0 (many years far away), despite both being old. Odin has less of a following, less contributors, minimal documentation, no books on Amazon, and many of its good ideals were admittedly "borrowed" straight from Jai. Many consider Odin a Jai-clone, where it would be better to wait on the "real McCoy", which would be Jon Blow's releasing of Jai to the general public. Jai fans[1] are about as hardcore as it gets. When Jai is finally released, nearly everybody will forget about Odin or C3 (even tsoding suggested dropping it for a public release of Jai), and very few people even know about them as it is. Just about whatever Odin (or C3) wanted or aims to do, Jai does.
[1]: https://jamesoswald.dev/posts/jai-1/ (Simplicity, Jai, and Joy)
[1]: vlang.io
Forgetting to check any given err value leads to potentially undefined behaviour.
But yeah, when you're building some kind of internal service with a classless CSS library that's just meant to provide some kind of dashboard to illustrate the state of your service, Go's stdlib is more than good enough and helps keep down long-term maintenance, everything will Just Keep Working.
I struggle to see where Rust fits in for web frameworks. You get the dependency tree explosion, the long compile times, difficulty collaborating with Frontend/UX. The benefit is, what, better performance? Is it really worth it?
Go is a perfect language when dealing with files or network. Once you add database layer, calling external APIs, then you face the same latency of other languages due to 3rd party integration.
Not only it is important for fast iteration, but it also contributes to the fun, waiting for compiler to finish is not fun
To me there shouldn't be any new language made without hotreload and incremental compilation
It's 2024, with the HW we have, we shouldn't have to wait more than 1 second to compile code
Fun fact, my game written in D (30k LOC), fully recompiles in 0.4 seconds (Intel i3 10400f), if i can do it, you can too
This avoids depending on a complex framework that may or may not exist in a few years, improves security by minimizing the amount of 3rd party dependencies, keeps the learning curve low for any new developers joining the project, and is more flexible and easier to maintain. I don't have experience with Rust, and judging by the comments here, web frameworks might still be useful for it. Which is a shame, since the batteries included stdlib approach is far superior IME.
Anyway, I don't want to shoot down your efforts. Congrats on the launch and good luck!