(untitled)

Rust or Go in 2021? Go's simplicity is nice but Rust seems to have more substantial features that Go is missing.

rust is eminently better suited for bigger projects. It's also more flexible for weird runtimes.

Rust will give your projects free publicity while Go will not

>>24835 >is it simple? Go. >is it not simple? Rust.

>>24840 This is how you should be deciding how to use a PL. Everybody else saying X is always better is lacking in experience in every other way. Write with the right tool for the right job.

>>24835 if you want to do async in rust use tokio dont go it alone

>>24835 Just pick the one you were introduced to first. As long as we all agree that the 90s style OOP languages (C++, Java, C#) are trash now, that's all that matters.

>>24845 c++ is not trash, you're just bad at it. I'm working on a humongous c++ project bit it's a breeze because we have stern guidelines regarding style and conventions. I've seen many codebases in many languages that were horrible, despite using "modern" languages

>>24845 Back in the 2000s it might have been trash but ever since C++14 it's probably the best all around language. C++20's import function (completely deprecates header bullshit) and 3 way operator completely changed the game in 1 release. You probably think C++ is like kicking dead whales down the beach because you read some soykafty indian guide on it that is based on an outdated version.

I really like Go's simplicity but I always feel like it is a bit bloated. I'm not much of a programmer, I just make some Prometheus exporters and simple microservices, but I can vouch for Golang as a really useful and easy language. As for Rust, I think it has a bit of a complicated syntax but it kinda repays that by letting you control the code very meticulously. I don't really use it much and I feel like rust applications always have kind of a fragile feel to them, I don't know.

>>24835 It depends entirely on what you're trying to build. Go is great for: - Cross-platform CLI tools - High-performance network daemons that are basically immune to buffer overruns - Self-contained web apps (the embed and template/html packages make deployment a dream compared to Node insanity) - Desktop programs where performance is less important than speedy development time, using something like Fyne.io Rust is great for: - Kernels - Drivers - High-performance computing - Desktop programs where performance is critical Most of what I do is in Go so I'm much more familiar with it than Rust. I like to think of Go more as a Python/Node competitor that gets rid of the need to keep an interpreter stack around, rather than as some sort of direct feature-for-feature competitor to C/C++/Rust. I wouldn't say that Go is "missing" some features of Rust, so much as deliberately leaves them out to accomplish its other goals, such as its ultra-fast compile times that can be accomplished only by leaving out C++/Rust style generics. It's simply a design tradeoff.

>>24849 >Self-contained web apps Yeah this is the situation where I'd most likely use Go. The ability to create static binaries that can run directly in a container with no other userspace is a nice feature.

>>24835 >Do I have to build a web server as fast as humanely possible with a bunch of fools on my team? Go >else Rust

>>24846 You can be good at bad things.

>>24835 If Rust is still relevant in 2041, it'll probably be very similar to what it looks like now. All the changes will be in the standard library. If Go is still relevant in 2041, it'll have half of C++ or Rust grafted on. Change is a bitch.

>>24909 Rust will probably continue to get more fancy/advanced type system features and morph to resemble Haskell code a bit more.

Why ppl in robotics use rust? I always thought they would use C or C++.

>>24849 >Rust is great for: >- Kernels stopped reading right there >>24926 Maybe these you know personally. Ask them.

Is Golang OOP?

>>24929 no, it's not OOP

>>24928 >Rust is great for: >- Kernels If you look at any properly low level rust code all it is is unsafe blocks with quasi-C code inside. Because hardware is hardware and no amount of bigbrain abstractions is going to save you from it. https://gitlab.redox-os.org/search?group_id=3&nav_source=navbar&project_id=17&repository_ref=master&scope=&search=unsafe&search_code=true&snippets=false

>>24929 It's OOP enough to be useful and practical for the average person's use-cases, but not OOP enough to be a C++/Java style nightmare clusterfuck of barely-readable, barely-maintainable spaghetti. I think it's a fantastic balance. It's a clean, practical language.

>>24835 C >>24935 >no pointers

>>24935 >If you look at any properly low level rust code all it is is unsafe blocks with quasi-C code inside. The point is to use rust to abstract over that stuff. Sure you write your memory allocator in unsafe rust, but then you write a safe interface for it and use that to interact with memory allocation.

>>24942 >Sure you write your memory allocator in unsafe rust, but then you write a safe interface for it and use that to interact with memory allocation. You don't need an entirely new and complicated programming language to do that though.

>>24945 >>Sure you write your memory allocator in unsafe rust, but then you write a safe interface for it and use that to interact with memory allocation. >You don't need an entirely new and complicated programming language to do that though. "Why must I use this 'accelerator' pedal contraption to induce my horseless carriage to increase velocity? A buggy whip has served me perfectly well to encourage my traditional carriage horse! I demand that my horseless carriage include a method to accelerate via buggy whip!"

>>24945 Technically speaking, you could do everything In machine language. That doesn't mean that other language constructs aren't valuable

>>24929 Pure, I.e everything is an object oop, no. Class based oop, no. Are there objects which you can slap methods onto, yes. Is there composition, yes through struct embedding. Is there polymorphism, yes through interfaces an soon generics OOP as a term is very ambigious, just try it out and see if you like it Present Day, Present Time! AHAHAHAHAHA!

>>24951 >Present Day, Present Time! AHAHAHAHAHA! wtf old users explain

>>24945 Rust is specifically designed to make that pattern convenient. If you want to stick to COBOL and ALGOL, nobody's stopping you, but I quite like rust and I think it is useful for the domains it is designed for. >>24952 your language has been enhanced.

>>24952 I've been lurking sporadically since 2015 and that's the only language enhancement I still cannot decipher. >>24840 This exactly. I've seen Go being compared to python and I think that's spot on. Want to spin up some quick API to be able to have something functional in your portfolio for an interview the next day? Go's the choice.

>>24935 And glibc is just a bunch of system calls in assembly wrapped with functions. You don't need C to do this. You should be using an assembler. Gosh.

>>24848 >Fragile feel That really hits with me. I'm using libgit2 and a solid third of my interaction with the crate is a mess of nested error handling. Really I just think that it reveals the fragility rather than causing it. libgit2 has always been brittle, as much as adding the "I give up" magic ? at the end of a call feels bad, in another language that would either be an ignored error (due to rarity) or it would be an if (...) {goto error;} .

>>24940 That response doesn't make sense. Objects refer to certain things, and by the vast majority of criteria (namely young and old), it fits none of them. The only tools go gives you here that look like OO are interfaces (a form of implicit resolution that isn't tied to objects), and structs (a concept that has long existed outside of the Objects). There is no late binding or other such relations in the Go Programming language. > but not OOP enough to be a C++/Java style nightmare clusterfuck of barely-readable, barely-maintainable spaghetti. I don't think Go really does much better here, given the lack of generics. Ultimately you will have similar parts that really would like certain kinds of abstractions, yet the language simply won't give them to you. >>24951 OOP is a nebulous term, you are correct about that, with that said it has meant a few things. 1. a system with late binding and inheritance 2. A message passing system in which you can send "messages" to objects. something like 2 evolved into erlang which has no object system. Whereas 1 is the roots of simula, and what is studied formally as a type system. Since go has no late binding, and lacks an object system with subclassing, I'd argue Go is not an object oriented language in the slightest. > Are there objects which you can slap methods onto, yes. By this you mean you have structs in which you can have an interface on. This is generic throughout all paradigms of programming. The same can be said with your other terms as well (polymorphism, composition) If these generic items are considered object oriented, then I'd argue Haskell and SML are the best Object oriented languages. >>24835 Why not pick other languages? It seems weird to compare Go and Rust here. Go is not acceptable for programs which require non-gc, and Rust is only fit for projects that can't live with GC. The reason why Rust is only a fit for projects that can't withstand GC, is that Rust is a hybrid between OCaml and the C programming Language, and thus expressing yourself is going to be more awkward in rust than it would be in say ocaml. They have similar kinds of abstractions but one ends up being much lower level. Further the advantages of a faster to compile languages are seen within ocaml, and would be a better fit for comparison. >>24956 Sum types do help express the fragility of interacting with the outside world, but it does turn out that this can be abstract away, but since Rust lacks stronger types you can't automate or remove a large portion of this. Often you can view this as some kind of feedback abstraction, or some other sort of Monad/Effect that with a better type would be a lot more manageable.

