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

The perfect language and why Go still isn't it

snazz.xyz

Post reply on HN
Print view View original

101–110 of 139 posts

Re: The perfect language and why Go still isn't it

#101

Post by thanatos_dem »

asdvxgxasjab wrote: post #95
mijoharas wrote: post #50

Every time I've tried to write some go, I've always started reaching for some things that aren't there (essentially generics). I'm looking forward to go 2.0 and hope the inclusion of generics will make it more pleasant to write. Also, while it's said comically often in HN comments, Rust (and particularly the iterator api) is very pleasing to write. I'd say it sits in quite a sweet spot language-wise. Context, I'm a C…

Curious about your use cases for generics. I write a lot of Go and don't often find myself missing generics. I also used to write a good deal of C++ and didn't find myself often needing templates either.

How often do you find yourself writing or using `interface{}`? It’s littered all over the go code I’ve seen, including the standard library.

`interface{}` is the equivalent to using `Object` in java land. It completely punts on any sort of type safety, relying on the developer to handle messy edge cases correctly. I think one of the only reasons that it hasn’t been as severe a problem in go as java is thanks to that explicit error checking that go makes developers do (and that gets so much hate online), forcing developers to consider the case that the type isn’t what they assume.

But genetics provide a useful way to safely make those assumptions, and cut down on the boilerplate around them.

Re: The perfect language and why Go still isn't it

#102

Post by asdvxgxasjab »

thanatos_dem wrote: post #101
asdvxgxasjab wrote: post #95

Earlier quoted context omitted.

Curious about your use cases for generics. I write a lot of Go and don't often find myself missing generics. I also used to write a good deal of C++ and didn't find myself often needing templates either.

How often do you find yourself writing or using `interface{}`? It’s littered all over the go code I’ve seen, including the standard library. `interface{}` is the equivalent to using `Object` in java land. It completely punts on any sort of type safety, relying on the developer to handle messy edge cases correctly. I think one of the only reasons that it hasn’t been as severe a problem in go as java is thanks to that…

I use it all the time indirectly when using a map or working with JSON. I don't find it all that messy to work with. If you're talking about type assertions, I don't use them all that much but they do come up. It doesn't require much boilerplate or special handling. If the assertion fails I return an error like I do everywhere else.

Re: The perfect language and why Go still isn't it

#103

Post by kolanos »

lkrubner wrote: post #98
twic wrote: post #75

Earlier quoted context omitted.

Docker is a bad design. It is monstrously overcomplicated for what it does. In historico-aesthetic analogies, it's baroque, not renaissance.

And what does it actually give that is new? What does Docker give that you can't get with a normal VM, with Terraform to spin up however many instances that you need? Put an app on an AMI, save it, if you need one instance, or a 1,000 instances, spin them up with Terraform. You get to stick with normal operating systems, such as Linux and Windows. You don't have to learn a bunch of new technologies. http://www.smashc…

Terraform is written in Go as well.

Re: The perfect language and why Go still isn't it

#104

Post by geofft »

0x445442 wrote: post #83
geofft wrote: post #73

Earlier quoted context omitted.

Building demos to pad your resume is bad for the company, but building demos to achieve unmet business needs is good for the company, and usually there are plenty of those lying around.

What I've noticed is in a lot of big enterprise shops that are playing "Agile" there is a big gap in support/tooling software; that is, software that makes developers more productive by automating repetitive tasks. Since this type of software doesn't exist to management because it won't fit nicely onto a Jira board or it can't be bent to fit a specific OKR, it's the perfect type of software to explore other languages…

Yes! It's also software that matters very little if you can't get a good support story for it - it's not customer facing and there are no SLAs, so worst case, everyone's automation fails but they can still get their job done. If you want to build a CLI for handling code reviews or an automated bisection tool using OCaml on a Raspberry Pi or whatever, that's way more acceptable than building customer-facing software (either services or shipped software) using OCaml on a Raspberry Pi.

Also, writing this type type of software makes you an actual 10x engineer (by making 10 other engineers more productive).

Re: The perfect language and why Go still isn't it

#105

Post by ChrisRackauckas »

snowAbstraction wrote: post #80
ypcx wrote: post #39

Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it - Go seems to have filled the space that Java was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to use for (which is everything). After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the…

I've been learning a bit of Go and I like what I've understood so far but one thing that seems somewhat lacking in the Go Eco system is mathy projects. I know there are some but I couldn't find many that were both active and to my taste. I was looking to learn and hopefully contribute. I was mostly looking for something mature for either mathematical optimization (stuff like linear, quadratic or integer programming)…

What are you not sure of with Julia here? There are places in the ecosystem to not be sure of, but this isn't one. Julia has probably the most advanced mathematical optimization right now with JuMP (http://www.juliaopt.org/JuMP.jl/v0.19.2/) and some of the most advanced post-DL machine learning with the full language differentiable programming tools (Zygote, Tracker, ForwardDiff) which have showcased applications like quantum machine learning and neural stochastic differential equations (https://arxiv.org/abs/1907.07587). Some of it is still in flux, but in terms of ecosystem there's a lot of stuff there that you won't find in other languages.

Re: The perfect language and why Go still isn't it

#106

Post by lossolo »

lkrubner wrote: post #98
twic wrote: post #75

Earlier quoted context omitted.

Docker is a bad design. It is monstrously overcomplicated for what it does. In historico-aesthetic analogies, it's baroque, not renaissance.

