Hacker News Reader

Hacker News

Comment by kumarvvr | Hacker News Reader

Full thread

kumarvvr

Go and Rust are harder to pick up.

With weird operators and syntax.

Maybe I am getting old, losing my edge or python has spoilt me.

Even C# is elegant compared to those two.

I tried to learn both of them, but they just didnt excite me as much as C# or Python.

View on HN

Rust has a similar "problem" as C++: it wants to be high level (for productivity) and close to the metal (for performance). Such languages are needed, but they are not going to be the easiest to learn. It is not their fault.

There has to be a simpler solution than Rust though. Rust seems to have started with some clear objectives but evolved into a nightmare.

We should be putting the effort into the compilers and keeping the language free of cruft and any unsafe concerns. Much like Delphi did for example.

For most, average userspace programs garbage collectors work very well. (Of course there are exceptional cases as I'm sure people will be quick to point out.) However if you deny garbage collection for all programs you have to replace it with something very complex to reason about, like RAII for C++ or borrow checking in Rust. Or you end up reimplementing GC inefficiently (C++ reference counting). Also certain algorithms -- persistent data structures with shared subgraphs and therefore cheap updates -- become very difficult to write because there's no local ownership of nodes, only something with a global program view (a GC) knows when an object is unreferenced and can be freed.

This. The Rust community seem to be pushing Rust as a more-or-less general purpose programming language. But giving up garbage collection never makes sense unless you have to. The applications where you really can't use GC are a tiny niche relative to the ones where you can.

>> The applications where you really can't use GC are a tiny niche relative to the ones where you can.

And this is one space Rust is targeting explicitly. Why would people replace Go with Rust for performance reasons otherwise?

https://blog.discord.com/why-discord-is-switching-from-go-to...

It's funny that one of the key selling points of Rust is "fearless concurrency", but IMO if you want "real" concurrency - i.e. not just "split work between threads" which is what Rust can do easily, but different threads doing the same work concurrently (e.g. accessing the same data structures, sending messages, etc.) you need lock-free data structures, and for those you need GC (or something different, e.g. epoch-based reclamation - but from what I've read (no practical experience though), it's just as tricky to implement and performs worse than good GCs).

I think the future is combined GC (for concurrency & unpredictable lifetime patterns) / reference counting (for resources - files, sockets, large primitive arrays) / safe manual (e.g. memory pools). I just need to figure out all the details :D

The crossbeam crate implements epoch-based GC for concurrency in Rust. It's widely used and seems to work fairly well.

Especially, if you have do limited scope GC like Erlang, and let the programmers pick when GC is happening. Sort of like malloc/free but without the fear of introducing bugs like double free.

Sometimes when I look at the strange constructs of Rust, and all the hoops that you must jump through to do certain things, I end up yearning for C++. Or even plain old C. And I tell myself, that I’ll be more careful with memory handling.

Exactly, C seems saner in my view, and in its own way, elegant too.

I have the opposite: when I see C or C++, I'm terrified of touching it for fear of messing up the memory handling. Rust allows me relax.

I'm not really seeing the whole "nightmare" part of Rust. If the borrow checker ever becomes an issue (and it really shouldn't be one in most cases, if you're familiar with the semantics) you can easily opt into increased flexibility. It just takes a little more boilerplate than in other languages.

There is. It's called Dlang or D.

And the core team went down the C++ path in many cases.

What weird operators and syntax do you have in Go? I'm asking because I feel the exact opposite. Someone who already knows a bit of a language with C-like syntax can pick it up very quickly.

Flipped variable declaration. Duck typeing, And the idomatic use of := instead of explicit declaration. Also the use of _ and multiple return values (which i really like). Are all a little tricky to begin with.

That use of := is my only very small hang up.

Whether variable declaration is 'flipped' or not depends on which languages you're used to. Duck typing has nothing to do with syntax or operators. ':=' is an explicit declaration (with simple type inference). The use of '_' to indicate an unused binding is common to many languages. Multiple return values in Go have about the simplest and most intuitive syntax imaginable. You separate the values with a comma both when returning them and when binding the returned values.

For Go:

1. Exports from packages are to be defined with a Capital letter. To me, that is very hard to read. An explicit export statement is way better, if verbose.

2. Type declarations after variable (x int, y int), to me personally, is hard to read. Now I know a lot of people are fine with it, so this is a personal thing for me.

3. Multiple return values syntax is terrible.

  func split(sum int) (x, y int) {

   x = sum * 4 / 9

   y = sum - x

   return

  }

In this function, the sum is the input and x & y are outputs. The syntax seems weird to be. This also is a personal gripe.

4. Variable declarations can be var i, j int = 1,2 AND k:= 3 with implicit typing. To me this is a bad design, with various programmers choosing different methods to declare and initialize. Leads to a lot of cognitive overhead to read code, especially on large open source projects. Why not make it explicit to declare types? Sure, it's a bit of more work for the programmer, but in the long run, that bit of more initial work will save a lot of downstream confusion and frustrations.

5. Constants cannot be declared using := syntax. I am sure there is a valid reason for it, but assignment in the language for now is = , := and those can and cannot be used in various places. That is confusing.

6. For loop has no parenthesis for the loop initialization but needs {} for the loop blocks. This is really stupid. Personally, for(i:=0,i<100;i++) {} is a concise syntax and looks pleasing and readable.

7. To complicate it further the initialization and post statements are optional

   // This is a valid for loop in Go

   sum := 1

   for ; sum<1000; {

    sum = sum + 1

   }

Isn't that confusing in itself. Sure, we don't have to write a loop that way, but some junior developer is going to write it anyway, and it muddles up the code for sure.

8. From the official Go Docs "At that point you can drop the semicolons: C's while is spelled for in Go"

   // This is a ALSO valid for loop in Go

   sum := 1

   for sum<1000 {

    sum = sum + 1

   }

yay.

9. And then there is this gem in the "if" statement.

   if v := math.Pow(x, n); v < lim {

     return v

   }

Yes, you can write an optional initial statement before the if condition. All this for what? So you save one extra line in the code? Sorry, the beards got too long and too tangled up for whoever came up with this idea. 10. Also, the initial statement you saw just after the if statement, the variable "v" is available in the scope of else/if and else statement blocks. But not outside the if/else scope.

Yay, another way to confuse code readers.

10. What is up with the defer keyword to defer function calls until the "surrounding function returns".

There are many more, but I think I have made it clear why, personally, Go is off putting.

edit : Changed format a bit.

Try prefixing code with two spaces instead of a ">"

  sum := 1
  for sum < 1000 {
    sum = sum + 1
  }

Uppercase exports are great once you get used to them. You can know whether an identifier is exported instantly without having to look up its declaration.

Agree that the multiple declaration/assignment syntaxes are unfortunate. Another example of this is that := can't be used for top-level declarations. Once you learn the rules you stop having to think about it, but if the rules were more consistent, they'd be easier to learn.

The other big issue with Go's variables is shadowing. Again, one of those things that you pick up fairly quickly, but will bite newbies a few times.

If-declarations are nice because they restrict the scope of a variable. I like knowing that I can see instantly that a particular variable is only used in three lines.

Defer is a great way to clean up resources without the complexity of destructors and exceptions. Defer is also ubiquitous in code that needs to wrap accessor functions in a mutex. It's been adopted by a few other languages, which shows that it has merit. My only gripe with defer is that it only works on function scope; it'd be nice to have a defer scoped to a for loop.

The other stuff is your personal preference, which I disagree with, but can't argue against :)

I'll add another personal gripe of mine, though: typecasting is indistinguishable from a function call, e.g. Foo(bar) might be calling Foo on bar, or casting bar to type Foo. Those should really have different syntax.

Don't know Go but I'm going to give it a shot:

1. Casing is a personal preference, so that's fair, but not a valid criticism.

2. Type decls after the variable are much easier to parse, and allow for (easier) type inference.

3. Yeah? References exist... C/C#/C++ have them too.

4. This ones a fair criticism.

5. That's because constants have a completely different syntax from variable assignment.

6. The parenthesis are syntactically unnecessary and add nothing, the curly braces are required for an unambiguous parser (barring significant whitespace).

7. This is true in almost every language with for loops. Try it in the JavaScript console in your browser.

8. Yeah? So?

9. The scoping is a feature, not a bug. E.G.

   if v := getResult(); v == Success {
     Print("Success!")
   } else {
     Print("Failed with error code ", v)
   }
   // v doesn't pollute namespace out here

10. That one I'm not educated enough to make a reply to.

Have you tried C++?

Rust is an alternative to C++ or C, not to Go, C# or Python.

Sure, you can write any program on any language, but if you try to write bare metal C code from C# or Python, your frustration will be quite large as well.

Use the right tool for the job.

Just a minor correction, Rust is trying to be replacement of C++. It will be unlikely to replace C, at least for next 2-3 decades. C will serve as the low level language and Rust will be a higher level language.

Today Rust needs LLVM (written in C++), to generate binaries and it may be 2-3 decades before Rust will be used to write anything like LLVM with supporting platforms.

Today Rust library to do anything useful rely on unsafe integration with underlying C code.

Rust is still on fringes and quite a complicated language compared to C. I still doubt it will be a replacement for either, may be it will go-exist with C/C++ on fringes and may be in next 30 years if it survives like Python might have significant code and can be useful in place of C++.

No language will replace C on its turf, FOSS UNIX clones and embedded POSIX RTOS.

Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++.

As for Rust, yes a co-existence is more likely.

> Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++.

You keep saying this, but I'd recommend you to look at a few random "C++" files in https://github.com/gcc-mirror/ for example.

For many of these projects, "moving to C++" often means to change the file extension. Or not even that, sometimes it's just changing the build setting to "Compile as C++".

There's no reason for holy wars. Fact is that regular C code is still ruling the world. Maybe not in the financial industry. Maybe it's embedded in a few C++ syntactic constructs. Maybe some people even found a way to use RAII in a way that doesn't suck in a large project. But the vast majority of the stuff that does something is still dangerous, evil, ugly C.

And now excuse me while I go watch another talk named "C++ Features to avoid" or "Taming build times in a large C++ codebase" or "Why we went back to plain C"

Yeah, the old USENET argument of comp.lang.c, kind of missed that.

Here are my reading recommendations,

https://gcc.gnu.org/wiki/gcc-in-cxx

"This page is meant to eventually help document the ongoing effort in the "gcc-in-cxx" branch to make gcc compile in C++ mode, i.e. as C++ source code. So, the goal of this branch is to facilitate switching GCC's implementation language to C++."

https://devblogs.microsoft.com/cppblog/the-great-c-runtime-c...

> "We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs."

https://llvm.org/docs/Proposals/LLVMLibC.html

"Provide C symbols as specified by the standards, but take advantage and use C++ language facilities for the core implementation."

You are excused, write a blog post afterwards.

There is a fallacy in taking enterprises that might be done "eventually" as being already completed and ultimately proven.

What you quote is not disagreeing with what I was saying at all.

Quick look at the GCC link you posted:

    Project Status (last updated 06/2009)
        Phase 1 of gcc-in-cxx now complete (06/2009)
        gcc-in-cxx completes bootstrap as of 03/2009

Seriously.

> "Provide C symbols as specified by the standards, but take advantage and use C++ language facilities for the core implementation."

Sure, now let's look at the code

https://github.com/llvm/llvm-project/blob/master/libc/src/

Oh, it's not even a completed project. Here is stdio

https://github.com/llvm/llvm-project/blob/master/libc/src/st...

stdio/ for example has just 3, mostly empty files: file.h, fwrite.cpp, fwrite.h. Last commit was 8 days ago. It's not a project to be taken as serious evidence for any argument.

You need to stop selling things that might never exist, or have long been dead in the water.

Apart from that, I've looked at 10 files and the only use of C++ I've seen was some namespacing (that just makes the code more verbose IMO; YMMV).

It's essentially C, the thing you're leading a religious war against.

In this day and age where it's common knowledge that we're all living in opinion reinforcement filter bubbles, it should be possible to expect from people to at least quickly skim the citations they provide.

Ah so we are back into the comp.lang.c days. Reply will come in due time.

Just back in times where we try at least not to back up claims with citations that can't withstand a 1-minute check.

Going over that LLVM-libc website again, this is absolutely hilarious. It reads like a bucket list of grandiose features, done by a Junior developer with lots of motivation, but with no idea that these add costs and complications, and no idea what's really important.

The Git repo matches that impression. There are neatly arranged directories containing CMakeLists and fuzzing stuff and READMEs and what not. Is there a good reason why strcpy() needs to be fuzzed? Some directories contain a lot of header files with 20 lines of comment junk and namespace junk, surrounding a single line that contains a function signature.

And looking at the code, it seems not even 1% of the actual functionality is implemented. I will be extremely surprised if this project gets ever completed.

Sometimes I do make the failure of doing a hasty reply, should know better.

Trying to reduce the amount of C code in the world since 1992, sometimes I win, sometimes I loose, in what concerns me, the outcome looks pretty much positive to me outside embedded development and FOSS UNIX clones.

As for the whole C compilers written in C++ thread, a proper reply will follow up rest assured, even if takes a couple of weeks like last time.

> For many of these projects, "moving to C++" often means to change the file extension. Or not even that, sometimes it's just changing the build setting to "Compile as C++".

It's a bit more than that in the case of GCC. Not a lot more, but GCC does use templated containers. I'm not sure it uses any other C++ features, a kind of "C with templates" might have been sufficient for its purposes.

But then again, what would you expect? GCC is huge. What would a huge refactoring buy the developers?

All I've been saying is that they don't REALLY seem to have "moved to C++". FWIW

Moving to C++ doesn't imply having classes everywhere, anything described in ISO C++, requiring compilation with a C++ compiler counts as moving into C++.

But if projects are basically C compiled as C++ that's absolutely meaningless and if you take that as an indication for anything then you're just fighting a pointless religious war.

On the contrary, that has been the argument from the C side since the comp.lang.c days trying to prove a point that C is still relevant without understanding that was C++'s Trojan horse.

Also just because it looks like C the semantics aren't the same, e.g. implicit conversions from void* aren't allowed in C++ compilers, ?: has a different precedence and a couple of other differences, this still in C89, let alone with everything that came afterwards.

These are pretty minor things that don't matter semantically or with regards to safety. For example I never knew that there was a difference in the precedence of the ?: ternary operator (which I don't use anyway), but I'd wager that it's more the byproduct of different language formalization methods, and not an intended change. There surely can't be a significant difference because it would hinder the Trojan effect.

