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

Go vs. Swift [pdf]

github.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Go vs. Swift [pdf]

#111

Post by SomeHacker44 »

chmike wrote: post #74

I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent…

"The best way to express it is that with Go programming is fun again."

I beg to disagree in the strongest possible terms. I found programming with Go to be the opposite of fun. It's a highly opinionated language which gives people poor libraries, poor tooling, and the worst of many possible worlds. It's as if someone who couldn't see past C wanted to be slightly Erlangish.

No thank you, I will go back to Common Lisp and Haskell any day of the week from this abomination of a language. I've been exploring Clojure (on JVM, CLR and JS) as a practical alternative to CL lately.

Re: Go vs. Swift [pdf]

#112

Post by SomeHacker44 »

unscaled wrote: post #104
chmike wrote: post #74

I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent…

> Go is a very original language in this aspect as well as with concurrency Actually it isn't. Using object Composition/Aggregation is a very old, and composition as the recommended paradigm dates back at least to COM (that's just my memory, it's probably older). Granted, delegation in COM aggregates was based on conventional interface and not structural typing, and it was implemented using ugly C macros, but dynamic…

"[I]t's about as fun as fingernails on chalkboard."

Nailed it.

Re: Go vs. Swift [pdf]

#113

Post by weberc2 »

cabalamat wrote: post #98
pawadu wrote: post #63

I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]? I would rather see a discussion about performance, platform support, maintainability, governance and do on. --- [1] someone please create a new programming language where the empty file means "print hello world". Since you can…

> And why should I care how many lines "hello world" is in a language? Because it's a good proxy for how good the language is for writing short, (often) throwaway programs.

I don't even think it's that. It's a good indicator of the language's ability to print a string constant, and nothing more.

Re: Go vs. Swift [pdf]

#114

Post by specialist »

hardwaresofton wrote: post #103
specialist wrote: post #99

Earlier quoted context omitted.

The compiler should be helpful. I love checked expressions, hate Optionals. I'll be happy when the language pimps stop trying to make Java look and act like a scripting language. Edit: I apologize if I've offended anyone with my opinions. I hope this helps. http://bit.ly/1S1943H

https://www.reddit.com/r/java/comments/5dgm96/are_checked_ex... They generally also break encapsulation (though you can kind of work around/sidestep this by making top-level visible errors more opaque) Do you have a good reason you'd like to share for liking checked expressions? It seems like the reason you like it is because it's enforced by the compiler -- but I don't think this makes them the right choice, as the…

"...a good reason you'd like to share for liking checked expressions?"

Because they're the best solution for the problem. In Java.

The problem with Java's checked exceptions is misuse; turgid overwrought frameworks which obfuscate. Work closer to the metal. Eschew Spring, JPA, Annotations, aspects (AOP). All terrible ideas (making Java more dynamic) implemented terribly. (Quoting myself: Spring is an exception obfuscation framework.)

If you have to catch an exception you can't handle, revisit the design.

Your linked comment references sum types (Rust, Haskell) and multiple return types (Go). I haven't used those, so I can't comment.

The only solution better than checked try/catch/finally might be proper state machines. Experimenting with that is (far down) on my to do list. I'm also curious about Erlang/Elixir (and CSP in general), which uses a completely different strategy for error handling.

*"... Java 1.8, it is a fact that optionals are not checked by the compiler..."

Java's Optionals are a bad idea implemented badly.

The Correct Answer is using the Null Object pattern. Or just use LISP/Scheme. Also good ideas are intrinsic path expressions (vs method chaining) and pattern matching.

---

Top-thread, someone shared the "composition over inheritance" heuristic. This is more correct. Null Object and composition are like peas and carrots.

You mention "breaking encapsulation". So? Choose composition, make most objects dumb, implement the smart/active parts as yet another Interpreter. Problem solved.

Re: Go vs. Swift [pdf]

#115

Post by wyager »

majewsky wrote: post #96
bad_user wrote: post #82

Earlier quoted context omitted.

> `5 == Just 5` fails. But in Swift this works like you would want Why in the world would you want those two to be equal when they obviously don't represent the same thing? That doesn't make sense, not even if they have the exact same memory representation, in which case I'm pretty sure it has been a compromise, which would mean you're still dealing with `null` with some lipstick on it, making that type behave incons…

> Why in the world would you want those two to be equal when they obviously don't represent the same thing? This is the difference between normal people and theoretical computer scientists, summarized in one sentence.

