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

A little Golang way

aerofs.com

Post reply on HN
Print view View original

151–160 of 194 posts

Re: A little Golang way

#151

Post by e12e »

vorg wrote: post #90
grey-area wrote: post #75

Earlier quoted context omitted.

reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns Really? Java 1.4 had an extensive and consistent standard library, implicit interfaces, composition instead of inheritance, static builds, and built-in concurrency? Go is not early Java, it's more like C 2.0, and I don't really see anything faux about the simplicity, it really is pretty simple, perhaps too simple for s…

> Go is not early Java, it's more like C 2.0 Or perhaps Go is C+

Technically, that'd be "float C2 = C + 0.5"? (And remember to treat C2 as a float, not an int!)

Re: A little Golang way

#152

Post by Scramblejams »

pcwalton wrote: post #139
Scramblejams wrote: post #138

Earlier quoted context omitted.

I feel the same about Erlang processes. It's so much easier on my brain to write synchronous code that's preemptively executed and communicating by message passing. Wish Rust gave me that option, speed hit and all, but I understand why it doesn't.

How does Rust not give you that option? The choice of 1:1 and M:N does not affect the programming model at all. It is simply an implementation detail. M:N scheduling is no more a requirement for CSP than Unix is for TCP.

Maybe I'm using terms incorrectly -- is there a good green thread library for Rust which supports the kind of Erlangy experience I've described? I looked around a couple of months ago but didn't find anything that seemed suitable.

Re: A little Golang way

#153

Post by duaneb »

travjones wrote: post #25

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is com…

Go is only a massive improvement over interpreted languages. Anyone who was already writing performance software will have a much harder time justifying the switch: many low and high level features are simply not in the language. (E.g. parametric types, macros, a runtime using a c-like stack, avoiding the GC).

Re: A little Golang way

#154

Post by nickpsecurity »

I appreciate you publishing this experiment as it will show Java's problems for what they are. However, a real test of Go's safety and efficiency would be a comparison to a similar language such as an optimized Wirth language, a subset of Free Pascal (Delphi-style), typed LISP (eg Racket), Julia, or Ada. People keep forgetting about the last one in safe, efficient, systems programming despite it doing for a long time what Go and Rust hope to do eventually. Its long-time use in embedded systems indicates it can be quite efficient.

Regardless, Go certainly improves on the reliability of applications vs C++ while being much more efficient than .NET or Java.

Re: A little Golang way

#155

Post by timtadh »

eternalban wrote: post #68
ploxiln wrote: post #2

I'm all for replacing java bloat with a little bit of go, but it seems like the cause of the bloat becoming a real problem was hopping on the docker bandwagon, for a collection of services that always run together in an appliance and really benefited from being hosted in a shared JVM? Isn't the JVM + servlet container thing supposed to be able to isolate the different services? They get their own bunch of threads, an…

You should read Sun's J2EE specs. There is little semantic distinction between a stateless session bean and a container hosted micro-service. The specs were never fully grasped (imo) by the Java community and those who got it (per gossip I heard) -- appserver vendors e.g. IBM, JBoss, etc. -- effectively crippled the spec by resisting the completion of the APIs that would commoditize their containers. Sun was really a…

So true. I had to read the entirety of the JSP spec (and a few others) when I was an intern to help the company do some static analysis things. I also read a good chunk of Tomcat. Sun had this grand vision of App servers which you could just push code to and it would run completely isolated. The app servers where supposed to be spec compliant meaning your app could run on any implementation. But, and this is what bit the company I was working for, all of the implementations add lots of non-standard bits and broke standard bits. This meant that if you had written your app to go on WebSphere there was essentially no way it was going to run on TomCat without modification.

If Sun had more tightly controlled the marketplace for these things I think the whole ecosystem would have been more robust.

Re: A little Golang way

#156

Post by pcwalton »

Scramblejams wrote: post #152
pcwalton wrote: post #139

Earlier quoted context omitted.

How does Rust not give you that option? The choice of 1:1 and M:N does not affect the programming model at all. It is simply an implementation detail. M:N scheduling is no more a requirement for CSP than Unix is for TCP.

Maybe I'm using terms incorrectly -- is there a good green thread library for Rust which supports the kind of Erlangy experience I've described? I looked around a couple of months ago but didn't find anything that seemed suitable.

Why do you need the threads to be "green"? That's what I'm asking. What's wrong with kernel threads, specifically?

Re: A little Golang way

#158

Post by e12e »

sz4kerto wrote: post #4

"Code size was reduced by almost half, from 175 lines down to 96." Hm, I how can we take a 175 LOC project as something relevant in any way?

Of course, neither program was actually 175 or 96 LOC -- they included thousands of lines of code from the standard library. Which is why it's possible to "do useful things" in ~200 LOC either in java or go (or python or...).

But just because you wrote just 200 LOC, that doesn't free you from bugs and regressions in the remaning thousands of lines of code you rely on.

As an anecdote, at a previous work place we had a program that parsed CVS-files for import into an SQL database. This particular program was written by a researcher (meaning: someone with great domain knowledge, but perhaps not a very strong software engineer) in Visual Basic.

The program worked great, but we had to upgrade the server that ran it to newer versions of windows, and at some point needed to recompile the code (I don't thing this was releated to a bugfix, IIRC it was simply a run-time/linking issue).

As it turned out, the code compiled, but the program didn't work -- MS had changed the API for CVS handling (probably fixing a bug). I don't recall exactly what it was, might have been how floating numbers were parsed/handled, possibly an edge case with Norwegian/English localization or something.

Net result, we had a pretty though debugging job on our hands, for a very small program...

(I feel a bit bad for singling out MS for this -- as I understand it, they are generally very good about maintaining backwards compatibility -- even to the extent that that becomes a problem. I guess we just hit on a corner case with our use-case and this particular old VB code).

Re: A little Golang way

#159

Post by threeseed »

cgag wrote: post #124
chadaustin wrote: post #84

Earlier quoted context omitted.

> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency sure, with an 1:1 thread model as opposed to an M:N thread model. M:N is not always a clear win over 1:1: https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m... Also, to be very clear, Java's threa…

I don't know if the programming model of threads and channels that's used by haskell and golang strictly depends on the existence of M:N threading, but it sure is nicer to use than the model in java/rust.

Go's channels/threading model already exists in Java:

https://github.com/puniverse/quasar

Re: A little Golang way

#160

Post by nickpsecurity »

omginternets wrote: post #150
nickpsecurity wrote: post #149

Earlier quoted context omitted.

That's definitely an advantage. People used to rag on me because I used a BASIC dialect for most of my development. One of main reasons: tens to hundreds of thousands of lines of code compiled and linked effortlessly. I later moved to LISP with its incremental, function-by-function compilation to get pause times down to tenth of a second. Either way, the elimination of long compile cycles and other interruptions main…

One of my colleagues (a Paris Politechnique guy, so very much a mathematical purist) was recently going on and on about the beauty of lisp, and how much better it was than C (on a formal level, of course). I think Go sits on the opposite end of the spectrum. It's a hacker's language, not a mathematician's language. It's ugly and very useful.

" It's a hacker's language, not a mathematician's language. It's ugly and very useful."

Lmao. That's exactly what hackers said about LISP. That people can often emulate a language or even paradigm (eg OOP) within the original language using macro's shows it. Strange enough, LISP can modify itself to do whatever modern languages are doing with similar productivity. It doesn't work vice versa. On top of it, the LISP compilers make pretty fast code for such a flexible language and past engineers even made dedicated hardware for it.

That's why, although far from perfect, LISP is still the ultimate, hackers' language.

Post reply on HN