void* not implicitly casting to their assigned value in C++ is an annoyance to me at best. I don't see any advantage at all there.

Things that matter are for example that C++ has vectors or other container types with the possibility to enable bounds checking with a compile flag. Well, you'd think they matter, because it is a security improvement at first sight, and I certainly thought so. I do now think that it makes programs significantly harder to maintain, to the point where superficial advantages cancel out or turn negative.

If that effect wasn't real at least to some extent, I wonder why do I see SO MANY function signatures in C++ projects where functions are passed in classic pointer + length style.

Furthermore tools like valgrind can be helpful in a way that gives some of the benefits of language-level methods for bounds-checking.

Why you see them? Because developers should know better, but there is a community that keeps writing C style code in C++, unfortunately, as their teachers are stuck in the 90's.

"CppCon 2015: Kate Gregory “Stop Teaching C"

https://www.youtube.com/watch?v=YnWhqhNdYyk

But what to expect when schools keep using Turbo C++ as teaching tool, https://galdin.dev/blog/why-you-shouldnt-be-using-turbo-c/

Oh my, another day, another random unrelated link fest. I do happen to have watched that talk, and I'm not sure what point you want to make by linking to it. That talk is someone else's opinion how to get students to write some C++ that compiles - students with no prior understanding of C++ or of programming. Students that do not aspire to be great programmers or even to understand a little bit of what's happening here. That will not be able to help themselves when there's a 200-line error spewn from templated containers for example. That don't even want to understand (or have trouble understanding) the concept pointers.