>>24849 > I wouldn't say that Go is "missing" some features of Rust, so much as deliberately leaves them out to accomplish its other goals, such as its ultra-fast compile times that can be accomplished only by leaving out C++/Rust style generics. It's simply a design tradeoff. This doesn't really add up to reality. I state this because a langauge like OCaml can compile fast, sometimes even faster than Go [1]. This is due to them not doing specialization of generics. I think go made that point as they wanted a rationalization to spred fud about generics besides "generics makes things complicated. Talking about this, go-lang is adding generics soon, sadly from what I recall it's a mess in its own right. Quite funny how it all comes around. [1] https://pl-rants.net/posts/haskell-vs-go-vs-ocaml-vs/ This isn't really meant to be demonstrative of all build times, however it does show that generics does not equal slow build times.

D has generics (templates) and compiles fast. DMD can compile itself in ~4 seconds on my machine, couple hundred thousand LoC full of templates. Go's compile times are also not really special, everything else is just garbage. Go's compile times are mediocre and unremarkable, but good in contrast to what people put up with, like compile times measured in MINUTES (!) in C++ and rust (even HOURS (??!!) for some big projects). GCC and clang are also slow, but there at least exist some fast C compilers, because it's a language one person could reasonably implement.

>>24946 >>24948 >>24955 Suspiciously consistent response. Is this part of the secret rust handbook on how to deal with criticism? No I didn't say write everything in assembly. I said you don't need an entirely new and complicated programming language to do that. We already have languages which can isolate the risky low level pointer fiddling behind a thin layer of abstraction. So that doesn't make rust, with all the extra baggage it brings along, particularly necessarily.

>>24985 >Suspiciously consistent response. Is this part of the secret rust handbook on how to deal with criticism? It's just the obvious response to what you said. > I said you don't need an entirely new and complicated programming language to do that But such a new and complicated language is _useful_ for doing that. >We already have languages which can isolate the risky low level pointer fiddling behind a thin layer of abstraction. yes, we all know about C++, but I think we can all agree that C++ is a big pile of soykaf. >>24984 D really is under-appreciated in these kinds of discussions. I've been meaning to learn it.

>>24984 The problem with D is the standard library depends on garbage collection which puts it in the same "native scripting language larping as a systems programming language" category that Go is in.

>>24986 >It's just the obvious response to what you said. <we don't need a new and complicated language to do X >WELL WRITE EVERYTHING IN ASSEMBLY THEN YOU RETARD I don't think so. >yes, we all know about C++, but I think we can all agree that C++ is a big pile of soykaf. yes, we all know about rust, but I think we can all agree that rust is a big pile of soykaf. The sad thing is you're not even the dumbest rust fanboy i've encountered

