HN user
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 :)
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.
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).
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.
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], ()));
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.
There's an unofficial in-progress comparison here: https://github.com/glennsl/reasonml.github.io/blob/124268155...
Good to see bors[0] getting some well deserved credit. That guy's a beast!
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.
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.
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.
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.
But even then the protocol is hidden, so still not the full website address. Much better though. Thanks for the tip!
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.
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.
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.
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.
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.
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).
What if you can't understand the logic of the compiler, and therefore aren't able to write any code in the language at all? Sure it's not very error-prone, but it's also not very useful.
I'm a big fan of Rust precisely because of its safety features. Even if you don't need manual memory management there are huge benefits to resource management safety that no other language can provide. But I still recognize that there's a trade-off here.
Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high.
I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.
1. Rust was designed for low-level systems programming, and in particular the multi-threaded kind, where performance and memory control are important. So things like web browsers (it's been developed alongside development of the Servo web browser), games, operating systems, embedded systems etc. It's basically a better C++.
2. There are already several web frameworks, in various stages of earliness. See [1]. I don't think it will ever be a good idea to write Rust client-side though (even though I believe there is an emscripten backend for it, so it's possible).
3. I see a very bright future for Rust. It could use some ergonomic improvements (but it's miles ahead of C++ even now, mind you), but is otherwise a very well designed language that fits very snuggly in its niche. And it has some very strong backing from Mozilla. I expect it will slowly take over large amounts of territory from C++ and possibly from C, as these developers start to realize the benefits of Rusts safety guarantees. It's also quite unique in that its safety entices many higher-level (python, ruby, C# etc.) developers into trying system programming, which could be really transformative to the system programming scene. For example, one thing that has already come out of this is the cargo package manager, which is similar to npm, bundler etc. but (before cargo) had yet to find its way down to the lowly systems programmers. Many (former?) C++ developers actually tout it as one of the major benefits of Rust.
Spoof the referrer header, so as to pretend you were sent by Google. I use the "Referrer Control" extension for Chrome (which probably isn't an option for you, but I'm sure there are similar extensions for Firefox) with a permanent rule to spoof the referrer header for wsj.com. Works like a charm.
we need a way for engineers and scientists to feel accountable for the outcomes of their work, and to straight out refuse working on such projects
This is one of the major reasons why I'm in favor of an unconditional basic income. We can't hold people responsible for doing their job if they're not realistically allowed to refuse it. Only by allowing them to say no, by providing an alternative, in this case an unconditional income to cover their basic needs, can we allow ourselves to hold them responsible for not saying no.
Yes, shitty jobs would actually pay well. That's hardly unfair is it? The labour market would become an actual free market, where prices are properly determined by supply and demand, not by "motivation for work", more aptly known as wage slavery.
I've heard this argument several times before, but I've never understood the reasoning behind it. No matter how you look at it, a basic income is redistribution of wealth. If we finance a basic income by just printing money, then yes it would be inflationary, and the value of the basic income, along with the currency as a whole, would depreciate. But it certainly wouldn't be eliminated, and wealth would have been redistributed.
Printing money isn't the only way to finance a basic income, however. A much more sane approach is through effectivization, by eliminating bullshit jobs and (most) existing means-tested benefits, as well as increased taxation. There's nothing inflationary about this approach.
Happy to oblige. I will have to skip a lot of reasoning and contingencies for brevity's sake, but I hope it gives you an idea of what a basic income might actually mean at least.
So first of all, a basic income would be a lot more transformative to society than it would seem at first glance. It's not just about people getting more money to spend. Crime would go down, peoples health would improve and we would trust each other much more since there's much less reason to lie and cheat just to get by (which is considered a major factor in the success of the Scandinavian model.) We'd need less police, less health care, and insurance costs would go down. And of course the entire means-testing bureaucracy would be unnecessary.
Then there's the labour market. Not being required to hold a job, and the increased bargaining power that entails, could lead to a number of different outcomes that are sometimes hard to predict. Shitty jobs would either become less shitty, pay better (which of course makes it more expensive for the employer), or get automated if it's cost-effective. As would jobs individually considered harmful, meaningless or counter-productive, like the military, weapons manufacturing, telemarkting and advertising, to name a few. People would likely get a lot more educated, and the education system would hopefully transform from being a production line of worker drones to actually encouraging curiosity and learning. Innovation would flourish, since anyone could just go out and do their own thing without risking homelessness. Cooperatives would be much more prevalent. "Good" jobs might pay less, since there would be a lot more well-educated labour available.
But here's the kicker: when having a job is no longer essential, there's no reason to artificially create jobs. We could stop encouraging consumerism and infinite growth, and institute policies that are untouchable today because they remove jobs or hinder job creation. Which would cause people to spend more time and energy on what they really want to do, things that actually matter, rather than hoarding stuff. Many would work less, others more, because they're able to do work they enjoy and don't have to do it primarily for material gains. Those with small children or elderly parents could spend more time taking care of them themselves, instead of shipping them off to some institution or other.
A lot of work that's good but difficult or impossible to monetize, that currently need to be supported by advertising or considered charity, could actually be done full-time without having to spend your time fundraising or degrading your work with advertisements. It could be done part-time alongside a part-time job for some extra spending money, or on a break from your ordinary job. I think we'd see a huge increase in political activism, journalism, and a transformation in how democracy would work in general. Finally, if we got rid of copyright, the production of creative works would be included in this category, and while not very likely, it would be possible to produce something like Game of Thrones without a single cent of funding.
If all that waste and abuse could be eliminated, or significantly reduced, it would reduce cost at every step of the production chain. Profit margins, and therefore prices, would be kept down unless for some reason competition decreases. Prices might even be lowered further if there's less manipulative marketing creating artificial demand. Skilled labour might be cheaper because there's more of it available, and if it's something people really want to work on I believe they'd care less about the paycheck and more about doing what the want to do.