I'd kill for a port of the .Net Entity Framework to JavaScript - the current ORMs for JavaScript are really nothing compared to EF.. If you haven't used it, it is super powerful at selecting super complex structured data from a database super easy. :) It's query format is also the linq standard so you use the same extension methods to work with in-memory collections as you do with database tables.
Ent: An Entity Framework for Go
31–40 of 68 posts
Re: Ent: An Entity Framework for Go
#32I'd kill for a port of the .Net Entity Framework to JavaScript - the current ORMs for JavaScript are really nothing compared to EF.. If you haven't used it, it is super powerful at selecting super complex structured data from a database super easy. :) It's query format is also the linq standard so you use the same extension methods to work with in-memory collections as you do with database tables.
Do you have a link that quickly expresses the gist of what makes Entity Framework good/powerful? I tried using it in college for a little project, hit the docs like a brick wall, and went back to Rails. I always struggle “getting to the good parts” with Microsoft’s stuff.
Re: Ent: An Entity Framework for Go
#33I think Ent for Go has a ton of potential. Although I haven’t used this library, I have spent a lot of time studying the design space of ORMs because I’m currently iterating on an internal library that does ORM-like things at Notion. I really like the Ent approach because it allows working with a graph-based data model directly in the embedding language, instead of forcing developers to learn a new query language lik…
> 1. Codegen is powerful, and often easier to understand than a mountain of typelevel magic. I disagree here. And I also don't like your framing. Yes, type-level logic is harder to learn than understanding code you already read everyday. It's also easier to count and calculate with your fingers and use concrete examples rather than learning abstract math. But we still do it, because in the end you learn it once and h…
> But we still do it, because in the end you learn it once and have a powerful tool that makes you more productive for the rest of your life and allow you do to things that you otherwise would never have been able to.
Your own words are apt: I disagree here. And I also don't like your framing.
> Go has more inexperierenced developers using it compared to other languages. But over time, they will turn into experienced developers. They learn more concept and want to become more productive. So they will gradually ask for more and more features until Go is nothing like it was before.
Ignoring the rest of your comment, as well as the possibly snide remark regarding the experience of engineers who use Go, I believe this neither reflects reality nor the reality I wish to participate in.
Go eschews complexity, and is particularly paranoid of complexity sneaking in under the guise of convenience. Productivity is rarely hindered by having to hand-write a for-loop or some boilerplate to handle errors.
Go is designed to be easy to read and easy to write, to be comprehensible by both green and sage developers, and most importantly maintainable. This means preferring explicit behavior over implicit magic. The toolchain prioritizes fast compilation times over aggressive optimization.
I don't write Go to be productive (but I am very productive). I write Go so everyone can be productive. I don't want anyone spending time unraveling your life's work masterpiece. I don't want anyone to ever have to understand Scala or Haskell.
It's cool that you feel it necessary to reach for more powerful, expressive language constructs to be productive. I do not.
Re: Ent: An Entity Framework for Go
#34Earlier quoted context omitted.
> 1. Codegen is powerful, and often easier to understand than a mountain of typelevel magic. I disagree here. And I also don't like your framing. Yes, type-level logic is harder to learn than understanding code you already read everyday. It's also easier to count and calculate with your fingers and use concrete examples rather than learning abstract math. But we still do it, because in the end you learn it once and h…
None of the industrial languages I’ve looked at (Kotlin, Typescript, Go, Java, Swift, Rust) can do the things I want to do using only typelevel features, especially at practical scale. Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. Often in Java/Kotlin projects people end up writing compiler plugins / annotation proce…
The other benefit of codegen in situations like this (a company wide schema) is the potential for multi language bindings. Entgo demonstrates this by bridging a Go ORM, SQL migrations and a GraphQl schema.
Interesting reading along the same lines is Language Oriented Programming (1994) http://www.gkc.org.uk/martin/papers/middle-out-t.pdf
Re: Ent: An Entity Framework for Go
#35> 100% statically typed and explicit API using code generation. Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. It's annoying to inspect and maintain and usually has quirks that I have to work around. How do Go developers feel about that?
> Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code.
A good use of code generation is to relieve yourself the burden of hand-writing repetitive mapping code, especially when modelling the database structure in application code. This is a perfect use case for that. Same is true for generating a client to some external API.
Otherwise I'm inclined to agree with you. A few times, I've written code generators before and realised I could've gotten away with some generic programming.
But that has its own set of gotchas and caveats. Though go has support for some generic programming now.
Re: Ent: An Entity Framework for Go
#36I'd kill for a port of the .Net Entity Framework to JavaScript - the current ORMs for JavaScript are really nothing compared to EF.. If you haven't used it, it is super powerful at selecting super complex structured data from a database super easy. :) It's query format is also the linq standard so you use the same extension methods to work with in-memory collections as you do with database tables.
Do you have a link that quickly expresses the gist of what makes Entity Framework good/powerful? I tried using it in college for a little project, hit the docs like a brick wall, and went back to Rails. I always struggle “getting to the good parts” with Microsoft’s stuff.
Microsoft documents are generally fairly good. I haven't touched much .Net these last 10years but i believe that it took at least EF6 in the original .Net framework to have the main good stuff and be productive, add the core version to the confusion...Latest few core versions should be good as well.
Re: Ent: An Entity Framework for Go
#37Earlier quoted context omitted.
Do you have a link that quickly expresses the gist of what makes Entity Framework good/powerful? I tried using it in college for a little project, hit the docs like a brick wall, and went back to Rails. I always struggle “getting to the good parts” with Microsoft’s stuff.
Microsoft documents are generally fairly good. I haven't touched much .Net these last 10years but i believe that it took at least EF6 in the original .Net framework to have the main good stuff and be productive, add the core version to the confusion...Latest few core versions should be good as well.
“Go read the docs” is not helpful! I tried that 8 years ago based on HN sentiment about C# and my experience with the Microsoft docs was that they are very detailed but the level of detail makes it difficult to quickly pick up what it’s like to actually use one of their thingies. I walked into the docs for Entity Framework, spent 6 hours trying to get Visual Studio and their suggested development database set up, then gave up and went back to Rails which took 1 apt-get command and 2 Ruby commands.
Re: Ent: An Entity Framework for Go
#38How would this go as a Django replacement? I still use Django for new projects, but find that I end up just putting a GraphQL API on top of the Django ORM. At face value, Ent seems to tick both those boxes, but with the efficiency of a compiled language.
Re: Ent: An Entity Framework for Go
#39How would this go as a Django replacement? I still use Django for new projects, but find that I end up just putting a GraphQL API on top of the Django ORM. At face value, Ent seems to tick both those boxes, but with the efficiency of a compiled language.
I have no experience in Django but in Ent with GraphQL.
Ent is not a full-featured web framework so you need to implement many of features by your own or use other libraries (e.g. http server and session management).
If you are only looking for ORM + GraphQL then I highly recommend trying Entgql, an Ent extension for GraphQL with Gqlgen library [1]. Once you define an ORM schema, it will generate GraphQL Query for Relay server. Still you need to implement GraphQL Mutations by your own but at least it will create Input types for you (both for Create/Update).
Re: Ent: An Entity Framework for Go
#40Hey @thunderbong
One of Ent's maintainers here. Thanks a lot for sharing our project.
To all others interested, Ariel (a8m) and I are here following this thread, so feel free to ask us anything and everything!