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

Solod: Go can be a better C

solod.dev

Post reply on HN
Print view View original

111–120 of 188 posts

Re: Solod: Go can be a better C

#111

Post by anamitra- »

pjmlp wrote: post #103
anamitra- wrote: post #97

Earlier quoted context omitted.

I disagree. Go's main plus point is concurrency, whereas the irony is it lacks thread safety—something languages such as Java have had from, let's say, day one. You can fix that issue by manually managing sync.Pool objects for performance and, on top of that, use channels, but this completely defeats the purpose of Go's simplicity. Even if you want a top-of-the-line performance with some convenience, there exists an…

My point was not about Go vs Java.

You missed a bit of my point. The point am trying to convey is that what it was made for that is efficiency and networking it fails somehow and somewhere in both. As i was surprised when i came across the thread safety issue of go which for me was diabolical, because go was meant to be lean at least on threads while maintaining thread safety by default.

The next point would be gc,maybe it can be improved and its being improved the recent being mark sweep algorithm was made a bit efficient by addition of more meta data about the total object structure, not going into it more.

Thing is it breaks the fundamental promise it was suppose to keep and yes its better than rust for network applications(am talking of getting things done in default way). It's stdlib is the strongest among all languages.

That summarises my point go needs severely improve it's issue of thread safety by default provision and gc efficiency.

Re: Solod: Go can be a better C

#112

Post by win311fwg »

pjmlp wrote: post #109
win311fwg wrote: post #101

Earlier quoted context omitted.

> Yeah but they were so that intentionally trying to build a better C++/Java They were trying to build a faster Python, thinking that would appeal to C++ developers. The theory was that developers were using C++ at Google because they had to, not because they wanted to, and would choose something like Python instead if it were up to the performance task. Although it turned out in the end that C++ developers actually…

No they weren't, in fact they were very surprised by the adoption from Python folks. "I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. We—Ken, Robert and myself—were C++ programmers when…

> No they weren't

Indeed they were. Your quote even says so — seeking out to solve the problems C++ was thought to have, which is that it didn't have the ergonomics of languages like Python, as explained in the original public Go announcement. To "feel like a dynamically-typed language" was a primary motivation. That was clearly told.

You can certainly hold the view that a better C++ and a fast Python are one and the same, but I suspect the HN crowd will vehemently disagree with you. Conflating the two would not serve to communicate much here.

> were very surprised by the adoption from Python folks.

Quite naturally. Python users were already using Python. One would be inclined to think that they didn't need another Python. Except it turns out they did, because it was actually they who needed a faster Python.

Re: Solod: Go can be a better C

#114

Post by jack_h »

pjmlp wrote: post #107
loup-vaillant wrote: post #77

Earlier quoted context omitted.

> Go is a better C already It’s not. Garbage collection made sure of it. I believe everyone agrees that a "better C" has to have manual memory management. Most even rule out Go as a systems language because of GC. Of course, I’m pretty sure Go is much better than C at some problems. But there’s no way in hell it supersedes it.

Nope, only the anti-GC religion would agree to that. Most of those folks would never manage to replicate something like Xerox Cedar on their own, from 1980 in their beloved 2026 computers. Thankfully we have the likes of Apple and Google, that have a my way or the highway education system for such developers, that want to go through their magical gardens.

There are roughly two orders of magnitude more microcontrollers in the world running code than application processors. GC is not acceptable on a microcontroller due to the extreme resource constraints. The GP post is correct, Go can replace some use cases for C, but it does not replace all use cases and GC is part of the reason.

Re: Solod: Go can be a better C

#115

Post by doodpants »

pjmlp wrote: post #105
loup-vaillant wrote: post #82

Earlier quoted context omitted.

> A better C++ is by definition a better C The definition is wrong, then. I wrote C++ for most of my career. And as of late, I found myself avoiding more and more features from it. The STL is mostly trash, not worth the increase in compilation times. Templates are good for containers, but that’s about it. Inheritance and polymorphism are circumstantial enough that I’m not sure they’re worth adding to the language: in…

I see it differently, given how C with Classes came to be, a Typescript for C in 1989.

The origin of a thing does not forever define what that thing is and always will be. C++ has evolved far beyond C with Classes.

Re: Solod: Go can be a better C

#116

Post by lilbigdoot »

jamiejquinn wrote: post #57
kfreds wrote: post #50

Earlier quoted context omitted.