>>24987 If I'm recalling my short time with D correctly, that depends on which standard library you use? I'm not even sure, it's been years, but I remember having two choices of standard library and one was significantly more performant.

>>24987 I hate being "that guy," but a good chunk of the standard library doesn't require the GC. And, depending on what you're doing that's labelled as systems programming, it's entirely possible that you can use the GC in a lot of places and disable it in others. Thankfully, D gives you the control to do just that as opposed to Go. Frankly, I feel many prematurely jump on the no-GC wagon without actually profiling their software and diagnosing the problem. As an example, dynamic allocation of memory, whether it's via the GC, malloc, or some custom allocator will kill performance if used in, say, a hot path. >>24989 Both depended on the GC, but that's moot now since there has only been one standard library for many years.

>>24990 >I hate being "that guy," We're all here to learn and share information except the rust missionaries >a good chunk of the standard library doesn't require the GC The way they are trying to peddle backwards to remove an entrenched GC and the ambiguity of how far they got is what keeps putting me off D. Everytime I check there is the same half-hearted "yeah we're working on it" message >There is currently work in progress to make the runtime library free of GC heap allocations https://dlang.org/spec/garbage.html Contrast that with Ada which was fully implemented without GC first and then an optional one thrown in later. Although I see an option called betterc. Do you have any opinions on that? >dynamic allocation of memory, whether it's via the GC, malloc will kill performance if used in, say, a hot path. I'm more coming at this from a firmware perspective where you only have 56Kb and need to know where every byte is going. Then again many such platforms are not supported by llvm which is what all these new "systems languages" prop themselves up on anyway.

>>24991 >We're all here to learn and share information Yup, but I don't like being seen as some D emissary, and thus if I say something retarded, people would attribute my behavior to others. I'm just a guy who writes D, nothing more. >The way they are trying to peddle backwards to remove an entrenched GC and the ambiguity of how far they got is what keeps putting me off D. Everytime I check there is the same half-hearted "yeah we're working on it" message The GC isn't seen as an inherently "bad" thing amongst many people and developers, and that includes some very smart individuals. Nonetheless, there is work being done, and as I mentioned, a good chunk is @nogc. D's stdlib, which includes some awesome stuff, has been through a lot, and removing the GC or even the dependency on the presence of a cstdlib would require redesigning whole modules and packages. That's a lot of work, and due to lack of manpower and inconsistent leadership, it isn't perfect, but without knowing somebody's requirements, I can't say whether it's suitable or not. D may be used a systems programming language, but it's more general-purpose than anything else, and that's how I'd advertise it. >Contrast that with Ada which was fully implemented without GC first and then an optional one thrown in later. Indeed, but mind you, being a systems programming language is more than just the presence of a GC, and anything that C (the gold standard, for better or worse) can do, D can do as well. >Although I see an option called betterc. Do you have any opinions on that? I don't use it often. From what I understand, its two main uses are for converting C projects to D, and for getting a foothold into systems that D's runtime doesn't support. (Since BetterC doesn't link to it and consequently the D stdlib.) From that point onward, one can iteratively build up D's runtime for the initially unsupported system. All-in-all, it's--well--a better version of C (Proper strings and non-decaying arrays, alone, are worth it, and also greatly help with bugs and safety issues.) or a gimped version of D, depending on how you look at it. For more information: https://dlang.org/spec/betterc.html >I'm more coming at this from a firmware perspective where you only have 56Kb and need to know where every byte is going. Ah, okay, thanks for clarifying. As I implied, "systems programming," as a term, is seemingly ill-defined; I never know what somebody means by it without proper context. To your point, I can't say I'm too knowledgeable about such an environment, and you'd need to ask a more experienced D programmer, but I think D's BetterC would be a good starting point. >Then again many such platforms are not supported by llvm which is what all these new "systems languages" prop themselves up on anyway. D has a GCC-based compiler, and it's actually part of the GCC, if that helps. Also, I wouldn't lump D in with the new crop of "systems languages" since it's quite old at this point: It began in the late-90s if I correctly recall. (Which also explains why it has a GC by default!)

>>24991 >I'm more coming at this from a firmware perspective where you only have 56Kb and need to know where every byte is going. Then it makes the most sense to use the language with the smallest runtime. Honestly there's embedded versions of python that would probably be better in a really limited environment like that, than rust, go, D, or even C.

Rust seems good for applications where speedy memory handling and garbage collection is needed.

>>24994 micropython needs at least 256k

>>24994 Why not use forth for these kinds of applications? It's a very comfy model of computation, and unlike C can abstract very well

>>24847 Yeah I used to hate C++ but it's become one of my favorite languages since I started using C++20. Modern C++ is a lot like rust, but it's more convenient to write imo. The thing that always bothered me about rust, particularly as someone who writes a lot of programs that interface with linux libraries, is that you basically have to write a wrapper around any C library if you want to use it properly. C++ is flexible enough that you can deal with those common C "pass pointers to heap allocated structs around" type APIs in a relatively elegant way, without too much hassle. Otherwise, pretty much all the rust idioms work just fine in C++. The only things I can think of right now that I prefer in rust are the way it does error handling and the way it does tests. You can do the same stuff in C++20 but every C++ library seems to do it in their own special way so there tends to be a lot more translation needed to get multiple libraries to play nice together.

>>24925 I hope that all happens. Haskell's syntax is great, but as a language its feature set puts it in a weird place between Go, python, the various JVM/mono languages, and to some extent rust. It's hard to find something that Haskell is uniquely good at, which is a shame because it's a pleasure to write.

