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

Re: Moving from PHP to Go and Back Again

blog.breakthru.solutions

Post reply on HN
Print view View original

221–230 of 281 posts

Re: Re: Moving from PHP to Go and Back Again

#221

Post by vardump »

cies wrote: post #177
jchw wrote: post #151

Earlier quoted context omitted.

To me, Rust is like C++, Go is like C. Rust loves zero cost abstractions, and isn't afraid to be complicated. It gives the programmer as much power as possible. Go is simple and actually very fast. The garbage collector is probably the biggest hurdle for performance and it's still best in class. Definitely higher level than C, but not enormously so.

> Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that…

> C was also king of the zero cost abstractions.

Seriously? That's news to me. Only C zero cost abstractions I know of are based on external code generators. Or some macro abuse, but that's rather limited way to create abstractions.

But then again, when you really need to understand everything that is going on, abstractions are often not helping you.

(I write kernel drivers and bare bones embedded, where memory measured in kilobytes, not megabytes.)

Re: Re: Moving from PHP to Go and Back Again

#222

Post by BuckRogers »

pjmlp wrote: post #81
cft wrote: post #53

Earlier quoted context omitted.

You cannot really write an operating system without manual memory management. That's why Go is not a systems programming language. It does not diminish Go advantages: I would personally prefer it as an application programming language to Java.

Completely false, there are several research OSes with kernel level GC. I suggest reading Project Oberon source code, it’s freely available.

I can't speak for the parent but he did say "cannot really". I would assume due to that he's aware you can write a research project in it. At one point, I thought Windows was to move to .Net even and MS backed out in the end.

Back to Go, for anyone else reading this thread and wondering what Rob Pike thinks it is, evidence of them removing "systems programming" off their website is here. He explicitly states that he regrets it and that Go is not an OS writing language[0]. Andrei Alexandrescu offers a litmus test shortly after with a property of a systems programming language that Go also fails. If the creator of a language says it's not a systems programming language, I'm not sure how it can be argued by outsiders that it is.

If there's more damning evidence that Go is not a systems programming language, I couldn't imagine what that would be. A shortlist of systems programming languages that would pass any litmus test would include C, C++, D and Rust.

[0]https://www.youtube.com/watch?v=BBbv1ej0fFo&feature=youtu.be...

Re: Re: Moving from PHP to Go and Back Again

#223

Post by AnimalMuppet »

pjmlp wrote: post #191
steveklabnik wrote: post #168

Earlier quoted context omitted.

> is thin enough by some arbitrary measure? Colloquially, this. There's historically been a fairly big gap between "very little runtime" and "more runtime", so "no runtime" and "runtime" are what people say. That said, the word is generally ill-defined; some people use it to mean "interpreter" or "vm" rather than the classic definition, which is (as you say) that every non-assembly language has a runtime.

Actually in the world of micro-code and uOPs even Assembly can be said to use a "runtime", for specific CPUs. :)

OK, if you really want to go as far low-level as possible: My mother, back in the 1950s, worked on at least one CPU where the instruction set could be changed with patch cords. So is the configuration of patch cords a "runtime"?

;-)

Re: Re: Moving from PHP to Go and Back Again

#224

Post by [deleted] »

shmish111 wrote: post #159
noncoml wrote: post #9

Earlier quoted context omitted.

> And yet we keep writing Go. What are the alternatives if you want something with type checking? Java? No, thanks. Haskel? Where are the libraries? C/C++? I guess Typescript is the only alternative

"Haskel? Where are the libraries?" What libraries are missing? The only issue I've had with libraries are that some client libraries are wrappers over C libraries and this makes static linking difficult (or seemingly impossible on a Mac) A few years ago there was a lack of libraries in some areas but that's not the case these days.

[deleted]

Re: Re: Moving from PHP to Go and Back Again

#225

Post by AnimalMuppet »

musage wrote: post #146
donjoe wrote: post #143

Earlier quoted context omitted.

... curly brackets on new lines do work perfectly fine in case you're writing code on your own. As soon as you start working in a team and each team member starts to use their own formatting, it becomes super messy and unreadable. Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself and never ever have to start arguing ab…

But why should Go enforce it on behalf of everybody? A parser option to not automatically insert semicolons would be all I need, but no. To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy. > Either you inforce a clear style guide which leaves you to explain the team why your style is the best, or you leave this task to the language itself Which then leav…

> To me, even with super short lines, braces at the end of the line are messy, and consistently messy is still messy.

To me, they're just harder to spot. I think having them on their own line "frames" the inner block nicely.

