8 ms·

I’ve been doing a lot of backend stuff recently with Dart after coming from a Node / Ruby background and I can’t begin to describe what a breath of fresh air it

by mdhb 2y ago

I’ve been doing a lot of backend stuff recently with Dart after coming from a Node / Ruby background and I can’t begin to describe what a breath of fresh air it is. Insanely high quality of life improvement for development. The experience is very similar to what people here are describing that they wanted from Swift. Also in a similar vein to Typescript, it’s another language I can now comfortably use and share between front and backend but with a very different and I think for most use cases better set of trade offs. Honestly I think it’s the most underrated modern language out there at the moment because people still only associate it with Flutter which is unfortunate.

bsaul 2y ago
Problem with backend dev is that it's 99% about plumbing between components written by someone else ( db, cache, queue, other web services , etc). In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.
- mdhb 2y ago
  One of the nice things about Dart in particular is that they are actually very aware that they are currently a small community. In that sense they ended up making a big focus on having great interop with other languages. Currently they have C, C++, Rust, Swift, JavaScript (browser and node), Java, Kotlin and Objective C all more or less working and an upcoming goal of WASI will also open up that entire ecosystem. Plus all of your usual interop solutions for out of process communication. I.e anything that speaks gRPC like Ruby, C#, Go, PHP etc has strongly typed automatically generated code libraries for you.
  - lukeh 2y ago
    Many of those solutions rely on Flutter platform channels (ie. serialization) which may not suit high performance use cases. Plug: native Swift platform channel implementation which I’ve been working on lately. https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift
- davidw 2y ago
  I don't think this is wrong, but maybe missing some nuance: Popularity definitely gives you "more stuff on the shelf", but it's also probably fair to say that at some level of popularity there's "enough" on the shelf. What "enough" is, probably varies for different projects. Just as an example, a while back I was involved in an Erlang project and while that ecosystem certainly does not have as much available as, say, Ruby, it had the pieces we needed, like a Postgres library and a few other things. The runtime itself was a better fit than others for the semi-embedded system we were working on, so in the end we chose that over more popular languages.
  - bsaul 2y ago
    For sure you're right, it's always a tradeoff. But to compensate for a deficit in popularity, a technology needs to have tremendous merits. Language performance is only important in some very specific cases (I/O trumps CPU in most use case), type safety is now becoming pretty standard everywhere. Your example of embedded system is indeed a case where the environment has so specific constraints that the runtime behavior of the technology can make a huge difference. But for the regular "json <-> postgres" backend that are the bread and butter of our industry, i'd say it's an exception.
