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

111–120 of 139 posts

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

#111

Post by Dylan16807 »

eternalban wrote: post #56
Dylan16807 wrote: post #32

Earlier quoted context omitted.

You know people write long articles explaining why PHP is not perfect, right?

"It's the economy, stupid", said a former US President. It's the economic attributes of a language that contribute to its market share. Go is a very good language from an economic point of view. (Java was also a remarkably good language, from an economic point of view.) As to the your specific point, I suggest a sufficiently large slice of software workers will include the sub-set that write long articles defending t…

PHP has a couple attributes that make it easy to start using and deploy, and a massive pile of network effects.

Those attributes have nothing to do with why it's a garbage fire, and 'sophistication' also has nothing to do with it. You could redo PHP to be equally sophisticated, and still have the things that make it popular, but also be a hundred times more consistent and less buggy. Heck, fixing refs and inconsistent syntax could make it less sophisticated.

At least they've been fixing some of it...

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

#112

Post by nathcd »

zinclozenge wrote: post #84
slx26 wrote: post #64

Go and Rust are the latest languages I started to use. Neither is perfect, both are awesome, but more importantly, both are a step forward, both get a lot of things very right, and for the rest, most are at least acceptable. When I code, most of my frustrating moments come from underlying problems with cross compatibility, access to hardware, graphics, encodings, etc, which are rarely problems caused by languages the…

Go has some great 'under the hood' features, ie ones provided by its runtime, but man the language syntax makes it really annoying to take advantage of them. The sweet spot for me would be something between Go and Rust, ie a language with generics, algebraic data types, pattern matching, garbage collection, good concurrency primitives with a good work stealing scheduler. So I'm basically asking for OCaml with multith…

In case you haven't heard of it, you should check out Pony (https://www.ponylang.io/). It's definitely got its own flair, but characteristically it's a lot like what you describe.

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

#113

Post by saganus »

Corazoor wrote: post #108
saganus wrote: post #97

Earlier quoted context omitted.

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 point…

I agree that this is the picture I get in my mind when talking about "fat" languages.

So I was wondering if it was something that people felt differently, or if it was mainly the same theme, as it seems like it is.

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

#114

Post by marmaduke »

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…

> What is that "thing" that makes us determine that a language is fat or light?

In the same way the word modern is thrown around in the context of languages that have evolved a bit, I think heaviness is a notion that is an indicator of how committed the person is to the tradeoffs made by the tech: a heavy language made tradeoffs erring on the side of technical debt and the light one has not.

But it's easier to present one's own preferences as technical facts when trying to flame or troll.

In the case of frameworks, they often make choices for you, they are opinionated. It's easier to get unhappy about it, in a bike shed sort of way

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

#115

Post by mijoharas »

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.

I remember the first time I tried to use them.

I just wanted to make some small functions for logging different types of things. I wanted to use parametric polymorphism to dispatch to different functions depending on the type of the thing I passed in. I think I ended up creating a few `log_type_foo` and `log_type_bar` functions rather than the single `log` function I wanted. It looked really ugly to my eye.

The thing I really wanted was parametric polymorphism. I seem to remember reading something where the go people think this is equivalent to generics.

EDIT: clarity

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

#116

Post by benesch »

lossolo wrote: post #60
threeseed wrote: post #46

Earlier quoted context omitted.

And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy. Also with GraalVM you can equally support low memory, fast startup use cases.

> And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy. ZK is using Paxos and Etcd is using Raft. It's difficult to compare languages in this case as you will compare consensus algorithms mostly. > Also with GraalVM you can equally support low memory, fast startup use cases. How is GraalVM performance this days? Last time I've checked[1] it was a lot slower than JIT.…

ZooKeeper uses a custom atomic broadcast protocol, Zab, not Paxos: https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs...

(Atomic broadcast can be reduced to consensus, but frames the problem differently.)

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

#117

Post by snowAbstraction »

ChrisRackauckas wrote: post #105
snowAbstraction wrote: post #80

Earlier quoted context omitted.

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 l…

I meant personally I am less sure about Julia, that my knowledge is less sure. I've neither used it myself nor spent a few hours browser project source code unlike most of other stuff I mentioned.

Since I am not finding what I am looking for in Go then maybe I should ought to try out Julia.

Thanks for the JuMP reference. That looks cool.

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

#118

Post by thelazydogsback »

6thaccount2 wrote: post #20
AdeptusAquinas wrote: post #15

F# hits all his 'perfect language' points for me. It feels like a more concise, opinionated and beautiful refinement of C#.

I really like F#, but it has a few major pain points that hinder adoption: The first is that once a user reads over the various functional things like let statements, record types, union types...etc, you still don't really know how to code in F# unless you already have a .NET and in particular C# background. Nearly all the documentation and books (I have 3 of them) assume you're a C# dev making the switch. This is si…

Well, it's pretty easy to treat F# as OCaml then if you're not doing .Net interop, and mind the edge cases.

Not the newest, but J.H.'s books are great: http://www.ffconsultancy.com/products/fsharp_for_technical_c... (I particularly like the old spiral-bound F# for Scientists.)

F# is pretty close to a first-class citizen in VS and VSCode (Ionide, etc.) at this point and the community seems good -- what support are you lacking?

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

#119

Post by majewsky »

mijoharas wrote: post #115
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.

I remember the first time I tried to use them. I just wanted to make some small functions for logging different types of things. I wanted to use parametric polymorphism to dispatch to different functions depending on the type of the thing I passed in. I think I ended up creating a few `log_type_foo` and `log_type_bar` functions rather than the single `log` function I wanted. It looked really ugly to my eye. The thing…

Go supports parametric polymorphism by specifying arguments with an interface type.

  func DoWorkWith(foo Loggable) { ... }

  type Loggable interface {
    //for example
    LogTo(os.Writer)
  }

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

#120

Post by majewsky »

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…

> It’s littered all over the go code I’ve seen, including the standard library.

From my experience, interface{} is incredibly uncommon in application code. In most instances where the standard library uses it, it's usually justified because the function in question really accepts literally any type of argument, e.g. json.Marshal() or reflect.TypeOf(). The only counterexample I can think of are sort.Sort() and sort.Slice().

Given all the implications of adding generics to the language, I think Go would be better off just adding the common higher-order list/map manipulation functions to the builtins, i.e. the likes of map(), filter(), maybe reduce().

Post reply on HN