glennsl

vor 4 Jahrendiscuss

See the reply to parent. For a hobby project I think it's an interesting experience to try. Especially if you also intend to write a back-end in Rust. But for production use, and productivity in general, I don't think it's close to ready.

I find Rescript to be much more enjoyable for both hobby and production use. If you're looking for a front-end language that is quite similar to Rust, just without the manual memory management :)

glennsl

vor 4 Jahrendiscuss

It's not easy to separate WASM specifically from Rust, and also hard to separate Rust from seed-rs, the UI framework we're using. But as far as problems with all of them together, here's the major ones:

- Very slow compilation times. A medium-sized app can take 30s to build incrementally on a fast desktop computer. And that's just way too slow for front-end development where fast iteration is key. In comparison, Rescript takes maybe a few hundred milliseconds on an app that's about the same size.

- Poor abstraction mechanisms, for making reusable and configurable components with more than a few properties, some being required and some being optional. The common Rust solution for this is the "builder" pattern, which is very verbose to implement, and still quite awkward if you have more than a few required properties.

- Poor debugging ability. WASM is opaque and there's no debugger for it as far as I know. The stack traces you get from Rust is also very noisy and imprecise. You basically only get the function name, and have to search for it in a big noisy stack trace. And because of inlining the problem might not actually even be in that function. Also, when a panic happens the app just freezes. There's probably some way of intercepting and overriding this behaviour, but by default it's quite bad UX.

- The cognitive overhead of manual memory management. Fighting the borrow checker and having to always think about who owns what and what strategy to use to manage data ownership is just completely unnecessary for most front-end development. Most of the time the app is just waiting for an event to happen, and when something does happen the processing needed tends to be dwarfed by the time spent by the browser to update and render the DOM.

- Large bundle size. Because you tend to use native Rust libraries instead of binding to non-idiomatic and often poorly designed browser APIs.

- Somewhat poor browser support? We've had some issues with the app simply failing to load after a new version is deployed, and having to clear the browser cache in order to fix it. We've yet to reproduce this reliably and therefore still haven't been able to track down why it happens.

glennsl

vor 4 Jahrendiscuss

