6 ms·

So what's the real use case here? Microcontrollers are generally pretty single purpose, you aren't exactly swapping apps in and out of them like you are with p

by edrxty 4y ago

So what's the real use case here? Microcontrollers are generally pretty single purpose, you aren't exactly swapping apps in and out of them like you are with phones. Anything that needs that functionality is using an embedded CPU (MPU) with an MMU rather than an MCU. There are plenty of languages that are better for MCU development than JS so your main use case would be interop with something JS is good for...like a web page served on the device. This is actually not super uncommon but you'd need to be able to interface with some really awful Wifi/Eth drivers that MCUs tend to use so you're still knee deep in C.

woojoo666 4y ago
Is it not enough for people to simply like coding in JS? I like the future that we are moving towards where people can code in the languages they like, irrespective of the platform they are targeting. Just look at the possibilities that WASM has opened up
- edrxty 4y ago
  Well, I've seen someone build a web scripting engine that parsed C because they really just liked C for whatever reason. I guess a better way of putting this is, with this at the top of HN, what are people excited about building in this?
- pelorat 4y ago
  Well, hopefully WASM will lead to JS dying out.
  - iamsaitam 4y ago
    Nothing would be gained with that
- neilalexander 4y ago
  > Is it not enough for people to simply like coding in JS? Irrespective of whether people _like_ a language, there are other considerations when evaluating whether something is the best tool for the job. JavaScript has an entire class of bugs in the form of countless unexpected type coercions and equality behaviours that simply don't exist in more compact statically typed languages that would typically be used to target the average microcontroller. When deploying something to the edge, where it becomes significantly harder to maintain, I would want the least surprising behaviour in the language as possible.
  - pwdisswordfish9 4y ago
    > JavaScript has an entire class of bugs in the form of countless unexpected type coercions Contra this tired sentiment, JS does not have "unexpected type coercions". If you're going to call what happens when, for example, adding an object and a boolean together "unexpected", the question becomes "What were you expecting when you wrote that code?" JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable, and (crucially) you are not _forced_ into writing any programs that use these dubious patterns. (Although, if you want to, that's your prerogative.) There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken. Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead. > behaviours that simply don't exist in more compact statically typed languages You're confusing matters. If you want static type checking when writing your program, then use a static type checker. Refusing static type checking and then complaining about it is more than a little bit silly.
    - neilalexander 4y ago
      > JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable Well-defined maybe, but predictable? Not really. Intuitive? Absolutely not. > There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken. On the contrary, I don't believe that this is really the case. People can and often do run into these bugs in the wild because they take some input from either a user who does something unexpected, an API that returns something unexpected or a library that acts in an unexpected way and, rather than failing a logical assertion, the program continues with effectively junk data. Sanitising inputs can be surprisingly complicated too, especially when you don't know or understand the conditions you are supposed to guard against. > Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead. My point is not that the alternative is superior, for whatever definition of "superior" you are choosing, but instead that many statically typed languages will force you to think about that behaviour rather than proceed in ignorance. > If you want static type checking when writing your program, then use a static type checker. If you have to rely on what is effectively a linter to type-check for you to make sure your program won't do surprising things, that's not an incredibly positive indictment of dynamic languages as a whole.
codermike 4y ago
Here are some use cases... - If you have an IoT device and want to share logic between the device and cloud. A concrete example might be a smart parking meter where you can pay for parking on the meter itself or online or by a mobile app, and you want common business logic, tariff calculations, parking rules, user workflow, etc. You could represent the logic in C but arguably something like JS is better suited. - You want downloadable behavior that's separate from the firmware. Maybe you're making a product with one base version of C firmware but customizable by downloading scripts. Or maybe you're an enterprise company and your customers all want behavior customization and you don't want the nightmare of managing separate firmware for each of them. In C, maybe you could do this with position-independent-code modules, but JS might just be more friendly. - Maybe you just like JS. JS has garbage collection and closures, for example. Callback-based async logic is easier in JS. Functional-style code is easier to write. Depends what you feel comfortable with. Perhaps not to replace C firmware, but to be able to script the higher-level behavior in a language that's more comfortable and expressive.
- neilalexander 4y ago
  > If you have an IoT device and want to share logic between the device and cloud ... You could represent the logic in C but arguably something like JS is better suited Is this ever realistically the case? JavaScript aside, I would expect there to be an interface layer in the form of some compact protocol (e.g. CoAP) for communication and for the IoT device to be doing as little as humanly possible.
  - codermike 4y ago
    Yes, the parking meter example is an exact case I ran into in real life. But Microvium didn't exist back then. But in general, an IoT solution may have some business logic or rules that transcends the specific device, and some may prefer to represent that logic in a high level language like JS, and some situations may benefit from being able to access that logic from multiple places -- e.g. front-end, back-end, and device.