>>24985 >Suspiciously consistent response. It's the obvious response. You gave the stereotypical answer. Paul Graham described your argument and refuted it two decades ago. >As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD611.html I don't even use Rust. >No I didn't say write everything in assembly. I said you don't need an entirely new and complicated programming language to do that. But it's all the same. Assembly is to C what C is to Rust. The features you think are simple and obvious are actually complex and arbitrary. http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02069.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02070.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02071.html There is an entire history of the transition from assemblers to programming languages. Pragmatists (Djistrka would say "people with a short Buxton Index". http://www.paulgraham.com/avg.html) fought progress then and they still do now. The difference is why using outdated inferior tools is pragmatic. In the old days, garbage hardware and compilers justified cultural inertia. "Nobody wants to learn anything new and we cannot afford the new stuff, so let's dig our feet in and enjoy what we have." Today, hardware is extremely powerful. Only cultural inertia is left: programmers must be trained, backwards compatibility matters, not all target platforms are supported. There are good reasons to use old simple languages in 2021, but you have not given any.

>>24954 how it's the easiest one to decipher

>>24935 And? Even in unsafe blocks, Rust is still a broadly better language than C. I'm not interested in hearing why Rust isn't that much better than C. Not that much better is still better.

What's the current state of the art build system for Go and C++? I'm currently using Rust for a far too simple application just because how good cargo is. I remember CMake being a nightmare and Go kept trying to centralize everything in ~/go. I prefer keeping project environments local like pipenv and npm do.

If you wanted what Go does shouldn't you just use erlang or elixir instead?

>>27346 They're too hard for the typical go programmer.

>>27346 go is a general purpose programming language and erlang just isn't. its a cool language but it isnt really suited to solving the same types of problems even if both languages were built with concurrency in mind. erlang is too high-level and abstract for most of go's use cases.