That seems like a brittle approach to transpilation. A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language. Also, there is so much more to a language than its surface syntax. I've never designed a transpiler (I'm not a programmer), but surely the correct approach is to transform the source code into its ty…

I'm really sorry to be harsh but if you don't use programming languages and have never written a transpiler, why should anyone read your comment? You critique the approach as brittle and yet the approach you propose doesn't solve the thorny problem gp described of a growing ball of reserved keywords.

I've written multiple transpilers and their comment is how I do it. Safely mapping identifiers is one of those many edge cases you discover as you go along

Re: Solod: Go can be a better C

#117

Post by leoedin »

jamiejquinn wrote: post #57
kfreds wrote: post #50

Earlier quoted context omitted.

That seems like a brittle approach to transpilation. A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language. Also, there is so much more to a language than its surface syntax. I've never designed a transpiler (I'm not a programmer), but surely the correct approach is to transform the source code into its ty…

I'm really sorry to be harsh but if you don't use programming languages and have never written a transpiler, why should anyone read your comment? You critique the approach as brittle and yet the approach you propose doesn't solve the thorny problem gp described of a growing ball of reserved keywords.

It's kind of hilarious isn't it?

"I don't even write code, yet here is my technical assessment of how a tricky software problem should work".

Re: Solod: Go can be a better C

#118

Post by mpyne »

pjmlp wrote: post #109
win311fwg wrote: post #101

Earlier quoted context omitted.

> Yeah but they were so that intentionally trying to build a better C++/Java They were trying to build a faster Python, thinking that would appeal to C++ developers. The theory was that developers were using C++ at Google because they had to, not because they wanted to, and would choose something like Python instead if it were up to the performance task. Although it turned out in the end that C++ developers actually…

No they weren't, in fact they were very surprised by the adoption from Python folks. "I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. We—Ken, Robert and myself—were C++ programmers when…

> No they weren't, in fact they were very surprised by the adoption from Python folks

I'm kind of surprised that the Go creators were surprised by this.

Like I know they didn't like C++, but Go is by no means a replacement for C++ despite whatever was said about "building a better C++/Java".

It took so long to pick up generics that Rust was already around and the logical next step for C++ developers by the time that happened. And that's only scratching the surface of why people choose C++.

On the other hand, having a more performant "simple" language that directly supports concurrency and lets you compile to native code without a ton of ceremony could be very helpful indeed if you're a Python dev who need to take an app to the next level without having to learn intricacies of C FFI or the GIL.

Re: Solod: Go can be a better C

#119

Post by mpyne »

win311fwg wrote: post #93
benjiro29 wrote: post #91

The problem with these type of new / transcompile languages is not the langue, its the lacking libraries and 3th party assets. Great if just want the most basic hello world programs, but the moment you need ... for example a http server. Then your often with: a) none b) http 1.1 c) ... forget about more Maybe you need rar support ... O well, ... And then you always enter the world where you need to start linking exte…

> Transcompile languages have always had tons of issues, and there is a reason why non became popular. While implementations have all died out now in favour of direct compilation, C++ the language was designed to be a transpiled language, and was for many years with C as the target. You can likely find many who agree that it has tons of issues, but unpopular it is not.

Typescript is an even better example. And there are some domain-specific languages that aren't meant to become popular general-purpose languages, but succeed in their niche through the help of transpilation to a general-purpose language.

Re: Solod: Go can be a better C

#120

Post by win311fwg »

mpyne wrote: post #118
pjmlp wrote: post #109

Earlier quoted context omitted.

No they weren't, in fact they were very surprised by the adoption from Python folks. "I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. We—Ken, Robert and myself—were C++ programmers when…

> No they weren't, in fact they were very surprised by the adoption from Python folks I'm kind of surprised that the Go creators were surprised by this. Like I know they didn't like C++, but Go is by no means a replacement for C++ despite whatever was said about "building a better C++/Java". It took so long to pick up generics that Rust was already around and the logical next step for C++ developers by the time that…

Why wouldn't they be surprised? Python users were already using Python, so presumably it already solved their problems and they wouldn't benefit from another Python. Through Google's eyes, anyone who needed performance would have already long abandoned Python for C++.

What Googlers don't have a grasp of is how resource constrained most other businesses are. They cannot afford to hire C++ experts and were using Python because Python developers were the only developers they could get their hands on, even where Python wasn't providing sufficient performance.

Post reply on HN