972 karma · joined June 18, 2018
It doesn't mean that you don't use javascript at all, you just use it in a limited fashion for enhancing specific bits of your website. Just like it was in the 2000s when making websites was easy.
https://alistapart.com/article/the-future-of-web-software-is...
HN discussion: https://news.ycombinator.com/item?id=26265999
I find developments in this area very exciting as I'm sick of dealing with layers and the required tedious glue you have to write to join them together.
It seems like you're trying to use SQLite as an example of something you don't want to end up with. This seems backwards so it weakens your argument. SQLite is one of the most widely deployed, reliable, broadly applicable and all round useful pieces of software ever written.
> RCS - 1982 CVS - 1990
I don't accept CVS as a breakthrough in the same way as git has been. Back in 2000 - 10 years after CVS - using source control wasn't a given. We had articles like "The Joel Test"[1] encouraging teams to use source control. CVS was a pain to set up and limited once you did. Thanks to git (and DVCS in general) using source control is the default for 1 person throwaway projects up to projects with thousands of contributors and million lines of code.
[1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
1. Stack Overflow - search for your problem, copy and paste the answer.
2. git - Revision control that is low enough overhead that you need to have a reason not to use it.
3. Open-source software as a commodity - Unless you've got very specific requirements there's probably a system that can do most of your heavy lifting. (Almost) no-one writes their own JSON parsers or databases or web frameworks. Using open-source software is low overhead and low risk compared to engaging with some vendor for the same.
4. Package managers - By making it easy to include other peoples code we lower the bar to doing so.
The common thread here is code-reuse. None of the above are programming languages, but all have driven productivity in building systems and solving problems.
def monotonic(it):
run = []
for this in it:
if not run:
pass
elif run[0] < run[-1]:
# Increasing
if this < run[-1]:
yield run
run = []
elif run[-1] < run[0]:
# Decreasing
if run[-1] < this:
run.reverse()
yield run
run = []
run.append(this)
if run:
if run[0] <= run[-1]:
# Increasing
yield run
else:
run.reverse()
yield run
The trick I've applied is that we don't explicitly keep track of whether we're increasing, decreasing or undecided. Instead we check the run in progress.
> * Improved software WebRender performance
This sounds interesting. Does anyone know where I could read more about this?
> While hard links are certainly a lesser evil than setuid, and there is little motivation to rid ourselves of them, they do serve to illustrate how a seemingly clever and useful design can have a range of side effects which can weigh heavily against the value that the design tries to bring.
It feels like I spend more time now waiting for the computer than I did then. It's the same with the phone - click, wait, click, wait, click, wait. For a taste of what it could be like try running Windows 2000 in a VM. Zoooooooom.
Why? Developers will only optimise their software when it becomes unbearably slow - and in the absence of automated performance tracking and eternal vigilance software gets slower over time. The result is that there is no reason* to get excited about CPU advances. It doesn't make your life better, it's just a cost you have to pay to stop your life getting worse.
* Sure there are some reasons - if you're already using/dependant upon heavily optimised software like games or machine learning, but for most people that's a very small part of their computing use.
> In absence of a standard effectively every language construct is 'implementation defined behaviour'.
But the parent said:
> In absence of a standard effectively every language construct is 'undefined behavior'.
Undefined behaviour != implementation defined behaviour. Both of these things exist in C and are separate. You can rely on implementation defined behaviour giving some consistent result on a given, compiler and hardware. You cannot rely on the behaviour of your program if you hit undefined behaviour.
For more see: https://blog.regehr.org/archives/213 and https://raphlinus.github.io/programming/rust/2018/08/17/unde... .
Mentioned this comment here: https://blog.williammanley.net/2021/03/31/seen-on-hn-invert-...
You’d need to implement a new protocol between terminal and shell. Maybe the shell would be in charge - allocating PTYs and multiplexing the output back to the terminal. Or maybe the terminal would be in charge where it would allocate PTYs for children and send them to the shell using FD passing. There are advantages both ways.
Integral to its success though would be getting the support for this new protocol upstream in bash. Bash is the most widely deployed shell and the only way to get to the point where you can log in to a new machine (or over SSH) and expect this to “just work”. Without that it would remain a niche and could join the graveyard of other improved shells/terminals that approximately no-one uses.
As such the protocol would have to be minimal and easily implementable in C. Systemd’s protocols could be an inspiration. I’ve implemented both sides of sd_notify and LISTEN_FDS before, in more than one programming language and it was very straightforward.
[DJB disagrees](https://cr.yp.to/djbdns/ipv6mess.html). Quote:
>The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
> Either you're C-compatible or you're not.
If we take this black and white approach then we must say that C++ is not C compatible just like Ada isn't C compatible.
The reality is that C++ being broadly a superset of C was integral to its adoption, even though that compatibility isn't perfect. It enabled easy incremental porting of projects.
This is really just a nit though. I do agree with your conclusions.
Your project is far more likely to die within a couple of years from having too few users than from having too many. If you find you're having scaling issues then that's a good time to solve them - your project is popular enough to justify the investment.
You'll likely be recoding your project quite a lot in the early phase of the development anyway as you learn more about the problem and (most importantly) more about what your users want/need. Anything that can reduce the cost of this early iteration will pay dividends later because it makes it more likely that you'll need to scale - and by the time you do need to scale you'll be scaling something that you understand and other people want.
Discussion of this article on the rust subreddit: https://www.reddit.com/r/rust/comments/czn3mx/how_rust_optim...