>>27182 In fairness, C is still worth learning, if only to maintain long-standing projects written in it which have no mature replacement on the horizon. >>27186 >What's the current state of the art build system for Go Just run "go build". Maybe spice it up with build tags if you want to for certain really weird situations that 99.999% of people will never run into. If you need to include asset files (like html templates, default config files, images, audio, whatever) in the static binary that's output, look into the embed package (https://pkg.go.dev/embed). But that's as complex as it gets. One of Go's major strengths is the lack of a need for an overly-complex build system (or even worse, multiple third-party build systems!) like the ones that had to be grafted onto C and other C derivatives after-the-fact.

>>24835 please stop comparing managed languages made for small web services to systems languages made for large safety-critical systems. It's almost like comparing C++ to Python. It makes zero sense.

>>27346 Go is far more popular than both of those despite being newer, unfortunately.

>>24926 who in robotics is using Rust?? I gotta send them my CV

>>27110 Its it " now "? Excuse me for testing this out here lol soykaf

>>28000 Or maybe even " today "? I don't post often enough to have found out. Also sorry for bumping this thread about my two least favorite popular langs, just use C and don't be dumb.

>>24988 Can we just agree that neophytes and zealots are dumb, and familiarity + use-case/features of a language are the ultimate deciding factors and move on? Rust and C++ are phenomenal, powerful languages when used at the right time for the right problems. Every language is soykaf in some circumstances.

>>28007 Ye. Programming languages are tools, and you can only compare a tool to other tools that do the same job in the same way. Comparing C to Rust is like comparing a hammer to a nailgun: even if they technically do roughly the same thing, they're different enough that arguing about them is a waste of time.

>>28000 It's : ^ ) >C Some of us care about security and not being owned by the CIA, for one >>28007 >depends on the use case Yeah let's just stop our thinking forever and then pick a tool that's right for no use case at all.

>>28029 >Yeah let's just stop our thinking forever and then pick a tool that's right for no use case at all. >Some of us care about security and not being owned by the CIA, for one Ah, I see, so you have literally nothing to add to the conversation.

So, what about now, in 2022? My problem with Rust is that the standard is the last commit and I fear that may break any code I'm building. As for Go, it feels like a programming language for people who can't program well enough, as if Google created it so their programmers would stop being so soykaf.

>>30967 Yeah, u are right, rust is still a growing one. I had fun with one crate that didn't even compile on my build. After that I checked their issues in GH and saw that they suggested updating to the latest nightly build. Imagine several crates with such a problems in ur toml file. Insane. But you know what - Rust is ideal for rapid microservices development. Idk, it is soo easy to build them, full-tuned and production-ready.

Go allows rapid prototyping while Rust doesn't. If you want to create new things, experiment and hack around, with Rust it's a huge sink of time. Rust by design assumes you have your architecture and algorithms laid out and ready for actual implementation. Which makes it "the" language of rewrites of already existing projects, projects that are just experiments proven successful - and therefore buggy and messy, but still working. For the same reason people prefer C++ to Rust. More bugs? Yes. But they don't know what they are about to make yet, and C++ gives them total freedom over their code. That being said, Rust was much easier for me to learn even despite Go being very narrow and dead simple. There are many things about Go that tick me off and some syntax decisions are very questionable... My advice for Arisu is to learn Go first and then you can decide whether you need more. Just keep in mind that Rust is not like other languages and is likely to stay niche for probably next decade.

>>30967 >As for Go, it feels like a programming language for people who can't program well enough, as if Google created it so their programmers would stop being so soykaf. I've seen this as a criticism of different languages over the years and I used to agree with it, but after working on real projects, this is definitely a feature, not a shortcoming. If using a certain language means I'll get to deal with less awful code from others, I'm happy to use it.

>>30971 >but after working on real projects I think it's just the image Go gives(or the one Google wanted to give) which is why I think it's like that since I have not tried to do some serious projects on it yet.

>>30970 >Go allows rapid prototyping while Rust doesnt this is the most person whose company I enjoy argument ive ever heard. you literally just copy/pasted an old argument for dynamic (soykaf) languages vs static and applied it to the new "underdog"

>>31008 also forgot to point out that Go code does not compile with unused variables, which is an antithesis to "rapid prototyping", but you retard niggers will chime in now and explain how this is actually fine

>>31009 jej Literally the only thing I liked when I saw Go was channels, and I can easily implement that data structure in C/C++.

>>31054

>>30970 >people prefer C++ to Rust. More bugs? Yes. But they don't know what they are about to make yet, and C++ gives them total freedom over their code. They are rewriting existing code in rust because it's as fast as C but not as insecure if a new bug isn't patched quickly. The damage control is a nightmare for every important C program that is still relevant. >Rust was much easier for me to learn I guess it makes sense if you already know how to program in a language like C or Java. I also got familiar very fast when I started making some projects to see if I liked it or not. It's not easy to master because of their design choices but it has the potential to be the go to language for everything where resources and performance are something to consider. Unfortunately nowadays most programmers are webdevs, and they will stick to literally low tier languages like react or the not so bad flutter, but if you care about the user experience rust or kotlin/swift have no rival right now.

>>31225 >They are rewriting existing code in rust because it's as fast as C but not as insecure And here I thought they were doing it because the Rust people can only annoy people with "Rewrite in Rust" and they rewrite(as in just start) anything just to keep the meme going.

>>31225 >Unfortunately nowadays most programmers are webdevs, and they will stick to literally low tier languages like react or the not so bad flutter, but if you care about the user experience rust or kotlin/swift have no rival right now. I think the Rust community is supposed to be fairly involved in webassembly stuff in attempts to make Rust suitable for a lot of the webdev currently dominated by js/ts. I don't see it being influential in the webdev field, but at least there's potential.

>>31230 We had the same meme with python and now with js, but at least with rust it makes sense to rewrite C code. People get obsessed when a new language becomes popular. >>31233 I discovered a project called trunk the other day in hacker news, it looks good but it'll only be used by rust devs that want to make something on the web, not the other way around.

>>31225 I think this is a bit unfair. The market has driven people to only value time to minimum viable product in web. Everything else is just a symptom of that. If you can make it performant enough and get there first, you'll probably do better even if your code is slow or trash, then you can just rewrite all of it.

>>31250 This works at the startup level, they are fighting for a place and to make their investment somewhat viable. But, at the end, the webapps that are still around were never poorly written and they weren't inventing anything new. Even though there are more devs than in the 90s, most people only use 4 or 5 apps in their phones (the desktop market is nonexistent). You are not going to be the 6th one if your code is garbage. You may fool some random company into using your electron react driven app, but you'll loose everything if someone takes the time to make an alternative with a good code base with your not so original idea. I guess that's why the subscription schemes are the only way to finance the garbage code those devs are producing.

My hot take as someone with experience in C11, C++17, Common Lisp, Tcl and all the POSIX DSLs (sh, make, awk, m4) and for who visual and conceptual elegance has a great importance: * D: ugly abomination that don't know if it wants to be C++ or C#, fortunately dead. * Rust: Perl/C++ like syntax makes me barf and the usual Rust fanboy argument that the great amount of features and their complexity justifies it completely ignore Common Lisp and even simpler fexprs based Lisps. The ML pedigree does bring advantages compared to the C++ it's replacing (ADTs, match, good parts of FP "no statements, only expressions" and closures) and it has a technical momentum that few PLs can reach, right now. Community is very gay. * Go: a lot of good points, quite readable, CSP programming is very nice. But the downsides are simply too great: - Biggest problem is the same as UNIX: reactionary (compared to Multics). Deliberately throwing the baby with the bathwater to avoid dealing with the same problems as everybody. Don't want to botch an important feature (out of band error signaling, generics, macros, etc...)? Just ignore it. - As the generics situation shows (remember the official "Generics? Never!" position?), the language is growing organically, as opposed to being designed well from the start, which is never good. - No macros... is this the dark age? - Owned and designed by Google, with little input from elsewhere (for good and for bad). - GC, even if quite good, is mandatory (no RC alternative, unlike Nim) and hard tuned for latency (no OpenJDK like choice between G1, ZGC and Shenandoah). * Swift: don't know, I'm not gay, lol. * Zig: reactionary too, but in a good way (i.e. clearly not trying to replace C++, but the low-level parts of C). But I want my high level features. Ugly to look at, though. * Hare: basically a meme. Not enough ambition to make me want to use it over established or establishing options (like Zig). Would have been interesting before Zig existed and Jai was the vaporware it still is. Doesn't look bad to the eye, though, it fails to learn from the mistake Python (or PHP, or JS) made or the one rms talked about when soykafting on Tcl: if your domain specific PL becomes popular, it's going to be used beyond its domain, and you'll be somewhat responsible for the resulting horrors, so plan ahead or REALLY make it impossible to use as general purpose PL (e.g. R, Prolog, AWK). * Nim: to be honest, I don't know soykaf about it, except that it seems like Go with a lot of its advantages without most of its design faults; that ARC/ORC thing is also quite promising. Looks okay to me, obviously Python inspired. * C++: still does "the job" when you can evade its many bad parts (including C legacy) but worst designs of all of these. Katamari lang is often used to mock it, for good reasons. I consider it somehow a Cobol/PHP lang: used because of the surrounding inertia (tooling, libraries, mindshare), but you'll never see it not ridiculed by people with experience in more varied PL families (ML, Lisp, Prolog etc...) and generally better designed langs. * Ada: only two problems in my view: - I said "modern", and Ada's modernization strategy is the same as C++: keep adding stuff but keep backward compatibility. - Offends my eye by using words for code "punctuation", like Pascal. So, if I were to choose one... probably Nim. Rust would have been nice without all the parts I don't want no need. Discuss. PS: among these, only C++ and Ada are properly ISO/ANSI standardized, so I'll stick with CL as it ticks most of my boxes except speed in some cases (e.g. string processing, static generic dispatch) and being "modern" (threads, atomics, SIMD, Unicode, etc... being part of its spec); and it's fabulous to look at once you manage to ignore the parentheses and properly indent it (like a more readable Python with complete AST information, basically).

>>31268 Sorry for all the typos and English mistakes, it's getting late here. Do understand that I'm talking about these PLs from the superficial point of view of someone who never tried them.

>>31268 Just discovered/remembered that Nim doesn't have an official compiler, only transpilers (https://github.com/arnetheduck/nlvm exists, but is obviously not very mature and doesn't seem to have any official interest or support). As bad as they are, I guess I'd take Zig or Rust, if I really had to choose.

