241–250 of 355 posts
> This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app I would love to hear what tech stack (or stacks) the HN community thinks currently allows a small team to move fastest for this type of product.
I guess nodejs might also be throw into the party, as it is anyway needed for many SPA frameworks, and for better or worse, Go, given its relevance on DevOps space.
Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…
PHP, Java and .NET have been doing it for 20 years, more or less.
Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…
But here's something to really chew on. Do we need the HTTP server at all?
Consider: why exactly do we need so much middleware plumbing for ordinary database driven web apps? A lot of this is to do with a winding evolutionary path rather than what you'd design with a clean slate.
Something I've been experimenting with lately is writing apps that connect directly to an RDBMS using its native protocol, over the internet, from a desktop app. Obvs the next step after is to try the same with a mobile app. Historically we've relied on web browsers and written translation layers for a few different reasons, but tech has been improving over time and some of those reasons are becoming obsolete:
1. Free relational databases were really rough back then and the commercial DBs often had weird limitations around distributing DB drivers. These days it's easier and postgres is a lot better.
2. You needed to slather lots of caches and other stuff in front of the RDBMS if you had high traffic. Modern DBs are a lot better at materialized views, cached query plans, read replicas etc. Postgres has a variety of load balancers that can sit in front of it and work around its per-connection overhead.
3. Security wasn't good enough. Nowadays you have features like row level security, security-definer views etc in the free DBs.
4. People translate everything to HTML/HTTP partly because it was too hard to distribute and update apps to Windows desktops/laptops in the 2000s, due to MS just generally losing the ability to execute and being distracted by stuff like Longhorn/WinFS. Browsers solved the basics of caching and refreshing of code for you. Now there's https://conveyor.hydraulic.dev/ which makes distributing desktop apps way easier. It's a lot more feasible now to just knock out a quick desktop app and upload to an S3 bucket, with built in online updates. Also the next release will support force-update-on-start, so you can get a web like experience where the user is always up to date so the schemas and client can be evolved in parallel.
If you could just write your UI using a 'real' UI toolkit and invoke directly to the DB from the UI code, you wouldn't need a lot of the microservices plumbing anymore, you wouldn't need to serialize stuff to JSON or HTML. You could just use the underlying DB protocol as an RPC layer and let the DB enforce business logic. It can be done for common kinds of enterprise apps today: there are only a few problems to solve, none of them especially hard. For instance a little service that turned OAuth SSO into client side certificates would make it easy to connect to a DB without needing to manage usernames or passwords. A tunnelling solution to get through awkward firewalls would also be useful (websockets etc).
For consumer apps there's more complexity. You wouldn't try to implement twitter that way for instance. But still, for the kind of SaaS-y thing that the article is about it could have saved a lot of complexity and improved iteration speed.
Earlier quoted context omitted.
I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly. I don’t think that’s any better in Rust though.
Rust has many convenient shorthands like the ? operator, where `let x = foo()?` is equivalent to let x = match foo() { Ok(value) -> value, Err(e) -> return Err(e), }
let x = match foo() {
Ok(value) -> value,
Err(e) -> return Err(e.into()),
}
As usual, very sad to see how little C# is mentioned as an alternative, having very robust, easy to use and performant stack of standard and third-party libraries for building the exact scenario outlined in the article. Especially that is has first-class support for gRPC, runs on every cloud/on-prem host you can think of and doesn't force you to go out of your way to get most performance out of your implementation. P…
Earlier quoted context omitted.
The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Ru…
You can find a GC language that does all those things that rust does but without: 1. The risk of future unsafety (a GC language will always safer than rust) 2. Faster development that's easier to change on a dime. 3. No risk of memory leaks (which can happen in safe rust)
[citation needed]
> 2. Faster development that's easier to change on a dime.
Yes, development can be faster at the expense of safety, which is a trade-off that favors the use of other languages at early company stages. Agreed here.
> 3. No risk of memory leaks (which can happen in safe rust)
... at the expense of making collection non-deterministic and significantly more resource intensive. Not to mention that the non-determinism means you generally end up grafting your own resource management scheme on top. I've never seen a company that hasn't at some point had someone crying over GC tuning. Leaks are safe (which is why they're allowed in safe Rust) and generally speaking both a non-issue - and very easy to track down.
Rust has been my daily driver at home since like 2015, and I have to say, I've never once gone "man you know what this thing needs? Shenandoah." I write a bunch of Kotlin too, for what it's worth.
These trade-offs are well known and there are pros and cons to both.
Earlier quoted context omitted.
The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Ru…
C++ already has that problem sorted out with Conan and vcpkg.
Like a lot of C++ things there's a big theme of "can we have X? we have X at home. X at home: o_O"
Earlier quoted context omitted.
C++ doesn't have a Rust-like ownership/borrow system.
I think you meant “borrow checker” because sure it does. It’s called a const reference. Want a mut borrow? That’s a pointer. That Rust can check these somewhat more explicitly (rather than via good coding style) and that C++ also allows you to do arbitrary permutations (a la non-const references) is what you’re talking about. But ownership is very very real in C++! Just look at the craziness that is move semantics!
These have very different semantics. Lexically you can only have either 1 mutable reference or N immutable references at a time to a given object. This is the foundation for a lot of the safety and aliasing [2] guarantees. Just because they both use an '&' doesn't make them equivalent! :)
Don't get my started on `std::move` which doesn't really move, and continues to allow you to use the source object - in whatever condition it may be in. These are also not the same. C++ move semantics are sort of the 'ruined fresco' [1] of Rust move semantics.
[1] https://www.npr.org/sections/thetwo-way/2012/09/20/161466361...
Earlier quoted context omitted.
The CEO wanted to move fast and break things with respect to security but offered a $2 million bug bounty?
I am not sure how those aren't incompatible thoughts... I was explicitly told, by the CEO, that she was channeling that mindset, and the security engineer there I ended up speaking to was clearly not bothering to actually figure out how to filter change sets made by their engineer as he "felt bad" about it... and I kind of don't blame them, as to the winners go the spoils in some sense? They were super lucky I was th…