- fauigerzigerk 2y ago
  >In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine. I would have thought so too, but surprisingly we have seen completely new ecosystems emerge where incumbants had seemingly covered all the bases. When Node.js and Go came along, we already had Perl, PHP, Python, Java and C# for backends (as well as tons of less popular options). Each new player offered some technical benefits, but I never felt that these relatively modest technical differences merited starting a whole new library ecosystem and doing it all over again. I can only conclude that you and I are wrong to think that the availability of mature libraries dominates other factors such as people wanting to get rid of the previous generation's culture. Wiping the slate clean seems to be a deeply felt desire.
  - tempodox 2y ago
    Fashion-driven development is obviously much more pervasive than we'd like to admit. And if I don't understand the previous tech better than the new one I might just as well use what's hot and all the rage now.
  - whizzter 2y ago
    Most of the stalwarts you mention had been built to depend on more or less huge systems where the webserver/appserver was in a central postion (Apache, J2EE or IIS), node had a certain minimalness combined with client/server code sharing going for it and Go had the whole "be as cool as Google" vibe off it (also not tied to a big server but being self-contained) and both of them meshed well with a certain microservice trend of those days. Yes, there was a certain hype driving them but they also fit into the "devops" paradigm shift where the unit of management became a container/application instead of begging a BOFH to configure part of a "large" server that were suddenly becoming commoditized (The desire wasn't maybe so much a clean slate as to not be held back by sysadmins).
mike_hearn 2y ago
How do you find it compared to Java or Kotlin?
- mdhb 2y ago
  Kotlin would be the most direct comparison for sure. There is much less boilerplate than Java and also just by the fact that it’s a relatively new language (~10 years old) that was allowed to grow without a large community attached to it for a long time but with an absolutely first class technical steering committee they actually had the chance to bring in a lot of really cool features without big messy community migrations. Even those major migrations that have occurred (I.e introducing fully sound null safety a couple of years ago) were done in such a smooth way it gave me a huge amount of hope for its future.
- brabel 2y ago
  I write mostly Java and Kotlin professionally but have lots of Dart side projects. Dart has evolved a lot in the last few years and is now a wonderful language to work with, not only the language itself has lots of useful features (non-nullability by default, sealed classes and pattern matching, Isolates, List spreading, first-class await/async, stream generators) but it has high quality documentation/package-manager/IDE support. The fact you can hot swap code without fuss and benchmark it using the Dart Dev Tools is amazing (https://dart.dev/tools/dart-devtools https://dart.dev/tools/dart-devtools). Kotlin as a language has some features that are nicer (e.g. data classes - though Dart has just released the first part of its new macro system which may make Dart more powerful than Kotlin in this regard) and others that are worse (e.g. pattern matching), so it's a close call. In terms of tooling, Kotlin has wonderful IDE support as well, but lacks in terms of code documentation (its doc system was in "alpha" quality level for years, haven't checked lately but I wouldn't be surprised it's still beta), package management (it pigbacks on top of Maven, which is not so great IMO, it does the job but it's not as nice as Rust and Dart, have a look at pub.dev - it's so good) and its main build system (Gradle seems to be the most popular and everyone who has used it knows it's not that nice to use, though it's extremely powerful - but notice you can use Maven just fine if you're not doing multi-platform, at least). If you want to do multi-platform, Dart is a clear winner because you'll have Flutter, which has an extremely polished UX and stable support for all platforms. Kotlin MP is still catching up, I have used it a lot recently and it's all just coming out of beta now (and a lot of peripherical stuff is unfinished). Kotlin has an advantage, however: you can write Kotlin common code and use the native UI system instead of going the Flutter way, which requires you to write the UI in Dart. So if that's what you prefer, Kotlin is the better option. If you do backend web development, Kotlin is superior, I think, because it can use all stuff from the Java world (Spring, Jetty, all the instrumentation stuff, libs to do anything). But Dart is fine as well, specially if you want to keep one language for back/front ends. And Dart has better interop with JS and a well developed FFI for calling native code (which makes the lack of libraries less of a problem... it's not much of a problem anyway as Dart has A LOT of packages these days). In the end, I think that which one is "better" depends a lot on pure personal preference, but regardless of which language you pick, you'll be alright, they're both great languages now.
moomoo11 2y ago
I also like dart having used it for flutter. How’s the performance story when using for backend? I love and use go for 99% backend and node for scripts (usually there’s a npm package that does what I need - done in 10 min) or spinning up simple aws lambda. Go is so highly performant at all things including CPU bound tasks (no point comparing io bound stuff, although it can handle a larger volume of these). Plus the scaling story is that it just always works fast the more resource you throw at it. I don’t use rust because I don’t need that level of perf. If rust is 10 go is 8-9. That’s fine for me. For context I have services doing 10-100k rps that cost me like $4 plus bandwidth (depending on usefase, each).I don’t need beefy instances.
- mdhb 2y ago
  I mean it’s a fully compiled, optimized machine code binary that I deploy but having said that, it’s not Rust or Go and I wouldn’t expect 100k rps at all. I just throw it up on Cloud Run and let it auto scale up and down as required and call it a day.
  - moomoo11 2y ago
    Interesting. Thank you! Cheers
  - neonsunset 2y ago
    Stop putting Go in the same bucket as Rust. You never looked at its low-level details. Please do. It has weak compiler, expensive write barriers and neither offers you APIs to reach optimal hardware utilization (aside from completely custom ASM dialect) nor the ability to define zero-cost abstractions. Its purpose is fast networked back-end applications that are scaled horizontally (by cranking replica count, because Go's GC does not scale well with cores, and the CSP pattern has scalability issues too), but that's pretty much it.
    - mdhb 2y ago
      I’m literally responding to someone who talked about Go and Rust who wanted a comparison.
chuckadams 2y ago
Dart's claim to fame was a static type system, but TS's type system eventually surpassed Dart's and then some: TS not only gives lots of escape hatches from soundness because the JS ecosystem is messy and needs it, but it also doesn't repeat Dart's colossal mistake of making every generic type covariant then inserting runtime checks on writes (something everyone knew was a mistake after Java arrays and Eiffel did it). Dart has some things in its favor: it's not defined by underlying JS semantics, so it's free to jettison some of its legacy (bye bye `undefined`). Unfortunately its changelog doesn't paint a picture of an evolving language.
- kjksf 2y ago
  Dart "lost" because it was a completely different language than JavaScript, with completely different , much smaller ecosystem of libraries and thus huge switching costs. TypeScript, being a type system over JavaScript, re-uses JavaScript ecosystem and allowed incremental adoption. Dart is now "winning" because Flutter is a very good way to write once and deploy on Android and iOS (and maybe in the future on web and desktop). That drives adoption of Dart and builds ecosystem of libraries.
  - chuckadams 2y ago
    Yah I just added the bit about Dart not being chained to JS, which is potentially a big win. But stuff like generic covariance is a whopper. Still, they fixed null-safety and implicit downcasts (which was pure WTF), so there's hope yet.
- brabel 2y ago
  > Unfortunately its changelog doesn't paint a picture of an evolving language. You haven't kept up with Dart in the last 3 or 4 years, have you?? They've improved almost every part of the language in this timeframe, I don't know what is an "evolving" language if Dart isn't it.
  - chuckadams 2y ago
    > You haven't kept up with Dart in the last 3 or 4 years, have you?? Not lately, but to my shame the changelog I looked at stopped at Dart 2, so I got a poor picture of things. Looks like variance annotations are still “experimental” though, but I take back what I said about Dart standing still.

by mdhb 2y ago

bsaul 2y ago

Problem with backend dev is that it's 99% about plumbing between components written by someone else ( db, cache, queue, other web services , etc). In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.

mdhb 2y ago
One of the nice things about Dart in particular is that they are actually very aware that they are currently a small community. In that sense they ended up making a big focus on having great interop with other languages. Currently they have C, C++, Rust, Swift, JavaScript (browser and node), Java, Kotlin and Objective C all more or less working and an upcoming goal of WASI will also open up that entire ecosystem. Plus all of your usual interop solutions for out of process communication. I.e anything that speaks gRPC like Ruby, C#, Go, PHP etc has strongly typed automatically generated code libraries for you.
- lukeh 2y ago
  Many of those solutions rely on Flutter platform channels (ie. serialization) which may not suit high performance use cases. Plug: native Swift platform channel implementation which I’ve been working on lately. https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift
davidw 2y ago
I don't think this is wrong, but maybe missing some nuance: Popularity definitely gives you "more stuff on the shelf", but it's also probably fair to say that at some level of popularity there's "enough" on the shelf. What "enough" is, probably varies for different projects. Just as an example, a while back I was involved in an Erlang project and while that ecosystem certainly does not have as much available as, say, Ruby, it had the pieces we needed, like a Postgres library and a few other things. The runtime itself was a better fit than others for the semi-embedded system we were working on, so in the end we chose that over more popular languages.
- bsaul 2y ago
  For sure you're right, it's always a tradeoff. But to compensate for a deficit in popularity, a technology needs to have tremendous merits. Language performance is only important in some very specific cases (I/O trumps CPU in most use case), type safety is now becoming pretty standard everywhere. Your example of embedded system is indeed a case where the environment has so specific constraints that the runtime behavior of the technology can make a huge difference. But for the regular "json <-> postgres" backend that are the bread and butter of our industry, i'd say it's an exception.
fauigerzigerk 2y ago
>In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine. I would have thought so too, but surprisingly we have seen completely new ecosystems emerge where incumbants had seemingly covered all the bases. When Node.js and Go came along, we already had Perl, PHP, Python, Java and C# for backends (as well as tons of less popular options). Each new player offered some technical benefits, but I never felt that these relatively modest technical differences merited starting a whole new library ecosystem and doing it all over again. I can only conclude that you and I are wrong to think that the availability of mature libraries dominates other factors such as people wanting to get rid of the previous generation's culture. Wiping the slate clean seems to be a deeply felt desire.
- tempodox 2y ago
  Fashion-driven development is obviously much more pervasive than we'd like to admit. And if I don't understand the previous tech better than the new one I might just as well use what's hot and all the rage now.
- whizzter 2y ago
  Most of the stalwarts you mention had been built to depend on more or less huge systems where the webserver/appserver was in a central postion (Apache, J2EE or IIS), node had a certain minimalness combined with client/server code sharing going for it and Go had the whole "be as cool as Google" vibe off it (also not tied to a big server but being self-contained) and both of them meshed well with a certain microservice trend of those days. Yes, there was a certain hype driving them but they also fit into the "devops" paradigm shift where the unit of management became a container/application instead of begging a BOFH to configure part of a "large" server that were suddenly becoming commoditized (The desire wasn't maybe so much a clean slate as to not be held back by sysadmins).

mike_hearn 2y ago

How do you find it compared to Java or Kotlin?

mdhb 2y ago
Kotlin would be the most direct comparison for sure. There is much less boilerplate than Java and also just by the fact that it’s a relatively new language (~10 years old) that was allowed to grow without a large community attached to it for a long time but with an absolutely first class technical steering committee they actually had the chance to bring in a lot of really cool features without big messy community migrations. Even those major migrations that have occurred (I.e introducing fully sound null safety a couple of years ago) were done in such a smooth way it gave me a huge amount of hope for its future.
brabel 2y ago
I write mostly Java and Kotlin professionally but have lots of Dart side projects. Dart has evolved a lot in the last few years and is now a wonderful language to work with, not only the language itself has lots of useful features (non-nullability by default, sealed classes and pattern matching, Isolates, List spreading, first-class await/async, stream generators) but it has high quality documentation/package-manager/IDE support. The fact you can hot swap code without fuss and benchmark it using the Dart Dev Tools is amazing (https://dart.dev/tools/dart-devtools https://dart.dev/tools/dart-devtools). Kotlin as a language has some features that are nicer (e.g. data classes - though Dart has just released the first part of its new macro system which may make Dart more powerful than Kotlin in this regard) and others that are worse (e.g. pattern matching), so it's a close call. In terms of tooling, Kotlin has wonderful IDE support as well, but lacks in terms of code documentation (its doc system was in "alpha" quality level for years, haven't checked lately but I wouldn't be surprised it's still beta), package management (it pigbacks on top of Maven, which is not so great IMO, it does the job but it's not as nice as Rust and Dart, have a look at pub.dev - it's so good) and its main build system (Gradle seems to be the most popular and everyone who has used it knows it's not that nice to use, though it's extremely powerful - but notice you can use Maven just fine if you're not doing multi-platform, at least). If you want to do multi-platform, Dart is a clear winner because you'll have Flutter, which has an extremely polished UX and stable support for all platforms. Kotlin MP is still catching up, I have used it a lot recently and it's all just coming out of beta now (and a lot of peripherical stuff is unfinished). Kotlin has an advantage, however: you can write Kotlin common code and use the native UI system instead of going the Flutter way, which requires you to write the UI in Dart. So if that's what you prefer, Kotlin is the better option. If you do backend web development, Kotlin is superior, I think, because it can use all stuff from the Java world (Spring, Jetty, all the instrumentation stuff, libs to do anything). But Dart is fine as well, specially if you want to keep one language for back/front ends. And Dart has better interop with JS and a well developed FFI for calling native code (which makes the lack of libraries less of a problem... it's not much of a problem anyway as Dart has A LOT of packages these days). In the end, I think that which one is "better" depends a lot on pure personal preference, but regardless of which language you pick, you'll be alright, they're both great languages now.

moomoo11 2y ago

I also like dart having used it for flutter. How’s the performance story when using for backend? I love and use go for 99% backend and node for scripts (usually there’s a npm package that does what I need - done in 10 min) or spinning up simple aws lambda. Go is so highly performant at all things including CPU bound tasks (no point comparing io bound stuff, although it can handle a larger volume of these). Plus the scaling story is that it just always works fast the more resource you throw at it. I don’t use rust because I don’t need that level of perf. If rust is 10 go is 8-9. That’s fine for me. For context I have services doing 10-100k rps that cost me like $4 plus bandwidth (depending on usefase, each).I don’t need beefy instances.

mdhb 2y ago
I mean it’s a fully compiled, optimized machine code binary that I deploy but having said that, it’s not Rust or Go and I wouldn’t expect 100k rps at all. I just throw it up on Cloud Run and let it auto scale up and down as required and call it a day.
- moomoo11 2y ago
  Interesting. Thank you! Cheers
- neonsunset 2y ago
  Stop putting Go in the same bucket as Rust. You never looked at its low-level details. Please do. It has weak compiler, expensive write barriers and neither offers you APIs to reach optimal hardware utilization (aside from completely custom ASM dialect) nor the ability to define zero-cost abstractions. Its purpose is fast networked back-end applications that are scaled horizontally (by cranking replica count, because Go's GC does not scale well with cores, and the CSP pattern has scalability issues too), but that's pretty much it.
  - mdhb 2y ago
    I’m literally responding to someone who talked about Go and Rust who wanted a comparison.

chuckadams 2y ago

Dart's claim to fame was a static type system, but TS's type system eventually surpassed Dart's and then some: TS not only gives lots of escape hatches from soundness because the JS ecosystem is messy and needs it, but it also doesn't repeat Dart's colossal mistake of making every generic type covariant then inserting runtime checks on writes (something everyone knew was a mistake after Java arrays and Eiffel did it). Dart has some things in its favor: it's not defined by underlying JS semantics, so it's free to jettison some of its legacy (bye bye `undefined`). Unfortunately its changelog doesn't paint a picture of an evolving language.

kjksf 2y ago
Dart "lost" because it was a completely different language than JavaScript, with completely different , much smaller ecosystem of libraries and thus huge switching costs. TypeScript, being a type system over JavaScript, re-uses JavaScript ecosystem and allowed incremental adoption. Dart is now "winning" because Flutter is a very good way to write once and deploy on Android and iOS (and maybe in the future on web and desktop). That drives adoption of Dart and builds ecosystem of libraries.
- chuckadams 2y ago
  Yah I just added the bit about Dart not being chained to JS, which is potentially a big win. But stuff like generic covariance is a whopper. Still, they fixed null-safety and implicit downcasts (which was pure WTF), so there's hope yet.
brabel 2y ago
> Unfortunately its changelog doesn't paint a picture of an evolving language. You haven't kept up with Dart in the last 3 or 4 years, have you?? They've improved almost every part of the language in this timeframe, I don't know what is an "evolving" language if Dart isn't it.
- chuckadams 2y ago
  > You haven't kept up with Dart in the last 3 or 4 years, have you?? Not lately, but to my shame the changelog I looked at stopped at Dart 2, so I got a poor picture of things. Looks like variance annotations are still “experimental” though, but I take back what I said about Dart standing still.