111–120 of 125 posts
Earlier quoted context omitted.
I think you are missing the fact that Dart is actually an incredibly nice language to work with in a way that Go absolutely is not.
The problem is that it’s yet another language. It’s the cognitive load and the inability to easily reuse code across a project.
Earlier quoted context omitted.
Oh how I enjoy trying to compile and use projects where they use some complex home brew codegen system often written in a different language entirely [1]. Luckily they often use Python as part of some core build step which never breaks compatability in their regex librwry [2]. Yes macros can be a pain and should be limited, but in my experience, a couple hundred lines of macros replaces many thousands of lines code g…
Bad code is bad code, but FWIW every time I've seen something that actually needs a "complex home brew codegen system", it's absolutely best expressed in a dedicated piece of software engineering and not within a macro environment. Zephyr leans heavily on that kind of engineering, actually. The point is really that "macros" is a weird sandwich between "complicated metaprogramming you need to do from first principles"…
I'd definitely agree with you about Zephyr's "I really want C macros to be real macros" system for it's device tree system. It's a huge pain to debug because you don't find issues until the linking step. However I'd counter with the fact that C macros _aren't_ real macros. Hence the pain.
Actually C's "macros" are literally just a separate codegen tool (m4 processor) just like what you're suggesting. It's a large part of what makes C code so hard to programmatically parse or automate.
Essentially Zephyr is doing meta-programming in an external codegen tool. Totally agree that a separate codegen tool specifically for device trees or whatnot could be better than that. However if C had a proper macro system (and compile time types), you could readily express the device tree system in the language at compile time and produce helpful errors.
> The point is really that "macros" is a weird sandwich between "complicated metaprogramming you need to do from first principles" and "you really didn't need metaprogramming, did you?". And that over the years that sandwich has been getting thinner.
They aren't really though. Homebrew codegen systems are much more of the weird sandwich between "you needed metaprogramming" and "you didn't have metaprogramming". Instead you build a system which is even more complicated in total, e.g. source and generated code gets out of sync, you have name clashes, the core API logic is spread out over different languages and code bases, etc.
Though I do agree the use cases for macros are shrinking, but more due to meta-programming via templates and compile time expressions becoming more powerful and usually preferable method to doing meta-programming.
Earlier quoted context omitted.
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…
MS wanted to fracture the Java ecosystem. The Microsoft Java VM was an attempt to lockin developers to MS Java and not sun Java. They created J# and C# because of the sun lawsuit they lost. They still wanted a Java like ecosystem but they would be sure it only ran on Windows servers. MS spent years being hostile to open source software. It's only in about the past decade that they've turned a corner. Here's a famous…
Hi, I work on Dart and was one of the people working on this feature. Reposting my Reddit comment to provide a little context: I'm bummed that it's canceled because of the lost time, but also relieved that we decided to cancel it. I feel it was the right decision. We knew the macros feature was a big risky gamble when we took a shot at it. But looking at other languages, I saw that most started out with some simple m…
Due to AOT compilation, some form of (pre)compile time code generation is needed, but it doesn't need to be macros. It doesn't need to be instantaneous, but it also shouldn't take minutes.
Adding features directly into the language removes the need for some code generation.
Augmentations will already make code generation much nicer to use.
build_runner needs to become more integrated so that IDEs would read build_runner's config and run it automatically.
Hi, I work on Dart and was one of the people working on this feature. Reposting my Reddit comment to provide a little context: I'm bummed that it's canceled because of the lost time, but also relieved that we decided to cancel it. I feel it was the right decision. We knew the macros feature was a big risky gamble when we took a shot at it. But looking at other languages, I saw that most started out with some simple m…
Sounds like performance is the biggest issue. I'm guessing the macros need to run after every keystroke. That creates big time constraint that while nice it's not really needed. Due to AOT compilation, some form of (pre)compile time code generation is needed, but it doesn't need to be macros. It doesn't need to be instantaneous, but it also shouldn't take minutes. Adding features directly into the language removes th…
Earlier quoted context omitted.
[Flutter founder here.] I'm pretty sure we did look at C# (and certainly a whole bunch of other languages). I don't actually recall why we didn't use C# at the time. I remember Go binaries were waaay to big, JS (what we originally wrote Flutter in) startup time was way too slow on iOS, Swift was too deeply tied to Apple (the standard library was closed source at that time), etc. It's possible that C# was too verbose…
I'm not going to log in to Xitter to read the rest of his tweets, but it doesn't seem like Miguel regrets using C# or is particularly in love with Dart. He's very complimentary of the goals and governance of Flutter, which is certainly more important than a language choice between two respectable languages. I do think C# is by far the best mainstream language, but good IDE support and library ecosystem are the dealma…
Earlier quoted context omitted.
C# is a fantastic language that has, in recent years, evolved very quickly for the better. Nice mix of object and functional drawing a lot of influence from F#. It shares a lot of language constructs with TypeScript (and by extension, JS) and has been converging with each release so I'm often surprised that people hate on it or that more startups don't reach for it if they are on Node with TS. Same syntax for key lan…
The improvements are great for people who have to or want to use C# for whatever reason? But how does that move the needle from other tech-stacks that are for more capable, especially on non-Windows environments (and please don't imply that C# is truly cross-platform, it's fine for web API's, it's not fine when dealing with actual system calls). If you're within the Windows garden, those tools certainly make sense to…
https://developers.redhat.com/blog/2016/09/14/pinvoke-in-net...
https://developers.redhat.com/blog/2019/03/25/using-net-pinv...
> without much technical clarity in what it brings to the table that's lacking in other ecosystems
What other GC language offers such levels of both high level expressiveness and low level control and also has a big ecosystem?
Earlier quoted context omitted.
I'm not going to log in to Xitter to read the rest of his tweets, but it doesn't seem like Miguel regrets using C# or is particularly in love with Dart. He's very complimentary of the goals and governance of Flutter, which is certainly more important than a language choice between two respectable languages. I do think C# is by far the best mainstream language, but good IDE support and library ecosystem are the dealma…
I think C# is just too associated to .Net like how Ruby is tied to Rails. Plus it's a Microsoft managed language, and if you're looking to move out of JS / TS, then you probably don't trust Microsoft's management of languages...
There is also a greater selection of IDEs and LS's.
Earlier quoted context omitted.
> I think they should try to come with a faster codegen, maybe write it in c++ or rust and fix these problems Language execution speed isn't the fundamental blocker for code generation in Dart. Dart isn't quite as fast as C++ or Rust, but it's in roughly the same ballpark as other statically typed GC languages like C#, Java, and Go. The performance challenges in code generation are more architectural and are around c…
I belive there are many low hanging fruits to improve the speed. In my project the code generation took more than 3 minutes. This is rather annoying if you have just renamed a field in a single “freezed“ class. We could speed up this process by 3x by hacking together a script which greps all .dart files for the relevant annotations like “@freezed“ and then only feeds those to the build_runner via a on-the-fly-generat…
Earlier quoted context omitted.
> I think they should try to come with a faster codegen, maybe write it in c++ or rust and fix these problems Language execution speed isn't the fundamental blocker for code generation in Dart. Dart isn't quite as fast as C++ or Rust, but it's in roughly the same ballpark as other statically typed GC languages like C#, Java, and Go. The performance challenges in code generation are more architectural and are around c…
I belive there are many low hanging fruits to improve the speed. In my project the code generation took more than 3 minutes. This is rather annoying if you have just renamed a field in a single “freezed“ class. We could speed up this process by 3x by hacking together a script which greps all .dart files for the relevant annotations like “@freezed“ and then only feeds those to the build_runner via a on-the-fly-generat…