Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise of Worse Is Better (1991)

dreamsongs.com

Post reply on HN
Print view View original

341–350 of 351 posts

Re: The Rise of Worse Is Better (1991)

#341

Post by kragen »

ahoka wrote: post #196
PhilipRoman wrote: post #156

Earlier quoted context omitted.

IMO the OSI layer system (even though using TCP/IP suite) has some merit in education. To most of us, the concept of layering protocols may seem obvious, but I've talked to people who are just learning this stuff, and they have a lot of trouble understanding it. Emphasizing that each layer is (in theory) cleanly separated and doesn't know about layers above and below, is a very useful step towards understanding abstr…

The problem is that this is not true. There are no such clean strictly hierarchical layers in most of the protocols that make up the internet.

There are; VNC doesn't know about IP, for example, and TCP doesn't know about Ethernet. IP is just as happy to run over PPP or Wireguard as over Ethernet. HTTP/1 knows about TCP/IP, but only a little bit, and you can easily run HTTP/1 over other protocols like TLS. Character-cell terminal protocols know very little indeed about the protocol layer under them and work almost equally well over telnet, rsh, SSH, a serial port, a modem, or a bare pseudo-TTY, the main surviving exception being window resize handling.

The problem is that ① the layers don't have a fixed relationship to each other the way the OSI model proposes, ② several of the OSI layers don't exist at all in real-life TCP/IP protocols, and ③ there are other layers in current stacks that have no analogue in the OSI model, like Wireguard, MPLS, SSH, TLS, and HTTP. If you want to understand the services HTTP provides to the protocols that ride on top of it, you need to read Roy Fielding's thesis, not X.225.

Re: The Rise of Worse Is Better (1991)

#342

Post by Valord »

epcoa wrote: post #334
bccdee wrote: post #333

Earlier quoted context omitted.

Go is an incremental improvement over Java and C#. I like it, but it tried extremely hard not to break new ground, and it succeeded at that. Java and Ruby and Python (odd how all these languages came out at almost the exactly the same time) had new ideas and new paradigms, like Rust does. Part of what I mean by "making a big impact" is affecting how we think about programs, which Rust has done and Go has not.

Go is an incremental improvement over C#?? I think you’re going to find quite a bit of controversy with that take. I think Go focusing on certain aspects of tooling and deployment early on might be considered improvements on C#/.NET (some, not all). There are aspects of the Golang standard library that are better designed for purpose than C#/.NET (Again even this has to be nuanced because quite a few 3rd party librar…

I agree that Go is not an improvement over C#. In my experience the language ergonomics of C# are better than Go. I've done both in industry and am much more productive with C#. It is too bad that C# and .NET are often perceived as bad because of Microsoft & Windows. .NET core has a lot of really things going on.

Not that Go is a bad language. It has its place. I recommend it for embedded systems and as an option for systems programming.

Re: The Rise of Worse Is Better (1991)

#343

Post by steveklabnik »

hollerith wrote: post #335
steveklabnik wrote: post #180

Earlier quoted context omitted.

The compiler doesn't do a whole lot to try and minimize LLVM-IR, and monomorphization produces quite a lot of it. This makes LLVM do a lot of work. (EDIT: maybe that's being too harsh, but what I mean is, there's been some work towards doing this but more that could possibly be done, but it's not a trivial problem.) On my current project, "cargo check" takes ten seconds, and "cargo build" takes 16. That's 62.5% of th…

Have you heard of anyone proposing to add to rustc a flag or an attribute that would cause a generic type to be implemented by a dispatch at run time to avoid monomorphization and consequently decrease compile time?

It’s been discussed, but not every trait is object safe, so it’s not a trivial task.

Re: The Rise of Worse Is Better (1991)

#344

Post by bccdee »

Valord wrote: post #342
epcoa wrote: post #334

Earlier quoted context omitted.

Go is an incremental improvement over C#?? I think you’re going to find quite a bit of controversy with that take. I think Go focusing on certain aspects of tooling and deployment early on might be considered improvements on C#/.NET (some, not all). There are aspects of the Golang standard library that are better designed for purpose than C#/.NET (Again even this has to be nuanced because quite a few 3rd party librar…

