d2p

There are lots of details about what we're rewriting any why that aren't really relevant to this discussion.

I'm (we're) not against 3rd party libraries; but we'd like to minimise our use of them because we're constantly bitten by poor libraries introducing breaking changes or being abandoned. I'm sure anyone that has worked on a huge codebase over a long period of time has been bitten in the same way. We certainly don't want to rely on 3rd party libraries for something so fundamental (and the absence of it from the Dart Team only makes us more concerned).

I wrote a blog post some time ago:

http://blog.dantup.com/2014/05/web-development-sucks-and-its...

And while responding to comments, I read a little more about Dart and it started to look quite appealing. I spend too much of my day maintaining and debugging legacy JavaScript written years ago in sub-optimal ways.

I tried to use protobuffers, to find the protobuffer library doesn't work on Windows.

Many products are > 1m LoC. I never said those 1m LoC are in one file (or even one repository).

Does this not sound like a rather complicated thing for the individual developers to do when 99% of Dart web apps will need to do this?

This is invented complexity; there is no need to support this in order to satisfy the majority of requirements.

Just because requirements can be made complicated doesn't mean there should be no support for something simple.

The built-in .NET JSON serialise is very limited; and there are third party libraries (even used by MS themselves for ASP.NET) to address that.

I'm sorry if it sounds like I'm being a dick; but I'm incredibly frustrated to have poured so much effort into trying to make Dart a viable option for a rewrite where I work (I've even been working on a Visual Studio extension since all the devs here are primitively .NET devs).

To find something so fundamental missing with no reasonable solution (and no information from the Dart team) is frustrating; it's not going to make selling Dart to my colleagues any easier.

Not really; that comment is incorrect. For example, in C# there's a JavaScriptSerializer.Deserialize<T>(string) method that does just this.

You're right; "Dart Types" is slightly ambiguous, it wasn't intended that way. It's possible to deserialise into a Map; but not into a type you defined (or even a built-in type that isn't in a small list of types it knows about).

The class you're deserialising into is the Schema; exactly like C# manages to do it:

var myPerson = deserialise<Person>(json);

If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings!

Apologies; it's been so long since I signed up, I didn't realise my username was quite so cryptic. The thread is indeed mine, and I posted it here in the hope that it might be seen by someone on the Dart Team, as there seems to have been no response from Google on this hole :(

The built-in stuff you mention deserialises into maps, not Dart classes. This loses all type checking, code-completion, etc.

(this is all detailed in the thread ;-))

It does support deserialising into a map, but not a class. One of the selling points of Dart is classes; which can give code-completion, static analysis, etc.. This is all lost if you use maps instead of classes.

Did you read about any of the suggested options? They all basically suck; requiring tons of boilerplate; are not-static formats (making it difficult to implement "the other side"); poor performance; and mostly implemented by third parties so they'll likely be broken or abandoned in 6 months.

Doesn't it seem strange that a Google-designed language for the future of the web (that's supposed to make development faster and easier) doesn't handle this (basic) requirement easily?

Valid points. I'm open to being convinced JS is a viable target; but the lack of compilers for mainstream lanfguages make me question if it's up to the job. There seem to be many attempts to bring, for example, C# to JS; yet they're all abandoned, incomplete or full of edge cases.

Is targeting JS more trouble than it's worth? Is it a good long-term solution?

The fact that we have great web apps shows that things aren't totally broken; that's not really my suggestion. I just think we need to be thinking forwards and planning for future web apps. What we have is not going to do us for the next 5, 10, 20 years :(

For the language, maybe so; but MS are building great tools for C#/VB and it's senseless for the community to reimplement them for the "other" .NET language :(

The refactor/codefix support in Roslyn/VS is great; but I wouldn't even know where to start doing something similar in F#? Can I reuse the functionality? Or is the editor so disconnected that I'd need to implement all the menu etc. myself too? (This would make it inconsistent and not play nice with submissions else's CodeFixes that might draw menus).

I didn't conclude it wasn't ready; it was an open question documenting my own concerns. The IDE support is poor compared to C#, which is what we're currently using. Roslyn isn't just about open source (nor writing a compiler in C#!); there's a bunch of functionality (like refactor, diagnostics, code fixes) that will breed a bunch of new tools that F# is sadly not on the boat for :(

We automated quite a bit with PowerShell. Our deployment scripts which unzip releases, update IIS config (apppools, virdirs, new sites) and our scheduled jobs are all done via PoSh. We also use it for lots of generation/execution of ad-hoc SQL for data manipulations.

As a shell (especially remoting to servers); it's great. As a scripting language, ironically I'm more likely to use F# (FSI) these days, mainly due to two serious bugs in PoSh Scheduled jobs we've never gotten any response from Microsoft over :(

Maybe so; though job ads I'd seen for F# seemed to have higher salaries. Possibly that was just because of where they're based (London salaries are way higher than here, for example)

I did mention that extension; and the bug I found right away :(

Roslyn isn't just about being open source; there's functionality like the Diagnostics/CodeFixes that make it trivial to do some really useful things, which are significantly harder using the F# source.

Overall my conclusion is not that F# is bad; I really love it; but there are some niggles for me still... Mostly around the level of investment from MS :/

Haha :)

The title could be qualified with "in our company", but then nobody would read it! ;)

I love F#, but I'm not sure it's currently getting the love it deserves from MS :(