That said, brace location is not the hill I'm willing to die on. It's a minor thing, not worth getting religious over. For my own code, I'll do it how I want. For a team, though, consistency really does matter. I'll make my case, and then I'll shut up and do what the group decides.

(And actually, I think consistency within a file matters more than consistency between files, so I'm fine with "The file author/main maintainer sets the style for the file. If you modify the file, keep the existing style.")

Re: Re: Moving from PHP to Go and Back Again

#226

Post by cies »

efficax wrote: post #220
cies wrote: post #177

Earlier quoted context omitted.

> Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that…

> Go obviously isn't. You can use atomics and syscalls and even assembly in Go to have complete control over the system in the same way that you can in C/C++. It's definitely not trivial to bypass Go's memory model and get raw access to memory, but you can do it if you want. I'd say that Go discourages you from doing so, just the way Rust discourages the use of unsafe memory access even though you can if you want.

Go strongly pushes a "way to do it", see concurrency for instance. C/C++/Rust have a (one or more) paradigm, but they leave as much liberty to you as a programmer as possible.

This I see as a stark difference.

Wrt concurrency, Go is more like Node: one way to do it.

Re: Re: Moving from PHP to Go and Back Again

#227

Post by cies »

vardump wrote: post #221
cies wrote: post #177

Earlier quoted context omitted.

> Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that…

> C was also king of the zero cost abstractions. Seriously? That's news to me. Only C zero cost abstractions I know of are based on external code generators. Or some macro abuse, but that's rather limited way to create abstractions. But then again, when you really need to understand everything that is going on, abstractions are often not helping you. (I write kernel drivers and bare bones embedded, where memory measu…

To now C's abstractions, you'd have to compare it to assembly I guess.

Re: Re: Moving from PHP to Go and Back Again

#228

Post by cies »

jchw wrote: post #185
cies wrote: post #177

Earlier quoted context omitted.

> Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that…

>C was also king of the zero cost abstractions. C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping. >C sure is not afraid to be complicated. Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of…

Good points about C. Thanks.

> Go differs most in it's [...] built-in concurrency.

That was what I was driving at, as well as Go not being fit for writing a kernel in. Sorry being so inarticulate.

Re: Re: Moving from PHP to Go and Back Again

#229

Post by AnimalMuppet »

pjmlp wrote: post #80
cft wrote: post #4

I don't know why the author bothered to even respond to that Medium article. The Medium article starts with that Go shines as a systems programming language. He lost me right there: how can a language with a garbage collector and a runtime be called a "systems programming language"?

Since Xerox PARC, UK Royal Navy, DEC, HP Labs, ETHZ, Microsoft Research have implemented full stack OSes in GC enabled systems programming languages. At ETHZ Oberon workstations were used during a couple of years by several users across the department. Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features.

> At ETHZ Oberon workstations were used during a couple of years by several users across the department.

The way you say that, it sounds pretty unimpressive. Say, 2 years and 10 users, plus or minus one order of magnitude. That's not enough to tell anything. Was it going to be portable to other hardware? Was it going to be maintainable? Was it going to be comparable in performance? The answers are all "no data". The only thing you can say is that it could be successfully written and gotten to work, for a definition of "work" that allowed a few people to use it for a little while.

> Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features.

Well... I wasn't there, but I took a look at the Wikipedia page (yeah, I know) giving the chronology of the Oberon OS, and it's quite unimpressive. For four years, it had "only simple text editing facilities". Those four years ended in 1991. That sounds very much like "lack of features" to me.

In particular, the competition was either DOS, Mac, or a Unix workstation. That feature set would not lead anyone to want to choose Oberon.

Now, I know, there were only a couple of people working on it part time. But all this really proves is that they were able to write an OS and get a text editor running on it. That's proof of concept, I suppose, but there's a huge difference between an OS like that and an OS you can "bring into the wider market".

I think you're idolizing a past that wasn't all that hot at the time...

Re: Re: Moving from PHP to Go and Back Again

#230

Post by pjmlp »

AnimalMuppet wrote: post #223
pjmlp wrote: post #191

Earlier quoted context omitted.

Actually in the world of micro-code and uOPs even Assembly can be said to use a "runtime", for specific CPUs. :)

OK, if you really want to go as far low-level as possible: My mother, back in the 1950s, worked on at least one CPU where the instruction set could be changed with patch cords. So is the configuration of patch cords a "runtime"? ;-)

I guess not, but uploading a micro-coded bytecode interpreter into an Alto CPU in 1973, to switch between Smalltalk, Interlisp-D and Mesa/Cedar support certainly feels like a runtime.
Post reply on HN