You're viewing a single thread.
It is so weird when people idolize programming languages. They are all flawed and they all encourage some bad design patterns. Just chill and pick yours.
Yeah, but that makes it sound like they're all equal, and there hasn't been any progression, which is untrue. You're either insane or a historical reenactor if you write something new in COBOL.
I think Rust is genuinely a huge leap forwards compared to C/C++. Maybe one day it will be shitty and obsolete, and at the very least it will become a boring standard option, but for now...
Rust is already obsolete, compared to Stingpie's excellent assembly language, paired with object oriented programming!
This is the SEALPOOP specification:
- an assembler must create a binary program which satisfies the programmer's specifications.
- a compiler must translate the programmer's code into SEALPOOP's parallel instruction set source, which should be fed into the SEALPOOP PISS assembler.
Well that's going to get cancelled. Think of the non binary folk out there!
Don't worry, they have DreamBerd
Booleans can be true, false or maybe. Technical info: Booleans are stored as one-and-a-half bits.
I now want a community led historical reenactment of loose tie wearing software devs in the 60s where they are just chain smoking and banging out COBOL or Fortran punch cards
I don't think much happens in person, but the community for it definitely exists.
C++ when it was new was exactly like this. Rust still hasn't had 30 years of legacy, all these Rust prophets will shit on it's name in 15 years when they have to maintain huge codebases with it
Besides, C++ is very likely to adopt memory safety
Now it seems the way is unique_ptr and shared_ptr. And std::any to replace void*. At least is what it seems to me.
Yeah, that's my guess too.
As to whether C++ can update enough to steal it's thunder, I feel less qualified to answer. It'd be pretty impressive if they managed to preserve backwards compatibility and do that at the same time, though.
i think it's more like a "significant" step in language design that could make a "huge" leap in software quality
I mean, until Electron is rewritten in Rust, so people with Stockholm syndrome can still write painful JavaScript desktop apps...
Tauri gets us quite a long way there
YOU CAN HAVE MY COBOL ON COGS WHEN YOU PRY IT FROM MY COLD, DEAD HANDS.
If you're also not familiar, in it's plain http glory: http://www.coboloncogs.org/
That is indeed very cool, and falls squarely into the second case.Edit: Or maybe the first? (A joke about how insane it would be counts)
It seems non-serious, given the lack of downloads and snail mail as a contact method. If they actually made this, though, reenactment.
makes it sound like they're all equal, and there hasn't been any progression
Programming peaked with Lisp (and SQL for database stuff).
Every “progression” made since Lisp has been other languages adding features to (partially but not quite completely) do stuff that could already be done in Lisp, but with less well implemented (though probably with probably less parentheses).
Spoken like a true Lisp fan. I dunno, I really like static typing, and too many brackets gets tiresome.
You can use typed Lisp, there are plenty of them, from Typed Racket to Shen in their complexity. Or to make your own type system in 50-100 lines when you actually need
There have been "improvements" but fundamentally in my perspective, these "improvements" could be revealed to be a mistake down the line.
Assembly has produced some insane pieces of software that couldn't be produced like that with anything else.
Maybe types in programming languages are bad because they are kinda misleading as the computer doesn't even give a shit about what is data and what is code.
Maybe big projects are just a bad idea in software development and any kind of dependency management is the wrong way.
I like modern languages, types and libraries are nice to have, but I am not the student of the future but of the past.
That's a valid argument, but a very weak one. If we are not completely sure something is an improvement in all aspects are we just to dismiss it altogether?
Yeah, you could dismiss combustion engines for the same reason, or like, carpentry. You wouldn't be wrong, they have caused problems down the line at various points (modern climate change, medieval deforestation), but you bet I'd still call them an advance on mule power, or on no carpentry.
This is pretty much an nullification of the idea of technological progress existing at all, which is a kinda hot take.
@[email protected], so you can reply in the right place.
I see your perspective and I think you kinda miss my perspective which I am to blame for.
I don't say there weren't improvements. I am saying that given the uncertainty of "goodness". Maybe we shouldn't idolize it. You can appreciate the attempt of creating memory safe code through a programing language without thinking the bare metal code should be written in that language. You can like a typeless easy to write language like Js without thinking desktop app should be written in it. You can like the idea behind functional programming while believing that any application is in the end about side effects and therefore a purely functional application impossible.
You can approach the whole topic as an area of study and possible technological advances instead of a dogma.
Oh, well I can agree with that.
You can like the idea behind functional programming while believing that any application is in the end about side effects and therefore a purely functional application impossible.
It's a bit of a tangent, but if you're doing something completely deterministic and non-interactive, like computing a digit of pi, it's great in practice as well. I use Haskell semi-regularly for that kind of thing.
You could argue printing the output is a side effect, but is a side effect followed by termination really "side"?
I agree.
I think it is a side effect if it runs on a modern Os. But honestly who cares...
[warning: "annoying Rust guy" comment incoming]
I don't think Rust is perfect, but arguably I do "idolize" it, because I genuinely think it's notably better both in design and in practice than every other language I've used. This includes:
- C
- C++
- Java
- C#
- Kotlin
- Scala
- Python
- Ruby
- JavaScript (...I've barely used this, but I doubt my opinion would change on this one)
- Perl
- Go
- Bash (...look, I've had to write actual nontrivial scripts with loops and functions, so yes, Bash is a real language; it just sucks)
- Tcl/Tk (if you don't know, don't ask)
- CommonLisp (...again, I've barely used this, and I wish I had more experience with this and other Lisps)
In a literal sense, I agree that all (practical) languages "are flawed." And there are things I appreciate about all of the above languages (...except Tcl/Tk), even if I don't "like" the language overall. But I sincerely believe that statements like "all languages are flawed" and "use the best tool for the job" tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:
- safety/correctness versus "power" (i.e. low-level system control)
- safety/correctness versus run-time efficiency (both parallelism and high single-thread performance)
- ease-of-use/ease-of-learning versus "power" and runtime-efficiency
- implementation simplicity versus feature-richness
- build-time versus run-time efficiency
- type-safety versus runtime flexibility
Looking at these, it's pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What's special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose "both" for the first two criteria (though certainly not the latter three; the "ease-of-use" one is debatable) at the expense of higher implementation complexity and a steeper learning curve.
The great thing about this isn't that Rust has "solved" the problem of language tradeoffs. It's that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn't that it becomes ubiquitous; it's that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)
There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:
- Erlang
- Gleam
- OCaml
- Swift
...but, with the exception of Swift, these are all effectively "niche" languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust's popularity.)
I know religious people who could not explain their faith so specifically.
Because they just have their own brain chemistry as the basis of it whereas the above comment clearly states:
Rust has proven empirically that the tradeoff between performance and safety doesn't need to exist.
Which is truth. And it's much easier to base a coherent argument on truth rather than vibes.
Eh, technical merit is only one of many factors that determine what language is the "best". Best is inherently a subjective assessment. Rust's safety and performance is the conceptual bible rustacians use to justify thier faith.
I also know religious people who have written books about their faith too (my uncle is a preacher and my ex-spouse was getting their doctorate in theology). Rust has the same reality-blind, proselytizing zealots.
The needs of the project being planning and the technical abilities of the developers building it are more important that what language is superior.
I like rust. I own a physical copy of the book and donated money to the rust foundation. I have written a few utilities and programs in rust. The runtime performance and safety is paid for in dev time. I would argue that for most software projects, especially small ones, Rust adds too much complexity for maintainability and ease of development.
Have you actually ever seen an example of such an annoying rust dev? Cause I haven't, only a ton of people who see rust as their enemy number 1 because of such people. Those who are "annoyed" are way more annoying…
I have. You just don't hang out in the "right" places
I have made experiences with annoying PHP devs and I don't hate them.
My critic wasn't towards rust devs or any devs of any language but towards idolization of a language instead of studying the nature of those languages the flaws and advantages and use the best tool available or attempting to create a better tool.
Yes, absolutely. Constantly, in fact.
Rust the language is great.
Rust the community makes me hate rust, never want anything to do with it, and actively advise people not to use Rust. Your community is so, so important to a programming language, because that's who makes your documentation, your libraries, fills out the discords, IRC, and mailing lists. As a developer, any time you're doing anything but rote boilerplate zombie work, you're interacting with the community. And Rust has a small, but extremely vocal, section of their community that are just absolute shitheads.
Maybe in 5-10 years when the techbros stop riding its' dick and go do something else will Rust recover its reputation, but for now? Absolutely no.
So you're saying Rust is the TOOL of programming languages.
I just villainize languages. C++ is the devil.
nice, i encourage satanic panics in software engineering too
It's a significant time investment for some, and they want to be reassured they picked the right camp. :D
I probably wouldn't describe them as flawed, because the goal wasn't and couldn't ever be perfection, so then everything is flawed, but then is it really a flaw? It sounds like more of an issue of what's useful in what type of situation.
That's something I don't get about doing things in a language that is not meant to be used for that (like JS for something other than web).
...but what if I pick the one with all the furries? :3
That's just Rust again. Well, or Python. Shower thing still applies.
I am proud of you and wish you happiness in your little corner of this world.
They are all flawed and they all encourage some bad design patterns.
On the other hand, Lisp.