I agree that Go is not an improvement over C#. In my experience the language ergonomics of C# are better than Go. I've done both in industry and am much more productive with C#. It is too bad that C# and .NET are often perceived as bad because of Microsoft & Windows. .NET core has a lot of really things going on. Not that Go is a bad language. It has its place. I recommend it for embedded systems and as an option for…

Yeah I should clarify that Go considers itself to be an incremental improvement on the Java/C# paradigm. You could certainly argue that it oversimplifies things.

Re: The Rise of Worse Is Better (1991)

#345

Post by bccdee »

epcoa wrote: post #334
bccdee wrote: post #333

Earlier quoted context omitted.

Go is an incremental improvement over Java and C#. I like it, but it tried extremely hard not to break new ground, and it succeeded at that. Java and Ruby and Python (odd how all these languages came out at almost the exactly the same time) had new ideas and new paradigms, like Rust does. Part of what I mean by "making a big impact" is affecting how we think about programs, which Rust has done and Go has not.

Go is an incremental improvement over C#?? I think you’re going to find quite a bit of controversy with that take. I think Go focusing on certain aspects of tooling and deployment early on might be considered improvements on C#/.NET (some, not all). There are aspects of the Golang standard library that are better designed for purpose than C#/.NET (Again even this has to be nuanced because quite a few 3rd party librar…

I'm not arguing that Go wasn't well-made. But "having good tooling early on" isn't a new paradigm. Neither is message-based concurrency.

The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language. I'm not saying nobody had thought about these things before, but as you said, C++ can't enforce any of it. Rust can.

When Python hit the market, it was competing with C++ for web dev, and the difference there is massive, because Python is dramatically simpler and more expressive. Java was fast, cross-platform and GC'd, and that also makes a massive difference as compared to C++. When you compare Rust with C++, Rust entirely eliminates dangerous categories of errors without the cost of a GC, and that's a big deal too.

Conversely, if you want to discuss Go vs C#, you can have a long talk about expressiveness and simplicity and it'll ultimately be mostly subjective unless you have a specific use case in mind. I like Go because it's less invested in object orientation than C# is, but Go isn't doing something transformatively new. It's just kinda nicer in some ways.

If Rust didn't guarantee memory safety, it would never have gotten into the Linux kernel. It'd fall into the same category as Go, Swift, D, Clojure, Nim, Zig, and every other programming language with good ideas but no killer value proposition. If Go didn't have Google's backing, it would never have seen mass adoption, because language choice is conservative. Picking something new is risky, and unless it has a big benefit or a big backer, people are going to avoid it where possible.

Re: The Rise of Worse Is Better (1991)

#346

Post by epcoa »

bccdee wrote: post #345
epcoa wrote: post #334

Earlier quoted context omitted.

Go is an incremental improvement over C#?? I think you’re going to find quite a bit of controversy with that take. I think Go focusing on certain aspects of tooling and deployment early on might be considered improvements on C#/.NET (some, not all). There are aspects of the Golang standard library that are better designed for purpose than C#/.NET (Again even this has to be nuanced because quite a few 3rd party librar…

I'm not arguing that Go wasn't well-made. But "having good tooling early on" isn't a new paradigm. Neither is message-based concurrency. The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language. I'm not saying nobody had thought about these things before, but as you said, C++ can't enforce any of it. Rust can. When Python hit the market, it was competing with C++ for w…

> Neither is message-based concurrency.

The design and mechanics of goroutines are pretty unique to Go among its commonly used contemporaries.

> The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language.

Ada and SPARK? Clearly Rust has become more “mainstream” and popular that’s not the argument (though both have had significant niche commercial success, they’re not obscure), just that the narrative comes across a bit reductionist.

Re: The Rise of Worse Is Better (1991)

#347

Post by bccdee »

epcoa wrote: post #346
bccdee wrote: post #345

Earlier quoted context omitted.

