9 ms·
I cant help feeling it is a missed opportunity to add generics to Go this late. A mistake that is copied from earlier languages (C++, Java), a mistake similar t
by cies 6y ago
I cant help feeling it is a missed opportunity to add generics to Go this late. A mistake that is copied from earlier languages (C++, Java), a mistake similar to other mistakes Go chose not to solve at it's inception, like: having implicit nulls (C, C++, Java, JS, C#), lack of proper sum types (C, C++, Java, JS) and only one blessed concurrency model (JS).
While I think I get the reasons for these decision in theory, make a simple-to-fully-understand language that compiles blazingly fast, I still feel it's a pity (most) these issues where not addressed.
- apta 6y ago> having implicit nulls (C, C++, Java, JS, C#), > lack of proper sum types (C, C++, Java, JS) Incidentally, Java and C# have addressed (or are in the process of addressing) both issues. Both languages/platforms are superior to golang in almost every conceivable way.
- karmakaze 6y agoI'm not aware of any current Java project on Sum types. There is multi-catch for exceptions but no immediate plans I know to use elsewhere.
- apta 6y agoA form of pattern matching and switch expression has already made it to the language as of JDK 14. Those are paving the way for full blown pattern matching and sealed types: https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://openjdk.java.net/jeps/360 https://openjdk.java.net/jeps/360
- richardwhiuk 6y agoJava aren't fixing nulls, IMHO. They are making it worse.
- apta 6y agoHow are they making it worse? In any case, there already exist solutions in place: https://checkerframework.org/manual/#example-use https://checkerframework.org/manual/#example-use https://github.com/uber/NullAway https://github.com/uber/NullAway
- richardwhiuk 6y agoThe code ends up looking like: Optional<Integer> foo; //.... if (foo != null) { foo.and_then(new Consumer () { function accept(Integer foo) { } }); }
- karmakaze 6y agoI would never assign null to an Optional nor use a library that returned one. To ensure assignment before use make it final.
- deleted 6y ago[deleted]
- matwood 6y agoI've used a lot of Java and C#, and a decent amount of Go. I'm not sure I would call Go inferior. The design goals were different. I'm also not a language wonk, so maybe that's why I enjoy the relative simplicity of Go. The developer loop of code, run, code is very fast, and the standard library is good out the box. I just want to write code and get stuff done. To that end, Go is another capable, workman type language (like Java or C#).
- spion 6y agoExcept for green threads.
- erik_seaberg 6y agoThat's true though Project Loom is working on fibers. There's already an early access release to test.
- pgwhalen 6y agoMinor point, they've settled on the name "virtual threads" instead at this point.
- balfirevic 6y agoSum types are not planned for C# 9, are they?
- apta 6y agoIt has pattern matching, but not a full discriminated union implementation yet. That seems to be on the roadmap though: https://github.com/dotnet/csharplang/issues/113 https://github.com/dotnet/csharplang/issues/113 https://github.com/dotnet/csharplang/issues/485 https://github.com/dotnet/csharplang/issues/485
- hactually 6y agoNeither have addressed it though - they do have works in progress. Same as the lack of decent threading in Java. It's been a WIP for years. Lets judge based on status quo rather than being disingenious.
- vips7L 6y agoHow does Java not have decent threading? Go doesn't even have actual threads. I'm assuming you're talking about goroutines aka virtual threads/fibers whatever which are entirely different from actual threads.
- hactually 6y agoapologies, but yes, you're correct - I was referring to green threads
- SureshG 6y agoHopefully will preview in next release (6 months release cycle) http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h... EAP build - http://jdk.java.net/loom/ http://jdk.java.net/loom/
- nine_k 6y agoIf you copy most of your design from Pascal / Modula 2 / Oberon as a safe bet to use a time-proven approach, this is only natural. If you don't want to use a time-proven approach, you need to design your own, and it's a massively more complex and fraught enterprise than adding GC and channels (which are both old, time-proven designs, too, just from elsewhere). You could say that one could maybe copy the time-proven OCaml. But OCaml doesn't have a proven concurrency story, unlike Oberon and Modula-2 (yes, it had working coroutines back in 1992). I also wish all these design decisions would not have been made in a new language, like they haven't been made in Rust. Unfortunately, the constraints under which creators of Go operated likely did not allow for such a luxury. As a result, Go is a language with first-class concurrency which one can get a grip of in a weekend, quick to market, and fast to compile. Most "better" languages, like Rust, OCaml, or Haskell, don't have most of these qualities. Go just fills a different segment, and there's a lot of demand in that segment.
- cies 6y ago> first-class concurrency That's an overstatement. Also implicit nulls are not beneficent to anyone. And sum types could have made results (error/success) so much nicer. I see no reason to go with nulls at Go's inception, hence I call it a mistake.
- ernst_klim 6y ago>As a result, Go is a language with first-class concurrency which one can get a grip of in a weekend Which is a mess. Sending mutable objects over channels is anything but "proven concurrency story". Both Rust and Haskell (and OCaml, if we talk about concurrency and not parallelism) have way better concurrency story than Go. I don't care how fast one could start to write concurrent and parallel code if this code is error prone. The only difference between Rust/Haskell and Go is that the former force you to learn how to write the correct code, while the latter hides the rocks under the water, letting you hit them in production.
- nine_k 6y agoI used "first-class" here to denote "explicitly a feature, a thing you can operate on", like "first-class functions" [1]. I didn't mean to say "best in class". I don't even think we have a definite winner in this area. [1]: https://en.wikipedia.org/wiki/First-class_function https://en.wikipedia.org/wiki/First-class_function
- simias 6y agoI feel the same way, but then again Rust (among others) exists so it's not like those of us who dislike this approach are "stuck" with Go. I think it's actually nice to have the choice, reading the comment in this thread it's pretty clear that there are people who don't feel like we do. Go clearly values "simple and practical" over "elegant". It seems to be quite successful at that.
- totalperspectiv 6y agoI agree with the spirit of what you are saying, but I'd nit pick and say that lack of generics and presence of implicit null types make Go not simple and not practical over other options in the same space.
- geodel 6y agoAs someone using Java which has null and hardly using any generics even though they are available in Java. I find Java immensely practical with huge number of libraries and other facilities of ecosystem. Seems you are of the opinion if you do not find something practical no one else can.
- kortex 6y agoAnd I find go immensely practical and Java immensely impractical. But I see its value. It's almost like we have different languages because people are myriad :) Problem-space and learning styles play a huge role.
- geodel 6y agoHaving seen Java shortcomings up and close I can totally understand that. It is just that some folks think their subjective opinion about programing are some universal objective truths.
- entha_saava 6y agoI have to refute this 'simple and practical' claim. Not having generics and neither having very common tools doesn't seem very good. You will have to write a for loop for what is a simple function call in python or javascript or <insert modern language here>. Such detail easily interrupts reading / writing flow.
- ChrisMarshallNY 6y agoSwift had generics in place from Day One. It also hides the generics when they don't need to be shown (like many collection types). I think that most of the standard language features are based on generics, but you would never know it, as a user of those features.
- apetrovic 6y agoTo be fair, Swift have a bit strange generics implementation that forces programmer to jumps through hoops to achieve something quite common in similar programming languages. The whole standard library is peppered with AnyThis and AnyThat, the language doesn't have generators (yield) and I'm not sure they're possible with the current generics design and programmers needs to learn what is type erasure just because the core team decided that returning generic interface from a function is something nobody will want. I like Swift a lot, for many reasons, but generics design isn't one of these reasons.
- ChrisMarshallNY 6y agoFair 'nuff. I was always a fan of the way C++ did it, but it was a great deal more technical. Swift is sort of "generics for the masses." C++ is a lot more powerful, but also a lot more "in your face." I really do like the way that Swift allows generics to have implicit types.
- icholy 6y agoCan't get enough of those template errors.
- jasonhansel 6y agoGo really should have learned 2 lessons from Java 5: 1. People will eventually want generics 2. Retrofitting generics onto an existing language is hard and leads to unusual problems (edit: I'm glad Go is doing this, but...Java learned this in 2004.)
- mikelward 6y agoIf this follows the monomorphic approach described in Featherweight Go [1][2], they will at least avoid problems caused by type erasure and avoid too much runtime overhead. 1. https://arxiv.org/abs/2005.11710 https://arxiv.org/abs/2005.11710 2. https://news.ycombinator.com/item?id=23368453 https://news.ycombinator.com/item?id=23368453
- jasonhansel 6y agoBut then you have compile time overhead (an issue Rust and C++ have faced). One of Go's design goals was to have very fast compile times, which might be in doubt if they take the monomorphization approach.
- deleted 6y ago[deleted]
- entha_saava 6y agoIs rust's slow compile time because of poor LLVM IR generation or just because monomorphization? D has generics and compiles fast. I guess Nim compile times are okay, too..
- gowld 6y agoAre you saying Go should have not launched in 2009, but shout have waited 10 years until generics were ready?
- jeremyjh 6y agoIf they made it a priority they could have shipped in 2010 with generics. There is no new art in this design.
- chubot 6y agoThe flip side was on the top of HN yesterday: Generics and Compile-Time in Rust https://news.ycombinator.com/item?id=23534974 https://news.ycombinator.com/item?id=23534974 It's easy for spectators / bystanders to call something a mistake because you don't understand the tradeoffs. Try designing and implementing a language and you'll see the tradeoffs more clearly.
- entha_saava 6y agoD has generics and compiles fast. There are probably other examples too. The overlooked thing is rustc produces poor quality LLVM IR which is also mentioned in FAQ. And generics reduce amount of manual for loop juggling code one has to write. I don't think adding generics makes much of a difference.
- 59nadir 6y ago> The overlooked thing is rustc produces poor quality LLVM IR which is also mentioned in FAQ. LLVM is also slow in general. If you use it, it's likely the thing that's bottlenecking your language's compile-time unless you've done something insane like templates and `#include`, etc.. Inevitably it's the case that even if your source language doesn't do nearly as badly at the design stage when it comes to generics as C++ does, if you use LLVM your build stage is probably going to be unacceptably slow.
- entha_saava 6y ago> LLVM is also slow in general. Agreed. But so is GCC. And I guess many of the 'zero cost' abstractions require some advanced optimizing compiler like LLVM to be zero cost (or move that complexity to compiler end). They specifically mentioned the technical debt and poor LLVM IR Generation issue though. I wonder if it has yet gotten attention or fixed. Maybe @pcwalton knows.
- chubot 6y agoOK sure, now write your own backend or use one other than LLVM (which one?). Now you're going to learn about a different set of tradeoffs.