My parents bought a house and went on multiple family vacations every year and never really were too concerned about money, saving up a decent amount for retirement. My mom was a teacher in a poor inner city school and my dad was a low level insurance salesman. My mom never had to worry about student loans, they were easily paid off. I think trading fiscal peace and security for an iPhone is a bad trade.
That this even needed to be said on a forum like HN baffles me. I suspect it's a result of decades of mainstream political/cultural doom-and-gloom propaganda.
This quality of life metric is purely economic, but it is easy to read it as general life quality- personally, I'd swap now for 1820s homesteading out west in a heartbeat even though that would register as 'extreme poverty' on the economic scale.
Well, for a start, it's safe to assume you're not a woman or a minority. And even if you're a young healthy white male, your quality of life would be significantly worse in the 1820s. Not only would you lose access to a lot of the everyday conveniences of life today, you're also far more likely to die a young and painful death from any number of disease.
Conveniences don't make life worth living, and a long life doesn't mean a good life. Do you really think people, on average, enjoyed their lives less back then? I don't
Well, enjoyment or happiness is tricky to measure because happiness = reality - expectation. So people in the 1820s might've been "happy" enough because they simply didn't know a better life like today's was a possibility. There's no reason to think they were happier than today's population though. And certainly, you as someone who experienced today's conveniences will not be happy long term if all those were taken away suddenly.
I've spent the best years of my life living in the woods and in wall-less huts w/ no water, plumbing or electricity. Imho our modern conveniences don't make life any richer, and in many cases take away the pleasure of things we take for granted. If I had medical problems I would probably feel differently.
Uh huh. What were you wearing? Did you sew your own clothes and grow your own cotton for those clothes? There's a surprising amount of "on the grid" work that afforded you the ability to live "off the grid".
There's also a big difference between living in a part of the world where the woods provide a relatively temperate climate. Try living out in the forest to Papua New Guinea with 100% humidity.
By the way, try to make sure you don't accidentally get bitten by a rabid animal because the cure for rabies wasn't invented until the 1880s.
I feel like you are probably taking a lot of things for granted. Clothes, food, equipment, vehicles, etc. Heck, even just the ability to choose to live in a hut in the woods.
If you are jumping in a time machine to move your consciousness to a body in 1820 USA you are rolling dangerous dice because you have a significant chance of living the horrible life of a slave.
The US government passed Homestead Acts back in the 1800s where they gave away plots of land, called homesteads, (like 10% of the country) for free. It's a lifestyle, for sure, but living off land you don't own isn't what I was referring to. I think the last homesteads (free land) were given away in the 1980s.
The median quality of life is MUCH higher today than 100 years ago. And bottom 1%-tile quality of life might be 1000 times better. All thanks to advance in technology and increased productivity.
I'm not exaggerating but this might just be the highest impact library I've seen. As a backend developer who has lots of great project ideas but bail at the thought of having to use JavaScript and HTML, this library is a godsend!
My only question is why it took so long for someone to implement it? And where are the equivalent libraries for Go, Rust and Java?
Well, I haven't looked into this one deeply yet, so I'm not sure what the differences are exactly. But there are many existing, broadly similar, projects. I see this as a solution to "I want to make an interactive website, and I don't want to touch the JS ecosystem at all and/or I really prefer python-specific libraries". This is my position exactly, so I sort of keep track of what's available. From that perspective, this is in the same space as: web2py, pyjs, streamlit, brython, pyodide, pywebio, gleam. I'm sure there are others.
This is a futile pursuit simply because you are creating a layer of abstraction over JS using another dynamic language so there's no real gain other than syntactic sugar.
Would you say the same thing about web assembly and emscripten? At least one of the above is based on those.
Using scientific and numeric packages from the python ecosystem is more than syntactic sugar, IMO. It seems like the JS world mostly ignores that stuff.
I have yet to try a real project with any of those python web tools. I know just enough HTML, vanilla JS and DOM API to cobble together ugly sites when I need to, so that's what I do. But I am optimistic that a better alternative will emerge eventually.
These tools are a waste of time. They take longer to learn then basic js and then in 3 years support is dropped you might have well learned a bit more js.
It's a bit big but just run nextjs, it solves almost everything for you. Even deployment is one click away. Would take 5 mins to get started. And a few hours to understand for a seasoned dev.
I honestly want to understand this viewpoint, so I can make informed decisions when looking at these tools. So let me ask...
I agree that some of these older python things are probably not worth using. But I'm a bit confused that you're entirely dismissing web assembly. I think it's well understood that using JavaScript as the foundation of front end software was a complete historical accident. It's a huge amount of inertia to compete with, but that doesn't mean it's insurmountable.
My understanding is that wasm is a major industry initiative, and it isn't going away. Emscripten seems to be nearly as stable. Now, maybe two or three non-js languages will emerge as the core of wasm-based development, and maybe python won't be in that small group. I'd rather learn, say, rust than continue writing JavaScript.
Where do you disagree? You think wasm will be shut down completely in a year? You think none of these languages will take off in terms of web-specific tooling? Something else?
Whether it was a mistake or not. It's taken over. And many people have worked hard to make it a modern language the last 20 years.
I've seen many attempts to take over js, thusfar they all failed. At the same time JS got more and more powerful.
Js is so integrated in every corporate it will not go away any time soon.
JS solves so many issues know and the css layout is much more mature than then any under native system (native apps, flash etc are much worse at responsive layouts)
Wasp sounds fun, it's very early stage and doesnt sound like it has anything to do with webpages but runs a binary in a browser sandbox. Kind of like flash without a plugin. Can have a lot of cool features, mainly games etc. But sounds like an addition not a replacement. But who knows!
I have been using JavaScript for decades, and I have never liked using it. I want to enjoy making interactive browser-based apps. Sorry that I don't buy into the cult of infinitely complex front end build tooling.
I tried using it a little bit but the reality is if you need JS to make your app more interactable it's really worth it to just learn some JS. As soon as you need something complex the extra layer of abstraction just gets in the way and becomes more of a headache, and if you don't need anything complex then you don't need a fancy JS solution in the first place.
JS only becomes complex when you are trying to create an enterprise version of your app along with a build platform. You can always just sprinkle in <script> tags in your HTML for simple one liners without getting into the weeds.
JS is a totally fine language. The entire browser ecosystem makes JS an incredible productive language for working on the web. You can disagree if you don't like the language personally but that doesn't change the fact JS gets the job done
I'm working on https://github.com/mayu-live/framework which is 100% server side Ruby. It's kinda like React/Preact, but server side, and Ruby. No JavaScript required (it's not even supported).
That's pretty neat. In general I think stuff like this is cool and works pretty well as a starter kit for simple CRUD apps if you don't already know Rails + JS, but like I said in my OP, once your app gets more complex, you hire some UX designers and you try to make your app more interactive, not having easy JS access makes it hard to do interesting things.
So could be useful for small projects but I wouldn't pick a solution like this for projects I would want to grow larger
Dealing with interactivity in the browser is subtle, complex and full of edge cases. JavaScript is also a horrible, broken language that’s not really fit for purpose. We’ve collectively invested a lot of time and resources trying to improve the experience of working with it, but the point still stands.
> And where are the equivalent libraries for Go, Rust and Java?
Not aware of anything yet for Go/Rust, but Java and Python have had libs like this for a while now (to the point that Pyjamas hasn't been updated in a decade):
* GWT (Java)
* Pyjamas (Python)
* Vaadin (Java)
Those are general purpose. After that you have the sci/data-oriented python frameworks like dash, streamlit, etc.
actually, as per the docs the framework is converting python code to Javascript. So you would need to JS skills to debug.
Most of the problems in web front have been solved in JS (think CSS styles, state management)
re-writting it in python would be pain, especially when everything compiles to js
Our goal is for the user to never have to see JS. We try to catch most errors in Python during compile time. We're also not trying to reinvent things like CSS styles, just make them accessible in Python.
That's not gonna happen if they have to solve browser runtime errors. And with there being so much variance between browsers and random nonsense to hack around, how can you possibly get around that?
Besides, python and js are so similar it's really funny to see people not wanting to use one but cling to the other.
Does this thing also convert python libraries for use on the web? Can it compile say keras or pytorch to javascript? I guess that would indeed be super neat to have on the browser client side.
I don't know much about Pynecone, but that is indeed what pyodide does:
> These include many general-purpose packages such as regex, pyyaml, lxml and scientific Python packages including numpy, pandas, scipy, matplotlib, and scikit-learn.
Again, not super familiar, so I don't know the level of effort required to support these libraries. Maybe adding pytorch would be infeasible, maybe they just need enough people to express interest.
These days, in the .NET ecosystem, there is Blazor. You write your whole web app in HTML, CSS and C# (frontend and backend). There are several different deployment models; Wikipedia gives a good summary:
You may not realise this, but this post is about a framework that let's python devs make modern web apps without touching the JS ecosystem.
The root comment appreciates the framework, and shares their unwillingness to write JavaScript and HTML. The reply to that comment asks why don't they try TypeScript.
I think that reply is absurd because asking someone to write TypeScript when they dislike JavaScript in the first place is absurd.
I know and realise the fact that JS+Types is way better than plain JS, and infact I write TypeScript on everyday basis.
> I think that reply is absurd because asking someone to write TypeScript when they dislike JavaScript in the first place is absurd.
I don't think it's absurd to ask someone to try Typescript first before jumping through hoops just to make Python run on the web, which certainly brings a lot of problems of its own. You do have to actually try it to see how it's a completely different experience, even if the types are just bolted on.
Hmm? In 90s and 2000s most web frameworks did not rely on JS at all, they were completely server-side. I.e. the server renders a page. User clicks a button, browser collects data from a form and sends request to the server. The server updates its state and renders a new page. There are some downsides to that approach, but it can be pretty good if you just need to get some information and/or let user browse a data collection.
Compile-to-JS approach started to appear in mid 2000s.
Maybe I am an optimist, but I'd say Vaadin is mostly Open Source (Apache License). You can build complete web applications with the open source version. Only some advanced components (e.g. an Excel-like grid, a WYSIWYG editor, Highcharts components) are proprietary and require a subscription for development, while the builds can be freely distributed.
Nope, but something better, e.g. Leptos for Rust which enables you to write Rust code and RsX (JsX equivalent) that runs on the server until all WASM is loaded to run it in the browser
Hi, I really enjoyed the piece! How much to test at each layer of abstraction has always been something that's bugged me. This article provides a nice strategy.
I still have questions about a few scenarios though. Let's say, I have two classes like this:
class KeyValueStore {
int64 Get(Key key);
};
class CachingKeyValueStore {
CachingKeyValueStore(const KeyValueStore& wrapped);
int64 Get(Key key);
}
Here, the `CachingKeyValueStore` class is a wrapper around the `KeyValueStore` class, and its purpose is to simply maintain an in-memory cache (instead of RPC calls or Database calls). How would you unit test the `CachingKeyValueStore` class? So far, using Mocks have been my only strategy, because behavior-wise, both classes have the exact same outputs for the same inputs.
The behavioral difference between Caching KeyValue Store and KeyValueStore is that it doesn't fetch from the underlying data source when called a second time. So that's what I would test. Given the signature you provided, I would either instrument KeyValueStore so I could tell if it had been run twice, or (if KeyValueStore has multiple implementations) I might create a ExampleKeyValueStore in my tests that had that instrumentation.
I solved this problem a bit differently in my code, though. Instead of making a CachingKeyValueStore, I made a MemoryCache. It has a get() method that takes a key and a function. The first time it's called, it runs the function; the second time, it returns the stored result. Here's one of my actual tests for that code (JavaScript):
it("caches result of function, so it's only run once", async function() {
const cache = createIndependentCache();
let runCount = 0;
const getFn = () => runCount++;
await cache.getAsync(NULL_LOG, "key", getFn);
await cache.getAsync(NULL_LOG, "key", getFn);
assert.equal(runCount, 1);
});
And in case you’re curious, here’s the implementation, excluding a bunch of instrumentation and logging:
You probably should have some additional tests around the CachingKeyValueStore related to eviction and size. Maybe this doesn't matter very often, but you should at least test the behavior of your Caching store if when the cache size is only, e.g. 1 item.
You can either do this by passing in a mock KVStore, or by passing in a normal/fake KV store in which you can update the underlying data. So for example:
data = ...
kv = new KVStore(data)
cache = new CachingKVStore(kv, cache_size=1)
v = cache.get(k1)
data.update(k1, new_value)
v2 = cache.get(k1)
assert v2 == v1 // Cached!
v3 = cache.get(k2) // evict k1
v4 = cache.get(k1)
assert v4 != v1
assert v4 == new_value // Gets the new value
Otherwise, yeah for some cases like this you can just inherit from the KVStore test class and run all the same tests with a slightly different set up method to use a caching store instead.
I would use a mock for the wrapped instance that generates a strong random value on each call to “Get”.
Then I would do some basic unit tests and maybe property based testing given that the only way for the same value to appear on subsequent “Get” calls is for caching to have occurred.
What I really find interesting here is that PyTorch, a library maintained by Facebook, is winning the marketshare and mindshare due to clean API, whereas Tensorflow, maintained by Google, is losing due to inferior API. In general, Google as a company emphasizes code quality and best practices far more than Facebook. But the story was reversed here.
Google's stereotype is the company that can handle and manage complexity - things like Kubernetes, indexing the internet, etc. They are clumsy at persuading people to use their products and have a patchy history of launching platforms that people want to use. Google+ and Google cloud vs AWS spring to mind, Kubernetes is a good platform but challenging to learn. Chrome is an unusual aberration where they did a great job. Android is maybe also a strong counterexample, not sure what the state of play was there.
But whatever their code quality may be, luring in devs to their API has seen hits and misses.
They did a pretty good job in persuading people to use search, adsense, YouTube, Gmail, Maps and a bunch of other products.
Singling out a few couple of the less successful ones to claim a trillion dollar company is “clumsy at persuading people to use their products” seems like a pretty bad take.
You'll note that all the examples you're citing were released more than a decade ago (search wasn't even this century!). And YouTube was an acquisition. They were basically the work of a different Google to the one that is walking around now.
The stereotype of Google back then was very different. People would quote things like "don't be evil".
The only products you listed which weren’t acquisitions are search and gmail. Search is exactly the problem Google was made to handle and Gmail.. well I don’t love gmail but it is a good enough product I guess?
The way Android NDK and AGK experience works, I always have the feeling it is maintained as a 20% project and none of the developers has ever used anything from the competition.
Couldn’t these organizations be big enough to have different technical cultures from team-to-team or product-to-product?
If that’s the case comparing FAANG to each other is like comparing Asia to Europe and then taking North-Korea and Portugal as examples.
> In general, Google as a company emphasizes code quality and best practices far more
That doesn't automatically have to mean better DX. For example the API can be clean, but too low level to conveniently accomplish typical cases (I'm not familiar with this example).
And ML compilers in the form of IREE/MLIR, which if successful in delivering hw and framework optionality, should make ML frameworks a far less consequential decision.
> Are all crimes, right? Banks will take your consumer money (provider management does get more complicated) for gambling and porn these days
Not necessarily. For example, PayPal has recently introduced "acceptable use policy" where they can freeze your account without you violating the law. Banks also have done the same for being "racist", "sexist", "anti-vaxx" etc. All of those things are perfectly legal in the US. So your assertion that only illegal activities require use of crypto is false.
And that's before we get to the fact that just because something is "illegal" doesn't mean it's good to have this banned. Pretty sure the ongoing Iranian protests are illegal.
> just because something is "illegal" doesn't mean it's good to have this banned
No, but it means that the question has nothing to do with money. Using BTC to launder or evade tracking for a transaction that is illegal is simply committing another crime. If you want to be free of prosecution, talk to your government, don't just cheat and figure it's OK because it's crypto. That's how you end up in jail.
First of all, the fact that you completely ignored the first point about perfectly legal "racist", "sexist", "anti-vaxx" behavior being enough to get you banned from PayPal/banks means you accept that there are valid LEGAL use cases of crypto.
As for your suggestion to "talk to your government", yeah I'm sure that will go down well with the Iranian regime trying to crack down on anti-hijab protestors.
Can you maybe cite the folks who are using crypto out of necessity instead of banking with money? Someone getting PayPal miffed at them isn't remotely the same thing as "can't use money", and I think you know that.
What you're doing is extrapolating from "some people sometimes have trouble with a bank" (true) to "the only way to evade oppressive banking censorship is crypto" (bananas).
Or rather, the second frame is true, for a certain subset of transactions that happen to be illegal.
I don't have examples of people getting banned by banks/PayPal for legal activities using crypto, no. But that doesn't mean crypto-based solutions can't fill that void in the future. Note that I never claimed crypto is the "only way" to solve this issue. But, it's a promising alternative. Any centralized solution for these use-cases are tricky because they're niche and don't probably have the necessary scale. Not to mention, any centralized solution is always carries censorship risks. If you have a decentralized, usable, non-crypto alternatives for these cases, I'm open ears.