Building an agtech platform (with quite a few other people, including a designer and data scientist, but I'm currently the sole developer, and for the most part it was built by a single developer).

Backend: Rust, rocket, sqlx, postgres + a little bit of R. Ansible for deployment.

Frontend: Rescript + React. Also a significant portion of Rust/WASM, but that was a mistake I'm trying to undo.

In short, statically typed and functional(-ish).

glennsl

vor 9 Jahrendiscuss

What are we supposed to be competing for? Reason is a tool that makes different trade-offs than some other tools. These trade-offs might work for you or they might not. It all depends on what YOU actually need.

glennsl

vor 9 Jahrendiscuss

Unfortunately not. It's an inseparable part of the Reason syntax. You can however use either the desugared form:

  ([@JSX] div(~foo=bar, ~children=[child1, child2], ()));

Or a preprocessor that'll give you a JSX-like syntax, but without the type checking: https://github.com/cxa/ppx_bsx

glennsl

vor 9 Jahrendiscuss

I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection.

Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well.

[1]: http://mlton.org/ValueRestriction

glennsl

vor 9 Jahrendiscuss

There's an unofficial in-progress comparison here: https://github.com/glennsl/reasonml.github.io/blob/124268155...

glennsl

vor 9 Jahrendiscuss

Non-AMP link: https://www.theverge.com/2017/7/14/15969674/slime-eels-hagfi...

glennsl

vor 10 Jahrendiscuss

Good to see bors[0] getting some well deserved credit. That guy's a beast!

[0] https://github.com/bors

glennsl

vor 10 Jahrendiscuss

Great, that's actually useful information.

But you could have safely skipped the "first!" comment. Being first does not make you any more superior in the front-end world than it does in a youtube comment.

glennsl

vor 10 Jahrendiscuss

Please stop the fanboyism. OP did not say there was anything wrong with Vue, but asked if there was any specific reason it was chosen, and suggested they try something that comes with good preconfigured defaults to avoid being overwhelmed by all the choices. Which you completely fail to address in your canned sales pitch.

glennsl

vor 10 Jahrendiscuss

He does suggest a solution, it's just not an easy one. But it is simple: Organize and get shit done. He often uses the womens liberation movement, civil rights movement and anti-vietnam-war movement as historical examples. There's still work to be done, and it takes a lot of effort and a long time to get anywhere, but we continue to progress towards the better.

glennsl

vor 10 Jahrendiscuss

Also used for effect in the 1969 greek-french-algerian political thriler "Z"[0]:

"Any resemblance to real events, or to people, alive or dead, is no coincidence. It is INTENTIONAL."

But this one actually is based on a true story.

[0] https://en.wikipedia.org/wiki/Z_(1969_film)

glennsl

vor 10 Jahrendiscuss

But even then the protocol is hidden, so still not the full website address. Much better though. Thanks for the tip!

glennsl

vor 10 Jahrendiscuss

Don't you think the owner of this deserted island with enough resources to live on might at some point object to you being there and force you off his land?

There is no living outside of society, outside of private property and the rule of law. There is no real choice here.

glennsl

vor 10 Jahrendiscuss

> Socialism (the real deal, not capitalist welfare states) does not work. Nationalizing industries does not work. Price controls do not work. Central planning does not work. The most skilled leader in the world couldn't make this program work.

Socialism is not nationalization of industries, price controls and central planning. What you describe is a very specific form of authoritarian socialism which people (as in masses, not individuals) only seek in deep desperation.

Actual socialism, as in workers control of the means of production, ie. workers owning and managing their own workplaces, does not require centralized power.

glennsl

vor 10 Jahrendiscuss

> If someone creates a ML variant with a day-to-day experience as clarified as Go then I will gladly jump on board.

I think Kotlin and (eventually) Swift comes very close, but both have compatibility as a high priority, which complicates the languages a bit. But I'm hoping these languages will be able to serve as gateway drugs into the world of ML-style programming, and that we'll soon see a no-compromise ML-style focusing on the full experience.

glennsl

vor 10 Jahrendiscuss

Sure. I think it's more prevalent among Go zealots, probably because so many were lured into it by the inital hype, but it's not at all Go-specific. Another example is the hype and love-hate relationship people have with Javascript MVC frameworks. Even with React, which actually deserve the hype, there are many who default to "hating" it because they're sick of being fooled by all the hype.

glennsl

vor 10 Jahrendiscuss

I don't dislike Go. I just think there are zero use cases where Go is the best choice. But what I do dislike is when people try to hype and con others into adopting a language to justify and increase the return on their own time investment.

glennsl

vor 10 Jahrendiscuss

> C and dynamic languages are used in important applications and being better than them for the same tasks does seem to be a design goal of go

C is essentially popular because it's popular. And it therefore has a huge ecosystem, can run on pretty much anything and has tons of code already written. That's a huge benefit, and one that Go does not have because it hasn't existed as the dominant language for 45 years yet.

Popular dynamic languages have the benefit of being toys with the bare minimum of features needed to scale beyond toy programs. You can build a house with legos too. It won't be a good house, and it won't be very cost-effective, but it's certainly possible.

> That's your opinion.

No, it's not just my opinion. A well-designed type system eliminates the possibility of you making certain types of very common errors. It will refuse to allow you, and it will sometimes even help you understand why, and what you should have done instead.

The complexity of Rust comes mostly from how the type system has been designed to handle manual memory management. If you take that part out and replace it with garbage collection, you'll get a language that is both safe and easy to learn and understand. Not quite as safe as Rust, and not quite as simple as Go, but very close in both regards. Languages like this do exist. See Kotlin and Swift, for example.

> It's weird to me that people compare Go and Rust, they're languages with very different motivations.

In this we agree. And I'm not arguing for Rust as a substitute for Go. But I am arguing for ignoring a language that ignores much of what the rest of us have learnt about type systems and programming languages during the past half a century (in real years, not tech years).

Submissions

Richard Branson, Kofi Annan, World Leaders Say End the Failed Drug War

comments