As suggested by the existence of this monstrosity, "theoretical computer scientists" have it right on this one.

https://dorey.github.io/JavaScript-Equality-Table/

Re: Go vs. Swift [pdf]

#116

Post by GregBuchholz »

majewsky wrote: post #95
GregBuchholz wrote: post #47

Earlier quoted context omitted.

>in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. -- Probably nothing like in Swift instance (Num a , Integral a) => Num (Maybe a) where fromInteger x = Just (fromIntegral x) main = print $ 5 == (Just 5)

This only works because you're working with number literals here, which have the very liberal type "Num a => a". If I replace your main function by check :: Int -> Bool check x = x == (Just x) main = print (check 5) I get a compile error: Main.hs:7:17: error: • Couldn't match expected type ‘Int’ with actual type ‘Maybe Int’ • In the second argument of ‘(==)’, namely ‘(Just x)’ In the expression: x == (Just x) In an e…

Right, it was just a fun little "Well Actually" moment.

http://tirania.org/blog/archive/2011/Feb-17.html

Re: Go vs. Swift [pdf]

#117

Post by mahyarm »

G4BB3R wrote: post #94
mahyarm wrote: post #53

Earlier quoted context omitted.

Aha! You haven't hit the LOC barrier that starts to make swift & xcode/source kit act like bsaul described. At around 100kloc you will start to get that experience with swift. While an equivalent 100-200kloc line app written in objective c will work quite fine with xcode. You'll start noticing some degradation as you get to 60-70kloc. You also have a simple module structure, which makes things better. You can see it…

Then, it's not Swift that is not production ready, but XCode that is crap :)

Most of this crap comes from the compiler / sourcekit itself, which is a major part of the language. It has scalability problems.

Re: Go vs. Swift [pdf]

#118

Post by solidsnack9000 »

eridius wrote: post #60
solidsnack9000 wrote: post #54

Earlier quoted context omitted.

The two differences that I wonder about: * What is the cost profile of Dispatch relative to the Go scheduler? It seems that Go programs suffer a slow down just to enable multi-threading, for example -- which is not unlike other systems (GHC at some time in the past) that have a similar model. * Is Dispatch suitable for "millions of threads" ala Erlang? Hundreds of thousands of threads? Dispatch allows you to decide w…

AIUI Dispatch is suitable for potentially hundreds of thousands of queues. It doesn't spin up thousands of actual OS threads, instead it intelligently manages a pool of OS threads and multiplexes the queues onto them. IIRC each dispatch queue is around 100-200 bytes in size (while empty).

Yeah but I wonder about is, is the concurrency truly fine-grained and scalable? For example, you want to do a map over an array of 1 million elements. Can you dump a million blocks on a queue for a linear speed-up?

Re: Go vs. Swift [pdf]

#119

Post by eridius »

solidsnack9000 wrote: post #118
eridius wrote: post #60

Earlier quoted context omitted.

AIUI Dispatch is suitable for potentially hundreds of thousands of queues. It doesn't spin up thousands of actual OS threads, instead it intelligently manages a pool of OS threads and multiplexes the queues onto them. IIRC each dispatch queue is around 100-200 bytes in size (while empty).

Yeah but I wonder about is, is the concurrency truly fine-grained and scalable? For example, you want to do a map over an array of 1 million elements. Can you dump a million blocks on a queue for a linear speed-up?

You could dump a million blocks in the queue, but that's probably too fine-grained. Each block is an allocation and there's some amount of overhead to executing blocks (though I've never measured how much). So unless each element actually takes a long time to process, you probably want to batch it up into larger segments. Dispatch has an API explicitly meant for this scenario (doing concurrent work over an array of elements), which is dispatch_apply() in C or DispatchQueue.concurrentPerform(iterations:execute:) in Swift, though the block is just given an index and it has to do the legwork of reading the correct elements from the input.

Re: Go vs. Swift [pdf]

#120

Post by SomeHacker44 »

danielparks wrote: post #55

Go feels like a beefed up version of C. Swift feels like a high level language with static typing. Interestingly, Swift doesn't feel much like Obj-C.

With C you almost always know what you have, and can always cast it to anything else you want (safely or otherwise).

With Go, I'm never sure what I have (pointer? reference? something other and weird?), and can't cast things that should be castable.

Either way, I'd still rather take Haskell or Common Lisp, but I'd gladly take C over Go after having used Go for a highly multithreaded communications server.

Post reply on HN