161–170 of 190 posts
FYI, this rant is from January 2015. Surprised to see it showing on HN today. If anyone is interested in what he removed, you can find it here: https://web.archive.org/web/20150101224641/http://c.learncod...
Zed is frustrating sometimes.
Do remember that this guy wrote: "I’ve more or less kept my mouth shut about some of the dumb and plain evil stuff that goes on in the Rails community. As things would happen though I’d take notes, collect logs, and started writing this little essay. As soon as I was stable and didn’t need Ruby on Rails to survive I told myself I’d revamp my blog and expose these fucks." and: "After Mongrel I couldn’t get a gang of m…
I don't think bringing out a list of generically outrageous things someone said in the past rises to the level of discourse we're trying for here. We detached this subthread from https://news.ycombinator.com/item?id=11727718 and marked it off-topic.
Earlier quoted context omitted.
Go is unsuitable as a replacement for C because it is garbage collected. End of discussion. Rust is unsuitable as a replacement for C because its memory management is poorly thought out (ie. its a joke). Here's the relevant paragraphs from the Rust FAQ. Really? "Rust avoids the need for GC through its system of ownership and borrowing, but that same system helps with a host of other problems, including resource manag…
You don't describe why you think it's a joke.
FYI, this rant is from January 2015. Surprised to see it showing on HN today. If anyone is interested in what he removed, you can find it here: https://web.archive.org/web/20150101224641/http://c.learncod...
It wasn't obvious when this dates from, but we'll take your word for it and add 2015 to the title.
https://web.archive.org/web/20150106191636/http://c.learncod...
Earlier quoted context omitted.
You don't describe why you think it's a joke.
Steve - did you read the FAQ? They really don't know what direction to go. At least Swift stuck with ARC, being a necessity as they were tasked with merging Swift with the Objective-C runtime for interoperability. Rust's multiple methods of memory management makes it strange, at best, for programmers to decide how to build a program or an API. Are the owners of Rust planning on adding a GC? Really?
> They really don't know what direction to go.
Does the presence of libraries for refcounting or even GC in C (most famously Boehm) mean that C has an incoherent story around memory?
> Rust's multiple methods of memory management makes it strange, at best,
> for programmers to decide how to build a program or an API.
> Are the owners of Rust planning on adding a GC? Really?
The second is something like Bohem: if a system wants to use GC for some reason, they have an interface to add a GC'd type. But Rust proper, the language, will not have GC. It's completely contradictory to the goals of the language.
Earlier quoted context omitted.
What in particular makes Rust (or Go or Swift) unsuitable?
GC languages are almost certainly not even in consideration for most embedded applications. There aren't good strategies for general garbage collection that don't insert random pauses for starters, and you also have a non-negligible impact on RAM usage on systems where RAM might be a premium. A lot of the things rust brings to the table aren't always relevant on embedded platforms. Dynamic memory allocation on embedd…
In that case, you can simply not use the dynamic allocation features of Rust, just as you can simply not use malloc() in C.
This is obviously a bitter rant, and devolves into uncomfortably ageist territory about halfway through. I do agree that we should be moving away from C and C++, though. It's pretty simple, really: C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. It now makes sense to revisit those decisions in light of nearly 40 years of practice. The so-called "PL Renaissance" has…
> C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. We also have nearly 40 years of infrastructure built on C, which needs to be maintained and updated. This is the same old argument advocating for rewriting everything from scratch just because someone somewhere managed to develop a new flavor of the month. There are plenty of reasons why the whole world still has a…
I'm not saying rewrite everything for no reason. I'm saying that there are reasons, and we've gotten a very good idea of what those are over the last 40 years.
Earlier quoted context omitted.
>I suspect this has a -lot- to do with performance. It's questionable whether people wanted that performance though, at least when it resulted in less security. About bounds checking in ALGOL 60: https://en.wikipedia.org/wiki/Bounds_checking A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the…
"The block structure of ALGOL 60 induced a stack allocation discipline. It had limited dynamic arrays, but no general heap allocation. The substantially redesigned ALGOL 68 had both heap and stack allocation. It also had something like the modern pointer type, and required garbage collection for the heap. The new language was complex and difficult to implement, and it was never as successful as its predecessor." -- h…
> That widely-used C compilers don't do that is a strong hint there are other, real-world constraints in place.
Yes. Those constraints are self-inflicted wounds caused by the fact that C wasn't designed for this. If you have a proper iterator API, a culture of unsigned array indexing, widespread use of a size_t equivalent instead of int for loops, etc. etc. these issues vanish.
Earlier quoted context omitted.
I agree with where you're coming from. Another analogy that comes to mind is knob-and-tube wiring ( https://en.wikipedia.org/wiki/Knob-and-tube_wiring ). It's an older home wiring technology that works fine for years if undisturbed, is still present and working OK in homes all over, was invented in the early days of electrified homes, requires considerable skill to install properly, tends to be unsafe if not handled…
Only, it isn't knob and tube or asbestos. It's much more like comparing crawling (machine code), walking (assembly), C (bi-cycling), and higher level languages (faster to write, more built in safety features, etc). Each is a good fit for a given role, and sometimes you need to get through tight spaces where using one of the lower impact methods is more effective; or maybe you just can't afford something 'nicer'. Use…
Oh Zed. Really? There is nothing wrong with carefully crafted C code for applications were it is the best suited tool. Sure, there are sharp edges. True you can write crappy, security nightmare code. You do make some good points. I agree Go is fantastic. Rust is coming along as well. However, C still runs the world. That's not changing anytime soon. Not with the explosion of IoT and GPU type devices. And, hello Linux…
Um, what's wrong with that in Rust?
> Rather, what about "let's write better, less security flaw prone C."
We've been trying this for the past 40 years and we've completely failed to stem the constant tide of new game-over security flaws. I think it's time to admit that if we couldn't do it in 40 years, we've failed.