>>24926 I am not aware of a large Rust following in the robotics community.

I noticed a very important feature missing from most of these: named parameters. Only Nim has them, other may emulate it via ugly and retarded workarounds like (not anonymous) struct literals; and, surprise surprise, none of them is as correct as CL providing an optional boolean to differentiate between user given and default values. Example for people who don't know: CL-USER> (defun f (x &optional (y 0 y-supplied?)) (format t "x: ~A, y: ~A (~A)~%" x y (if y-supplied? "supplied" "default value"))) CL-USER> (f 0) x: 0, y: 0 (default value) CL-USER> (f 0 0) x: 0, y: 0 (supplied) I discovered at the same time that Zig lacks optional parameters; which isn't completely dumb, as optional unamed parameters can get confusing quite fast (basically, never use more than one and with precaution, especially in PLs like C++ with implicit ctor bullshit). ┌────────────────────────────┬─────┬─────┬────┬────┬──────┬─────┬──────┬─────┐ │ Feature │ Ada │ C++ │ CL │ Go │ Hare │ Nim │ Rust │ Zig │ ├────────────────────────────┼─────┼─────┼────┼────┼──────┼─────┼──────┼─────┤ │ Optional parameters │ Y │ Y │ Y │ N │ N │ Y │ N │ N │ ├────────────────────────────┼─────┼─────┼────┼────┼──────┼─────┼──────┼─────┤ │ Named parameters │ Y │ N │ Y │ N │ N │ Y │ N │ N │ ├────────────────────────────┼─────┼─────┼────┼────┼──────┼─────┼──────┼─────┤ │ Argument provenance marker │ N │ N │ Y │ N │ N │ N │ N │ N │ └────────────────────────────┴─────┴─────┴────┴────┴──────┴─────┴──────┴─────┘ Sources: https://rosettacode.org/wiki/Optional_parameters https://rosettacode.org/wiki/Named_parameters https://github.com/rust-lang/rfcs/pull/2964 https://github.com/rust-lang/rfcs/issues/323 https://github.com/ziglang/zig/issues/479 https://github.com/ziglang/zig/issues/484 https://nim-lang.org/docs/tut1.html#procedures-named-arguments Hare doc doesn't mention anything, so, knowing the philosophy, I put "N" tl;dr stay with "old" langs, they're not made by retards for retards

>>31277 fuarrrk, forgot the code tags. ┌────────────────────────────┬─────┬─────┬────┬────┬──────┬─────┬──────┬─────┐ │ Feature │ Ada │ C++ │ CL │ Go │ Hare │ Nim │ Rust │ Zig │ ├────────────────────────────┼─────┼─────┼────┼────┼──────┼─────┼──────┼─────┤ │ Optional parameters │ Y │ Y │ Y │ N │ N │ Y │ N │ N │ ├────────────────────────────┼─────┼─────┼────┼────┼──────┼─────┼──────┼─────┤ │ Named parameters │ Y │ N │ Y │ N │ N │ Y │ N │ N │ ├────────────────────────────┼─────┼─────┼────┼────┼──────┼─────┼──────┼─────┤ │ Argument provenance marker │ N │ N │ Y │ N │ N │ N │ N │ N │ └────────────────────────────┴─────┴─────┴────┴────┴──────┴─────┴──────┴─────┘

>>31278 >>31277 C# has that too Really optional and named params are not that great, they're syntactic sugar. Any good API designer can just define some struct with a builder pattern interface and a bunch of optional fields in Rust, and then have that be the entry point or argument for the function.

Answer me this: Out of the procedural and/or OOP langs, does any language even come close to Rust in terms of capability of managing mutable state? Every procedural language I can think of, not only is mutability of variables the default behavior, but there is actually no way to declare an object instance as immutable. You can declare the reference to the object instance as immutable, but the object itself is still mutable. How much confusion has been caused in the so-called "safe" GCed langs by declaring const Thing a = new Thing(); and then later forgetting, and calling a.mutate(); Whereas in Rust, anything you declare is 100% immutable by default, barring some stuff happening in unsafe blocks? Also, how about deep copies/cloning? Once again, I have seen (and then rectified) production code where someone wrote: Thing a = new Thing(); // Later Thing copy = a; copy.mutate(); In Rust, it's standard for most types to implement Copy, and it does a proper deep copy. I know both of these features aren't very relevant in FP world with all the fancy immutable data types, but in procedural land, I have yet to see a single other language that gives this basic assurance.

