I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to say, I definitely see how it can be disliked and I also disliked it when I started working with it but it definitely grew on me.
> It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages.
Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.
I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/
This might not be obvious in anyway if you’re not pretty deep in the Dart ecosystem but I’ve never seen anyone pay as much attention about building a good long term language as that team.
They put crazy amounts of thought and effort into how they evolve it.
Their entire strategy as far as I know was to intentionally aim for “boring and predictable” so that no matter how large or complicated your application got that you would never outgrow it.
Then they built a bunch of really nice tooling and DX on top of it.
It’s genuinely a pleasure to work with in my experience.
I was enjoying the frog book (The Dart Programming Language, Gilad Bracha & Erik Meiker) but that was 2015, and now very out of date. Its strange to see there is no up to date book from major publisher, like the Rust book at https://doc.rust-lang.org/book/
The incentive structures around technical books are pretty weird.
Most major publishers pay quite small royalty rates, so even a popular tech book won't actually make the author much money. And the effort to write a good technical book is pretty huge. Also, the set of people who will actually finish writing a book is quite a bit smaller than the set of people who aspire to. (An editor at O'Reilly told me once that only about 1/3 of the authors they sign deals with actually end up finishing the book.)
So for a book to appear, you need to find someone who:
1. Knows this particular topic in depth.
2. Is interested in spending a lot of time writing a book about it.
3. For relatively little money in return.
4. And actually has the discipline to finish it.
Not a lot of people in that set. It's also particularly hard for technologies that are in flux since the quicker the book gets out of date, the less value there is in writing it.
Former O'Reilly editor here: story checks out. The 1/3 might be a bit low -- I had some surprises (one guy joined the Peace Corps and moved to South America, plus usual divorces and deaths and job changes) but it felt more like 80% completed. This might be the rosy glasses of memory, though.
There's also a weird difference in incentive between writing the first edition and working on updates: if the author was just after "I wrote a book!" then they already have that, and won't be so interested in updating.
If they were made famous and now have a lot of work as a result of the first book, they may not have time for it. It's quite the delicate dance to get someone else to update the book: without the update, sales will drop, but 1st edition authors feel weird giving a lot of their (not sizable) royalties to someone who didn't write most of the text.
That is fascinating. As someone who has writing a technical book as a life goal, I'd love to ask--do you have any insights you'd be willing to share regarding how to get started?
Are you already blogging? If not, I would start doing that. Writing short form technical articles and sharing them is like bootcamp for longer form writing. You'll learn the mechanics of organizing thoughts into a linear narrative, the discipline to finish, and you'll get feedback from readers about what works and what doesn't.
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
Alternative to (3) - Company that owns a language and is willing to pay decent money for someone qualified to write a book in order to increase popularity
Yeah, this is viable, but the cost is quite high if you're paying a skilled software engineer for their time. The company driving the language can probably spend that budget better elsewhere. (For example, on online documentation that is more easily incrementally maintained and grown.)
Picking it up is really easy if you have any experience with Java or C# and the QOL improvements compared to the former make it seem like a treat for me. What language are people who hate it coming from?
