5 ms·

Different use cases. You don't necessarily want a 10 ton standard library for every use case, like on embedded devices or plugins for a software package. C/C++/

Different use cases. You don't necessarily want a 10 ton standard library for every use case, like on embedded devices or plugins for a software package. C/C++/Rust being 1st class citizens is also very useful.

arcticbull 8y ago
Standard libraries are what make languages useable. In my experience there's a solid case to be made for a 10-ton standard library (for targets with an operating system) or basically none whatsoever (for embedded). A thin standard library is always going to be too small to do useful things easily at the high level and too big to be deployed on an embedded system. Rust is good because it can play in both sandboxes.
kllrnohj 8y ago
For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?
- vardump 8y ago
  Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?
  - ex3ndr 8y ago
    is it really a use case for WASM?
  - kllrnohj 8y ago
    Do you have an actual example of such a thing? I'm struggling to come up with a case of multiple independent mini-programs in such a microcontroller that needs, or even benefits, from that level of fault isolation.
    - vardump 8y ago
      Rapid prototyping, replacement for a scripting facility, diagnostics filtering & output, a platform for "apps" for a small IoT type devices and just the ability to run the same plugin anywhere you please. It can be an enabler for new innovations. Even if it runs 2-10x slower than native code. And what if the answer was just: just because I can? That's how a lot in our industry got started.
  - pjmlp 8y ago
    Ah, just like JavaCard.
GordonS 8y ago
.NET's '10 tonne' standard library is a decent part of what makes it so usable. And it's not exactly massive either - I can publish a standalone .NET Core app that's only around 30MB in size. For the usability and GC, I'll take that over C any day.
- naasking 8y ago
  > I can publish a standalone .NET Core app that's only around 30MB in size. Honestly, it shouldn't need to be that big. There's plenty of cruft even in .NET core.
  - rndgermandude 8y ago
    That will probably come done quiet a bit when illink gets out of alpha. It is basically a tree-shaker to eliminate dead/unused stuff from the resulting standalone binary. https://github.com/dotnet/announcements/issues/30 https://github.com/dotnet/announcements/issues/30
    - naasking 8y ago
      A tree shaking linker will definitely help a lot, but there's still some runtime baggage that probably can't be removed. For instance, dynamic loading and all of the related type and assembly metadata structures. I look forward to seeing what they can do!

arcticbull 8y ago

Standard libraries are what make languages useable. In my experience there's a solid case to be made for a 10-ton standard library (for targets with an operating system) or basically none whatsoever (for embedded). A thin standard library is always going to be too small to do useful things easily at the high level and too big to be deployed on an embedded system. Rust is good because it can play in both sandboxes.

kllrnohj 8y ago

For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?

vardump 8y ago
Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?
- ex3ndr 8y ago
  is it really a use case for WASM?
- kllrnohj 8y ago
  Do you have an actual example of such a thing? I'm struggling to come up with a case of multiple independent mini-programs in such a microcontroller that needs, or even benefits, from that level of fault isolation.
  - vardump 8y ago
    Rapid prototyping, replacement for a scripting facility, diagnostics filtering & output, a platform for "apps" for a small IoT type devices and just the ability to run the same plugin anywhere you please. It can be an enabler for new innovations. Even if it runs 2-10x slower than native code. And what if the answer was just: just because I can? That's how a lot in our industry got started.
- pjmlp 8y ago
  Ah, just like JavaCard.

GordonS 8y ago

.NET's '10 tonne' standard library is a decent part of what makes it so usable. And it's not exactly massive either - I can publish a standalone .NET Core app that's only around 30MB in size. For the usability and GC, I'll take that over C any day.

naasking 8y ago
> I can publish a standalone .NET Core app that's only around 30MB in size. Honestly, it shouldn't need to be that big. There's plenty of cruft even in .NET core.
- rndgermandude 8y ago
  That will probably come done quiet a bit when illink gets out of alpha. It is basically a tree-shaker to eliminate dead/unused stuff from the resulting standalone binary. https://github.com/dotnet/announcements/issues/30 https://github.com/dotnet/announcements/issues/30
  - naasking 8y ago
    A tree shaking linker will definitely help a lot, but there's still some runtime baggage that probably can't be removed. For instance, dynamic loading and all of the related type and assembly metadata structures. I look forward to seeing what they can do!