>>31279 If you've worked on any big and complex project, you'll know that it's the kind of "syntactic sugar" that is objectively useful (especially named, optional only can be confusing, as said earlier); otherwise, why would people who have access to it use it constantly (and not only Python noobs, I'm talking CL including its standard library)? >Any good API designer can just define some struct with a builder pattern interface and a bunch of optional fields in Rust, and then have that be the entry point or argument for the function. And it's ugly (both to pass by the caller and access in the callee), in an already ugly language (and it pollutes the type namespace). The consequence is obvious: who actually uses named parameters when you have to use workarounds this cumbersome? Nobody, right? Is there a macro making it as transparent as possible? >>31280 Your example looks like (wrong) C++ (which is not a GC lang), mate. In C++, only const methods can be called on const objects, so you're wrong: $ cat test.cpp #include <cstdio> struct S { S() : a(3) {}; void method() {}; void const_method() const {}; int a; }; int main(void) { const S *sp = new S; sp->method(); sp->const_method(); delete sp; const S s; s.method(); s.const_method(); } $ g++ -Wall -Wextra -pedantic -std=c++20 test.cpp -o test test.cpp: In function ‘int main()’: test.cpp:15:19: error: passing ‘const S’ as ‘this’ argument discards qualifiers [-fpermissive] 15 | sp->method(); | ~~~~~~~~~~^~ test.cpp:6:14: note: in call to ‘void S::method()’ 6 | void method() {}; | ^~~~~~ test.cpp:20:17: error: passing ‘const S’ as ‘this’ argument discards qualifiers [-fpermissive] 20 | s.method(); | ~~~~~~~~^~ test.cpp:6:14: note: in call to ‘void S::method()’ 6 | void method() {}; | ^~~~~~ I do agree on immutable by default.

