5 ms·

I think it's really great to see a project like this coming out, as someone who loves writing Go on the server side, but has been grinding my teeth through lear

by jd20 9y ago

I think it's really great to see a project like this coming out, as someone who loves writing Go on the server side, but has been grinding my teeth through learning JS to be able to do client-side work. That said, I would love to hear more about how a compiled Go app will handle three of what I see as being RN's biggest advantages: 1) Ability to quickly see changes in the simulator as you're modifying code (one of the main reasons I went with RN over ObjC/Swift, is I can just Cmd+R and boom, my changes are live in a second). 2) Pushing new updates remotely, without having to resubmit your app. Would Go being statically compiled, mean we can't ship bits of executable code for minor updates / bug fixes as we see fit? 3) Debugging is really nice on RN, because you get to leverage awesome JS debugging environments like Chrome DevTools. While I've not yet had a need for a fancy debugger with Go, I could see that as a big sticking point for teams trying to choose. Nonetheless, really applaud this effort so far, and look forward to seeing more. Go's concept of goroutines seems much better suited to UI event handling, then stringing together a ton of promises and callbacks. And don't even get me started on the async keyword...

megawatthours 9y ago
>And don't even get me started on the async keyword Please do! Genuinely curious what you don't like about it.
- NightMKoder 9y ago
  If you’re coming from Go especially, my money would be in a similar vein to http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... . That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around. You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.
  - jd20 9y ago
    NightMKoder is right on, that article ("What color is your function") sums up exactly how I felt, trying to learn JavaScript after knowing Go. Also, this interview with Node.js creator Ryan Dahl, where he himself admits that Go solves the async programming model much better than JavaScript, I can relate completely to the reasons he gives: https://www.mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://www.mappingthejourney.com/single-post/2017/08/31/epi...
  - jerf 9y ago
    "You can also make a explicit is better than implicit argument;" While I'm generally an explicit sort of guy in these contexts, there isn't much that being explicit buys you here, except the ability to write bugs. There's really only one right answer and the compiler is perfectly capable of handling it. In the exceedingly rare cases where you need to override it, you can. Given how exceedingly rare those cases are we're easily in the realm of "use another language" or "fork & hack the runtime" sorts of things.
ASinclair 9y ago
RN = ReactNative? Gentle Tech Writing reminder that it helps to spell out initialisms the first time you use them.
- jd20 9y ago
  You're totally right, I'd go back and fix that if I could. Funny how a few months learning a new framework can make you forget how normal people talk :)
O_H_E 9y ago
Sorry, but I have a noob question. What do you mean in #2 by "Pushing new updates remotely, without having to resubmit your app"
- my_ghola 9y ago
  You can update the javascript parts without having to deploy a new version of the app, which takes time on the store's end to approve.
  - duiker101 9y ago
    Isn't that highly against the policy?
    - s73ver_ 9y ago
      They've oked it.
      - jd20 9y ago
        At one point, I read that the rule in question, is you cannot push new features without going through the approval process again. So it really comes down to what Apple considers "new features". People have definitely pushed bug fixes, and even small features, without issue. Perhaps ironically, when I worked on the iTunes Store (which is mostly all HTML and JavaScript) there was hardly a week went by that new code didn't get pushed (mostly bug fixes and under-the-hood updates). Yet Apple only really announced new iTunes Store features several times a year. So, one would hope they understand the need for continuously updating a complex piece of software, versus shipping major pieces of new functionality.
    - sghiassy 9y ago
      Per Apples policy interpreted languages are allowed to be updated over-the-air as long as they don’t change the app in any significant way (aka bug fixes and such)
  - O_H_E 9y ago
overcyn 9y ago
Yeah unfortunately, those are downsides that I don't think will change unless we get Go on wasm or something similar. Go brings its own advantages though. Fast, static typing, goroutines, theres no need for JSX, etc. And personally the JS ecosystem doesn't appeal to me at all.
- rounce 9y ago
  You have kinda missed the point, Go produces fat binaries with all dependencies and the Go runtime included. Serious question: How do you propose that WASM is going to help the situation?
  - overcyn 9y ago
    Well if they got the Go runtime on WASM, you could run it in a interpreter and do live reloading. Keeping state across reloads would be challenging, but I don't think it would be an impossible feat. https://github.com/golang/go/issues/18892 https://github.com/golang/go/issues/18892
    - jerf 9y ago
      Saving and reloading object state across code changes is one of those things that if you don't build it in to the language from day one, it's really hard to add it in later. I wouldn't expect Go to get it anytime soon. Even if you do manage to hack it in to something that wasn't designed with it in mind, it's always hacky, quirky, and unreliable, and you never quite know whether you're looking at a bug in your own code or in the state management hackery. It isn't impossible. You are technically correct. But it's certainly taking impossible out for drinks, followed by long strolls on the beach, and a lot of meaningful staring.
Gonzih 9y ago
For me biggest disadvantage of RN is JSX. It was not bad idea originally, but at this point its very complicated thig full of edge cases.
- RussianCow 9y ago
  What edge cases? JSX is basically just syntactic sugar over a function call.