It's NOT a talk suggesting that C is bad or that the use of it is bad (despite the title).

It's a talk that suggests that C++ needn't be hard. If we were about actually understanding the language and making significant use of its features, Bjarne Stroustroup himself begs to disagree with the idea that C++ is a language that an individual can fully understand.

It's a talk suggesting how to approach teaching when the goal is to get quick (and surely limited) results instead of understanding.

But that's totally uninteresting to me. If it's interesting to you, we should end doing more comments, and I should try not to be annoyed when I read your evangelism and your ton of comments where you often hop around and quickly change topic when someone disagrees, and where you instead throw more links to pages that may have a title that suits your agenda, but that are often low on content or dead-in-the-water stuff, or that are completely unrelated to the discussion.

I'm tired of playing wack-a-mole with you.

> Things that matter are for example that C++ has vectors or other container types with the possibility to enable bounds checking with a compile flag.

As I mentioned above, templated containers is the one significant C++ feature that GCC uses. So maybe you now agree that it's not just C compiled as C++ after all?

Well I was never going into a "technically" argument, I thought that was pretty clear from the start. I had already knewn that those containers are used there in some places (although I didn't find any when I quickly skimmed the codebase 2 days ago). So let's just say "yes technically I agree" and maybe I won't seem as a totally boneheaded evangelist.

My actual intention and the reason for my comments was to put things into relation. Compared to what you want to argue about here, pjmlp has a totally different idea of how things are or should be, and which I think is rose tinted and skewed.

Using a templated container once maybe every few dozen or hundred lines is not a justification for unfounded and unbalanced hating, and it is no indication for taking this codebase as an argument that C is so bad that they couldn't deal with it anymore, so they had to switch to C++ which solved all their alleged problems. That's just not the way it is.

Not taking from that technical point of agreement, and as an aside because I can't resist, I personally prefer to just use stay with C completely/"technically", and I believe I get better results by improving the architecture of my projects to work around C's "shortcoming" of not having templated containers. One can even make a point that just templated dynamic vectors are easily available in C since C does have polymorphism for arrays, supported by its pointer syntax, and using valgrind and the occasional assert() you can get lots of the same benefits in terms of security. The way I go about this achieves the same level of convenience, minus RAII (which I found to be problematic on larger scale. Templated containers and maps are nice though for short throw away code and temporary variables that never leave the function scope.)

I also actually make heavy use of a C99 feature that is still not in C++, which is designated initializers to make static arrays (often readonly data) to map from enums to additional data. I also found that I've wasted a lot of my time trying to build arbitrary "nice" things in C++ and always finding myself in a place some time later where I've totally locked myself in, so that's why I prefer just not to use a C++ compiler at all, even if there are some little nice-to-haves that you can get with it.

So there you go, my rant that is totally out of place here, why I don't think C++ is a better choice even if used very lightly.

>> Rust will be a higher-level language.

It does lots of low-level things that are closer to C though.

Rust can absolutely replace C in everything except small embedded platforms where only a C compiler is available. With the unsafe subset, it can do anything that C can do. It's actually harder to seamlessly replace C++, because C++ has its own semantics that are not very easily replicated in Rust.

> Rust is trying to be replacement of C++.

Rust is not trying to replace any language.

> it may be 2-3 decades before Rust will be used to write anything like LLVM with supporting platforms.

Depending on what you mean by "like LLVM," this already exists partially in Cranelift. We'll see if it takes three decades or not.

Hopefully something like zig will replace C. Much less complex than Rust, but with niceties like modules and arrays.

> Rust is trying to be replacement of C++.

Citation needed.

Rust lacks so many fundamental C++ "features" (variadics, thin pointers, HKTs, const generics, specialization, overloading, inheritance, good FFI with C++, C++ exceptions, ...), that trying to sell it as a C++ replacement is quite hard.

OTOH, Rust is pretty much at feature parity with C, having excellent interoperability with it, and only lacking somewhat in inline assembly, allocas/VLAs, etc.

You can take any C project, and implement a new feature or refactor some part of it in Rust without issues.

You can't do the same for C++ code easily: integrating with C++ templates is hard (e.g. try to use a C++ Boost library, or the C++ standard library from Rust), integrating with C++ error handling is hard (try to write Rust code that can error using C++ exceptions, or that can be unwinded with one), calling C++ ABIs is hard from Rust, interfacing C++ types with Rust is also hard (inheritance, virtual functions, etc.).

Any successful C++ projects that uses Rust (e.g. Firefox), uses Rust as a better C to implement a C library, that can be called from C++. That's not "being a better C++" in any way of the word.

I have used C++. I understand about using the right tool for the job. But Rust and Go are not good tools solely due to their syntax.

Similar opinion. The only two things I consider worthy at this point are C and Python. Everything else seems to have lost the balance of compromise, stability, low API and language volatility, the ability to retain it and it's API in mind effectively and tool flexibility.

On the Go front I have to say I like the language but not the rigidity which quite frankly gets in the way a lot of the time and turns minor experiments and refactoring into a time consuming nightmare.

On the C# front, I've been writing C# since before the compile toolchain was even RTM and I dislike every moment now. It has become a bloated mess of a language and the supporting frameworks are impossible to keep track of and up to date.

Edit: I prefer SBCL over everything really but that's another universe :)

> On the Go front I have to say I like the language but not the rigidity which quite frankly gets in the way a lot of the time and turns minor experiments and refactoring into a time consuming nightmare.

Can you give an example of this?

Have you looked at Nim?

Reply on news.ycombinator.com