>>31277 I agree that named parameters are extremely useful, but their existence leads to a very `Lispy' style of code where functions adopt a whole brood of optional parameters and become heavily overloaded in terms of functionality. This is readily apparent in CL and Elisp's standard libraries. Remove in CL has 7, I think that's excessive and :test-not is completely superfluous, but at least they're (mostly) there to make the function extremely general. There are much worse cases like make-array's :displaced-to which does something completely different from making an array, instead returning a view into another array given as argument (akin to Rust's slices). This sort of functionality is extremely useful and should be made more obvious instead of being tucked away in a named parameter. A lot of the utility of named parameters can be implemented in a neater way with currying and composition of higher order functions.

>>31288 You're arguing (a good case, mind you) against [s]optional[/s] parameters, not named parameters. There is agreement that optional parameters can easily get confusing, and you show how their mere existence might encourage poor design choices. On these points I think there is consensus: Optional, unnamed parameters: madness. Optional, named parameters: handy, but also abusable. And to those I add: Named, mandatory parameters: a necessity. In a statically-typed language, every function that takes two or more (non-commutative) parameters of the same type should accept named parameters, for readability and to avoid errors. In a dynamically-typed language, same minus the type constraint.

>>31290 I agree about the utility of named parameters. But in the absence of optional parameters, I find structs perfectly reasonable and equally correct. Do you have an objection beyond you don't like it and you want the other thing?

>>24840 And either is better than C++

>>31292 >Do you have an objection beyond you don't like it and you want the other thing? As I've already said, it is much more cumbersome and hard on the eyes. To the point where almost nobody uses this workaround; when you don't have first class optional/named parameters, you simply don't think about them when designing your API. I mean, look at https://rosettacode.org/wiki/Named_parameters#C.2B.2B, would you use such a contraption unless it is needed? By the way, >>31290 isn't me.

>>31288 >Remove in CL has 7, I think that's excessive and :test-not is completely superfluous, How are most of the typical sequence keyword arguments "excessive"? Anyway, you want a look at the real world alternative? Look at C++'s STL where the complexity is spread between T::operator== for :test and :key, iterators for :start, :end and :count (forcing you to verbosely pass `thing.begin(), thing.end()` when you want to iterate over the whole container) and backward iterators for :from-end; you also have something like 4 overloads for each std::algorithm function and some _n variants doing exactly what :count does.

>>31287 >If you've worked on any big and complex project, you'll know that it's the kind of "syntactic sugar" that is objectively useful (especially named I have and do, and I use named params (and recommend them in code review) where relevant. But usually, if you have enough params for it to be a useful feature, you need to define a new type that contains all those fields. I'd rather have that, than a >150 character line of text, or splitting all the args up across lines. And then think of your API users-- if you're not around to tell them, "hey, you should use named params for code cleanliness," there's a good chance they won't do it because it's optional. Then you're haunted by the possibility something might go out of order.

>>31280 >Whereas in Rust, anything you declare is 100% immutable by default, barring some stuff happening in unsafe blocks? this isn't true. interior mutability exists in safe rust.

>>31303 >But usually, if you have enough params for it to be a useful feature, you need to define a new type that contains all those fields Why? If named arguments are named, it's precisly to avoid this horrible boilerplate.

>>31277 >>31278 It's important to note that, in Ada, all subprogram parameters are optionally-named or positional. This makes it much harder to write the subprograms, but much more pleasant to use them. >>31279 >Any good API designer can just define some struct with a builder pattern interface and a bunch of optional fields in Rust, and then have that be the entry point or argument for the function. That's a disgusting hack on par with the C language using bit positions in an integer to emulate them. Optional parameters are clearly wanted, so why dance around this? >>31280 This is Ada: -- constant local variable A : constant Thing := ...; -- local variable, named access type, constant access, no allocator T : aliased Thing := ...; A : constant Thing_Access := T'Access; -- This can't be pointed at by just any access type. T : aliased constant Thing := ...; -- constant anonymous access variable, allocator A : constant access Thing := new Thing(...); -- I can also have the following access types. constant access Thing access constant Thing constant access constant Thing Ada also has limited types, which are types without predefined equality and assignment, permitting total control over them. >I know both of these features aren't very relevant in FP world with all the fancy immutable data types, but in procedural land, I have yet to see a single other language that gives this basic assurance. Oh, well I suppose looking back at what people were doing in 1983 is a little difficult.

>>31329 Do you have a book recommendation for Ada 2012?

>>31348 I recommend Programming in Ada 2012 by John Barnes: http://www.cambridge.org/barnes I don't recommend learning about Ada 2022, as it has some qualities which I dislike.

>>31367 You mean https://learn.adacore.com/courses/whats-new-in-ada-2022/index.html? Multiprecision arithmetic is an important addition, 'Image on values is nice and I can see @ being useful, since Ada sadly doesn't have op=. But the aggregate stuff is meh, looks too much like Python/C++ featuritis.

>>31367 >>31375 Damn, I've found https://stackoverflow.com/questions/23982388/custom-image-attribute-in-ada just by googling "Ada image attribute", pretty sad. Even in C++, you can overload to_string as much as you want (as long as you do it in your namespace, of course).

>>31376 I'm retarded. In Ada 2022, you can apply the 'Image attribute to any type, including records, arrays, access types, and private types

The fees literally not a single reason not to use c for everything

>>24841 should have been /thread

One of the things holding me back from dealing with Rust is the community. I don't want to have to deal with never ending soykaf about CoCs and various maladjusted people.

>>31620 That's not specific to Rust. CoCs are everywhere now, especially Go projects. For the most part, it's a non-issue as well. So you have to be polite in your contributions to a project now, not a big deal.

>>31634 I don't remember anybody being rude in their contribution before, it's just a ploy by people like pic related to get more power than they deserve. I can't say that about Steve Klabnik though, he actually deserves the praise, he's a skilled man.

>>31645 >I don't remember anybody being rude in their contribution before except famous examples like Linus and Theo

>>31647 >Linus >Theo Extremely based people

>>31647 Who, unlike her, did something for the open source community.

>>31647 You're confusing "quality control" with "rude". They weren't behaving like that just to "be a dick". Saying "You can do better than this abortion you're call code" is a clear misunderstanding. You'd take it personally, which you shouldn't , because he's just saying "You can do better than that" and he's clearly only criticizing the actual code itself. The response here might be "Then just say that" but that's exactly what he is saying. Unlike most people, these guys said what they mean and didn't beat around the bush. Now people tip toe and allow shoddy code in. >>31653 >her That horrid creature created a lot of animosity. That's about it.

>>31645 What's this lady have to do with rust? From what I have gathered, she's some ruby programmer who's now big into ethics and who made a code of conduct (the contributor covenant) that is adopted by a lot of projects, but not by Rust. In fact, the adopters page for the website lists Go as an adopter, so if your issue is this lady's CoC, it seems your answer for this Rust vs Go thread should be Rust instead. >I don't remember anybody being rude in their contribution before Flaming was a decent part of the open source culture for a while. As fun as it can be, it does inevitably derail discussions and can be a barrier to productivity, so it's reasonable for a project to ban it. For bigger projects, allowing it may introduce them into similar legal trouble a workplace could get into for allowing it, so definitely can't blame them for banning it.

>>31620 >>31634 >>31645 >>31647 >>31648 >>31653 >>31654 Dude I love drama!

>>31659 >lady You have to be more subtle to get some bites, you know.

>>31677 Dude, even more drama! Just like funny 4chan.

>>31690 lainchan coul d use some 4chan 4fun to be honest

>>31659 a rule does not need to be written to exist, to be enforced, or be generally understood. These projects have long maintained adequate order without the COC, so establishing it is not the aim of the COC movement. The COC movement is about armtwisting project maintainers to either publicly declare their opposition to a powerful faction, or their submission to its rule.

>>31698 I'm glad this is what the thread is about now. Sage.

>>31694 >what is a good distro to use? >"nigger tranny glitterboy" No, it really doesn't. Keep the cultures separated.

>>24835 They are different languages for different purposes. But I in commercial development Go is more common now. So... go with Go. It's used and loved for reasons.

>>24835 Both languages are memes. Go with a real language like C if you want performance or Java if you want the work to be mostly done and just glue APIs together.

>>32850 But does Go even compete with C? C is a low-level language that should only be used for system software and kernel development.

>>24847 >>24846 Why should i use C++ over say, lisp with CLOS?

>>31659 So the big thing from what i remember was that the people who were writing up the CoC's would've been the first to be punted because of it. It especially didn't help that, she didn't really do that much(?), i know she made some pushes but that was about it. Unless that was someone else... Really though, if you want a reason, it would be the fact that you have such a steep learning curve to do something that could be done easily in another language like pascal or C, you just have to be smart about it, or just write a reference counter library and use that. or use an array that is calloced and defragged every so often? would that work?