pjmlp 9y ago
> ... went with RN over ObjC/Swift, is I can just Cmd+R and boom, my changes are live in a second). As someone with experience in Delphi, C++ Builder, Smalltalk having younger developers rediscovering this looks funny. Have a look at Flutter and Xamarin.
- jd20 9y ago
  I actually remember Delphi and C++ Builder (though I spent most of my time in Visual C++), and React Native certainly wasn't my first exposure to hot reloading, but if your only exposure to iOS programming was via XCode, having hot reloading (whether that's React Native or Flutter or Xamarin) can seem like a revelation in how much more productive you can be, when you're not waiting for your app to rebuild and install. So from that perspective, it is kind of like rediscovering the old. (And I didn't mention it, but React Native can reload while preserving state, it's just not the default). Flutter looks very promising btw, I probably can't use it yet though for the same reasons as Matcha, which is my current project depends on too many external libraries (for which React Native and the larger JavaScript community has been great).
solidr53 9y ago
Wait, Cmd+R... you don't have HMR enabled?

by jd20 9y ago

megawatthours 9y ago

>And don't even get me started on the async keyword Please do! Genuinely curious what you don't like about it.

NightMKoder 9y ago
If you’re coming from Go especially, my money would be in a similar vein to http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... . That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around. You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.
- jd20 9y ago
  NightMKoder is right on, that article ("What color is your function") sums up exactly how I felt, trying to learn JavaScript after knowing Go. Also, this interview with Node.js creator Ryan Dahl, where he himself admits that Go solves the async programming model much better than JavaScript, I can relate completely to the reasons he gives: https://www.mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://www.mappingthejourney.com/single-post/2017/08/31/epi...
- jerf 9y ago
  "You can also make a explicit is better than implicit argument;" While I'm generally an explicit sort of guy in these contexts, there isn't much that being explicit buys you here, except the ability to write bugs. There's really only one right answer and the compiler is perfectly capable of handling it. In the exceedingly rare cases where you need to override it, you can. Given how exceedingly rare those cases are we're easily in the realm of "use another language" or "fork & hack the runtime" sorts of things.

ASinclair 9y ago

RN = ReactNative? Gentle Tech Writing reminder that it helps to spell out initialisms the first time you use them.

jd20 9y ago
You're totally right, I'd go back and fix that if I could. Funny how a few months learning a new framework can make you forget how normal people talk :)

O_H_E 9y ago

Sorry, but I have a noob question. What do you mean in #2 by "Pushing new updates remotely, without having to resubmit your app"

my_ghola 9y ago
You can update the javascript parts without having to deploy a new version of the app, which takes time on the store's end to approve.
- duiker101 9y ago
  Isn't that highly against the policy?
  - s73ver_ 9y ago
    They've oked it.
    - jd20 9y ago
      At one point, I read that the rule in question, is you cannot push new features without going through the approval process again. So it really comes down to what Apple considers "new features". People have definitely pushed bug fixes, and even small features, without issue. Perhaps ironically, when I worked on the iTunes Store (which is mostly all HTML and JavaScript) there was hardly a week went by that new code didn't get pushed (mostly bug fixes and under-the-hood updates). Yet Apple only really announced new iTunes Store features several times a year. So, one would hope they understand the need for continuously updating a complex piece of software, versus shipping major pieces of new functionality.
  - sghiassy 9y ago
    Per Apples policy interpreted languages are allowed to be updated over-the-air as long as they don’t change the app in any significant way (aka bug fixes and such)
- O_H_E 9y ago

overcyn 9y ago

Yeah unfortunately, those are downsides that I don't think will change unless we get Go on wasm or something similar. Go brings its own advantages though. Fast, static typing, goroutines, theres no need for JSX, etc. And personally the JS ecosystem doesn't appeal to me at all.

rounce 9y ago
You have kinda missed the point, Go produces fat binaries with all dependencies and the Go runtime included. Serious question: How do you propose that WASM is going to help the situation?
- overcyn 9y ago
  Well if they got the Go runtime on WASM, you could run it in a interpreter and do live reloading. Keeping state across reloads would be challenging, but I don't think it would be an impossible feat. https://github.com/golang/go/issues/18892 https://github.com/golang/go/issues/18892
  - jerf 9y ago
    Saving and reloading object state across code changes is one of those things that if you don't build it in to the language from day one, it's really hard to add it in later. I wouldn't expect Go to get it anytime soon. Even if you do manage to hack it in to something that wasn't designed with it in mind, it's always hacky, quirky, and unreliable, and you never quite know whether you're looking at a bug in your own code or in the state management hackery. It isn't impossible. You are technically correct. But it's certainly taking impossible out for drinks, followed by long strolls on the beach, and a lot of meaningful staring.

Gonzih 9y ago

For me biggest disadvantage of RN is JSX. It was not bad idea originally, but at this point its very complicated thig full of edge cases.

RussianCow 9y ago
What edge cases? JSX is basically just syntactic sugar over a function call.

pjmlp 9y ago

> ... went with RN over ObjC/Swift, is I can just Cmd+R and boom, my changes are live in a second). As someone with experience in Delphi, C++ Builder, Smalltalk having younger developers rediscovering this looks funny. Have a look at Flutter and Xamarin.

jd20 9y ago
I actually remember Delphi and C++ Builder (though I spent most of my time in Visual C++), and React Native certainly wasn't my first exposure to hot reloading, but if your only exposure to iOS programming was via XCode, having hot reloading (whether that's React Native or Flutter or Xamarin) can seem like a revelation in how much more productive you can be, when you're not waiting for your app to rebuild and install. So from that perspective, it is kind of like rediscovering the old. (And I didn't mention it, but React Native can reload while preserving state, it's just not the default). Flutter looks very promising btw, I probably can't use it yet though for the same reasons as Matcha, which is my current project depends on too many external libraries (for which React Native and the larger JavaScript community has been great).

solidr53 9y ago

Wait, Cmd+R... you don't have HMR enabled?