I'm not arguing that Go wasn't well-made. But "having good tooling early on" isn't a new paradigm. Neither is message-based concurrency. The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language. I'm not saying nobody had thought about these things before, but as you said, C++ can't enforce any of it. Rust can. When Python hit the market, it was competing with C++ for w…

> Neither is message-based concurrency. The design and mechanics of goroutines are pretty unique to Go among its commonly used contemporaries. > The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language. Ada and SPARK? Clearly Rust has become more “mainstream” and popular that’s not the argument (though both have had significant niche commercial success, they’re not obs…

I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety. So I looked it up, and the first result was a paper called "Safe Dynamic Memory Management in Ada and SPARK" [1]. Here's a quote (emphasis mine):

> In this work, we propose a restricted form of pointers for Ada that is safe enough to be included in the SPARK subset. As our main contribution, we show how to adapt the ideas underlying the safe pointers from permission-based languages like Rust or ParaSail, to safely restrict the use of pointers in more traditional imperative languages like Ada. In section 2, we provide rationale for the rules that we propose to include in the next version of Ada, which takes into account specifics of Ada such as by-copy/by-reference parameter passing and exception handling. In section 3, we outline how these rules make it possible to formally verify SPARK programs using such pointers. Finally, we present related work and conclude.

> Section 2: A Proposal for Ownership Types in Ada

If Ada and SPARK are now taking inspiration from Rust with regard to safe memory management, I think that's enough to demonstrate that Rust's ownership system is substantially novel, relative to Ada and SPARK.

Re: The Rise of Worse Is Better (1991)

#348

Post by epcoa »

bccdee wrote: post #347
epcoa wrote: post #346

Earlier quoted context omitted.

> Neither is message-based concurrency. The design and mechanics of goroutines are pretty unique to Go among its commonly used contemporaries. > The new paradigm Rust introduced was compiler-enforced memory and concurrency safety in a non-GC language. Ada and SPARK? Clearly Rust has become more “mainstream” and popular that’s not the argument (though both have had significant niche commercial success, they’re not obs…

I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety. So I looked it up, and the first result was a paper called "Safe Dynamic Memory Management in Ada and SPARK" [1]. Here's a quote (emphasis mine): > In this work, we propose a restricted form of pointers for Ada that is safe enough to be included in the SPARK subset. As our main contribution, we sh…

> I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety.

The point for bringing up Ada was more that a non-academic "memory-safe" language without GC existed for decades (predating Linux). Old school Ada doesn't use the ownership system, and true doesn't give all the compile-time safety guarantees of Rust but it does give some (and rust in practice cant't either, run the output of grep unsafe | wc on the linux/rust source tree), it also provides some affordances lacking in safe rust. Memory-safety is not some binary or univariate concept that you seem somewhat close to implying. You could have written Linux in Ada from day one and been "safer" than C (imagine that universe).

Related:

https://pling.jondgoodwin.com/post/cyclone/ (which is also referred to in the aforementioned paper).

> I think that's enough to demonstrate that Rust's ownership system is substantially novel

Well, where did anyone say it wasn't, but it certainly wasn't novel in pushing safety as a first class concept for a low level systems language. The fact that it is as (deservedly) successful as it is must be due to other factors. I'm not saying Ada did it first as some kind of gotcha, but Ada did it first and it does not rule the world.

Also, interesting comments from the creator of Rust.

https://www.reddit.com/r/rust/comments/t9972l/comment/hztbsn...

https://www.reddit.com/r/rust/comments/le7m54/comment/gmb4zg...

I'll reiterate, I'm very pro-Rust. I'm just old and look at the current governance and state of corporate involvement and it gives me flashbacks to commercial Unix in the late 80s/early 90s. IIn any case, I think fetishizing the borrow checker or a specific PL feature as having much to with its success (or failure) is sort of irrelevant.

Re: The Rise of Worse Is Better (1991)

#349

Post by bccdee »

epcoa wrote: post #348
bccdee wrote: post #347

Earlier quoted context omitted.

I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety. So I looked it up, and the first result was a paper called "Safe Dynamic Memory Management in Ada and SPARK" [1]. Here's a quote (emphasis mine): > In this work, we propose a restricted form of pointers for Ada that is safe enough to be included in the SPARK subset. As our main contribution, we sh…

> I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety. The point for bringing up Ada was more that a non-academic "memory-safe" language without GC existed for decades (predating Linux). Old school Ada doesn't use the ownership system, and true doesn't give all the compile-time safety guarantees of Rust but it does give some (and rust in practice ca…

> Ada did it first and it does not rule the world.

Well I mean, Ada didn't do "it" first—"it" being whatever Rust did that led to it making such a big splash. If Ada had done that first, it would have made the kind of splash that Rust has. Rust isn't the first systems language to ever consider being safer than C, but it is the first one to have such a large impact, and I think that's a product, primarily, of its technical decisions.

> I think fetishizing the borrow checker or a specific PL feature as having much to with its success (or failure) is sort of irrelevant.

I think that's an odd stance. Why would the technical specs of a language be irrelevant to its success? I think that's probably the most relevant factor, besides an institutional backer. C# was pushed hard by Microsoft and Go got a lot of support from Google. Rust wasn't part of an major tech player's pre-existing ecosystem, though, so it had to succeed on technical merit alone. None of its ideas are really that new except the borrow checker, and most of the time, when I've seen an institution talk about adopting Rust, there's been a lot of focus on the safety afforded by the borrow checker. I don't think that can be a coincidence.

That's not "fetishization." When a programming language with one new idea and little institutional backing gains traction in the mainstream, it's probably because that new idea in particular has a lot of merit.

Re: The Rise of Worse Is Better (1991)

#350

Post by epcoa »

bccdee wrote: post #349
epcoa wrote: post #348

Earlier quoted context omitted.

> I was familiar with Ada, but I wasn't aware that it had an ownership system like Rust that could guarantee memory safety. The point for bringing up Ada was more that a non-academic "memory-safe" language without GC existed for decades (predating Linux). Old school Ada doesn't use the ownership system, and true doesn't give all the compile-time safety guarantees of Rust but it does give some (and rust in practice ca…

> Ada did it first and it does not rule the world. Well I mean, Ada didn't do "it" first—"it" being whatever Rust did that led to it making such a big splash. If Ada had done that first, it would have made the kind of splash that Rust has. Rust isn't the first systems language to ever consider being safer than C, but it is the first one to have such a large impact, and I think that's a product, primarily, of its tech…

> Ada didn't do "it" first

It did the safety thing first, or at least much earlier.

> Rust wasn't part of an major tech player's pre-existing ecosystem,

Completely overlooking Mozilla’s backing early on is too extreme. Mozilla pumped a ton of money that got Rust off the ground. And of course even now the Rust Foundation isn’t poor or something.

Despite Google employing the Go people, not really part of their “ecosystem” for years either. They really hedged on that one. Go popularity mostly grew outside of Google for years

But yes both projects have/had plenty of money. This isn’t Nim or Lua or something.

> when I've seen an institution talk about adopting Rust, there's been a lot of focus on the safety afforded by the borrow checker.

So why did they just start caring about safety this recently?

> it's probably because that new idea in particular has a lot of merit.

The point is “safety” for a low level system language wasn’t a new idea at all, it was just that the world outside did not value/demand it.

> That's not "fetishization."

The fetishization I am referring to is focusing on the memory safety so far above the type system, tooling, open community building, and even the syntax. Conversely Rust can’t manage to have an ABI past extern “C”. Never said technical specs are irrelevant, that’s a straw man.

And finally, again this all to say, I think its memory safety story is not what is going to determine its fate and destiny in the next decade. It needs to evolve, this is more about governance than about a particular feature. That rust in Linux depends on unstable isn’t end of the world, it’s not something to be proud of either.

I think it’s naive to think things like Carbon don’t have some competitive effects either.

To touch back on “it's still a relatively young language.” Java, C#, Swift and Go were all well established in their niches younger than Rust. But, it really doesn’t matter one whit if Rust is 5 or 35. I’m more interested in the present trajectory and where and why Rust struggles or has struggled to make inroads, not everything is fair to chalk up to just age IMHO.

Post reply on HN