[HN Gopher] Google discontinuing work on Dart macros
___________________________________________________________________
Google discontinuing work on Dart macros
Author : oltmang
Score : 65 points
Date : 2025-01-29 22:08 UTC (51 minutes ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| eseidel wrote:
| Former Eng. Dir for Dart, co-founder of Flutter, here.
|
| I'd like to believe this is a good thing for the Dart project,
| but only time will tell. My hot take here:
| https://shorebird.dev/blog/dart-macros/
| bloqs wrote:
| Thanks!
| elcritch wrote:
| Thanks, good take. Especially if some of the pieces are still
| being added.
|
| In my humble opinion, you can handle many cases like
| serialization better with 'compileTime' or comptime features
| though I'm partial to macros. Especially with core compile time
| constructs like 'fields' [1, 2]. Though those require some
| abilities dart's compiler may not have or be able to do
| efficiently. That'd be a bummer, as even C++ is finally getting
| compile time reflection.
|
| 1: https://nim-lang.org/docs/iterators.html#fieldPairs.i%2CT 2:
| https://www.openmymind.net/Basic-MetaProgramming-in-Zig/
| ElliotH wrote:
| This is good news. The dart language has been getting more
| complicated without corresponding quality of life improvements. A
| first class record object without messing around with macros
| would be a great start.
| msie wrote:
| Why is it that many languages, at the start, don't have support
| for records/plain structs?
| ajross wrote:
| Maybe it's time to just recognize that lisp-style macros-as-
| language-syntax features just aren't worth the struggle and
| grief?
|
| The big metaprogramming feature traditionally implemented in
| macros, type generation, is already provided in some form by all
| major languages already.
|
| And an awful lot (and I mean an _awful_ lot) of good work can be
| done at the string replacement level with cpp. And generating
| code upstream of the compiler entirely via e.g. python scripts or
| templating engines is a very reasonable alternative too. And at
| lower levels generating code programmatically via LLVM and GPU
| shaders is well-trodden and mature.
|
| Basically, do "macros" really have a home as a first class
| language feature anymore?
| thuuuomas wrote:
| In another world, macros could have filled the role that
| programmable yaml fills today.
| DiggyJohnson wrote:
| |- help me
| anothername12 wrote:
| Why is it that Lisp family macros are easy to implement and use,
| but not so in other languages?
| lolinder wrote:
| Are Lisp macros easy to use? My understanding was that Lisp
| code is notoriously difficult to understand if you didn't write
| it, largely because of the obscenely powerful macro system that
| makes it too easy to be too clever. Which is essentially the
| same complaint that everyone has about every macro system.
| db48x wrote:
| It's possible to do that, but in practice it's quite
| uncommon. Especially since Lisps offer great tools for
| programmers to learn what the macros that the are using
| actually do.
| fiddlerwoaroof wrote:
| I've been working with Common Lisp for about ten years now
| and I've never found that this criticism matches the reality
| of working on lisp codebases.
| behnamoh wrote:
| in Scheme you can redefine `define` to be number 5. Easy to
| implement, but a nightmare in real world scenarios [0]. That's
| why languages like Go became popular, they're trashy, boring,
| and dumb, but that's exactly what's needed in big projects.
|
| [0]: imagine your colleague wrote a macro that redefines for
| loops because at the time, it made life easier for him.
| codemac wrote:
| > in Scheme you can redefine `define` to be number 5.
|
| This is like asking "what if your coworker named all errs as
| `ok`" so everything was `if ok { return errors.New("Not
| ok!!"); }`. It's possible but no one does it.
|
| This is why `defmacro` and `gensym` in common lisp are
| awesome, and similarly why Go's warts don't matter. Much of
| programming language ugliness is an "impact x frequency"
| calculation, rather than one or the other.
|
| It's also why javascript is so terrible, you run into it's
| warts constantly all day long.
| lolinder wrote:
| "No one does it" is extremely relative. Take your closing
| remark about JavaScript: I don't run into JS warts very
| often at all, and I'm a professional web developer who
| works in it day in and day out. I guess my team just
| doesn't do dumb JS stuff?
|
| But apparently lots of other people do run into them
| regularly, so I believe that such things do exist.
|
| By the same token, I've heard countless reports of people
| struggling with the flexibility that Lisp offers, with co-
| workers who abuse it to create nightmarish situations. That
| you haven't experienced that doesn't mean no one does.
| dokyun wrote:
| Why is it that square pegs are easy to fit in a square hole,
| but not so in a round hole?
| _moof wrote:
| This is just my opinion but I believe it's because the syntax
| tree _is_ the syntax. In a Lisp macro you are working with
| lists, just like you are for any other Lisp code. Almost every
| other language I 've used (I've been programming since the late
| 1980s) has, at best, a special data structure to manipulate
| ASTs. So it ends up being quite unnatural. Lisp macros are just
| Lisp.
| Alifatisk wrote:
| What will the Dart team focus on instead? I wish the cross-
| compilation issue was taken to a higher priority, I mean Flutter
| already kinda of solved it.
| leecommamichael wrote:
| Good. Dart already has good support for code-generation. It would
| just encourage package authors and app developers to waste their
| time golfing.
| zigzag312 wrote:
| They should have just use C# for Flutter.
|
| Without investing significant time, like they did with Dart, they
| would have a language with a much bigger ecosystem that is
| faster, already has compile time code generation and better
| support for data than Dart. It supports ahead-of-time compilation
| and hot-reload. The only feature missing in C# is compilation to
| JS, but with WASM is that really needed? Biggest downside of C#
| is probably that it's not invented at Google.
| kernal wrote:
| And Microsoft should have just used Java.
| refulgentis wrote:
| And Java should have just been C++ with a really nice garbage
| collector
| donatj wrote:
| And C++ should have just been Objective-C with saner
| invocation syntax.
| zachrip wrote:
| Genuine question, is this comparison really apples to apples?
| Microsoft wanted to compete with sun right? Does google want
| to compete with programming languages like this? My gut tells
| me this is NIH not wanting to compete.
| refulgentis wrote:
| It is apples to apples.
|
| Microsoft didn't want to compete with Sun so much as have
| an application development language with a garbage
| collector that wasn't owned by Sun.
|
| You don't make much money off programming languages
| inherently.
|
| This also elides an obvious riposte (so you mean they
| should have just used Mono? how did all that work out?) and
| a metric ton of differences between what C# targets and
| what Dart targets.
| refulgentis wrote:
| Dart's awesome.
|
| I'm sure C# is too.
|
| I've been unlucky enough to have many years in on both iOS and
| Android, and Dart is a fantastic language, far better than both
| incumbents.
|
| I worry about judging it as a whole, based on their ability to
| launch pre-compile time code generation that is faster than
| their current approach.
|
| Macros seemed really cool + really difficult to improve past
| the current codegen.
|
| I have a 35K LOC "main" code base that generates _670K_ lines
| of code under the current approach. It takes 52 seconds for a
| cold generation of all 670K. _shrugs_
| jcstk wrote:
| FWIW, I enjoyed the hundreds of hours I spent with dart:mirrors
| to automate serialization, and the code-generation heavy approach
| always felt like kind of a bummer. But I feel like AI-assisted
| programming solves the majority of use cases this feature was
| meant for.
| mindwok wrote:
| I always feel better about the stewardship of a project when you
| see a thoughtfully written reason for saying no to a feature,
| especially when there's already sunk cost. Props to the team.
| lutherqueen wrote:
| Perfection is achieved, not when there is nothing more to add,
| but when there is nothing left to take away
| mdhb wrote:
| I think after reading through the blog post the reasons they have
| made a whole lot of sense and sounded like that of a mature
| engineering team to me.
|
| There are a bunch of other interesting approaches here they can
| look at. Improving the code generation story more generally,
| shopping the augmentations feature (basically C#'s partial
| classes) and getting more serious about serialization all feel
| like sensible directions from here.
|
| There is a really interesting community proposal at the moment on
| the serialization front that I think would solve a lot of the
| issues that got people so excited about macros in the first place
| here: https://github.com/schultek/codable/blob/main/docs/rfc.md
___________________________________________________________________
(page generated 2025-01-29 23:00 UTC)