And what does it actually give that is new? What does Docker give that you can't get with a normal VM, with Terraform to spin up however many instances that you need? Put an app on an AMI, save it, if you need one instance, or a 1,000 instances, spin them up with Terraform. You get to stick with normal operating systems, such as Linux and Windows. You don't have to learn a bunch of new technologies. http://www.smashc…

> What does Docker give that you can't get with a normal VM

There is a difference between Linux container (Docker underhood) and full blown Virtual Machine. In case of docker you are not running new operating system, you are just running new processes in different namespace but still using the same kernel. Linux containers are lightweight, you can start them as easy and fast as other processes, without overhead. VM (in most cases) is separate operating system running, which means startup time is different, you have overhead (CPU usage for keeping OS running and all its services, additional RAM usage, additional disk space usage etc) of whole operating system + virtualization overhead (in a lot of cases but can be minimzed).

Re: The perfect language and why Go still isn't it

#107

Post by ypcx »

saganus wrote: post #97
delusional wrote: post #85

Earlier quoted context omitted.

> Java was too fat for I think it should always be mentioned when people call java fat, that the core language is usually fast enough. What makes java "fat" is the mentality of "Frameworks". For me, Go seems like java, but without the fucking frameworks.

I have been wondering for some time now, when exactly is a language "fat" or "light"? The idea seems to be there and "obvious" in a way, but haven't been able to pinpoint exactly what it is. Is it a feeling or an actual metric? e.g. When I work with Java in IntelliJ, things don't feel significantly slower than developing Node in WebStorm. Is it perhaps the way the code looks, in terms of verbosity? I do agree that fr…

The one area where Java feels fat is the memory usage overhead due to 64-bit pointers being used a lot. So if you end up holding and processing a lot of data in RAM, the process allocation and the garbage collector metrics won't look awesome. That said, recently Openj9 improves on this literally by miles. I agree with all the other points - Java and its tooling are very powerful and by that nature they are enabling us to put that much more load on it, so yes, that's where it will be predominantly visible.

Edit: that said, Java was created when we didn't have containers. (Just as Clojure was created before Java had lambdas and aggregate streams). So it may be the time to come back closer to the metal again, but as you point out, we need to maintain a clear mind while contemplating that.

Re: The perfect language and why Go still isn't it

#108

Post by Corazoor »

saganus wrote: post #97
delusional wrote: post #85

Earlier quoted context omitted.

> Java was too fat for I think it should always be mentioned when people call java fat, that the core language is usually fast enough. What makes java "fat" is the mentality of "Frameworks". For me, Go seems like java, but without the fucking frameworks.

I have been wondering for some time now, when exactly is a language "fat" or "light"? The idea seems to be there and "obvious" in a way, but haven't been able to pinpoint exactly what it is. Is it a feeling or an actual metric? e.g. When I work with Java in IntelliJ, things don't feel significantly slower than developing Node in WebStorm. Is it perhaps the way the code looks, in terms of verbosity? I do agree that fr…

Well,"fat" is an unprecise term anyway, but the main concern when evaluating languages like that is mandatory overhead.

What exactly constitutes overhead is debatable, but generally anything that is not strictly necessary for the functionality is considered as such... Even if it has useful tradeoffs.

Examples from Java are the GC, compound types need to be objects and thus are wasting space with type and vtable pointers, and the jvm is actually an interpreter (one with only stack semantics at that).

Since C++ has none of that, it is quite natural to say that it is more lightweight than Java.

But that in itself is not necessarily a judgement about execution speed, although it is heavily implied. If you write Java in a way that it is heavily jitable and doesn't stress the GC, you can end up with a faster program than a naive C++ version would achieve.

But all else being equal, the C++ version will be ever so slightly fester, because less stuff to do means more stuff done.

Re: The perfect language and why Go still isn't it

#109

Post by otterley »

cpuguy83 wrote: post #89
otterley wrote: post #67

Earlier quoted context omitted.

> Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. Can you please elaborate on this? My experience with Go is that it is able to fork/exec programs and manage cgroups via sysfs on Linux at least as well as any other programming language can.

You pretty much need to do everything from a separate process, which is the main issue. Certain things like setns(mountns) will straight up fail in a multithreaded program, so there are some nasty hacks in runc to handle such things in C prior to the go runtime firing up.

> You pretty much need to do everything from a separate process, which is the main issue.

I’m confused. fork()/spawn() are the proper means to launch child processes on Linux. What language would do things differently if the syscall determines the means here?

Re: The perfect language and why Go still isn't it

#110

Post by cpuguy83 »

otterley wrote: post #109
cpuguy83 wrote: post #89

Earlier quoted context omitted.

You pretty much need to do everything from a separate process, which is the main issue. Certain things like setns(mountns) will straight up fail in a multithreaded program, so there are some nasty hacks in runc to handle such things in C prior to the go runtime firing up.

> You pretty much need to do everything from a separate process, which is the main issue. I’m confused. fork()/spawn() are the proper means to launch child processes on Linux. What language would do things differently if the syscall determines the means here?

Because go is always multithreaded. You literally cannot do certain system level things in Go. For instance trying to "setns" to a mount namespace will yield EINVAL from the kernel in all cases with Go.

In fact, all namespace related operations are really annoying to do from Go because the runtime is always multithreaded and you have no control over the threading except for locking the active goroutine to its currently assigned thread. This also makes that thread unusable for any new goroutine (even goroutines that are spawned from code running in that thread), which has the side-effect that the new goroutine will always be in the original namespace context.

Post reply on HN