by edrxty 4y ago

woojoo666 4y ago

Is it not enough for people to simply like coding in JS? I like the future that we are moving towards where people can code in the languages they like, irrespective of the platform they are targeting. Just look at the possibilities that WASM has opened up

edrxty 4y ago
Well, I've seen someone build a web scripting engine that parsed C because they really just liked C for whatever reason. I guess a better way of putting this is, with this at the top of HN, what are people excited about building in this?
pelorat 4y ago
Well, hopefully WASM will lead to JS dying out.
- iamsaitam 4y ago
  Nothing would be gained with that
neilalexander 4y ago
> Is it not enough for people to simply like coding in JS? Irrespective of whether people _like_ a language, there are other considerations when evaluating whether something is the best tool for the job. JavaScript has an entire class of bugs in the form of countless unexpected type coercions and equality behaviours that simply don't exist in more compact statically typed languages that would typically be used to target the average microcontroller. When deploying something to the edge, where it becomes significantly harder to maintain, I would want the least surprising behaviour in the language as possible.
- pwdisswordfish9 4y ago
  > JavaScript has an entire class of bugs in the form of countless unexpected type coercions Contra this tired sentiment, JS does not have "unexpected type coercions". If you're going to call what happens when, for example, adding an object and a boolean together "unexpected", the question becomes "What were you expecting when you wrote that code?" JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable, and (crucially) you are not _forced_ into writing any programs that use these dubious patterns. (Although, if you want to, that's your prerogative.) There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken. Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead. > behaviours that simply don't exist in more compact statically typed languages You're confusing matters. If you want static type checking when writing your program, then use a static type checker. Refusing static type checking and then complaining about it is more than a little bit silly.
  - neilalexander 4y ago
    > JS _will_ evaluate these kinds of expressions, but the results are well-defined and predictable Well-defined maybe, but predictable? Not really. Intuitive? Absolutely not. > There's a double standard here, in which people who don't do any operations on wacky combinations of disjoint types in their preferred language will gleefully jump into JS and start doing those things seemingly just so they can declare that JS is broken. On the contrary, I don't believe that this is really the case. People can and often do run into these bugs in the wild because they take some input from either a user who does something unexpected, an API that returns something unexpected or a library that acts in an unexpected way and, rather than failing a logical assertion, the program continues with effectively junk data. Sanitising inputs can be surprisingly complicated too, especially when you don't know or understand the conditions you are supposed to guard against. > Take any of these cases of "unexpected type coercions" and show me some production code from a program in your preferred language where you're actually doing something similar with disjoint types and describe its superior behavior instead. My point is not that the alternative is superior, for whatever definition of "superior" you are choosing, but instead that many statically typed languages will force you to think about that behaviour rather than proceed in ignorance. > If you want static type checking when writing your program, then use a static type checker. If you have to rely on what is effectively a linter to type-check for you to make sure your program won't do surprising things, that's not an incredibly positive indictment of dynamic languages as a whole.

codermike 4y ago

Here are some use cases... - If you have an IoT device and want to share logic between the device and cloud. A concrete example might be a smart parking meter where you can pay for parking on the meter itself or online or by a mobile app, and you want common business logic, tariff calculations, parking rules, user workflow, etc. You could represent the logic in C but arguably something like JS is better suited. - You want downloadable behavior that's separate from the firmware. Maybe you're making a product with one base version of C firmware but customizable by downloading scripts. Or maybe you're an enterprise company and your customers all want behavior customization and you don't want the nightmare of managing separate firmware for each of them. In C, maybe you could do this with position-independent-code modules, but JS might just be more friendly. - Maybe you just like JS. JS has garbage collection and closures, for example. Callback-based async logic is easier in JS. Functional-style code is easier to write. Depends what you feel comfortable with. Perhaps not to replace C firmware, but to be able to script the higher-level behavior in a language that's more comfortable and expressive.

neilalexander 4y ago
> If you have an IoT device and want to share logic between the device and cloud ... You could represent the logic in C but arguably something like JS is better suited Is this ever realistically the case? JavaScript aside, I would expect there to be an interface layer in the form of some compact protocol (e.g. CoAP) for communication and for the IoT device to be doing as little as humanly possible.
- codermike 4y ago
  Yes, the parking meter example is an exact case I ran into in real life. But Microvium didn't exist back then. But in general, an IoT solution may have some business logic or rules that transcends the specific device, and some may prefer to represent that logic in a high level language like JS, and some situations may benefit from being able to access that logic from multiple places -- e.g. front-end, back-end, and device.